Summary

  • RFC 3359 published a common map of IS-IS TLV values to prevent collisions while explicitly saying that the document was neither a standard nor an authority assigning numbers.
  • RFC 3563 later turned that snapshot into a temporarily IANA-maintained registry with designated-expert review; registration coordinated a name but never proved parser support, deployment or a network result.

Two protocol designers can be individually careful and collectively incompatible. Each sees an unused-looking octet, assigns it to a different extension and produces software that behaves correctly according to its own private table. When their implementations meet, the wire carries one number and the receivers supply two meanings.

The failure does not begin with a malformed packet. It begins with a namespace that lacks shared memory.

RFC 3359, published as Informational in August 2002, supplied that memory for IS-IS Type-Length-Value elements. T. Przygienda's short document collected the top-level values known to be used by the protocol and pending extensions. It showed whether each TLV belonged in an IIH, LSP or SNP, and gave a broad status source.

The table was visibly untidy, because the protocol's institutional history was untidy. Some values came from ISO 10589. Others came from RFC 1195's use of IS-IS for IP. Several were attached to IETF drafts. One DECnet entry was labelled ancient. Lucent and Nortel proprietary values appeared beside open work. “Used” did not mean “standardized by one body,” and every row did not carry the same authority.

That mixed status was not a defect hidden in the small print. It was the very reason the list mattered. Extension work was occurring in several places, while the numeric field remained one shared wire space. If each community looked only at its own documents, a collision could cross the institutional boundary before any organization knew it existed.

RFC 3359 was unusually direct about what it could not do. It said the document existed to avoid future conflicts, but did not constitute or represent a standard or an authority assigning TLV numbers. Allocation occurred on a shared, informational basis among ISO, SIF and IETF groups. ISO provided no numbering authority for the space, while IANA's responsibility was then described as limited to IP-related coding points. The memo concluded that no plausible central authority existed at that moment.

The list therefore coordinated by disclosure. A new extension author could see that a value was already occupied or pending and choose another. No police power was needed for the list to be useful. Its force came from participants preferring interoperability over a private claim to an octet.

The limits remained concrete. RFC 3359 did not identify the specific defining document behind every value. It did not resolve sub-TLV codepoints. It expected periodic updates and admitted that an official registry might replace it. A row was a warning against reuse, not a complete provenance record.

This was the same year that RFC 3232 retired the practice of republishing the broad Assigned Numbers catalogue as successive RFCs in favor of an online database. A living registry could change without issuing a new historical document for every assignment. Yet IS-IS presented an additional difficulty: its core came from ISO, its Internet extensions came through the IETF, and implementations already occupied values outside a single clean process.

The institutional repair arrived in RFC 3563. Published in 2003, it recorded the cooperative agreement between ISOC/IETF and ISO/IEC JTC1/SC6. The agreement distinguished core IS-IS mechanisms maintained through ISO from Internet-specific extensions within IETF scope. It also asked IANA to maintain the IS-IS TLV registry temporarily until JTC1 provided registry service.

“Temporarily” is important. RFC 3563 did not crown IANA as a permanent sovereign. It contemplated transferring allocation authority to JTC1 after notification, while IANA could retain an informational copy updated from JTC1. Custody of a web page, power to approve a value and responsibility for the protocol standard were separable roles.

The new registry began with continuity rather than erasure. RFC 3563 said its initial state should be synchronized with RFC 3359. The informal map became seed evidence for the formal process. New values required approval by a designated expert appointed by the IESG. The IETF would keep JTC1/SC6 informed, and JTC1/SC6 would refer requests from its constituencies into the IANA process.

That agreement did not make every old row equivalent. It created a shared doorway for future allocations and a maintained place to record them. A later specification still had to define syntax and behavior. Software still had to implement it. Operators still had to enable it. Peers still had to exchange and interpret it correctly.

The registry itself continued to acquire structure. RFC 6233 added a Purge column so the top-level table could record whether a TLV may appear in a purged LSP. That was not cosmetic metadata. PDU context affects whether identical bytes are valid. A registry schema can therefore carry a bounded part of protocol interpretation, while the defining RFC retains the full rule.

RFC 7370, published on the Standards Track in 2014, refined both the table and the human review behind it. It combined related sub-TLV registries where one namespace was intended, and gave designated experts guidance for codepoints requested before a draft became an RFC.

The process was not simply “an expert likes it.” Requests were expected from working-group documents or an AD-sponsored path where no suitable group existed. Experts should check with chairs for working-group consensus or with the Area Director for approval. They should review technical merit, but not overrule IETF consensus. If the document failed to progress, the allocation could expire and be removed under the early-allocation discipline associated with RFC 7120.

This arrangement makes review a filter with recorded inputs, not personal ownership of the namespace. RFC 8126's registration-policy vocabulary helps describe such filters: Standards Action, Specification Required, Expert Review and other policies impose different prerequisites. None of them says that the allocated feature is implemented well or used anywhere.

The reverse danger is excessive friction. RFC 9650 changed one IS-IS neighbor-link-attribute bit registry from Standards Action to Expert Review in 2024. The reason was operationally sharp: the stricter policy prevented experimental protocols from obtaining bits, increasing the temptation to use unregistered values and collide through codepoint squatting. A gate that is too hard to enter can make the shared map less complete.

The durable design problem is therefore not centralization versus freedom. It is keeping coordination cheaper and more credible than silent reuse. Too little process permits collisions. Too much process can drive experimentation outside the record. A bounded expert review, visible reference and expiry rule try to occupy the middle.

The current IANA page is a living result of that evolution. It contains top-level and nested registries, applicability columns, references and policies that did not all exist in the 2002 table. This article freezes the page as a dated source. It does not claim that today's shape was present in RFC 3359 or that it will never change again.

Most importantly, a registry row is not running code. It proves that a coordination record associates a value with a name and reference under some policy. It does not prove that a parser recognizes the value, that the value is legal in the observed PDU, that two vendors interoperate, that operators enabled the extension, that a route entered the database or that a packet arrived.

Those are later receipts. Capability documentation and conformance tests speak to implementation. Configuration speaks to intended use. Packet captures show that a value appeared at one measured point. Logs and database state show local processing. Traffic tests show a result. The registry makes these observations comparable; it cannot substitute for them.

Two essays by Lu Heng are used here as disclosed analytical lenses. “Minimum Initial Specification” helps explain why a modest shared table could be valuable before final institutional custody was settled. “Reality Layers” keeps the numeric record, specification, implementation, deployment and outcome apart. These are editorial readings, not claims about RFC 3359's authorship or intent.

RFC 3359 had no allocation authority. That did not make it powerless. It gave communities one common fact before they chose, and sometimes one common fact is enough to prevent two correct private worlds from producing an incompatible public wire.

Sources