summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7942.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7942.txt')
-rw-r--r--doc/rfc/rfc7942.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc7942.txt b/doc/rfc/rfc7942.txt
new file mode 100644
index 0000000..4243639
--- /dev/null
+++ b/doc/rfc/rfc7942.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Y. Sheffer
+Request for Comments: 7942 Intuit
+BCP: 205 A. Farrel
+Obsoletes: 6982 Juniper Networks
+Category: Best Current Practice July 2016
+ISSN: 2070-1721
+
+
+ Improving Awareness of Running Code: The Implementation Status Section
+
+Abstract
+
+ This document describes a simple process that allows authors of
+ Internet-Drafts to record the status of known implementations by
+ including an Implementation Status section. 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.
+
+ This process is not mandatory. Authors of Internet-Drafts are
+ encouraged to consider using the process for their documents, and
+ working groups are invited to think about applying the process to all
+ of their protocol specifications. This document obsoletes RFC 6982,
+ advancing it to a Best Current Practice.
+
+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 has been approved for publication by the Internet
+ Engineering Steering Group (IESG). Further information on BCPs is
+ available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7942.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer & Farrel Best Current Practice [Page 1]
+
+RFC 7942 Running Code July 2016
+
+
+Copyright Notice
+
+ 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
+ (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 . . . . . . . . . . . . . . . . . . . . . . . . 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 participants are familiar with the saying "rough consensus
+ and running code" [Tao] and can identify with its pragmatic approach.
+ However, implementation is not a requirement for publication as an
+ RFC. There are many examples of Internet-Drafts containing protocol
+ specifications that have gone through to publication as Proposed
+ Standard RFCs without implementation. Some of them may never get
+ implemented.
+
+ Over time, a variety of policies have been applied within the IETF to
+ consider running code. In the Routing Area, it used to be a
+ requirement that one or more implementations must exist before an
+ Internet-Draft could be published as a Proposed Standard RFC
+ [RFC1264]. That RFC was later obsoleted and the requirement for
+ implementation was lifted, but each working group was given the
+ authority to impose its own implementation requirements [RFC4794] and
+ at least one working group, Inter-Domain Routing (IDR), continues to
+ require two independent implementations.
+
+
+
+
+
+Sheffer & Farrel Best Current Practice [Page 2]
+
+RFC 7942 Running Code July 2016
+
+
+ The hypothesis behind the current document is that there are benefits
+ to the IETF standardization process of producing implementations of
+ protocol specifications before publication as RFCs. These benefits,
+ which include determining that the specification is comprehensible
+ and that there is sufficient interest to implement, are further
+ discussed in Section 4.
+
+ This document describes a simple mechanism that allows authors of
+ Internet-Drafts to record and publicize the status of known
+ implementations by including an Implementation Status section. The
+ document defines (quite informally) the contents of this section to
+ ensure that the relevant information is included. 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, but one result might be the preferential treatment of
+ documents, resulting in them being processed more rapidly. We
+ recommend that the Implementation Status section should be removed
+ from Internet-Drafts before they are published as RFCs. As a result,
+ we do not envisage changes to this section after approval of the
+ document for publication, e.g., the RFC errata process does not
+ apply.
+
+ This process is not mandatory. Authors of Internet-Drafts are
+ encouraged to consider using the process for their documents, and
+ working groups are invited to think about applying the process to all
+ of their protocol specifications.
+
+ The scope of this process is all Internet-Drafts (I-Ds) that contain
+ implementable specifications, whether produced within IETF working
+ groups or outside working groups but intended for IETF consensus.
+ I-Ds published on the Independent Stream are explicitly out of scope.
+ It is expected that the greatest benefit will be seen with Standards
+ Track documents developed within working groups.
+
+ This process was initially proposed as an experiment in [RFC6982].
+ That document is now obsoleted, and the process advanced to Best
+ Current Practice.
+
+ Historically, there have been other ways for experience based on
+ protocol implementations to feed back into the IETF process. Many
+ "implementation reports" have been published, in some cases several
+ years after the protocol was originally published. Providing
+
+
+
+
+
+Sheffer & Farrel Best Current Practice [Page 3]
+
+RFC 7942 Running Code July 2016
+
+
+ feedback to published protocols is a related goal, but different from
+ the current document's focus. Two notable examples of published
+ implementation reports are [RFC1369] and [RFC5080].
+
+2. The "Implementation Status" Section
+
+ Each Internet-Draft may contain a section entitled "Implementation
+ Status". This section, if it appears, should be located just before
+ the "Security Considerations" section and contain, for each existing
+ implementation, 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 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: what version/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.
+
+ In addition, this section can contain information about the
+ interoperability of any or all of the implementations, including
+ references to test-case descriptions and interoperability reports,
+ when such exist.
+
+
+
+
+
+Sheffer & Farrel Best Current Practice [Page 4]
+
+RFC 7942 Running Code July 2016
+
+
+ Working group chairs and area directors (ADs) are requested to ensure
+ that this section is not used as a marketing venue for specific
+ implementations.
+
+ Since this information is necessarily time dependent, it is
+ inappropriate for inclusion in a published RFC. The authors should
+ include a note to the RFC Editor requesting that the section be
+ removed before publication.
+
+2.1. Introductory Text
+
+ The following boilerplate text is proposed to head the Implementation
+ Status section:
+
+ 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 requested to add a note to the RFC Editor at the top of
+ this section, advising the Editor to remove the entire section before
+ publication, as well as the reference to RFC 7942.
+
+3. Alternative Formats
+
+ Sometimes it can be advantageous to publish the implementation status
+ separately from the base Internet-Draft, e.g., on the IETF wiki:
+
+ - When the Implementation Status section becomes too large to be
+ conveniently managed within the document.
+
+ - When a working group decides to have implementors, rather than
+ authors, keep the status of their implementations current.
+
+
+
+Sheffer & Farrel Best Current Practice [Page 5]
+
+RFC 7942 Running Code July 2016
+
+
+ - When a working group already maintains an active wiki and prefers
+ to use it for this purpose.
+
+ - If the working group decides that the information is still
+ valuable (and needs to be kept current) after the I-D is published
+ as an RFC, and the Implementation Status section had been removed
+ from it.
+
+ It is highly desirable for all readers of the Internet-Draft to be
+ made aware of this information. Initially, this can be done by
+ replacing the Implementation Status section's contents with a URL
+ pointing to the wiki. Later, the IETF Tools may support this
+ functionality, e.g., by including such a link in the HTML file of the
+ document, similar to the IPR link.
+
+ If the implementation status is published separately from the I-D,
+ then this information needs to be openly available without requiring
+ authentication, registration, or access controls if it is to have any
+ useful effects.
+
+4. Benefits
+
+ Publishing the information about implementations provides the working
+ group with several benefits:
+
+ - Working group members, chairs, and ADs may use the information
+ provided to help prioritize the progress of I-Ds, e.g., when there
+ are several competing proposals to solve a particular problem.
+
+ - Similarly, the information is useful when deciding whether the
+ document should be progressed on a different track (individual
+ submission, Experimental, etc.).
+
+ - Making this information public and an explicit part of WG
+ deliberations will motivate participants to implement protocol
+ proposals, which in turn helps in discovering protocol flaws at an
+ early stage.
+
+ - Other participants can use the software to evaluate the usefulness
+ of protocol features, its correctness (to some degree), and other
+ properties, such as resilience and scalability.
+
+ - WG members may choose to perform interoperability testing with
+ known implementations, especially when they are publicly
+ available.
+
+
+
+
+
+
+Sheffer & Farrel Best Current Practice [Page 6]
+
+RFC 7942 Running Code July 2016
+
+
+ - In the case of open source, people may want to study the code to
+ better understand the protocol and its limitations, determine if
+ the implementation matches the protocol specification, and whether
+ the protocol specification has omissions or ambiguities.
+
+ - And lastly, some protocol features may be hard to understand, and
+ for such features, the mere assurance that they can be implemented
+ is beneficial. We note though that code should never be used in
+ lieu of a clear specification.
+
+ We do not specify here whether and to what degree working groups are
+ expected to prefer proposals that have "running code" associated with
+ them, over others that do not.
+
+ Working group chairs are invited to suggest this mechanism to
+ document editors in their working groups, and to draw the attention
+ of their working group participants to Implementation Status sections
+ where they exist.
+
+5. Security Considerations
+
+ This is a process document; therefore, it does not have a direct
+ effect on the security of any particular IETF protocol. However,
+ better-reviewed protocols are likely to also be more secure.
+
+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>.
+
+
+
+
+
+
+Sheffer & Farrel Best Current Practice [Page 7]
+
+RFC 7942 Running Code July 2016
+
+
+ [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 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, Joel M. Halpern,
+ 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.
+
+Authors' Addresses
+
+ Yaron Sheffer
+ Intuit
+
+ Email: yaronf.ietf@gmail.com
+
+
+ Adrian Farrel
+ Juniper Networks
+
+ Email: adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer & Farrel Best Current Practice [Page 8]
+