Document: draft-ietf-dnsop-dnssec-operational-practices-07.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Tuesday 2/28/2006 7:03 PM CST IESG Telechat Date: Thursday, 02 March 2006 Summary: Slightly surprised this isn't a BCP even given the disclaimer - I know it updates RFC2541 which was Informational. It does after all represent the best advice that is around at the moment and unlike RFC2541 it really is about operational practice. I think I would support BCP for this. Either way it is almost ready. In general the document seems well written and helpful: Not being a DNS administrator I can't vouch for its completeness or accuracy. I think a brief section summarizing what DNSSEC needs and how it works would make it useful for operators trying to get a feel for the operational load before diving into the details. Otherwise there are a number of editorial nits that ought to be fixed: they are IMO a bit more than copy editing but could be handled that way. In particular the tables in sections 4.2.x need more captioning and the non-IETF references need additional information. Editorial: s1: Refs to the defining RFCs for DNSSEC would be a good idea. s1.1/s1.2: good idea to say where DNSKEY, RRSIG, SOA, NOTIFY, IXFT, and AXFR records are defined and maybe include them in the glossary. s1.2.: Expand RR, TTL. s1.2, "Signature publication period": a/After one stopped/After one stops/ s3.3, para 3: s/For a key sizes that matches/For key sizes that match/ s3.4, para 3: s/is roughly done at the same speed as with RSA/takes roughly the same time as with the RSA procedures/ s3.4. para 5: s/recommend to use/recommend the use of/ s3.5, para 1: s/it does not make much sense in making/there is not much sense in making/ s3.5, para 2: s/Paragraph 1 of that RFC/The first part of the selection procedure in Section 1 of that RFC/ s4.1.1, bullet 3: s/to both fetch and verifying/to both fetch and verify/ s4.2.1.1: The first table in this section would be more immediately comprehensible if it had - Column titles e.g., Stage 1 Stage 2 Stage 3 Stage 4 - A caption: e.g., Stages of Deployment for Pre-Publish Key Rollover and an introductory sentence for the description of the stages: Pre-publish Key Rollover involves four stages as follows: Similarly for the second table and the tables in s4.2.1.2 and s4.2.2. s4.2.1.2, new DNSKEY stage: s/The rollover period will need to exist/The rollover period will need to continue/ (?) s4.2.2: expand DS s4.4.1: s/off-band/out-of-band/ (2 places) (i think) The three non-IETF references are rather incomplete: ref 11: A copy of this paper can be viewed at http://www.win.tue.nl/~klenstra/key.pdf ref12: The publication data for this book is ISBN 0-471-12845-7 (hardcover),0-471-59756-2 (paperback), John Wiley & Sons Inc ref 13: The actual workshop notes are hard to find. The IETF site has a presentation that gives some top level bullets but the detail appears to be only in this one message http://www.cafax.se/dnssec/maillist/0000-00/msg00153.html This is a little ephemeral: It might almost be worth taking the relevant paragraph out and quoting it in an Appendix. Appendix A: Key size and next entry: s/mathematical/mathematically/ (2 places) Appendix A "Singing the Zone File": For the folkies among us I anticipate that the new series of Radio Ballads now being broadcast on BBC Radio 2 (Monday evenings from 27 Feb, Listen Again available for 7 days after) will contain an extra programme lamenting in song the sad demise of the traditional profession of unsecured DNS Zone Administrators as, without the cryptic keys, their zones are gradually poisoned out of existence. [http://www.bbc.co.uk/radio2/radioballads/, http://www.bbc.co.uk/radio2/radioballads/original/singingthefishing.shtml] PS: I expect to hear a Zone File sung in the bar in Dallas!