idnits 2.17.1 draft-atkinson-newtrk-twostep-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 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 4 instances of too long lines in the document, the longest one being 1 character 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 (22 February 2006) is 6638 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) == Outdated reference: A later version (-04) exists of draft-ietf-newtrk-repurposing-isd-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (ref. '5') (Obsoleted by RFC 7749) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Atkinson, Editor 3 Internet-Draft Extreme Networks 4 Expires: 22 July 2006 22 February 2006 6 A two stage standards process 7 draft-atkinson-newtrk-twostep-00.txt 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 have 13 been or will be disclosed, and any of which he or she becomes aware 14 will be disclosed, in accordance with Section 6 of BCP 79. 16 This document is subject to the rights, licenses, and restrictions 17 contained in BCP 78, and except as set forth therein, the authors 18 retain all their rights. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on 22 July 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document proposes several changes to the Internet standards 44 process, especially a reduction from three to two stages in the 45 IETF standards track. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Stage 1: Proposed Standard . . . . . . . . . . . . . . . . . . 3 51 3. Stage 2: Interoperable Standard . . . . . . . . . . . . . . . . 3 52 4. Stage 3: No stage three . . . . . . . . . . . . . . . . . . . . 4 53 5. Timing rules . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 6. IS can reference PS . . . . . . . . . . . . . . . . . . . . . . 5 55 7. The STD designation, and updates . . . . . . . . . . . . . . . 5 56 8. Transitional arrangements . . . . . . . . . . . . . . . . . . . 5 57 9. Not excluded . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 10. Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 14. Informative References . . . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 Intellectual Property and Copyright Statements . . . . . . . . . . 9 66 1. Introduction 68 This document proposes several changes to the Internet standards 69 process defined in RFC-2026. [1] These changes are designed to 70 simplify the process. They seek to reduce the set of impediments to 71 standards progression without any major changes to Internet 72 engineering philosophy. 74 The background for this proposal is the published analysis of 75 problems in the IETF [2], various discussions in the IETF's "New IETF 76 Standards Track Discussion" (newtrk) working group, various largely 77 expired drafts, the original author's personal experience, and the 78 editor's personal experience. It has little claim to originality 79 (see Acknowledgements). 81 The problems tackled by this proposal are those of clumsiness in the 82 three-stage standards process, and related clumsiness in the clarity 83 and useability of IETF standards. This draft is deliberately short 84 on rationale and explanation - the interested reader should study the 85 above references and discussions carefully. 87 2. Stage 1: Proposed Standard 89 This is exactly as described in RFC-2026. [1] 91 3. Stage 2: Interoperable Standard 93 This is very similar to Draft Standard as described in [1]. The name 94 is changed partly to mark the change, partly because people outside 95 the IETF often confuse "Draft Standard" with "Internet-Draft", and 96 partly to emphasise the IETF's value statement of "rough consensus 97 and running code." 99 The criteria for advancing from Proposed Standard to Interoperable 100 Standard are roughly the same as the current criteria for moving to 101 Draft Standard. 103 However, two inconveniences in the present advancement process and 104 interoperability requirements have been encountered: 106 1. The objective is to validate that a specification contains only 107 features that have been demonstrated to be interoperable. The 108 current text does not make it crystal clear that this, and not 109 the availability of conformant implementations, is being 110 demonstrated: the essential difference being that all features 111 must be interoperable, not that all implementations must be shown 112 to support all features. 114 2. The current text requires features that have not been demonstrated 115 as interoperable to be removed from the specification. This may 116 cause an RFC to be updated, at a cost of many months delay, even 117 if only one or two features have not been demonstrated to 118 interoperate. The proposed new text would also allow an RFC to 119 be upgraded without change, even if some features had not been 120 proved interoperable, as long as this fact was duly documented. 122 Thus, this paragraph: 124 "The requirement for at least two independent and interoperable 125 implementations applies to all of the options and features of the 126 specification. In cases in which one or more options or features 127 have not been demonstrated in at least two interoperable 128 implementations, the specification may advance to the Draft Standard 129 level only if those options or features are removed." 131 is replaced by: 133 "The requirement for at least two independent and interoperable 134 implementations applies to each of the options and features of the 135 specification considered individually. In cases in which one or more 136 options or features have not been demonstrated in at least two 137 interoperable implementations, the specification may advance to the 138 Interoperable Standard level only if those options or features are 139 removed, or marked as untested for interoperability in a revised 140 specification or in an external document available at the IETF web 141 site and at the IETF ftp site." 143 4. Stage 3: No stage three 145 The final, rare, "Standard" stage is simply abolished. The 146 difference between the second and third stages isn't enough to 147 justify the extra bureaucracy, and there is nothing negative about 148 "Interoperable Standard" as the final state. 150 5. Timing rules 152 The minimum time at "Proposed Standard" remains six months. 154 The highly theoretical rule about annual review of PS documents after 155 two years is dropped to a recommendation; no review cycle is mandated 156 for IS documents. 158 The six month (and two year) timer starts when the IESG approval 159 announcement for a document is sent, not when the RFC is published. 160 As an adjunct to this, approved drafts should be parked in a special 161 public directory while they are in the RFC queue, so that they are 162 readily available to implementers. 164 6. IS can reference PS 166 Interoperable Standards are allowed to make normative references to 167 Proposed Standards. The current rule prohibiting "down references" 168 is a major cause of stickiness in the publication process. This 169 change, in theory, allows an Interoperable Standard to reference 170 features that have not been formally agreed to be demonstrably 171 interoperable. But it is a matter of common sense - if we want to be 172 able to promote Proposed Standard documents expeditiously, we have to 173 allow this form of down reference. (Down references from an RFC to 174 an Internet-Draft continue to be prohibited.) 176 7. The STD designation, and updates 178 Presently, an STD designation and number is only given to a document 179 (or document set) at the full Standard level. This can cause extreme 180 confusion when a full Standard is technically obsoleted by a Proposed 181 Standard. What is an implementer to do? 183 One option is to simply abolish the STD designation, which is little 184 used anyway. (The editor prefers to abolish STD on grounds that it 185 eliminates needless process and is currently not often used; however, 186 his view is not strongly held.) 188 The alternative is to assign the STD designation (and number) to a 189 document (or document set) at PS level; if a PS is promoted to IS, 190 its STD number goes with it; if an IS is obsoleted by a PS, the STD 191 number reverts to the PS. In any case, this function (assigning 192 documents to specific STD designations) would be an IETF (WG or IESG) 193 matter and not an RFC Editor action as today. 195 8. Transitional arrangements 197 On the day these changes enter service, all existing Draft Standard 198 and (Full) Standard RFCs would be automatically reclassified as 199 Interoperable Standard RFCs. Corresponding changes would be made to 200 the RFC Index and various features of the RFC Editor site and any 201 other RFC repositories displaying the status of RFCs. 203 If and only if the STD designation is retained, all existing STD 204 designations will be applied as follows: 206 1. If the old Standard has not been obsoleted, it is now an IS with 207 the same STD designation. 209 2. If the old Standard has been obsoleted, the STD designation 210 goes to the document(s) that obsoleted it, which may be PS, IS or 211 a mixture. 213 3. If the old Standard has been updated, the STD designation is 214 added to the document(s) that updated it, which may be PS, IS or 215 a mixture. 217 4. The IESG would designate a team or teams to rapidly classify 218 all PS and IS documents not assigned an STD designation by the 219 above process into new STD designations. 221 (If the STD designation is abolished, these steps would be 222 unnecessary, but various cleanings up of the RFC Index and the RFC 223 Editor web site would be needed to remove all references to STD.) 225 9. Not excluded 227 The above changes have been constructed in such a way that they do 228 not exclude the notions of WG Snapshots (drafts declared to be in a 229 stable state by the WG), Stable Snapshots (drafts declared to be in a 230 stable state with IESG agreement) or Internet Standards Documentation 231 (ISDs, external descriptors of a set of RFCs as a single 232 standard)[3]. 234 This document has been written such that it neither requires nor 235 prohibits other unrelated process changes to be made. 237 10. Initial Publication as Historic RFC 239 An unrelated process clarification is that, occasionally, the IESG 240 may decide to approve a document for immediate publication as 241 Historic (rather than Informational), when it is desired to publish 242 it for the record but the document's content is already overtaken by 243 events. 245 10. Housekeeping 247 Obviously, [1] will need considerable editing in addition to the 248 above changes, for example to remove the intellectual property 249 material which is already obsolete. Also, [4], which defined the STD 250 designation, should be obsoleted. (Even if the STD designation is 251 retained, it should be fully described in the replacement for [1].) 253 11. Security Considerations 255 This document does not directly affect the security of the Internet. 257 12. IANA Considerations 258 This document requests no action by the IANA. 260 13. Acknowledgements 262 The current editor proposed a two-stage standards track process to 263 the IAB and IESG whilst he was serving on the IAB. At that time, the 264 idea did not garner much support. Separately, a two-stage standards 265 track proposal was made Spencer Dawkins, Charlie Perkins and Dave 266 Crocker in 2003, which also contained a version of the WG Snapshot 267 proposal. Another variant including Stable Snapshots was made by 268 Scott Bradner in 2004. This draft was written by Brian Carpenter in 269 June 2005. The current editor took over the draft in February 2006 270 with permission from Brian Carpenter. Comments on the Brian 271 Carpenter's original draft by Spencer Dawkins are gratefully 272 acknowledged. 274 This document was originally produced using the xml2rfc tool[5], but 275 the current editor is using nroff. 277 14. Informative References 279 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 280 BCP-9, RFC-2026, October 1996. 282 [2] Davies, E., "IETF Problem Statement", RFC-3774, May 2004. 284 [3] Klensin, J. and J. Loughney, "Internet Standards Documentation 285 (ISDs)", draft-ietf-newtrk-repurposing-isd-03 (work in 286 progress), April 2005. 288 [4] Postel, J., "Introduction to the STD Notes", RFC-1311, March 289 1992. 291 [5] Rose, M., "Writing I-Ds and RFCs using XML", RFC-2629, June 292 1999. 294 Author's Address 296 Randall Atkinson 297 Extreme Networks 298 PO Box 14129 299 3306 East NC Highway 54, Suite 100 300 Research Triangle Park, NC 301 27709 USA 303 Email: rja@extremenetworks.com 305 Intellectual Property Statement 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be found 314 in BCP-78 and BCP-79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this specification 320 can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org. 329 Disclaimer of Validity 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 334 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 335 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 336 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 339 Copyright Statement 341 Copyright (C) The Internet Society 2006. This document is subject to 342 the rights, licenses and restrictions contained in BCP-78, and except 343 as set forth therein, the author and editor retain all their rights. 345 Acknowledgment 347 Funding for the RFC Editor function is currently provided by the 348 Internet Society.