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

[Eliot Lear <[e-mail]>]

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.  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.  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.

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
>
>
>