Internet DRAFT - draft-moonesamy-consensus
draft-moonesamy-consensus
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,
<http://dx.doi.org/10.1038/nature03236>
[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, <http://dx.doi.org/10.1016/j.anbehav.2007.05.010>
[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]
