Summary

  • RFC 5218 distinguishes implementation, deployment or enablement, actual use, and “wild” success beyond the protocol's original purpose or scale. A large installed base is evidence of reach, not proof that the original assumptions still hold.
  • Leadership needs a design-space receipt: the original purpose and scale, the new uses, the extensions and intermediaries involved, preserved invariants, measured limits, affected users, and the owner of each remediation decision.

The victory report arrived one receipt too early

The dashboard said the protocol had won. Implementations existed in every important product family. Operators had enabled it. Traffic volume kept rising. New teams were building functions on top of it that the original authors had never named.

That is not the end of the evaluation. It is the moment the evaluation changes.

RFC 5218, the IAB's 2008 study of protocol success, draws a boundary between ordinary success and “wild” success. Ordinary success meets the original purpose at the intended scale. Wild success exceeds the planned purpose, the planned scale, or both. The second state sounds better in a launch memo. Operationally, it is a different system.

The protocol may now carry traffic with different latency, privacy or trust assumptions. Its extension points may be used by parties who never coordinated with the original designers. Intermediaries may have learned only the old values. Attackers gain a more valuable target. A limit that was harmless inside the original population may become a system constraint.

Success therefore creates a debt: not guilt for adoption, but an obligation to re-establish what remains true.

Four facts hidden inside one adoption number

RFC 5218 lists three failure symptoms: no mainstream implementation, no deployment or enablement, and no actual use. The sequence matters because each transition needs separate evidence.

A product can ship code that no operator enables. An operator can enable a feature that no application invokes. An application can send a protocol message without producing a valuable user outcome. Conversely, a mechanism can be useful inside one domain without being inter-domain, and can meet its original goal without becoming universal.

An adoption percentage collapses those facts. The denominator may count capable devices, configured devices, observed messages, active users or traffic volume. Those quantities answer different questions. A board that approves further dependence on “80 per cent adoption” without naming the denominator has approved an adjective, not a control.

The useful ledger records specification status, implementation support, enabled population, observed use, purpose, scale, extension set and user outcome separately. No row inherits the proof of the previous row.

The design space moved under the installed base

RFC 5218 identifies four consequences when use escapes the original design space. Choices that were appropriate for the first purpose can create side effects in the new one. Performance can fail at an unplanned scale. Implementers can change behaviour without understanding system invariants. Popularity can make uncertain extensions attractive attack surfaces.

This is a governance issue because no single group necessarily owns the expanded system. The standards body maintains text. Vendors choose implementations and release branches. Operators configure intermediaries. Application teams invent new uses. Users bear failures. The party able to observe one layer may not have authority to repair another.

The correct response is not to declare the protocol a failure. Nor is it to let success excuse every extension. It is to reopen the design case for the actual system now in service.

RFC 6709 sharpens that duty for extensions: identify invariants, specify how unknown extensions are handled, and analyse interaction among extensions. RFC 9170 adds a deployed reality: an extension point can exist on paper yet be unusable because endpoints or middleboxes have ossified around the old values. A reserved code point is not a traversable capability.

Build a design-space receipt

Leadership should require one evidence package before treating expanded use as authorised dependence.

First, preserve the original contract: intended users, purpose, topology, scale, threat model, mandatory behaviour and explicit non-goals. Second, describe the observed expansion with measurements rather than aspiration: active endpoints, traffic, domains, intermediaries, extension values and user tasks. Third, test the invariants that must survive the move. Fourth, identify who can change each affected layer and who bears the loss.

The receipt must also keep negative evidence. Unknown-extension drops, fallback rates, parse failures, limit exhaustion, downgrade paths and unexplained absence of new values are not noise. They show where the deployed protocol differs from the extensible protocol described by its specification.

Finally, record user outcomes. RFC 8890's end-user priority prevents the installed base from becoming its own justification. More messages, devices or vendors do not prove that the expanded use serves the people relying on the system.

What the record does not establish

These documents are design and research guidance. They do not prove that a named protocol, vendor or deployment is currently unsafe. RFC 5218's examples are historical case studies, not a 2026 census. RFC 9170's discussion of ossification does not show that every extension point is blocked.

The evidence supports a narrower conclusion. Widespread use proves widespread use. It does not prove that new purposes preserve old assumptions, that a new extension traverses the deployed path, that scale remains below every hard bound, or that users received the intended benefit.

Sources

Additional standards record

  1. RFC 5218 plain text
  2. RFC 5218 information record
  3. RFC 5218 Datatracker record
  4. RFC 5218 errata record
  5. RFC 6709 information record
  6. RFC 8170 information record
  7. RFC 8890 information record
  8. RFC 9170 information record