Summary

  • RFC 9650 changes the registration procedure for the IS-IS Neighbor Link-Attribute Bit Values registry from Standards Action to Expert Review so experimental work can obtain coordinated values without resorting to unregistered use.
  • Expert approval and an IANA row prove a bounded allocation decision; they do not prove protocol quality, interoperability, implementation, deployment, operator adoption or routing effect.
  • Leadership should preserve a receipt chain from request and expert decision through build, authorised enablement, advertisement, peer parsing, local policy, selected route and observed service outcome.

A collision made from two reasonable shortcuts

Imagine two implementers working before either extension has reached an RFC. Each needs one flag in a 16-bit field. Each checks the public registry, sees the same empty position and calls it temporary. Their private choices work in their own labs. When the implementations meet, one bit now names two incompatible behaviours.

The failure is not that either team failed to count. It is that scarcity was coordinated privately. A value that looks unused is not a safe local resource because another experiment can make the same inference. RFC 7120 describes both bad endings: IANA may later assign the extension a different value, separating early implementations from the final standard, or assign the squatted value to another extension, producing a collision in deployed packets.

RFC 9650 addresses that incentive in one precise place. RFC 5029 had created the IS-IS Neighbor Link-Attribute Bit Values registry and required Standards Action, while permitting Early Allocation. RFC 9650 says that procedure was unnecessarily restrictive for experimental protocols and increased the risk of unregistered code point use. It changes the policy to Expert Review.

That is a coordination repair, not a relaxation of reality. It makes it easier to reserve a shared symbol before a complete standards verdict exists. It does not make the earlier verdict exist.

What is actually being allocated

RFC 5029 defines the Link-Attributes sub-TLV as subtype 19. Its value is a 16-bit flags field. The original specification assigned 0x1 to Local Protection Available and 0x2 to Link Excluded from Local Protection. The sub-TLV is optional, may appear at most once for a neighbour and can be silently ignored by a router that does not support it.

The live IANA IS-IS TLV Codepoints registry now records Expert Review, names designated experts and cites RFCs 5029, 9667 and 9650. It also records 0x4 for Local Edge Enabled for Flooding, defined by RFC 9667.

That row answers a narrow and indispensable question: which documented meaning owns this bit in the shared namespace? It does not answer whether a vendor implemented the feature, whether a particular binary contains it, whether an operator enabled it, whether a peer parsed it or whether the route calculation changed.

This distinction matters because registry interfaces look authoritative. They are authoritative about allocation. The visual neatness of a row can tempt a change process to infer approval over adjacent layers that the row never examined.

Expert Review is review, not a miniature standard

RFC 8126 places registration policies on different procedural levels. Standards Action requires a Standards Track RFC. Expert Review requires a designated expert to evaluate a sufficiently documented request under published guidance. It is neither no review nor first come, first served.

The reason to choose the lighter mechanism is operational, not ideological. RFC 8126 warns that overly strict criteria and excessive cost in time or effort can discourage registration. When actual use moves outside the registry, the registry stops reflecting the namespace and loses the value that made review worthwhile. The recommended design is the least strict policy that still fits the registry's needs.

RFC 9650 binds this discretion to guidance. RFC 7370 tells the designated experts to consider requests from working-group documents or planned Area Director-sponsored work, check the relevant consensus or approval, and review technical merit. Experts should not overrule IETF consensus, although they may raise issues before an assignment. Once approved, IANA records the value and associated document. If the document fails to progress, the expiry and deallocation process applies.

The expert therefore decides whether a value should be coordinated under the registry's rules. The expert does not certify every property of the protocol. Allocation can precede the evidence that only implementation and deployment will create.

The receipt must not stop at IANA

A defensible chain begins with the exact request: document revision, requested function, range, change controller and date. It then records the expert's identity, scope, criteria, questions and decision. The IANA receipt adds the assigned bit, reference, lifecycle state and observed registry timestamp.

Implementation creates a new evidence layer. Record the commit, build provenance, parser and emitter tests, behaviour for unknown flags and behaviour when more than one Link-Attributes sub-TLV appears. RFC 5029 says a receiver should consider only the first duplicate instance. A test must show what the deployed build actually does.

Deployment creates another layer. Preserve who authorised enablement, on which devices and adjacencies, under which configuration and rollback boundary. Capture the emitted Link State Packet. At each receiving peer, distinguish packet arrival, syntactic parsing, semantic support, policy acceptance and route-calculation use.

Finally, preserve forwarding and service observations. A registered bit can arrive and be ignored. It can be parsed but excluded by policy. It can affect a route calculation without producing the expected service result. Each transition deserves its own receipt because no earlier transition entails the later one.

This is running-code primacy in its practical form. The registry supplies vocabulary. The loaded binary, configuration, packet and route supply operational fact.

Security did not move with the procedure

RFC 9650 explicitly says that it does not change the security issues in RFC 5029. The older document notes that Link State Packets can expose additional capability information to an observer and that modification can matter; specifications using the mechanism must discuss disclosure and modification, with integrity protection considered where the risk is high.

Changing the allocation policy neither cures nor worsens a particular implementation by itself. It cannot authorise an originator, protect an LSP, validate a parser or constrain a route policy. Those controls remain where they were.

This is an important governance pattern. A process can reduce one risk—namespace collision—without absorbing responsibility for every risk attached to the thing being named. Treating an allocation as a security review would not strengthen the system. It would hide the party who actually owns parser safety, configuration authority or routing consequence.

A minimum shared rule with visible local authority

Heng Lu's Minimum Initial Specification supplies the useful design test. The shared layer should carry the minimum fact needed for independent systems to avoid collision and understand the symbol. Future adoption and operating choices should remain local and explicit.

RFC 9650 fits that shape. The IETF and IANA maintain a common meaning for a scarce bit. An implementer decides whether to write code. A vendor decides what to ship. An operator decides what to enable. A peer applies its own support and policy. The network produces a result that must be observed rather than inferred.

The reality-layers discipline prevents the registry row from impersonating those later facts. Request, expert judgment, allocation, specification, build, advertisement, parse, route and service are connected. They are not interchangeable.

Sources