[saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt

[Eric Rescorla <[e-mail]>]

On Fri, Nov 29, 2024 at 12:54 PM Randy Bush <[e-mail]> wrote:

> < rant >
>
> >> A draft may be stable.  The spec in the draft is not.  Authors
> >> may choose to update that spec at any time.  Therefore, if
> >> implementers are looking for spec stability, drafts are the wrong
> >
> > As long as the code points are references by versioned drafts,
> > this is not an issue. We are looking at the few cases where this
> > was done using an unversioned draft and working with IANA to
> > resolve those.
>
> it is not about control, our delicate egos, blah blah blah
>
> standards are for the *users* so that we have vendor/implementation
> choice.  the screw from vendor A must fit the nut from vendor B.
> this would seem to require long lived immutable documents.  to
> create them is why we go through the review process from hell.  as
> eliot points out, internet-drafts do not make that bar, period.
> neither does github.
>

I fear that this rant (your words, not mine) manages to elide a lot of
context.

To recap, the situation is that many IETF protocols allow the use of
multiple
algorithms, which are indicated by code points drawn from a given namespace
[0].
The IETF defines and standardizes some algorithms and registers them in
the namespace. Those specifications of course go through the IETF review
process that you are referring to, with the associated interoperability
benefits
(at least ideally).

However, it is also frequently the case that vendors wish to register their
own algorithms and get an associated code point even if there is little or
no
interest in the IETF in standardizing those algorithms. There are a number
of possible responses to that type of request, including but not limited to:

1. No, you can't register
2. You can register, but only meeting a certain minimum bar, either in terms
    of technical quality (this seems OK) or document quality (this seems
    to be documented sufficiently to allow interoperability), or both. This
might
    be something like a light WG review or more likely Expert Review.
3. You can register without meeting any quality bar at all (e.g., FCFS).

In my opinion, the IETF has three primary interests here:

1. Ensuring that there are not conflicting usages of a single code point.
2. Efficiently using IETF resources to promote IETF work.
3. Ensuring quality and interoperability even for proprietary protocol
extensions.

However, these points are in tension: ensuring quality of proprietary
extensions
requires that the IETF spend time reviewing documents even when there
is no real interest in standardization, as well as withholding code point
assignments
from vendors while we review the documents. This costs IETF resources and
also runs the risk that vendors will just use code points without
registering
them ("squatting"). Moreover, in my experience vendors are often quite
resistant
to changing their specifications in response to this kind of review (again,
we're
talking about cases where we're not standardizing), so now everyone is
spending
a lot of time on a mechanism which won't really change, even if it's not
very good.

For this reason, some WGs (TLS, QUIC, etc.) have decided to instead
make it very easy to register code points with only limited review, thus
minimizing the use of IETF resources at the cost of providing no real
guarantees for non-standardized mechanisms. The question then becomes
what the minimum documentation ought to be for these code point
registrations.

I actually think a reasonable case could be "none", on the theory that
we're
not trying to ensure quality at all for these mechanisms, but so far what
these WGs have settled on is that some document must exist, but that
the Experts do not really need to review it for completeness. What we're
discussing
here is to a great extent whether that largely unreviewed document needs to
be an RFC or not. Obviously, YMMV, but I think in that case the arguments
you are offering for why said document needs to be permanent and immutable
(leaving aside that I don't really agree with your characterization of the
properties
of I-Ds and GitHub) are quite a bit weaker

-Ekr

[0] This is a specific case of a more general class of extensibility
mechanisms.