idnits 2.17.1 draft-huston-ietf-pact-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 25, 2002) is 7847 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft Telstra 4 Expires: April 25, 2003 M. Rose 5 Dover Beach Consulting, Inc. 6 October 25, 2002 8 A Proposal to Improve IETF Productivity 9 draft-huston-ietf-pact-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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 http:// 27 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 April 25, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 The IETF standards process must exhibit four qualities 41 (Predictability, Accountability, Competency, and Timeliness), which 42 we term "the IETF Pact". Growth in the IETF's size and diversity 43 challenges its ability to make progress in producing useful 44 specifications. This proposal puts forward procedural changes that 45 will improve the IETF PACT, without altering the IETF's philosophy or 46 structure, and without requiring changes to the formal IETF standards 47 process (cf., RFC 2026 [1]). 49 Table of Contents 51 1. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The IETF "PACT" . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Working Group Operation . . . . . . . . . . . . . . . . . . 5 54 3.1 The "Utility Focus" model for WGs . . . . . . . . . . . . . 5 55 3.2 The "Short-term" model for WGs . . . . . . . . . . . . . . . 5 56 4. IETF Operation . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1 The "Area Focus" model for the IESG . . . . . . . . . . . . 6 58 4.1.1 Bounded Discussion . . . . . . . . . . . . . . . . . . . . . 6 59 4.1.2 Proportional Voting . . . . . . . . . . . . . . . . . . . . 7 60 4.1.3 Vote Explanations . . . . . . . . . . . . . . . . . . . . . 7 61 4.1.4 Status Reporting . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2 The "Bounded Outcome" model for the IETF . . . . . . . . . . 8 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . 10 65 References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 67 A. Summary of Proposed Rules . . . . . . . . . . . . . . . . . 12 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 70 1. The Problem 72 Growth in the IETF's size and diversity challenge its ability to make 73 progress in producing useful specifications. For example, Working 74 Group (WG) efforts often take far too long, and the result of those 75 efforts is sometimes not very useful to the Internet community. 76 These difficulties are sometimes exacerbated by IESG procedures that 77 introduce further delay and ambiguity to the process. 79 This memo proposes seven procedural changes that will improve the 80 Predictability, Accountability, Competency and Timeliness of the IETF 81 ("the IETF Pact"), without altering the IETF's philosophy or 82 structure, and without requiring changes to the formal IETF standards 83 process (cf., RFC 2026 [1]). 85 2. The IETF "PACT" 87 The IETF standards process must exhibit four qualities: 89 Predictability: IETF efforts must not waste time and energy. 91 For example, if the responsible AD has any issue with a Working 92 Group (WG) document, these should be known to the WG long before 93 the document is submitted to the IESG. IESG procedures for 94 documents must be clear and consistent, and the status and 95 progress of documents through the procedures must be visible to 96 all. At any point, it must be clear what the next step is for a 97 document and when that step will be taken. 99 Accountability: Those holding IETF management positions necessarily 100 wield considerable power and the IETF community needs to be able 101 to know who has wielded it and when. 103 Competency: The process must encourage the production of technically 104 competent output; otherwise, we are left with a fair, expeditious, 105 but useless process. 107 Timeliness: Timeliness relates to relevance and quality and, as such, 108 the IETF's work is sensitive to real-world needs. 110 If the IETF process takes too long, the results will be irrelevant 111 and other, less engineered solutions will emerge. Ultimately 112 then, the Internet community will be less dependent on the IETF's 113 work. Finally, longer WG processes often lead to work with less 114 focus and clarity, and the resulting technical specifications are 115 often confusing and laden with questionable features. This makes 116 them more difficult to implement correctly and, again, less likely 117 to have real-world utility. 119 We now present a set of proposed changes to the way the IETF manages 120 its working groups. Each change is presented in two parts: 122 o a philosophy or rational for a change in the IETF's behavior; and, 124 o a corresponding rule to be employed by the IESG. 126 Finally, Appendix A summarizes the proposed rules. 128 In considering these proposals, please keep in mind that the changes 129 being presented do not change the way in which areas are managed 130 according to RFC 2026 [1]; rather these are changes to the IESG 131 management model, which the standards process purposefully leaves to 132 the discretion of the IESG. 134 3. Working Group Operation 136 An IETF working group is for engineering, rather than research or 137 general discussion. Hence a WG must understand what problem it is 138 solving, who will use the solution and how it will be used, and the 139 WG must make near-term progress towards that solution. 141 3.1 The "Utility Focus" model for WGs 143 An IETF working group charter is characterized as a contract between 144 the WG and the IETF. As the IETF has grown larger and more diverse, 145 and as the problems tackled by WGs have grown more ambitious, 146 charters have sometimes become too vague to provide adequate guidance 147 about the goals and scope of the WG. 149 Accordingly, a WG charter must explicitly state: 151 o what problems are to be solved or what specific benefits are 152 intended from the work to be done; 154 o who the intended beneficiaries are (also describing some examples 155 of the use and effect that will accrue from using the capabilities 156 provided by the WG's output); and, 158 o where areas of difficulty are likely to be encountered. 160 3.2 The "Short-term" model for WGs 162 If an effort requires more than 1.5 years to produce something that 163 is ready for IETF last call, then it is not yet ready for the IETF. 164 The effort must do its pre-standards work elsewhere and then come to 165 the IETF when a solution is ready to be standardized. 167 Accordingly, a WG gets no more than 18 months to have their first 168 Internet-Draft (I-D) approved by the IESG; similarly, a WG gets no 169 more than 12 months to have each succeeding document approved by the 170 IESG. 172 4. IETF Operation 174 The IESG must juggle two extremely difficult tasks: 176 o technical oversight; and, 178 o process management. 180 It is essential to retain and support both of these tasks, while also 181 balancing the need to make timely progress. 183 After a document is given to the IESG for approval it can be 184 difficult to ascertain the document's status and how it got there. 185 The procedures that the IESG uses for voting are not well known, and 186 the reasoning behind the IESG's votes are not published. Further, 187 some of the procedures may result in a document being delayed, even 188 if there is a strong consensus in the IESG for it to go forward. As 189 a result, WG chairs and document editors often find themselves in 190 "limbo", where they don't know what to do to move documents through 191 the IETF system. 193 Two complimentary changes can remedy the problem: 195 o a greater emphasis on area focus; and, 197 o a narrower emphasis on what gets evaluated during IETF last call. 199 4.1 The "Area Focus" model for the IESG 201 Each area comprises considerable specialization. Although it is 202 essential to have coordination and collaboration among the areas, it 203 is equally important that the WGs in an area be allowed to focus on 204 their own activities and have their consensus results published. 206 Our philosophy is that whenever the IESG makes any decisions, all ADs 207 get a voice, but no one AD gets a veto. In realizing this, several 208 factors must be balanced. 210 4.1.1 Bounded Discussion 212 It is essential that no AD be able to exercise a "pocket veto". 213 Hence there needs to be a way, within the IESG, to override blockages 214 by individual ADs. 216 Accordingly, once a document is submitted to the IESG for approval, a 217 formal request for further discussion may delay IESG voting on the 218 document until no later than the next IESG meeting. (In other words, 219 there may be at most one request for discussion for the document and 220 any AD may request it.) 222 4.1.2 Proportional Voting 224 Responsible ADs are presumed to be expert in the work under review, 225 both in terms of the technology and their WGs' history. In order to 226 facilitate the efficiency of their work, they must have a 227 disproportionate say in progressing a document. 229 Accordingly, all IESG votes require a minimum of 55% of those voting 230 "yes" to pass; further, the votes of the responsible ADs are weighted 231 to 45% of all votes, with the remaining ADs combining to 55% of all 232 votes. 234 The voting proportions give extra weight to the votes of the 235 Responsible ADs, but permit the remainder of the IESG to override 236 them. 238 For example, let's assume that there are 13 ADs voting and that 2 ADs 239 are responsible for an area: 241 if the two responsible ADs then passage requires 242 ============================= ================================ 243 both vote yes at least 2 other ADs to vote yes 244 both vote no all other ADs to vote yes 245 split (one yes, the other no) at least 7 other ADs to vote yes 247 For example, if both routing ADs vote "yes", then it takes most of 248 the other ADs voting "no" to defeat an action in the routing area. 250 Naturally, the usual checks-and-balances apply, e.g., if an IESG 251 member disapproves of an IESG action, they (like any other IETF 252 member) are free to appeal to the IAB. 254 4.1.3 Vote Explanations 256 In order to give WGs a constructive path towards resolving AD 257 concerns, a WG must know precisely what those concerns are. 258 Requiring publication of IESG rationale for rejecting a document 259 helps ensure IESG accountability when a rejection occurs. 261 Accordingly, if an IESG vote rejects a WG document, then the IESG 262 must publish an explanation prior to the next IESG meeting. If no 263 report is published in that timeframe, then the document is 264 automatically approved. 266 4.1.4 Status Reporting 268 WG documents do not materialize out of the ether -- WGs are granted 269 charters by the IESG, and work under the guidance of an AD when 270 producing their documents. As such, the IESG's decision process 271 should presume a timely, favorable outcome for WG output. 273 Accordingly, the IESG must publish regular reports identifying those 274 actions they have not yet addressed and explaining why. At a 275 minimum, the IESG must publish these reports no later than one month 276 prior to each face-to-face IETF meeting. 278 4.2 The "Bounded Outcome" model for the IETF 280 A document is developed as a sequence of design decisions, as a WG 281 makes progress. Hence the resulting document typically is produced 282 from a substantial number of group consensus assessments. This 283 should create a very strong presumption of community approval for the 284 document. 286 Any document can be criticized for its choices. An IETF effort is 287 designed to resolve engineering choices for one issue and then move 288 to a new issue. It is not reasonable to permit arbitrary criticisms 289 to be raised late in the process, derailing the incremental effort of 290 a WG. 292 It is always reasonable to raise fundamental engineering problems, 293 but it is essential to distinguish these from matters of engineering 294 aesthetics. In particular, the IETF Last Call and IESG review 295 periods are not intended for second-guessing a WG's design choices -- 296 the purpose of an IETF Last Call and IESG review is to focus on the 297 overall viability of the document. 299 Accordingly, When evaluating a document, the IESG should heed 300 comments that identify fundamental engineering problems and should 301 ignore comments that suggest better ways of solving the same problem. 303 5. IANA Considerations 305 This memo does not create any new issues for the IANA. 307 6. Security Considerations 309 To the extent that the proposed changes produce documents that are 310 more timely and simpler, those documents, in theory, should contain 311 fewer security holes. 313 References 315 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 316 9, RFC 2026, October 1996. 318 Authors' Addresses 320 G. Huston 321 Telstra 322 5/490 Northbourne Avenue 323 Dickson, ACT 2602 324 AU 326 EMail: gih@telstra.net 328 Marshall T. Rose 329 Dover Beach Consulting, Inc. 330 POB 255268 331 Sacramento, CA 95865-5268 332 US 334 Phone: +1 916 483 8878 335 EMail: mrose@dbc.mtview.ca.us 337 Appendix A. Summary of Proposed Rules 339 Rule 1: A WG charter must explicitly state: 341 * what problems are to be solved or what specific benefits are 342 intended from the work to be done; 344 * who the intended beneficiaries are (also describing some 345 examples of the use and effect that will accrue from using the 346 capabilities provided by the WG's output); and, 348 * where areas of difficulty are likely to be encountered. 350 Rule 2: A WG gets no more than 18 months to have their first I-D 351 approved by the IESG; similarly, a WG gets no more than 12 months 352 to have each succeeding document approved by the IESG. 354 Rule 3: Once a document is submitted to the IESG for approval, a 355 formal request for further discussion may delay IESG voting on the 356 document until no later than the next IESG meeting. 358 Rule 4: All IESG votes require a minimum of 55% of those voting "yes" 359 to pass; further, the votes of the responsible ADs are weighted to 360 45% of all votes, with the remaining ADs combining to 55% of all 361 votes. 363 Rule 5: If an IESG vote rejects a WG document, then the IESG must 364 publish an explanation prior to the next IESG meeting. If no 365 report is published in that timeframe, then the document is 366 automatically approved. 368 Rule 6: The IESG must publish regular reports identifying those 369 actions they have not yet addressed and explaining why. At a 370 minimum, the IESG must publish these reports no later than one 371 month prior to each face-to-face IETF meeting. 373 Rule 7: When evaluating a document, the IESG should heed comments 374 that identify fundamental engineering problems and should ignore 375 comments that suggest better ways of solving the same problem. 377 Full Copyright Statement 379 Copyright (C) The Internet Society (2002). All Rights Reserved. 381 This document and translations of it may be copied and furnished to 382 others, and derivative works that comment on or otherwise explain it 383 or assist in its implementation may be prepared, copied, published 384 and distributed, in whole or in part, without restriction of any 385 kind, provided that the above copyright notice and this paragraph are 386 included on all such copies and derivative works. However, this 387 document itself may not be modified in any way, such as by removing 388 the copyright notice or references to the Internet Society or other 389 Internet organizations, except as needed for the purpose of 390 developing Internet standards in which case the procedures for 391 copyrights defined in the Internet Standards process must be 392 followed, or as required to translate it into languages other than 393 English. 395 The limited permissions granted above are perpetual and will not be 396 revoked by the Internet Society or its successors or assigns. 398 This document and the information contained herein is provided on an 399 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 400 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 401 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 402 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 403 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Acknowledgement 407 Funding for the RFC Editor function is currently provided by the 408 Internet Society.