idnits 2.17.1 draft-klensin-process-july14-02.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 258. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 274), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- == 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 Introduction section. ** 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 13, 2004) is 7316 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? 'RFC1396' on line 227 looks like a reference -- Missing reference section? 'RFC2026' on line 229 looks like a reference -- Missing reference section? 'RFC3667' on line 231 looks like a reference -- Missing reference section? 'RFC3668' on line 233 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft S. Dawkins 4 Expires: October 12, 2004 April 13, 2004 6 A model for IETF Process Experiments 7 draft-klensin-process-july14-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 12, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The IETF has designed process changes over the last ten years in one 40 of two ways -- announcement by the IESG, sometimes based on informal 41 agreements with limited community involvement, and awareness, and 42 formal use of same mechanism as is used for protocol specification. 43 The first mechanism has often proven to be too lightweight, the 44 second too heavyweight. There is a middle ground. 46 This document proposes a middle-ground approach to the system of 47 making changes to IETF process, one that relies heavily on a "propose 48 and carry out an experiment, evaluate the experiment, and then 49 establish permanent procedures based on operational experience" model 50 rather than the ones that have been attempted previously. 52 Table of Contents 54 1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 58 A. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . 9 61 1. Proposal 63 Since the 1992 changes documented in RFC 1396, the IETF has used two 64 mechanisms for process changes. 65 1. IESG has adopted a number of procedural changes on its own 66 initiative and documented them informally, utilizing the wide 67 discretion implicitly granted them by RFC 2026. This provided a 68 lightweight mechanism for change, but the lightness came with a 69 cost: there was sometimes too little alignment with the larger 70 IETF community. 71 2. The IETF has also used the RFC 2026 protocol standards 72 development process (identify a community of interest, hold one 73 or more BoFs, charter a working group, discuss proposed changes 74 within the community, develop IETF-wide consensus on the changes, 75 and publish (usually) Best Current Practice specifications. This 76 provided full community involvement, but also came with a cost in 77 flexibility. The IETF does not change its formal processes often 78 (the IPR clarifications in RFCs 3667-3668 are the first 79 documented changes to RFC 2026 since 1996), and the community is 80 understandably reluctant to permanently alter or extend 81 formally-adopted processes with untried new procedures. 83 There is a middle ground between BCP process updates and informal 84 agreements. This document proposes to regularize and formalize the 85 mechanism listed first above as a means of moving forward with 86 procedural changes that might prove valuable. 88 The mechanisms outlined here are not intended to be exclusive: they 89 add to the IESG's range of tools for dealing with process issues on 90 an ongoing basis, rather that replacing those tools with a single 91 "magic bullet". The choice as to whether to use the procedure 92 outlined in this document (if it is adopted) or other mechanisms 93 available to the IESG and the community --present or future-- remains 94 in the IESG's hands. If the IESG does not exercise that discretion 95 wisely, this document provides no additional remedies. 97 Some have read the current procedures as giving the IESG all of the 98 capabilities outlined here, i.e., this document changes almost 99 nothing. If this is true, this document only encourages the IESG to 100 use this type of mechanism more frequently in preference to less 101 streamlined ones, and to more explicitly document what it is doing 102 and what decisions it is making. 104 We propose to permit (and encourage) the IESG to adopt and institute 105 "process experiments" using the following procedure: 106 1. An I-D is written that describes what the proposed new or altered 107 procedure is about and how it works. A statement of what problem 108 it is expected to solve would be desirable, but is not a 109 requirement (the intent is to keep the firm requirements for such 110 an experiment as lightweight as possible). Similarly, specific 111 experimental or evaluation criteria are very desirable, but not 112 required -- for some of the process changes we anticipate, having 113 the IESG reach a conclusion at the end of the sunset period that 114 the community generally believes things to be better (or worse) 115 will be both adequate and sufficient. The I-D must state an 116 explicit "sunset" timeout, typically not to exceed one year after 117 adoption. 118 2. If the IESG believes the proposal is plausible and plausibly 119 useful, a four week IETF Last Call is initiated. The IESG can 120 institute whatever procedures it wishes to make that 121 determination and to avoid denial of service attacks from large 122 numbers of spurious or unimportant proposals. In particular, 123 they might institute a procedure requiring some number of 124 endorsements, or endorsements of a particular type, before the 125 IESG considers the draft. The IESG is, however, expected to 126 understand that procedures or review processes that act as a 127 mechanism for significant delays do not fall within the intent of 128 this proposal. 129 3. At the conclusion of the Last Call, the IESG reevaluates the 130 plausibility and appropriateness of the proposal. If they 131 conclude that the proposed experiment is appropriate, a second 132 I-D is generated (either by the IESG or by the original authors 133 with IESG advice) that cleans up any definitional issues exposed 134 in the Last Call and that explicitly identifies and responds to 135 issues raised during that Last Call. 136 4. The document and experiment are then announced, the experiment is 137 begun, and the document is forwarded for publication as an 138 Experimental RFC. 140 The IESG is explicitly authorized to use this mechanism (based on 141 Experimental RFCs) to gain experience with proposed changes to BCP 142 specifications - there is no requirement to approve a BCP 143 specification for the experiment until the experiment is found to 144 have value. 146 The IESG could, of course, reach a "bad idea" conclusion at any stage 147 in this process and abandon the experiment. It might recommend 148 publication of the experimental document, with a discussion of why it 149 was a bad idea, but is not required to do so. The list above is 150 deliberately agnostic about where the I-Ds come from: a WG, design 151 team, individual contribution, editing group, or other mechanism, 152 could be used in the first and/or third steps, but no specific 153 mechanisms are required and the IESG is explicitly permitted to 154 generate such proposals internally. 156 In each case, the IESG's making of the decisions to go forward (or 157 not) with a procedural experiment, or the steps leading up to one, is 158 expected to reflect their judgment of the existence of rough 159 consensus in the community. That judgment may be appealed using the 160 usual procedures, but the IESG and the community are reminded that an 161 experimental attempt to try something for a fixed period is typically 162 a better engineering approach than extended philosophical discussion 163 without any experience to back it up. 165 Nothing above is to be construed as a requirement that any given 166 process experiment be attempted IETF-wide. A proposal for such an 167 experiment may specify selected areas, selected working groups, 168 working groups meeting some specific criteria (such as those created 169 after a particular time or more than a specified number of years 170 old), or be specific in other ways. 172 At or before the end of the "sunset" timeout, the IESG would either 173 revise (or cause to be revised) the document into a BCP RFC or the 174 procedure would expire and, presumably, not be tried again unless 175 something changed radically. A document describing why the 176 experiment had succeeded or failed would be desirable but could not, 177 realistically, be a requirement. If the procedure went to BCP, the 178 BCP would reflect what we would call "operational experience" in the 179 real world. 181 We note that, if the procedures the IESG has adopted (and procedural 182 exceptions it has made) over the last decade are legitimate, then the 183 IESG has the authority to institute the changes proposed here by 184 bootstrapping the proposed process. 186 2. Security Considerations 188 This document specifies a mechanism for evolving IETF procedures. It 189 does not raise or consider any protocol-specific security issues. In 190 considering experimental changes to procedures, the IESG should, of 191 course, exercise due caution that such changes not reduce the quality 192 of security review and consideration for protocols or, at least, that 193 the process experiment proposals contain early detection and 194 correction mechanisms should quality deterioration occur. 196 3. Acknowledgements 198 The first revision of this document benefited significantly from 199 suggestions and comments from Avri Doria, Margaret Wasserman, and 200 Harald Alvestrand, and from discussions with the General Area 201 Directorate and at its open meeting during IETF 59. After mailing 202 list discussion, considerable explanatory material was removed to a 203 separate document for the current version. 205 The first version of this document was posted as an Internet Draft on 206 7 February 2004. 208 Authors' Addresses 210 John C Klensin 211 1770 Massachusetts Ave, #322 212 Cambridge, MA 02140 213 USA 215 Phone: +1 617 491 5735 216 EMail: john-ietf@jck.com 218 Spencer Dawkins 219 1547 Rivercrest Blvd. 220 Allen, TX 75002 221 USA 223 Phone: +1 469 330 3616 224 EMail: spencer@mcsr-labs.org 226 Appendix A. References 227 [RFC1396]: "The Process for Organization of Internet Standards", RFC 228 1396, S. Crocker and POISED Working Group, 1993 229 [RFC2026]: "The Internet Standards Process -- Revision 3", RFC 2026 230 (also BCP 9), S. Bradner (editor), 1996 231 [RFC3667]: "IETF Rights in Contributions", RFC 3667 (also BCP 78), S. 232 Bradner (editor), 2004 233 [RFC3668]: "Intellectual Property Rights in IETF Technology", RFC 234 3668 (also BCP 79), S. Bradner (editor), 2004 236 Intellectual Property Statement 238 The IETF takes no position regarding the validity or scope of any 239 Intellectual Property Rights or other rights that might be claimed to 240 pertain to the implementation or use of the technology described in 241 this document or the extent to which any license under such rights 242 might or might not be available; nor does it represent that it has 243 made any independent effort to identify any such rights. Information 244 on the IETF's procedures with respect to rights in IETF Documents can 245 be found in BCP 78 and BCP 79. 247 Copies of IPR disclosures made to the IETF Secretariat and any 248 assurances of licenses to be made available, or the result of an 249 attempt made to obtain a general license or permission for the use of 250 such proprietary rights by implementers or users of this 251 specification can be obtained from the IETF on-line IPR repository at 252 http://www.ietf.org/ipr. 254 The IETF invites any interested party to bring to its attention any 255 copyrights, patents or patent applications, or other proprietary 256 rights that may cover technology that may be required to implement 257 this standard. Please address the information to the IETF at 258 ietf-ipr@ietf.org. 260 Disclaimer of Validity 262 This document and the information contained herein are provided on an 263 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 264 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 265 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 266 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 267 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 268 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Copyright Statement 272 Copyright (C) The Internet Society (2004). This document is subject 273 to the rights, licenses and restrictions contained in BCP 78, and 274 except as set forth therein, the authors retain all their rights. 276 Acknowledgment 278 Funding for the RFC Editor function is currently provided by the 279 Internet Society.