Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla <[e-mail]>]

On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman <[e-mail]>
wrote:

> On Jun 19, 2020, at 9:26 AM, Eric Rescorla <[e-mail]> 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