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