idnits 2.17.1 draft-sheffer-running-code-02.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 (January 25, 2013) is 4102 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1264 (Obsoleted by RFC 4794) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: July 29, 2013 Juniper 6 January 25, 2013 8 Improving Awareness of Running Code: the Implementation Status Section 9 draft-sheffer-running-code-02 11 Abstract 13 This document describes a simple process that allows authors of 14 Internet-Drafts to record the status of known implementations by 15 including an Implementation Status section. This will allow 16 reviewers and working groups to assign due consideration to documents 17 that have the benefit of running code and potentially reward the 18 documented protocols by treating the documents with implementations 19 preferentially. 21 The process in this document is offered as an experiment. Authors of 22 Internet-Drafts are encouraged to consider using the process for 23 their documents, and working groups are invited to think about 24 applying the process to all of their protocol specifications. The 25 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 July 29, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.2. Summary Report . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.3. Success Criteria . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 10. Informative References . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 Most IETF participants are familiar with the saying, "rough consensus 80 and running code" [tao], and can identify with its pragmatic 81 approach. However, there are many examples of Internet-Drafts 82 containing protocol specification that have gone through to 83 publication as Proposed Standard RFCs without implementation. Some 84 of them may never get implemented. 86 Over time, a variety of policies have been implemented within the 87 IETF to consider running code. In the Routing Area it used to be a 88 requirement that one or more implementations must exist before an 89 Internet-Draft could be published as a Proposed Standard RFC 90 [RFC1264]. That RFC was later obsoleted and the requirement for 91 implementation was lifted, but each working group was given the 92 authority to impose its own implementation requirements [RFC4794] and 93 at least one working group (IDR) continues to require two independent 94 implementations. 96 The hypothesis behind this document is that there are benefits to the 97 IETF standardization process of producing implementations of protocol 98 specifications before publication as RFCs. These benefits, which 99 include determining that the specification is comprehensible and that 100 there is sufficient interest to implement, are further discussed in 101 Section 4. 103 This document describes a simple process that allows authors of 104 Internet-Drafts to record the status of known implementations, by 105 including an Implementation Status section. The document defines 106 (quite informally) the contents of this section, to ensure that the 107 relevant information is included. This will allow reviewers and 108 working groups to assign due consideration to documents that have the 109 benefit of running code and potentially reward the documented 110 protocols by treating the documents with implementations 111 preferentially. 113 Contrary to proposals to fast-track Internet-Drafts that have 114 associated source code implementations [I-D.farrell-ft], this 115 document provides a mechanism to record and publicize the existence 116 of running code. It is up to the individual working groups to use 117 this information as they see fit, but one result might be the 118 preferential treatment of documents resulting in them being processed 119 more rapidly. 121 The process in this document is offered as an experiment. Authors of 122 Internet-Drafts are encouraged to consider using the process for 123 their documents, and working groups are invited to think about 124 applying the process to all of their protocol specifications. 126 The authors of this document intend to collate experiences with this 127 experiment and to report them to the community. 129 2. The "Implementation Status" Section 131 Each Internet-Draft may contain a section entitled "Implementation 132 Status". This section, if it appears, should be located just before 133 the "Security Considerations" section and contain, for each existing 134 implementation: 136 o The implementation's name and/or a link to a web page describing 137 the implementation. 138 o A brief general description. 139 o The implementation's level of maturity: alpha, beta, production, 140 or widely used. 141 o Coverage: which parts of the protocol specification are 142 implemented and which versions of the Internet-Draft were 143 implemented. 144 o Licensing: the terms under which the implementation can be used. 145 For example: proprietary, royalty licensing, freely distributable 146 with acknowledgement (BSD style), freely distributable with 147 requirement to redistribute source (GPL style), other (specify). 149 In addition, this section can contain information about the 150 interoperability of any or all of the implementations. 152 Since this information is necessarily time-dependent, it is 153 inappropriate for a published RFC. The authors should include a note 154 to the RFC Editor requesting that the section be removed before 155 publication. 157 3. Alternative Formats 159 Sometimes it can be advantageous to publish the implementation status 160 separately from the base Internet Draft, e.g. on the IETF wiki: 162 o When the Implementation Status section becomes too large to be 163 conveniently managed within the document. 164 o When a working group decides to have implementors, rather than 165 authors, keep the status of their implementations current. 166 o When a working group already maintains an active wiki and prefers 167 to use it for this purpose. 169 It is highly important that all readers of the Internet Draft should 170 be made aware of this information. Initially this can be done by 171 replacing the Implementation Status section's contents with a URL 172 pointing to the wiki. Later, the IETF Tools may support this 173 functionality, e.g. by including such a link from the HTMLized draft 174 version, similarly to the IPR link. 176 The implementation status information must be publicly available, in 177 line with general IETF policy. 179 4. Benefits 181 Publishing the information about implementations provides the working 182 group with several benefits: 184 o Participants are motivated to implement protocol proposals, which 185 helps in discovering protocol flaws at an early stage. 186 o Other participants can use the software, to evaluate the 187 usefulness of protocol features, its correctness (to some degree) 188 and other properties, such as resilience and scalability. 189 o WG members may choose to perform interoperability testing with 190 known implementations, especially when they are publicly 191 available. 192 o In the case of open source, people may want to study the code to 193 better understand the protocol and its limitations, determine if 194 the implementation matches the protocol specification, and whether 195 the protocol specification has omissions or ambiguities. 196 o Working group chairs and ADs may use the information provided to 197 help prioritize the progress of I-Ds in some way [I-D.farrell-ft]. 198 o Similarly, the information is useful when deciding whether the 199 document should be progressed on a different track (individual 200 submission, Experimental etc.). 201 o And lastly, some protocol features may be hard to understand, and 202 for such features, the mere assurance that they can be implemented 203 is beneficial. 205 We do not specify here whether and to what degree working groups are 206 expected to prefer proposals that have "running code" associated with 207 them, over others that do not. 209 5. Process Experiment 211 The current proposal is proposed as an experiment. The inclusion of 212 "Implementation Status" sections in Internet-Drafts is not mandatory, 213 but the authors of this document wish to encourage authors of other 214 Internet-Drafts to try out this simple process to discover whether it 215 is useful. Working group chairs are invited to suggest this process 216 to document editors in their working groups, and to draw the 217 attention of their working group participants to "Implementation 218 Status" sections where they exist. 220 Following a community discussion, it was concluded that [RFC3933] is 221 not an appropriate framework for this experiment, primarily because 222 no change is required to any existing process. 224 5.1. Duration 226 Given the typical time to produce an RFC (see [stats]), we propose a 227 duration of 18 months for the experiment. Thus, 18 months after the 228 date of initial posting of this document, the authors will report on 229 the experiment as described in the next section. 231 5.2. Summary Report 233 The authors will summarize the results of the experiment at the end 234 of the period assigned to the experiment (see Section 5.1). If 235 nothing happens (no I-Ds or only a handful include an "Implementation 236 Status" section), an email to the IETF list will be sufficient. This 237 would obviously constitute a failure to adopt the idea and the 238 authors will abandon the experiment. 240 If this idea is adopted by document authors, a summary I-D will be 241 written containing the statistics of such adoption, as well as 242 (necessarily subjective) reports by working group chairs and area 243 directors who have used this mechanism. 245 The authors may then propose more wide-scale use of the process and 246 might suggest more formal adoption of the process by the IETF. 248 5.3. Success Criteria 250 The goal of this experiment is to improve the quality of IETF 251 specifications. This is impossible to quantify, of course. We 252 suggest that generally positive answers to the following questions 253 would indicate that the experiment was successful: 255 o Did the working group make decisions that were more informed when 256 comparing multiple competing solutions for the same work item? 257 o Did authors significantly modify proposed protocols based on 258 implementation experience? 259 o Did disclosure of implementations encourage more interoperability 260 testing than previously? 261 o Did non-authors review documents based on interactions with 262 running code and/or inspection of the code itself? 264 6. Implementation Status 266 This is a process document and therefore does not have any meaningful 267 implementation status. "Implementation" in the context of this 268 document means actual program code. 270 7. Security Considerations 272 This is a process document and therefore, it does not have a direct 273 effect on the security of any particular IETF protocol. Better 274 reviewed protocols are likely to also be more secure. 276 8. IANA Considerations 278 None. 280 9. Acknowledgements 282 We would like to thank Stephen Farrell, who reawakened community 283 interest in this topic. Several reviewers provided important input, 284 including Loa Andersson, Dave Crocker, Ned Freed, and Curtis 285 Villamizar. 287 This document was prepared using the lyx2rfc tool, and we would like 288 to thank Nico Williams, its author. 290 10. Informative References 292 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 293 Routing Protocol Standardization Criteria", RFC 1264, 294 October 1991. 296 [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process 297 Experiments", BCP 93, RFC 3933, November 2004. 299 [RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, 300 December 2006. 302 [I-D.farrell-ft] 303 Farrell, S., "A Fast-Track way to RFC with Running Code", 304 draft-farrell-ft-03 (work in progress), January 2013. 306 [stats] Arkko, J., "Distribution of Processing Times", 307 December 2012, 308 . 310 [tao] Hoffman, P., Ed., ""The Tao of IETF: A Novice's Guide to 311 the Internet Engineering Task Force", 2012, 312 . 314 Authors' Addresses 316 Yaron Sheffer 317 Porticor 318 10 Yirmiyahu St. 319 Ramat HaSharon 47298 320 Israel 322 Email: yaronf.ietf@gmail.com 324 Adrian Farrel 325 Juniper Networks 327 Email: adrian@olddog.co.uk