Summary

  • Revision 00 of draft-ietf-intarea-legacy-registries proposes closing one registry, tightening another, giving two neglected registries a lightweight policy, and removing a registry that should not have existed. Those are four different governance moves, not one declaration that legacy technology is dead.
  • A registry receipt proves an assignment or administrative state. It does not prove implementation support, packet carriage, operator authorization or a successful service outcome. Retirement decisions fail when those evidence layers are collapsed.

A closed door with occupants still inside

The draft's cleanest example is the “NetWare/IP Option Type 63 Sub-Option Codes” registry. Revision 00 asks IANA to close it because NetWare is no longer being extended. Yet the same text says the information already recorded remains valid and existing registrations may still be updated under RFC 8126's closure guidance. The institution would stop admitting new values without rewriting the history or semantics of the values already admitted.

That distinction matters well beyond NetWare. A closed registry answers a narrow question: may a new code point enter this namespace through the ordinary process? It does not answer whether an old code point is implemented in a warehouse appliance, accepted by a parser, emitted by a compatibility shim, blocked by a network, or required by a customer contract. Those facts live in different systems and may persist on different clocks.

A careless retirement programme reads the registry label as an execution command. It removes decoding tables, suppresses telemetry, or treats every sighting as malformed. A disciplined programme first inventories the installed path. It identifies who still emits the value, which receivers accept it, whether translation occurs, how failures appear, and what evidence would prove that the last dependency is gone. Registry closure can start that investigation; it cannot substitute for it.

One draft, four kinds of institutional action

The other three proposals show why “legacy cleanup” is too blunt a category.

For IP Option Numbers, the draft proposes IESG Approval. This is deliberately a high allocation gate. It does not rehabilitate IPv4 options on the public Internet. The document says their use is broken and warns that designs depending on new options will probably be unreliable. An approved number would therefore prove that an allocation decision was made, not that routers, firewalls, fast paths and middleboxes will carry the option intact.

For Machine Names and Terminal Type Names, the draft proposes First Come First Served. The registries lack defined procedures and have seen no registrations in two decades. FCFS provides an orderly way to keep names unique without asking IANA to judge their architectural merit. It is an admission rule, not a quality mark. A syntactically accepted name can still be useless, unused or misunderstood.

For the IP Time to Live Parameter registry, the proposed action is removal—or, if removal is impractical, a note explaining that there is no TTL registry because the operating system or application freely selects the field. This is not the retirement of a particular TTL value. It is the correction of a category error. A recommended default of 64 can guide implementations while remaining different from a centrally assigned code point.

Put together, the four actions form a useful taxonomy. Closure says no new members. IESG Approval says new members require an explicit institutional decision. FCFS says coordination is needed but substantive review is not. Removal says the purported namespace was the wrong model for the field. None of these acts, by itself, changes running software.

The registry is a receipt, not the whole transaction

The history behind the proposal reinforces the point. RFC 1700 published Assigned Numbers as a static document. RFC 3232 moved the authoritative record to online IANA databases so the registry could evolve without repeatedly issuing a new RFC. That transfer improved the maintenance surface, but it did not move every form of technical truth into the database.

Protocol specifications still define wire semantics. Implementations decide what they parse and emit. Operators choose what they permit. Networks determine what traverses the path. Applications reveal whether a service still works. The current IANA page records administrative state at one layer. It cannot truthfully stand in for all the others.

This is the evidence chain a retirement owner should preserve:

  1. The document receipt identifies the exact revision and its standards-process state.
  2. The registry receipt shows the current policy, row and change controller.
  3. The implementation receipt shows what a named version emits, accepts, ignores or rejects.
  4. The path receipt shows what actually crosses the relevant network under defined conditions.
  5. The service receipt shows whether the intended user or machine outcome completed.

A missing fifth receipt cannot be repaired by presenting the first twice. Nor does a successful service transaction prove that the registry still accepts new assignments. Each claim needs evidence from the surface that owns it.

Revision 00 is a proposal, not the completed cleanup

The temporal boundary is as important as the technical one. The Datatracker describes the document as an active Internet Area Working Group draft in the I-D Exists state. The text is dated 11 September 2026 and expires 15 March 2027. It is not an RFC. It does not prove IESG approval, publication, or completed IANA action. The current registry pages remain the place to inspect current administrative state.

That uncertainty is productive. Reviewers can ask whether the proposed policy matches the actual ownership and use of each namespace. They can challenge whether closure, a stronger gate, FCFS or removal is the right instrument. What they should not do is treat the draft's diagnosis as a magic deactivation of deployed behavior.

Sources