Skip to main content

Revised IANA Considerations for DNSSEC
RFC 9157

Yes

Warren Kumari

No Objection

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

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

Warren Kumari Yes

Alvaro Retana No Objection

Comment (2021-10-04 for -04)
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

Comment (2021-10-07 for -04)
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

Comment (2021-10-02 for -04)
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

Comment (2021-10-06 for -04)
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

No Objection (2021-10-05 for -04)
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

No Objection (for -04)