On 12/11/2024 7:56 AM, Eliot Lear 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. I reiterate: a draft can be stable where a specification
is not. We make that distinction of whether a specification is stable
through our publication process.
For what it's worth, I have far less of a problem with IANA
assignments to drafts than I do with drafts not being considered
working documents. And again, the hint is in the name: draft.
Eliot
Hi Eliot -
I want to make a few statements that I believe are true. I'd like to
see how close I get to what the community believes.
1) An internet draft is a versioned document. E.g. it's the collection
of the versions of the document, not a single version. (e.g. more like a
linear version of a GIT repo than anything else)
2) When we discuss an ID (e.g. draft-stjohns-example) we're generally
talking about the continuum of versions and mostly the latest version of
the document in the continuum (e.g. draft-stjohns-example-23) . As a
new version is provided (note I avoid "published" here), we generally
change our focus to that version.
3) A specific version of an ID may have a stable reference, but an ID
does not (due to the fact that the versioning is not a closed
continuum). (Note here - I do not believe we've written it into the IT
requirements that the URL for an ID needs to be stable over a 10 year+
period).
4) 1-3 are not well understood by the greater community. (this is more
an opinion than fact)
5) AFAICT - IANA tagging an ID with a version number in the registry
(under the "Specification Required" policy) is still liable to confusion
as its possible that there may be a later document in the ID system.
The version tagging is a "hack" as there is no specific policy that the
registry assignment is tied to a specific ID version. It may be
"understood" that this is the case, but see (4) above.
6) AFAICT - There is no prohibition on continuing to provide later
versions of an ID used for Specification Required nor on changing the
meaning of the protocol assignment within that later version. Ideally,
there is text in the ID that notes the previous registry assignment, but
there is no specific policy that requires this. (Note here - this might
lead to the strange state of affairs where an ID references a previous
version of itself - where the registry entry was created - at some point)
__________
My proposal would be:
1) ID's can still be used for early assignments, but will be tagged as
such in the IANA registry. The assignment will follow the most recent
version of the ID and the registry entry will be very clear about this
ephemerality. The assignment will carry over into an RFC if published,
or will be marked as obsolete if the ID series is abandoned for a year.
2) The text of an ID, or for that matter any text sufficiently clear and
in any stable form may be used as a Specification for permanent registry
assignment. If you're using the ID XML, it's straightforward to use the
tools to produce a non-ID based on the ID text. The idea is to accept
pretty much any material for a specification - and just treat the ID
format as one possible processing system. The IANA would store this in
its own system and make it available via the IANA websites distinct and
separate from the IETF system (as it's already doing for IDs). Later
IDs either based on the same text or a new ID series could reference the
IANA document without fear of confusion or change.
3) The IANA would provide some boilerplate that would need to be
required in the proffered document (e.g. at least enough rights to
provide copies to the public of the document) and the list of acceptable
doc formats (text, word xml etc) they would accept and the IANA would
maintain that copy as the sole Stable Reference for the registry
assignment. Depending on the specific registry, the IANA MAY accept an
updated specification from the original or successor author/organization
and replace the reference with a new stable reference after the same
level of Expert Review. In any event, this would eliminate the
possibility for floating references due to ID versioning and
misunderstandings.
4) IDs as we know them now remain limited cite - works in progress.
Later, Mike
_______________________________________________
rfc-interest mailing list -- rfc-interest@rfc-editor.org
To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
