On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Jun 19, 2020, at 9:26 AM, Eric Rescorla <e...@rtfm.com> wrote: > > What's your reasoning for why there needs to be community review before > there is a code point assigned? > > Historically, the quality of algorithm descriptions in early drafts has > been variable. What the author considers sufficient and obvious, another > might not. Also, review gives folks a chance to say things like "your test > vectors appear wrong", "having test vectors would be really useful", and so > on. > > > Would that still apply if the space were larger? > > Yes. Leveraging the fact that the IETF community is in fact a community > seems worth the effort to have the references in registries be useful to a > new developer a decade in the future. > OK. In that case you and I disagree. My reasoning is that (as above) these algorithms are generally of low interest and that requiring community review for code point registration has the result of consuming quite scarce resources in the service of making the algorithms which are being registered marginally clearer. This opinion is based on my extensive experience in reviewing code point assignments for TLS (largely for things like exporters) where one was presented with a long specification which was embedded in the context of some other protocol and then one had to make sense of it and determine whether it was implementable. And because you were actually holding up other people's work based on that review, there was pressure to complete it. This kind of experience is why we changed to the current system. More generally, it seems like there are two primary purposes for code point registration here: 1. To promote interoperability of the code points 2. To avoid code point collisions My perspective here is that while interoperability is good, the primary value here is to avoid collisions. People who wish to have interoperability will still have the IETF process available to them, but given the large number of uses of our protocols, I do not believe that it is productive to make it harder for people to extend them in order to require interoperability for those who do not believe they need it (or at least do not believe they need the IETF enforcing it). -Ekr
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
