--On Sunday, November 26, 2023 09:08 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:
I'm not clear that there's any gap in our rules. The situation
seems clear for IETF documents (if the IESG approves a
document, that amounts to an IETF request to IANA). Since
RFC2860 is the text of an agreement "on behalf of the Internet
Engineering Task Force and the Internet Research Task Force"
there is presumably no problem for the IRTF either. It's also
a clear no for the Independent stream because it's not part of
either the IETF or the IRTF. If an Independent stream RFC
wants to create a registry, the IETF (or IRTF) would need to
approve the request. RFC8726 rather cleverly (perhaps
unintentionally) finesses this because in the rare case where
this might arise, it says "The IESG will be invited to provide
its opinions about the advisability of the creation of any new
registries during its conflict review of the document."
Brian,
I'm not sure. I'm also not sure, even after a few days of
discussion, just what Tom is concerned about. Especially if we
are basing answers on RFC 2860, can we step back a bit?
As a specific example derived from your comment above, RFC 2860
could not mention the Independent Stream because there was no
such creature before RFC 4844ff. That is different from, e.g.,
the IRTF, which was created more or less contemporaneously with
the IETF and is explicitly covered by Section 5 of 2860. Also
remember that, prior to 4844, what we now call the Independent
Stream included a collection of documents that were submitted
directly to the RFC Editor rather than going through the IETF
process. That collection included IAB documents, IANA statements
about how things were being done (including the Assigned Numbers
collection), and assorted other things. In that regard, the
first sentence of Section 4.1 of RFC 2860, particularly "...only
as directed by the criteria and procedures specified in RFCs,
including ... documents, and any other RFC that calls for IANA
assignment." is instructive, noting the "any other RFC" part.
And then it goes on to provide for parameter registration (but
maybe not creation of new registries, see below) based on
historical precedent.
So, at least prior to RFC 8726, if the Independent Stream
decided to publish an RFC specifying protocol parameter
registrations, that specification would be in "any other RFC".
In that regard, the language that you describe as rather clever
appears to me to be nothing more than a specific application to
IANA registries of the general principle laid out in RFC 4846:
the ISE is required to ask the IESG for advice but is not
required to take it. In that regard, while 8726 says, for
example, that the Independent Stream will "in general" not
request creation of new registries (and imposes additional
requirements on the exceptions), 8726 itself is simply an
Independent Stream statement of Independent Stream policies at
the time it was published. At least in principle, the
Independent Stream could generate a new document tomorrow that
would specify a completely different set of rules including
registry creation. They would need to ask the IESG for comment
but, AFAICT, as long as 2860 and 4846 apply, they could ignore
any negative advice, publish the 8726bis document as an RFC, and
that would be it. (The language in 2860 about disputes between
the IETF/IESG and IANA being settled by the IAB would not apply
because the ISE isn't any of those parties.)
I don't expect that to happen because, AFAICT, every ISE we have
had has been a mature adult, guided by a desire to make
decisions that are consistent with the best interests of the
community and, perhaps coincidentally in Postel's tradition, to
avoid getting drawn into controversies that would be harmful
regardless of outcome. I expect that tradition will continue
and, btw, I think the general principles laid out in 8726 are
reasonable. But, if we are going to treat RFC 2860 as the final
authority, then the rule is "RFC publication" and, if we
(presumably the RSWG/RSAB these days) ever decided to create a
stream for an entity with no IETF/IAB affiliation or
obligations, the definition of that stream had best be very
careful, probably requiring an update to the MOU.
FWIW, I note that the MOU also fails to draw a distinction that
is clearly laid out in 8726 and elsewhere, and that is the
distinction between defining/ creating a registry and the rules
for allocating new values (parameters) in existing registries
and being the authority for determining which values can be
added.
That difference brings me to another difference between the
situation in the first half of 2000 when RFC 2860 was discussed
and adopted and the present. Prior to Jon Postel's passing and
the establishment of ICANN, IANA had significant technical
knowledge available to it and was expected to apply that
knowledge and considerable discretion to the organization of
registries and its record-keeping in general. There are, for
example, no generally available public documents about the
transitions between registries in paper in a notebook, having
some (and then others) online (first as publication of contents
of those notebooks in the "Assigned Numbers" RFCs), availability
by FTP, and then migrating to the web, much less requests for
permission. IETF requests for registration were just that --
requests-- and most often specified principles not detailed
instructions, and never specific values. That has changed --
somewhat by a process of evolution and, at least IMO, quite
dramatically after the PTI changeover-- to the point that,
today, IANA seems to expect very explicit instructions about
exactly what should be done, instructions that go well beyond
what I believe was anticipated when 2860 was written (you and
Fred know more about that then I do) and certainly beyond what
would have been considered acceptable a few years earlier. And,
in that process, a review and approval process has been
implemented for some actions that probably violate provisions of
RFC 2860.
Personally, I think we are better off with the flexibility of
"Do the Right Thing" over getting ourselves more and more
tangled in increasingly specific rules and procedures. But, if
we need such procedures, let's not pretend they are there when
they aren't.
best,
john
