Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)
-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. --- v | 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
Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2012 12:48 AM, Alfred � 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. (B) Editorial flaws (B.1) general -- terminology The draft should make more consistent use of signature timing terms. Adopted your suggestions. (B.2) Section 1 -- outdated text The 2nd paragraph of Section 1 says: During workshops and early operational deployment, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these experiences into a set of practices for zone administrators. At the | time of writing -the root has just been signed and the first secure | delegations are provisioned- there exists relatively little experience with DNSSEC in production environments below the top-level domain (TLD) level; this document should therefore explicitly not be seen as representing 'Best Current Practices'. Instead, ... The tagged phrase seems to be outdated now and should be updated to reflect te successful deployment of DNSSEC in the Root zone and many TLDs. As of today, the ICANN TLD DNSSEC Report (2012-04-03) ( http://stats.research.icann.org/dns/tld_report/ ) says: | Summary | | * 313 TLDs in the root zone in total | * 91 TLDs are signed; | * 85 TLDs have trust anchors published as DS records in the root zone; | * 4 TLDs have trust anchors published in the ISC DLV Repository. So I suggest to modify the dangling sentence in the above quote to say: During workshops and early operational deployment, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these | experiences into a set of practices for zone administrators. Although | the DNS Root has been signed since July 15, 2010 and now more than 80 | secure delegations are provisioned in the root, at the time of writing there still exists relatively little experience with DNSSEC in production environments below the top-level domain (TLD) level; this document should therefore explicitly not be seen as representing 'Best Current Practices'. Instead, ... Yes, that's what you get when a document is laying around for so long. It used to be the root is being signed ;). But I have adopted your change. (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. (B.5) Section 4.1.1.1 -- clarifications a) The preamble to Figure 1 says: | Pre-Publish key rollover involves four stages as follows: For clarity on first reading, I suggest to make this clause a bit more precise, in mentioning the role of the ZSKs in the figure: vvv | Pre-Publish key rollover from key 10 to key 11 involves four stages | as follows: IMHO, there is no need to repeat a similar addition for subsequent figures because a sequential reader of the memo will take note of the elaborations below Figure 1 and not need to be made aware of similar context in the other rollover figures. Or Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves... (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. --- v | 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. | DNSKEY removal: After the
Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)
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. --- v | 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. --- v | 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 v ^ | 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
Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)
On 11 April 2012 14:48, Matthijs Mekking matth...@nlnetlabs.nl wrote: On 04/05/2012 12:48 AM, Alfred � wrote: | 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. The word 'period' means the (constant) interval between events in a sequence; for example, the orbital period of a satellite. The time elapsed between aperiodic events occurring at times t1 and t2 is best described as an interval of duration (t2-t1). Absolute time was deprecated in 1905. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
