Revised IANA Considerations for DNSSEC
draft-ietf-dnsop-dnssec-iana-cons-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-11-30
|
05 | (System) | Received changes through RFC Editor sync (created alias RFC 9157, changed abstract to 'This document changes the review requirements needed to get DNSSEC algorithms … Received changes through RFC Editor sync (created alias RFC 9157, changed abstract to 'This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-12-01, changed IESG state to RFC Published, created updates relation between draft-ietf-dnsop-dnssec-iana-cons and RFC 5155, created updates relation between draft-ietf-dnsop-dnssec-iana-cons and RFC 6014, created updates relation between draft-ietf-dnsop-dnssec-iana-cons and RFC 8624) |
2021-11-29
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-11-23
|
05 | (System) | RFC Editor state changed to AUTH48 |
2021-11-08
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-10-12
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-10-12
|
05 | (System) | RFC Editor state changed to EDIT |
2021-10-12
|
05 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-10-12
|
05 | (System) | Announcement was received by RFC Editor |
2021-10-12
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-10-12
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-10-12
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-10-12
|
05 | (System) | IANA Action state changed to In Progress |
2021-10-12
|
05 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2021-10-12
|
05 | Cindy Morgan | IESG has approved the document |
2021-10-12
|
05 | Cindy Morgan | Closed "Approve" ballot |
2021-10-12
|
05 | Cindy Morgan | Ballot approval text was generated |
2021-10-07
|
05 | Paul Hoffman | New version available: draft-ietf-dnsop-dnssec-iana-cons-05.txt |
2021-10-07
|
05 | (System) | New version accepted (logged-in submitter: Paul Hoffman) |
2021-10-07
|
05 | Paul Hoffman | Uploaded new revision |
2021-10-07
|
04 | (System) | Removed all action holders (IESG state changed) |
2021-10-07
|
04 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2021-10-07
|
04 | Martin Duke | [Ballot comment] Nit: Please expand DS and NSEC3 on first use. The original DISCUSS: Section 8 of RFC8126 says that bis documents should update the … [Ballot comment] Nit: Please expand DS and NSEC3 on first use. The original DISCUSS: Section 8 of RFC8126 says that bis documents should update the reference in IANA registries to replace obsolete documents with not-obsolete ones. It appears that 3658 didn't have a "bis" document but clearly was replaced by three others. I don't really understand how they fully obsolete 3658 if there are still registries hanging out there. Regardless, perhaps this draft is an opportunity to update the reference to these registries? Or is 3658 not "really" obsolete? At the telechat, the conclusion was that the document relationship is a little messy, but it probably wasn't worth fixing, and if it were to be fixed Warren would choose to do it a separate document. IANA had no objection to this course of action. |
2021-10-07
|
04 | Martin Duke | [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss |
2021-10-06
|
04 | Roman Danyliw | [Ballot comment] Thank you to Dan Harkins for the SECDIR review. |
2021-10-06
|
04 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-10-06
|
04 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-10-05
|
04 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-10-05
|
04 | Benjamin Kaduk | [Ballot comment] Thanks to Dan Harkins for the secdir review, and the authors for the corresponding updates. Section 1 DNSSEC is primarily described in … [Ballot comment] Thanks to Dan Harkins for the secdir review, and the authors for the corresponding updates. Section 1 DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. DNSSEC commonly uses two resource records beyond those defined in RFC 4034: DS [RFC3658] (which was obsoleted by RFC 4034) and NSEC3 [RFC5155]. I'm a bit confused at how DS is "beyond those defined in RFC 4034" when RFC 4034 includes discussion of DS, the record format, etc. Section 4 In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" registry, the registration procedure for "DNSSEC NSEC3 Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" are changed from "Standards Action" to "RFC Required". I note (this is a "comment", after all, right?) that the "flags" registries have only 7 values available. It is not entirely clear to me that the IESG would be justified in using an RFC 5742 conflict-review response to try to block any frivolous registration attempts made in non-IETF-stream RFCs, but maybe we are willing to place confidence in the other streams' managers behaving responsibly and otherwise accept this risk. NITS Section 2 only talks about "DS or NSEC3 hash algorithms" but the actual registry actions also cover the NSEC3{,PARAMS} flags registries. |
2021-10-05
|
04 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-10-05
|
04 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-10-04
|
04 | Tim Wicinski | This document now replaces draft-hoffman-dnssec-iana-cons instead of None |
2021-10-04
|
04 | Alvaro Retana | [Ballot comment] This document should be marked as replacing draft-hoffman-dnssec-iana-cons. |
2021-10-04
|
04 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-10-04
|
04 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-10-04
|
04 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-10-03
|
04 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. Technical Summary: This document changes the review requirements needed to get DNSSEC … (1) RFC is Standards Track, and this is the correct RFC type. Technical Summary: This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was a lot of debate and discussion when it was first introduced. There was a feeling that loosenign the requirements on adding new DNSSEC algorithms would lead to algorithsm not geting implemented, algorithms designed around nationalistic crypto, etc. This was resolved with some discussion. Document Quality: The IANA registries being updated in this document were previously updated. During that process, there were a few updates that were overlooked. This document attempts to bring all relevant registries in line. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is very solid. (10) There has been no appeals. (11) The following nits are raised, with our replies: == Missing Reference: 'DNSKEY-IANA' is mentioned on line 114, but not defined That's in a quotation from another RFC. I do not want to misquote that RFC to make idnits feel better. == Missing Reference: 'DS-IANA' is mentioned on line 114, but not defined That's in a quotation from another RFC. I do not want to misquote that RFC to make idnits feel better. -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) The reference is to the RFC that defined things that were in fact not obsolete: DS records. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This document will update RFCs 3658, 5155, 6014, 8624, and they are in the abstract and the introduction. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) There are no new IANA registries, only updates to the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" and the "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registries. (19) N/A (20) No Yang Necessary |
2021-10-02
|
04 | Murray Kucherawy | [Ballot comment] The Document Quality section of the shepherd writeup appears to be incomplete. In Security Considerations, it says: Security decisions about which … [Ballot comment] The Document Quality section of the shepherd writeup appears to be incomplete. In Security Considerations, it says: Security decisions about which algorithms are safe and not safe should be made by reading the security literature, not by looking in IANA registries. Should this document request addition of a note to this effect on the registry page itself? |
2021-10-02
|
04 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record |
2021-10-02
|
04 | Murray Kucherawy | [Ballot comment] The Document Quality section of the shepherd writeup appears to be incomplete. |
2021-10-02
|
04 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2021-10-01
|
04 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-09-30
|
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-09-28
|
04 | Martin Duke | [Ballot discuss] Holding this point because we should discuss it; this might be a problem to be solved by a different document, in which case … [Ballot discuss] Holding this point because we should discuss it; this might be a problem to be solved by a different document, in which case I'll lift it. Section 8 of RFC8126 says that bis documents should update the reference in IANA registries to replace obsolete documents with not-obsolete ones. It appears that 3658 didn't have a "bis" document but clearly was replaced by three others. I don't really understand how they fully obsolete 3658 if there are still registries hanging out there. Regardless, perhaps this draft is an opportunity to update the reference to these registries? Or is 3658 not "really" obsolete? |
2021-09-28
|
04 | Martin Duke | [Ballot comment] Nit: Please expand DS and NSEC3 on first use. |
2021-09-28
|
04 | Martin Duke | [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke |
2021-09-22
|
04 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-09-21
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-09-21
|
04 | Amy Vezza | Placed on agenda for telechat - 2021-10-07 |
2021-09-21
|
04 | Warren Kumari | Ballot has been issued |
2021-09-21
|
04 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2021-09-21
|
04 | Warren Kumari | Created "Approve" ballot |
2021-09-21
|
04 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2021-09-20
|
04 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list. |
2021-09-16
|
04 | Paul Hoffman | New version available: draft-ietf-dnsop-dnssec-iana-cons-04.txt |
2021-09-16
|
04 | (System) | New version accepted (logged-in submitter: Paul Hoffman) |
2021-09-16
|
04 | Paul Hoffman | Uploaded new revision |
2021-09-16
|
03 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-09-16
|
03 | Paul Hoffman | New version available: draft-ietf-dnsop-dnssec-iana-cons-03.txt |
2021-09-16
|
03 | (System) | New version accepted (logged-in submitter: Paul Hoffman) |
2021-09-16
|
03 | Paul Hoffman | Uploaded new revision |
2021-09-16
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins. Submission of review completed at an earlier date. |
2021-09-16
|
02 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-09-15
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins. |
2021-09-15
|
02 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-09-15
|
02 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-dnssec-iana-cons-02. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-dnssec-iana-cons-02. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, on the Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters registry page, located at: https://www.iana.org/assignments/dnssec-nsec3-parameters/ the registration procedure for all three registries: DNSSEC NSEC3 Flags DNSSEC NSEC3 Hash Algorithms, and DNSSEC NSEC3PARAM Flags will be changed from "Standards Action" to "RFC Required" based on the definition in RFC8126. Second, on the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms registry page located at: https://www.iana.org/assignments/ds-rr-types/ the registration procedure for the Digest Algorithms registry is changed from "Standards Action" to "RFC Required" based on the definition in RFC8126.. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-09-09
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2021-09-09
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2021-09-03
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2021-09-03
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2021-09-02
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-09-02
|
02 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-09-16): From: The IESG To: IETF-Announce CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dnssec-iana-cons@ietf.org, tjw.ietf@gmail.com, warren@kumari.net … The following Last Call announcement was sent out (ends 2021-09-16): From: The IESG To: IETF-Announce CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dnssec-iana-cons@ietf.org, tjw.ietf@gmail.com, warren@kumari.net Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Revised IANA Considerations for DNSSEC) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Revised IANA Considerations for DNSSEC' as Proposed Standard 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 last-call@ietf.org mailing lists by 2021-09-16. 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 changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ No IPR declarations have been submitted directly on this I-D. |
2021-09-02
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-09-02
|
02 | Amy Vezza | Last call announcement was generated |
2021-09-02
|
02 | Amy Vezza | Changed consensus to Yes from Unknown |
2021-09-02
|
02 | Amy Vezza | Intended Status changed to Proposed Standard from None |
2021-09-02
|
02 | Amy Vezza | Last call announcement was generated |
2021-09-02
|
02 | Warren Kumari | Last call was requested |
2021-09-02
|
02 | Warren Kumari | Last call announcement was generated |
2021-09-02
|
02 | Warren Kumari | Ballot approval text was generated |
2021-09-02
|
02 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
2021-09-02
|
02 | Warren Kumari | IESG state changed to Last Call Requested from Publication Requested |
2021-09-02
|
02 | Warren Kumari | Ballot writeup was changed |
2021-08-24
|
02 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. Technical Summary: This document changes the review requirements needed to get DNSSEC … (1) RFC is Standards Track, and this is the correct RFC type. Technical Summary: This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was a lot of debate and discussion when it was first introduced. There was a feeling that loosenign the requirements on adding new DNSSEC algorithms would lead to algorithsm not geting implemented, algorithms designed around nationalistic crypto, etc. This was resolved with some discussion. Document Quality: While these are updates to existing IANA considerations. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is very solid. (10) There has been no appeals. (11) The following nits are raised, with our replies: == Missing Reference: 'DNSKEY-IANA' is mentioned on line 114, but not defined That's in a quotation from another RFC. I do not want to misquote that RFC to make idnits feel better. == Missing Reference: 'DS-IANA' is mentioned on line 114, but not defined That's in a quotation from another RFC. I do not want to misquote that RFC to make idnits feel better. -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) The reference is to the RFC that defined things that were in fact not obsolete: DS records. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This document will update RFCs 3658, 5155, 6014, 8624, and they are in the abstract and the introduction. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) There are no new IANA registries, only updates to the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" and the "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registries. (19) N/A (20) No Yang Necessary |
2021-08-24
|
02 | Tim Wicinski | Responsible AD changed to Warren Kumari |
2021-08-24
|
02 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-08-24
|
02 | Tim Wicinski | IESG state changed to Publication Requested from I-D Exists |
2021-08-24
|
02 | Tim Wicinski | IESG process started in state Publication Requested |
2021-08-24
|
02 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. Technical Summary: This document changes the review requirements needed to get DNSSEC … (1) RFC is Standards Track, and this is the correct RFC type. Technical Summary: This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was a lot of debate and discussion when it was first introduced. There was a feeling that loosenign the requirements on adding new DNSSEC algorithms would lead to algorithsm not geting implemented, algorithms designed around nationalistic crypto, etc. This was resolved with some discussion. Document Quality: While these are updates to existing IANA considerations. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is very solid. (10) There has been no appeals. (11) The following nits are raised, with our replies: == Missing Reference: 'DNSKEY-IANA' is mentioned on line 114, but not defined That's in a quotation from another RFC. I do not want to misquote that RFC to make idnits feel better. == Missing Reference: 'DS-IANA' is mentioned on line 114, but not defined That's in a quotation from another RFC. I do not want to misquote that RFC to make idnits feel better. -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) The reference is to the RFC that defined things that were in fact not obsolete: DS records. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This document will update RFCs 3658, 5155, 6014, 8624, and they are in the abstract and the introduction. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) There are no new IANA registries, only updates to the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" and the "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registries. (19) N/A (20) No Yang Necessary |
2021-08-23
|
02 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-08-23
|
02 | Paul Hoffman | New version available: draft-ietf-dnsop-dnssec-iana-cons-02.txt |
2021-08-23
|
02 | (System) | New version accepted (logged-in submitter: Paul Hoffman) |
2021-08-23
|
02 | Paul Hoffman | Uploaded new revision |
2021-08-04
|
01 | Tim Wicinski | Notification list changed to tjw.ietf@gmail.com because the document shepherd was set |
2021-08-04
|
01 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
2021-08-04
|
01 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
2021-07-23
|
01 | Benno Overeinder | Added to session: IETF-111: dnsop Mon-1600 |
2021-07-21
|
01 | Cindy Morgan | New version available: draft-ietf-dnsop-dnssec-iana-cons-01.txt |
2021-07-21
|
01 | (System) | Secretariat manually posting. Approvals already received |
2021-07-21
|
01 | Cindy Morgan | Uploaded new revision |
2021-03-05
|
00 | Benno Overeinder | Added to session: IETF-110: dnsop Thu-1530 |
2021-01-22
|
00 | Paul Hoffman | New version available: draft-ietf-dnsop-dnssec-iana-cons-00.txt |
2021-01-22
|
00 | (System) | New version accepted (logged-in submitter: Paul Hoffman) |
2021-01-22
|
00 | Paul Hoffman | Uploaded new revision |