idnits 2.17.1 draft-dawkins-pstmt-twostage-02.txt: -(86): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 371. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 387), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (May 21, 2004) is 7279 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) -- Missing reference section? 'DAWK' on line 340 looks like a reference -- Missing reference section? 'BRAD' on line 338 looks like a reference -- Missing reference section? 'STD' on line 346 looks like a reference -- Missing reference section? 'LOUG' on line 342 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Dawkins 3 Internet-Draft Inet Technologies, Inc. 4 Expires: November 19, 2004 D. Crocker 5 Brandenburg Internetworking 6 C. Perkins 7 Nokia Research Center 8 May 21, 2004 10 Two Stage Standardization 11 draft-dawkins-pstmt-twostage-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 19, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 RFC 2026 specifies a three-stage Standards Track. As currently 45 practiced, IETF standards track documents typically attain only the 46 first stage. This proposal discusses the problems caused by the 47 disparity between documented procedures and actual practice, and 48 proposes a two-step standard track. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. A Hybrid Solution . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1 Proposed Standard (PS) . . . . . . . . . . . . . . . . . . 5 56 3.2 Internet Standard (IS) . . . . . . . . . . . . . . . . . . 5 57 4. Formal Editing Changes . . . . . . . . . . . . . . . . . . . . 6 58 4.1 [RFC2026-4.1.1] Proposed Standard . . . . . . . . . . . . 6 59 4.2 [RFC2026-4.1.3] Internet Standard . . . . . . . . . . . . 6 60 4.3 [RFC2026-6.2] Advancing in the Standards Track . . . . . . 7 61 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5.1 Proposed Standard . . . . . . . . . . . . . . . . . . . . 8 63 5.2 Internet Standard . . . . . . . . . . . . . . . . . . . . 8 64 6. Relationship With Other Proposals . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 67 A. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 Intellectual Property and Copyright Statements . . . . . . . . 12 70 1. Introduction 72 RFC 2026 specifies a three-stage standards process. In theory, 73 Proposed Standard is an entry to the standards track. In practice 74 relatively few specifications ever advance even to the second stage, 75 Draft Standard. Furthermore, the periodic IESG review of "immature" 76 standards that is called for in section 6.2 of RFC 2026 seldom 77 happens. Consequently the Internet runs on Proposed Standards, some 78 of which are more than 25 years old, covering critical aspects of 79 routing, congestion control, and security. 81 This results in vulnerability at both ends of the spectrum: 82 1. Admission to "Proposed Standard" carries a heavier burden than 83 originally envisioned, because responsible reviewers realize this 84 is probably their last chance to identify problems with the 85 specification, and try to �think of everything that could go 86 wrong�. This thought exercise causes standards track work to be 87 less timely. The protracted development cycle often causes 88 productive engineers to lose interest and/or their opportunity to 89 remain involved. 90 2. In spite of this, advancing to "Proposed Standard" still does not 91 require implementation or deployment experience, so that the 92 IETF's "rough consensus and running code" guiding principle isn't 93 given a chance to be effective. 95 Discussion venue: Online discussion of this draft should take place 96 on the newtrk@lists.uoregon.edu mailing list. 98 2. The Problems 100 Current IETF standards management has a number of harmful properties: 102 1. Our documented process isn't what we use in practice. This 103 disparity creates opportunities for miscommunication, which in 104 turn creates opportunities for mistrust. 105 2. Basing the review for Proposed Standard on a thought exercise 106 instead of implementation and deployment experience encourages 107 "late surprises" in the process. The desire for perfection 108 drives reviewers to agonize over warnings and clarity. Whether a 109 specification will be returned to a working group for rework is 110 unpredictable, and the time required for approval is highly 111 variable. 112 3. Consumers of IETF specifications have learned to disregard our 113 formal process. RFC 2026 recommends in clear language that Draft 114 Standard, not Proposed Standard, is the proper maturity level for 115 widespread deployment. Any vendor that waits for this status is 116 left far behind in the marketplace (in most cases, infinitely far 117 behind). 118 4. Newcomers to the IETF have no written document to explain the ad 119 hoc adjustments we've made to accommodate current practice. For 120 example, the Transport Area routinely cycles proposed changes to 121 TCP congestion control through Experimental status before 122 approval as a Proposed Standard - a reasonable practice, but one 123 not described in RFC 2026. 124 5. We are almost assured that the IETF inventory of standards 125 contains specifications which do not reflect the corresponding 126 protocols in use on the Internet today, because the protocols 127 require modifications to the Proposed Standard specification 128 based on implementation or deployment experience, or simply 129 because some of these "standard" protocols may not be used at 130 all. 132 3. A Hybrid Solution 134 This current proposal merges a previous proposal by two of the 135 current authors [DAWK], with one suggested by Scott Bradner [BRAD]. 136 The resulting recipe for labeling IETF standards track documents 137 includes some additional seasoning. 139 A two-stage standards process is suggested, and Draft Standard status 140 is dropped. 142 3.1 Proposed Standard (PS) 144 The IETF process would retain current Proposed Standard rules, with 145 the following modifications: 146 1. All specifications must have least one implementation that has 147 been tested under the circumstances that represent its intended 148 use. 149 2. A fixed, 36-month time limit exists for all Proposed Standards. 150 By the end of that time the specification must be re-processed 151 for PS status, or it must be processed for the next standards 152 level, or it will be moved to Historic status. 153 3. PS specifications receive a STD number, or are added to an 154 existing STD. 156 3.2 Internet Standard (IS) 158 This is essentially the same as current full Standard. The 159 specification must have attained a significant degree of community 160 acceptance. 162 In other words, it must have demonstrated that it is deployed and 163 useful in the real world. 165 4. Formal Editing Changes 167 This proposal would be put into effect by making the following formal 168 changes to official IETF process and procedures specifications. 169 Specifically: 171 o Delete section 4.1.2 of [STD] 172 o Rewrite sections 4.1.1 and 4.1.3 of [STD], according to text 173 provided later this section 174 o Rewrite the last paragraph of section 6.2 of [STD] 175 o Remove references to Draft Standard from [STD] 176 o Perform other edits required for consistency 178 4.1 [RFC2026-4.1.1] Proposed Standard 180 The entry-level maturity for the IETF standards track is "Proposed 181 Standard". A specific action by the IESG is required to move a 182 specification onto the standards track at the "Proposed Standard" 183 level. 185 A Proposed Standard is generally stable, has resolved known design 186 choices, is believed to be well understood, has received significant 187 community review, and appears to enjoy enough community interest to 188 be considered valuable. However, further experience may well result 189 in a change of the specification before it advances, or even perhaps 190 a retraction. 192 Implementation experience is required for the designation of a 193 specification as a Proposed Standard. The specification must have 194 least one implementation that has been tested under the circumstances 195 that represent its intended use. This experience will usually 196 represent a strong argument in favor of designation as a Proposed 197 Standard. 199 A Proposed Standard should have no known technical omissions with 200 respect to the requirements placed upon it. However, the IESG may 201 waive this requirement in order to allow a specification to advance 202 to the Proposed Standard state when it is considered useful and 203 necessary (and timely) even with known technical omissions. 205 A specification that reaches the status of Proposed Standard is 206 assigned a number in the STD series. 208 4.2 [RFC2026-4.1.3] Internet Standard 210 A specification may be elevated to the Internet Standard level, when 211 the specification has been significantly deployed and used over the 212 Internet. 214 An Internet Standard is characterized by a high degree of technical 215 maturity and by a generally held belief that the specified protocol 216 or service provides significant benefit to the Internet community. 218 A specification that reaches the status of Internet Standard retains 219 its STD number, but is given a new RFC number. 221 The Working Group chair is responsible for documenting the community 222 adoption and use of the specification. 224 An Internet Standard must be well understood and known to be quite 225 stable, both in its semantics and as a basis for developing an 226 implementation. 228 An Internet Standard is normally considered a final specification, 229 and changes are likely to be made only to solve specific problems 230 encountered. In most circumstances, it is reasonable for vendors to 231 deploy implementations of Internet Standards into a disruption 232 sensitive environment. 234 4.3 [RFC2026-6.2] Advancing in the Standards Track 236 From the time it is assigned Proposed Standard status, a 237 specification has thirty-six (36) months to achieve the status of 238 Internet Standard. If it fails to achieve IS status, it will 239 automatically be moved to the status of Historic. This 240 reclassification to Historic status shall be communicated to the IETF 241 by electronic mail to the IETF Announce mailing list. Alternatively, 242 a specification may be renewed as Proposed Standard, if it again 243 satisfies the usual requirements for that status. 245 5. Discussion 247 This proposal seeks to capture, specify and refine current practise 248 in the IETF, by making its formal labeling actions more streamlined. 249 It makes implementation history required for all Proposed Standards, 250 eliminates Draft Standard and calls for Internet Standard status to 251 be based strictly upon community adoption and use. 253 The suggested scheme uses these labels: 254 PS: IETF-wide technical approval 255 IS: Internet community production deployment and use 257 Simplistically this means that PS is the goal for community technical 258 evaluation and IS is the goal for operations community adoption. 260 5.1 Proposed Standard 262 The status of Proposed Standard is the entry-level standards label, 263 resulting from IETF-wide technical review and approval. Many 264 Proposed Standards documents already reflect implementation and 265 testing history, because this improves both the technical quality and 266 the credibility of the work. The new process requires "running code" 267 for all PS specifications. However only one implementation is 268 required. Therefore the requirement for PS is not as demanding as 269 the current Draft Standard. 271 In order to keep the IETF inventory from having unused and/or buggy 272 specifications, documents are allowed to reside at PS for only a 273 limited time. 275 5.2 Internet Standard 277 The Internet Standard label is assigned to a specification that has 278 received the convincing demonstration of community support, namely 279 community use. Hence the label is not assigned due to technical 280 evaluation, but rather by virtue of demonstrated utility. 282 Hence the requirements for achieving IS status are to have been at PS 283 and then to receive community rough consensus that the specification 284 has established a track record of significant usefulness to the 285 community. 287 6. Relationship With Other Proposals 289 This proposal touches the topic area for [LOUG], which focuses on 290 improving our ability to describe what documents make up a standard. 291 We like many of the ideas in [LOUG], and our proposal will 292 significantly increase the number of STDs assigned, and will likely 293 increase the need for [LOUG], or something like it. But [LOUG] is 294 orthogonal to this proposal. 296 We continue to hope for adoption of some variant of the "Working 297 Group Snapshot"/"Stable Snap Shot" mechanism described in [BRAD] and 298 [DAWK], but that mechanism is also orthogonal to this proposal. 300 7. Security Considerations 302 This document contains no text with security issues, except perhaps 303 the security of the IETF standards process. 305 Authors' Addresses 307 Spencer Dawkins 308 Inet Technologies, Inc. 309 1547 Rivercrest Blvd. 310 Allen, TX 75002 311 USA 313 Phone: +1.469.330.3616 314 EMail: spencer@mcsr-labs.org 316 Dave Crocker 317 Brandenburg Internetworking 318 675 Spruce Dr. 319 Sunnyvale, CA 94086 320 USA 322 Phone: +1.408.246.8253 323 EMail: dcrocker@brandenburg.com 325 Charles E. Perkins 326 Nokia Research Center 327 Communications Systems Lab 328 313 Fairchild Drive 329 Mountain View, CA 94043 330 USA 332 Phone: +1.650.625.2986 333 EMail: charles.perkins@nokia.com 335 Appendix A. References 337 Informative 338 [BRAD]: Bradner, S., "An Idea for an Alternate IETF Standards Track", 339 draft-bradner-ietf-stds-trk-00.txt, July 2003. 340 [DAWK]: Dawkins, S., C. E. Perkins, "Two Stage Standardization 341 Approach", draft-dawkins-pstmt-twostage-00.txt, June 2003. 342 [LOUG]: Loughney, J., "Standards, What Standards?", 343 draft-loughney-what-standards-01.txt, February 2004. 345 Normative 346 [STD]: Bradner, S., "The Internet Standards Process -- Revision 3", 347 RFC 2026, October 1996. 349 Intellectual Property Statement 351 The IETF takes no position regarding the validity or scope of any 352 Intellectual Property Rights or other rights that might be claimed to 353 pertain to the implementation or use of the technology described in 354 this document or the extent to which any license under such rights 355 might or might not be available; nor does it represent that it has 356 made any independent effort to identify any such rights. Information 357 on the procedures with respect to rights in RFC documents can be 358 found in BCP 78 and BCP 79. 360 Copies of IPR disclosures made to the IETF Secretariat and any 361 assurances of licenses to be made available, or the result of an 362 attempt made to obtain a general license or permission for the use of 363 such proprietary rights by implementers or users of this 364 specification can be obtained from the IETF on-line IPR repository at 365 http://www.ietf.org/ipr. 367 The IETF invites any interested party to bring to its attention any 368 copyrights, patents or patent applications, or other proprietary 369 rights that may cover technology that may be required to implement 370 this standard. Please address the information to the IETF at 371 ietf-ipr@ietf.org. 373 Disclaimer of Validity 375 This document and the information contained herein are provided on an 376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 378 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 379 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 380 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 Copyright Statement 385 Copyright (C) The Internet Society (2004). This document is subject 386 to the rights, licenses and restrictions contained in BCP 78, and 387 except as set forth therein, the authors retain all their rights. 389 Acknowledgment 391 Funding for the RFC Editor function is currently provided by the 392 Internet Society.