Matthijs, again thanks for your quick and detailed response and action. A few selected follow-up remark can be found inline below.
On 11 Apr 2012 15:48:26 +0200, Matthijs Mekking wrote: > On 04/05/2012 12:48 AM, Alfred Hönes wrote: >> Here we go with part (B); if deemed necessary, please consider >> to provide feedback for the items below on the list. > > Again, all items that are adopted without feedback necessary have > been omitted from this reply. And I additionally dropped those items where I'm satisfied with your response and do not see the need to add more thoughts. >> (B) Editorial flaws >> ++++++++++++++++++++ >> >> ... >> >> (B.3) Section 1.2 -- clarification >> >> With respect to item (B.1) above, I suggest to even better clarify the >> definition of "Signature validity period" in Section 1.2 (1st bullet): >> >> OLD: >> | o "Signature validity period" The period that a signature is valid. >> | It starts at the time specified in the signature inception field >> | of the RRSIG RR and ends at the time specified in the expiration >> | field of the RRSIG RR. >> >> NEW: >> | o "Signature validity period" The time interval during which a >> | signature is valid. It starts at the (absolute) time specified in >> | the signature inception field of the RRSIG RR and ends at the >> | (absolute) time specified in the expiration field of the RRSIG RR. > > I don't see why this should be changed. Do you prefer interval over > period? Do you want the clarify that the times are absolute? This is a > non-issue in my opinion. Well, the issue is that RFCs 4033 and 4034, after initially using the precise term, "signature validity interval", have switched to use the misnomer "signature validity period", and we are stuck with that unfortunate usage for consistency with RFCs 4033/4034. "Period" is used in "Re-Sign Period" "Refresh Period" in this draft in the proper sense of a period - a recurring, floating interval that relates to the reciprocal value, a frequency. Therefore I still believe that it is worth emphasizing here, early in the document, that "period" in "signature validity period" is different, actually being a fixed time interval that, once passed, will not recur. The suggested two additions of parenthetical "absolute" [time] seem to be a suitable way to do that with a very small textual footprint. >> ... >> >> (B.6) Section 4.1.5, list items below Figure 5 -- clarifications >> >> (c) >> In subsequent list items, I suggest to clarify the text -- where >> becessary -- by making the distinction between "old" and newer data >> more explicit, and -- in two instances -- an indication of the >> possibility of more than one DNSKEY RR (as in the Figure, due to the >> split KSK/ZSK scheme used) should be indicated by talking about the >> "DNSKEY RRset": >> >> | new DNSKEY: After the cache data has expired, the new key can be >> added to the zone. >> --- vvvvv >> | new DNSKEY: After the old cache data has expired, the new key can be >> added to the zone. > > What is an old cache? I suggest "After the old data has expired from > cache" here. The proposed text did say "old cache data", not "old cache". :-) But the wording you suggest is fine as well; I just tried to a change with a smaller footprint. > >> | DNSKEY removal: After the cache data for the DS has expired, the old >> | algorithm can be removed. This time the key needs to be removed >> | first, before removing the signatures. >> --- vvvvv >> | DNSKEY removal: After the cache data for the old DS has expired, the > > "old DS RRset" Agreed. > >> | old algorithm can be removed. This time the old key needs to be >> vvvvv ^^^^^ >> | removed first, before removing the old signatures. >> >> ... > > Best regards, > Matthijs Best regards, Alfred. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
