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