idnits 2.17.1 draft-hardie-alt-consensus-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 boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 482), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 482. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 530 lines 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 53 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 271 has weird spacing: '...xcluded from ...' -- 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 (April 2004) is 7308 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Internet-Draft Qualcomm, Inc. 3 Category: Experimental April 2004 5 Alternative Decision Making Processes 6 for Consensus-blocked Decisions in the IETF 7 draft-hardie-alt-consensus-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 14 with RFC 3668. 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 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 . 29 The list of Internet-Draft Shadow Directories can be accessed at 30 . 32 This Internet-Draft will expire in September 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document proposes an experimental set of alternative 41 decision-making processes for use in IETF working groups. There 42 are a small number of cases in IETF working groups in which the 43 group has come to consensus that a particular decision must be made 44 but cannot come to consensus on the decision itself. This document 45 describes alternative mechanisms which can be used to come to a 46 decision in those cases. This is not meant to provide an exhaustive 47 list, but to provide a known set of tools which can be used when 48 required. 50 1. Introduction. 52 Dave Clark's much-quoted credo for the IETF cites "rough consensus 53 and running code" as the key criteria for decision making in the 54 IETF. Aside from a pleasing alliteration, these two touchstones 55 provide a concise summary of the ideals which guide the IETF's 56 decision making. The first implies an open process in which any 57 technical opinion will be heard and any participant's concerns 58 addressed; the second implies a recognition that any decision must 59 be grounded in solid engineering and the known characteristics of 60 the network and its uses. The aim of the IETF is to make the best 61 possible engineering choices and protocol standards for the 62 Internet as a whole, and these two statements guide it in making 63 its choices and standards. 65 In a small number of cases, working groups within the IETF cannot 66 reach consensus on a technical decision which must be made in order 67 to ensure that an interoperable mechanism or set of standards is 68 available in some sphere. In most of these cases, there are two or 69 more competing proposals at approximately the same level of 70 technical maturity, deployment, and specification. In some cases, 71 working groups can achieve consensus to advance multiple proposals 72 and to either revisit the question when experienced has been gained or 73 to build the required mechanisms to handle multiple options for 74 the life of the protocol. In other cases, however, a working group 75 decides that it must advance a single proposal. Choosing among 76 these proposals can be especially difficult when each is optimized 77 for slightly different use cases, as this implies that the working 78 group's best choice depends on the participants' views of likely 79 future use. Further problems arise when different proposals assign 80 costs in implementation, deployment, or use to different groups, as 81 it is a normal human reaction to seek to prevent one's own ox 82 being gored. 84 This document puts forward a set of experimental mechanisms which 85 for use in that small number of cases. In order to gauge the 86 results of those cases where one of these mechanisms is used, it is 87 suggested that the Last Call issued to the IETF community note that 88 such a mechanism was used and which one of the set was chosen. If 89 and when the community becomes satisfied that one or more of these 90 methods is useful, it should be documented in a BCP for that small 91 number of cases. 93 In no way should this experiment or any future BCP for this small 94 number of cases take precendence over the IETF's normal mode of 95 operation. 97 2. Rough Consensus as a baseline approach. 99 The Conflict Research Consortium at the University of Colorado 100 outlines the pros and cons of consensus as: 102 The advantage of consensus processes is that the resulting 103 decision is one that meets the interests of all the parties and 104 that everyone can support. The disadvantage is that developing 105 such a decision can be a very slow process, involving many 106 people over a long period of time. There is also a relatively 107 high probability of failure. If a quick decision is needed, the 108 consensus approach may not work. Consensus rule processes also 109 tend to favor those that oppose change and want to preserve the 110 status quo. All these people have to do is refuse to support 111 any consensus compromises and they will win (at least as long 112 as they can delay change). (CONFLICT) 114 Using "rough consensus" as a guideline limits some of disadvantages 115 of consensus processes by ensuring that individuals or small 116 factions cannot easily block a decision which has otherwise general 117 support. The second touchstone of "running code" can also limit 118 the disadvantages of consensus processes by requiring that 119 statements opposing particular proposals be technically grounded. 121 These limitations do not change the core mechanisms of 122 consensus-building, however, and the IETF process continues to 123 require individual participants both to use their best engineering 124 judgment to select among proposals and to balance their own 125 interests with those of the Internet as a whole. Active 126 participation and a willingness to compromise, possibly on key 127 points, are needed. Historically, this has worked because a large 128 majority of participants have recognized that the Internet's growth 129 and enhancement are more important overall than any specific 130 short-term advantage. 132 In other words, the use of "rough consensus" is sufficient in most 133 cases in the IETF to ensure that individuals or small groups are 134 heard when they raise technical objections, but that they cannot 135 block progress when a general agreement has been reached. This 136 document does not suggest changing the usual mechanisms for 137 achieving forward progress; it proposes mechanisms for use when a 138 working group has consensus that it must make a decision, but it 139 cannot make that decision by the usual rules. 141 3. Conditions for use. 143 In general, working groups should consider using alternate decision 144 making processes when it is clear both that a choice must be made 145 and that the choice cannot be made by continued discussion, 146 refinement of specifications, and implementation experience. A 147 guideline for determining that these conditions have been met is 148 included below. 150 3.1 There is a clear decision to be reached. 152 There must be a clear statement of the decision to be reached. 153 This may be in the working group's charter, in requirements 154 documents, or in other documents developed by the working group. 155 Prior to any invocation of an alternate decision making process, 156 the Chair(s) should confirm with the working group that there is 157 general agreement on the decision to be reached. This should 158 include a specific consensus call on whether the working group 159 can advance multiple proposals or must select a single proposal 160 for the work item. 162 3.2 Proposals are available in draft form. 164 Proposed solutions must be available as Internet drafts and must be 165 sufficiently specified to cause the Chair(s) to believe that they 166 could be, possibly with further refinement, published as an IETF 167 specification. If the Chair indicates to those proposing a 168 solution that it is insufficiently specified, concrete problems to 169 be resolved must be identified and a reasonable amount of time 170 provided to resolve those problems. Note that if one of the 171 proposed solutions is "do nothing", an explicit draft to that 172 effect must be available; it may, however, be produced when the 173 group invokes an alternate decision making process. 175 3.3 The working group has discussed the issue without reaching 176 resolution. 178 Consensus-building requires significant amounts of discussion, and 179 there is no general rule for indicating how much discussion a 180 technical issue requires before a group should reach consensus. If 181 there is any question about whether the discussion has been 182 sufficient, the working group chair(s) should always err on the 183 side of allowing discussion to continue. Before using an alternate 184 decision making process, the working group chair(s) should also 185 make an explicit call for consensus, summarizing the technical 186 issues and the choice to be made. If new technical points are made 187 during the call for consensus, discussion should continue. If no 188 new points are raised, but the group cannot come to consensus, the 189 working group may consider using an alternate decision making 190 process. Under no circumstances is the working group required to 191 use an alternate decision making process. 193 3.4 There is an explicit working group last call to use an alternate 194 method. 196 In item 3.3 above, it is noted that the Chair(s) should make an 197 explicit call for consensus on the technical issues and should 198 proceed only after that call has yielded no forward progress. A 199 different last call on the question of whether to use an alternate 200 decision making method is required, with a stated period for 201 comments by working group members. This is to indicate that 202 the decision to use an alternate method should be taken at least as 203 seriously as the decision to advance a document on the standards 204 track. It also provides a clear signal that this is a last moment for 205 participants to reconsider their positions. The decision to use an 206 alternate decision making process requires the rough consensus of 207 the working group, as determined by the Chair(s). The choice of which 208 alternate decision to use may be made in the last call or may be the 209 subject of separate discussions within the working group. If the 210 group comes to consensus that an alternative method is required but 211 does not come to consensus on the method to use, an external review 212 team (c.f. section 4.1, below) will be formed. 214 In discussions of this draft, several points have been raised about 215 the viability of any mechanism that requires consensus to use 216 an alternative to consensus-based decision making. Some of those 217 concerns pointed out that groups having trouble achieving consensus 218 on the technical matter may have similar problems achieving 219 consensus on the procedural matter. Others have been concerned 220 that this will be used as an attempt to end-run rough consensus. 221 These are all valid concerns, and they point both to the need 222 to retain rough consensus as the baseline mechanism and to exercise 223 caution when using these alternate methods. More importantly, 224 though, they highlight the nature of these alternatives. They 225 are primarily mechanisms that allow people to see the need for 226 compromise in a new way, to back away from entrenched technical 227 positions by putting the technical choice in the hands of the 228 broader community, and to highlight that the choice for each 229 participant is now between achieving *a* decision and failure. 231 There is a fundamental tension between the IETF community's 232 desire to get the best decision for a particular technical 233 problem and the IETF community's desire to get a decision that 234 has community buy-in in the form of rough consensus. These 235 mechanisms cannot resolve that fundamental tension. They may, 236 however, provide a way forward in some situations which might 237 otherwise end in deadlock or stagnation. 239 4. Alternate methods. 241 In setting up an alternate method, care must be given that the 242 process by which the decision is reached remains open and remains 243 focused on making the best technical choice for the Internet as a 244 whole. The steps set out below provide a straw proposal for four 245 such mechanisms. These are relatively heavy weight systems, 246 partially to highlight the gravity of choosing to invoke these 247 methods and partially to ensure that the IETF community as a whole 248 is alerted to and kept informed of the process. Note that 249 alternate procedures have been used in the past; see RFC 3127 250 (RFC3127) for a description of that used in the decision between 251 two competing candidate protocols for Authentication, Authorization 252 and Accounting. By setting out these proposals, this document does 253 not intend to limit working group choice, but to provide a set of 254 well defined processes that obviate the need for reinvention in 255 most cases. 257 4.1 Alternate method one; external review team formation. 259 The working group notifies the IETF community that it intends to 260 form an external review team by making a public announcement on the 261 IETF-announce mailing list. That announcement should include a 262 summary of the issue to be decided and a list of the 263 internet-drafts which contain the alternate proposals. It should 264 also include the name and location of an archived mailing list for 265 the external review team's deliberations. 267 4.1.1 External review team membership. 269 External review teams have five members who must meet the same 270 eligibility requirements as those set out a voting member of the 271 NomCom (2727bis). Explicitly excluded from participation in 272 external review teams are all those who have contributed 273 to the relevant working group mailing list within the previous 12 274 months, the IESG, the IAB, and the sitting NomCom. 276 Volunteers to serve on the review team send their names to the 277 IETF executive director. Should more than five volunteer, five 278 are selected according to the process outlined in RFC2777(RFC2777) 279 note that the same rules on affiliation apply here as to the NomCom, 280 to reduce the burden on any one organization and to remove any 281 implication of "packing" the review team. 283 Participants in the working group may actively solicit others to 284 volunteer to serve on the review team but, as noted above, they may 285 not serve themselves if they have commented on the list within the 286 previous 12 months. 288 4.1.2 External review team deliberation. 290 The external review team is alloted one month for deliberations and 291 any member of the team may extend that allotment by two weeks by 292 notifying the relevant working group Chair(s) that the extension 293 will be required. 295 The team commits to reading the summary provided during the IETF 296 announcement and all of the relevant Internet drafts. Members may 297 also read the archived mailing list of the working group, and they 298 may solicit clarifications from the document authors, the working 299 group chairs, or any other technical experts they see fit. All 300 such solicitations and all deliberations among the review team of 301 the proposals should take place on the archived mailing list 302 mentioned in the IETF announcement. The team members may, of 303 course, have one-on-one discussions with relevant individuals by 304 phone, email, or in person, but group deliberations should be on 305 the archived list. 307 4.1.3. Decision statements. 309 Each member of the external review team writes a short decision 310 statement, limited to one page. That decision statement contains a 311 list of the proposals in preference order. It may also contain a 312 summary of the review team member's analysis of the problem and 313 proposed solutions, but this is not required. These decision 314 statements are sent to the archived mailing list, the relevant 315 working group chair(s), and the IESG. 317 4.1.4 Decision statement processing. 319 The Decision statements will be tallied according to 320 "instant-runoff voting" rules, also known as "preference voting" 321 rules (VOTE). 323 4.2 Alternate method two; mixed review team. 325 This mechanism allows for the working group to designate a review 326 team that involves those outside the working group as well as those 327 who have been involved in the process within the working group. 328 While it may appear that having a single representative of each 329 proposal will have a null effect on the outcome, this unlikely to 330 be the case except when there is a binary choice, because of the 331 rules for decision statement processing (c.f. 4.2.4 below). As in 332 4.1, the working group notifies the IETF community that it intends 333 to form a mixed review team by making a public announcement on the 334 IETF-announce mailing list. That announcement should include a 335 summary of the issue to be decided and a list of the 336 internet-drafts which contain the alternate proposals. It should 337 also include the name and location of an archived mailing list for 338 the external review team's deliberations. 340 4.2.1 Mixed review team membership. 342 Mixed review teams are composed of one designated representative of 343 each of the proposals, typically the Internet draft's principal 344 author, and six external members. Five of the external members are 345 selected as according 4.1.1. above. The sixth is designated by the 346 IESG as a chair of the group. Though the primary role of the chair 347 is to ensure that the process is followed, she or he may vote and 348 engage in the deliberations. 350 4.2.2 Mixed review team deliberation. 352 The review team is alloted one month for its deliberations and any 353 member of the team may extend that allotment by two weeks by 354 notifying the review team Chair that the extension will be 355 required. 357 The review team commits to reading the summary provided during the 358 IETF announcement and all of the relevant Internet drafts. Members 359 may also read the archived mailing list of the working group, and 360 any other technical experts they see fit. All such solicitations 361 and all deliberations among the review team of the proposals should 362 take place on the archived mailing list mentioned in the IETF 363 announcement. 365 4.2.3 Decision statements. 367 As in 4.1.3, above. 369 4.2.4 Decision statement processing. 371 As in 4.1.4, above. 373 4.3 Alternate method three; qualified short-straw selection. 375 As in 4.1 and 4.2, the working group notifies the IETF community 376 that it plans to use an alternate decision mechanism by making a 377 public announcement on the IETF-announce mailing list. That 378 announcement should include a summary of the issue to be decided 379 and a list of the Internet-drafts which contain the alternate 380 proposals. 382 In this method, a single working group participant is selected to 383 make the decision. Any individual who has contributed to the 384 working group in the twelve months prior to the working group last 385 call on the technical question (c.f. 3.3, above) may volunteer to 386 serve as the decision maker. Individuals may qualify as 387 participants by having made a public statement on the working group 388 mailing list, serving as an author for an Internet draft under 389 consideration by the working group, or making a minuted comment in 390 a public meeting of the working group. The Chair(s) may not 391 volunteer. Each qualified volunteer sends her or his name to the 392 working group chair and the IETF Executive Director within 3 weeks 393 of the announcement sent to the IETF-announce mailing list. The 394 IETF Executive Director then uses the selection procedures 395 described in RFC2777 to select a single volunteer from the list. 396 That volunteer decides the issue by naming the internet-draft 397 containing the selected proposal in an email to the relevant 398 working group chair, the working mailing list, and the IESG. 400 4.4 Alternate method four; random assignment. 402 Among the small number of cases for which consensus in not an 403 appropriate method of decision-making are a tiny minority for which 404 the decision involves no technical points at all, but involves the 405 need to select among options randomly. The IDN working group, as 406 an example, needed to designate a specific DNS prefix. As the 407 decision involved early access to a scarce resource, a random 408 selection was required. In such cases, a working group may ask 409 IANA to make a random assignment from among a set of clearly 410 delineated values. Under such circumstances, IANA will be guided 411 by RFC2777 in its selection procedures. Under extraordinary 412 circumstance, the working group may, with the approval of the IESG, 413 ask IANA to select among a pool of Internet Drafts in this way. 415 5. Appeals. 417 The technical decisions made by these processes may be appealed 418 according to the same rules as any other working group decision, 419 with the explicit caveat that the working group's consensus to use 420 an alternate method stands in for the working group's consensus on 421 the technical issue. 423 6. Security Considerations. 425 The risk to moving to a system like this is that it shifts the 426 basis of decision making within the IETF. The hope in providing 427 these mechanisms is that certain decisions which may be intractable 428 under consensus rules may be tractable under the rules set out 429 here. The risk, of course, is that forcing the evaluation to occur 430 under these rules may allow some set of individuals to game the 431 system. 433 7. IANA Considerations. 435 Section 4.3 may require the IANA to make random selections among a 436 known set of alternates. 438 8. Normative References 440 Eastlake, Donald 3rd. "Publicly Verifiable Nomcom Random Selection", 441 RFC2777. 442 (RFC2727) 444 J. Galvin, Ed. "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees". 445 draft-ietf-nomcom-rfc2727bis-09.txt (2727bis). 447 9. Non-Normative References 449 Mitton, D. et al. "Authentication, Authorization, and Accounting: 450 Protocol Evaluation", RFC3127. (RFC3127) 452 Center for Democracy and Voting. "Frequently Asked Questions about 453 IRV", http://www.fairvote.org/irv/faq.htm . (VOTE) 455 International Online Training Program on Intractable 456 Conflict,"Consensus Rule Processes", 457 Conflict Research Consortium, University of Colorado, USA. 458 http://www.colorado.edu/conflict/peace/treatment/consenpr.htm 459 (CONFLICT) 461 10. Acknowledgements 463 The author would like to acknowledge the contributions and 464 challenging exchanges of reviewers of this draft, among them 465 John Klensin, Dave Crocker, Pete Resnick, Spencer Dawkins, 466 Scott Bradner, Joel Halpern, Avri Dora, Melinda Shore, Harald 467 Alvestrand, Alex Simonelis, Keith Moore, Brian Carpenter, 468 and Alex Rousskov. 470 11. Author's Address 472 Ted Hardie 473 Qualcomm, Inc. 474 675 Campbell Technology Parkway 475 Suite 200 476 Campbell, CA U.S.A. 478 EMail: hardie@qualcomm.com 480 Full Copyright Statement 482 Copyright (C) The Internet Society (2003). All Rights Reserved. 484 This document and translations of it may be copied and furnished to 485 others, and derivative works that comment on or otherwise explain 486 it or assist in its implementation may be prepared, copied, 487 published and distributed, in whole or in part, without restriction 488 of any kind, provided that the above copyright notice and this 489 paragraph are included on all such copies and derivative works. 490 However, this document itself may not be modified in any way, such 491 as by removing the copyright notice or references to the Internet 492 Society or other Internet organizations, except as needed for the 493 purpose of developing Internet standards in which case the 494 procedures for copyrights defined in the Internet Standards process 495 must be followed, or as required to translate it into languages 496 other than English. 498 The limited permissions granted above are perpetual and will not be 499 revoked by the Internet Society or its successors or assigns. 501 This document and the information contained herein is provided on 502 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 503 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 504 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 505 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 506 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 508 Acknowledgement 510 Funding for the RFC Editor function is currently provided by the 511 Internet Society.