Summary

  • An IETF proposal in Last Call would allow IANA to create an entire protocol-parameter registry before the document establishing it has been approved for publication as an RFC. The registry would be visibly temporary for two years, subject to renewal, closure or finalization.
  • Creation and expiry dates are necessary but not sufficient. A public state-transition ledger should connect the registry to the exact draft, consensus and approval route, the provisional admission procedure used for each entry, every policy change, and the effect of renewal, closure or finalization.

A protocol value can leave its birthplace quickly. It moves from an IANA page into source code, test vectors, equipment images, configuration guides and packet captures. The copy usually keeps the number and loses the footnote.

That familiar problem becomes more demanding when the provisional object is not one value but the registry itself. On 27 August, the IESG opened Last Call on Early IANA Registry Creation. Comments are due by 10 September. The document is an active Internet-Draft intended for the Standards Track; it is not an approved standard.

The proposal answers a real coordination problem. A working group may define a new namespace in one draft while other drafts, or even another standards organization, already need values from it. Keeping an unofficial spreadsheet or private list risks two sources of truth. Waiting for the founding RFC can delay useful implementation work. The draft therefore offers a third route: after a defined IETF approval chain, IANA could create the registry early and operate it in public.

That is a larger act than assigning a temporary value from an existing table. It creates the table, installs an interim rule for entry, and starts a clock before the document that normally supplies the durable authority has completed review.

The proposal creates a whole provisional institution

The current version 02 gives authors, working-group chairs, Area Directors and IANA distinct jobs. Authors ask the chairs for early creation. The chairs decide whether the stated conditions are met and gauge whether the working group has consensus that early creation is appropriate. The Area Director then applies judgment, especially where there is a risk that the registry never becomes permanent. Only after that approval do the chairs ask IANA to act.

IANA would place the registry in its proper location, mark it temporary, and publish its creation and expiry dates. The initial term is two years. If the clock is running out, IANA asks the chairs and Area Director whether they want another two-year period. Renewals after the first extension also need IESG approval, reasons and a plan for the specification. If an extension is not approved, IANA closes the registry and labels it accordingly. Chairs may request closure earlier. A registry that is still valid when its founding draft enters IESG consideration does not expire during that review.

Those are meaningful controls. They prevent a provisional registry from arriving without a visible status or living indefinitely through inertia alone. They also create several distinct transitions: requested, approved, created, renewed, paused for IESG review, closed or finalized. A date field tells the public where one clock points. It does not necessarily reveal which decision moved the object into its current state.

The registry clock and the entry clock can disagree

The most important complication appears in the proposed admission rules. The permanent registration policy named in the founding draft would not yet apply. Until finalization, IANA would use a temporary procedure chosen according to that projected policy.

If the future registry is expected to use First Come First Served or Expert Review, an entry would require working-group chair approval during the provisional period. The draft says such approved entries do not require renewal. If the creating document is sponsored directly by an Area Director, the sponsoring AD fills that role.

If the future rule will require an RFC, such as IETF Review or Standards Action, an entry must follow the companion early-allocation proposal. Those entries remain temporary even after the registry itself becomes permanent, until their own documents are approved. “Specification Required” branches again according to whether Internet-Drafts will qualify as permanent specifications.

The result is not one temporary flag. A temporary registry may contain a chair-approved entry that does not renew, an early allocation with its own time limit, and an initial entry supplied by the founding draft. Later, the registry can become permanent while one of its rows remains temporary. The enclosure and the contents have related but non-identical state machines.

That distinction also separates this proposal from RFC 7120. The existing BCP addresses early allocation from a registry that already exists. The new draft would authorize creation of the registry before its founding document is approved. It is a change in the object being made operational, not merely a longer list of eligible values.

Draft evolution can change the rule at the gate

The proposal anticipates that the projected permanent policy may change while the founding document is still being written. A move from Expert Review to IETF Review, for example, would imply a different provisional admission route. IANA must be notified. The draft is equally clear that IANA will not track changes to documents that create early registries.

That boundary is sensible. IANA is the registry operator, not a shadow editor monitoring every draft revision. Authors and chairs remain responsible for reviewing changes to content and structure and telling IANA what must change. But the boundary creates an evidence dependency: a public table can look current even when the draft, projected policy and temporary procedure have moved on different dates.

A durable record should therefore bind the notification to an exact version of the document and show when the new rule took effect. Otherwise a later reader may know that entry 17 exists but not whether it was admitted under chair approval, early allocation, expert review or a rule that was only expected to apply after finalization.

The missing object is a transition ledger

The draft already requires visible creation and expiration dates. The useful next step is not a longer disclaimer. It is a compact state-transition ledger for the registry and for each entry.

At registry level, the record should identify the registry, the founding draft and exact revision, a content digest, the working-group consensus record, chair and AD approvals, request date, creation date, current expiry, projected permanent policy and provisional procedure. Each structural or policy change should name the version that caused it, the notifier, the effective time and the entries affected. Renewal, an IESG-review pause, an IANA suspension request, closure and finalization should appear as attributable events rather than overwritten fields.

At entry level, the record should preserve the value, meaning, reference, change controller, approval route, policy version and temporal state. Where an entry depends on its own draft, that dependency belongs in the row. When the enclosing registry closes or becomes permanent, the row should record what changed and what did not.

This need not publish private correspondence. A date, actor role, decision reference, document hash and outcome are enough to prove the institutional transition while keeping operational and personal material out of the public surface.

What the IANA row still does not prove

Early publication would improve coordination; it would not accelerate every other form of authority. A chair-approved entry is not final IETF approval of the technology. A Last Call is not an IESG decision. An IANA record is not product certification or a command to deploy. Closure of the registry is not evidence, on the current text, that every contained value was deleted or made immediately reusable.

The proposal itself remains open to change. No evidence reviewed for this article shows an early registry already created under it, a deployment that relied on one, or an abuse of the proposed route. The point of a transition ledger is preventive: make provisional authority travel with the values before operational copying turns a temporary institutional decision into an apparently permanent technical fact.

Sources