Network Working Group Y. Sheffer Internet-Draft Porticor Intended status: Experimental December 7, 2012 Expires: June 10, 2013 Improving "Rough Consensus" with Running Code draft-sheffer-running-code-00 Abstract This document proposes a simple-to-implement solution to the problem of rewarding Internet protocols that have been implemented over those that have not. Rather than establishing an explicit process, we allow authors to publicize their implementation, which should enable working groups to treat relevant drafts preferentially. This solution is suggested for consideration as a process experiment. 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 June 10, 2013. Copyright Notice Copyright (c) 2012 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 Sheffer Expires June 10, 2013 [Page 1] Internet-Draft Running Code December 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . . 3 2. The "Implementation Status" Section . . . . . . . . . . . . . 3 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Process Experiment . . . . . . . . . . . . . . . . . . . . . 4 4.1. Duration . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Summary Report . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Success Criteria . . . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 Sheffer Expires June 10, 2013 [Page 2] Internet-Draft Running Code December 2012 1. Introduction Most IETF participants are familiar with the saying, "rough consensus and running code", and can identify with its pragmatic approach. However we are all aware of I-Ds that have gone through to publication with no implementation. Some of them may never get implemented. It was recently proposed [I-D.farrell-ft] to fast-track Internet drafts that have associated code. There are two issues with this proposal: o It is unclear if the "fast track" mechanism improves the quality of the final RFC or rather detracts from it by reducing the amount of review. o The fast-track mechanism can at best cut the overall time until an RFC is published by a month or two. This is meager motivation for authors who can typically expect about a 2 year period from the initial version of the document until publication. Instead, we propose a simpler process, whereby draft authors can publicize the availability of running code. It is up to the individual working groups to use this information as they see fit. We suggest that this proposal be adopted as a process experiment, within the lightweight framework of [RFC3933]. 1.1. Conventions used in this document 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]. 2. The "Implementation Status" Section Each Internet Draft MAY contain a section entitled Implementation Status, located just before the Security Considerations. This section, if it appears, should contain for each existing implementation of the draft: o The implementation's name and/or a link to the implementation. o A general description. o The implementation's level of maturity: alpha, beta, production, or widely used. o Coverage: how much of the proposed standard is implemented. Sheffer Expires June 10, 2013 [Page 3] Internet-Draft Running Code December 2012 o Licensing: whether the implementation is closed source, shareware, or open source. In addition, this section can contain information about the interoperability of any or all of the implementations. Since this information is necessarily time-dependent, the authors SHOULD remove this section when the I-D is published as an RFC. Another subsection that could be valuable (but could equally prove controversial) is an assertion of the IPR status of the implementation, e.g. whether it can be reused with no known encumbrance. 3. Benefits Publishing the information about implementations provides the working group with several benefits: o Participants are motivated to implement protocol proposals, which helps in discovering protocol flaws at an early stage. o Other participants can use the software, to evaluate the usefulness of protocol features. 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. 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 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. 4. Process Experiment The current proposal is a natural candidate for a process experiment, as described in [RFC3933]. This section defines the details of such an experiment. 4.1. Duration Given the typical time to produce an RFC (see [stats]), we propose a duration of 18 months for the experiment. Sheffer Expires June 10, 2013 [Page 4] Internet-Draft Running Code December 2012 4.2. Summary Report The author will summarize the results of the experiment at the end of the period. If nothing happens (no I-Ds or only a handful include an Implementation Status), an email to the IETF list is sufficient. This would obviously constitute a failure of 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 chairs and area directors who have used this mechanism. 4.3. Success Criteria The eventual goal of this experiment is to improve the quality of IETF standards. 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 more informed decisions 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? o Did the experiment result in toy implementations, aimed at "gaining points" at the IETF, or were they real and useful? 5. Implementation Status 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. Security Considerations This is a process document and therefore, it does not have a direct effect on the security of any particular IETF protocol. Better reviewed protocols are likely to also be more secure. 7. IANA Considerations None. Sheffer Expires June 10, 2013 [Page 5] Internet-Draft Running Code December 2012 8. Acknowledgements This document was prepared using the lyx2rfc tool, and we would like to thank Nico Williams, its author. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004. 9.2. Informative References [I-D.farrell-ft] Farrell, S., "A Fast-Track way to Proposed Standard with Running Code", draft-farrell-ft-01 (work in progress), December 2012. [stats] Arkko, J., "Distribution of Processing Times", December 2012, . Author's Address Yaron Sheffer Porticor 10 Yirmiyahu St. Ramat HaSharon 47298 Israel Email: yaronf.ietf@gmail.com Sheffer Expires June 10, 2013 [Page 6]