Skip to main content

DNSSEC Operational Practices, Version 2
draft-ietf-dnsop-rfc4641bis-13

Yes

(Ron Bonica)

No Objection

(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Wesley Eddy)

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

Barry Leiba Former IESG member
Yes
Yes (2012-08-30 for -12) Unknown
Another vote for "A fine document."  And another vote for "Turn Appendix E into a retained summary of changes from 4641."
Ron Bonica Former IESG member
Yes
Yes (for -12) Unknown

                            
Sean Turner Former IESG member
Yes
Yes (2012-08-30 for -12) Unknown
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).
Stephen Farrell Former IESG member
Yes
Yes (2012-08-29 for -12) Unknown
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/
Adrian Farrel Former IESG member
No Objection
No Objection (2012-08-29 for -12) Unknown
I would also like a summary of changes from 4641 to be retained in the final document.
Brian Haberman Former IESG member
No Objection
No Objection (2012-08-28 for -12) Unknown
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.
Pete Resnick Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection (2012-08-30 for -12) Unknown
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.
Wesley Eddy Former IESG member
No Objection
No Objection (for -12) Unknown