[saag] Re: [rfc-i] Re: Re: RFCs vs Standards

[Joel Halpern <[e-mail]>]

I think there are a couple of aspects in EKR's note.   It seems likely 
that there can be WGs with approaches and clarity enough to know when a 
code point is sufficiently well-defined by the then-current I-D.  But 
that is by no means universal.  There also may be protocols that are 
sufficiently insensitive to expected drift that it is effective.

This is actually formally recognized in much of the routing work with 
two different techniques.  On the one hand, we normally define 
experimental code points to enable folks to perform experiments among 
consenting adults with no registration. Conversely, when we have IETF 
I-Ds that are close enough to done that the definition is actually 
stable, we have provision for early allocation when supported by the WG 
chairs.

A blanket rule allowing "specification required" based on I-Ds seems 
likely to mislead and confirm implementors outside of the IETF process.

Yours,

Joel

On 12/11/2024 9:04 AM, Eric Rescorla wrote:
>
>
> On Wed, Dec 11, 2024 at 4:56 AM Eliot Lear <[e-mail]> wrote:
>
>     Eric,
>
>     On 11.12.2024 13:26, Eric Rescorla wrote:
>>
>>     On Tue, Dec 10, 2024 at 12:47 PM Eliot Lear <[e-mail]> wrote:
>>
>>         And this is where we run into problems, because the moment
>>         you change that boiler plate, you will devalue the RFC series
>>         and create support and interoperability problems as people
>>         end up implementing different versions of a specification.
>>         And to be clear, IANA is the LEAST of our problems. The IETF
>>         needs a way to have not-ready-for-prime-time DRAFT work
>>         without fear ofcreating a mess.
>>
>>     I think this assumes facts not in evidence.
>
>     If you are asking for evidence that we have trained the industry
>     to believe that drafts are temporary, you should work in or near a
>     commercial organization who answers RFPs.  I've seen my share, and
>     they rarely include internet-drafts.  If you are asking for
>     evidence that this sort of training would break down, that would
>     be asking for evidence of an event that has not yet occurred
>     because the boiler plate has largely stated the draft nature of
>     drafts from the beginning.
>
> Indeed. So we are just left with our respective opinions.
>
>     I reiterate: a draft can be stable where a specification is not.
>
> You can reiterate it, but it's only true for a specific meaning of 
> "draft". Draft *versions* are in fact stable, which is why we have 
> been able to do Internet scale deployments based on them.
>
> -Ekr
>
>
> _______________________________________________
> rfc-interest mailing list [e-mail]
> To unsubscribe send an email [e-mail]