Movatterモバイル変換

Internet Engineering Task Force (IETF)                        Y. ShefferRequest for Comments: 6982                                      PorticorCategory: Experimental                                         A. FarrelISSN: 2070-1721                                                  Juniper                                                               July 2013Improving Awareness of Running Code: The Implementation Status SectionAbstract   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, which may serve as evidence of   valuable experimentation and feedback that have 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 document is not an Internet Standards Track specification; it is   published for examination, experimental implementation, and   evaluation.   This document defines an Experimental Protocol for the Internet   community.  This document is a product of the Internet Engineering   Task Force (IETF).  It represents the consensus of the IETF   community.  It has received public review and has been approved for   publication by the Internet Engineering Steering Group (IESG).  Not   all documents approved by the IESG are a candidate for any level of   Internet Standard; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6982.Sheffer & Farrel              Experimental                      [Page 1]

RFC 6982                      Running Code                     July 2013Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .32.  The "Implementation Status" Section . . . . . . . . . . . . .42.1.  Introductory Text . . . . . . . . . . . . . . . . . . . . .53.  Alternative Formats . . . . . . . . . . . . . . . . . . . . .64.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .65.  Process Experiment  . . . . . . . . . . . . . . . . . . . . .75.1.  Duration  . . . . . . . . . . . . . . . . . . . . . . . . .75.2.  Summary Report  . . . . . . . . . . . . . . . . . . . . . .85.3.  Success Criteria  . . . . . . . . . . . . . . . . . . . . .86.  Security Considerations . . . . . . . . . . . . . . . . . . .87.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .88.  Informative References  . . . . . . . . . . . . . . . . . . .9Sheffer & Farrel              Experimental                      [Page 2]

RFC 6982                      Running Code                     July 20131.  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, Inter-Domain Routing (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 inSection 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, which may serve as evidence of   valuable experimentation and feedback that have 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.Sheffer & Farrel              Experimental                      [Page 3]

RFC 6982                      Running Code                     July 2013   The process in this document is offered as an experiment (though not   as an [RFC3933] experiment; seeSection 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 (I-Ds)   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:   o  The organization responsible for the implementation, if any.   o  The implementation's name and/or a link to a web page describing      the implementation.   o  A brief general description.   o  The implementation's level of maturity: research, prototype,      alpha, beta, production, widely used, etc.   o  Coverage: which parts of the protocol specification are      implemented and which versions of the Internet-Draft were      implemented.   o  Licensing: the terms under which the implementation can be used.      For example: proprietary, royalty licensing, freely distributable      with acknowledgement (BSD style), freely distributable with      requirement to redistribute source (General Public License (GPL)      style), and other (specify).   o  Implementation experience: any useful information the implementers      want to share with the community.Sheffer & Farrel              Experimental                      [Page 4]

RFC 6982                      Running Code                     July 2013   o  Contact information: ideally a person's name and email address,      but possibly just a URL or mailing list.   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 and area directors (ADs) 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 inRFC6982.  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 toRFC 6982, "this will allow reviewers and working      groups to assign due consideration to documents that have the      benefit of running code, which may serve as evidence of valuable      experimentation and feedback that have 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 toRFC 6982.Sheffer & Farrel              Experimental                      [Page 5]

RFC 6982                      Running Code                     July 20133.  Alternative Formats   Sometimes it can be advantageous to publish the implementation status   separately from the base Internet-Draft, e.g., on the IETF wiki:   o  When the Implementation Status section becomes too large to be      conveniently managed within the document.   o  When a working group decides to have implementors, rather than      authors, keep the status of their implementations current.   o  When a working group already maintains an active wiki and prefers      to use it for this purpose.   o  If the working group decides that the information is still      valuable (and needs to be kept current) after the I-D is published      as an RFC, and the Implementation Status section had been removed      from it.   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 in the HTML file of the   document, 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:   o  Working group members, chairs, and ADs may use the information      provided to help prioritize the progress of I-Ds, e.g., when there      are several competing proposals to solve a particular problem.   o  Similarly, the information is useful when deciding whether the      document should be progressed on a different track (individual      submission, Experimental, etc.).   o  Making this information public and an explicit part of WG      deliberations will motivate participants to implement protocol      proposals, which in turn helps in discovering protocol flaws at an      early stage.Sheffer & Farrel              Experimental                      [Page 6]

RFC 6982                      Running Code                     July 2013   o  Other participants can use the software to evaluate the usefulness      of protocol features, its correctness (to some degree), and other      properties, such as resilience and scalability.   o  WG members may choose to perform interoperability testing with      known implementations, especially when they are publicly      available.   o  In the case of open source, people may want to study the code to      better understand the protocol and its limitations, determine if      the implementation matches the protocol specification, and whether      the protocol specification has omissions or ambiguities.   o  And lastly, some protocol features may be hard to understand, and      for such features, the mere assurance that they can be implemented      is beneficial.  We note though that code should never be used in      lieu of a clear specification.   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.Sheffer & Farrel              Experimental                      [Page 7]

RFC 6982                      Running Code                     July 20135.2.  Summary Report   The authors will summarize the results of the experiment at the end   of the period assigned to the experiment (seeSection 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:   o  Did the working group make decisions that were more informed when      comparing multiple competing solutions for the same work item?   o  Did authors significantly modify proposed protocols based on      implementation experience?   o  Did disclosure of implementations encourage more interoperability      testing than previously?   o  Did non-authors review documents based on interactions with      running code and/or inspection of the code itself?6.  Security Considerations   This is a process document; 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.7.  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.Sheffer & Farrel              Experimental                      [Page 8]

RFC 6982                      Running Code                     July 2013   This document was originally prepared using the lyx2rfc tool, and we   would like to thank Nico Williams, its author.8.  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, <http://www.arkko.com/tools/lifecycle/wgdistr.html>.   [Tao]      Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to              the Internet Engineering Task Force", November 2012,              <http://www.ietf.org/tao.html>.Authors' Addresses   Yaron Sheffer   Porticor   EMail: yaronf.ietf@gmail.com   Adrian Farrel   Juniper Networks   EMail: adrian@olddog.co.ukSheffer & Farrel              Experimental                      [Page 9]