RFC 6410

Reducing the Standards Track to Two Maturity Levels 🎀

Okay bestie, let's talk about RFC 6410 💖 It's a Best Current Practice (BCP 9) from October 2011, and it's giving main character energy because it literally changes how IETF standards move up the ladder ✨

Authors: R. Housley (Vigil Security), D. Crocker (Brandenburg InternetWorking), and E. Burger (Georgetown University) 👑

Status: ISSN 2070-1721, a Best Current Practice 🌸

It updates RFC 2026 🦋 and doesn't obsolete anything. The title block also lists Updates: 2026, so yep, that's the one getting the glow-up.

---

Abstract ✨

Okay so this document updates the Internet Engineering Task Force (IETF) Standards Process from RFC 2026. The big move? It shrinks the Standards Process from three Standards Track maturity levels down to two 💅

Status of This Memo 🌈

This memo documents an Internet Best Current Practice 🧚

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG). For more BCP info, check Section 2 of RFC 5741 💜

Info about the current status of this doc, any errata, and how to give feedback lives at:

http://www.rfc-editor.org/info/rfc6410

Copyright Notice 💌

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🫶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please review those carefully, because they describe your rights and restrictions. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜

1. Introduction 🍓

Okay, so this doc changes the Internet Standards Process from RFC 2026 [1]. The IETF had a real struggle getting documents through the maturity levels (Proposed Standard, Draft Standard, and finally Standard) 😭 The goal is to simplify things and cut down on roadblocks, while keeping the best parts of the IETF engineering approach. On top of that, the requirement for annual review of Standards Track documents that haven't hit the top of the ladder is removed. Bye bye 👋

A bunch of people had proposals for smoothing this out over the years. In May 2010 the IESG talked through many of them, and then at IETF 78 in July 2010 a plenary showed big support for going from three tiers to two 🔥

Here's the tea: in recent years, the vast majority of Standards Track docs got published as Proposed Standards and never leveled up. Very few specs advanced in the last decade 🙈 The idea is that implementation and deployment experience should actually be used to improve specs, which is lowkey the whole point ✨

The main change is the requirements for moving past Proposed Standard. RFC 2026 [1] wanted a report showing interoperability between at least two implementations from different code bases as an interim step ("Draft Standard") before going to the final level ("Standard") based on widespread deployment and use. This doc instead measures interoperability through widespread deployment of multiple implementations from different code bases, so the two metrics get condensed into one 💖

The expected result is maturity advancement based on widespread deployment of quality specs. Plus, lessons from implementation and deployment get folded in, and protocols get better by ditching complexity from unused features 🦋

In RFC 2026 [1], widespread deployment was basically the metric for going from Draft Standard to Standard. Using that same metric past Proposed Standard means the top two tiers aren't meaningfully different anymore, so the ladder gets cut to two tiers 💅

Also, RFC 2026 [1] required an annual review of specs that hadn't reached the top level. That review is no longer required 🌸

2. Two Maturity Levels 🎀

This doc swaps the three-tier ladder from RFC 2026 [1] for a two-tier one. Specs become Internet Standards through two maturity levels in the "Standards Track": "Proposed Standard" and "Internet Standard" 👑

A spec may be (and honestly, is likely to be) revised as it moves from Proposed Standard to Internet Standard. When a revised spec gets proposed for Internet Standard, the IESG shall determine the scope and significance of the changes and, if necessary and appropriate, modify the recommended action. Minor revisions and removing unused features are expected, but a significant revision may need more experience at Proposed Standard before it progresses 🧚

2.1. The First Maturity Level: Proposed Standard 💜

The stated requirements for Proposed Standard are not changed. They stay exactly as RFC 2026 [1] specifies. No new requirements get added, and no existing published requirements get relaxed 🫶

2.2. The Second Maturity Level: Internet Standard ⭐

This maturity level merges Draft Standard and Standard, as RFC 2026 [1] defined them. The name was picked to avoid mixing things up with "Internet-Draft" 🌈

The characterization of an Internet Standard stays as RFC 2026 [1] describes it, which says:

An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.

The IESG, in an IETF-wide Last Call of at least four weeks, confirms that a doc advances from Proposed Standard to Internet Standard. The reclassification request goes to the IESG along with an explanation of how the criteria were met. The criteria are:

1. There are at least two independent interoperating implementations with widespread deployment and successful operational experience.
2. There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.
3. There are no unused features in the specification that greatly increase implementation complexity.
4. If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process.

After reviewing and considering significant errata, the IESG will run an IETF-wide Last Call of at least four weeks on the requested reclassification. If there's consensus, the RFC gets reclassified without publishing a new RFC 💅

As RFC 2026 [1] says, in a timely fashion after the Last Call ends, the IESG shall make its final call and tell the IETF about it by email on the IETF Announce mailing list. No changes are made to Section 6.1.2 of RFC 2026 [1] 🌸

2.3. Transition to a Standards Track with Two Maturity Levels 🦋

Any protocol or service currently at Proposed Standard stays right there 🍓

Any protocol or service currently at Standard shall be immediately reclassified as an Internet Standard 👑

Any protocol or service currently at the abandoned Draft Standard maturity level keeps that classification, unless someone takes explicit action. There are two possible actions:

1. A Draft Standard may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied.
2. At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard 🧚

3. Removed Requirements 💖

3.1. Removal of Requirement for Annual Review 🌸

In practice, the annual review of Proposed Standard and Draft Standard documents after two years (called for in RFC 2026 [1]) never actually happened. Not having it didn't cause any ill effects on the Internet Standards Process, so the requirement is dropped. No review cycle is imposed on Standards Track documents at any maturity level 💅

3.2. Requirement for Interoperability Testing Reporting 🫶

Testing for interoperability is a long tradition in Internet protocol development and is still important for reliable deployment. The IETF Standards Process no longer requires a formal interoperability report, since deployment and use is enough to show interoperability ✨

Even though it's no longer required, RFC 5657 [2] can be helpful for interoperability testing 🎀

4. Security Considerations 🔥

This document does not directly affect the security of the Internet 🌈

5. Acknowledgements 💜

A two-tier Standards Track has been proposed many times, so shoutout to everyone who put in the work! Spencer Dawkins, Charlie Perkins, and Dave Crocker made a proposal in 2003. Scott Bradner proposed in 2004, Brian Carpenter in June 2005, and Ran Atkinson in 2006. This document takes ideas from many of those, plus the IESG discussion in May 2010, the IETF 78 plenary in July 2010, and yet another proposal from Spencer Dawkins, Dave Crocker, Eric Burger, and Peter Saint-Andre in November 2010 🦋

6. References 📜

6.1. Normative References

[1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
     9, RFC 2026, October 1996.

6.2. Informative References

[2]  Dusseault, L. and R. Sparks, "Guidance on Interoperation and
     Implementation Reports for Advancement to Draft Standard", BCP
     9, RFC 5657, September 2009.

Author's Address 💌

Russell Housley
Vigil Security, LLC
EMail: housley@vigilsec.com

Dave Crocker
Brandenburg InternetWorking
EMail: dcrocker@bbiw.net

Eric W. Burger
Georgetown University
EMail: eburger@standardstrack.com
URI:   http://www.standardstrack.com