idnits 2.17.1 draft-dusseault-consensus-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1104. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1117. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 634: '...tion is that clients MAY resubmit, and...' RFC 2119 keyword, line 635: '... servers MAY accept or reject res...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (December 4, 2007) is 5980 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3184 (Obsoleted by RFC 7154) -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Dusseault 3 Internet-Draft CommerceNet 4 Intended status: Informational December 4, 2007 5 Expires: June 6, 2008 7 Notes on IETF Rough Consensus 8 draft-dusseault-consensus-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 6, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The IETF makes decisions using what we refer to as rough consensus, 42 using a great deal of flexibility and judgement depending on the 43 situation. This document documents various approaches to determining 44 rough consensus. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1. Comparing Decision-Making Processes . . . . . . . . . . . 4 52 2.2. Consensus as a Process . . . . . . . . . . . . . . . . . . 5 53 2.3. Informality . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.4. Who may participate . . . . . . . . . . . . . . . . . . . 6 55 2.5. When Silence is Consent . . . . . . . . . . . . . . . . . 7 56 2.6. Questionable tactics in consensus calls . . . . . . . . . 8 57 2.7. Backroom dealing . . . . . . . . . . . . . . . . . . . . . 9 58 3. Consensus calls in meeting rooms . . . . . . . . . . . . . . . 9 59 3.1. Easy consensus calls . . . . . . . . . . . . . . . . . . . 11 60 3.2. Fine-tuning consensus calls . . . . . . . . . . . . . . . 11 61 3.3. Chains of consensus calls . . . . . . . . . . . . . . . . 12 62 4. Consensus Calls in Mailing Lists . . . . . . . . . . . . . . . 13 63 4.1. Sample effective consensus call on-list . . . . . . . . . 13 64 4.2. Declaring consensus on-list . . . . . . . . . . . . . . . 14 65 4.3. Confirming in-room consensus on Mailing List . . . . . . . 14 66 5. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 15 67 5.1. Taking Time . . . . . . . . . . . . . . . . . . . . . . . 15 68 5.2. Deciding to Make a Decision . . . . . . . . . . . . . . . 16 69 5.3. Using votes and plurality decision-making . . . . . . . . 16 70 5.4. Let the Editor Choose . . . . . . . . . . . . . . . . . . 17 71 5.5. Flipping a coin . . . . . . . . . . . . . . . . . . . . . 17 72 6. Accountability . . . . . . . . . . . . . . . . . . . . . . . . 17 73 6.1. Challenging Consensus Call Results . . . . . . . . . . . . 18 74 6.2. Sample challenge to a mailing list consensus call . . . . 19 75 6.3. Overturning Consensus Call Outcomes . . . . . . . . . . . 19 76 7. Recommendations for Individual Participants . . . . . . . . . 20 77 7.1. What if you don't agree? . . . . . . . . . . . . . . . . . 20 78 7.2. Avoiding blocked consensus . . . . . . . . . . . . . . . . 21 79 7.3. Questioning the process . . . . . . . . . . . . . . . . . 21 80 7.4. Final tips . . . . . . . . . . . . . . . . . . . . . . . . 22 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 11. Informative References . . . . . . . . . . . . . . . . . . . . 23 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 Intellectual Property and Copyright Statements . . . . . . . . . . 24 88 1. Introduction 90 Consensus is a way for people to make decisions and generate 91 commitment to those decisions. Coming to decisions by consensus is 92 difficult and time-consuming. It's a much broader and more flexible 93 process than simply picking a position and seeing if everybody 94 agrees. The process cannot be reduced to an algorithm; consensus is 95 complex, human and messy. We choose skilled people to help us come 96 to consensus, and they do so based on their experience and judgement. 98 The IETF has much folklore about its "rough" consensus. Many people, 99 not just chairs, make statements about a group's consensus. There 100 are many opinions about what approaches are OK or not in determining 101 consensus. The IETF also has some unique approaches to determining 102 consensus, including "hums" taken to gauge consensus in meeting rooms 103 by volume of sound generated. 105 This document attempts to provide detail on how rough consensus works 106 on IETF mailing lists and in IETF meetings, with some suggestions for 107 dealing with exceptions and difficult cases. The "Alternative 108 Decision Making Process for Consensus Blocked Decisions" described in 109 [RFC3929] contains valuable approaches for certain difficult cases. 110 In contrast, this document describes more of the common context and 111 practice of the IETF. The reader is particularly recommended to read 112 Section 2 of [RFC3929]. 114 Most of the information here can be construed as either advice and 115 ideas for chairs or an explanation for participants of what they 116 might see. The last section is advice for individual participants. 118 Information provided here is not intended to create any IETF process 119 requirements that are not already extant: nor is there any intent to 120 limit chairs from trying other approaches. There are many ways to 121 develop and determine rough consensus. In choosing approaches, 122 chairs need be guided the goals of the Internet Standards Process in 123 [RFC2026]. There are many difficult tradeoffs. 125 1.1. Terminology 127 The word "chair" is used in this document to identify the person 128 running the consensus call. Sometimes this person is not the Working 129 Gropu (WG) chair. The phrase "WG chair" or "meeting chair" is used 130 when it's necessary to be specific about context. 132 The word "vote" is used informally in this specification and doesn't 133 usually imply formal vote counting -- it's just that the phrase "to 134 vote" is shorter than "to express one's preference on the mailing 135 list or in a meeting room". 137 2. Consensus 139 This section discusses what consensus is, including some of the 140 subtler ways consensus differs from voting, what silence means in 141 consensus, and a couple areas that are sometimes problematic. 143 2.1. Comparing Decision-Making Processes 145 Formal, classic consensus cultures [BUJ] are rather rare. They can 146 be found in quite a few intentional communities and in a small number 147 of boards, committees and project teams. In many thriving consensus 148 cultures, any veto by any member really can, and does, block decision 149 making until some opinion or proposal changes. 151 There are many organizations that do weak consensus; they prefer to 152 get consensus but not if it's too difficult. These organizations may 153 depart from formal consensus by limiting who can veto, by limiting 154 who can make proposals or how many proposals there can be, by 155 limiting discussion that might lead to new proposals or consensus 156 changes, or by having fallback non-consensus processes (e.g. the 157 development manager decides) when consensus takes too long. 159 Parliamentary rules such as Robert's Rules of Order are not part of 160 most consensus processes. They are not formally used in the IETF, 161 although some parliamentary rules are adopted ad-hoc as useful 162 habits. One notable difference from many parliamentary rules sets is 163 that the chair of an IETF group or meeting may vote. 165 Majority rule is common, easy and fast. However, it often compares a 166 limited and closed set of proposals. In the worst case, time 167 pressure (real or imagined) could cause a group to do a vote on the 168 first proposal at hand, which could pass by a slim margin despite the 169 suspicion of a few participants that it has flaws. Technical 170 excellence requires the creative exploration of alternatives. A 171 consensus process doesn't guarantee creativity, but it does encourage 172 it. It's up to chairs (with help from participants) to note when an 173 important decision is at hand, and wait for multiple proposals before 174 calling for a decision. 176 Another problem with majority rule systems, in the context of the 177 IETF, is they tend to involve competition in 'winning' a vote. Since 178 IETF standards are only adopted voluntarily by implementors, that 179 means that adversarial position-taking can hamper the acceptance and 180 adoption of a standard. 182 Building United Judgement [BUJ] has extensive discussion and examples 183 comparing majority rule to consensus. 185 2.2. Consensus as a Process 187 Consensus is not simply a decision. It can't entirely be described 188 in a moment in time despite the immediacy of our hums; it's an 189 evolving balance. The hum is a snapshot of the current state of the 190 evolving consensus among the present population. A chair pays 191 attention to the whole changing picture to decide whether there is 192 already a consensus, whether more discussion is needed, and when to 193 do a formal call for consensus. 195 A chair must continue to pay attention to the balance after a 196 consensus call to see if it has shifted and if that's important 197 enough to go back and fix. 199 A chair can weight the balance according to the experience of those 200 offering views and whether there have been convincing arguments about 201 some option simply not working. We allow and value input from those 202 with experience and those without, but the "running code" part of the 203 catchy "rough consensus and running code" phrase means that we pay 204 special attention to input based on implementation experience. It's 205 good if the chair can make this explicit: 207 "I think we've heard a convincing argument from Aaron that this 208 leaves servers open to DOS attacks, so I conclude this feature 209 can't be added as-is." 211 2.3. Informality 213 Consensus is not always formally called or determined. Sometimes 214 draft editors (or authors) ask for opinions to help decide what to 215 write. Sometimes editors make assumptions about what the consensus 216 is. If the editor gets the sense of consensus right, there may be no 217 need to do a formal consensus call. If the editor at least takes a 218 reasonable stab at sensing the consensus there should be no reason 219 for reproach. If there's a problem, anybody can ask the WG chair to 220 do an explicit consensus call. 222 In meetings, it's not always the meeting chair who asks for consensus 223 and figures out how to word the question. It can be anybody who 224 thinks they have grasped the issue and is helping by asking for 225 consensus. In these cases it's polite to turn to the meeting chair 226 to state the outcome, but sometimes in difficult cases the meeting 227 chair turns to respected, experienced or unbiased members of the 228 community to help determine the outcome of a consensus call. 230 Votes on a mailing list may be simply "+1" or may express misgivings 231 or caveats, and it's up to the chair to interpret or ask for 232 clarification. Votes in a meeting room are often hums, but sometimes 233 the chair asks for hands to be raised instead, or simply interprets a 234 bunch of negative comments at the microphone as demonstrating a 235 consensus against a proposal. 237 2.4. Who may participate 239 The IETF is extremely open about allowing participation in consensus 240 calls. You may see some of the following: 242 1. A hum from a person in a meeting room who does not follow the 243 list. 245 2. A mailing list vote from a person who is not subscribed to the 246 list. 248 Note that it may be impossible to determine that somebody does not 249 read the list -- lists may be read through the list archive site or 250 mailing list mirror services. 252 3. Multiple votes, whether the same or different, from multiple 253 people from the same organization. 255 4. An individual deferring to somebody else in their organization 256 who has already voted. 258 We count individuals at the IETF, not organizations, but don't force 259 everybody to vote. 261 5. Votes in the jabber room during a meeting. 263 6. Votes at the microphone, in Jabber, by humming and on the list 264 -- even from the same person. 266 We rely on chairs to roughly adjust for repeat voting. We don't 267 encourage this, but we allow it because we hope that people explain 268 their preference each time apart from the hum. 270 7. Votes from chairs, ADs, secretaries, document authors and 271 editors. 273 Sometimes the author's vote is implicit in their proposal but we 274 don't stop them from voting. 276 When chairs do contribute their own opinions to a debate (which is 277 not required but is certainly allowed) it helps to be explicit. 278 Example: 280 "Chair hat OFF: I don't like requiring resolvability, it gives no 281 benefit beyond uniqueness which we have already. Chair hat ON: So 282 far I see only weak support for resolvability, and several against 283 it, so I don't think we have consensus to add that to the spec so 284 far. " 286 2.5. When Silence is Consent 288 One way of calling consensus is to summarize what might be the 289 consensus position (e.g. to accept a particular proposal) and 290 explicitly ask the group if there are any objections. This is a 291 little different from calling consensus when two alternatives are 292 provided, because the WG chair may assume that a lack of clear 293 objections constitutes approval of the consensus call as stated. 294 Obviously a chair can steer consensus towards proposals in this way, 295 but the IETF tries to pick chairs who have technical and engineering 296 judgement in order to help us reach quick decisions when it's 297 appropriate. 299 When a consensus call in the meeting room has a clear result and the 300 result is minuted and posted to the mailing list, silence can be 301 taken to mean consent -- the consensus has been confirmed. WG 302 participants who cannot make it to a meeting are given ample 303 opportunities (Jabber participation, audio feeds and minutes on the 304 list) to learn about the consensus call and raise objections. 306 One situation that might be abused is when 20% of a WG favour one 307 approach, 20% favour another, and the rest are silent. It is 308 possible to construct questions in a biased manner so that the chair 309 assumes that the silent majority agree with the approach the chair 310 favours. In meeting rooms we frequently ask for "hums for" and "hums 311 against" in order to make sure that we don't see consensus where 312 there is none (or even "hums for option A", "hums for option B", 313 "don't care" and "something else"). On mailing lists it's easier for 314 people to advocate directly for the the outcome they think best so we 315 don't typically ask both sides of the question. Chairs try to be 316 responsible about seeing when the group's expressed opinion is 317 balanced and try to get more input or encourage further discussion. 319 Sometimes silence means disinterest. On the principle that 320 unimportant work crowds out the attention available for important 321 work, the IETF should not in general encourage much time spent on 322 unimportant work. To help make that happen, chairs need to determine 323 how important a proposal is before accepting it as a WG work item. 324 It's not enough for an author to explain a proposal and answer a few 325 questions; there must also be enough explicit interest to adopt a 326 work item. It's up to the WG chair to be the bad guy if necessary 327 and tell the author that there is not a strong enough consensus to 328 adopt the work item. 330 The same principle can be applied to new features suggested for 331 addition, or even to features which are part of an important proposal 332 (when the specification can be simplified without reducing its 333 utility). 335 Here's an example from real life of an issue where the person who 336 raised the issue only suggested a problem with text, not a 337 resolution. The issue was resolved with the text unchanged because 338 of silence. In this case, the chair usefully made this explicit 339 rather than implicitly allowing the text to remain unchanged. 341 "There has been no additional discussion on this issue since draft 342 -02 came out. This issue is now considered closed. 344 2.6. Questionable tactics in consensus calls 346 Once in a while the IETF also sees what may appear to be attempts to 347 stack a vote. Some possibilities: 349 1. bringing extra people to a meeting to hum on cue 351 2. causing extra participants (perhaps even dummy accounts) to voice 352 opinions in a Jabber room or mailing list 354 3. humming into the microphone 356 4. very loud humming 358 We can't always tell if these are inappropriate or intentional. Case 359 1 might appear to arise when experts in a security technology come to 360 offer an opinion on the security choices in a WG they don't normally 361 participate in. This may create a difficult situation for the chair 362 to overcome, but these are still valid and appropriate community 363 opinions. Case 4 actually illustrates one of the strengths of 364 humming, because it allows us to express and hear urgency and 365 strength of feeling in both directions (chairs have at times heard 366 such apathetic hums about how a feature should work that they 367 proposed dropping the feature). 369 If there is a suspicion of foul play, the chair can quickly ask for 370 participants to behave better and call for consensus again, or even 371 repeat the call later on a mailing list. However, the chair is not 372 required to overturn a consensus just because of accusations of foul 373 play. Because of the many ways that IETF consensus calls can 374 possibly be gamed, chairs must at times make judgement calls about 375 what the consensus really is rather than have it be mechanically 376 tallied. 378 Working group participants are advised to keep their mouths closed 379 while humming, as it not only encourages fair humming but is also 380 more attractive. 382 2.7. Backroom dealing 384 When a small number of people get together for a technical 385 conversation, and information learned in this conversation informs 386 their opinions and proposals in meetings and on the public mailing 387 lists, we generally consider this to be a *good* thing. Sometimes 388 it's easier to explore an idea or explain a difficult point in small 389 groups. Chairs and ADs frequently interact with small groups of 390 participants in order to break down a consensus block or solve an 391 issue that's not getting far on the mailing list. Often the outcome 392 of such a conversation becomes quite naturally public even though the 393 conversation itself wasn't. Sometimes the conversation remains 394 private because to relate it publicly would be tedious, pointless or 395 somehow harmful. 397 As always, it's up to everybody involved to balance openness with 398 other values including fairness, efficiency and technical 399 correctness. 401 Note also that the IETF has rules about design teams [RFC2418]. 403 3. Consensus calls in meeting rooms 405 We know from organizational psychology research that in-person 406 decision-making has different characteristics than computer-mediated 407 decision-making. Some examples: 409 o When we evaluate hums and hand-raising compared to email votes, we 410 use much different cognitive tools. In-person voting is nearly 411 instantaneous and relies on visual and auditory impressions, 412 whereas email voting relies on interpretation, abstraction and 413 memory. 415 o Emotional influence is probably stronger in meeting rooms. On the 416 one hand, there may be more pressure to conform (probably bad when 417 technical judgement is needed). On the other hand, there may be 418 valuable information channels in meeting rooms that we just don't 419 have access to in email, such as judging when somebody is 420 uncertain about a statement or position. 422 o Email tends to polarize and is prone to flames [AA]. 424 o Groups that solve problems in-person tend to share more hidden 425 information than computer-mediated groups [Hol]. 427 The IETF approach is to combine computer-mediated distributed 428 interactions with in-person meetings. Sometimes a protracted on-list 429 argument can be resolved by bringing participants together. 431 In meeting room consensus calls, we always assume we are asking for a 432 complete sense of the room, not just new votes. This is quite 433 different from mailing list consensus calls discussed shortly, where 434 frequently chairs solicit only new opinions or information. 436 Chairs frequently ask who has read a document before doing a 437 consensus call related to that document. This can be useful for a 438 number of reasons: 440 o Can weigh opinions from informed partipants more heavily 442 o Might shame people who haven't read documents from expressing 443 uninformed opinions in the first place 445 o Can gauge if there is enough expertise to even ask the consensus 446 question and expect a good result 448 o Can gauge if there's insufficient interest for the work in the 449 first place 451 Once the consensus call is made, the creative discussion of 452 alternatives is over at least for the time being. If a participant 453 has a new contribution -- a new alternative, a flaw in one of the 454 alternatives or a new reason to consider one of the alternatives 455 better -- this should be brought to the attention of the chair as a 456 polite interrupt if time permits. 458 Chairs often pay careful attention to the wording of consensus calls 459 in meetings, as do attendees. Once in a while, nuances the wording 460 of the alternatives makes a significant difference in outcome. 462 For the minutes, jabber logs and audio recording, the chair should 463 state the outcome after the consensus call (in particular, raised 464 hands cannot be seen via jabber or audio feeds). Even though hums 465 taken in meetings can be confirmed or not on the mailing lists (see 466 section 4.3), chairs sometime state the consensus as if it were 467 final. We also see phrases like "The Bar BoF consensus was..." which 468 is obviously also limited to the participants of the Bar BoF, not to 469 an official WG. Since this is often simply a shorthand for a more 470 accurate but no more helpful formulation, one should not quibble with 471 this wording. 473 It may be worth pointing out that not every decision should be taken 474 with hums in the room; that would be very inefficient. Good issues 475 to address in meeting hums are often difficult issues involving 476 preference tradeoffs rather than pure technical feasibility. 478 3.1. Easy consensus calls 480 If a discussion isn't too heated the chair might simply take a stab 481 at declaring consensus, ready to back off if the declaration was 482 premature. 484 e.g. "Will suggests we deprecate error code 410. Shall we do 485 that then? [hears approval noises] Good" 487 Alternatively: 489 e.g. "Will suggests we deprecate error code 410. Shall we do 490 that then? [hears objections] Ok, it seems we don't all agree. 491 Can we hear from the objectors?" 493 3.2. Fine-tuning consensus calls 495 A chair can fine-tune the wording of consensus calls on the fly. 497 Chair: Those in favour of proposal A, hum 499 WEAK HUM 501 Chair: Those against? 503 SOME HUMS and MUTTERING about wording of consensus call 505 Chair: Let me restate. Those in favour of proposal B? 507 WEAK HUM 509 Chair: That was rather indecisive. Those who would accept either 510 proposal? 512 [silence] 514 Chair: Do we have a problem with the two alternatives? 516 ... group explores more solutions 518 3.3. Chains of consensus calls 520 In a meeting, a chair can make a related chain of consensus calls. 521 An experienced chair can make progress quickly by narrowing down the 522 solution set at a high level first then at lower levels. 524 One specific use of this is to first call for consensus on how to 525 make a decision on a difficult issue, then to call for consensus on 526 the issue itself. 528 Example consensus call chain 530 Chair: We've been arguing about the details of this for quite a 531 while. Do we have enough information to make a decision on Sue's 532 proposal? Those who believe we're ready to make a decision, hum. 534 STRONG HUM 536 Chair: Those who don't believe we're ready, hum. 538 [silence] 540 Chair: That's in favour of making a decision, so here's the 541 decision: Do we generally believe that we want the ability to 542 fragment? Those who want fragmentation, hum. 544 STRONG HUM 546 Chair: Those who don't want fragmentation at all, hum 548 WEAK HUM 550 Chair: Assuming we want fragmentation capability then. Do we want 551 fragmentation to be limited to messages over a certain size, not 552 picking the size just yet but in principle? Those in favour of 553 allowing fragmentation all the time, hum 555 WEAK HUM 557 Those in favour of allowing fragmentation only on large messages, 558 hum 560 STRONG HUM 562 Chair: Ok, so only on large messages. Those in favour of 563 fragmentation allowed only on messages over 10,000... 565 4. Consensus Calls in Mailing Lists 567 Some WGs only do consensus calls in mailing lists. Sometimes these 568 are WGs that never meet (and difficulties may be created in the long 569 run by never meeting face to face -- but that's a topic for another 570 document). In other cases, the WG may meet but have a preference for 571 doing consensus calls on-list only. 573 Consensus calls on mailing lists are more obviously a continuum, a 574 balance arrived at over time. An initial proposal might inspire a 575 few agreements or disagreements immediately, creating the first sense 576 of possible consensus. It's actually quite frequent for an early 577 decision to be obvious to everybody. 579 If consensus isn't obvious immediately, the discussion typically 580 plays on for a while and additional opinions get added to the mix, 581 and alternative proposals may be made. At some point the chair may 582 explicitly make a consensus call. Some WGs expect that even 583 participants who have already stated a position will repeat their 584 opinions after an explicit consensus call, while other WGs expect 585 that any positions already stated still stand, and only new or 586 changed positions need to be stated. It can't hurt for chairs to be 587 explicit about the expectation. 589 Mailing list consensus calls need not be exclusive to a small set of 590 alternatives. The discussion sparked by the consensus call can and 591 should include new alternatives or creative compromises if any are 592 thought of. 594 4.1. Sample effective consensus call on-list 596 This email is effective in that it's clear that only new opinions are 597 solicited, and how a participant can avoid confusion over what issue 598 is discussed. 600 From: Steve 601 To: Example WG 602 Subject: Open issues status 604 We have three open issues: 606 #87 Section 3.3 inconsistent use of word "modify" 607 #89 Security Considerations needs to address DoS 608 #90 Retry limits 610 Are there any *new* (or changed) positions on these issues 611 before I declare consensus based on the discussion so far? 612 Please send one email per issue and include the issue number 613 in the subject. 615 4.2. Declaring consensus on-list 617 It's helpful to be explicit about consensus reached. Chairs need to 618 state what an outcome is for those who aren't paying attention, for 619 the record, and to remind those still arguing for different 620 alternatives to present new information or accept the outcome. 622 Sample 624 From: Alexander 625 To: Example WG 626 Subject: Issue #xxxx ReSubmission -- summary 628 So far I see some support for and elaboration of the 629 resubmission proposal, although there was some dissent. 630 I think there's a consensus around allowing resubmission 631 even without a server error. I saw the proposal to require 632 servers to accept resubmission but I didn't see any tangible 633 benefit to that. 634 Thus, the proposed resolution is that clients MAY resubmit, and 635 servers MAY accept or reject resubmissions. 637 We don't have consensus on whether the resubmit must have the 638 same message ID, so I'd like to see more input on that. 640 4.3. Confirming in-room consensus on Mailing List 642 Although consensus calls in meetings must be confirmed on the list, 643 we have flexibility in how this is done. Often the consensus call is 644 noted in the meeting minutes and silence (of two weeks or more) is 645 considered to be consent. Although [RFC4677] says that "Any decision 646 made at a face-to-face meeting must also gain consensus on the WG 647 mailing list", [RFC2418] requires that the in-person opinions remain 648 part of the consensus, and implies that once mailing list 649 participants have been given the opportunity to understand and 650 consider objections, the in-meeting consensus may well prevail 651 without calling consensus from scratch: "the volume of messages on a 652 topic is not, by itself, a good indicator of consensus". 654 The population that votes on a mailing list can be somewhat different 655 than the population that votes meeting room. Between meetings, 656 people are more likely to vote against the consensus than bother to 657 send a vote confirming the consensus so far, and this bias can 658 magnify the appearance of dissent. 660 The redress for people who disagree with the result of an in-room 661 consensus call is to dissent on the mailing list, ideally within two 662 weeks of meeting minutes being published (which, regrettably, is 663 often a month or more after the meeting itself). 665 When chairs do review a meeting decision on the mailing list, since 666 the votes made during the meeting (and possibly from before the 667 meeting) are already taken into account, it's not very helpful for 668 participants to provide redundant opinion statements. In rare cases, 669 a WG chair may have to ask everybody to restate their opinion even if 670 they have already given it, in which case chairs must be very 671 explicit about requesting this. 673 5. Alternative Approaches 675 Sometimes proposals are too hotly debated or too close to call 676 consensus easily. These are a number of approaches that a chair 677 might use to arrive at a decision, including those recommended in 678 [RFC3929] (external or mixed review team, short straw, and random 679 assignment). 681 5.1. Taking Time 683 It's often quite effective for the chair to put off a consensus call, 684 or having made a consensus call, to put off declaring an outcome. 685 Although this sounds like an inefficient use of time, it can allow 686 the WG to make progress on easier issues until more information is 687 in. Recall that consensus is not just about making a decision, it's 688 also about exploring alternatives, understanding a problem and 689 creating commitment among participants; extra time can help 690 particularly if one or more of these facets needs more work. 692 Examples: 694 "We're still having significant technical discussion on this. I 695 know Shuichi had a strong opinion and he's not here, and it's 696 possible his opinion could change based on some of this. But 697 we've run out of time in this meeting, so let's bring this 698 discussion back to the mailing list. Amy can you explain the race 699 condition on the list?..." 701 "I just heard weak hums on both sides of this issue, yet since 702 it's an important issue, I think we want a stronger consensus. 703 Does anybody have any other solutions to suggest? ... [silence] 704 ... Let's let this one marinate a bit. We've got fourteen other 705 open issues to work on, I think that will take us a couple months, 706 and we can revisit this later." 708 Taking extra long time should not be the first choice if quicker 709 solutions are available. A chair that finds too many decisions 710 taking too long should start to try to find shortcuts. A pattern of 711 long and difficult decision-making might be an indication of a WG 712 that needs to have a few beers together, or has grown too small and 713 entrenched. New people can be brought in temporarily (external 714 review) or permanently, or the chair can compromise on the goals, 715 leaving more work undone than previously intended. 717 5.2. Deciding to Make a Decision 719 Sometimes opinion is narrowly split between two or more alternatives 720 even after lengthy discussion, yet in the end the WG is willing to 721 accept an arbitrary outcome once one is fairly chosen. The WG may 722 choose to use a non-consensus way to pick an alternative (e.g. 723 counting votes) and we may still consider the outcome to be rough 724 consensus. 726 Often this "meta-decision" -- the decision to accept a decision -- is 727 made in one consensus call in an in-person meeting, followed by the 728 decision itself. In-person meetings are great for the quick 729 turnaround to make this possible. It's always nice to have explicit 730 WG permission to take an alternative approach. 732 "Let the minutes note that the WG agreed to a plurality vote in 733 order to make a decision on this issue" 735 5.3. Using votes and plurality decision-making 737 When a chair decides to count votes carefully, this can mean that the 738 WG explicitly chose plurality decision-making to resolve an impasse. 739 (It can also mean that the chair is covering their ass in a WG where 740 an individual is being difficult about what is actually a rough 741 consensus that the individual would rather not have to accept.) 743 It's usually obvious how to count votes in a mailing list, or if it's 744 not obvious the longer time scale can allow clarification. Chairs 745 should encourage participants to vote openly. Votes in private email 746 to the chair make consensus more difficult, and the outcome less 747 transparently justifiable. A close call should not depend on private 748 votes if at all possible. 750 It's somewhat less obvious how to vote in a room. Chairs may 751 sometimes want to make statements on how the voting will proceed 752 before attempting to call the vote and count the results. 754 o Is it OK to vote for two proposals? If allowed, this can help 755 show whether one proposal is acceptable to many, even if it's not 756 the favourite proposal for most. 758 o Will votes in the Jabber room be counted? 760 o Who will do the counting? 762 5.4. Let the Editor Choose 764 Many decisions are not suitable for consensus calls. If a 765 participant argues for a particular document organization, but the 766 document author prefers the document organization they have already, 767 a chair should usually defer to the author. The choice of names for 768 error codes or namespaces is frequently up to the author. We do not 769 write documents (even WG documents) by committee in the IETF. 770 Editorial discretion is still a valid part of our rough consensus. 772 When the WG chair chooses a document editor and makes a point to use 773 that term rather than 'author', it's typically with the understanding 774 that the editor will take his cues from the WG and put the WG 775 decisions in the document. That doesn't mean that the editor can't 776 have technical or editorial opinions and contribute them to the 777 consensus. In fact, the editor's opinion should not be taken 778 lightly, on the grounds that they are paying attention, are 779 knowledgeable about the domain, and were selected as editor for their 780 abilities to think about and explain technical issues as well as for 781 listening carefully to a variety of opinions. 783 5.5. Flipping a coin 785 It's OK to flip a coin. A coin-flip may be perfectly appropriate to 786 make a minor decision quickly and fairly, or to choose between two 787 alternatives that are well-balanced in support and tradeoffs. If 788 there are two element names under consideration for an XML element, 789 after a brief argument about which name is better, a chair may flip a 790 coin (or allow the editor to flip a coin) and declare one the winner. 792 It's OK even to virtually flip a coin. Again, with two alternative 793 names having been discussed for five minutes, a chair might say "Ok, 794 enough of this, let's pick the first one and move on." Participants 795 can assume that the chair is acting out of a desire for efficiency 796 and not in order to destroy fairness. 798 6. Accountability 800 Those who call consensus are accountable to the community and 801 responsible for outcomes. They should be prepared to explain their 802 decisions, and at times even review and revisit their decisions. To 803 explain consensus decisions, it always helps to have a good record. 804 Where possible, the consensus record can be public: well-minuted 805 consensus decisions in proceedings (required anyway), along with 806 clear conclusions to consensus calls on public mailing lists. 808 Chairs who use design teams and creative consensus calls (e.g. 809 plurality votes) are more likely to be called to account for 810 decisions, and appropriately so. 812 6.1. Challenging Consensus Call Results 814 Chairs and ADs make great efforts to attend meetings and read every 815 email on a mailing list in order to have an ongoing sense of 816 consensus on all important issues. In addition, there may be hallway 817 discussions or phone conversations with information or opinions 818 relating to a consensus decision. We can't second-guess every 819 consensus call. Sometimes we have to trust the decision history and 820 long-term performance of the person chosen to make consensus calls. 822 It is appropriate to discuss the process details of a consensus call 823 at times. For example, one might alert the community and its leaders 824 to questionable aspects of an important and close consensus call. An 825 example of this was a meeting where participants voted either 826 remotely via Jabber or in the physical room. Later, the chairs 827 learned from private input that several of the Jabber votes were from 828 dynamically-generated nicknames that had all connected to Jabber at 829 the same time from the same IP address. 831 Sometimes, learning of an irregularity can lead a chair to reset and 832 call for consensus again. However, if there were a rule insisting on 833 a reset, this could easily be manipulated by bad actors introducing 834 procedural irregularities in order to force new consensus calls. 835 Even when informed of distasteful tactics and irregularities in the 836 call, it's still up to the chairs whether to let a consensus stand. 838 When a previous decision is invoked, sometimes WG participants say 839 something like "We decided this in Oslo", referring to a meeting. If 840 a consensus call was made in a meeting in Oslo and not shortly 841 overturned on the list, then this statement is a reasonable 842 approximation of history. Rather than nitpick the wording of this, 843 it's most helpful to say something like "Regardless, I think there's 844 new information here and I'd like to see if the consensus has 845 changed." A chair may or may not agree and call for consensus again. 847 6.2. Sample challenge to a mailing list consensus call 849 From: Jay 850 To: Example Working Group 851 Subject: Pushing back on Modified Property Consensus Call 853 I'd like to push back on this consensus call. I read through the 854 threads and didn't see rousing support for this proposal and I 855 am currently -1 on it. Some of the problems were never brought 856 to the surface during the discussion, the largest being that 857 this adds a mandatory (MUST) level element to an entry, which 858 the base spec never required. 860 From: Michael 861 To: Jay, Example Working Group 862 Subject: Re: Pushing back on Modified Property Consensus Call 864 Hmm, upon further review, while this proposal did have some friendly 865 comment, "lots of support" might have been overstating it. I seem 866 to have counted at least one person twice. And Jay's point below 867 about the collision with the base spec seems pretty telling. Would 868 anyone like to jump up and shout in favor of saving it? 870 6.3. Overturning Consensus Call Outcomes 872 Consensus calls need not be final. However, there can be some harm 873 in overturning a consensus call. 875 o A new consensus necessarily takes more time. 877 o New discussions can be frustrating to those who participated in 878 prior consensus calls, particular if long discussions were 879 involved then. 881 o A change can be destabilizing to the documents and editing process 883 o The later consensus call can represent quite a different group of 884 people, perhaps because new people are alerted to the issue, but 885 perhaps because long-standing participants have given up or run 886 out of time to dedicate. 888 However, the harm may at times be more than balanced by the good that 889 comes of making a decision that participants have more confidence in. 890 Chairs need to be very explicit about voiding the consensus so that 891 people know to speak up again. 893 One of the most difficult situations to handle is when a WG has 894 consensus, but the WG document proves not to have IETF consensus or 895 IESG approval. Both "community consensus" (which can include anybody 896 since IETF and WG membership are not limited) and IESG approval are 897 required by [RFC2026], whereas WG consensus is not mentioned (see 898 also [RFC4677]). The first step is to allow the WG an opportunity to 899 evaluate the new input. If the consensus on the WG mailing list 900 remains the same, it becomes difficult to weight the IETF Last Call 901 input to decide whether it falls in the "rough" part of rough 902 consensus. We can rule out weighting the new input at zero as well 903 as weighting the original WG consensus at zero, but somewhere in 904 between those two extremes is a difficult judgement call and a large 905 region where more consensus-developing effort is required. It can 906 certainly take time to get the differing parties talking, but a 907 standoff can take even more time and a standoff doesn't progress 908 towards a good, well-approved technical standard. 910 7. Recommendations for Individual Participants 912 Participants are naturally important in determining rough consensus 913 when they voice opinions. Participants can be even more valuable 914 helping chairs gauge and reach consensus by listening, explaining, 915 mediating, proposing clear actions, helping others participate and so 916 on. This section provides some specific tips or ideas to consider. 917 See also [RFC3184] for the IETF Guidelines for Conduct. 919 7.1. What if you don't agree? 921 It can be difficult to find oneself in the "rough" part of rough 922 consensus. Strongly held personal convictions must sometimes make 923 way for the consensus of the group. These are some approaches to be 924 considered once a participant has already attempted to voice their 925 opinion and explain the technical basis for it, and still finds 926 themselves dissatisfied enough to take further action. 928 Can convictions be assuaged by stating or restating them? 930 "I'd like to state for the record that I still believe this 931 feature is unnecessary, but I won't argue any further." 933 Is it possible to seek elaboration either to become convinced or show 934 those in the consensus so far that they don't necessarily agree? 936 "I don't understand if this decision is being made based on a 937 belief that language negotiation is too difficult, or based on not 938 seeing the need for negotiation. Although Linda already declared 939 the consensus call, it would help me understand whether it's 940 worthwhile trying to convince people that it's easier than it 941 looks, or if that's a wasted effort". 943 Finally, it's each participant's job to build consensus rather than 944 to demand it. It can really help to talk to other individuals 945 privately and find out why they agree or disagree with you. 947 7.2. Avoiding blocked consensus 949 It helps not to state positions so strongly that one feels one's 950 reputation is staked on a particular outcome! 952 BAD: "It's not acceptable to change this header in a way that's 953 not backwards-compatible." 955 ALSO BAD: "I won't allow..." or "we can't" (when there's no strict 956 technical infeasibility.) 958 BETTER: "I strongly feel that we should not change this header 959 unless we can do so in a way that is backwards-compatible." 961 EVEN BETTER: "Is there some way we can do this without breaking 962 backward compatibility?" 964 ALSO GOOD: "Why do people feel strongly enough about this to break 965 backwards compatibility? I don't think I understand that 966 tradeoff." 968 Making an issue personal can bake people into firm oppositional 969 positions. Avoid the temptation to make personal accusations or to 970 oppose a person per se. Oppose the proposal, not the proposer. One 971 specific tactic to reduce knee-jerk opposition is to ask somebody to 972 explain the other position to show they understand it. 974 7.3. Questioning the process 976 First, remember that it looks bad for your technical position to 977 challenge the outcome on a process basis! Often challenging the 978 process can be avoided by suggesting a process rather than 979 criticizing what happened. Example: 981 "Can we take a hum on that issue? I'm not sure everybody is 982 really going along with Vlad's proposal." 984 Often, a participant who disagrees with the way a decision was made 985 also disagrees with the decision itself. It helps to address these 986 separately. The best way to dispute the decision being made is to 987 offer a technical or other reasonable opinion, perhaps with explicit 988 notes about tradeoff preferences, and ideally with new information. 989 In contrast, the best way to dispute the way the decision was reached 990 is to question the process and appeal to principles of fairness and 991 openness. 993 When the situation merits criticizing the process, the critic needs 994 to be clear about what went wrong or what needs to be remedied. 995 Cries of "unfair" are not usually helpful without more detail. 996 Again, to avoid making the issue personal, one can typically simply 997 ask the chair to remedy the situation (and explain why) rather than 998 accuse them of errors. Example: 1000 "I'd like to ask the chair to take that consensus call to the 1001 list, from scratch. I think this proposal is too complicated for 1002 us to really be able to hum for consensus right now." 1004 7.4. Final tips 1006 It helps to state why one is rejecting a proposal when the consensus 1007 call is yay/nay on a single proposal. 1009 "I'm -1 on this proposal. We'll have to deal with difficult i18n 1010 concerns if we head down this path." 1012 When accepting a proposal it's fine to be very brief. 1014 "+1". 1016 It helps to state on what basis one chooses between two proposals. 1018 "I prefer the stateless approach over the token approach. 1019 Generally I like pushing the work to servers, but in this case 1020 keeping state can degrade performance noticeably." 1022 8. Acknowledgements 1024 Thanks to Harald Alvestrand, Mary Barnes, Steve Bellovin, Tim Bray, 1025 Joe Gregorio, Tony Hansen, and Cullen Jennings. Some provided 1026 comments directly, and others provided examples of good consensus 1027 practices or expressed its principles nicely on discussion lists. 1029 9. IANA Considerations 1031 There are no IANA considerations introduced in this document. 1033 10. Security Considerations 1035 There are no security considerations arising from the information in 1036 this document. 1038 11. Informative References 1040 [AA] Alonzo, M. and M. Aiken, "Flaming in electronic 1041 communication", Decision Support Systems, Vol. 36, No. 3., 1042 pp. 205-213. , January 2004. 1044 [BUJ] Center for Conflict Resolution, "Building United Judgement 1045 -- A Handbook for Consensus Decision Making", 1981. 1047 [Hol] Hollingshead, A., "The Rank-Order Effect in Group Decision 1048 Making", Organizational Behavior and Human Decision 1049 Processes, Vol. 68, No. 3., pp. 181-193. , December 1996. 1051 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1052 3", BCP 9, RFC 2026, October 1996. 1054 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1055 Procedures", BCP 25, RFC 2418, September 1998. 1057 [RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, 1058 RFC 3184, October 2001. 1060 [RFC3929] Hardie, T., "Alternative Decision Making Processes for 1061 Consensus-Blocked Decisions in the IETF", RFC 3929, 1062 October 2004. 1064 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 1065 Guide to the Internet Engineering Task Force", RFC 4677, 1066 September 2006. 1068 Author's Address 1070 Lisa Dusseault 1071 CommerceNet 1072 169 University Ave. 1073 Palo Alto, CA 94301 1074 US 1076 Phone: 1-650-279-7365 1077 Email: ldusseault@commerce.net 1079 Full Copyright Statement 1081 Copyright (C) The IETF Trust (2007). 1083 This document is subject to the rights, licenses and restrictions 1084 contained in BCP 78, and except as set forth therein, the authors 1085 retain all their rights. 1087 This document and the information contained herein are provided on an 1088 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1089 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1090 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1091 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1092 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1093 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1095 Intellectual Property 1097 The IETF takes no position regarding the validity or scope of any 1098 Intellectual Property Rights or other rights that might be claimed to 1099 pertain to the implementation or use of the technology described in 1100 this document or the extent to which any license under such rights 1101 might or might not be available; nor does it represent that it has 1102 made any independent effort to identify any such rights. Information 1103 on the procedures with respect to rights in RFC documents can be 1104 found in BCP 78 and BCP 79. 1106 Copies of IPR disclosures made to the IETF Secretariat and any 1107 assurances of licenses to be made available, or the result of an 1108 attempt made to obtain a general license or permission for the use of 1109 such proprietary rights by implementers or users of this 1110 specification can be obtained from the IETF on-line IPR repository at 1111 http://www.ietf.org/ipr. 1113 The IETF invites any interested party to bring to its attention any 1114 copyrights, patents or patent applications, or other proprietary 1115 rights that may cover technology that may be required to implement 1116 this standard. Please address the information to the IETF at 1117 ietf-ipr@ietf.org. 1119 Acknowledgment 1121 Funding for the RFC Editor function is provided by the IETF 1122 Administrative Support Activity (IASA).