DNSSEC Operational Practices, Version 2
draft-ietf-dnsop-rfc4641bis-13
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
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
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
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
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
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
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.