Summary

  • RFC 2000 recorded two independent judgments: where a specification sat in the standards process, and how strongly an applicable class of systems was advised to implement it.
  • Inclusion, maturity and requirement labels were dated institutional evidence. They did not by themselves prove deployment, interoperable operation, traffic share, purchasing authority or present validity; Historic did not prove that installed systems had disappeared.

The most useful sentence in RFC 2000 was almost an expiry stamp: do not use this edition after 16 June 1997. Published in February as STD 1, it replaced RFC 1920 and earlier official summaries. In June, RFC 2200 replaced it and supplied another deadline. The list was designed to be superseded.

That version boundary changes how every row should be read. RFC 2000 was an official answer to a question with a date: how the IAB and IESG classified the recorded specifications at that moment. It was not a census of installed code. Indeed, the document acknowledged that some vendor protocols had achieved widespread implementation without IESG approval. Formal position and operational adoption could plainly diverge.

Its central device was not one ladder but two independent axes. The STATE axis recorded maturity: Standard, Draft Standard, Proposed Standard, Experimental, Informational or Historic. The STATUS axis recorded a requirement level: Required, Recommended, Elective, Limited Use or Not Recommended. The printed matrix showed common combinations, not observations of implementation volume.

Maturity answered what the standards institution had established about a specification. Standard meant the IESG had made it an official Internet standard and assigned an STD number. Under the process set out in RFC 2026, Draft Standard demanded at least two independent, interoperable implementations from different code bases and sufficient successful operational experience. Yet even that level could encounter unforeseen behaviour at production scale. Proposed Standard was narrower still: it was generally stable and reviewed, but implementation and operational experience were usually not prerequisites. The label invited learning; it did not certify that the learning had already happened.

The three off-track labels required their own reading. Experimental recorded research or development work and, as RFC 2000 said explicitly, appeared for the community’s convenience rather than as evidence of standardization. Informational could carry work from other standards bodies or vendors. Historic described a specification unlikely to become a standard because it had been superseded or lost interest. None of those definitions queried routers, software inventories or traffic. Historic closed or displaced a documentary path; it did not switch off every implementation.

The requirement axis answered a different question: within an applicability domain, how strongly should a system implement the specification? RFC 2000 compressed that decision to one word while warning that one word was insufficient for every kind of host, gateway, router or server. RFC 2026 made the scope explicit. Required meant necessary for minimal conformance as specified by an Applicability Statement—not a universal order to every buyer. Recommended remained desirable but not mandatory for minimal conformance. Elective created no general necessity, although an implementation that chose the function still had to follow the specification.

Limited Use and Not Recommended constrained general use for several possible reasons; neither label alone identified which machines still ran it.

The document also separated movement from applicability. Only a change of STATE advanced a protocol along the standards track, while STATUS could be revisited at any time. A protocol could become more mature without turning into a universal requirement, or remain formally important inside a limited domain. Combining the two columns into a single score destroys that distinction.

Even the snapshot’s internal clocks were imperfectly aligned. RFC 2000 called RFC 1602 the definitive process description while its own “new RFCs” section listed RFC 2026, which had already replaced RFC 1602 in October 1996. That does not establish why the wording survived. It does show why a composite catalogue cannot make every paragraph contemporaneous merely by carrying one publication date.

The institutions later changed both the ladder and the publication mechanism. RFC 6410 collapsed the three standards-track maturity levels into Proposed Standard and Internet Standard in 2011, retaining demanding implementation, interoperability and deployment evidence for the upper level. RFC 7100 retired the periodic STD 1 summary in 2013 because it had ceased to stay current and readers had moved to the RFC Editor’s online list.

RFC 2000 therefore remains valuable precisely when its authority is kept narrow. It is evidence of what the official classification said in one window of 1997, how two distinct judgments were encoded, and which further documents a reader had to consult. To claim actual use, conformance, interoperability or survival, the list must be joined to implementation records, tests, telemetry, procurement scope and a current status source.

Sources: RFC 2000; RFC Editor record; RFC 1920; RFC 2026; RFC 2200; RFC 6410; RFC 7100.