Summary

  • RFC 6410 replaced three standards-track levels with two, yet existing Draft Standards kept that label unless the IETF explicitly reclassified them.
  • The new rules allowed promotion under stricter deployment criteria or an optional IESG downgrade after two years; they did not automatically clean up old statuses.

Analysis

What the old rung required

In October 1996, RFC 2026 set out three standards-track levels: Proposed Standard, Draft Standard and Internet Standard. A specification could reach Draft Standard after at least two independent, interoperable implementations from different code bases and sufficient successful operational experience. The working-group chair was to document the qualifying implementations and their interoperability tests. “Draft Standard” was a maturity label for a published specification, not another name for an Internet-Draft.

The next step asked a different question. RFC 2026 described an Internet Standard as a specification with significant implementation and successful operational experience, and a generally held belief that it benefited the Internet community. The ladder therefore separated early implementation evidence from broader maturity.

What changed in 2011

RFC 6410 said that very few specifications had advanced in the previous decade and that most remained Proposed Standards. It merged Draft Standard and Standard into one Internet Standard level. The IETF kept deployment and operational experience in the advancement criteria: two independent interoperating implementations had to be widely deployed and successfully operated, alongside checks for interoperability-breaking errata and unused features that added substantial complexity.

The revision also removed two process obligations. RFC 2026’s annual review of specifications that had not reached the top level was not taking place, RFC 6410 said, so it removed the review cycle. And it stopped requiring a formal interoperability report. Testing remained important; RFC 6410 said deployment and use could demonstrate interoperability, while RFC 5657 could still help people prepare reports.

Transition was not migration

The transition rule treated the old statuses differently. Proposed Standards remained Proposed. Existing Internet Standards were immediately called Internet Standards. A document already classified as Draft Standard, however, kept that classification absent explicit action. It could be promoted under RFC 6410’s new criteria. After two years from the document’s approval as a Best Current Practice, the IESG could choose to reclassify it as Proposed Standard.

That was not an automatic downgrade, a promotion, or a list-wide reset. The text left an old label attached unless a later decision changed it. RFC 6410 does not count how many documents stayed in that state or say when any individual document was eventually reclassified.

The label and the network

RFC 6410 streamlined the path for future advancement, but it did not turn a status entry into a census of software in use. A Draft Standard left over from the previous ladder did not, by that fact alone, prove current interoperability or broad deployment. Conversely, the absence of a formal report after 2011 did not mean testing had become irrelevant. The revised criteria still relied on independent implementations and successful use.

The record is narrow: one standards-process change and its transition rules. It does not show what every operator deployed. The operational distinction is easy to miss when a label survives longer than the process that created it.

Sources