Skip to main content

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