One document matched: draft-petithuguenin-running-code-considerations-00.txt
Network Working Group M. Petit-Huguenin
Internet-Draft (Unaffiliated)
Intended status: BCP H. Sinnreich
Expires: September 4, 2009 Adobe
March 3, 2009
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
Petit-Huguenin & Sinnreich Expires September 4, 2009 [Page 1]
Internet-Draft Running Code March 2009
measurements.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Content of the Running Code Considerations Section . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Running Code Considerations . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 6
A.1. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Petit-Huguenin & Sinnreich Expires September 4, 2009 [Page 2]
Internet-Draft Running Code March 2009
1. Introduction
One of the motto of the IETF is "We believe in rough consensus and
running code" [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 [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
Petit-Huguenin & Sinnreich Expires September 4, 2009 [Page 3]
Internet-Draft Running Code March 2009
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].
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.
Petit-Huguenin & Sinnreich Expires September 4, 2009 [Page 4]
Internet-Draft Running Code March 2009
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
o idnits code modified to verify the presence of a Running Code
Consideration Section [1]. Marc Petit-Huguenin
<petithug@acm.org>. Implements version -00.
7. Acknowledgements
This document was written with the xml2rfc tool described in
[RFC2629].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
Guide to the Internet Engineering Task Force", RFC 4677,
September 2006.
URIs
Petit-Huguenin & Sinnreich Expires September 4, 2009 [Page 5]
Internet-Draft Running Code March 2009
[1] <http://ietf.implementers.org/idnits-2.11.05a.tgz>
Appendix A. Release notes
This section must be removed before publication as an RFC.
A.1. TODO List
(Empty)
Authors' Addresses
Marc Petit-Huguenin
(Unaffiliated)
Email: petithug@acm.org
Henry Sinnreich
Adobe
Email: henrys@adobe.com
Petit-Huguenin & Sinnreich Expires September 4, 2009 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:40 |