Summary

  • The Datatracker recorded WG -00 approved for draft-ietf-intarea-legacy-registries-00 on 11 September 2026. That makes it an INTAREA working-group document, not an RFC or a completed IANA instruction.
  • The draft requests different actions for five live registry surfaces: close one, set IESG Approval on one, set First Come First Served on two, and remove or rewrite the note for one.
  • The live IANA pages still show their earlier state. A registry-action receipt should preserve the exact verb, decision stage, before-and-after snapshot and archival result instead of labelling every step “cleanup.”

A new owner, not a change order

The current Datatracker record identifies “Updates to Legacy IANA Registries” as an active INTAREA document. Its history dates the working-group -00 to 11 September and records two distinct facts: the chairs approved the WG revision, and that revision replaced the individual draft series.

Those facts matter. Adoption gives a working group responsibility for developing the text. It moves the proposal from an individual author's draft into the group's queue. It does not mean the IETF has approved a Proposed Standard, and it does not turn future-tense requests in an IANA Considerations section into completed registry operations.

The history of the individual series makes the boundary unusually visible. On 27 August, the chairs recorded consensus to adopt. They also recorded an objection, said it had been heard and discussed, and stated that the document concerns registry-maintenance procedure rather than a position on IPv4's future. Adoption can therefore be a decision to work on a document even when a policy argument inside it remains contested.

The handoff did not smuggle in a substantive rewrite. A comparison of individual revision 03 with WG revision 00 shows the same requested actions. The visible changes are a grammatical correction in Security Considerations and an added reviewer acknowledgement. The new filename is process evidence, not evidence that IANA has acted.

“Cleanup” contains four different verbs

The draft groups several old registry problems into one short document, but it does not prescribe one uniform treatment.

For the NetWare/IP Option Type 63 Sub-Option Codes registry, the request is closure. The draft says NetWare is no longer being extended. Closure would stop new registrations while preserving existing values. That preservation is not a courtesy added by the author: RFC 8126 says a closed registry accepts no further registrations, but its information remains valid and existing registrations may still be updated.

For IP Option Numbers, the request is a policy assignment: IESG Approval. The document says public-Internet use of IPv4 options is unreliable and suggests more robust alternatives, yet it deliberately does not close the registry. RFC 8126 describes IESG Approval as an exceptional route, seldom used and not intended as the common case. A new assignment need not be documented in an RFC, although the IESG may request supporting material and may consult the community.

For Machine Names and Terminal Type Names, the request goes the other way. Both would receive First Come First Served. RFC 8126 summarizes that policy as no review and minimal documentation. The draft acknowledges the risk of nonsensical entries and relies on IANA's ordinary filtering. The two lists have not received registrations for decades, but defining a low-friction intake rule is still different from closing them.

For the IP Time to Live Parameter registry, the preferred request is removal. The draft argues that a node or application can freely select the IPv4 TTL and that the registry should never have been created. If complete removal is not possible, it supplies replacement note text instead. Removal, note replacement and closure are three different archival outcomes. A summary that says “five obsolete registries will be closed” would be wrong.

The live pages are the execution surface

At this research cutoff, the DHCP and BOOTP parameters page still lists the NetWare sub-option registry with its registration procedure as Not defined. The values remain visible.

The IPv4 parameters page still shows Not defined for IP Option Numbers. It also still contains the IP Time to Live Parameter registry and its recommendation that the default TTL is 64. The four RFC 3692-style experimental IPv4 option values remain separately identified; the draft's move to IESG Approval has not appeared as a live policy field.

The Machine Names registry still says Not defined. The Terminal Type Names registry still says Not defined?, including the question mark. Neither page yet displays First Come First Served.

That is not evidence of delay or failure. It is the expected difference between document development and registry execution. RFC 8126 says IANA normally acts when a document is approved for publication. The current draft remains a working document. The INTAREA document list should be read for process state; the IANA pages should be read for registry state. One cannot substitute for the other.

The argument did not disappear at adoption

The IETF 126 INTAREA minutes capture two concerns that remain useful after adoption. One participant argued that refusing future IPv4 option numbers could block legitimate limited-domain use. Another stressed that information should be preserved when old material becomes defunct. The author answered that experimental values exist and that registry entries remain.

The adoption discussion went further. Objections challenged how the draft characterized IPv4-option reliability and worried that its justification might later be quoted too broadly. Supporters favoured adoption. The chairs' eventual decision puts the text under working-group control; it does not retrospectively convert every statement in the thread into consensus.

That distinction is healthy. A working group needs to be able to adopt a tractable problem before it has settled every sentence. Public accountability then depends on keeping the decision object precise: “adopt this document for work” is not “approve each requested IANA action,” and neither is “IANA executed the action.”

Give every registry action its own receipt

The document already names exact registries and exact operations. The missing public join is between those instructions and their later disposition. A compact registry-action receipt could be published for each requested operation. This is an editorial proposal, not an IETF or IANA requirement.

Each receipt would record the registry's exact name and URL; a dated pre-change snapshot; the draft revision and hash; the action verb—close, set policy, remove or replace note; the applicable working-group, IETF and IESG milestones; IANA's execution confirmation; the effective reference; a dated post-change snapshot; and the archival treatment of existing values.

The receipt should not collapse two name registries merely because both receive the same policy. Nor should it describe a closed registry as deleted. If IANA uses the fallback note instead of removing the TTL page, the record should say so. If later review changes the proposed IP Option policy, the receipt should retain the superseded request rather than silently overwriting the path.

This is small governance machinery for a small document. Its value is that the public can tell whether a claim describes authorship, working-group ownership, standards approval or operational execution. The new WG filename proves the first handoff. The live registries prove the present state. Everything between them still has to happen in the open.

Sources

  1. IETF Datatracker — current working-group document
  2. Datatracker — working-group document history
  3. Immutable working-group revision 00
  4. Datatracker — replaced individual-document history
  5. Immutable individual revision 03
  6. IETF 126 INTAREA minutes
  7. INTAREA adoption discussion
  8. IANA — DHCP and BOOTP parameters
  9. IANA — IPv4 parameters
  10. IANA — Machine Names
  11. IANA — Terminal Type Names
  12. RFC 8126 — IANA registration guidance
  13. INTAREA documents