Revised IANA Considerations for DNSSEC
RFC 9157
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Warren Kumari Yes
Alvaro Retana No Objection
This document should be marked as replacing draft-hoffman-dnssec-iana-cons.
Erik Kline No Objection
Francesca Palombini No Objection
John Scudder No Objection
Lars Eggert No Objection
Martin Duke (was Discuss) No Objection
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.
Murray Kucherawy No Objection
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 No Objection
Roman Danyliw No Objection
Thank you to Dan Harkins for the SECDIR review.
Zaheduzzaman Sarker No Objection
Éric Vyncke No Objection
(Benjamin Kaduk; former steering group member) No Objection
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.
(Martin Vigoureux; former steering group member) No Objection