Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
draft-ietf-dnsext-ecdsa-07
Yes
(Ralph Droms)
No Objection
(Dan Romascanu)
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
Note: This ballot was opened for revision 06 and is now closed.
Ralph Droms Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-02-14)
Unknown
I presume that Section 6 needs to be updated as this document goes through the publication process. I think you should provide instructions to the RFC Editor on what should be done to this section. A way to do this would be to supply an RFC Editor note that fixes the section consistent with the actual IANA allocations, but will not show in the document until published as an RFC.
Dan Romascanu Former IESG member
No Objection
No Objection
(for -06)
Unknown
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
(was Discuss)
No Objection
No Objection
(2012-02-28)
Unknown
Thank you for addressing the issues raised by Bill Mills in his AppsDir review.
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2012-02-13)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-02-13)
Unknown
Section 4 says you MUST support signing "and/or" validation with both lengths. I think that is not quite clear enough as the requirement differs for different players in the DNSSEC game. Aside from basic clarity, which is the most important thing, there is also an IPR declaration here that distinguishes between things that are needed and things that are optional so I think expressing it in a way that makes clear that there are no optional-to-implement bits for anyone would be an improvement. I'd say that it'd be better to spell it out that implementations that create DNSSEC values to put into the DNS MUST implement signing and verification for both lengths, and that DNSSEC clients MUST implement verification for both lengths. (Or whatever is the right way to say thing.) Will the examples be re-done after IANA have allocated codes? Be more than nice if that were to be the case. An informational pointer to RFC 6090 might be no harm here (and everywhere that uses ECC).
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(2012-02-14)
Unknown
I support Russ and PSA's DISCUSS points