Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF
draft-hardie-alt-consensus-02

Network Working Group                                      T. Hardie 
Internet-Draft                                         Qualcomm, Inc.  
Category: Experimental                                     April 2004

                  Alternative Decision Making Processes
               for Consensus-blocked Decisions in the IETF
                     draft-hardie-alt-consensus-02.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance
   with RFC 3668.

   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>.

    This Internet-Draft will expire in September 2004.

Copyright Notice

    Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

    This document proposes an experimental set of 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.  This is not meant to provide an exhaustive
    list, but to provide a known set of tools which can be used when
    required.

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.  In some cases,
    working groups can achieve consensus to advance multiple proposals
    and to either revisit the question when experienced has been gained or 
    to build the required mechanisms to handle multiple options for
    the life of the protocol.  In other cases, however, a working group
    decides that it must advance a single proposal. 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.

    This document puts forward a set of experimental mechanisms which
    for use in that small number of cases.  In order to gauge the
    results of those cases where one of these mechanisms is used, it is
    suggested that the Last Call issued to the IETF community note that
    such a mechanism was used and which one of the set was chosen.  If
    and when the community becomes satisfied that one or more of these
    methods is useful, it should be documented in a BCP for that small
    number of cases.

    In no way should this experiment or any future BCP for this small
    number of cases take precendence over the IETF's normal mode of
    operation.

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.  This should
    include a specific consensus call on whether the working group
    can advance multiple proposals or must select a single proposal
    for the work item.

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 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.  It also provides a clear signal that this is a last moment for
    participants to reconsider their positions.  The decision to use an
    alternate decision making process 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 be 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.

    In discussions of this draft, several points have been raised about
    the viability of any mechanism that requires consensus to use
    an alternative to consensus-based decision making.  Some of those
    concerns pointed out that groups having trouble achieving consensus
    on the technical matter may have similar problems achieving 
    consensus on the procedural matter.  Others have been concerned 
    that this will be used as an attempt to end-run rough consensus.
    These are all valid concerns, and they point both to the need
    to retain rough consensus as the baseline mechanism and to exercise
    caution when using these alternate methods.  More importantly,
    though, they highlight the nature of these alternatives.  They      
    are primarily mechanisms that allow people to see the need for
    compromise in a new way, to back away from entrenched technical
    positions by putting the technical choice in the hands of the
    broader community, and to highlight that the choice for each
    participant is now between achieving *a* decision and failure.
 
    There is a fundamental tension between the IETF community's 
    desire to get the best decision for a particular technical
    problem and the IETF community's desire to get a decision that
    has community buy-in in the form of rough consensus.  These
    mechanisms cannot resolve that fundamental tension.  They may, 
    however, provide a way forward in some situations which might
    otherwise end in deadlock or stagnation.
   

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 set out a voting member of the 
    NomCom (2727bis).  Explicitly excluded  from participation in 
    external 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)
    note that the same rules on affiliation apply here as to the NomCom,
    to reduce the burden on any one organization and to remove any
    implication of "packing" the review team.
  
    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 sixth 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; qualified 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)

  
J. Galvin, Ed. "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees". 
draft-ietf-nomcom-rfc2727bis-09.txt (2727bis).

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.  Acknowledgements

    The author would like to acknowledge the contributions and
    challenging exchanges of reviewers of this draft, among them
    John Klensin, Dave Crocker, Pete Resnick, Spencer Dawkins,
    Scott Bradner, Joel Halpern, Avri Dora, Melinda Shore, Harald
    Alvestrand, Alex Simonelis, Keith Moore, Brian Carpenter,
    and Alex Rousskov.  

11. Author's Address

    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.