Skip to main content

DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
draft-ietf-dnsext-nsec3-13

Yes

(Mark Townsley)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Lars Eggert)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Sam Hartman)

Note: This ballot was opened for revision 13 and is now closed.

Mark Townsley Former IESG member
Yes
Yes () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2007-05-22) Unknown
  From the Gen-ART Review by Pasi Eronen: 

  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?

  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".

  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...).

  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?

  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.
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was Discuss) No Objection
No Objection (2007-05-21) Unknown
Appendix C.1 begins with the statement:

"Augmenting original owner names with salt before hashing increases
the cost of a dictionary of pre-generated hash-values."

It would be helpful if this section explained that including a salt,
regardless of size, does not affect the cost of constructing the
NSEC3 RRs using the method outlined in section 7.1.   (It does,
however, increase the size of the NSEC3 RR.  That should also be
noted.)