INTERNET-DRAFT S. Moonesamy Intended Status: Informational Expires: April 10, 2014 October 7, 2013 Consensus draft-moonesamy-consensus-00 Abstract Decision-making is difficult when there is a need to consider the interests of all of the affected parties and when it is important to gain widespread community consensus. This document discusses about consensus. It neither seeks to define consensus nor does it prescribe practices for the Internet Standards Process. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Expires April 10, 2014 [Page 1] S. Moonesamy Consensus October 7, 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Background The Internet Standards Process [RFC2026] was first documented in RFC 1310 [RFC1310]. One of the goals for achieving Internet standardization was openness and fairness. In July 1992, David Clark presented a vision of the future which covered the making of standards. The sound bite that is remembered to this day is: "We reject: kings, presidents and voting. We believe in: rough consensus and running code." RFC 1602 [RFC1602] highlighted that the process was difficult as there was a need to consider the interests of all of the affected parties and the importance of establishing widespread community consensus. 1.1. Introduction In groups of animals only a small proportion of individuals may possess particular information, such as a migration route or the direction to a resource. Individuals may differ in preferred direction resulting in conflicts of interest and, therefore, consensus decisions may have to be made to prevent the group from splitting [CROWDS]. This document discusses about consensus. It neither seeks to define consensus nor does it prescribe practices for the Internet Standards Process. There is a brief description of decision-making processes in Section 2. Consensus and decision-making are discussed in Section 3, with examples to illustrate the decisions. The conclusion is that people determine consensus, and they do so based on their experience and judgement. 2. Decision-making 2.1. Benevolent dictatorship The benevolent dictatorship is where one person or a small group of persons have the power to take decisions. There is a presumption of benevolence and wisdom. The following would not be seen as fair: "All persons are equal... but some persons are more equal than others." [FARM] Expires April 10, 2014 [Page 2] S. Moonesamy Consensus October 7, 2013 2.2. Voting The commonly-known decision-making procedure is simple majority rule where the decision is taken if more than one half of the group votes for it. It can lead to the group splitting. It is also against the goal of considering the interests of all the persons within the group. 2.3. Consensus A study showed that only a very small proportion of informed individuals is required in a group to achieve great accuracy in decision-making. It was also demonstrated that groups can make consensus decisions, even though informed individuals do not know whether they are in a majority or minority [COUZIN]. Consensus can be seen as a conclusion which any other person would reach if he or she was taking the decision. 3. Consensus and Decision-Making Consensus on technical issues is a matter of weighing the technical opinions which have been expressed. It is neither a vote nor a count of the number of persons who have stated a preference for or against a proposal. In the IETF, any attempt to determine consensus is more difficult if the issues are technical, economic and political. Impassioned discussion, with little technical content, leads to an impasse. It is up to the person making the determination to tease apart the points and find out how to reduce the amount people disagree on, find the bounds of the conversation, and separate out the technical issues. 3.1. Rough Consensus IETF Working Groups make decisions through a "rough consensus" process [RFC1603]. Consensus does not require that all participants agree although this is, of course, preferred. Rough consensus is a subjective decision as determining the general sense of agreement is a matter of judgement. 3.1. Decision-Making Consensus decision-making is a process, i.e. there are steps which are carefully followed until everyone is agreeable with the choices which they are provided with. People are given fair notice about the decision to be taken and how the decision will be decided. 3.1.1. Face-to-face sessions Expires April 10, 2014 [Page 3] S. Moonesamy Consensus October 7, 2013 RFC 1603 [RFC1603] mentioned that consensus can be determined by balloting, humming, or any other means on which the WG agrees (by rough consensus, of course). During a face-to-face session [RFC2418], Working Groups sometimes resort to humming to find out how to reduce the amount people disagree on. Humming allows each and every person in the room to express his or her opinion after listening or participating in the discussion about an issue. The advantage of humming is that a person can express an opinion as an individual without being subject to negative consequences (e.g. the person can express an opinion which is contrary to the interests of his or her organization). Humming is an effective way to gauge the "sense of the room". For example, if, in a room for twenty persons, there is a choice between two colors, red and black, and the questions are: (a) Hmm if you prefer red (b) Hum if you prefer black (c) Hum if you do not have any opinion and there is a soft hum for (a), a mild hum for (b), and a loud hum for (c), the "sense of the room" is neither for red nor for black. During a face-to-face session a Working Group might decide to have a "show of hands" to determine a preference. It is like having a vote which is not secret. The disadvantage is that the opinion expressed by the person is not secret and there is a risk that the person might be coerced to express a particular opinion. For example, if there is a choice between two colors, red and black, and the questions are: (i) Raise your hand if you prefer red (ii) Raise your hand if you prefer black (iii) Raise your hand if you do not have any opinion and two persons raised their hands for (i), four persons raised their hand for (ii), and nobody raised their hand for (iii), the decision is not clear. A decision can be undermined by people conforming to what other people in the group think. It is important not to encourage the perception that the decision-maker is trying to change the result. It is better to only try once to ask a group of persons to express their preference about a set of alternatives. It is to be noted that the Working Group takes the decision on its Expires April 10, 2014 [Page 4] S. Moonesamy Consensus October 7, 2013 mailing list and not in a face-to-face meetings. The preference stated during the face-to-face session is taken to the mailing list for confirmation and the decision is announced on the mailing list. 3.1.2. Mailing list discussions A significant problem for decision-making through a mailing list is that it is possible to bias the outcome as any person can express an opinion more than once. The IETF side-stepped that problem by weighing opinions instead of counting opinions. For example, if there is a choice between two colors, red and black, and the questions are: (1) Do you prefer red (2) Do you prefer black (3) Do you do have any opinion and two persons posted messages to vote for (1), four persons posted messages to vote for (2), and two persons stated that they did not have any opinion, it is not clear whether the vote is based on informed opinions or whether it is an attempt to bias the outcome. It is important to note that the choice is not a popularity contest; it is more about reaching the optimal rational decision. If the two persons who voted for (1) explained their preference while the four persons voting for (2) did not provide any explanation, the first opinion (1) can bear more weight than the other opinions. In essence, it is about evaluating the different opinions which have been expressed. 3.2. Lazy Consensus It is easier for people to agree, by doing nothing, than it is to object. This is referred to as lazy consensus. It is doubtful whether a person can fairly say that there is consensus when nobody has expressed an opinion. 4. Security Considerations Some decisions can have an impact on security. It is important that decisions are careful considered so as to reduce the risks. 5. Conclusion The IETF uses a consensus-driven process to reach a decision. The process cannot be reduced to an algorithm; consensus is complex, Expires April 10, 2014 [Page 5] S. Moonesamy Consensus October 7, 2013 human and messy [DUSS]. The IETF chooses people to determine consensus, and they do so based on their experience and judgement. Consensus does not work well without accountability. The person determining consensus should be able to explain the decision. It is entirely acceptable for a person to disagree with the decision. It is up to the person to explain why he or she disagrees and what he or she disagrees to. Consensus decision-making is not only a matter of listening to what people are are saying; it is also about of how they are saying it, and what they are not saying. 6. Acknowledgements The text about how to reduce the amount people disagree on was written by Ralph Droms. 7. IANA Considerations [RFC Editor: please remove this section] 8. References 8.1. Informative References [RFC1310] Chapin, L., "The Internet Standards Process", RFC 1310, March 1992. [RFC1602] Internet Architecture Board and Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994. [RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, March 1994. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [COUZIN] Couzin, Iain D., Krause, Jens, Franks, Nigel R., Levin, Simon A., "Effective leadership and decision-making in animal groups on the move", November 2004, [CROWDS] John R.G. Dyer, Christos C. Ioannou, Lesley J. Morrell, Darren P. Croft, Iain D. Couzin, Dean A. Waters, Jens Expires April 10, 2014 [Page 6] S. Moonesamy Consensus October 7, 2013 Krause, "Consensus decision making in human crowds", May 2007, [DUSS] Dusseault, L., "Notes on IETF Rough Consensus", draft- dusseault-consensus-00, June, 2008. [FARM] Orwell, G., "Animal Farm", ISBN 0140126708, 1945. 9. Author's Address S. Moonesamy 76, Ylang Ylang Avenue Quatres Bornes Mauritius Email: sm+ietf@elandsys.com Expires April 10, 2014 [Page 7]