Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-dnssec-iana-cons-04: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 05 Oct 2021 12:16:06 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-dnssec-iana-cons-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Oct 2021 17:16:39 +0000

Thank you; no one else noticed this. I've replaced it with:
DNSSEC is primarily described in {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}.
DNSSEC commonly uses another resource record beyond those defined in RFC 4034:
NSEC3 {{RFC5155}}.
DS resrouce records were originally defined in {{RFC3658}}, and that definition
was obsoleted by RFC 4034.

> the other streams' managers behaving responsibly and otherwise accept

I think so, yes.

> registry actions also cover the NSEC3{,PARAMS} flags registries.

Good catch. I'll update that sentence to talk about all the registries.

--Paul Hoffman