idnits 2.17.1 draft-moonesamy-consensus-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2013) is 3853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1310 (Obsoleted by RFC 1602) -- Obsolete informational reference (is this intentional?): RFC 1602 (Obsoleted by RFC 2026) -- Obsolete informational reference (is this intentional?): RFC 1603 (Obsoleted by RFC 2418) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Moonesamy 3 Intended Status: Informational 4 Expires: April 10, 2014 October 7, 2013 6 Consensus 7 draft-moonesamy-consensus-00 9 Abstract 11 Decision-making is difficult when there is a need to consider the 12 interests of all of the affected parties and when it is important to 13 gain widespread community consensus. This document discusses about 14 consensus. It neither seeks to define consensus nor does it 15 prescribe practices for the Internet Standards Process. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 50 S. Moonesamy Consensus October 7, 2013 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Background 58 The Internet Standards Process [RFC2026] was first documented in RFC 59 1310 [RFC1310]. One of the goals for achieving Internet 60 standardization was openness and fairness. In July 1992, David Clark 61 presented a vision of the future which covered the making of 62 standards. The sound bite that is remembered to this day is: 64 "We reject: kings, presidents and voting. 65 We believe in: rough consensus and running code." 67 RFC 1602 [RFC1602] highlighted that the process was difficult as 68 there was a need to consider the interests of all of the affected 69 parties and the importance of establishing widespread community 70 consensus. 72 1.1. Introduction 74 In groups of animals only a small proportion of individuals may 75 possess particular information, such as a migration route or the 76 direction to a resource. Individuals may differ in preferred 77 direction resulting in conflicts of interest and, therefore, 78 consensus decisions may have to be made to prevent the group from 79 splitting [CROWDS]. 81 This document discusses about consensus. It neither seeks to define 82 consensus nor does it prescribe practices for the Internet Standards 83 Process. There is a brief description of decision-making processes 84 in Section 2. Consensus and decision-making are discussed in Section 85 3, with examples to illustrate the decisions. The conclusion is that 86 people determine consensus, and they do so based on their experience 87 and judgement. 89 2. Decision-making 91 2.1. Benevolent dictatorship 93 The benevolent dictatorship is where one person or a small group of 94 persons have the power to take decisions. There is a presumption of 95 benevolence and wisdom. The following would not be seen as fair: 97 "All persons are equal... but some persons are more equal than 98 others." [FARM] 100 S. Moonesamy Consensus October 7, 2013 102 2.2. Voting 104 The commonly-known decision-making procedure is simple majority rule 105 where the decision is taken if more than one half of the group votes 106 for it. It can lead to the group splitting. It is also against the 107 goal of considering the interests of all the persons within the 108 group. 110 2.3. Consensus 112 A study showed that only a very small proportion of informed 113 individuals is required in a group to achieve great accuracy in 114 decision-making. It was also demonstrated that groups can make 115 consensus decisions, even though informed individuals do not know 116 whether they are in a majority or minority [COUZIN]. Consensus can 117 be seen as a conclusion which any other person would reach if he or 118 she was taking the decision. 120 3. Consensus and Decision-Making 122 Consensus on technical issues is a matter of weighing the technical 123 opinions which have been expressed. It is neither a vote nor a count 124 of the number of persons who have stated a preference for or against 125 a proposal. 127 In the IETF, any attempt to determine consensus is more difficult if 128 the issues are technical, economic and political. Impassioned 129 discussion, with little technical content, leads to an impasse. It is 130 up to the person making the determination to tease apart the points 131 and find out how to reduce the amount people disagree on, find the 132 bounds of the conversation, and separate out the technical issues. 134 3.1. Rough Consensus 136 IETF Working Groups make decisions through a "rough consensus" 137 process [RFC1603]. Consensus does not require that all participants 138 agree although this is, of course, preferred. Rough consensus is a 139 subjective decision as determining the general sense of agreement is 140 a matter of judgement. 142 3.1. Decision-Making 144 Consensus decision-making is a process, i.e. there are steps which 145 are carefully followed until everyone is agreeable with the choices 146 which they are provided with. People are given fair notice about the 147 decision to be taken and how the decision will be decided. 149 3.1.1. Face-to-face sessions 150 S. Moonesamy Consensus October 7, 2013 152 RFC 1603 [RFC1603] mentioned that consensus can be determined by 153 balloting, humming, or any other means on which the WG agrees (by 154 rough consensus, of course). During a face-to-face session 155 [RFC2418], Working Groups sometimes resort to humming to find out how 156 to reduce the amount people disagree on. Humming allows each and 157 every person in the room to express his or her opinion after 158 listening or participating in the discussion about an issue. The 159 advantage of humming is that a person can express an opinion as an 160 individual without being subject to negative consequences (e.g. the 161 person can express an opinion which is contrary to the interests of 162 his or her organization). Humming is an effective way to gauge the 163 "sense of the room". For example, if, in a room for twenty persons, 164 there is a choice between two colors, red and black, and the 165 questions are: 167 (a) Hmm if you prefer red 169 (b) Hum if you prefer black 171 (c) Hum if you do not have any opinion 173 and there is a soft hum for (a), a mild hum for (b), and a loud hum 174 for (c), the "sense of the room" is neither for red nor for black. 176 During a face-to-face session a Working Group might decide to have a 177 "show of hands" to determine a preference. It is like having a vote 178 which is not secret. The disadvantage is that the opinion expressed 179 by the person is not secret and there is a risk that the person might 180 be coerced to express a particular opinion. For example, if there is 181 a choice between two colors, red and black, and the questions are: 183 (i) Raise your hand if you prefer red 185 (ii) Raise your hand if you prefer black 187 (iii) Raise your hand if you do not have any opinion 189 and two persons raised their hands for (i), four persons raised their 190 hand for (ii), and nobody raised their hand for (iii), the decision 191 is not clear. 193 A decision can be undermined by people conforming to what other 194 people in the group think. It is important not to encourage the 195 perception that the decision-maker is trying to change the result. 196 It is better to only try once to ask a group of persons to express 197 their preference about a set of alternatives. 199 It is to be noted that the Working Group takes the decision on its 201 S. Moonesamy Consensus October 7, 2013 203 mailing list and not in a face-to-face meetings. The preference 204 stated during the face-to-face session is taken to the mailing list 205 for confirmation and the decision is announced on the mailing list. 207 3.1.2. Mailing list discussions 209 A significant problem for decision-making through a mailing list is 210 that it is possible to bias the outcome as any person can express an 211 opinion more than once. The IETF side-stepped that problem by 212 weighing opinions instead of counting opinions. For example, if 213 there is a choice between two colors, red and black, and the 214 questions are: 216 (1) Do you prefer red 218 (2) Do you prefer black 220 (3) Do you do have any opinion 222 and two persons posted messages to vote for (1), four persons posted 223 messages to vote for (2), and two persons stated that they did not 224 have any opinion, it is not clear whether the vote is based on 225 informed opinions or whether it is an attempt to bias the outcome. 226 It is important to note that the choice is not a popularity contest; 227 it is more about reaching the optimal rational decision. 229 If the two persons who voted for (1) explained their preference while 230 the four persons voting for (2) did not provide any explanation, the 231 first opinion (1) can bear more weight than the other opinions. In 232 essence, it is about evaluating the different opinions which have 233 been expressed. 235 3.2. Lazy Consensus 237 It is easier for people to agree, by doing nothing, than it is to 238 object. This is referred to as lazy consensus. It is doubtful 239 whether a person can fairly say that there is consensus when nobody 240 has expressed an opinion. 242 4. Security Considerations 244 Some decisions can have an impact on security. It is important that 245 decisions are careful considered so as to reduce the risks. 247 5. Conclusion 249 The IETF uses a consensus-driven process to reach a decision. The 250 process cannot be reduced to an algorithm; consensus is complex, 252 S. Moonesamy Consensus October 7, 2013 254 human and messy [DUSS]. The IETF chooses people to determine 255 consensus, and they do so based on their experience and judgement. 257 Consensus does not work well without accountability. The person 258 determining consensus should be able to explain the decision. It is 259 entirely acceptable for a person to disagree with the decision. It 260 is up to the person to explain why he or she disagrees and what he or 261 she disagrees to. Consensus decision-making is not only a matter of 262 listening to what people are are saying; it is also about of how they 263 are saying it, and what they are not saying. 265 6. Acknowledgements 267 The text about how to reduce the amount people disagree on was 268 written by Ralph Droms. 270 7. IANA Considerations 272 [RFC Editor: please remove this section] 274 8. References 276 8.1. Informative References 278 [RFC1310] Chapin, L., "The Internet Standards Process", RFC 1310, 279 March 1992. 281 [RFC1602] Internet Architecture Board and Internet Engineering 282 Steering Group, "The Internet Standards Process -- 283 Revision 2", RFC 1602, March 1994. 285 [RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines 286 and Procedures", RFC 1603, March 1994. 288 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 289 3", BCP 9, RFC 2026, October 1996. 291 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 292 Procedures", BCP 25, RFC 2418, September 1998. 294 [COUZIN] Couzin, Iain D., Krause, Jens, Franks, Nigel R., Levin, 295 Simon A., "Effective leadership and decision-making in 296 animal groups on the move", November 2004, 297 299 [CROWDS] John R.G. Dyer, Christos C. Ioannou, Lesley J. Morrell, 300 Darren P. Croft, Iain D. Couzin, Dean A. Waters, Jens 302 S. Moonesamy Consensus October 7, 2013 304 Krause, "Consensus decision making in human crowds", May 305 2007, 307 [DUSS] Dusseault, L., "Notes on IETF Rough Consensus", draft- 308 dusseault-consensus-00, June, 2008. 310 [FARM] Orwell, G., "Animal Farm", ISBN 0140126708, 1945. 312 9. Author's Address 314 S. Moonesamy 315 76, Ylang Ylang Avenue 316 Quatres Bornes 317 Mauritius 319 Email: sm+ietf@elandsys.com