Summary

  • RFC 1264 required routing standards to carry distinct evidence for specification quality, manageability, security design, independent implementations, feature testing, operational experience and scaling limits.
  • RFC 4794 retired that routing-specific universal checklist in 2006 because it impeded timely publication. It preserved the IESG's power to require evidence and a working group's choice to keep local procedures.
  • Later process documents kept separating status from execution: RFC 6410 tied Internet Standard maturity to independent interoperability, widespread deployment and successful operations, while RFC 7942 made implementation-status reporting useful but voluntary and not independently verified.

A routing document entered with an evidence cabinet

RFC 1264 treated a routing protocol as a distributed real-time system whose weaknesses might remain invisible in a single laboratory. One implementation could work in one topology and still fail when another code base interpreted a corner differently. A protocol could look stable at today's network size and collapse at an unforeseen limit.

The answer was not a single certificate. It was a cabinet of separate records. One drawer held the protocol and usage specifications. Another held the Management Information Base needed for remote management. A third held the security architecture. Others held implementation origins, test scenarios, test results, operational environments and a scaling analysis.

This mattered because every record answered a different question. A readable specification showed that an outsider might reproduce the design. A MIB showed that operators had defined observable and controllable state. A security architecture described intended protection. None proved that two implementations exchanged routes, that authentication worked, or that the protocol survived a production topology.

Independence was a provenance claim

RFC 1264 generally required multiple interoperable implementations, including at least two written independently. The adjective changed the evidence. Two binaries derived from one code base could repeat the same interpretation and the same defect. Independent origins created a harder test of whether the document itself carried enough meaning.

The implementation list therefore had to record code origin. The test report had to identify scenarios and results. For advancement to Draft Standard, all features had to run between at least two implementations, including all security features. The document did not let an implementation count stand in for feature coverage.

Even that receipt was bounded. A successful exchange in a test arrangement showed behavior under those versions, inputs and conditions. It did not prove multivendor operations at scale, resistance to every attack, or a reliable service for users. Implementation, interoperation, security demonstration and outcome remained separate facts.

Operational experience had a shape

RFC 1264 did not accept the phrase “operational experience” without coordinates. Reports were to include topology, environment, time, duration, implementations, overall results and conclusions. Significant features had to be exercised. Exterior protocols had to carry the full exterior route set; interior protocols had to carry both interior and exterior routes unless another mechanism did the latter.

The burden changed with maturity. Proposed Standard needed an implementation and evidence that major features had been tested, but no operational experience was required. Draft Standard demanded significant experience in a moderate router population and moderately complex topology that was part of the operational Internet. Full Standard demanded a large router population, complex topology and multivendor operation.

Those thresholds were requirements, not historical findings. RFC 1264 did not certify that every candidate had met them. A standards action and the underlying implementation report needed their own identities, dates and scope.

The second report asked where the protocol would break

The most unusual part of the checklist was not an interoperability count. It was the second report. The protocol's key algorithms had to be explained; bandwidth, memory and CPU use had to be examined under normal conditions; growth had to be modeled at least an order of magnitude beyond the current environment; limits and unsuitable environments had to be named.

This made applicability part of maturity. A protocol was not simply “scalable.” It consumed specific resources under assumptions and had boundary conditions. Comparison with existing routing protocols made the claimed improvement inspectable.

Analysis still was not observation. A scaling model could state where designers expected failure. A test could approach that boundary. A live network could encounter a different one. Keeping model, experiment and operation separate prevented a forecast from becoming a deployment receipt.

In 2006, timeliness changed the control surface

RFC 4794 declared RFC 1264 Historic in December 2006. Its argument was institutional: a blanket extra process for one class of protocols slowed publication, while the general standards process and other pressures already constrained unreasonable designs. The problem was not that routing had become simple.

The removal was precise. RFC 4794 eliminated the broad requirement from every routing document. It also said Routing Area Directors could still require implementation or operational experience under RFC 2026. Working groups could continue procedures based on RFC 1264 if they found them useful. Manageability and security remained concerns under broader policies.

Authority therefore moved. Instead of one mandatory routing checklist deciding the minimum evidence for every case, the IESG and working groups could calibrate the demand. That improved discretion and timeliness. It also made the decision record more important: readers now needed to know who requested which evidence, for what risk, and why the available record was sufficient.

General process did not collapse status into deployment

RFC 2026 already distinguished the first maturity level from later operational confidence. Proposed Standard normally required neither implementation nor operations, although the IESG could demand them for core protocols or behavior with significant operational impact. Implementers were warned to treat Proposed Standards as immature and to use implementation for validation and learning.

RFC 6410 later reduced the ladder from three levels to two. It did not erase the higher evidence burden. Its Internet Standard criteria included at least two independent interoperating implementations with widespread deployment and successful operational experience, alongside errata, unused-feature and licensing checks.

Even “widespread deployment” is a category, not a universal service result. It needs populations, versions, time windows and observations. A protocol can be widely deployed while a particular network has not enabled it, a feature remains unused, or an operator experiences a different outcome.

A lighter implementation record carried its own warning

RFC 7942 made an Implementation Status section a Best Current Practice for Internet-Drafts. The section could list implementation maturity, licensing, experience, contacts and interoperability reports. Its benefit was earlier feedback: running code might reveal whether a specification was comprehensible and interesting enough to implement.

The process was voluntary. Its standard boilerplate also said contributor-supplied listings were not IETF endorsement, had not necessarily been independently verified, and were not a catalogue of available implementations or features. Authors could report an implementation without proving every claim a reader might infer from the entry.

This was not a weakness hidden in the process. It was a declared provenance boundary. The implementation section supported a decision; it did not replace test artifacts, operational telemetry or deployment evidence.

Sources and evidence limits

The 1991 checklist and its stage-specific requirements come from RFC 1264. The general standards authority comes from RFC 2026. The routing-specific retirement comes from RFC 4794. The two-level maturity model comes from RFC 6410, and the voluntary implementation-status record from RFC 7942.

These sources establish published procedures, criteria and stated reasons for changing them. They do not establish that any named routing protocol satisfied RFC 1264, that a listed implementation was independently verified, that a specific operator deployed a feature, or that users obtained an outcome. Historic status records a process decision; it does not erase old evidence or prove old claims false.