Joel,
Thanks for your note. I agree that there is a lot of variation in the
demands of protocols and we should be trying to support the needs of
different communities within the IETF (I think that's what you are saying,
at least!).
Re a blanket rule: I think it would be bad to retroactively change the IANA
considerations of existing protocols, so if that's what a blanket rule is,
I am not in favor of it. My read of 8126 is that it provides policy
templates that WGs are free to adopt, so I think what would be helpful here
would be:
(1) An IETF-wide agreement that some policy which requires a document but
could include a draft is reasonable (as noted, we already do this in some
cases, but I know some people object)
(2) A new template policy ("Document Required") in some 8126-bis that
provides a template for that policy. And then WGs could adopt that or not.
Alternately I guess we can muddle along as we have.
-Ekr
On Wed, Dec 11, 2024 at 7:00 AM Joel Halpern <j...@joelhalpern.com> wrote:
> 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 <l...@lear.ch> wrote:
>
>> Eric,
>> On 11.12.2024 13:26, Eric Rescorla wrote:
>>
>>
>> On Tue, Dec 10, 2024 at 12:47 PM Eliot Lear <l...@lear.ch> 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 -- rfc-interest@rfc-editor.org
> To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
>
>
_______________________________________________
rfc-interest mailing list -- rfc-interest@rfc-editor.org
To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
