RFC 7942

Improving Awareness of Running Code: The Implementation Status Section

📅 published July 2016, from ietf

Improving Awareness of Running Code: The Implementation Status Section 💖

Okay bestie, this is RFC 7942 🎀, a doc from the Internet Engineering Task Force (IETF) that came out in July 2016 (ISSN 2070-1721). It's a Best Current Practice 💅 and it's labelled BCP 205. The two authors are Y. Sheffer from Intuit and A. Farrel from Juniper Networks 🧚. It obsoletes RFC 6982, which was the earlier experiment that got promoted up to BCP status 🦋. The header doesn't list any Updates, so nothing else is being changed.

Abstract ✨

Okay so this doc describes a super simple process that lets Internet-Draft authors record the status of the implementations they know about by adding a section called Implementation Status 📝. Why? So that reviewers and working groups can give proper consideration to docs that have running code 🏃‍♀️. Running code is real evidence of experimentation and feedback, and it's what makes protocols more mature 🌸.

This process is not mandatory 🫶. Authors of Internet-Drafts are encouraged to think about using it, and working groups are invited to consider applying it to all of their protocol specs. And again, this doc obsoletes RFC 6982 and advances it to a Best Current Practice 👑.

Status of This Memo 🌈

This memo documents an Internet Best Current Practice, so it's an official BCP, not just vibes 💜.

It's a product of the IETF and it was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, go check Section 2 of RFC 7841 🍓.

For the current status of this document, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7942 🔗.

Copyright (c) 2016 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, which you can find at http://trustee.ietf.org/license-info as they were on the publication date. Please actually read these, because they spell out your rights and restrictions 🙈. Code Components pulled out of 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 the Simplified BSD License describes 📜.

Table of Contents 🧾

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  The "Implementation Status" Section . . . . . . . . . . . . .   4
       2.1.  Introductory Text . . . . . . . . . . . . . . . . . . . .   5
     3.  Alternative Formats . . . . . . . . . . . . . . . . . . . . .   5
     4.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction 🦋

Most IETF people know the saying "rough consensus and running code" [Tao] and vibe with its practical energy 💖. Still, implementation is not a requirement for publication as an RFC 😭. Plenty of Internet-Drafts with protocol specs have gone all the way to publication as Proposed Standard RFCs without ever being implemented, and some of those may never get implemented at all 💀.

Over time, the IETF has tried a bunch of different policies around running code 🔁. In the Routing Area, it used to be required that one or more implementations exist before an Internet-Draft could be published as a Proposed Standard RFC [RFC1264]. That RFC was later obsoleted and the implementation requirement was lifted, but each working group got the power to set its own implementation requirements [RFC4794]. At least one working group, Inter-Domain Routing (IDR), still requires two independent implementations 👑.

The big idea behind this doc is that producing implementations of protocol specs before they're published as RFCs is good for the standardization process 🧚. Those benefits include finding out that the spec is comprehensible and that there's enough interest to actually implement it. Section 4 gets into these more ✨.

This doc describes a simple mechanism that lets Internet-Draft authors record and publicize the status of known implementations by adding an Implementation Status section 📝. It defines the contents of that section pretty informally, so the relevant info actually gets included. This lets reviewers and working groups give due consideration to docs with running code, which can be real evidence of valuable experimentation and feedback that made the protocols more mature 🌸.

It's up to each working group how to use this info, but one result could be that documents get preferential treatment and move through processing faster 🏃‍♀️. We recommend that the Implementation Status section be removed from Internet-Drafts before they're published as RFCs 🗑️. Because of that, we don't expect this section to change after the document is approved for publication, so the RFC errata process doesn't apply to it 🙅‍♀️.

This process is not mandatory, again 🫶. Authors of Internet-Drafts are encouraged to consider using it, and working groups are invited to think about applying it to all of their protocol specs.

The scope is all Internet-Drafts (I-Ds) that contain implementable specifications, whether they were produced inside IETF working groups or outside them but intended for IETF consensus 🌈. I-Ds published on the Independent Stream are explicitly out of scope, so don't come for them 🚫. The biggest payoff is expected with Standards Track documents developed inside working groups 👑.

This process started out as an experiment in [RFC6982] 🧪. That doc is now obsoleted, and the process has been advanced to Best Current Practice 💅.

Historically there have been other ways for protocol implementation experience to feed back into the IETF process 📚. Lots of "implementation reports" have been published, sometimes several years after the protocol first came out. Giving feedback on already-published protocols is a related goal, but it's different from what this doc is focused on 🙈. Two famous examples of published implementation reports are [RFC1369] and [RFC5080] 🍓.

2. The "Implementation Status" Section 💜

