idnits 2.17.1 draft-sheffer-running-code-06.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 (June 2, 2013) is 3974 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: December 4, 2013 Juniper 6 June 2, 2013 8 Improving Awareness of Running Code: the Implementation Status Section 9 draft-sheffer-running-code-06 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, by considering the running 18 code as evidence of valuable experimentation and feedback that has 19 made the implemented protocols more mature. 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 December 4, 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 2.1. Introductory Text . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Alternative Formats . . . . . . . . . . . . . . . . . . . . . 5 66 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Process Experiment . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. Duration . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2. Summary Report . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.3. Success Criteria . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Current Drafts Using This Guidance . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 10. Informative References . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 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, implementation is not a requirement for 84 publication as an RFC. There are many examples of Internet-Drafts 85 containing protocol specification that have gone through to 86 publication as Proposed Standard RFCs without implementation. Some 87 of them may never get implemented. 89 Over time, a variety of policies have been applied within the IETF to 90 consider running code. In the Routing Area it used to be a 91 requirement that one or more implementations must exist before an 92 Internet-Draft could be published as a Proposed Standard RFC 93 [RFC1264]. That RFC was later obsoleted and the requirement for 94 implementation was lifted, but each working group was given the 95 authority to impose its own implementation requirements [RFC4794] and 96 at least one working group (IDR) continues to require two independent 97 implementations. 99 The hypothesis behind the current document is that there are benefits 100 to the IETF standardization process of producing implementations of 101 protocol specifications before publication as RFCs. These benefits, 102 which include determining that the specification is comprehensible 103 and that there is sufficient interest to implement, are further 104 discussed in Section 4. 106 This document describes a simple mechanism that allows authors of 107 Internet-Drafts to record and publicize the status of known 108 implementations, by including an Implementation Status section. The 109 document defines (quite informally) the contents of this section, to 110 ensure that the relevant information is included. This will allow 111 reviewers and working groups to assign due consideration to documents 112 that have the benefit of running code, by considering the running 113 code as evidence of valuable experimentation and feedback that has 114 made the implemented protocols more mature. 116 It is up to the individual working groups to use this information as 117 they see fit, but one result might be the preferential treatment of 118 documents resulting in them being processed more rapidly. We 119 recommend that the Implementation Status section should be removed 120 from Internet Drafts before they are published as RFCs. As a result, 121 we do not envisage changes to this section after approval of the 122 document for publication, e.g. the RFC Errata process does not apply. 124 The process in this document is offered as an experiment (though not 125 as an [RFC3933] experiment, see Section 5). Authors of Internet- 126 Drafts are encouraged to consider using the process for their 127 documents, and working groups are invited to think about applying the 128 process to all of their protocol specifications. 130 The scope of the intended experiment is all Internet-Drafts that 131 contain implementable specifications, whether produced within IETF 132 working groups or outside working groups but intended for IETF 133 consensus. I-Ds published on the Independent Stream are explicitly 134 out of scope. It is expected that the greatest benefit in the 135 experiment will be seen with Standards Track documents developed 136 within working groups. 138 The authors of this document intend to collate experiences with this 139 experiment and to report them to the community. 141 2. The "Implementation Status" Section 143 Each Internet-Draft may contain a section entitled "Implementation 144 Status". This section, if it appears, should be located just before 145 the "Security Considerations" section and contain, for each existing 146 implementation some or all of the following: 148 o The organization responsible for the implementation, if any. 149 o The implementation's name and/or a link to a web page describing 150 the implementation. 151 o A brief general description. 152 o The implementation's level of maturity: research, prototype, 153 alpha, beta, production, widely used etc. 154 o Coverage: which parts of the protocol specification are 155 implemented and which versions of the Internet-Draft were 156 implemented. 157 o Licensing: the terms under which the implementation can be used. 158 For example: proprietary, royalty licensing, freely distributable 159 with acknowledgement (BSD style), freely distributable with 160 requirement to redistribute source (GPL style), other (specify). 161 o Implementation experience: Any useful information the implementers 162 want to share with the community. 163 o Contact information: ideally a person's name and email address, 164 but possibly just a URL or mailing list. 166 In addition, this section can contain information about the 167 interoperability of any or all of the implementations, including 168 references to test case descriptions and interoperability reports, 169 when such exist. 171 Working group chairs are requested to ensure that this section is not 172 used as a marketing venue for specific implementations. 174 Since this information is necessarily time-dependent, it is 175 inappropriate for inclusion in a published RFC. The authors should 176 include a note to the RFC Editor requesting that the section be 177 removed before publication. 179 2.1. Introductory Text 181 The following boilerplate text is proposed to head the Implementation 182 Status section: 184 This section records the status of known implementations of the 185 protocol defined by this specification at the time of posting of 186 this Internet-Draft, and is based on a proposal described in [RFC 187 Editor: replace by a reference to this document]. The description 188 of implementations in this section is intended to assist the IETF 189 in its decision processes in progressing drafts to RFCs. Please 190 note that the listing of any individual implementation here does 191 not imply endorsement by the IETF. Furthermore, no effort has 192 been spent to verify the information presented here that was 193 supplied by IETF contributors. This is not intended as, and must 194 not be construed to be, a catalog of available implementations or 195 their features. Readers are advised to note that other 196 implementations may exist. 197 According to [RFC Editor: replace by a reference to this 198 document], "this will allow reviewers and working groups to assign 199 due consideration to documents that have the benefit of running 200 code, by considering the running code as evidence of valuable 201 experimentation and feedback that has made the implemented 202 protocols more mature. It is up to the individual working groups 203 to use this information as they see fit". 205 Authors are requested to add a note to the RFC Editor at the top of 206 this section, advising the Editor to remove the entire section before 207 publication, as well as the reference to [RFC Editor: replace by a 208 reference to this document]. 210 3. Alternative Formats 212 Sometimes it can be advantageous to publish the implementation status 213 separately from the base Internet-Draft, e.g. on the IETF wiki: 215 o When the Implementation Status section becomes too large to be 216 conveniently managed within the document. 217 o When a working group decides to have implementors, rather than 218 authors, keep the status of their implementations current. 220 o When a working group already maintains an active wiki and prefers 221 to use it for this purpose. 222 o If the working group decides that the information is still 223 valuable (and needs to be kept current) after the I-D is published 224 as an RFC, and the Implementation Status section had been removed 225 from it. 227 It is highly desirable for all readers of the Internet-Draft to be 228 made aware of this information. Initially this can be done by 229 replacing the Implementation Status section's contents with a URL 230 pointing to the wiki. Later, the IETF Tools may support this 231 functionality, e.g. by including such a link from the HTMLized draft 232 version, similar to the IPR link. 234 If the implementation status is published separately from the I-D, 235 then this information needs to be openly available without requiring 236 authentication, registration or access controls if it is to have any 237 useful effects. 239 4. Benefits 241 Publishing the information about implementations provides the working 242 group with several benefits: 244 o Working group members, chairs and ADs may use the information 245 provided to help prioritize the progress of I-Ds, e.g. when there 246 are several competing proposals to solve a particular problem. 247 o Similarly, the information is useful when deciding whether the 248 document should be progressed on a different track (individual 249 submission, Experimental etc.). 250 o Making this information public and an explicit part of WG 251 deliberations will motivate participants to implement protocol 252 proposals, which in turn helps in discovering protocol flaws at an 253 early stage. 254 o Other participants can use the software, to evaluate the 255 usefulness of protocol features, its correctness (to some degree) 256 and other properties, such as resilience and scalability. 257 o WG members may choose to perform interoperability testing with 258 known implementations, especially when they are publicly 259 available. 260 o In the case of open source, people may want to study the code to 261 better understand the protocol and its limitations, determine if 262 the implementation matches the protocol specification, and whether 263 the protocol specification has omissions or ambiguities. 264 o And lastly, some protocol features may be hard to understand, and 265 for such features, the mere assurance that they can be implemented 266 is beneficial. We note though that code should never be used in 267 lieu of a clear specification. 269 We do not specify here whether and to what degree working groups are 270 expected to prefer proposals that have "running code" associated with 271 them, over others that do not. 273 5. Process Experiment 275 The current proposal is proposed as an experiment. The inclusion of 276 "Implementation Status" sections in Internet-Drafts is not mandatory, 277 but the authors of this document wish to encourage authors of other 278 Internet-Drafts to try out this simple mechanism to discover whether 279 it is useful. Working group chairs are invited to suggest this 280 mechanism to document editors in their working groups, and to draw 281 the attention of their working group participants to "Implementation 282 Status" sections where they exist. 284 Following a community discussion, it was concluded that [RFC3933] is 285 not an appropriate framework for this experiment, primarily because 286 no change is required to any existing process. 288 5.1. Duration 290 Given the typical time to produce an RFC (see [Stats]), we propose a 291 duration of 18 months for the experiment. Thus, 18 months after the 292 date of publication of this document as an RFC, the authors will 293 report on the experiment as described in the next section. 295 I-D authors are obviously free to include Implementation Status 296 sections in their documents even after the experiment has concluded. 298 5.2. Summary Report 300 The authors will summarize the results of the experiment at the end 301 of the period assigned to the experiment (see Section 5.1). If 302 nothing happens (no I-Ds or only a handful include an "Implementation 303 Status" section), an email to the IETF list will be sufficient. This 304 would obviously constitute a failure to adopt the idea and the 305 authors will abandon the experiment. 307 If this idea is adopted by document authors, a summary I-D will be 308 written containing the statistics of such adoption, as well as 309 (necessarily subjective) reports by working group members, chairs and 310 area directors who have used this mechanism. 312 The authors may then propose more wide-scale use of the process and 313 might suggest more formal adoption of the process by the IETF. 315 5.3. Success Criteria 317 The goal of this experiment is to improve the quality of IETF 318 specifications. This is impossible to quantify, of course. We 319 suggest that generally positive answers to the following questions 320 would indicate that the experiment was successful: 322 o Did the working group make decisions that were more informed when 323 comparing multiple competing solutions for the same work item? 324 o Did authors significantly modify proposed protocols based on 325 implementation experience? 326 o Did disclosure of implementations encourage more interoperability 327 testing than previously? 328 o Did non-authors review documents based on interactions with 329 running code and/or inspection of the code itself? 331 6. Implementation Status 333 [Note to RFC Editor: please remove this entire section before 334 publication.] 336 This is a process document and therefore does not have any meaningful 337 implementation status. "Implementation" in the context of this 338 document means actual program code. 340 6.1. Current Drafts Using This Guidance 342 As of this writing, the following drafts include an Implementation 343 Status section, citing the current draft: draft-clausen-lln-loadng, 344 draft-ovsienko-babel-hmac-authentication, draft-wilde-xml-patch, 345 draft-ietf-mpls-multipath-use. 347 7. Security Considerations 349 This is a process document and therefore, it does not have a direct 350 effect on the security of any particular IETF protocol. However, 351 better reviewed protocols are likely to also be more secure. 353 8. IANA Considerations 355 None. 357 9. Acknowledgements 359 We would like to thank Stephen Farrell, who reawakened community 360 interest in this topic. Several reviewers provided important input, 361 including Loa Andersson, Dave Crocker, Ned Freed, Christer Holmberg, 362 Denis Ovsienko, and Curtis Villamizar. 364 This document was prepared using the lyx2rfc tool, and we would like 365 to thank Nico Williams, its author. 367 10. Informative References 369 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 370 Routing Protocol Standardization Criteria", RFC 1264, 371 October 1991. 373 [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process 374 Experiments", BCP 93, RFC 3933, November 2004. 376 [RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, 377 December 2006. 379 [Stats] Arkko, J., "Distribution of Processing Times", 380 December 2012, 381 . 383 [Tao] Hoffman, P., Ed., ""The Tao of IETF: A Novice's Guide to 384 the Internet Engineering Task Force", 2012, 385 . 387 Authors' Addresses 389 Yaron Sheffer 390 Porticor 391 10 Yirmiyahu St. 392 Ramat HaSharon 47298 393 Israel 395 Email: yaronf.ietf@gmail.com 397 Adrian Farrel 398 Juniper Networks 400 Email: adrian@olddog.co.uk