RFC 4020

Early IANA Allocation of Standards Track Code Points 🦋

Okay bestie, this is RFC 4020 from the Network Working Group 🎀 It's a Best Current Practice (that's BCP 100), dated February 2005. The authors are K. Kompella (Juniper Networks) and A. Zinin (Alcatel). Its header doesn't list any RFCs it obsoletes or updates, so there's no drama there 💅

Status of This Memo 📜

This doc is a Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited.

Copyright Notice ©

Copyright (C) The Internet Society (2005).

Abstract ✨

This memo is about allocating code points early, through IANA, as a fix for the mess the "Standards Action" IANA policy creates. That mess shows up for protocols where implementation and deployment experience is desired or required prior to publication 🌸

1. Introduction 💖

In Standards Track RFCs there's often a need to allocate code points for objects, messages, or other protocol entities so implementations can interoperate 🧚 Lots of these code point spaces have registries run by the Internet Assigned Number Authority (IANA). Several IANA allocation policies are described in RFC 2434 [2434]. Some of them, like First Come First Served or Expert Review, don't need a formal IETF action before IANA does the allocation. But when code points are scarce and/or the IETF community wants tight control over the protocol, policies like IESG Approval, IETF Consensus, or Standards Action get used. The Standards Action policy becomes a problem when implementation and/or deployment experience is desired or required for the Standards Action 😭

To break the deadlock, "pre-RFC" implementations have sometimes just picked some "seemingly unused" code points 💀 Those might turn out to be different from the ones IANA later assigns. To make things worse, these "pre-RFC" implementations often end up deployed. That creates a few interop problems between early implementations and implementations of the final standard:

1. IANA allocates code points different from those that early implementations assumed would be allocated. Early implementations won't interoperate with standard ones.
2. IANA allocates code points used silently for other extensions. Different extensions will collide.

This gets in the way of the main purpose of standards, which is to facilitate interoperable implementations 🙈

It's easy to say pre-RFC implementations should be kept private and should not be deployed 🙄 But the length of the standards process and the immense value of early implementations and early deployments say we should find a better solution. Take documents produced by Working Groups in the Routing Area: a pre-RFC implementation is highly desirable and sometimes even required, and early deployments give useful feedback on the technical and operational quality of the specification 🔥

This memo proposes that, under strictly controlled circumstances, IANA make an early allocation of code points. It lays out the conditions for early allocation and the process to follow. It also explains how these allocations get dealt with if the process fails along the way, like if the RFC never gets published 🍓

This memo only covers early allocation of code points from spaces whose allocation policy is "Standards Action" [2434] AND that have been amended to permit early allocation. That permission MUST be granted by the IESG, and code spaces with permission for early allocation MUST be marked as such in the IANA registry 👑

2. Conditions for Early Allocation 🌈

The following conditions MUST hold before anyone can request early allocation of code points:

• a) The code points MUST be from a space designated as "Standards Action", amended by IESG approval to permit Early Allocation.
• b) The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") MUST be adequately described in an Internet draft that is proposed as Standards Track.
• c) The specifications of these code points MUST be stable; i.e., if there is a change, implementations based on the earlier and later specifications MUST be seamlessly interoperable.
• d) There is sufficient interest in early (pre-RFC) implementation and deployment in the community ✨

If conditions (a) or (b) aren't met, then the processes in this memo don't apply 🚫

3. Process for Early Allocation 🧁

There are three processes tied to early allocation: making the request for code points, following up on the request, and revoking an early allocation. I can't stress this enough: these processes MUST have a minimal impact on IANA itself, or they won't be feasible 😤

The processes below assume the document is the product of an IETF Working Group. If it isn't, swap "WG chairs" below for "shepherding Area Director" 🫶

3.1. Request 📝

Here's how requesting and getting early allocation of code points goes:

1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points need early allocation and which document they should be assigned to.
2. The WG chairs determine whether the conditions for early allocations described in section 2 are met; particularly, conditions (c) and (d).
3. The WG chairs gauge whether there is consensus within the WG that early allocation is appropriate for the given document.
4. If it is, with the approval of the Area Director(s), the WG chairs request IANA to make an early allocation.
5. IANA makes an allocation from the appropriate registry, marking it as "temporary", valid for a period of one year from the date of allocation. The date of allocation SHOULD also be recorded in the registry and made visible to the public 🦋

Note that Internet Drafts SHOULD NOT include a specific value of a code point until IANA has formally allocated that value 🙌

3.2. Follow-Up 🔍

It's the job of the document authors and the Working Group chairs to review changes in the document, especially in the specifications of the code points that got an early allocation request, and make sure those changes are backward compatible 🧐

If at some point changes that aren't backward compatible are still required, someone needs to decide whether previously allocated code points MUST be deprecated (see section 3.3 for more information on code point deprecation). The considerations include things like whether older implementations are already deployed, and therefore whether older and newer implementations could collide in the field 😬

If the document gets to the point where IANA normally makes code point allocations, it's on the authors and the WG chairs to remind IANA that there were early allocations, and of the code point values allocated, in the IANA Considerations section of the RFC-to-be. After that, allocation is just a matter of removing the "temporary" tag from the allocation description ✨

3.3. Expiry ⏳

If early allocations expire before the document gets to the point where IANA normally makes allocations, the authors and WG chairs MAY follow an abbreviated version of the process in section 3.1 to request renewal of the code points. At most, one renewal request MAY be made, so authors SHOULD choose carefully when they make the original request 🧠

As an exception to that rule, under rare circumstances more than one allocation renewal MAY be justified. All such renewal requests MUST be reviewed by the IESG. The renewal request to the IESG MUST include the reasons the renewal is necessary, and the WG's plans regarding the specification 🎀

If a follow-up request isn't made, or the document fails to progress to a Standards Track RFC, the WG chairs are responsible for telling IANA that the code points are to be marked "deprecated" (and are not to be allocated). The WG chairs are also responsible for telling IANA when the deprecated code points can be completely de-allocated (i.e., made available for new allocations) 💅

In particular, it is not IANA's responsibility to track the status of allocations, their expiration, or when they MAY be re-allocated 🫠

Note that if a document is submitted for review to the IESG and some early allocations are still valid (not expired) at the time of submission, those allocations SHOULD NOT be expired while the document is under IESG consideration or waiting in the RFC Editor's queue after IESG approval 🌸

Part 1 wraps here, bestie 🫶 Part 2 picks up with Section 4 (IANA Considerations) and goes through the rest of the doc, including Security Considerations, the references, and the copyright statement 🧚

Intellectual Property

okay so the IETF is being super clear here 💅 it takes no position on whether any Intellectual Property Rights (or other rights) that someone claims over the tech in this doc are valid or in scope 🧐 It also doesn't say whether a license to those rights is or isn't available, and it hasn't done any independent digging to find out if such rights exist 🙈 If you want the IETF's rules on rights in IETF Documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances that licenses will be provided. The same goes for the results of any attempt to get a general license or permission for implementers or users to use proprietary rights. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️✨

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them 📣 Send that info to the IETF at ietf-ipr@ietf.org 💌 it's giving transparency, bestie 🫶

---

Acknowledgement

the RFC Editor function is funded by the Internet Society 🌈 so a big thank you to them for keeping the lights on 💖🧚