idnits 2.17.1 draft-sheffer-rfc6982bis-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 02, 2016) is 2878 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1264 (Obsoleted by RFC 4794) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Obsoletes: 6982 (if approved) A. Farrel 5 Intended status: Best Current Practice Juniper Networks 6 Expires: December 4, 2016 June 02, 2016 8 Improving Awareness of Running Code: The Implementation Status Section 9 draft-sheffer-rfc6982bis-03 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, which may serve as evidence of 18 valuable experimentation and feedback that have made the implemented 19 protocols more mature. 21 This process is not mandatory. Authors of Internet-Drafts are 22 encouraged to consider using the process for their documents, and 23 working groups are invited to think about applying the process to all 24 of their protocol specifications. This document obsoletes RFC 6982, 25 advancing it to a Best Current Practice. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 4, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. The "Implementation Status" Section . . . . . . . . . . . . . 4 63 2.1. Introductory Text . . . . . . . . . . . . . . . . . . . . 5 64 3. Alternative Formats . . . . . . . . . . . . . . . . . . . . . 5 65 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Informative References . . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Document History . . . . . . . . . . . . . . . . . . 9 70 A.1. draft-sheffer-rfc6982bis-03 . . . . . . . . . . . . . . . 9 71 A.2. draft-sheffer-rfc6982bis-02 . . . . . . . . . . . . . . . 9 72 A.3. draft-sheffer-rfc6982bis-01 . . . . . . . . . . . . . . . 9 73 A.4. draft-sheffer-rfc6982bis-00 . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Most IETF participants are familiar with the saying "rough consensus 79 and running code" [Tao] and can identify with its pragmatic approach. 80 However, implementation is not a requirement for publication as an 81 RFC. There are many examples of Internet-Drafts containing protocol 82 specification that have gone through to publication as Proposed 83 Standard RFCs without implementation. Some of them may never get 84 implemented. 86 Over time, a variety of policies have been applied within the IETF to 87 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, Inter-Domain Routing (IDR), continues to 94 require two independent implementations. 96 The hypothesis behind the current document is that there are benefits 97 to the IETF standardization process of producing implementations of 98 protocol specifications before publication as RFCs. These benefits, 99 which include determining that the specification is comprehensible 100 and that there is sufficient interest to implement, are further 101 discussed in Section 4. 103 This document describes a simple mechanism that allows authors of 104 Internet-Drafts to record and publicize the status of known 105 implementations by including an Implementation Status section. The 106 document defines (quite informally) the contents of this section to 107 ensure that the relevant information is included. This will allow 108 reviewers and working groups to assign due consideration to documents 109 that have the benefit of running code, which may serve as evidence of 110 valuable experimentation and feedback that have made the implemented 111 protocols more mature. 113 It is up to the individual working groups to use this information as 114 they see fit, but one result might be the preferential treatment of 115 documents, resulting in them being processed more rapidly. We 116 recommend that the Implementation Status section should be removed 117 from Internet-Drafts before they are published as RFCs. As a result, 118 we do not envisage changes to this section after approval of the 119 document for publication, while the document sits in the RFC-editor 120 queue, e.g., the RFC errata process does not apply. 122 This process is not mandatory. Authors of Internet-Drafts are 123 encouraged to consider using the process for their documents, and 124 working groups are invited to think about applying the process to all 125 of their protocol specifications. 127 The scope of this process is all Internet-Drafts (I-Ds) that contain 128 implementable specifications, whether produced within IETF working 129 groups or outside working groups but intended for IETF consensus. 130 I-Ds published on the Independent Stream are explicitly out of scope. 131 It is expected that the greatest benefit will be seen with Standards 132 Track documents developed within working groups. 134 This process was initially proposed as an experiment in [RFC6982]. 135 That document is now obsoleted, and the process advanced to Best 136 Current Practice. 138 Historically there have been other ways for experience based on 139 protocol implementations to feed back into the IETF process. Many 140 "implementation reports" have been published, in some cases several 141 years after the protocol was originally published. Providing 142 feedback to published protocols is a related goal, but different from 143 the current document's focus. Two notable examples of published 144 implementation reports are [RFC1369] and [RFC5080]. 146 2. The "Implementation Status" Section 148 Each Internet-Draft may contain a section entitled "Implementation 149 Status". This section, if it appears, should be located just before 150 the "Security Considerations" section and contain, for each existing 151 implementation, some or all of the following: 153 - The organization responsible for the implementation, if any. 155 - The implementation's name and/or a link to a web page where the 156 implementation or a description of it can be found. 158 - A brief general description. 160 - The implementation's level of maturity: research, prototype, 161 alpha, beta, production, widely used, etc. 163 - Coverage: which parts of the protocol specification are 164 implemented. 166 - Version compatibility: what version/versions of the Internet Draft 167 are known to be implemented. 169 - Licensing: the terms under which the implementation can be used. 170 For example: proprietary, royalty licensing, freely distributable 171 with acknowledgement (BSD style), freely distributable with 172 requirement to redistribute source (General Public License (GPL) 173 style), and other (specify). 175 - Implementation experience: any useful information the implementers 176 want to share with the community. 178 - Contact information: ideally a person's name and email address, 179 but possibly just a URL or mailing list. 181 - The date when information about this particular implementation was 182 last updated. 184 In addition, this section can contain information about the 185 interoperability of any or all of the implementations, including 186 references to test-case descriptions and interoperability reports, 187 when such exist. 189 Working group chairs and area directors (ADs) are requested to ensure 190 that this section is not used as a marketing venue for specific 191 implementations. 193 Since this information is necessarily time dependent, it is 194 inappropriate for inclusion in a published RFC. The authors should 195 include a note to the RFC Editor requesting that the section be 196 removed before publication. 198 2.1. Introductory Text 200 The following boilerplate text is proposed to head the Implementation 201 Status section: 203 This section records the status of known implementations of the 204 protocol defined by this specification at the time of posting of 205 this Internet-Draft, and is based on a proposal described in RFC 206 [[RFC Editor: replace by RFC number]]. 207 The description of implementations in this section is 208 intended to assist the IETF in its decision processes in 209 progressing drafts to RFCs. Please note that the listing of any 210 individual implementation here does not imply endorsement by the 211 IETF. Furthermore, no effort has been spent to verify the 212 information presented here that was supplied by IETF contributors. 213 This is not intended as, and must not be construed to be, a 214 catalog of available implementations or their features. Readers 215 are advised to note that other implementations may exist. 217 According to RFC [[RFC Editor: replace by RFC number]], 218 "this will allow reviewers and working 219 groups to assign due consideration to documents that have the 220 benefit of running code, which may serve as evidence of valuable 221 experimentation and feedback that have made the implemented 222 protocols more mature. It is up to the individual working groups 223 to use this information as they see fit". 225 Authors are requested to add a note to the RFC Editor at the top of 226 this section, advising the Editor to remove the entire section before 227 publication, as well as the reference to RFC [[RFC Editor: replace by 228 RFC number]]. 230 3. Alternative Formats 232 Sometimes it can be advantageous to publish the implementation status 233 separately from the base Internet-Draft, e.g., on the IETF wiki: 235 - When the Implementation Status section becomes too large to be 236 conveniently managed within the document. 238 - When a working group decides to have implementors, rather than 239 authors, keep the status of their implementations current. 241 - When a working group already maintains an active wiki and prefers 242 to use it for this purpose. 244 - If the working group decides that the information is still 245 valuable (and needs to be kept current) after the I-D is published 246 as an RFC, and the Implementation Status section had been removed 247 from it. 249 It is highly desirable for all readers of the Internet-Draft to be 250 made aware of this information. Initially, this can be done by 251 replacing the Implementation Status section's contents with a URL 252 pointing to the wiki. Later, the IETF Tools may support this 253 functionality, e.g., by including such a link in the HTML file of the 254 document, similar to the IPR link. 256 If the implementation status is published separately from the I-D, 257 then this information needs to be openly available without requiring 258 authentication, registration, or access controls if it is to have any 259 useful effects. 261 4. Benefits 263 Publishing the information about implementations provides the working 264 group with several benefits: 266 - Working group members, chairs, and ADs may use the information 267 provided to help prioritize the progress of I-Ds, e.g., when there 268 are several competing proposals to solve a particular problem. 270 - Similarly, the information is useful when deciding whether the 271 document should be progressed on a different track (individual 272 submission, Experimental, etc.). 274 - Making this information public and an explicit part of WG 275 deliberations will motivate participants to implement protocol 276 proposals, which in turn helps in discovering protocol flaws at an 277 early stage. 279 - Other participants can use the software to evaluate the usefulness 280 of protocol features, its correctness (to some degree), and other 281 properties, such as resilience and scalability. 283 - WG members may choose to perform interoperability testing with 284 known implementations, especially when they are publicly 285 available. 287 - In the case of open source, people may want to study the code to 288 better understand the protocol and its limitations, determine if 289 the implementation matches the protocol specification, and whether 290 the protocol specification has omissions or ambiguities. 292 - And lastly, some protocol features may be hard to understand, and 293 for such features, the mere assurance that they can be implemented 294 is beneficial. We note though that code should never be used in 295 lieu of a clear specification. 297 We do not specify here whether and to what degree working groups are 298 expected to prefer proposals that have "running code" associated with 299 them, over others that do not. 301 Working group chairs are invited to suggest this mechanism to 302 document editors in their working groups, and to draw the attention 303 of their working group participants to Implementation Status sections 304 where they exist. 306 5. Security Considerations 308 This is a process document; therefore, it does not have a direct 309 effect on the security of any particular IETF protocol. However, 310 better-reviewed protocols are likely to also be more secure. 312 6. Acknowledgements 314 We would like to thank Stephen Farrell, who reawakened community 315 interest in this topic. Several reviewers provided important input, 316 including Loa Andersson, Dave Crocker, Ned Freed, Joel M. Halpern, 317 Christer Holmberg, Denis Ovsienko, and Curtis Villamizar. 319 This document was originally prepared using the lyx2rfc tool, and we 320 would like to thank Nico Williams, its author. 322 7. Informative References 324 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 325 Routing Protocol Standardization Criteria", RFC 1264, 326 DOI 10.17487/RFC1264, October 1991, 327 . 329 [RFC1369] Kastenholz, F., "Implementation Notes and Experience for 330 the Internet Ethernet MIB", RFC 1369, 331 DOI 10.17487/RFC1369, October 1992, 332 . 334 [RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, 335 DOI 10.17487/RFC4794, December 2006, 336 . 338 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 339 Dial In User Service (RADIUS) Implementation Issues and 340 Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 341 2007, . 343 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 344 Code: The Implementation Status Section", RFC 6982, 345 DOI 10.17487/RFC6982, July 2013, 346 . 348 [Tao] Hoffman, P., ""The Tao of IETF: A Novice's Guide to the 349 Internet Engineering Task Force"", 2012, 350 . 352 Appendix A. Document History 354 A.1. draft-sheffer-rfc6982bis-03 356 - Comment from Suresh re: I-D version compatibility. 358 A.2. draft-sheffer-rfc6982bis-02 360 - Implemented IESG review comments. 362 A.3. draft-sheffer-rfc6982bis-01 364 - Removed the IANA Considerations section. 366 - Implemented GENART comments. 368 A.4. draft-sheffer-rfc6982bis-00 370 Initial version. RFC 6982 as-is, without the experiment sections. 372 Authors' Addresses 374 Yaron Sheffer 375 Intuit 377 EMail: yaronf.ietf@gmail.com 379 Adrian Farrel 380 Juniper Networks 382 EMail: adrian@olddog.co.uk