Summary

  • RFC 7120 lets qualifying IETF work obtain a public code point before the RFC that would normally authorize allocation. The value is marked Temporary, dated and ordinarily valid for one year.
  • The row coordinates running code; it does not certify consensus, endorse the design or promise permanence. Draft authors, working-group chairs, Area Directors, IANA and implementers hold different parts of the decision.
  • Expiry is a state transition, not an eraser. An expired value can remain visible, become deprecated and only later return to the free pool after deployed-use risk is considered.

A number was needed before the document was done

Protocol specifications regularly assign small integers to messages, flags, extensions or behaviours. Those numbers look trivial until two programs attach different meanings to the same one. A registry prevents that ambiguity by giving every recognized use a unique place in a shared namespace.

Publication, however, arrives late in the engineering sequence. Implementers often need to test whether a draft can be built, whether two independent implementations interoperate and whether an operational network exposes assumptions the text missed. If the final code point is unavailable, teams may select the next apparently empty value and write it into software.

RFC 7120 describes the two failures that follow. IANA may later assign the draft a different value, leaving early and final implementations unable to understand one another. Worse, the guessed value may be assigned to another extension while the pre-standard implementation remains deployed. One octet then carries two legitimate-looking but incompatible instructions.

Michelle Cotton’s document does not resolve that problem by pretending drafts are standards. It creates a registry state that exists before final approval and says exactly how provisional it is.

“Do not implement yet” was not a complete policy

It would be administratively tidy to insist that no one ship code before RFC publication. RFC 7120 rejects that as insufficient. Standards work can take years, and implementation experience is often the evidence that shows whether a design deserves to advance. In routing work, the IETF has specifically moved away from an old rule set while preserving the value of multiple implementations and operational experience.

The choice is therefore not between perfect order and reckless deployment. It is between coordinated experimentation and experimentation that will happen with guessed identifiers. Early allocation gives the former a public address without converting it into a final verdict.

That distinction matters because a number is unusually sticky. Prose can change between draft revisions. A code point compiled into equipment, configuration templates, packet dissectors and test fixtures creates a compatibility constituency. The registry can label the value temporary; it cannot remotely remove it from products.

Four conditions before the clock starts

RFC 7120 does not open every registry to every unfinished idea. Its general process applies to IETF Stream work in spaces governed by Specification Required when the specification is intended for an RFC, RFC Required, IETF Review or Standards Action. More permissive registries already have other routes.

The draft must describe the format, semantics, processing and related rules adequately. The specification must also be stable: a later change should leave implementations based on the earlier and later text seamlessly interoperable. Working-group chairs and Area Directors must see enough community interest in pre-RFC implementation or enough risk of contention if no value is held.

These are not claims that the protocol is correct. They answer a narrower commissioning question: is the draft mature enough that reserving one scarce identifier is less dangerous than letting implementers invent one?

The requirement for stability is especially revealing. Early allocation is meant to protect interoperability, not merely to help an author replace TBD with an integer. If the wire meaning is still fluid, a public number may accelerate the very incompatibility the process is designed to prevent.

The path deliberately has several hands

Authors first ask the working-group chairs, identifying the requested values and the draft. The chairs test the conditions, especially stability and implementation need, and gauge working-group consensus. They then seek Area Director approval. An Area Director can apply judgment, including concern about depleting a small registry. Only after that approval do the chairs ask IANA to act.

IANA’s act is precise. It assigns from the appropriate registry, marks the entry Temporary, and publishes both the first-allocation date and the expiry date. The normal lifetime is one year. The draft should not write in a specific value before this step is complete, because before registration nothing prevents another request from receiving it.

No participant in that chain performs all roles. Authors do not reserve the number by typing it. Working-group consensus does not execute the registry change. Area Director approval is not final standards approval. IANA records the authorized temporary state but does not endorse the protocol. Implementers decide whether and where to run it.

Michelle Cotton is relevant precisely because RFC 7120 describes this seam from the registry side without granting the registry a fictional power to judge the entire design. Her authorship turns administrative timing into a protocol-safety mechanism: status, dates and responsibility are part of interoperability.

What Temporary proves—and what it cannot

A temporary row proves that the request passed the early-allocation route and that other requesters can see the value is occupied for the stated period. It provides a common target for implementations and a public warning against collision.

It does not prove that the Internet-Draft will become an RFC. It does not show that the IESG has approved the technical design, that a security review is complete, that products interoperate or that any deployment exists. The number is a coordination receipt, not a quality seal.

This is visible in a current registry. On 8 September 2026, the IANA DNSKEY RR Flags table showed flag 14, Authoritative Delegation Types, as temporary. The row recorded 20 July 2026 as registration, 20 July 2027 as expiry and an active DNSOP draft as its reference. Those fields establish the reservation and its clock. They do not predict the draft’s outcome or measure support in authoritative servers, validators or tooling.

The example also shows why public dates matter. A copied integer without its status can travel through slides, source code and vendor documents as if it were permanent. The registry row preserves the condition that makes the integer safe to interpret.

Promotion, expiry and de-allocation are different events

If the document reaches the stage where IANA would normally allocate the value, authors and chairs must remind IANA of the early assignment. The transition to permanence can then be recorded by removing the temporary tag. The number stays the same; its authority changes.

If the year runs out first, the process allows one ordinary renewal by repeating the request. Further renewals are rare and go to the IESG with reasons and a plan. A calendar extension is therefore new governance evidence, not an automatic subscription.

Without renewal or RFC progress, the expired entry remains visible. Chairs can tell IANA that it is no longer required and should be marked deprecated. Deprecated does not mean freely reusable: the value is neither allocated for documented use nor available for another allocation. Later de-allocation may return it to the pool, but possible implementations and the amount of remaining space must inform that choice.

This sequence resists two forms of historical loss. Immediate deletion would conceal the meaning that may still be compiled into software. Immediate reuse would place a new interpretation on the same wire value. An honest registry sometimes needs a state that says, in effect, “not valid for new work, but not safe to forget.”

The modest authority of a registry entry

RFC 7120 anticipates abuse. A working group or company might seek an early value to create momentum around work unlikely to survive IETF review. Large numbers of provisional requests could consume scarce code space or overload IANA. Area Director consent, escalation to the IESG and IANA’s ability to ask for suspension are controls against turning the exception into a private fast lane.

Those safeguards reveal the design’s underlying restraint. Running code deserves room to produce evidence, but it does not get to pre-empt the standards process merely by running. The registry gives an experiment a collision-free coordinate and an expiry date. Everything else—technical merit, consensus, deployment judgment and eventual permanence—still needs its own receipt.

That is the durable contribution associated with Cotton’s RFC. It does not choose between documents and implementation. It makes them meet under a label that tells the truth about time.

Sources