Network Working Group Y. Sheffer
Internet-Draft Porticor
Intended status: Experimental A. Farrel
Expires: December 04, 2013 Juniper
June 02, 2013

Improving Awareness of Running Code: the Implementation Status Section
draft-sheffer-running-code-06

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, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature.

The process in this document is offered as an experiment. 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 authors of this document intend to collate experiences with this experiment and to report them to the community.

Status of This Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on December 04, 2013.

Copyright Notice

Copyright (c) 2013 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

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 specification 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 (IDR) continues to require two independent implementations.

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, by considering the running code as evidence of valuable experimentation and feedback that has 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.

The process in this document is offered as an experiment (though not as an [RFC3933] experiment, see Section 5). 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 the intended experiment is all Internet-Drafts 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 in the experiment will be seen with Standards Track documents developed within working groups.

The authors of this document intend to collate experiences with this experiment and to report them to the community.

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:

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.

Working group chairs 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 Editor: replace by a reference to this document]. 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 Editor: replace by a reference to this document], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has 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 Editor: replace by a reference to this document].

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:

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 from the HTMLized draft version, 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:

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.

5. Process Experiment

The current proposal is proposed as an experiment. The inclusion of "Implementation Status" sections in Internet-Drafts is not mandatory, but the authors of this document wish to encourage authors of other Internet-Drafts to try out this simple mechanism to discover whether it is useful. 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.

Following a community discussion, it was concluded that [RFC3933] is not an appropriate framework for this experiment, primarily because no change is required to any existing process.

5.1. Duration

Given the typical time to produce an RFC (see [Stats]), we propose a duration of 18 months for the experiment. Thus, 18 months after the date of publication of this document as an RFC, the authors will report on the experiment as described in the next section.

I-D authors are obviously free to include Implementation Status sections in their documents even after the experiment has concluded.

5.2. Summary Report

The authors will summarize the results of the experiment at the end of the period assigned to the experiment (see Section 5.1). If nothing happens (no I-Ds or only a handful include an "Implementation Status" section), an email to the IETF list will be sufficient. This would obviously constitute a failure to adopt the idea and the authors will abandon the experiment.

If this idea is adopted by document authors, a summary I-D will be written containing the statistics of such adoption, as well as (necessarily subjective) reports by working group members, chairs and area directors who have used this mechanism.

The authors may then propose more wide-scale use of the process and might suggest more formal adoption of the process by the IETF.

5.3. Success Criteria

The goal of this experiment is to improve the quality of IETF specifications. This is impossible to quantify, of course. We suggest that generally positive answers to the following questions would indicate that the experiment was successful:

6. Implementation Status

[Note to RFC Editor: please remove this entire section before publication.]

This is a process document and therefore does not have any meaningful implementation status. “Implementation” in the context of this document means actual program code.

6.1. Current Drafts Using This Guidance

As of this writing, the following drafts include an Implementation Status section, citing the current draft: draft-clausen-lln-loadng, draft-ovsienko-babel-hmac-authentication, draft-wilde-xml-patch, draft-ietf-mpls-multipath-use.

7. Security Considerations

This is a process document and 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.

8. IANA Considerations

None.

9. 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, Christer Holmberg, Denis Ovsienko, and Curtis Villamizar.

This document was prepared using the lyx2rfc tool, and we would like to thank Nico Williams, its author.

10. Informative References

[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004.
[RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, December 2006.
[Stats] Arkko, J., "Distribution of Processing Times", December 2012.
[Tao] Hoffman, P., ""The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", 2012.

Authors' Addresses

Yaron Sheffer Porticor 10 Yirmiyahu St. Ramat HaSharon, 47298 Israel EMail: yaronf.ietf@gmail.com
Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk