As required by RFC 4858, this is the current template for the Document
Changes are expected over time. This version is dated 24 February 2012.
This is the Shepherd write up for draft-ietf-dnsop-rfc5011-security-considerations
(1) The document is being presented as a Proposed Standard, though it also
claims to be updated RFC7583, which is published as informational; and based on
the path the document took to reach consensus, it could easily be addressed
This document extends the RFC5011 DNSSEC Key Rollover Strategy with
additional timing advice that must be followed by the publisher in to
Working Group Summary:
The Working Group had a very *rough* consenus on this draft. The document is
designed to update the timing requirements of RFC5011 in performing key
rollover. There were several reviews which the authors were able to resolve.
However, the largest issue was with the author of RFC5011 who felt the math in
this document was too complicated and did not add enough to RFC5011 to make it
Despite this, the rest of the working group achieved consensus on this document.
The chairs and this shpeherd felt it should be moved along, with these caveats
spelled out explicitly.
The document describes the timing requirements around updating the DNSSEC
keys of the root. This document has gone through several thorough reviews
by several members of the root server community, and they were OK with the
Document Shepherd is Tim Wicinski and Area Director is currently Warren
Kumari, but he is also one of the authors.
(3) The document shepherd did several thorough reviews of this
document, both for content as well as editing issues. The shepherd feels it is
ready for publication, with the rough consensus caveat.
4) The document shepherd is more than satisfied with the depth and
breath of the reviews.
(5) It is the opinion of the document shepherd that this document does
not need broader reviews.
(6) The document shepherd has no specific concerns or issues with this
(7) The authors have confirmed that there are no IPR disclosures that
need to be filed.
(8) No IPR disclosures have been filed for this document.
(9) The working group was able to come to consesus. The one outlier was the
author of RFC5011, which this document is designed to be ab operational
companion document. It is hard to accurately express the authors feelings, so
I will include a few links to help guide the IESG.
It is the opinion of the document shepherd that given the conflicts in gathering
consensus, the Intended status should be Informational rather than Standards
(10) No one has threatened an appeal.
(11) The Major nits here are 1) stating this document - which is listed as
Standards Track - updating an Informational RFC. Also RFC 7583 and RFC7719 are
listed as normative.
(12) Document does not meet any required formal review criteria.
(13) All references have been identified as either normative or
(14) There are not normative references that are holding up this
(15) There are two downward normative references; RFC7583 (which tihs document
discusses updating); and RFC7719 (which is current DNS Terminology document)
(16) This document wished to update RFC7583, though it is not marked in the
(17) The IANA considerations section requests an update to the Resource
Record (RR) Types Registry to reference this document for one value.
This is consistent with the body of the document.
(18) There are no new IANA registries.