DNSSEC Operational Practices, Version 2
RFC 6781

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

(Ron Bonica) Yes

(Stephen Farrell) Yes

Comment (2012-08-29 for -12)
No email
send info
Excellent document, thanks.

I found the diff from RFC 4641 to be too big to be much use
(with the time available for review) so feel free to tell me
where to go if I make a comment on existing 4641 text and
you don't wanna think about the comment.

- 3.4.1 - I think its fair to say now that rsa-sha256 is
widely supported in libraries at least. I've no idea about
how well its supported in validators, but the lack of sha256
in libraries was previously the cause of delay elsewhere.

- 3.4.4 - Maybe worth a reference to the Lenstra paper [1]
as a warning to use good RNGs. They found a non-negligible
percentage of keys that were badly generated due
(presumably) to a lack of good randomness when e.g. devices
were first powered on.

   [1] http://eprint.iacr.org/2012/064

- 4.4.1 - "to be a fraction of your signature validity
period" is unclear. 1/100000 is a fraction as is 9/10 but so
is 100000/1. In another reading of that text you might also
be asking that the signature validity period be a multiple 
of the TTL. I think that needs to be made more clear.

- 4.4.2.2 - Is "Inception time" well (enough) defined? It is
mentioned in 1.2 but I'd forgotten that by the time I got
here and 1.2 doesn't have a reference. Might be no harm to
say a bit more about what that is in both places. (In
particular since here, you also have the inception offset
which is not defined in this doc.) Maybe do that in 
appendix A?

typos:

- p8, last sentence of 3rd para has a typo, maybe
s/are based/that are based/

- p10, typo, s/it's not much point/there's not much
point/

Barry Leiba Yes

Comment (2012-08-30 for -12)
No email
send info
Another vote for "A fine document."  And another vote for "Turn Appendix E into a retained summary of changes from 4641."

(Sean Turner) Yes

Comment (2012-08-30 for -12)
No email
send info
This was a pleasure to read - nicely done.

One shameless plug for security considerations of MD5 and SHA-1: RFC 6151 (MD5 Security Considerations) and RFC 6194 (SHA-1 security considerations).

(Stewart Bryant) No Objection

Comment (2012-08-30 for -12)
No email
send info
I have not read this draft, but from the reviews of my IESG colleagues, it is clear that I would have no objection to it's publication.

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-08-29 for -12)
No email
send info
I would also like a summary of changes from 4641 to be retained in the final document.

(Brian Haberman) No Objection

Comment (2012-08-28 for -12)
No email
send info
I have no problems with the publication of this document, but I do have one suggestion...

The change information in Appendix E is quite useful, but it currently says it should be deleted prior to publication.  I would suggest keeping the appendix, maybe in a more condensed format, to identify the key changes made from RFC 4641.

(Russ Housley) No Objection

(Pete Resnick) No Objection

(Robert Sparks) No Objection