Carsten, I think we moistly agree.
Where we disagree seems to be in the reading of RFC 8126. If we want to
give the Expert latitude to decide if the registry entry is allowed
based on an I-D, we use the "Expert Review" branch. If we want to
require a specification, we use the "Specification Required" branch. If
we want to require both, then we specify both. But as written, Expert
Review IANA registries do not require a document.,
Is all we are arguing about allowing an informational reference to I-Ds
in Expert Review registries? (The earlier email I saw seemed to be
about "Specification Required" registries.
Yours,
joel
On 12/10/2024 4:23 PM, Carsten Bormann wrote:
On 10. Dec 2024, at 22:02, Joel Halpern <j...@joelhalpern.com> wrote:
4) Related to 3, citing an I-D for an IANA registry that requires a stable
specification seems very odd.
I agree with your first three points, but this one is off.
The I-D by definition is guaranteed stable and accessible, so that is not the
problem.
Whether it actually fulfills the requirements of Section 4.6 of RFC 8126 is for
the designated expert to decide. The RFC that created the registry can give
instructions to the DE, including about whether an I-D or a GitHub page or any
other page on the Web is acceptable or the specification requires some blessing
beyond that (good luck with defining that precisely, but the designated experts
can make a decision).
Do we intend the code point to mean any version of the document (even though
they probably differ?
No!
The code point is tied to the stable document (which happens to be an I-D here).
Of course, there should be a way to update a reference, and I would expect the
designated expert to have a look when such an update is desired whether the
requirements of Section 4.6 of RFC 8126 are violated by it.
Do we intend the code point to mean the behavior in this version of the
document, even though the IETF may later decide that the right behavior is
something else?
Yes!
(More precisely:
Get a new code point if you need to indicate the new behavior to prevent false
interoperability.
Deprecate the old code point if that is actively harmful.
Don’t get a new code point if old behavior and new behavior can interoperate.)
There is a change controller for each registration, and that (together with the
designated expert) can manage such kinds of evolution in such a way that there
is an acceptable outcome.
If we claimed to want a stable specification so implementations using the code
point interoperate (as distinct from an FCFS registry where the point is just
to make sure folks don't collide) then we need to actually be stable.
Yes, modulo bug fixing (see above).
(If we discover that while we thought we wanted interoperable code points all
we really want is non-conflicting code points then fix the rules for the
specific registry.)
Well, that can be complicated [1].
But you put this point into parentheses, so I think you agree that this isn’t a
required part of the solution.
The nice thing is that we already have all the above in place and working; we
actually don’t need to change anything.
(The likely outcome of any protracted change process is that we have wasted a
lot of time and made the actual result in terms of the resulting behavior of
the people involved worse. See Eliot’s concerns above.)
Grüße, Carsten
[1]: https://www.ietf.org/archive/id/draft-fossati-core-cf-reg-update-03.html
_______________________________________________
rfc-interest mailing list -- rfc-interest@rfc-editor.org
To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
