Running Code Considerations Section in RFCs
(Unaffiliated)
petithug@acm.org
Adobe
henrys@adobe.com
This document provides guidelines to IETF authors on the text that must be included in documents to reference running code and measurements.
One of the motto of the IETF is "We believe in rough consensus and running code".
It is difficult to evaluate a protocol under development in a series of Internet-Draft documents without been able to verify the existence and conformance of the running code developed for this protocol.
This document describes how the references to such running code must be documented during the lifetime of an Internet-Draft.
Been able to have access to running code during the development of a protocol is important for multiple reasons.
First of all an existing implementation proves that the protocol is implementable but because code can be considered as a formal description of a protocol, it is also useful to detect early any design flaws.
A second major reason for running code is to assess the interest in and validity of a new protocol.
A protocol that will never be implemented is a waste of IETF resources.
An Internet-Draft that cannot collect at least two independent implementations after few iterations should be abandoned if no more interest can be found.
The "running" part in "running code" means that the code must be complete and executable, so a code snippet does not fulfill the requirement for running code.
The "code" part must be understood as source code, as binary code is useless to evaluate the difficulties created when implementing the protocol.
Note that this does not mean that the code source must be available under a free or open source license.
The minimum rights that should be granted for this source code are the right to duplicate it for purpose of reading it and the right to execute it or generate the binary code to execute it.
Other rights, like the right to integrate it as part of another software or distribute modified versions can be useful but are not needed for the purpose of evaluating the protocol.
The development of SIP provides useful examples and the incentive to write this memo.
There is a wealth of published code for SIP servers and SIP User Agents and this explains in large part the success of SIP.
On the other hand, more complex aspects of SIP networks, such as routing between numerous servers and other network elements and NAT traversal have not been backed up by public available routing code.
This has caused very large numbers of I-D revisions and sheer endless discussions between experts in the IETF.
Some of these discussions have not been concluded as of this writing, due to the lack of available code to inspect and the lack of measurements to prove the assumptions.
New protocols that have performance implications or protocol extensions aimed at improvements of performance or where competing protocols already exist must also be accompanied by a discussion of the metrics for performance and measurements that prove the performance of the protocol.
Writing and maintaining running code during the development of a new protocol is a difficult task so code authors and eventual sponsors must be clearly cited in all the versions of the document as a way to recognize their contribution.
Even if the code is no longer maintained and compatible with subsequent versions of the document, its authors and sponsors must still be acknowledged in the Running Code Considerations section for the whole lifetime of the document.
Note that there is no compatibility guaranteed between two versions of an Internet-Draft.
Even with early implementations, Internet-Draft authors should not hesitate to break compability if it improves the protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
The "Running Code Considerations" section MUST be present in all Internet-Draft and SHOULD be inserted after the Security Considerations and IANA Considerations sections.
This section MUST be present even if the document does not describe an implementable protocol and should contain in this case a text explaining why this section is irrelevant.
The RFC Editor can remove this "Running Code Considerations" section before publication as RFC.
The "Running Code Considerations" section MUST contain the list of all protocol implementations starting with the oldest, with the author(s) and eventually sponsor(s) names, the URL to where the source code can be retrieved and the version(s) of the document that this code implements.
In the case a specific code implements multiple versions of the document, the URL MUST point to the latest version available but the text MUST contain the complete list of versions supported.
Adding a Running Code Considerations section does not increase the security risks in a protocol but can help to detect security issues early in the development cycle of this protocol.
There are no IANA considerations.
idnits code modified to verify the presence of a Running Code Consideration Section.
Marc Petit-Huguenin <petithug@acm.org>.
Implements version -00.
This document was written with the xml2rfc tool described in .
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Writing I-Ds and RFCs using XML
Invisible Worlds, Inc.
660 York Street
San Francisco
CA
94110
US
+1 415 695 3975
mrose@not.invisible.net
http://invisible.net/
General
RFC
Request for Comments
I-D
Internet-Draft
XML
Extensible Markup Language
This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.
SIP: Session Initiation Protocol
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK]
The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force
This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. This memo provides information for the Internet community.
This section must be removed before publication as an RFC.