Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc.
May 2003
Alternative Decision Making Processes
for Consensus-blocked Decisions in the IETF
draft-hardie-alt-consensus-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document proposes alternative decision-making processes
for use in IETF working groups. There are a small number of cases
in IETF working groups in which the group has come to consensus
that a particular decision must be made but cannot come to consensus
on the decision itself. This document describes alternative mechanisms
which can be used to come to a decision in those cases.
1. Introduction.
Dave Clark's much-quoted credo for the IETF cites "rough consensus
and running code" as the key criteria for decision making in the
IETF. Aside from a pleasing alliteration, these two touchstones
provide a concise summary of the ideals which guide the IETF's
decision making. The first implies an open process in which any
technical opinion will be heard and any participant's concerns
addressed; the second implies a recognition that any decision must
be grounded in solid engineering and the known characteristics of
the network and its uses. The aim of the IETF is to make the best
possible engineering choices and protocol standards for the
Internet as a whole, and these two statements guide it in making
its choices and standards.
In a small number of cases, working groups within the IETF cannot
reach consensus on a technical decision which must be made in
order to ensure that an interoperable mechanism or set of
standards is available in some sphere. In most of these cases,
there are two or more competing proposals at approximately the
same level of technical maturity, deployment, and specification.
Choosing among these proposals can be especially difficult when
each is optimized for slightly different use cases, as this
implies that the working group's best choice depends on the
participants' views of likely future use. Further problems arise
when different proposals assign costs in implementation,
deployment, or use to different groups, as it is a normal human
reaction to seek to prevent one's own ox being gored.
2. Rough Consensus as a baseline approach.
The Conflict Research Consortium at the University of Colorado
outlines the pros and cons of consensus as:
The advantage of consensus processes is that the resulting
decision is one that meets the interests of all the parties
and that everyone can support.Ê The disadvantage is that
developing such a decision can be a very slow process,
involving many people over a long period of time.Ê There is
also a relatively high probability of failure. If a quick
decision is needed, the consensus approach may not work.Ê
Consensus rule processes also tend to favor those that oppose
change and want to preserve the status quo. All these people
have to do is refuse to support any consensus compromises and
they will win (at least as long as they can delay
change). (CONFLICT)
Using "rough consensus" as a guideline limits some of
disadvantages of consensus processes by ensuring that individuals
or small factions cannot easily block a decision which has
otherwise general support. The second touchstone of "running
code" can also limit the disadvantages of consensus processes by
requiring that statements opposing particular proposals be
technically grounded.
These limitations do not change the core mechanisms of
consensus-building, however, and the IETF process continues to
require individual participants both to use their best engineering
judgment to select among proposals and to balance their own
interests with those of the Internet as a whole. Active
participation and a willingness to compromise, possibly on key
points, are needed. Historically, this has worked because a large
majority of participants have recognized that the Internet's
growth and enhancement are more important overall than any
specific short-term advantage.
In other words, the use of "rough consensus" is sufficient in most
cases in the IETF to ensure that individuals or small groups are
heard when they raise technical objections, but that they cannot
block progress when a general agreement has been reached. This
document does not suggest changing the usual mechanisms for
achieving forward progress; it proposes mechanisms for use when a
working group has consensus that it must make a decision, but it
cannot make that decision by the usual rules.
3. Conditions for use.
In general, working groups should consider using alternate
decision making processes when it is clear both that a choice must
be made and that the choice cannot be made by continued
discussion, refinement of specifications, and implementation
experience. A guideline for determining that these conditions
have been met is included below.
3.1 There is a clear decision to be reached.
There must be a clear statement of the decision to be reached.
This may be in the working group's charter, in requirements
documents, or in other documents developed by the working group.
Prior to any invocation of an alternate decision making process,
the Chair(s) should confirm with the working group that there is
general agreement on the decision to be reached.
3.2 Proposals are available in draft form.
Proposed solutions must be available as Internet drafts and must
be sufficiently specified to cause the Chair(s) to believe that
they could be, possibly with further refinement, published as an
IETF specification. If the Chair indicates to those proposing a
solution that it is insufficiently specified, concrete problems to
be resolved must be identified and a reasonable amount of time
provided to resolve those problems. Note that if one of the
proposed solutions is "do nothing", an explicit draft to that
effect must be available; it may, however, be produced when the
group invokes an alternate decision making process.
3.3 The working group has discussed the issue without reaching resolution.
Consensus-building requires significant amounts of discussion, and
there is no general rule for indicating how much discussion a
technical issue requires before a group should reach consensus.
If there is any question about whether the discussion has been
sufficient, the working group chair(s) should always err on the
side of allowing discussion to continue. Before using an
alternate decision making process, the working group chair(s)
should also make an explicit call for consensus, summarizing the
technical issues and the choice to be made. If new technical
points are made during the call for consensus, discussion should
continue. If no new points are raised, but the group cannot come
to consensus, the working group may consider using an alternate
decision making process. Under no circumstances is the working
group required to use an alternate decision making process.
3.4 There is an explicit working group last call to use an alternate method.
In item 3.3 above, it is noted that the Chair(s) should make an
explicit call for consensus on the technical issues and should
proceed only after that call has yielded no forward progress. A
different last call on the question of whether to use an alternate
decision making method is required, with a stated period for
comments by working group members. This is both to indicate that
the decision to use an alternate method should be taken at least
as seriously as the decision to advance a document on the
standards track and to provide a clear signal that this is a last
moment for participants to reconsider their positions. The
decision to use an alternate decision requires the rough consensus
of the working group, as determined by the Chair(s). The choice
of which alternate decision to use may be made in the last call or
may the subject of separate discussions within the working group.
If the group comes to consensus that an alternative method is
required but does not come to consensus on the method to use, an
external review team (c.f. section 4.1, below) will be formed.
4. Alternate methods.
In setting up an alternate method, care must be given that the
process by which the decision is reached remains open and remains
focused on making the best technical choice for the Internet as a
whole. The steps set out below provide a straw proposal for four
such mechanisms. These are relatively heavy weight systems,
partially to highlight the gravity of choosing to invoke these
methods and partially to ensure that the IETF community as a whole
is alerted to and kept informed of the process. Note that
alternate procedures have been used in the past; see RFC 3127
(RFC3127) for a description of that used in the decision between
two competing candidate protocols for Authentication,
Authorization and Accounting. By setting out these proposals,
this document does not intend to limit working group choice, but
to provide a set of well defined processes that obviate the need
for reinvention in most cases.
4.1 Alternate method one; external review team formation.
The working group notifies the IETF community that it intends to
form an external review team by making a public announcement on
the IETF-announce mailing list. That announcement should include
a summary of the issue to be decided and a list of the
internet-drafts which contain the alternate proposals. It should
also include the name and location of an archived mailing list for
the external review team's deliberations.
4.1.1 External review team membership.
External review teams have five members who must meet the same
eligibility requirements as those for a voting member of the
NomCom. Explicitly excluded from membership in review teams are
all those who have contributed to the relevant working group
mailing list within the previous 12 months, the IESG, the IAB, and
the sitting NomCom. Volunteers to serve on the review team send
their names to the IETF executive director. Should more than five
volunteer, five are selected according to the process outlined in
RFC2777(RFC2777). Participants in the working group may actively
solicit others to volunteer to serve on the review team but, as
noted above, they may not serve themselves if they have commented
on the list within the previous 12 months.
4.1.2 External review team deliberation.
The external review team is alloted one month for deliberations
and any member of the team may extend that allotment by two weeks
by notifying the relevant working group Chair(s) that the
extension will be required.
The team commits to reading the summary provided during the IETF
announcement and all of the relevant Internet drafts. Members may
also read the archived mailing list of the working group, and they
may solicit clarifications from the document authors, the working
group chairs, or any other technical experts they see fit. All
such solicitations and all deliberations among the review team of
the proposals should take place on the archived mailing list
mentioned in the IETF announcement. The team members may, of
course, have one-on-one discussions with relevant individuals by
phone, email, or in person, but group deliberations should be on
the archived list.
4.1.3. Decision statements.
Each member of the external review team writes a short decision
statement, limited to one page. That decision statement contains
a list of the proposals in preference order. It may also contain
a summary of the review team member's analysis of the problem and
proposed solutions, but this is not required. These decision
statements are sent to the archived mailing list, the relevant
working group chair(s), and the IESG.
4.1.4 Decision statement processing.
The Decision statements will be tallied according to
"instant-runoff voting" rules, also known as "preference voting"
rules (VOTE).
4.2 Alternate method two; mixed review team.
This mechanism allows for the working group to designate a review
team that involves those outside the working group as well as
those who have been involved in the process within the working
group. While it may appear that having a single representative of
each proposal will have a null effect on the outcome, this
unlikely to be the case except when there is a binary choice,
because of the rules for decision statement processing (c.f. 4.2.4
below). As in 4.1, the working group notifies the IETF community
that it intends to form a mixed review team by making a public
announcement on the IETF-announce mailing list. That announcement
should include a summary of the issue to be decided and a list of
the internet-drafts which contain the alternate proposals. It
should also include the name and location of an archived mailing
list for the external review team's deliberations.
4.2.1 Mixed review team membership.
Mixed review teams are composed of one designated representative
of each of the proposals, typically the Internet draft's principal
author, and six external members. Five of the external members
are selected as according 4.1.1. above. The six is designated by
the IESG as a chair of the group. Though the primary role of the
chair is to ensure that the process is followed, she or he may
vote and engage in the deliberations.
4.2.2 Mixed review team deliberation.
The review team is alloted one month for its deliberations and any
member of the team may extend that allotment by two weeks by
notifying the review team Chair that the extension will be
required.
The review team commits to reading the summary provided during the
IETF announcement and all of the relevant Internet drafts.
Members may also read the archived mailing list of the working
group, and any other technical experts they see fit. All such
solicitations and all deliberations among the review team of the
proposals should take place on the archived mailing list mentioned
in the IETF announcement.
4.2.3 Decision statements.
As in 4.1.3, above.
4.2.4 Decision statement processing.
As in 4.1.4, above.
4.3 Alternate method three; short-straw selection.
As in 4.1 and 4.2, the working group notifies the IETF community
that it plans to use an alternate decision mechanism by making a
public announcement on the IETF-announce mailing list. That
announcement should include a summary of the issue to be decided
and a list of the Internet-drafts which contain the alternate
proposals.
In this method, a single working group participant is selected to
make the decision. Any individual who has contributed to the
working group in the twelve months prior to the working group last
call on the technical question (c.f. 3.3, above) may volunteer to
serve as the decision maker. Individuals may qualify as
participants by having made a public statement on the working
group mailing list, serving as an author for an Internet draft
under consideration by the working group, or making a minuted
comment in a public meeting of the working group. The Chair(s)
may not volunteer. Each qualified volunteer sends her or his name
to the working group chair and the IETF Executive Director within
3 weeks of the announcement sent to the IETF-announce mailing
list. The IETF Executive Director then uses the selection
procedures described in RFC2777 to select a single volunteer from
the list. That volunteer decides the issue by naming the
internet-draft containing the selected proposal in an email to the
relevant working group chair, the working mailing list, and the
IESG.
4.4 Alternate method four; random assignment.
Among the small number of cases for which consensus in not an
appropriate method of decision-making are a tiny minority for
which the decision involves no technical points at all, but
involves the need to select among options randomly. The IDN
working group, as an example, needed to designate a specific DNS
prefix. As the decision involved early access to a scarce
resource, a random selection was required. In such cases, a
working group may ask IANA to make a random assignment from among
a set of clearly delineated values. Under such circumstances,
IANA will be guided by RFC2777 in its selection procedures. Under
extraordinary circumstance, the working group may, with the
approval of the IESG, ask IANA to select among a pool of Internet
Drafts in this way.
5. Appeals.
The technical decisions made by these processes may be appealed
according to the same rules as any other working group decision,
with the explicit caveat that the working group's consensus to use
an alternate method stands in for the working group's consensus on
the technical issue.
6. Security Considerations.
The risk to moving to a system like this is that it shifts the
basis of decision making within the IETF. The hope in providing
these mechanisms is that certain decisions which may be
intractable under consensus rules may be tractable under the rules
set out here. The risk, of course, is that forcing the evaluation
to occur under these rules may allow some set of individuals to
game the system.
7. IANA Considerations.
Section 4.3 may require the IANA to make random selections among a
known set of alternates.
8. Normative References
Eastlake, Donald 3rd. "Publicly Verifiable Nomcom Random Selection", RFC2777.
(RFC2727)
9. Non-Normative References
Mitton, D. et al. "Authentication, Authorization, and Accounting:
Protocol Evaluation", RFC3127. (RFC3127)
Center for Democracy and Voting. "Frequently Asked Questions about IRV",
http://www.fairvote.org/irv/faq.htm . (VOTE)
International Online Training Program on Intractable Conflict,"Consensus Rule Processes",
Conflict Research Consortium, University of Colorado, USA.
http://www.colorado.edu/conflict/peace/treatment/consenpr.htm
(CONFLICT)
10. Authors' Addresses
Ted Hardie
Qualcomm, Inc.
675 Campbell Technology Parkway
Suite 200
Campbell, CA
U.S.A.
EMail: hardie@qualcomm.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Datatracker
draft-hardie-alt-consensus-00
This is an older version of an Internet-Draft that was ultimately published as RFC 3929.
