-----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: > > vvvvvvvvvvvvvvvvvvvvvvv > | 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. > --- 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. > | 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" > | old algorithm can be removed. This time the old key needs to be > vvvvv ^^^^^ > | removed first, before removing the old signatures. > Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhYuqAAoJEA8yVCPsQCW5mXMH/ROOolBIhhyLQqq+8OEbaFxn 1czQaoqxF/O7Uzwe5BID3+3a5aCFBh2RouBwkdSdFHurLPTnjEH0L1vOM76rKduM QfOZlgk96LT3wAAQUYD63fMonT40q+erxqfgYNKfDrDMlwcsTeQDQkVgoTJX6xyR y9CJaWyvHaybfDT04mSkzYvOXuUukfUJEfwD+ErCuSifGluD40OacnZk0s9euxvn iK2fnZMhu81OXpztSEuDlk6XyWgeIfZZUsPHi4YpJorTT6f/fgMibYOvZFQwd1AW JufSOMEthXiyXUldZf4Fg4A6RoUVGyigGsBL6TK6x+/721ujE2Va8OXal48LsLo= =Pe21 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
