-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alfred,
I have no further comments on part (A). I have also adopted the leftovers in part (B), with explanation in between lines. Best regards, Matthijs On 04/11/2012 10:08 PM, Alfred � wrote: > 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. Ok, with that explanation I at least understand why you suggested this change. Adopted. >>> ... >>> >>> (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. But it was ambiguous (at least to me), so I suggested the other wording. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhpABAAoJEA8yVCPsQCW5yVsH/jSUiaExz5hP7s5sscxXOIaz UmP2r3KLOWnG6f46I3inkRSv2LcDfLnI0OFkWnjhoy2bR0QbRfTeEMWRkFfJBSAc 2cOMoKgcF+ytRQl2PBkEUiRsnoe+9ExRQHD2HnnyrNHdYyj3Lt445x0XoDF4NnAw P2KZugLbxW15LHkfQ4ng/kwExw9bIVCAkk75zn2DtQx3YomSa7APdZreDhrTYrJL GRY53vEsdhxXo4wPJxp+PqSzVG5YlhCgEwMAjucWNOy74JKq1PS75B7KfKwpMAhj +EXNulnmf8zevkobrWA7J8f8SCrzVUbquqiytk6+/hRVxt3XVnVl1ccFSjT88o4= =uGVH -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop