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

[Eric Rescorla <[e-mail]>]

On Thu, Nov 28, 2024 at 10:44 PM Eliot Lear <[e-mail]> wrote:

> Hi Eric,
>
> You missed my point.  You are thinking about this from the interior point
> of view of the IETF.  For any given work, we here are likely to have a
> pretty good feel for whether it is likely to continue to change.  From
> outside, nobody knows.
>
> You also have part of the argument reversed.  Currently, this behavior
> (using drafts for code points) *isn't* the norm and so there is no issue.
>
Norms vary. As I said, this has been the norm for the main protocols on the
Web for quite some time.

But again, you're conflating the two cases I was careful to distinguish in
the message you are responding to.

Proponents should show evidence that changing the norm won't cause harm to
> the general market.  And we *have* trained the market to pay attention to
> RFCs rather than drafts.  How do I know this?  I routinely get requests for
> drafts to be published because a certain customer base is looking for the
> RFC imprimatur.
>
But this is in fact the problem: the value of the RFC imprimateur is from
IETF review, not from some notional sense of immutability or that it went
through the RPC. And when we are just documenting some vendors work, that's
not what is happening.

I argue that's a *very* good thing for everyone because it means that
> developers here in the IETF get to worry far less about long term
> interoperability impact as we do our work.
>
And here you're talking about interim deployment again.

-Ekr


This is not to say that early allocation of code points isn't necessary,
> but really that should be for our INTERNAL use, not for general market
> availability.
>
> By the way, it may interest you to know how other SDOs avoid these
> interoperability problems: they often don't make drafts available to the
> general public.
>
> Eliot
> On 29.11.2024 01:09, Eric Rescorla wrote:
>
>
> On Thu, Nov 28, 2024 at 3:59 PM Eliot Lear <[e-mail]> wrote:
>
>> Greetings Paul!
>> On 29.11.2024 00:00, Paul Wouters wrote:
>>
>>
>> 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.
>>
>> But it is also an issue if you are an implementer and not a protocol spec
>> developer, and you are trying to economically and securely manage your
>> coding and COGS investments.  An RFC or similar vehicle is signal that
>> This->spec will not change without going through a rather involved public
>> development process. It gets particularly concerning when different RFPs
>> have different specific draft version requirements.  That's really where
>> either interoperability begins to break down and/or code complexity goes
>> up, even if different code points are used for different versions.
>>
> Maybe.
>
> There are a number of different cases here.
>
> On one extreme, we have a specification which is being actively developed
> by the IETF, and goes through a number of draft revisions before finally
> being published as an RFC. In that case, yes, it is somewhat difficult to
> have code points associated with drafts prior to the RFC (though TBH, not
> that difficult, and we do this in TLS and QUIC fairly routinely).
>
> On the other extreme, we have a specification which simply documents some
> externally developed technology which will not be modified by the IETF but
> just needs a codepoint registration. In this case, there is generally no
> real issue with multiple versions and I do not believe that having a
> reference to a draft version, because there is no real need to revise it.
> Note that this is distinct from submissions to the Independent stream,
> which naturally go through multiple draft revisions prior to becoming an
> RFC, which might lead to confusion. However, if the code point is just
> assigned on the basis of an I-D with no intention to make an RFC, that is
> not the case. Do you have evidence that there has been significant
> confusion in such cases?
>
> -Ekr
>
>
>
>