idnits 2.17.1 draft-resnick-on-consensus-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 01, 2013) is 3857 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IETF24' is defined on line 607, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Resnick 3 Internet-Draft Qualcomm Technologies, Inc. 4 Intended status: Informational October 01, 2013 5 Expires: April 04, 2014 7 On Consensus and Humming in the IETF 8 draft-resnick-on-consensus-04 10 Abstract 12 The IETF has had a long tradition of doing its technical work through 13 a consensus process, taking into account the different views among 14 IETF participants and coming to (at least rough) consensus on 15 technical matters. In particular, the IETF is supposed not to be run 16 by a "majority rule" philosophy. This is why we engage in rituals 17 like "humming" instead of voting. However, more and more of our 18 actions are now indistinguishable from voting, and quite often we are 19 letting the majority win the day, without consideration of minority 20 concerns. This document is a collection of thoughts on what rough 21 consensus is, how we have gotten away from it, and the things we can 22 do in order to really achieve rough consensus. 24 Note (to be removed before publication): This document is quite 25 consciously being put forward as Informational. It does not 26 propose to change any IETF processes and is therefore not a BCP. 27 It is simply a collection of principles, hopefully around which 28 the IETF can come to (at least rough) consensus. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 04, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Lack of disagreement is more important than agreement . . . . 3 65 3. Rough consensus is achieved when all issues are addressed, 66 but not necessarily accommodated . . . . . . . . . . . . . . 5 67 4. Humming should be the start of a conversation, not the end . 7 68 5. Consensus is the path, not the destination . . . . . . . . . 10 69 6. One hundred people for and five people against might not be 70 rough consensus . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Five people for and one hundred people against might still be 72 rough consensus . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 10. Informative References . . . . . . . . . . . . . . . . . . . 15 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 Almost every IETF participant knows the aphorism from Dave Clark's 82 1992 plenary presentation [Clark] regarding how we make decisions in 83 the IETF: 85 We reject: kings, presidents and voting. 87 We believe in: rough consensus and running code. 89 That is, our credo is that we don't let a single individual make the 90 decisions, nor do we let the majority dictate decisions, nor do we 91 allow decisions to be made in a vacuum without practical experience. 92 Instead, decisions are made by (more or less) consent of all 93 participants, and the actual products of engineering trump 94 theoretical designs. Our ideal is full consensus, but we don't 95 require it: Full consensus would allow a single intransigent person 96 who simply keeps saying "No!" to stop the process cold. We only 97 require rough consensus: If the chair of a working group determines 98 that a technical issue brought forward by an objector has been truly 99 considered by the working group, and the working group has made an 100 informed decision that the objection has been answered or is not 101 enough of a technical problem to prevent moving forward, the chair 102 can declare that there is rough consensus to go forward, the 103 objection notwithstanding. To reinforce that we do not vote, we have 104 also adopted the tradition of "humming": When (for example) the chair 105 of the working group wants to get a "sense of the room", instead of a 106 show of hands, the chair asks for each side to hum for or against a 107 question. 109 However, in recent years we have seen participants (and even some 110 folks in IETF leadership) who do not understand some of the 111 subtleties of consensus-based decision making. Participants ask, 112 "Why are we bothering with this 'humming' thing? Wouldn't a show of 113 hands be easier? That way we could really see how many people want 114 one thing over another." Chairs, many of whom have little experience 115 in leading large volunteer groups like those in the IETF, let alone 116 experience in how to gather consensus, are faced with factious 117 working groups with polarized viewpoints and long-running unresolved 118 issues that return again and again to the agenda. More and more 119 frequently, people walk away from working groups, thinking that 120 "consensus" has created a document with horrible compromises to 121 satisfy everyone's pet peeve instead of doing "the right thing". 122 None of these things are indicators of a rough consensus process 123 being used, and are likely due to some basic misperceptions. 125 This document attempts to explain some features of rough consensus, 126 explain what is not rough consensus, and suggest ways that we might 127 achieve rough consensus and judge it in the IETF. Though this 128 document describes some behaviors of working groups and chairs, it 129 does so in broad brushstrokes and it is not intended to dictate 130 specific procedures. It is intended to foster understanding of the 131 underlying principles of IETF consensus processes. 133 2. Lack of disagreement is more important than agreement 135 A working group comes to a technical question of whether to use 136 format A or format B for a particular data structure. The chair 137 notices that a number of experienced people think format A is a good 138 choice. The chair asks on the mailing, "Is everyone OK with format 139 A?" Inevitably, a number of people object to format A for one or 140 another technical reason. The chair then says, "It sounds like we 141 don't have consensus to use format A. Is everyone OK with format B?" 142 This time even more people object to format B, on different technical 143 grounds. The chair, not having agreement on either format A or 144 format B, is left perplexed, thinking the working group has 145 deadlocked. 147 The problem that the chair got themselves into in the above case was 148 thinking that what they were searching for was agreement. "After 149 all", thinks the chair, "consensus is a matter of getting everyone to 150 agree, so asking whether everyone agrees is what the chair ought to 151 do. And if lots of people disagree, there's no consensus." But 152 _determining_ consensus and _coming to_ consensus are different 153 things than _having_ consensus. Consensus is not when everyone is 154 happy and agrees that the chosen solution is the best one. Consensus 155 is when everyone is sufficiently satisfied with the chosen solution, 156 such that they no longer have specific objections to it. The 157 distinction might be a bit subtle, but it's important. Engineering 158 always involves a set of tradeoffs. It is almost certain that any 159 time engineering choices need to be made, there will be options that 160 appeal to some people that are not appealing to some others. The key 161 is to separate those choices that are simply unappealing from those 162 that are truly problematic. 164 So in the case of a working group decision, after the initial 165 discussion of the pros and cons of the available choices, it is most 166 important to ask not just for objections to a particular proposal, 167 but for the nature of those objections. A chair who asks, "Is 168 everyone OK with choice A?" is going to get objections. But a chair 169 who asks, "Can anyone not live with choice A?" is more likely to only 170 hear from folks who think that choice A is impossible to engineer 171 given some constraints. Following up with, "What are the reasons you 172 object to choice A?" is also essential. Then the purported failings 173 of the choice can be examined by the working group. The objector 174 might convince the rest of the group that the objections are valid, 175 or the working group might convince the objector that the concerns 176 can be addressed, or that the choice is simply unappealing (i.e., 177 something the objector can "live with") and not a show-stopper. In 178 any event, closure is much more likely to be achieved quickly by 179 asking for and trying to accommodate the objections rather than 180 asking for agreement. 182 This also brings up an important point about reaching consensus and 183 "compromising": Unfortunately, the word "compromise" gets used in two 184 different ways, and though one sort of compromising to come to 185 consensus is good (and important), the other sort of compromising in 186 order to achieve consensus is actually harmful. As mentioned 187 earlier, engineering always involves balancing tradeoffs, and 188 figuring out whether one engineering decision makes more sense on 189 balance compared to another involves making engineering 190 "compromises": We might have to compromise processor speed for lower 191 power consumption, or compromise throughput for congestion 192 resistance. Those sorts of compromises are among engineering 193 choices, and they are expected and essential. We always want to be 194 weighing tradeoffs and collectively choosing the best set. 196 However, there is another sense of "compromise" that involves 197 compromising between people, not engineering principles. For 198 example, a minority of a group might object to a particular proposal, 199 and even after discussion still think the proposal is deeply 200 problematic, but decide that they don't have the energy to argue for 201 it and say, "Forget it, do what you want". That surely can be called 202 a compromise, but a chair might mistakenly take this to mean that 203 they agree, and have therefore come to consensus. But really all 204 that they've done is conceded; they've simply given up by trying to 205 appease the others. That's not coming to consensus; there still 206 exists an outstanding unaddressed objection. Even worse is the 207 "horse-trading" sort of compromise: "I object to your proposal for 208 such-and-so reasons. You object to my proposal for this-and-that 209 reason. Neither of us agree. If you stop objecting to my proposal, 210 I'll stop objecting to your proposal and we'll put them both in." 211 That again results in an "agreement" of sorts, but it also results in 212 two outstanding unaddressed issues, again ignoring them for the sake 213 of expedience. These sorts of "giving up" or "horse-trading" 214 compromises have no place in consensus decision making. In each 215 case, a chair who looks for "agreement" might find it in these 216 examples because it appears that people have "agreed". But again, 217 answering technical disagreements is what is needed to achieve 218 consensus, sometimes even when the people who stated the 219 disagreements no longer wish to discuss them. 221 Coming to consensus is when everyone comes to the conclusion that 222 either the objections are valid (and therefore making a change to 223 address the objection) or that the objection was not really a matter 224 of importance, but merely a matter of taste. Of course, coming to 225 full consensus like that does not always happen. That's why in the 226 IETF, we talk about "rough consensus". 228 3. Rough consensus is achieved when all issues are addressed, but not 229 necessarily accommodated 231 The preceding discussion gives an example where the working group 232 comes to consensus on a point: Either the objector is satisfied, or 233 the working group is satisfied. But that doesn't happen all of the 234 time, and it's certainly not the problematic case. Engineering is 235 always a set of tradeoffs. Often, a working group will encounter an 236 objection where everyone understands the issue and acknowledges that 237 it is a real shortcoming in the proposed solution, but the vast 238 majority of the working group believe that accommodating the 239 objection is not worth the tradeoff of fixing the problem. 241 So, an objector might say, "The proposal to go with protocol X is 242 much more complicated than going with protocol Y. Protocol Y is a 243 much more elegant and clean solution, which I can code much more 244 easily, and protocol X is a hack." The working group might consider 245 this input, and someone might respond, "But we have a great deal of 246 code already written that is similar to protocol X. While I agree 247 that protocol Y is more elegant, the risks to interoperability with 248 an untested solution is not worth it compared to the advantages of 249 going with the well-understood protocol X." If the chair finds, in 250 their technical judgement, that the issue has truly been considered, 251 and that the vast majority of the working group has come to the 252 conclusion that the tradeoff is worth making, even in the face of 253 continued objection from the person(s) who raised the issue, the 254 chair can declare that the group has come to rough consensus. 256 Note that this portrays rough consensus as an "exception". In one 257 sense, it is: As a working group does its work and makes its choices, 258 it behaves as if it is striving toward full consensus and tries to 259 get all issues addressed to the satisfaction of everyone in the 260 group, even those who originally held objections. It treats rough 261 consensus as a sort of "exception processing", to deal with cases 262 where the person objecting still feels strongly that their objection 263 is valid and must be accommodated. But it is certainly true that 264 more often than not in the IETF, at least someone in the group will 265 be unsatisfied with a particular decision. In that sense, rough 266 consensus might be closer to the norm than the "exception". However, 267 when a participant says, "That's not my favorite solution, but I can 268 live with it; I'm satisfied that we've made a reasonable choice", 269 that participant is not in the "rough" part of a rough consensus; the 270 group actually reached consensus if that person is satisfied with the 271 outcome. It's when the chair has to declare that an unsatisfied 272 person still has an open issue, but that the group has truly answered 273 the objection, that the consensus is only rough. 275 Now, a conclusion of having only rough consensus relies heavily on 276 the good judgement of the consensus caller. The group must truly 277 consider and weigh an issue before the objection can be dismissed as 278 being "in the rough". The chair of the working group in one of these 279 cases is going to have to decide that not only has the working group 280 taken the objection seriously, but that it has fully examined the 281 ramifications of not making a change to accommodate it, and that the 282 outcome does constitute a failure to meet the technical requirements 283 of the work. In order to do this, the chair will need to have a good 284 idea of the purpose and architecture of the work being done and use 285 their own technical judgement to make sure that the solution meets 286 those requirements. What can't happen is that the chair bases their 287 decision solely on hearing a large number of voices simply saying, 288 "The objection isn't valid." That would simply be to take a vote. A 289 valid justification needs to me made. 291 Any finding of rough consensus needs, at some level, to provide a 292 reasoned explanation to the person(s) raising the issue of why their 293 concern is not going to be accommodated. A good outcome is for the 294 objector to understand the decision taken and accept the outcome, 295 even though their particular issue is not being accommodated in the 296 final product. Remember, if the objector feels that the issue is so 297 essential that it must be attended to, they always have the option to 298 file an appeal. A technical error is always a valid basis for an 299 appeal. The chair (or whoever is responsible to hear an appeal) may 300 determine that the issue was addressed and understood, but they also 301 have the freedom and the responsibility to say, "The group did not 302 take this technical issue into proper account" when appropriate. 303 Simply having a large majority of people agreeing to dismiss an 304 objection is not enough to claim there is rough consensus; the group 305 must have honestly considered the objection and evaluated that other 306 issues weighed sufficiently against it. Failure to do that reasoning 307 and evaluating means that there is no true consensus. 309 4. Humming should be the start of a conversation, not the end 311 We don't vote in the IETF. In some ways, we can't vote: Since the 312 IETF is not a membership organization, it's nearly impossible to 313 figure out who would get a vote for any given question. We don't 314 know who the members of any given working group are at any one time, 315 and we certainly don't know who all of the members of the IETF are. 316 Indeed, we often recruit additional implementers and other experts 317 into working groups in order to ensure that broader views are brought 318 into the discussion. So voting is simply not practical. We've also 319 decided that coming to consensus (albeit sometimes rough consensus) 320 is an important thing to do. So instead of voting, we "hum". 322 However, more and more we see people who think that a hum is a sort 323 of anonymous vote, with some chairs calling every question they have 324 for the working group by asking for a hum and judging the result by 325 the loudest hum, even saying things like, "There were lots of hums 326 for choice 1 and very few hums for choice 2, so it sounds like we 327 have rough consensus for choice 1." This really misses the point of 328 humming and is almost certainly mis-assessing the consensus. Hums 329 should not be used as votes. 331 So, why do we hum? The first reason is pragmatic. Quite often, a 332 chair is faced with a room full of people who seem to be 333 diametrically opposed on some choice facing the group. In order to 334 find a starting place for the conversation, it is often useful for 335 the chair to ask for a hum to see if one of the choices already has a 336 stronger base of support than the other. If choice "foo" has a 337 significant amount more support than choice "bar", it is likely 338 easier to start the discussion by saying, "OK, 'foo' seems to have 339 quite a bit of support. Let's have the people that think 'foo' is a 340 bad idea come up and tell us why it is problematic." At that point, 341 the group can start going through the issues and see if any of them 342 are showstoppers. It may turn out that one of the objections is 343 instantly recognized by the entire group as a fatal flaw in "foo" and 344 the group will then turn to a discussion of the merits (and demerits) 345 of "bar" instead. All that the hum does is give the chair a starting 346 point: There were likely to be less objections to "foo" than to "bar" 347 at the beginning of the discussion, so starting with whatever got the 348 most hums can shorten the discussion. 350 But couldn't the above could have been done with a show of hands 351 instead of a hum? Sure, but there are more formal reasons for using 352 a hum instead of a show of hands: Another reason we hum is because it 353 actually gives the chair the opportunity to take the temperature of 354 the room. A smaller bunch of loud hums for choice A and a larger 355 number of non-committal hums for choice B might indicate that some 356 people believe that there are serious problems with choice B, albeit 357 the more popular by sheer number of people. The chair might decide 358 that starting with choice A and getting objections to it is the 359 easier path forward and more likely to result in consensus in the 360 end. Remember, coming to consensus is a matter of eliminating 361 disagreements, so the chair wants to choose the path that gets to the 362 least objections fastest. A bunch of people who are not strongly 363 committed to B might have no real technical objection to A, even 364 though it is not their first preference. There is always a chance 365 that this could be misleading, because some people are more willing 366 to hum loudly than others (just by didn't of personality), but keep 367 in mind that taking the hum is to figure out how to start the 368 conversation. The chair could always be surprised because the hum 369 turns out to be unanimous. Otherwise, the hum begins the discussion, 370 it doesn't end it. 372 Of course, a chair could get the temperature of the room by doing a 373 show of hands too, and knowing who specifically feels one way or 374 another can help a good chair guide the subsequent conversation. 375 However, a show of hands will often leave the impression that the 376 number of people matters in some formal way. It takes a chair and a 377 working group with a solid understanding of how consensus works to do 378 a show of hands and not end up reinforcing the mistaken notion that a 379 vote is taking place. A chair can always take the hum and then later 380 ask for specific folks to identify themselves to elicit more 381 discussion. The hum makes it perfectly clear that the chair is 382 simply figuring out the direction of the conversation. 384 This also points to another misuse of the hum: If the chair is 385 already convinced that the group has come to consensus, there is no 386 reason to take a hum. In fact, taking the hum only serves to 387 discourage those who might be in the minority from voicing their 388 concerns to the group in the face of a large majority who want to 389 move forward. The right thing for the chair to do if they already 390 sense consensus is to say, "It sounds to me like we have consensus 391 for choice A. Does anybody have any concerns or objections to going 392 with A?" This allows folks to bring up issues to the group that the 393 chair might have mistakenly missed without having them feel that the 394 majority has "already spoken". 396 There are times where the result of a hum is a pretty even split. In 397 practical terms, that means it doesn't matter where the chair starts 398 the discussion. And in fact, we've had working groups where a coin- 399 flip decided which proposal to start with. That doesn't mean that 400 the coin-flip determined the outcome; if a fatal technical flaw was 401 found in the solution that won the coin flip, it is still incumbent 402 upon the group to address the issue raised, or abandon that solution 403 and find another. Rough consensus on the technical points, in the 404 end, is always required. Any way to find a place to start, be it the 405 hum or the coin-flip, is only getting to the beginning of the 406 discussion, not the end. 408 5. Consensus is the path, not the destination 410 We don't try to reach consensus in the IETF as an end in itself. We 411 use consensus-building as a tool to get to the best technical (and 412 sometimes procedural) outcome when we make decisions. Experience has 413 shown us has been that traditional voting leads to gaming of the 414 system, "compromises" of the wrong sort described earlier, important 415 minority views being ignored, and in the end worse technical 416 outcomes. Coming to consensus is what we do during the process to 417 arrive at the best solution. "Declaring" consensus is not the end 418 goal. Indeed, attempts to declare consensus at the end of a 419 discussion often get us back into the voting mentality that we're 420 trying to avoid. 422 We often hear chairs say that they are making a "consensus call". 423 Sometimes, they simply mean they are making a call _of_ the 424 consensus; that is, they are declaring the consensus that has, in 425 their view, been reached when the discussion has reached an end. 426 That's a fine thing and what chairs are supposed to do: They are 427 "calling" the consensus. Sometimes, when a chair says that they are 428 making a "consensus call", the chair is actually making a call _for 429 discussion_ of a particular point in order to reach consensus. 430 Although it's a bit odd to call that a "consensus call" (as opposed 431 to a "call for discussion" or the like), it is fine for a chair to 432 occasionally identify a particular point of contention and get the 433 group to focus discussion on it in order to reach consensus. But 434 more and more often, we hear chairs say that they are making a 435 "consensus call" at the end of a discussion, where the chair will 436 pose the classic "Who is in favor of choice A? Who is in favor of 437 choice B?" questions to the working group. That's not really a 438 "consensus call", and has the same potential problems as the "hum" at 439 the end of a discussion: It can be tantamount to asking for a vote. 440 Even talk of "confirming consensus" has this problem: It implies that 441 you can confirm that there is consensus by counting people, not 442 issues. The important thing for a chair to do is to "call consensus" 443 in the sense of declaring the consensus; others can always object and 444 say that the chair has gotten the consensus wrong and ask for 445 reconsideration. But the chair ought to be looking for consensus 446 throughout the discussion, not asking for it at the end. 448 There are some times where chairs will ask a question or take a hum 449 toward the end of a discussion in order to figure out the state of 450 consensus, but this must be done with extreme caution. This is 451 discussed in the next section. 453 6. One hundred people for and five people against might not be rough 454 consensus 456 Remember that consensus is found when all of the objections have been 457 addressed. Because of this, using rough consensus avoids a major 458 pitfall of a straight vote: If there is a minority of folks who have 459 a valid technical objection, that objection must be dealt with before 460 consensus can be declared. This also reveals one of the great 461 strengths of using consensus over voting: It isn't possible to use 462 "vote stuffing" (simply recruiting a large number of people to 463 support a particular side, even people who have never participated in 464 a working group or the IETF at all) to change the outcome of a 465 consensus call. As long as the chair is looking for outstanding 466 technical objections and not counting heads, vote stuffing shouldn't 467 affect the outcome of the consensus call. 469 So in a large working group with over 100 active participants and 470 broad agreement to go forward with a particular protocol, if a few 471 participants say, "This protocol is going to cause congestion on the 472 network, and it has no mechanism to back off when congestion occurs; 473 we object to going forward without such a mechanism in place", and 474 the objection is met with silence on the mailing list, there is no 475 consensus. Even if the working group chair makes a working group 476 last call on the document, and 100 people actively reply and say, 477 "This document is ready to go forward", if the open issue hasn't been 478 addressed, there's still no consensus. It's the existence of the 479 unaddressed open issue, not the number of people, which is 480 determinative in judging consensus. As discussed earlier, you can 481 have rough consensus with issues that have been purposely dismissed, 482 but not ones that have been ignored. 484 This brings us back to when a hum could be used (cautiously) at the 485 end of a discussion. A discussion may be ongoing for some time, and 486 a particular objection seems to be holding up the decision. A 487 diligent chair who's been carefully listening to the discussion might 488 think, "I have heard person X make this objection, and I've heard 489 responses from many other folks that really address the issue. I 490 think we have rough consensus. But the objection keeps coming up. 491 Maybe it's just the one person getting up again and again with the 492 same argument, but maybe we don't have rough consensus. I'm not 493 sure." At this point, the chair might ask for a hum. If only a 494 single hum objecting can be heard, even a loud one, in the face of 495 everyone else humming that the objection has been answered, the chair 496 has pretty good reason to believe that they heard the single 497 objection all along and it really has been addressed. However, to 498 say immediately after the hum, "It sounds like we have rough 499 consensus" and nothing else is at best being slipshod: What the chair 500 really needs to say at that point is, "I believe the only objection 501 we've heard is A (coming from person X), and I've heard answers from 502 the group that fully address that issue. So, unless I hear a 503 different objection than the one I've just described, I find that 504 there is rough consensus to move on." That leaves the door open for 505 someone to tell the chair that the objection was really on different 506 grounds and they misevaluated, but makes it clear that the chair has 507 found rough consensus due to the discussion, not due to the hum. 508 Again, it's not the hum that ends things, it's that the issues have 509 been addressed. If the small minority (even one person) still has an 510 issue that hasn't been addressed, rough consensus still hasn't been 511 achieved. 513 7. Five people for and one hundred people against might still be rough 514 consensus 516 This one is the real mind bender for most people, and certainly the 517 most controversial. Say there is a very small working group, one 518 with half a dozen truly active participants who are experts in the 519 field; everybody else is just following along, but not contributing 520 to the discussion. The active folks come up with a protocol document 521 that they all agree is the right way forward, and people inside and 522 outside the working group agree that the protocol is likely to get 523 widespread adoption; it is a good solution to a real problem, even if 524 the non-experts don't have the ability to fully judge the details. 526 However, one of the active members has an objection to a particular 527 section: The protocol currently uses a well-known algorithm to 528 address an issue, but the objector has a very elegant algorithm to 529 address the issue, one which works especially well on their 530 particular piece of hardware. There is some discussion, and all of 531 the other contributors say, "Yes, that is elegant, but what we're 532 using now is well-understood, widely-implemented, and it works 533 perfectly acceptably, even on the objector's hardware. There is 534 always some inherent risk to go with a new, albeit more elegant, 535 algorithm. We should stick to the one we've got." The chair follows 536 the conversation and says, "It sounds like the issue has been 537 addressed and there's consensus to stick with the current solution." 538 The objector is not satisfied, maybe even saying, "But this is silly. 539 You've seen that my algorithm works. We should go with that." The 540 chair makes the judgement that the consensus is rough, in that there 541 is still an objector, but the issue has been addressed and the risk 542 argument has won the day. The chair makes a working group last call. 544 Now the worst case scenario happens. The objector, still unhappy 545 that their preferred solution was not chosen, recruits one hundred 546 people, maybe a few who were silent participants in the working group 547 already, but mostly people who work at the same company as the 548 objector who never participated before. The objector gets them all 549 to post a message to the list saying, "I believe we should go with 550 the new elegant algorithm in section Z instead of the current one. 551 It is more elegant, and works better on our hardware." The chair 552 sees these dozens of messages coming in and posts a query to each of 553 them: "We discussed this on the list, and we seemed to have consensus 554 that, given the inherent risk of a new algorithm, and the widespread 555 deployment of this current one, it's better to stick with the current 556 one. Do you have further information that indicates something 557 different?" And in reply the chair gets utter silence. These 558 posters to the list (say some of whom were from the company sales and 559 marketing department) thought that they were simply voting and have 560 no answer to give. At that point, it is within bounds for the chair 561 to say, "We have objections, but the objections have been 562 sufficiently answered, and the objectors seem uninterested in 563 participating in the discussion. Albeit rough in the extreme, there 564 is rough consensus to go with the current solution." 566 There is no doubt that this is the degenerate case and a clear 567 indication of something pathological. But this is precisely what 568 rough consensus is designed to guard against: vote stuffing. In the 569 presence of an objection, the chair can use their technical judgement 570 to decide that the objection has been answered by the group and that 571 rough consensus overrides the objection. Now, the case described 572 here is probably the hardest call for the chair to make (how many of 573 us are willing to make the call that the vast majority of people in 574 the room are simply stonewalling, not trying to come to consensus?), 575 and if appealed it would be incredibly difficult for the appeals body 576 to sort out. Indeed, it is likely that if a working group got this 577 dysfunctional, it would put the whole concept of coming to rough 578 consensus at risk. But still, the correct outcome in this case is to 579 look at the very weak signal against the huge background noise in 580 order to find the rough consensus. 582 8. Conclusion 584 Although this document talks quite a bit about the things chairs and 585 working groups and other IETF participants might do to achieve rough 586 consensus, this document is not really about process and procedures. 587 It describes a way of thinking about how we make our decisions. 588 Sometimes, a show of hands can be useful; sometimes it can be quite 589 damaging and result in terrible decisions. Sometimes, using a device 590 like a "hum" can avoid those pitfalls; sometimes it is just a poorly 591 disguised vote. The point of this document is to get all of us to 592 think about how we are coming to decisions in the IETF, to make sure 593 we avoid the dangers of "majority rule" and actually get to rough 594 consensus decisions with the best technical outcomes. 596 9. Security Considerations 598 "He who defends with love will be secure." -- Lao Tzu 600 10. Informative References 602 [Clark] Clark, D., "A Cloudy Crystal Ball - Visions of the 603 Future", July 1992. 605 In 607 [IETF24] Davies, M., Ed., Clark, C., Ed., and D. Legare, Ed., 608 "Proceedings of the Twenty-Fourth Internet Engineering 609 Task Force", July 1992, 610 . 612 [Sheeran] Sheeran, M., "Beyond Majority Rule: Voteless Decisions in 613 the Religious Society of Friends", December 1983. 615 Appendix A. Acknowledgements 617 This document is the result of conversations with many IETF 618 participants, too many to name individually. I greatly appreciate 619 all of the discussions and guidance. I do want to extend special 620 thanks to Peter Saint-Andre, who sat me down and pushed me to start 621 writing, and to Melinda Shore for pointing me to Beyond Majority Rule 622 [Sheeran], which inspired some of the thinking in this document. 624 Author's Address 626 Pete Resnick 627 Qualcomm Technologies, Inc. 628 5775 Morehouse Drive 629 San Diego, CA 92121 630 US 632 Phone: +1 858 6511 4478 633 Email: presnick@qti.qualcomm.com