DNSSEC Key Rollover Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-06

[Ballot comment]
Please move Appendix A into section 1.3 as it would be better to have all terms, symbols, and variables used in the draft defined in the terminology section.  Russ Housley noticed this and I agree with him in that it would be good to fix.

In 1.4 should this include key sizes as well since they are not discussed?  I see the explanation in section 5 and am just wondering if the procedures are the same when key properties change as opposed to expiration and revocation, which are both mentioned in the draft.

The SecDir review found a few nits you should probably fix as well:
https://www.ietf.org/mail-archive/web/secdir/current/msg05318.html

IESG writeup for key-timing

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The RFC is being requested as Informational. This is indicated in the
(title page, and the RFC discusses various methods of changing or 'rolling
(over') the DNSSEC keys of a domain, and various effects they have.

(2) Technical Summary:  This document describes the issues surrounding the
(timing of events  when updating or 'rolling') the key in a DNSSEC-secured
(zone.  It presents  timelines for the key rollover and explicitly identifies
(the  relationships between the various parameters affecting the process.

Working Group Summary: This document was originally presented in 2012, and had
been accepted and was in WGLC when it stalled, primarily due to a secondary
document updating some of the steps in this document. The WG had no direction
and it remained stalled until it was re-started, and the two documents were
merged, and editorial flair was applied.

Document Quality:  The document went through a very editorial process and we
feel it is of strong quality.

Personnel:  The Document Shepherd is Tim Wicinski and the Area Director is
Joel Jaggeli.

(3) The Document Shepherd participated in regular conference calls with the
(authors where editorial issues was addressed. Since the details of this draft
(involves some mathematical formulas, there was a fear of not being completely
(correct, so several independent efforts were made to verify the steps.

anBriefly describe the review of this document that was performed by the
Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

(4) The Document Shepherd has no concerns about the depth and breath of
(reviews.  There were many detailed reviews of the document from several
(sources, both in technical details, but also editorial concerns on
(readability, etc.

(5) This document, or any portion of this document need review from broader
(perspective.

(6) The Document Shepherd has no concerns with this document.  There was a
(very strong editorial process involved before reaching last call and many
(issues around readability were addressed.

(7) Each author has confirmed that there are no IPR disclosures needing to be
(filed.

(8) There are no IPR disclosures references or filed with this document.

(9) The WG is very solid in consensus behind this document.  There was broad
(consensus to publish the document and its findings, as they are relevant to
(the operations community at large.

(10) No one has threatened an appeal or indicated any discontent.

(11) There are no known nits that were found, either automated or manual
(checks.

(12) This document does not need any formal review from specific type reviews.


(13) Have all references within this document been identified as either
normative or informative?

(14) There are no normative references to documents that are not ready for
(advancement.

(15) There are no  downward normative references references in this document.

(16) Publication of this document will not change the status of any existing
(RFCs.


(17)  This document includes no requests of IANA, and no consideration is
(needed.

(18)  No IANA registries will require Expert Review for this document.

(19) No automated checks were performed to validate the document, as there was
(no formal language used in the document.  There were a few simple formulas
(which were vetted by several different people.

IESG writeup for key-timing

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The RFC is being requested as Informational. This is indicated in the title page, and the RFC discusses various methods of changing (or 'rolling over') the DNSSEC keys of a domain, and various effects they have.

(2) Technical Summary:  This document describes the issues surrounding the timing of events  when updating (or 'rolling') the key in a DNSSEC-secured zone.  It presents  timelines for the key rollover and explicitly identifies the  relationships between the various parameters affecting the process.

Working Group Summary: This document was originally presented in 2012, and had been accepted and was in WGLC when it stalled, primarily due to a secondary document updating some of the steps in this document. The WG had no direction and it remained stalled until it was re-started, and the two documents were merged, and editorial flair was applied.

Document Quality:  The document went through a very editorial process and we feel it is of strong quality.

Personnel:  The Document Shepherd is Tim Wicinski and the Area Director is Joel Jaggeli.

(3) The Document Shepherd participated in regular conference calls with the authors where editorial issues was addressed. Since the details of this draft involves some mathematical formulas, there was a fear of not being completely correct, so several independent efforts were made to verify the steps.

anBriefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) The Document Shepherd has no concerns about the depth and breath of reviews.  There were many detailed reviews of the document from several sources, both in technical details, but also editorial concerns on readability, etc.

(5) This document, or any portion of this document need review from broader perspective.

(6) The Document Shepherd has no concerns with this document.  There was a very strong editorial process involved before reaching last call and many issues around readability were addressed.

(7) Each author has confirmed that there are no IPR disclosures needing to be filed.

(8) There are no IPR disclosures references or filed with this document.

(9) The WG is very solid in consensus behind this document.  There was broad consensus to publish the document and its findings, as they are relevant to the operations community at large.

(10) No one has threatened an appeal or indicated any discontent.

(11) There are no known nits that were found, either automated or manual checks.

(12) This document does not need any formal review from specific type reviews.


(13) Have all references within this document been identified as
either normative or informative?

(14) There are no normative references to documents that are not ready for advancement.

(15) There are no  downward normative references references in this document.

(16) Publication of this document will not change the status of any existing RFCs.


(17)  This document includes no requests of IANA, and no consideration is needed.

(18)  No IANA registries will require Expert Review for this document.

(19) No automated checks were performed to validate the document, as there was no formal language used in the document.  There were a few simple formulas which were vetted by several different people.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-dnssec-key-timing-06, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNSSEC Key Rollover Timing Considerations) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNSSEC Key Rollover Timing Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the issues surrounding the timing of events
  in the rolling of a key in a DNSSEC-secured zone.  It presents
  timelines for the key rollover and explicitly identifies the
  relationships between the various parameters affecting the process.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ballot/


No IPR declarations have been submitted directly on this I-D.

IESG writeup for key-timing

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The RFC is being requested as Informational. This is indicated in the title page, and the RFC discusses various methods of changing (or 'rolling over') the DNSSEC keys of a domain, and various effects they have.

(2) Technical Summary:  This document describes the issues surrounding the timing of events  when updating (or 'rolling') the key in a DNSSEC-secured zone.  It presents  timelines for the key rollover and explicitly identifies the  relationships between the various parameters affecting the process.

Working Group Summary: This document was originally presented in 2012, and had been accepted and was in WGLC when it stalled, primarily due to a secondary document updating some of the steps in this document. The WG had no direction and it remained stalled until it was re-started, and the two documents were merged, and editorial flair was applied.

Document Quality:  The document went through a very editorial process and we feel it is of strong quality.

Personnel:  The Document Shepherd is Tim Wicinski and the Area Director is Joel Jaggeli.

(3) The Document Shepherd participated in regular conference calls with the authors where editorial issues was addressed. Since the details of this draft involves some mathematical formulas, there was a fear of not being completely correct, so several independent efforts were made to verify the steps.

anBriefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) The Document Shepherd has no concerns about the depth and breath of reviews.  There were many detailed reviews of the document from several sources, both in technical details, but also editorial concerns on readability, etc.

(5) This document, or any portion of this document need review from broader perspective.

(6) The Document Shepherd has no concerns with this document.  There was a very strong editorial process involved before reaching last call and many issues around readability were addressed.

(7) Each author has confirmed that there are no IPR disclosures needing to be filed.

(8) There are no IPR disclosures references or filed with this document.

(9) The WG is very solid in consensus behind this document.  There was broad consensus to publish the document and its findings, as they are relevant to the operations community at large.

(10) No one has threatened an appeal or indicated any discontent.

(11) There are no known nits that were found, either automated or manual checks.

(12) This document does not need any formal review from specific type reviews.


(13) Have all references within this document been identified as
either normative or informative?

(14) There are no normative references to documents that are not ready for advancement.

(15) There are no  downward normative references references in this document.

(16) Publication of this document will not change the status of any existing RFCs.


(17)  This document includes no requests of IANA, and no consideration is needed.

(18)  No IANA registries will require Expert Review for this document.

(19) No automated checks were performed to validate the document, as there was no formal language used in the document.  There were a few simple formulas which were vetted by several different people.