Summary

  • RFC 9515 changes ranges 32768–65530 in six BGP Monitoring Protocol registries from Specification Required to First Come First Served.
  • The new policy can prevent collisions by giving extensions public numbers early, but it intentionally performs no technical filtering and does not require an interoperability-grade specification.
  • Leaders must keep allocation evidence separate from semantic definition, implementation, collector support, transport protection, deployment and the operational conclusions drawn from telemetry.

The request arrives with a preferred number, a short description and a reference. If the request is well formed and the value is free, IANA can assign it. There is no designated expert deciding whether two independent implementations could build the same behavior from the document. That absence is not a process failure. Under First Come First Served, it is the policy.

RFC 9515 made that policy explicit for six registries created by the BGP Monitoring Protocol. Its aim is practical: lower the cost of public coordination before implementers occupy numbers privately and collide later. The gain is real. So is the limit of what the resulting row can prove.

Six ranges changed, not the whole protocol

The affected range is 32768–65530 in BMP Statistics Types; Initiation and Peer Up Information TLVs; Termination Message TLVs; Termination Message Reason Codes; Route Mirroring TLVs; and Route Mirroring Information Codes. The lower range, 0–32767, continues to require Standards Action. Values 65531–65534 remain experimental and 65535 remains reserved.

RFC 9515 does not redefine a BMP message, add a transport protection or approve an extension. It changes one institutional gate. RFC 7854 had used Specification Required for those high ranges. Later experience persuaded the working group that the policy was too close to the burden of Standards Action in practice and that a much lower bar would reduce code-point squatting.

The distinction is sharper than “less paperwork.” RFC 8126 says First Come First Served has essentially no filtering: a well-formed request is accepted if the value is available. Specification Required adds designated-expert approval and a permanent public specification sufficiently stable, clear and technically sound for independent interoperable implementations. RFC 9515 deliberately removes both of those checks from the high BMP ranges.

That makes this reform different from RFC 9519, which moved ordinary SSH registrations from IETF Review to Expert Review, and RFC 9650, which made a comparable Expert Review change for an IS-IS registry. Both retain a technical reviewer. RFC 9515 removes that gate for the named BMP ranges. The older policy vocabulary in RFC 5226, cited by RFC 7854, supplies the historical baseline; RFC 8126 is the current authority.

A registry row solves one collision

The live IANA BMP Parameters registry now displays First Come First Served for the six ranges and cites RFC 9515. A completed assignment can establish that one public value is associated with one description and reference, and that IANA did not knowingly assign the same value twice in the same registry.

It cannot establish that the reference defines every bit, error case and version transition. It cannot show that two routers emit the same payload, that collectors parse it alike, or that a dashboard labels it correctly. It cannot prove that the observation came from the router named in a report. Nor can it prove that an operator should act on the resulting metric.

Those gaps matter because BMP is not decorative metadata. RFC 7854 uses it to export route views, peer events, mirrored BGP messages and statistics to a monitoring station. Its security section warns that the feed can expose private routing information and that, without suitable protection, an attacker may impersonate a router or collector, read the stream or alter it. A collision-free type code inside an unauthenticated or ambiguously interpreted feed is still weak evidence.

Cheap allocation moves cost downstream

Under Specification Required, part of the semantic burden was visible before assignment. Under First Come First Served, the registry can no longer be used as a proxy for that work. The burden moves to implementers and operators—and it should appear in their records.

The allocation receipt should contain the exact registry and range, request, number, description, reference, requester, contact or change controller, availability result and timestamps. The semantic receipt should contain a versioned specification, wire examples, units, cardinality, error behavior, compatibility rules and change history. The implementation receipt should name commits, releases, router roles, collector/parser versions and test vectors. The deployment receipt should add configuration scope, transport protection, data provenance, observed failures, schema migration and rollback.

Keeping those receipts separate avoids two symmetrical mistakes. A vendor cannot present an IANA number as technical approval. An operator also should not treat the absence of expert review as evidence that the allocation is illegitimate. FCFS should be judged on fast, collision-free coordination. The extension should be judged on independent operational evidence.

The current IANA page is a live document. Later work such as RFC 9736 and RFC 9972 has changed BMP namespaces and assignments. That history is another reason to store the policy version, assignment time and implementation version rather than treating today’s registry as a timeless snapshot.

The documentary trail is reconstructable through the RFC Editor’s information record, plain text, XML and errata search, plus the Datatracker RFC history and final draft. These prove how the gate changed. They do not prove what a later extension does in a network.

The analytical discipline follows three distinct Heng Lu essays on running-code primacy, minimum initial specification and voluntary adoption and reality layers. Their useful common demand is precision: a symbolic allocation must not impersonate an operational result.