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

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?

Thank you to Dan Harkins for the SECDIR review.

This document should be marked as replacing draft-hoffman-dnssec-iana-cons.

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.

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.