RFC 7127

Characterization of Proposed Standards

📅 published January 2014, from ietf

RFC 7127: Characterization of Proposed Standards 💖

okay bestie, this is the RFC that gives Proposed Standards a glow-up 🦋 here's the title block so you know who's behind it ✨

  • Request for Comments: 7127
  • BCP: 9
  • Category: Best Current Practice
  • Date: January 2014
  • Updates: RFC 2026
  • ISSN: 2070-1721
  • Stream: Internet Engineering Task Force (IETF)
  • Authors: O. Kolkman (NLnet Labs), S. Bradner (Harvard University), and S. Turner (IECA, Inc.) 🫶

Abstract 🌸

okay so RFC 2026 explains how the IESG reviews IETF Proposed Standard RFCs and what maturity level those docs get. this doc is the update 💅 it gives a more current and accurate description of Proposed Standards so nobody's working off outdated vibes.

Status of This Memo 📜

this memo is an Internet Best Current Practice 🍓

it's an IETF product, and the IESG approved it for publication. if you want more on BCPs, check out Section 2 of RFC 5741.

info about the current status, errata, and where to send feedback lives at http://www.rfc-editor.org/info/rfc7127 🎀

the legal bit, but make it cute: Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully because they spell out your rights and restrictions 🙈 and any Code Components pulled from this doc need the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come without warranty, per that same license.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  IETF Review of Proposed Standards . . . . . . . . . . . . . .   2
3.  Characterization of Specifications  . . . . . . . . . . . . .   3
  3.1.  Characterization of IETF Proposed Standard Specifications   3
  3.2.  Characteristics of Internet Standards . . . . . . . . . .   4
4.  Further Considerations  . . . . . . . . . . . . . . . . . . .   4
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   5

1. Introduction 🦋

so, in the two decades since RFC 2026 came out, the IETF has upgraded how it reviews Proposed Standard RFCs 📈 which means Section 4.1.1 of RFC 2026 [RFC2026] doesn't really describe Proposed Standards anymore. lowkey outdated 💀

this doc only touches the Proposed Standards characterization from Section 4.1.1 of RFC 2026 [RFC2026]. it doesn't change how Standards Track docs get maintained, which is covered in RFC 2026 [RFC2026] and RFC 6410 [RFC6410]. if you want the full picture of standardization requirements, read those alongside this one 🫶

2. IETF Review of Proposed Standards 💜

the entry-level maturity for the standards track is "Proposed Standard" ✨ getting a spec onto the Standards Track at that level takes a specific action by the IESG 👑

the original plan was that most IETF technical specs would level up through Proposed Standard, then Draft Standard, and finally Internet Standard (see Section 6 of RFC 2026 [RFC2026]). but that hasn't really happened, for a bunch of reasons 😭 plenty of Proposed Standards are out there running the Internet and getting used a ton as stable protocols. which proves the community often doesn't think it's worth bumping a spec up to Internet Standard. in practice, going through the whole sequence is super rare, and most popular IETF protocols just stay at Proposed Standard. meanwhile the IETF built out a much more thorough review process 🔥

Proposed Standards get open development and review from the Internet technical community, including a bunch of formal cross-discipline reviews and a security review specifically 🔐 in lots of cases, implementations and even interoperable code help make it even stronger 💅 so Proposed Standards are high-quality enough to go into the usual market-based product development and deployment on the Internet. ready to slay 👑

3. Characterization of Specifications 🧚

this section replaces Section 4.1.1 of RFC 2026 [RFC2026]. Section 3.2 is a verbatim copy of the Internet Standards characterization from Section 4.1.3 of RFC 2026 [RFC2026], included so you can find it easily 🎀 this part only covers the characterization. the process stuff for Draft and Internet Standards lives in RFC 2026 [RFC2026] and its updates, mainly RFC 6410 [RFC6410].

3.1. Characterization of IETF Proposed Standard Specifications 🌷

same vibe as Section 2: the entry-level maturity for the standards track is "Proposed Standard", and moving a spec onto the standards track at that level needs a specific action by the IESG ✨

a Proposed Standard spec is stable, has resolved its known design choices, has gotten significant community review, and seems to have enough community interest to be worth it 💖

usually, you don't need implementation or operational experience to get the Proposed Standard label 🙈 still, that experience is highly desirable and will usually be a strong argument in favor of Proposed Standard 🔥

the IESG may ask for implementation and/or operational experience before granting Proposed Standard status to a spec that materially affects the core Internet protocols or specifies behavior that may have significant operational impact on the Internet 👀

a Proposed Standard will have no known technical omissions with respect to the requirements placed on it. Proposed Standards are high-quality enough that implementations can be deployed in the Internet 🫶 but, like all technical specs, Proposed Standards may be revised if problems are found or better solutions show up, especially once experiences with deploying implementations at scale come in 🦋

3.2. Characteristics of Internet Standards 🏆

a spec with significant implementation and successful operational experience may be elevated to the Internet Standard level ✨ an Internet Standard (which may simply be called a Standard) has a high degree of technical maturity and is generally believed to provide significant benefit to the Internet community 👑

4. Further Considerations 🌸

sometimes the IETF may choose to publish a Proposed Standard that has areas with known limitations or challenges 🙈 when that happens, any known issues get clearly and prominently communicated in the document, for example in the abstract, the introduction, or a separate section or statement. no hiding the tea ☕

5. Security Considerations 🔐

this doc does not directly affect the security of the Internet. 💀 low-key the most chill section ever, but it's still on the record 🫶

6. Normative References 📚

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

[RFC6410]  Housley, R., Crocker, D., and E. Burger, "Reducing the
           Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
           October 2011.

Appendix A. Acknowledgements 🫶

this doc was inspired by a discussion at the open microphone session during the technical plenary at IETF 87 🎤 huge thanks, in alphabetical order, to Jari Arkko, Carsten Bormann, Scott Brim, Randy Bush, Benoit Claise, Dave Cridland, Spencer Dawkins, Adrian Farrel, Stephen Farrell, Subramanian Moonesamy, and Pete Resnick for motivation, input, and review 💖

John Klensin and Dave Crocker made significant contributions too 👑

Authors' Addresses 💌

Olaf Kolkman
Stichting NLnet Labs
Science Park 400
Amsterdam  1098 XH
The Netherlands

EMail: olaf@nlnetlabs.nl
URI:   http://www.nlnetlabs.nl/


Scott O. Bradner
Harvard University Information Technology
Innovation and Architecture
8 Story St., Room 5014
Cambridge, MA  02138
United States of America

Phone: +1 617 495 3864
EMail: sob@harvard.edu
URI:   http://www.harvard.edu/huit


Sean Turner
IECA, Inc.

EMail: turners@ieca.com
📦 where this page comes from