Running Code Considerations Section in RFCs
draft-petithuguenin-running-code-considerations-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 4, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document provides guidelines to IETF authors on the text that must be included in documents to reference running code and measurements.

Table of Contents

1.  Introduction
2.  Terminology
3.  Content of the Running Code Considerations Section
4.  Security Considerations
5.  IANA Considerations
6.  Running Code Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Release notes
    A.1.  TODO List
§  Authors' Addresses

1.  Introduction

One of the motto of the IETF is "We believe in rough consensus and running code" (Hoffman, P. and S. Harris, “The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force,” September 2006.) [RFC4677]. 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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] 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.

2.  Terminology

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Content of the Running Code Considerations Section

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.

4.  Security Considerations

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.

5.  IANA Considerations

There are no IANA considerations.

6.  Running Code Considerations

• idnits code modified to verify the presence of a Running Code Consideration Section. Marc Petit-Huguenin <petithug@acm.org>. Implements version -00.

7.  Acknowledgements

This document was written with the xml2rfc tool described in [RFC2629] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.).

8.  References

8.1. Normative References

8.2. Informative References

Appendix A.  Release notes

This section must be removed before publication as an RFC.

A.1.  TODO List

(Empty)

Authors' Addresses