Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
RFC 6605

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

(Ralph Droms; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-02-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 steering group member) No Objection

No Objection ( for -06)
No email
send info

(David Harrington; former steering group member) No Objection

No Objection ()
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) (was Discuss) No Objection

No Objection (2012-02-28)
No email
send info
Thank you for addressing the issues raised by Bill Mills in his AppsDir review.

(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2012-02-13)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2012-02-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection (2012-02-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Russ and PSA's DISCUSS points