I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Document: draft-ietf-dnsop-dnssec-operational-practices-07.txt
Intended Status: Informational
Shepherding AD: David Kessens
Review Trigger: IESG Telechat 2 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!
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
