Summary

  • The 26 October IANABIS draft would tell IANA to create a Change Controller field for new registries that accept assignments without an IETF-stream RFC. It names First Come First Served, Expert Review, Specification Required and RFC Required. Existing registries without the field would receive empty fields in the future. The text is an Internet-Draft, so this is a proposal.
  • RFC 8126 already advised explicit change control; the draft changes the instruction and its reach. A live IANA JSONPath table shows the difference between a named reviewer and a named controller: Glyn Normington is the listed Expert, while the five existing function entries identify the IETF as Change Controller.

The edit after the invention

Imagine the quietest possible standards dispute. A protocol registry already contains a value. No new code point is requested. Its public description or reference needs to be updated because the software and documents around it have moved on. The person who wrote the original document may be gone. The working group may be closed. The registry still has to answer a concrete question: who can authorize a change to this entry?

The current RFC 8126 gives the answer a place in the design of a registry. It says change control for registries and registrations that originate in IETF-stream RFCs rests by default with the IETF through the IESG. It advises authors to specify a controller for registries that accept registrations from outside that stream and for each relevant value. It also says new First Come First Served and Expert Review registries should include a field for the controller. The advice is clear. Its force is a recommendation to authors, and existing tables have grown under different histories.

The IANABIS revision dated 26 October takes the next step. Section 11.2 instructs IANA to create Change Controller fields in all new registries using First Come First Served, Expert Review, Specification Required or RFC Required, and any registration procedure that does not require an IETF-stream RFC. Section 2.5 says an IETF-stream registration should ordinarily list IETF in the field rather than IESG: the latter acts for the former. Some source RFCs explicitly require IESG, and those remain exceptions. The distinction sounds like stationery until an edit request arrives. A reviewer can assess technical merit; a contact can answer mail; the controller is the party authorized to approve the change.

An empty column does not appoint anyone

The draft's treatment of older tables contains the most candid line. IANA would in the future add empty fields to existing registries that use these procedures and lack the column. Empty means empty. It creates a place to record authority without manufacturing an owner from a mailing address, a past author or a designated expert. A populated column would tell an operator whose approval matters; a blank one would tell the operator where the record still needs work. The draft supplies no count of affected registries and no schedule for filling their old entries. Those two facts would change the scale of the work.

A current IANA JSONPath registry shows what a filled entry looks like. Its Function Extensions use Expert Review, and its page names Glyn Normington as Expert. The table separately names IETF as Change Controller for length, count, match, search and value. The expert's name and the controller's name occupy different roles on the same public record. This is an existing example, not evidence that the new draft has taken effect. It makes the proposed standardization easy to see: a registry can already publish the approval line next to the technical entry.

The difference matters again when the edit concerns a contact or controller itself. The draft says that, unless a registry specifies otherwise, its registration procedure also governs modification. For a registration made without an RFC, IANA may confirm and approve updates to contact and controller information, asking experts or Area Directors for advice when needed. That fallback can repair an old record. It also means the public field and the actual approval procedure must agree; merely adding a brass nameplate does not establish who may put a name on it.

The document is still an IETF working-group Internet-Draft. Its Section 11.2 describes work for IANA if the text advances, while RFC 8126 remains the operative guidance today. A later approved text, IANA implementation record and populated examples would show whether the proposed columns became operational. Until then the live JSONPath table illustrates an existing practice, and the new wording describes a proposed obligation.