Each Internet-Draft may contain a section called "Implementation Status" 📝. If it shows up, it should sit right before the "Security Considerations" section 🧚. For each existing implementation, it should contain some or all of the following:

  • The organization responsible for the implementation, if there is one 🏢.
  • The implementation's name and/or a link to a web page where the implementation, or a description of it, can be found 🔗.
  • A brief general description ✨.
  • The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc. 🌱.
  • Coverage: which parts of the protocol specification are implemented 🧩.
  • Version compatibility: which version or versions of the Internet-Draft are known to be implemented 🔖.
  • Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify) ⚖️.
  • Implementation experience: any useful information the implementers want to share with the community 💬.
  • Contact information: ideally a person's name and email address, but possibly just a URL or mailing list 📬.
  • The date when information about this particular implementation was last updated 📅.

The section can also include info about the interoperability of any or all of the implementations, including references to test-case descriptions and interoperability reports, when those exist 🤝.

Working group chairs and area directors (ADs) are asked to make sure this section is not used as a marketing venue for specific implementations 🙅‍♀️. No ads in the Implementation Status section, periodt 💅.

Since this info is time dependent by nature, it's inappropriate for a published RFC ⏰. Authors should add a note to the RFC Editor asking for the section to be removed before publication 📮.

2.1. Introductory Text 🎀

The following boilerplate text is proposed to head the Implementation Status section 📋. Copy it exactly:

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of
   this Internet-Draft, and is based on a proposal described in
   RFC 7942.  The description of implementations in this section is
   intended to assist the IETF in its decision processes in
   progressing drafts to RFCs.  Please note that the listing of any
   individual implementation here does not imply endorsement by the
   IETF.  Furthermore, no effort has been spent to verify the
   information presented here that was supplied by IETF contributors.
   This is not intended as, and must not be construed to be, a
   catalog of available implementations or their features.  Readers
   are advised to note that other implementations may exist.

   According to RFC 7942, "this will allow reviewers and working
   groups to assign due consideration to documents that have the
   benefit of running code, which may serve as evidence of valuable
   experimentation and feedback that have made the implemented
   protocols more mature.  It is up to the individual working groups
   to use this information as they see fit".

Authors are asked to add a note to the RFC Editor at the top of this section 📝, telling the Editor to remove the entire section before publication, along with the reference to RFC 7942 💖.

4. Benefits ✨

okay so publishing this info about implementations gives the working group a bunch of perks, bestie 🫶

  • Working group members, chairs, and ADs can use the info to help prioritize which I-Ds move forward 📋, like when there are a few competing proposals trying to solve the same problem.
  • It's also super useful when deciding whether a document should be progressed on a different track 🛤️, like individual submission, Experimental, etc.
  • Making this info public and a real part of WG deliberations is lowkey iconic 👑, because it motivates people to actually implement protocol proposals, and that helps catch protocol flaws early 🔍.
  • Other participants can run the software to check how useful a protocol feature is, whether it's correct (to some degree) 🧪, and other stuff like resilience and scalability 💪.
  • WG members can choose to do interoperability testing against known implementations 🤝, especially when those implementations are publicly available.
  • If it's open source, people can study the code to get a better grip on the protocol and its limitations 🧠, check whether the implementation matches the protocol spec, and see if the spec has gaps or fuzzy bits 👀.
  • And lastly, some protocol features are hard to wrap your head around 🤯, and for those, just knowing they can be implemented is a whole win. Just note though, code is never a replacement for a clear specification 💅.

We aren't saying here whether, or how much, working groups should prefer proposals that come with "running code" 🏃‍♀️ over ones that don't. That's a vibe check for each group to do on their own.

Working group chairs are encouraged to pitch this mechanism to their document editors 📣, and to point their participants toward any Implementation Status sections that exist 🎀.

5. Security Considerations 🔐

This is a process document, so it doesn't directly affect the security of any particular IETF protocol 🙅‍♀️. That said, better-reviewed protocols are likely to be more secure too 💖. Reviewing is the bestie of security, no cap ✨.

6. Informative References 📚

[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, DOI 10.17487/RFC1264, October 1991, http://www.rfc-editor.org/info/rfc1264.

[RFC1369] Kastenholz, F., "Implementation Notes and Experience for the Internet Ethernet MIB", RFC 1369, DOI 10.17487/RFC1369, October 1992, http://www.rfc-editor.org/info/rfc1369.

[RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, DOI 10.17487/RFC4794, December 2006, http://www.rfc-editor.org/info/rfc4794.

[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, http://www.rfc-editor.org/info/rfc5080.

[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, http://www.rfc-editor.org/info/rfc6982.

[Tao] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", 2012, http://www.ietf.org/tao.html.

Acknowledgements 🫶

We want to thank Stephen Farrell, who revived community interest in this topic 🌈. Several reviewers gave important input, including Loa Andersson, Dave Crocker, Ned Freed, Joel M. Halpern, Christer Holmberg, Denis Ovsienko, and Curtis Villamizar 💜.

This document was originally prepared using the lyx2rfc tool, and we want to thank Nico Williams, its author 🧚.

Authors' Addresses 💌

Yaron Sheffer Intuit

Email: yaronf.ietf@gmail.com

Adrian Farrel Juniper Networks

Email: adrian@olddog.co.uk

📦 where this page comes from