RFC 6982

RFC 6982: Improving Awareness of Running Code: The Implementation Status Section 💅✨

Okay bestie, here's the header tea 🫖. This is an Experimental RFC from July 2013 (ISSN 2070-1721), written by Y. Sheffer (Porticor) and A. Farrel (Juniper) for the IETF. Neither Obsoletes nor Updates appears anywhere in its header, so it doesn't replace or patch any other RFC 🌸

Abstract 🎀

Okay, so this doc gives authors of Internet-Drafts a simple way to list the status of known implementations, using a section called Implementation Status. Reviewers and working groups can then give proper weight to drafts that have running code, which is basically proof that someone tested the idea and gave feedback that made the protocol more mature 🔥

The process here is an experiment 🧪 Authors are encouraged to try it, and working groups are invited to think about using it for all their protocol specs. The authors plan to collect what happens and share it with the community 🫶

Status of This Memo 📜

This one is NOT an Internet Standards Track spec, bestie 🙈 It's published so people can look at it, try implementing it, and evaluate it.

It defines an Experimental Protocol for the Internet community ✨ It's an IETF product, it reflects IETF consensus, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, though. See Section 2 of RFC 5741 for the details 💅

For the latest status, errata, and feedback info, check http://www.rfc-editor.org/info/rfc6982 🦋

Copyright Notice 🧾

Legal text has to be exact, so here it is untouched:

Copyright (c) 2013 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 of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  The "Implementation Status" Section . . . . . . . . . . . . .   4
2.1.  Introductory Text . . . . . . . . . . . . . . . . . . . . .   5
3.  Alternative Formats . . . . . . . . . . . . . . . . . . . . .   6
4.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
5.  Process Experiment  . . . . . . . . . . . . . . . . . . . . .   7
5.1.  Duration  . . . . . . . . . . . . . . . . . . . . . . . . .   7
5.2.  Summary Report  . . . . . . . . . . . . . . . . . . . . . .   8
5.3.  Success Criteria  . . . . . . . . . . . . . . . . . . . . .   8
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
8.  Informative References  . . . . . . . . . . . . . . . . . . .   9

1. Introduction 🦋

Most IETF folks know the saying "rough consensus and running code" [Tao], and they vibe with its pragmatic energy 💖 But implementation is NOT required before an RFC gets published. Plenty of Internet-Drafts with protocol specs became Proposed Standard RFCs without anyone implementing them, and some of those may never get implemented at all 😭

Policies have shifted over time. In the Routing Area, one or more implementations used to be required before an Internet-Draft could become a Proposed Standard RFC [RFC1264]. That RFC was later obsoleted and the implementation requirement was dropped. Each working group got to set its own implementation rules instead [RFC4794], and at least one group, Inter-Domain Routing (IDR), still requires two independent implementations 👑

The core hypothesis here is that building implementations of protocol specs before they become RFCs is genuinely worth it 🧚 Those benefits include finding out the spec is understandable and that people actually want to implement it. Section 4 gets into this more ✨

This doc describes a simple mechanism: authors of Internet-Drafts can record and publicize implementation status by including an Implementation Status section 🎀 The doc sets out (pretty informally) what goes in that section so the important info actually gets included. That lets reviewers and working groups give proper consideration to drafts with running code, which is evidence of valuable experimentation and feedback that made the protocols more mature 💜

Working groups get to decide how to use this info. One possible result is that documents get treated preferentially and move through processing faster 🚀 The authors recommend removing the Implementation Status section from Internet-Drafts before they're published as RFCs. Because of that, no changes are expected to this section after the document is approved for publication. For example, the RFC errata process does not apply to it 🙈

The process is an experiment, though not an [RFC3933] experiment; see Section 5 for why. Authors are encouraged to try it, and working groups are invited to think about applying it to all their protocol specs 🌈

The experiment covers all Internet-Drafts (I-Ds) with implementable specifications, whether they came out of IETF working groups or outside them but are meant for IETF consensus. I-Ds on the Independent Stream are explicitly out of scope 🙅‍♀️ The biggest payoff is expected with Standards Track documents developed inside working groups 💅

Last bit: the authors plan to collate experiences from this experiment and report them to the community 🫶

2. The "Implementation Status" Section 🧁

Each Internet-Draft may include a section called "Implementation Status" 🎀 If it's there, it should sit right before the "Security Considerations" section. For each existing implementation, it can contain some or all of the following:

• The organization responsible for the implementation, if any.
• The implementation's name and/or a link to a web page describing the implementation.
• 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 and which versions of the Internet-Draft were 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 section can also cover 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 doesn't become a marketing venue for specific implementations 📣🚫

Since this info is time-dependent, it doesn't belong in a published RFC 🕰️ Authors should add a note to the RFC Editor asking them to remove the section before publication ✨

2.1. Introductory Text 🌸

Here's the proposed boilerplate to open the Implementation Status section. It's kept verbatim in a code block:

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
6982.  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 6982, "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 should also put a note at the very top of this section for the RFC Editor 📝 It should tell the Editor to remove the entire section before publication, and to remove the reference to RFC 6982 too ✨

