RFC 8726

RFC 8726: How Requests for IANA Action Will Be Handled on the Independent Stream 💖🎀

Okay, bestie, this one is written by A. Farrel, the Independent Submissions Editor (ISE) 🧚. It's an Informational doc, dated November 2020, with ISSN 2070-1721, and it's an Independent Submission. It doesn't obsolete or update any RFCs (the title block lists neither), but it does complement RFC 4846 ✨.

---

Abstract ✨

So the Internet Assigned Numbers Authority (IANA) keeps registries to track code points used by protocols like the ones the IETF defines in its RFCs 🦋. The Independent Submission Stream is another way documents can become RFCs, and the ISE looks after it 👑.

This doc adds to RFC 4846 by explaining how the ISE currently handles Independent Stream documents that ask IANA for actions 💅. Nothing here changes existing IANA registries or their allocation policies, and it doesn't change any previously documented processes 🌸.

Status of This Memo 🧾

This doc is not an Internet Standards Track specification. It's published for informational purposes 🍓.

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the details 🔥.

For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8726 🌈.

Copyright Notice 🌈

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🫶.

Table of Contents 📚

1.  Introduction
2.  Allocations from Existing Registries
3.  Changing Policies of Existing Registries
4.  Creating New IANA Registries
5.  Assigning Designated Experts
6.  Transfer of Control
7.  IANA Considerations
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Author's Address

1. Introduction ✨

Okay, so IANA keeps registries to track code points for protocols like the IETF ones and the RFCs developed on the IETF Stream 🦋. You can find the full list of registries and code points at https://www.iana.org/protocols 💖.

People can ask IANA to create registries or to allocate code points from existing ones. The procedures for both are in [RFC8126] 🎀.

A lot of requests for IANA action show up in documents heading toward publication as RFCs. Those RFCs can come from the IETF Stream, but they can also come from other streams, including the Independent Submission Stream (the Independent Stream), as described in [RFC4846]. The Independent Stream is looked after by the Independent Submissions Editor (ISE) 👑.

This doc complements [RFC4846] by describing how the ISE currently handles Independent Stream documents that ask IANA for actions. Nothing here changes existing IANA registries or their allocation policies, and it doesn't change any previously documented processes 🌸.

If something comes up that this doc doesn't cover exactly, the ISE may talk it through with the people involved. That includes IANA, the IESG, the stream managers for other streams, and the authors of an Independent Submission that asks IANA for action 🫶.

2. Allocations from Existing Registries 🍓

Every IANA registry has an allocation policy. That's the set of rules IANA follows to decide which code points can be allocated and under what circumstances 💅. These policies are described in [RFC8126].

Documents coming from the Independent Stream will always follow the assignment policies of the registries they ask allocations from. Likewise, every code point assignment is subject to oversight by any designated expert (DE) appointed for that registry 🧚.

Here's the tea: documents on the Independent Stream can never turn into Standards Track RFCs, and they're never subject to IETF review 💀. So a registry whose policy is "IETF Review" or "Standards Action" [RFC8126] is not available to Independent Stream documents 🙈.

3. Changing Policies of Existing Registries 🌷

Every so often, somebody decides to change a registry's allocation policy. Those changes are normally made only through the allocation policy of the registry itself, and they usually need documentation from the same stream that created the registry 🦋.

Independent Stream RFCs won't try to change the allocation policies of any registries, except the ones created by Independent Stream documents. That list is very limited, though. See Section 4 ✨.

4. Creating New IANA Registries 🎀

Sometimes a new protocol, or an extension to an existing one, needs registries to track its new code points 💖.

Generally, Independent Stream documents can't ask for a brand-new IANA registry 🙅‍♀️.

There's one exception. If a document going to the Independent Submission Stream asks for a code point from an existing registry whose allocation policy is Specification Required, Expert Review, RFC Required, or First Come First Served, then it may also need to create a registry tied to that specific code point. That new registry is used to interpret a sub-code 🧚.

For example, think about the "Uniform Resource Identifier (URI) Schemes" registry [URL-URIschemes]. Every so often, a URI scheme needs a registry of its associated parameters. The tel URI scheme, for instance, has a registry of parameters called the "tel URI Parameters" [URL-telURI] 📞.

These cases are rare, and they only exist to support the allocation from the base registry. When the existing base registry has an appointed DE, the code point can be assigned from the base registry and the new registry can be created only if the DE approves both actions 👑.

The new registry has a few more constraints too 📋:

• The allocation policy for the new registry may only be First Come First Served, RFC Required, Experimental, or Private Use. Basically, no registry can be created if it would need IETF action to get a future code point allocation. See Section 5 for why Specification Required and Expert Review aren't acceptable policies for any registry created from an Independent Stream document 🙈.
• If the allocation policy for the new registry is First Come First Served, the document must include a short statement and explanation of the expected arrival rate of new registrations over time 🌈.
• The new registry must include a clear statement of the escalation process for any issues that come up with it. Here's a model for that statement:

This registry was created by [RFCXXXX], which was published on the
Independent Submission Stream.  Any issues that arise with the
management of this registry will be resolved by IANA in
consultation with the Independent Submissions Editor.

• The IESG will be invited to share its opinions on whether any new registries are a good idea, during its conflict review of the document [RFC5742]. The ISE will give those opinions full consideration 🫶.

Authors of Independent Submission Stream documents should think about the best place to host these registries. That means looking at where the expertise to manage and review registry assignments actually lives. In some cases, registries may end up hosted by organizations other than IANA 🌸.

---

Author's Address 🎀

okay bestie, last stop! 🫶 the person who wrote this whole thing is Adrian Farrel 💅

Adrian is an Independent Submissions Editor 🌸

if you wanna reach out, the email is rfc-ise@rfc-editor.org 💌

and that's a wrap on RFC 8726!! 🦋✨