On Wed, Jan 29, 2025 at 1:52 PM, Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Jan 29, 2025, at 10:23, Tim Wicinski <tjw.i...@gmail.com> wrote: > > During the DNSOP chairs call, myself, Suzanne, Benno, AD Warren and Author > Warren discussed this requirement. After much discussion, we came to two > points we agree on: > > - We DO want to make it easy for people to create and experiment with new > DNSSEC algorithm ideas, including code points. > > - We DO NOT want to make it easy for people to use those code points to > force implementers to support these same DNSSEC algorithm ideas. > > I'm hoping that "we" in those two sentences are "we the WG", not "we the > WG chairs". > Yup. I had understood Tim's usage of "we" to mean "the WG and the chairs" (and, probably, everyone else, because it seems self-evident). But even in that case, it does not match the outcome of the WG discussion > on this point. No one felt that any code point listed as "MAY" could be > used to "force implementers to support" the algorithm; the entire point of > MAY in that column is to differentiate from RECOMMENDED and MUST. > > We feel these points align with the feedback of the working group (I am > always happy to be proven wrong). > > I have looked at the thread again, and I still believe you are wrong. > There was a lot of support for allowing easier access to get initial code > points as long as they had to later ask the IETF for upgrading. > Apologies for the delay - some of us were traveling. The chairs had a chance to discuss this at DNS-OARC and reviewed the threads, etc. Tim asked[*] us to post a new version of the document "allowing easier access to get initial code points", so we posted a new version saying: Adding a new entry to the "DNS System Algorithm Numbers" registry with a recommended value of MAY in the "Use for DNSSSEC Signing", "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", or"Implement for DNSSSEC Validation" columns is via the "Specification Required" policy as defined in [RFC8126]. New entries will have the value of MAY for all columns. " As a reminder for the WG, "Specification Required" is described in https://datatracker.ietf.org/doc/html/rfc8126#section-4.6 . The summary is: "values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. This policy is the same as Expert Review, with the additional requirement of a formal public specification. [...] The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path, including informal documentation." If the WG feels that this is still too onerous, it's easy to s/Specification Required/Expert Review/. My view is that Specification Required is the right policy — people can play / experiment with "Private Use" (see below), and then publish some "findable and retrievable" documentation once they are ready for a more public test. If / once there is broader support, we can then publish an RFC…. But, that's just like, my opinion…. > Also, the thread had nothing to do with "experimenting": there are already > code points for private use. > This is only true in the DNS Security Algorithm Numbers[1], but not the DS RRType Registry[2], which has no code points for private use. As we are making it easier to get code points on the DS RRType registry, there is a (tiny) chance that we could run into issues with scarcity, and so we are proposing: 1: New entries at the MAY level with just a spec. 2: Request that IANA Reserve codepoints 128 - 252 in the DS RRType Registry[2] (this makes it similar to the DNS Security Algorithm Numbers registry[1], which has codepoints 123 - 251 reserved). and 3: Request that the IANA mark codepoints 253 and 254 in the DS RRType Registry as reserved for private use (this matches the DNS Security Algorithm Numbers registry). This way people who just want to do a private experiment can, and once they feel like they have some confidence in their proposal, they can request a codepoint (at the MAY level ). If there is a massive flood of these (incredibly unlikely, but still), we will bump into the Reserved range, and can figure out then what to do. We also fixed a few nits, addressed some IANA comments (e.g "please include a pointer to that section in the IANA Considerations".), and also updated our table to address GOST R 34.11-2012 & SM3, which were added to the Algorithms Registry in RFC9558 & RFC9563 (i.e after Wes and I had written our initial tables), updated the Acknowledgements section, etc. The diffs is here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-rfc8624-bis-04&url2=draft-ietf-dnsop-rfc8624-bis-05&difftype=--html Hopefully this is acceptable to everyone, W [1]: DNS Security Algorithm Numbers registry - https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml [2]: DS RRType Registry: https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml [*]: He just sent a short mail to the list now (he's currently on a plane traveling back from Atlanta), and will send a longer one with more detail later. I wanted to get this update and mail posted tonight because I'm supposed to be flying back from Atlanta tomorrow, but these is a snow / ice storm headed to the East coast and so I'm not sure where I'll be / what connectivity I'll have for the next few days…
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
