idnits 2.17.1 draft-sheffer-running-code-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2012) is 4147 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 280, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1264 (Obsoleted by RFC 4794) == Outdated reference: A later version (-03) exists of draft-farrell-ft-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: Experimental A. Farrel 5 Expires: June 20, 2013 Juniper 6 December 17, 2012 8 Improving "Rough Consensus" with Running Code 9 draft-sheffer-running-code-01 11 Abstract 13 This document describes a simple process that allows authors of 14 Internet-Drafts to record the status of known implementations. This 15 will allow reviewers and working groups to assign due consideration 16 to documents that have the benefit of running code and potentially 17 reward the documented protocols by treating the documents with 18 implementations preferentially. 20 The process in this document is offered as an experiment. Authors of 21 Internet-Drafts are encouraged to consider using the process for 22 their documents, and working groups are invited to think about 23 applying the process to all of their protocol specifications. 25 The authors of this document intend to collate experiences with this 26 experiment and to report them to the community. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 20, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. The "Implementation Status" Section . . . . . . . . . . . . . 4 64 3. Alternative Formats . . . . . . . . . . . . . . . . . . . . . 4 65 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Process Experiment . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Duration . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.2. Summary Report . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.3. Success Criteria . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 76 10.2. Informative References . . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 Most IETF participants are familiar with the saying, "rough consensus 82 and running code" [tao], and can identify with its pragmatic 83 approach. However, there are many examples of Internet-Drafts 84 containing protocol specification that have gone through to 85 publication as Proposed Standard RFCs without implementation. Some 86 of them may never get implemented. 88 Over time, a variety of policies have been implemented within the 89 IETF to consider running code. In the Routing Area it used to be a 90 requirement that one or more implementations must exist before an 91 Internet-Draft could be published as a Proposed Standard RFC 92 [RFC1264]. That RFC was later obsoleted and the requirement for 93 implementation was lifted, but each working group was given the 94 authority to impose its own implementation requirements [RFC4794] and 95 at least one working group (IDR) continues to require two independent 96 implementations. 98 The hypothesis behind this document is that there are benefits to the 99 IETF standardization process of producing implementations of protocol 100 specifications before publication as RFCs. These benefits, which 101 include determining that the specification is comprehensible and that 102 there is sufficient interest to implement, are further discussed in 103 Section 4. 105 This document describes a simple process that allows authors of 106 Internet-Drafts to record the status of known implementations. This 107 will allow reviewers and working groups to assign due consideration 108 to documents that have the benefit of running code and potentially 109 reward the documented protocols by treating the documents with 110 implementations preferentially. 112 Contrary to proposals to fast-track Internet-Drafts that have 113 associated source code implementations [I-D.farrell-ft], this 114 document provides a mechanism to record and publicize the existence 115 of running code. It is up to the individual working groups to use 116 this information as they see fit, but one result might be the 117 preferential treatment of documents resulting in them being processed 118 more rapidly. 120 The process in this document is offered as an experiment. Authors of 121 Internet-Drafts are encouraged to consider using the process for 122 their documents, and working groups are invited to think about 123 applying the process to all of their protocol specifications. 125 The authors of this document intend to collate experiences with this 126 experiment and to report them to the community. 128 2. The "Implementation Status" Section 130 Each Internet-Draft may contain a section entitled "Implementation 131 Status". This section, if it appears, should be located just before 132 the "Security Considerations" section and contain, for each existing 133 implementation: 135 o The implementation's name and/or a link to a web page describing 136 the implementation. 137 o A brief general description. 138 o The implementation's level of maturity: alpha, beta, production, 139 or widely used. 140 o Coverage: which parts of the protocol specification are 141 implemented and which versions of the Internet-Draft were 142 implemented. 143 o Licensing: whether the implementation is closed source, shareware, 144 or open source. 146 In addition, this section can contain information about the 147 interoperability of any or all of the implementations. 149 Since this information is necessarily time-dependent, the authors 150 should remove this section when the I-D is published as an RFC. 152 3. Alternative Formats 154 Sometimes it can be an advantage to publish the implementation status 155 separately from the base Internet Draft, e.g. on the IETF wiki: 157 o When the Implementation Status section becomes too large to be 158 conveniently managed within the document. 159 o When a working group decides to have implementors, rather than 160 authors, keep the status of their implementations current. 161 o When a working group already maintains an active wiki and prefers 162 to use it for this purpose. 164 It is highly important that all readers of the Internet Draft should 165 be made aware of this information. Initially this can be done by 166 replacing the Implementation Status section with a URL pointing to 167 the wiki. Later, the IETF Tools may support this functionality, e.g. 168 by including such a link from the HTMLized draft version, similarly 169 to the IPR link. 171 The implementation status information must be publicly available, in 172 line with general IETF policy. 174 4. Benefits 176 Publishing the information about implementations provides the working 177 group with several benefits: 179 o Participants are motivated to implement protocol proposals, which 180 helps in discovering protocol flaws at an early stage. 181 o Other participants can use the software, to evaluate the 182 usefulness of protocol features. 183 o WG members may choose to perform interoperability testing with 184 known implementations, especially when they are publicly 185 available. 186 o In the case of open source, people may want to study the code to 187 better understand the protocol and its limitations. 188 o Working group chairs and ADs may use the information provided to 189 help prioritize the progress of I-Ds in some way [I-D.farrell-ft]. 190 o And lastly, some protocol features may be hard to understand, and 191 for such features, the mere assurance that they can be implemented 192 is beneficial. 194 We do not specify here whether and to what degree working groups are 195 expected to prefer proposals that have "running code" associated with 196 them, over others that do not. 198 5. Process Experiment 200 The current proposal is proposed as an experiment. The inclusion of 201 "Implementation Status" sections in Internet-Drafts is not mandatory, 202 but the authors of this document wish to encourage authors of other 203 Internet-Drafts to try out this simple process to discover whether it 204 is useful. Working group chairs are invited to suggest this process 205 to document editors in their working groups, and to draw the 206 attention of their working group participants to "Implementation 207 Status" sections where they exist. 209 Following a community discussion, it was concluded that [RFC3933] is 210 not an appropriate framework for this experiment, primarily because 211 no change is required to any existing process. 213 5.1. Duration 215 Given the typical time to produce an RFC (see [stats]), we propose a 216 duration of 18 months for the experiment. Thus, 18 months after the 217 date of initial posting of this document, the authors will report on 218 the experiment as described in the next section. 220 5.2. Summary Report 222 The authors will summarize the results of the experiment at the end 223 of the period assigned to the experiment (see Section 5.1). If 224 nothing happens (no I-Ds or only a handful include an "Implementation 225 Status" section), an email to the IETF list will be sufficient. This 226 would obviously constitute a failure to adopt the idea and the 227 authors will abandon the experiment. 229 If this idea is adopted by document authors, a summary I-D will be 230 written containing the statistics of such adoption, as well as 231 (necessarily subjective) reports by working group chairs and area 232 directors who have used this mechanism. 234 The authors may then propose more wide-scale use of the process and 235 might suggest more formal adoption of the process by the IETF. 237 5.3. Success Criteria 239 The goal of this experiment is to improve the quality of IETF 240 specifications. This is impossible to quantify, of course. We 241 suggest that generally positive answers to the following questions 242 would indicate that the experiment was successful: 244 o Did the working group make decisions that were more informed when 245 comparing multiple competing solutions for the same work item? 246 o Did authors significantly modify proposed protocols based on 247 implementation experience? 248 o Did disclosure of implementations encourage more interoperability 249 testing than previously? 250 o Did non-authors review documents based on interactions with 251 running code and/or inspection of the code itself? 252 o Did the experiment result in toy implementations, aimed at 253 "gaining points" at the IETF, or were they real and useful? 255 6. Implementation Status 257 This is a process document and therefore does not have any meaningful 258 implementation status. "Implementation" in the context of this 259 document means actual program code. 261 7. Security Considerations 263 This is a process document and therefore, it does not have a direct 264 effect on the security of any particular IETF protocol. Better 265 reviewed protocols are likely to also be more secure. 267 8. IANA Considerations 269 None. 271 9. Acknowledgements 273 This document was prepared using the lyx2rfc tool, and we would like 274 to thank Nico Williams, its author. 276 10. References 278 10.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 10.2. Informative References 285 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 286 Routing Protocol Standardization Criteria", RFC 1264, 287 October 1991. 289 [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process 290 Experiments", BCP 93, RFC 3933, November 2004. 292 [RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, 293 December 2006. 295 [I-D.farrell-ft] 296 Farrell, S., "A Fast-Track way to RFC with Running Code", 297 draft-farrell-ft-02 (work in progress), December 2012. 299 [stats] Arkko, J., "Distribution of Processing Times", 300 December 2012, 301 . 303 [tao] Hoffman, P., Ed., ""The Tao of IETF: A Novice's Guide to 304 the Internet Engineering Task Force", 2012, 305 . 307 Authors' Addresses 309 Yaron Sheffer 310 Porticor 311 10 Yirmiyahu St. 312 Ramat HaSharon 47298 313 Israel 315 Email: yaronf.ietf@gmail.com 317 Adrian Farrel 318 Juniper Networks 320 Email: adrian@olddog.co.uk