Part 1 wraps here. Part 2 picks up with Section 3 (Alternative Formats) 🧚💜

4. Benefits ✨

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

• Working group members, chairs, and ADs can use the info to help decide which I-Ds to push forward first 🚀, like when there are a few competing proposals that try to solve the same problem 🥊
• It also helps when deciding whether a doc should move on a different track 🛤️ (individual submission, Experimental, etc.) 🧪
• Making this info public and a real part of WG discussions will motivate people to actually implement protocol proposals 🙌, and that's how protocol flaws get caught early 🕵️‍♀️🔍
• Other participants can run the software to check how useful a feature is, how correct it is (to some degree) ✅, and other stuff like resilience and scalability 📈
• WG members might do interoperability testing with known implementations, especially when they're publicly available 🤝
• If the implementation is open source, people may want to read the code 👀 to understand the protocol and its limitations 🧩, figure out whether the implementation matches the protocol spec 📋, and spot whether the spec has omissions or ambiguities 🫣
• And lastly, some features are super hard to understand 🤯, and for those, just knowing they CAN be implemented is already a huge win 🏆. BUT, we note that code should NEVER be used in lieu of a clear specification 🚫📜

We do not specify here whether, or to what degree, working groups are expected to prefer proposals that have "running code" attached to them over ones that don't 🏃‍♀️💨. That part's left up to y'all 💜.

5. Process Experiment 🧪🎀

The current proposal is an experiment 🔬. Putting Implementation Status sections in Internet-Drafts is not mandatory 🙅‍♀️, but the authors really want other I-D authors to try this simple mechanism and see if it's useful 🥰. WG chairs are invited to suggest it to doc editors in their groups, and to point their participants toward any Implementation Status sections that exist 📣.

After a community discussion, it was concluded that [RFC3933] is not an appropriate framework for this experiment 🙅‍♀️, mainly because no change is required to any existing process 🤷‍♀️.

5.1. Duration ⏳

Given how long it typically takes to produce an RFC (see [Stats]) 📆, we propose an 18-month duration for the experiment 🌸. So 18 months after this document is published as an RFC, the authors will report on the experiment as described in the next section 📝.

I-D authors are obviously free to keep including Implementation Status sections in their docs even after the experiment wraps up 💖.

5.2. Summary Report 📊

The authors will summarize the results at the end of the period assigned to the experiment (see Section 5.1) 🗓️. If nothing happens (no I-Ds, or only a handful, include an Implementation Status section) 😬, an email to the IETF list will be sufficient 📧. That would obviously count as a failure to adopt the idea 💀, and the authors will abandon the experiment 🪦.

If document authors adopt the idea 🎉, a summary I-D will be written with the stats on how much it was adopted 📈, plus (necessarily subjective) reports from WG members, chairs, and area directors who used the mechanism 🗣️.

The authors may then propose more wide-scale use of the process 🌍, and might suggest more formal adoption of it by the IETF 👑.

5.3. Success Criteria 🏆

The goal of this experiment is to improve the quality of IETF specifications ✨. This is impossible to quantify, of course 🙈. We suggest that generally positive answers to the following questions would indicate the experiment was successful 🌈:

• Did the working group make more informed decisions when comparing multiple competing solutions for the same work item 🧠?
• Did authors significantly modify proposed protocols based on implementation experience 🛠️?
• Did disclosing implementations encourage more interoperability testing than before 🤝?
• Did non-authors review documents based on interactions with running code and/or by inspecting the code itself 🔎?

6. Security Considerations 🔐

This is a process document 📋, so it doesn't have a direct effect on the security of any particular IETF protocol 🙅‍♀️. However, better-reviewed protocols are likely to also be more secure 🛡️💜.

7. Acknowledgements 🫶

We would like to thank Stephen Farrell, who reawakened community interest in this topic 👏. Several reviewers provided important input, including Loa Andersson, Dave Crocker, Ned Freed, Christer Holmberg, Denis Ovsienko, and Curtis Villamizar 💖🌸.

This document was originally prepared using the lyx2rfc tool 🛠️, and we would like to thank Nico Williams, its author 🙌.

8. Informative References 📚

[RFC1264]  Hinden, R., "Internet Engineering Task Force Internet
           Routing Protocol Standardization Criteria", RFC 1264,
           October 1991.

[RFC3933]  Klensin, J. and S. Dawkins, "A Model for IETF Process
           Experiments", BCP 93, RFC 3933, November 2004.

[RFC4794]  Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, December
           2006.

[Stats]    Arkko, J., "Distribution of Processing Times", December
           2012, <http://www.arkko.com/tools/lifecycle/wgdistr.html>.

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

Authors' Addresses 💌

Yaron Sheffer
Porticor

EMail: yaronf.ietf@gmail.com


Adrian Farrel
Juniper Networks

EMail: adrian@olddog.co.uk