While I am sure we will differ on the details, the approach you describe
sounds like one I can work with.
Thank you,
Joel
On 12/11/2024 8:38 PM, Eric Rescorla wrote:
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 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
