<[EMAIL PROTECTED]> wrote on 05/18/2007 02:06:50 PM: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call > comments you may receive. > > > Document: draft-ietf-dnsext-nsec3-10 > Reviewer: Pasi Eronen > Review Date: 18 May 2007 > IETF LC End Date: 23 May 2007 > IESG Telechat date: 24 May 2007 > > Summary: This draft is basically ready for publication, but has > nits that should be fixed before publication. > > Comments: > > This is a very complex document, and quite difficult to understand for > someone who's not intimately familiar with the existing DNSSEC specs > (like myself). Thus, my review is quite superficial... > > Some minor suggestions for improvement: > > 1) This document creates a new registry for NSEC3 RR hash algorithms. > Is there a reason why the existing registry for DS RR hash algorithms > can't be used?
Yes. The seperation was a result of a discussion that lead to "issue 22: Defining new hash algorithms": Initially, we'd piggyback on the registry for DS RR hash algorithms. This lead to a number of concerns: a) Operators might get the impression that if a new hash algorithm is added to the DS registry, then it is automatically defined for use in NSEC3. b) The desirable criteria for a DS digest algorithm and an NSEC3 hash algorithm are not exactly the same. For instance, NSEC3 is less sensitive to the second pre-image resistance property of a hash. In fact, algorithms that would simply not be acceptable for DS may be totally fine for NSEC3 (e.g., MD5.) c) There are things that must be defined about how a hash works with NSEC3 before it can be successfully used. For instance, if the hash length is longer that 63 characters in base 32, then the hash must be split across multiple labels. The consequences of this will no doubt require a significant amount of specification, possibly modifying the current NSEC3 specification. Hence the decision to split. > 2) Section 10.1: it would be useful to give a numerical example of > what the maximum length is (for say, "foo.example.com" zone and SHA-1), > instead of just saying "it depends". I will add an example. > 3) Appendix A: it would be useful if the example zone contained > a list of hashes-vs-names as comments (they're included later > in the example queries/answers, but wouldn't hurt repeating them...). I'll add that too. > 4) Section C.1 seems to be in wrong place. Given its location, I > would expect to find only some background information, not sentences > containing MUST or SHOULD keywords. Probably this should be somewhere > earlier in the document? I'll raise it with the other authors, but I think you have a point. > 5) I found Section C.2.3 very confusing. It's not clear whether this > section describes a feature of the protocol, or a feature that was > proposed but was not included (and design rationale why not). Either > way, this section needs clarification. That's historic stuff. Will remove. Thanks Pasi Roy _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
