Running Code Considerations Section in RFCs

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 "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.