Skip to main content

Revised IANA Considerations for DNSSEC
draft-ietf-dnsop-dnssec-iana-cons-05

Yes

(Warren Kumari)

No Objection

Erik Kline
Éric Vyncke
(Francesca Palombini)
(John Scudder)
(Lars Eggert)
(Martin Vigoureux)
(Robert Wilton)
(Zaheduzzaman Sarker)

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

Erik Kline
No Objection
Roman Danyliw
No Objection
Comment (2021-10-06 for -04) Not sent
Thank you to Dan Harkins for the SECDIR review.
Éric Vyncke
No Objection
Warren Kumari Former IESG member
Yes
Yes (for -04) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2021-10-04 for -04) Sent
This document should be marked as replacing draft-hoffman-dnssec-iana-cons.
Benjamin Kaduk Former IESG member
No Objection
No Objection (2021-10-05 for -04) Sent
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.
Francesca Palombini Former IESG member
No Objection
No Objection (for -04) Not sent

                            
John Scudder Former IESG member
No Objection
No Objection (for -04) Sent

                            
Lars Eggert Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Martin Duke Former IESG member
(was Discuss) No Objection
No Objection (2021-10-07 for -04) Sent
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.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Murray Kucherawy Former IESG member
No Objection
No Objection (2021-10-02 for -04) Sent
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?
Robert Wilton Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection (for -04) Not sent