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