idnits 2.17.1 draft-carpenter-newtrk-questions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2006) is 6531 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter (ed) 3 Internet-Draft IBM 4 Expires: December 11, 2006 June 9, 2006 6 Questions about the standards track 7 draft-carpenter-newtrk-questions-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 11, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document sets out some thoughts about three possible directions 41 for further work on the evolution of the IETF standards track. Its 42 purpose is to stimulate community discussion leading to a choice 43 between these three directions. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Focus on document relationships . . . . . . . . . . . . . . . 4 49 3. Focus on maturity levels . . . . . . . . . . . . . . . . . . . 6 50 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 53 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 54 8. Change log [RFC Editor: please remove this section] . . . . . 7 55 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 57 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 Intellectual Property and Copyright Statements . . . . . . . . . . 10 61 1. Introduction 63 BCP 9 [RFC2026] is the current definition of the IETF standards 64 track. For some years there has been concern in the IETF that the 65 three stages of the standards track are no longer well adapted to 66 current conditions. One version of the statement of this problem is 67 in [RFC3774] which says: 69 "2.4. Three Stage Standards Hierarchy not properly Utilized 71 The current hierarchy of Proposed, Draft, and Full Standard maturity 72 levels for specifications is no longer being used in the way that was 73 envisioned when the stratification was originally proposed. In 74 practice, the IETF currently has a one-step standards process that 75 subverts the IETF's preference for demonstrating effectiveness 76 through running code in multiple interoperable implementations. This 77 compresses the process that previously allowed specifications to 78 mature as experience was gained with actual implementations: 80 o Relatively few specifications are now progressed beyond Proposed 81 Standard (PS) to Draft Standard (DS) level, and even fewer to Full 82 Standard (FS)." 83 (etc.) 85 It is important that the concern is not viewed only as a matter 86 internal to the IETF. The IETF's output is of no value unless it is 87 useful to a much wider community: implementors, vendors, service 88 providers, and directly or indirectly for the whole user community. 89 Therefore, the comprehensibility and useability of IETF 90 specifications for all these stakeholders is at issue. This broad 91 perspective, and not the IETF's internal workings, should be our 92 first concern. This point seems to have been missed in the drafting 93 of [RFC3774], which is rather focussed on the mechanics of the IETF, 94 but is implicit in the IETF Mission Statement [RFC3935]. 96 Some time ago, the New IETF Standards Track Discussion (newtrk) WG 97 was set up to tackle this problem. Its charter says in part: 99 "The goal of this working group is to agree on a revised IETF 100 Standards Track, to replace the standards track described in RFC 101 2026. The working group will also decide on a process path forward. 103 "The disparity between the documented IETF standards process and what 104 is used in practice can cause confusion on the part of those people 105 or organizations that use IETF technologies... 107 "The goal of this working group is to agree on a revised IETF 108 Standards Track, taking into consideration the above points, to 109 replace the standards track described in RFC 2026. The working group 110 will also decide on a process for making forward progress... 112 "As part of a revised standards track process, the group will also 113 explore the creation of a new series of short IESG-approved IETF 114 documents to describe and define IETF technology standards. These 115 documents should be able to be used to define the IETF understanding 116 of what constituted a specific IETF standard at particular points in 117 time." 119 This draft will not attempt to recapitulate the history of 120 discussions in newtrk. However, they have not yet led to a set of 121 proposals which have both solid WG support and seem likely to rapidly 122 reach IETF consensus and IESG approval. There are undoubtedly 123 differences of opinion about how this situation arose and who is to 124 blame. This draft avoids that discussion. Its goal is to set out 125 three distinct ways forward and to stimulate constructive discussion 126 in the community (not just in the WG) about which is the best choice 127 for the future. 129 The three possible ways forward are: 130 1. Agree that, apart from day to day efforts to improve efficiency, 131 the problems with the existing standards track are not serious 132 enough to justify the effort needed to make substantial changes. 133 Conclude that [RFC3774] exagerrated the problem and we only need 134 to make a relatively minor set of clarifications to BCP 9 135 [RFC2026]. 136 2. Focus on the issue of document relationships, or as the newtrk 137 charter currently says "the creation of a new series of short 138 IESG-approved IETF documents to describe and define IETF 139 technology standards." 140 3. Focus on the three-stage standards track, or as the newtrk 141 charter currently says "agree on a revised IETF Standards 142 Track... to replace the standards track described in RFC 2026." 144 The next two sections expand somewhat on the latter two alternatives. 146 2. Focus on document relationships 148 Today, users of IETF standards have no way to unambiguously identify 149 the complete current set of specifications for a given standard. In 150 particular, there is no effective structured document identification 151 scheme and no systematic approach to documenting the relationship 152 between various parts and versions of a standard. 154 This issue is best illustrated by example. Perhaps the most 155 fundamental example is Internet Protocol version 4. Consider a 156 hypothetical programmer on a desert island, with a computer and an 157 electricity supply, but no information except the indexed corpus of 158 RFCs and their external normative references. How can this 159 programmer implement IPv4 interoperably? The index will suggest 160 starting with RFC 791 (a Standard), updated by RFC 1349 (a Proposed 161 Standard, i.e. of lower status, so how can it have priority?). The 162 index then tells our programmer that RFC 1349 was obsoleted by RFC 163 2474 (another Proposed Standard). It then indicates that RFC 2474 164 was updated by RFC 3168 (Proposed Standard) and by RFC 3260 165 (Informational). Only by reading RFC 2474 will our programmer know 166 to consult RFC 2475 (Informational). And nowhere in this process is 167 she led to a much more important reference: RFC 1122 "Requirements 168 for Internet Hosts - Communication Layers" (a Standard), which itself 169 has been updated by RFC 1349 (again) and RFC 4379 (17 years later). 170 We will stop the trail here, but it should be clear that our isolated 171 programmer is unlikely to determine which RFCs she needs to follow to 172 build an interoperable IPv4 stack. 174 Other examples abound. What is the set of documents needed to fully 175 specify TCP or SMTP? How does an implementor of FTP know that the 176 appropriate reference for ASCII is RFC 20? Among more modern 177 protocols, where does a SIP or MPLS implementor look for the complete 178 set of relevant specifications? 180 All is not hopeless. An IPv4 implementor who starts with RFC 1122 181 and its updates has a better chance than one who starts with RFC 791, 182 at least until having to tackle DHCP. An IPv6 implementor can start 183 with RFC 4294 (IPv6 Node Requirements). An IPv4 router implementor 184 can start with RFC 1812 (Requirements for IP Version 4 Routers). But 185 these are exceptions produced with great effort. In the general 186 case, implementors need to be experts in the baroque structure of the 187 corpus of RFCs as much as in the technology itself. This is a cost 188 to the community, directly resulting from the IETF's piecemeal 189 approach. 191 At least two lines of attack on this problem have been pursued in the 192 newtrk WG. To avoid this document interfering in newtrk's due 193 process, only a very brief overview is given here. 195 The first approach is known as Internet Standards Documents (ISDs). 196 Conceptually, an ISD defines what a given standard is and which RFCs 197 (of any maturity level) form part of that standard. In this model, 198 an ISD equivalent of RFC 4294 would actually be *the* IPv6 standard, 199 for example. 201 The other, simpler, approach is an XML model for describing a set of 202 associated RFCs, without otherwise affecting the concept of what a 203 standard actually is. These documents would be known as Set of RFC 204 Documents (SRDs). In effect, they are a boost to the existing 205 indexing mechanisms for RFCs. 207 Obviously, the introduction of any such mechanism would create a new 208 document series and, in some cases, extra work. In other cases the 209 work is already done but in other forms (e.g. Applicability 210 Statement RFCs, or external white papers). As with any change of 211 practice in the IETF, we would need all WG chairs, and the IESG, to 212 sign on and to manage the necessary work. The community needs to 213 decide whether the benefits outweigh these costs. 215 3. Focus on maturity levels 217 The current three stage standards track is perceived to be under-used 218 and to have specific problems that make some aspects of it 219 unrealistic. (It should be noted that the number of stages in the 220 standards track does not affect the time taken to move a draft 221 through the approval process and to publish it, so the problem under 222 discussion is distinct from the issues of the time taken to obtain 223 IESG approval and RFC publication.) 225 This is the topic that the newtrk WG tackled initially. Proposals 226 have been made over several years for reducing the standards track 227 from three to two stages or even one stage, for adding a WG Snapshot 228 option, and for related clarification of the implementation report 229 requirement (a.k.a. the "running code" requirement) for advancement 230 in the standards track. All of these changes are relatively simple 231 to define, but no consensus has emerged in the WG as to which of them 232 is preferable. 234 It seems to be generally agreed that the requirement in BCP 9 235 [RFC2026] for regular review of Proposed Standards and Draft 236 Standards to see if they are ready for advancement is unrealistic, 237 with so many such RFCs on the books. Even the exercise in de- 238 classifying unused Proposed Standards [RFC4450] proved to be a lot of 239 work, needing several rounds of community review. 241 The community needs to decide whether the problems in this area are 242 in fact grievous enough to be tackled in priority, or whether they 243 are relatively benign. 245 4. Discussion 247 Clearly a case can be made for all three of the approaches mentioned. 248 We could shrug our shoulders and perform a maintenance update of BCP 249 9 [RFC2026]. We could make a concerted effort to choose between a 250 two-stage and a one-stage replacement for the three-stage standards 251 track. We could set that question aside and make a concerted effort 252 to agree on a standards-description recipe. However, experience 253 strongly suggests that we *do* need to make a choice as a community 254 between these three alternatives, and (assuming effort can be found) 255 charter work on only one of them with clear goals and realistic 256 milestone dates. 258 It seems likely that if we choose to charter work on the standards 259 description effort, formal adjustments to the three-stage standards 260 track could be made at a later stage if the community wanted. It 261 also seems likely that a maintenance update of BCP 9 will be needed 262 anyway, but this should not be confused with the major question: do 263 we embark first on the standards track update, the standards 264 description effort, or neither? 266 Community discussion is invited, in the first instance at 267 ietf@ietf.org. 269 5. Security Considerations 271 This document has no security implications for the Internet. 273 6. IANA Considerations 275 This document requires no action by the IANA. 277 7. Acknowledgements 279 In drafting this document, previous discussions within the IESG were 280 reviewed. Discussion with, among others, the current newtrk Chair, 281 Scott Bradner, and John Klensin are gratefully acknowledged. 283 This document was produced using the xml2rfc tool[RFC2629]. 285 8. Change log [RFC Editor: please remove this section] 287 draft-carpenter-newtrk-questions-00: original version, 2006-06-09 289 9. References 290 9.1. Normative References 292 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 293 3", BCP 9, RFC 2026, October 1996. 295 9.2. Informative References 297 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 298 June 1999. 300 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 302 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 303 BCP 95, RFC 3935, October 2004. 305 [RFC4450] Lear, E. and H. Alvestrand, "Getting Rid of the Cruft: 306 Report from an Experiment in Identifying and Reclassifying 307 Obsolete Standards Documents", RFC 4450, March 2006. 309 Author's Address 311 Brian Carpenter (ed) 312 IBM 313 8 Chemin de Blandonnet 314 1214 Vernier, 315 Switzerland 317 Email: brc@zurich.ibm.com 319 Intellectual Property Statement 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Disclaimer of Validity 345 This document and the information contained herein are provided on an 346 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 347 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 348 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 349 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 350 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 Copyright Statement 355 Copyright (C) The Internet Society (2006). This document is subject 356 to the rights, licenses and restrictions contained in BCP 78, and 357 except as set forth therein, the authors retain all their rights. 359 Acknowledgment 361 Funding for the RFC Editor function is currently provided by the 362 Internet Society.