[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                             L. Dusseault
Internet-Draft                                               CommerceNet
Intended status: Informational                          December 4, 2007
Expires: June 6, 2008

                     Notes on IETF Rough Consensus

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 6, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   The IETF makes decisions using what we refer to as rough consensus,
   using a great deal of flexibility and judgement depending on the
   situation.  This document documents various approaches to determining
   rough consensus.

Dusseault                 Expires June 6, 2008                  [Page 1]

Internet-Draft                  Consensus                  December 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Consensus  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Comparing Decision-Making Processes  . . . . . . . . . . .  4
     2.2.  Consensus as a Process . . . . . . . . . . . . . . . . . .  5
     2.3.  Informality  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4.  Who may participate  . . . . . . . . . . . . . . . . . . .  6
     2.5.  When Silence is Consent  . . . . . . . . . . . . . . . . .  7
     2.6.  Questionable tactics in consensus calls  . . . . . . . . .  8
     2.7.  Backroom dealing . . . . . . . . . . . . . . . . . . . . .  9
   3.  Consensus calls in meeting rooms . . . . . . . . . . . . . . .  9
     3.1.  Easy consensus calls . . . . . . . . . . . . . . . . . . . 11
     3.2.  Fine-tuning consensus calls  . . . . . . . . . . . . . . . 11
     3.3.  Chains of consensus calls  . . . . . . . . . . . . . . . . 12
   4.  Consensus Calls in Mailing Lists . . . . . . . . . . . . . . . 13
     4.1.  Sample effective consensus call on-list  . . . . . . . . . 13
     4.2.  Declaring consensus on-list  . . . . . . . . . . . . . . . 14
     4.3.  Confirming in-room consensus on Mailing List . . . . . . . 14
   5.  Alternative Approaches . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Taking Time  . . . . . . . . . . . . . . . . . . . . . . . 15
     5.2.  Deciding to Make a Decision  . . . . . . . . . . . . . . . 16
     5.3.  Using votes and plurality decision-making  . . . . . . . . 16
     5.4.  Let the Editor Choose  . . . . . . . . . . . . . . . . . . 17
     5.5.  Flipping a coin  . . . . . . . . . . . . . . . . . . . . . 17
   6.  Accountability . . . . . . . . . . . . . . . . . . . . . . . . 17
     6.1.  Challenging Consensus Call Results . . . . . . . . . . . . 18
     6.2.  Sample challenge to a mailing list consensus call  . . . . 19
     6.3.  Overturning Consensus Call Outcomes  . . . . . . . . . . . 19
   7.  Recommendations for Individual Participants  . . . . . . . . . 20
     7.1.  What if you don't agree? . . . . . . . . . . . . . . . . . 20
     7.2.  Avoiding blocked consensus . . . . . . . . . . . . . . . . 21
     7.3.  Questioning the process  . . . . . . . . . . . . . . . . . 21
     7.4.  Final tips . . . . . . . . . . . . . . . . . . . . . . . . 22
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   11. Informative References . . . . . . . . . . . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24

Dusseault                 Expires June 6, 2008                  [Page 2]

Internet-Draft                  Consensus                  December 2007

1.  Introduction

   Consensus is a way for people to make decisions and generate
   commitment to those decisions.  Coming to decisions by consensus is
   difficult and time-consuming.  It's a much broader and more flexible
   process than simply picking a position and seeing if everybody
   agrees.  The process cannot be reduced to an algorithm; consensus is
   complex, human and messy.  We choose skilled people to help us come
   to consensus, and they do so based on their experience and judgement.

   The IETF has much folklore about its "rough" consensus.  Many people,
   not just chairs, make statements about a group's consensus.  There
   are many opinions about what approaches are OK or not in determining
   consensus.  The IETF also has some unique approaches to determining
   consensus, including "hums" taken to gauge consensus in meeting rooms
   by volume of sound generated.

   This document attempts to provide detail on how rough consensus works
   on IETF mailing lists and in IETF meetings, with some suggestions for
   dealing with exceptions and difficult cases.  The "Alternative
   Decision Making Process for Consensus Blocked Decisions" described in
   [RFC3929] contains valuable approaches for certain difficult cases.
   In contrast, this document describes more of the common context and
   practice of the IETF.  The reader is particularly recommended to read
   Section 2 of [RFC3929].

   Most of the information here can be construed as either advice and
   ideas for chairs or an explanation for participants of what they
   might see.  The last section is advice for individual participants.

   Information provided here is not intended to create any IETF process
   requirements that are not already extant: nor is there any intent to
   limit chairs from trying other approaches.  There are many ways to
   develop and determine rough consensus.  In choosing approaches,
   chairs need be guided the goals of the Internet Standards Process in
   [RFC2026].  There are many difficult tradeoffs.

1.1.  Terminology

   The word "chair" is used in this document to identify the person
   running the consensus call.  Sometimes this person is not the Working
   Gropu (WG) chair.  The phrase "WG chair" or "meeting chair" is used
   when it's necessary to be specific about context.

   The word "vote" is used informally in this specification and doesn't
   usually imply formal vote counting -- it's just that the phrase "to
   vote" is shorter than "to express one's preference on the mailing
   list or in a meeting room".

Dusseault                 Expires June 6, 2008                  [Page 3]

Internet-Draft                  Consensus                  December 2007

2.  Consensus

   This section discusses what consensus is, including some of the
   subtler ways consensus differs from voting, what silence means in
   consensus, and a couple areas that are sometimes problematic.

2.1.  Comparing Decision-Making Processes

   Formal, classic consensus cultures [BUJ] are rather rare.  They can
   be found in quite a few intentional communities and in a small number
   of boards, committees and project teams.  In many thriving consensus
   cultures, any veto by any member really can, and does, block decision
   making until some opinion or proposal changes.

   There are many organizations that do weak consensus; they prefer to
   get consensus but not if it's too difficult.  These organizations may
   depart from formal consensus by limiting who can veto, by limiting
   who can make proposals or how many proposals there can be, by
   limiting discussion that might lead to new proposals or consensus
   changes, or by having fallback non-consensus processes (e.g. the
   development manager decides) when consensus takes too long.

   Parliamentary rules such as Robert's Rules of Order are not part of
   most consensus processes.  They are not formally used in the IETF,
   although some parliamentary rules are adopted ad-hoc as useful
   habits.  One notable difference from many parliamentary rules sets is
   that the chair of an IETF group or meeting may vote.

   Majority rule is common, easy and fast.  However, it often compares a
   limited and closed set of proposals.  In the worst case, time
   pressure (real or imagined) could cause a group to do a vote on the
   first proposal at hand, which could pass by a slim margin despite the
   suspicion of a few participants that it has flaws.  Technical
   excellence requires the creative exploration of alternatives.  A
   consensus process doesn't guarantee creativity, but it does encourage
   it.  It's up to chairs (with help from participants) to note when an
   important decision is at hand, and wait for multiple proposals before
   calling for a decision.

   Another problem with majority rule systems, in the context of the
   IETF, is they tend to involve competition in 'winning' a vote.  Since
   IETF standards are only adopted voluntarily by implementors, that
   means that adversarial position-taking can hamper the acceptance and
   adoption of a standard.

   Building United Judgement [BUJ] has extensive discussion and examples
   comparing majority rule to consensus.

Dusseault                 Expires June 6, 2008                  [Page 4]

Internet-Draft                  Consensus                  December 2007

2.2.  Consensus as a Process

   Consensus is not simply a decision.  It can't entirely be described
   in a moment in time despite the immediacy of our hums; it's an
   evolving balance.  The hum is a snapshot of the current state of the
   evolving consensus among the present population.  A chair pays
   attention to the whole changing picture to decide whether there is
   already a consensus, whether more discussion is needed, and when to
   do a formal call for consensus.

   A chair must continue to pay attention to the balance after a
   consensus call to see if it has shifted and if that's important
   enough to go back and fix.

   A chair can weight the balance according to the experience of those
   offering views and whether there have been convincing arguments about
   some option simply not working.  We allow and value input from those
   with experience and those without, but the "running code" part of the
   catchy "rough consensus and running code" phrase means that we pay
   special attention to input based on implementation experience.  It's
   good if the chair can make this explicit:

      "I think we've heard a convincing argument from Aaron that this
      leaves servers open to DOS attacks, so I conclude this feature
      can't be added as-is."

2.3.  Informality

   Consensus is not always formally called or determined.  Sometimes
   draft editors (or authors) ask for opinions to help decide what to
   write.  Sometimes editors make assumptions about what the consensus
   is.  If the editor gets the sense of consensus right, there may be no
   need to do a formal consensus call.  If the editor at least takes a
   reasonable stab at sensing the consensus there should be no reason
   for reproach.  If there's a problem, anybody can ask the WG chair to
   do an explicit consensus call.

   In meetings, it's not always the meeting chair who asks for consensus
   and figures out how to word the question.  It can be anybody who
   thinks they have grasped the issue and is helping by asking for
   consensus.  In these cases it's polite to turn to the meeting chair
   to state the outcome, but sometimes in difficult cases the meeting
   chair turns to respected, experienced or unbiased members of the
   community to help determine the outcome of a consensus call.

   Votes on a mailing list may be simply "+1" or may express misgivings
   or caveats, and it's up to the chair to interpret or ask for
   clarification.  Votes in a meeting room are often hums, but sometimes

Dusseault                 Expires June 6, 2008                  [Page 5]

Internet-Draft                  Consensus                  December 2007

   the chair asks for hands to be raised instead, or simply interprets a
   bunch of negative comments at the microphone as demonstrating a
   consensus against a proposal.

2.4.  Who may participate

   The IETF is extremely open about allowing participation in consensus
   calls.  You may see some of the following:

      1.  A hum from a person in a meeting room who does not follow the

      2.  A mailing list vote from a person who is not subscribed to the

   Note that it may be impossible to determine that somebody does not
   read the list -- lists may be read through the list archive site or
   mailing list mirror services.

      3.  Multiple votes, whether the same or different, from multiple
      people from the same organization.

      4.  An individual deferring to somebody else in their organization
      who has already voted.

   We count individuals at the IETF, not organizations, but don't force
   everybody to vote.

      5.  Votes in the jabber room during a meeting.

      6.  Votes at the microphone, in Jabber, by humming and on the list
      -- even from the same person.

   We rely on chairs to roughly adjust for repeat voting.  We don't
   encourage this, but we allow it because we hope that people explain
   their preference each time apart from the hum.

      7.  Votes from chairs, ADs, secretaries, document authors and

   Sometimes the author's vote is implicit in their proposal but we
   don't stop them from voting.

   When chairs do contribute their own opinions to a debate (which is
   not required but is certainly allowed) it helps to be explicit.

Dusseault                 Expires June 6, 2008                  [Page 6]

Internet-Draft                  Consensus                  December 2007

      "Chair hat OFF: I don't like requiring resolvability, it gives no
      benefit beyond uniqueness which we have already.  Chair hat ON: So
      far I see only weak support for resolvability, and several against
      it, so I don't think we have consensus to add that to the spec so
      far.  "

2.5.  When Silence is Consent

   One way of calling consensus is to summarize what might be the
   consensus position (e.g. to accept a particular proposal) and
   explicitly ask the group if there are any objections.  This is a
   little different from calling consensus when two alternatives are
   provided, because the WG chair may assume that a lack of clear
   objections constitutes approval of the consensus call as stated.
   Obviously a chair can steer consensus towards proposals in this way,
   but the IETF tries to pick chairs who have technical and engineering
   judgement in order to help us reach quick decisions when it's

   When a consensus call in the meeting room has a clear result and the
   result is minuted and posted to the mailing list, silence can be
   taken to mean consent -- the consensus has been confirmed.  WG
   participants who cannot make it to a meeting are given ample
   opportunities (Jabber participation, audio feeds and minutes on the
   list) to learn about the consensus call and raise objections.

   One situation that might be abused is when 20% of a WG favour one
   approach, 20% favour another, and the rest are silent.  It is
   possible to construct questions in a biased manner so that the chair
   assumes that the silent majority agree with the approach the chair
   favours.  In meeting rooms we frequently ask for "hums for" and "hums
   against" in order to make sure that we don't see consensus where
   there is none (or even "hums for option A", "hums for option B",
   "don't care" and "something else").  On mailing lists it's easier for
   people to advocate directly for the the outcome they think best so we
   don't typically ask both sides of the question.  Chairs try to be
   responsible about seeing when the group's expressed opinion is
   balanced and try to get more input or encourage further discussion.

   Sometimes silence means disinterest.  On the principle that
   unimportant work crowds out the attention available for important
   work, the IETF should not in general encourage much time spent on
   unimportant work.  To help make that happen, chairs need to determine
   how important a proposal is before accepting it as a WG work item.
   It's not enough for an author to explain a proposal and answer a few
   questions; there must also be enough explicit interest to adopt a
   work item.  It's up to the WG chair to be the bad guy if necessary
   and tell the author that there is not a strong enough consensus to

Dusseault                 Expires June 6, 2008                  [Page 7]

Internet-Draft                  Consensus                  December 2007

   adopt the work item.

   The same principle can be applied to new features suggested for
   addition, or even to features which are part of an important proposal
   (when the specification can be simplified without reducing its

   Here's an example from real life of an issue where the person who
   raised the issue only suggested a problem with text, not a
   resolution.  The issue was resolved with the text unchanged because
   of silence.  In this case, the chair usefully made this explicit
   rather than implicitly allowing the text to remain unchanged.

      "There has been no additional discussion on this issue since draft
      -02 came out.  This issue is now considered closed.

2.6.  Questionable tactics in consensus calls

   Once in a while the IETF also sees what may appear to be attempts to
   stack a vote.  Some possibilities:

   1.  bringing extra people to a meeting to hum on cue

   2.  causing extra participants (perhaps even dummy accounts) to voice
       opinions in a Jabber room or mailing list

   3.  humming into the microphone

   4.  very loud humming

   We can't always tell if these are inappropriate or intentional.  Case
   1 might appear to arise when experts in a security technology come to
   offer an opinion on the security choices in a WG they don't normally
   participate in.  This may create a difficult situation for the chair
   to overcome, but these are still valid and appropriate community
   opinions.  Case 4 actually illustrates one of the strengths of
   humming, because it allows us to express and hear urgency and
   strength of feeling in both directions (chairs have at times heard
   such apathetic hums about how a feature should work that they
   proposed dropping the feature).

   If there is a suspicion of foul play, the chair can quickly ask for
   participants to behave better and call for consensus again, or even
   repeat the call later on a mailing list.  However, the chair is not
   required to overturn a consensus just because of accusations of foul
   play.  Because of the many ways that IETF consensus calls can
   possibly be gamed, chairs must at times make judgement calls about
   what the consensus really is rather than have it be mechanically

Dusseault                 Expires June 6, 2008                  [Page 8]

Internet-Draft                  Consensus                  December 2007


   Working group participants are advised to keep their mouths closed
   while humming, as it not only encourages fair humming but is also
   more attractive.

2.7.  Backroom dealing

   When a small number of people get together for a technical
   conversation, and information learned in this conversation informs
   their opinions and proposals in meetings and on the public mailing
   lists, we generally consider this to be a *good* thing.  Sometimes
   it's easier to explore an idea or explain a difficult point in small
   groups.  Chairs and ADs frequently interact with small groups of
   participants in order to break down a consensus block or solve an
   issue that's not getting far on the mailing list.  Often the outcome
   of such a conversation becomes quite naturally public even though the
   conversation itself wasn't.  Sometimes the conversation remains
   private because to relate it publicly would be tedious, pointless or
   somehow harmful.

   As always, it's up to everybody involved to balance openness with
   other values including fairness, efficiency and technical

   Note also that the IETF has rules about design teams [RFC2418].

3.  Consensus calls in meeting rooms

   We know from organizational psychology research that in-person
   decision-making has different characteristics than computer-mediated
   decision-making.  Some examples:

   o  When we evaluate hums and hand-raising compared to email votes, we
      use much different cognitive tools.  In-person voting is nearly
      instantaneous and relies on visual and auditory impressions,
      whereas email voting relies on interpretation, abstraction and

   o  Emotional influence is probably stronger in meeting rooms.  On the
      one hand, there may be more pressure to conform (probably bad when
      technical judgement is needed).  On the other hand, there may be
      valuable information channels in meeting rooms that we just don't
      have access to in email, such as judging when somebody is
      uncertain about a statement or position.

Dusseault                 Expires June 6, 2008                  [Page 9]

Internet-Draft                  Consensus                  December 2007

   o  Email tends to polarize and is prone to flames [AA].

   o  Groups that solve problems in-person tend to share more hidden
      information than computer-mediated groups [Hol].

   The IETF approach is to combine computer-mediated distributed
   interactions with in-person meetings.  Sometimes a protracted on-list
   argument can be resolved by bringing participants together.

   In meeting room consensus calls, we always assume we are asking for a
   complete sense of the room, not just new votes.  This is quite
   different from mailing list consensus calls discussed shortly, where
   frequently chairs solicit only new opinions or information.

   Chairs frequently ask who has read a document before doing a
   consensus call related to that document.  This can be useful for a
   number of reasons:

   o  Can weigh opinions from informed partipants more heavily

   o  Might shame people who haven't read documents from expressing
      uninformed opinions in the first place

   o  Can gauge if there is enough expertise to even ask the consensus
      question and expect a good result

   o  Can gauge if there's insufficient interest for the work in the
      first place

   Once the consensus call is made, the creative discussion of
   alternatives is over at least for the time being.  If a participant
   has a new contribution -- a new alternative, a flaw in one of the
   alternatives or a new reason to consider one of the alternatives
   better -- this should be brought to the attention of the chair as a
   polite interrupt if time permits.

   Chairs often pay careful attention to the wording of consensus calls
   in meetings, as do attendees.  Once in a while, nuances the wording
   of the alternatives makes a significant difference in outcome.

   For the minutes, jabber logs and audio recording, the chair should
   state the outcome after the consensus call (in particular, raised
   hands cannot be seen via jabber or audio feeds).  Even though hums
   taken in meetings can be confirmed or not on the mailing lists (see
   section 4.3), chairs sometime state the consensus as if it were
   final.  We also see phrases like "The Bar BoF consensus was..." which
   is obviously also limited to the participants of the Bar BoF, not to
   an official WG.  Since this is often simply a shorthand for a more

Dusseault                 Expires June 6, 2008                 [Page 10]

Internet-Draft                  Consensus                  December 2007

   accurate but no more helpful formulation, one should not quibble with
   this wording.

   It may be worth pointing out that not every decision should be taken
   with hums in the room; that would be very inefficient.  Good issues
   to address in meeting hums are often difficult issues involving
   preference tradeoffs rather than pure technical feasibility.

3.1.  Easy consensus calls

   If a discussion isn't too heated the chair might simply take a stab
   at declaring consensus, ready to back off if the declaration was

      e.g.  "Will suggests we deprecate error code 410.  Shall we do
      that then? [hears approval noises] Good"


      e.g.  "Will suggests we deprecate error code 410.  Shall we do
      that then? [hears objections] Ok, it seems we don't all agree.
      Can we hear from the objectors?"

3.2.  Fine-tuning consensus calls

   A chair can fine-tune the wording of consensus calls on the fly.

      Chair: Those in favour of proposal A, hum

      WEAK HUM

      Chair: Those against?

      SOME HUMS and MUTTERING about wording of consensus call

      Chair: Let me restate.  Those in favour of proposal B?

      WEAK HUM

      Chair: That was rather indecisive.  Those who would accept either


      Chair: Do we have a problem with the two alternatives?

      ... group explores more solutions

Dusseault                 Expires June 6, 2008                 [Page 11]

Internet-Draft                  Consensus                  December 2007

3.3.  Chains of consensus calls

   In a meeting, a chair can make a related chain of consensus calls.
   An experienced chair can make progress quickly by narrowing down the
   solution set at a high level first then at lower levels.

   One specific use of this is to first call for consensus on how to
   make a decision on a difficult issue, then to call for consensus on
   the issue itself.

   Example consensus call chain

      Chair: We've been arguing about the details of this for quite a
      while.  Do we have enough information to make a decision on Sue's
      proposal?  Those who believe we're ready to make a decision, hum.


      Chair: Those who don't believe we're ready, hum.


      Chair: That's in favour of making a decision, so here's the
      decision: Do we generally believe that we want the ability to
      fragment?  Those who want fragmentation, hum.


      Chair: Those who don't want fragmentation at all, hum

      WEAK HUM

      Chair: Assuming we want fragmentation capability then.  Do we want
      fragmentation to be limited to messages over a certain size, not
      picking the size just yet but in principle?  Those in favour of
      allowing fragmentation all the time, hum

      WEAK HUM

      Those in favour of allowing fragmentation only on large messages,


      Chair: Ok, so only on large messages.  Those in favour of
      fragmentation allowed only on messages over 10,000...

Dusseault                 Expires June 6, 2008                 [Page 12]

Internet-Draft                  Consensus                  December 2007

4.  Consensus Calls in Mailing Lists

   Some WGs only do consensus calls in mailing lists.  Sometimes these
   are WGs that never meet (and difficulties may be created in the long
   run by never meeting face to face -- but that's a topic for another
   document).  In other cases, the WG may meet but have a preference for
   doing consensus calls on-list only.

   Consensus calls on mailing lists are more obviously a continuum, a
   balance arrived at over time.  An initial proposal might inspire a
   few agreements or disagreements immediately, creating the first sense
   of possible consensus.  It's actually quite frequent for an early
   decision to be obvious to everybody.

   If consensus isn't obvious immediately, the discussion typically
   plays on for a while and additional opinions get added to the mix,
   and alternative proposals may be made.  At some point the chair may
   explicitly make a consensus call.  Some WGs expect that even
   participants who have already stated a position will repeat their
   opinions after an explicit consensus call, while other WGs expect
   that any positions already stated still stand, and only new or
   changed positions need to be stated.  It can't hurt for chairs to be
   explicit about the expectation.

   Mailing list consensus calls need not be exclusive to a small set of
   alternatives.  The discussion sparked by the consensus call can and
   should include new alternatives or creative compromises if any are
   thought of.

4.1.  Sample effective consensus call on-list

   This email is effective in that it's clear that only new opinions are
   solicited, and how a participant can avoid confusion over what issue
   is discussed.

      From: Steve
      To: Example WG
      Subject: Open issues status

      We have three open issues:

      #87  Section 3.3  inconsistent use of word "modify"
      #89  Security Considerations needs to address DoS
      #90  Retry limits

      Are there any *new* (or changed) positions on these issues
      before I declare consensus based on the discussion so far?
      Please send one email per issue and include the issue number

Dusseault                 Expires June 6, 2008                 [Page 13]

Internet-Draft                  Consensus                  December 2007

      in the subject.

4.2.  Declaring consensus on-list

   It's helpful to be explicit about consensus reached.  Chairs need to
   state what an outcome is for those who aren't paying attention, for
   the record, and to remind those still arguing for different
   alternatives to present new information or accept the outcome.


      From: Alexander
      To: Example WG
      Subject: Issue #xxxx ReSubmission -- summary

      So far I see some support for and elaboration of the
      resubmission proposal,  although there was some dissent.
      I think there's a consensus around allowing resubmission
      even without a server error.  I saw the proposal to require
      servers to accept resubmission but I didn't see any tangible
      benefit to that.
      Thus, the proposed resolution is that clients MAY resubmit, and
      servers MAY accept or reject resubmissions.

      We don't have consensus on whether the resubmit must have the
      same message ID, so I'd like to see more input on that.

4.3.  Confirming in-room consensus on Mailing List

   Although consensus calls in meetings must be confirmed on the list,
   we have flexibility in how this is done.  Often the consensus call is
   noted in the meeting minutes and silence (of two weeks or more) is
   considered to be consent.  Although [RFC4677] says that "Any decision
   made at a face-to-face meeting must also gain consensus on the WG
   mailing list", [RFC2418] requires that the in-person opinions remain
   part of the consensus, and implies that once mailing list
   participants have been given the opportunity to understand and
   consider objections, the in-meeting consensus may well prevail
   without calling consensus from scratch: "the volume of messages on a
   topic is not, by itself, a good indicator of consensus".

   The population that votes on a mailing list can be somewhat different
   than the population that votes meeting room.  Between meetings,
   people are more likely to vote against the consensus than bother to
   send a vote confirming the consensus so far, and this bias can
   magnify the appearance of dissent.

   The redress for people who disagree with the result of an in-room

Dusseault                 Expires June 6, 2008                 [Page 14]

Internet-Draft                  Consensus                  December 2007

   consensus call is to dissent on the mailing list, ideally within two
   weeks of meeting minutes being published (which, regrettably, is
   often a month or more after the meeting itself).

   When chairs do review a meeting decision on the mailing list, since
   the votes made during the meeting (and possibly from before the
   meeting) are already taken into account, it's not very helpful for
   participants to provide redundant opinion statements.  In rare cases,
   a WG chair may have to ask everybody to restate their opinion even if
   they have already given it, in which case chairs must be very
   explicit about requesting this.

5.  Alternative Approaches

   Sometimes proposals are too hotly debated or too close to call
   consensus easily.  These are a number of approaches that a chair
   might use to arrive at a decision, including those recommended in
   [RFC3929] (external or mixed review team, short straw, and random

5.1.  Taking Time

   It's often quite effective for the chair to put off a consensus call,
   or having made a consensus call, to put off declaring an outcome.
   Although this sounds like an inefficient use of time, it can allow
   the WG to make progress on easier issues until more information is
   in.  Recall that consensus is not just about making a decision, it's
   also about exploring alternatives, understanding a problem and
   creating commitment among participants; extra time can help
   particularly if one or more of these facets needs more work.


      "We're still having significant technical discussion on this.  I
      know Shuichi had a strong opinion and he's not here, and it's
      possible his opinion could change based on some of this.  But
      we've run out of time in this meeting, so let's bring this
      discussion back to the mailing list.  Amy can you explain the race
      condition on the list?..."

      "I just heard weak hums on both sides of this issue, yet since
      it's an important issue, I think we want a stronger consensus.
      Does anybody have any other solutions to suggest? ... [silence]
      ...  Let's let this one marinate a bit.  We've got fourteen other
      open issues to work on, I think that will take us a couple months,
      and we can revisit this later."

Dusseault                 Expires June 6, 2008                 [Page 15]

Internet-Draft                  Consensus                  December 2007

   Taking extra long time should not be the first choice if quicker
   solutions are available.  A chair that finds too many decisions
   taking too long should start to try to find shortcuts.  A pattern of
   long and difficult decision-making might be an indication of a WG
   that needs to have a few beers together, or has grown too small and
   entrenched.  New people can be brought in temporarily (external
   review) or permanently, or the chair can compromise on the goals,
   leaving more work undone than previously intended.

5.2.  Deciding to Make a Decision

   Sometimes opinion is narrowly split between two or more alternatives
   even after lengthy discussion, yet in the end the WG is willing to
   accept an arbitrary outcome once one is fairly chosen.  The WG may
   choose to use a non-consensus way to pick an alternative (e.g.
   counting votes) and we may still consider the outcome to be rough

   Often this "meta-decision" -- the decision to accept a decision -- is
   made in one consensus call in an in-person meeting, followed by the
   decision itself.  In-person meetings are great for the quick
   turnaround to make this possible.  It's always nice to have explicit
   WG permission to take an alternative approach.

      "Let the minutes note that the WG agreed to a plurality vote in
      order to make a decision on this issue"

5.3.  Using votes and plurality decision-making

   When a chair decides to count votes carefully, this can mean that the
   WG explicitly chose plurality decision-making to resolve an impasse.
   (It can also mean that the chair is covering their ass in a WG where
   an individual is being difficult about what is actually a rough
   consensus that the individual would rather not have to accept.)

   It's usually obvious how to count votes in a mailing list, or if it's
   not obvious the longer time scale can allow clarification.  Chairs
   should encourage participants to vote openly.  Votes in private email
   to the chair make consensus more difficult, and the outcome less
   transparently justifiable.  A close call should not depend on private
   votes if at all possible.

   It's somewhat less obvious how to vote in a room.  Chairs may
   sometimes want to make statements on how the voting will proceed
   before attempting to call the vote and count the results.

   o  Is it OK to vote for two proposals?  If allowed, this can help
      show whether one proposal is acceptable to many, even if it's not

Dusseault                 Expires June 6, 2008                 [Page 16]

Internet-Draft                  Consensus                  December 2007

      the favourite proposal for most.

   o  Will votes in the Jabber room be counted?

   o  Who will do the counting?

5.4.  Let the Editor Choose

   Many decisions are not suitable for consensus calls.  If a
   participant argues for a particular document organization, but the
   document author prefers the document organization they have already,
   a chair should usually defer to the author.  The choice of names for
   error codes or namespaces is frequently up to the author.  We do not
   write documents (even WG documents) by committee in the IETF.
   Editorial discretion is still a valid part of our rough consensus.

   When the WG chair chooses a document editor and makes a point to use
   that term rather than 'author', it's typically with the understanding
   that the editor will take his cues from the WG and put the WG
   decisions in the document.  That doesn't mean that the editor can't
   have technical or editorial opinions and contribute them to the
   consensus.  In fact, the editor's opinion should not be taken
   lightly, on the grounds that they are paying attention, are
   knowledgeable about the domain, and were selected as editor for their
   abilities to think about and explain technical issues as well as for
   listening carefully to a variety of opinions.

5.5.  Flipping a coin

   It's OK to flip a coin.  A coin-flip may be perfectly appropriate to
   make a minor decision quickly and fairly, or to choose between two
   alternatives that are well-balanced in support and tradeoffs.  If
   there are two element names under consideration for an XML element,
   after a brief argument about which name is better, a chair may flip a
   coin (or allow the editor to flip a coin) and declare one the winner.

   It's OK even to virtually flip a coin.  Again, with two alternative
   names having been discussed for five minutes, a chair might say "Ok,
   enough of this, let's pick the first one and move on."  Participants
   can assume that the chair is acting out of a desire for efficiency
   and not in order to destroy fairness.

6.  Accountability

   Those who call consensus are accountable to the community and
   responsible for outcomes.  They should be prepared to explain their
   decisions, and at times even review and revisit their decisions.  To

Dusseault                 Expires June 6, 2008                 [Page 17]

Internet-Draft                  Consensus                  December 2007

   explain consensus decisions, it always helps to have a good record.
   Where possible, the consensus record can be public: well-minuted
   consensus decisions in proceedings (required anyway), along with
   clear conclusions to consensus calls on public mailing lists.

   Chairs who use design teams and creative consensus calls (e.g.
   plurality votes) are more likely to be called to account for
   decisions, and appropriately so.

6.1.  Challenging Consensus Call Results

   Chairs and ADs make great efforts to attend meetings and read every
   email on a mailing list in order to have an ongoing sense of
   consensus on all important issues.  In addition, there may be hallway
   discussions or phone conversations with information or opinions
   relating to a consensus decision.  We can't second-guess every
   consensus call.  Sometimes we have to trust the decision history and
   long-term performance of the person chosen to make consensus calls.

   It is appropriate to discuss the process details of a consensus call
   at times.  For example, one might alert the community and its leaders
   to questionable aspects of an important and close consensus call.  An
   example of this was a meeting where participants voted either
   remotely via Jabber or in the physical room.  Later, the chairs
   learned from private input that several of the Jabber votes were from
   dynamically-generated nicknames that had all connected to Jabber at
   the same time from the same IP address.

   Sometimes, learning of an irregularity can lead a chair to reset and
   call for consensus again.  However, if there were a rule insisting on
   a reset, this could easily be manipulated by bad actors introducing
   procedural irregularities in order to force new consensus calls.
   Even when informed of distasteful tactics and irregularities in the
   call, it's still up to the chairs whether to let a consensus stand.

   When a previous decision is invoked, sometimes WG participants say
   something like "We decided this in Oslo", referring to a meeting.  If
   a consensus call was made in a meeting in Oslo and not shortly
   overturned on the list, then this statement is a reasonable
   approximation of history.  Rather than nitpick the wording of this,
   it's most helpful to say something like "Regardless, I think there's
   new information here and I'd like to see if the consensus has
   changed."  A chair may or may not agree and call for consensus again.

Dusseault                 Expires June 6, 2008                 [Page 18]

Internet-Draft                  Consensus                  December 2007

6.2.  Sample challenge to a mailing list consensus call

    From: Jay
    To: Example Working Group
    Subject: Pushing back on Modified Property Consensus Call

    I'd like to push back on this consensus call. I read through the
    threads and didn't see rousing support for this proposal and I
    am currently -1 on it. Some of the problems were never brought
    to the surface during the discussion, the largest being that
    this adds a mandatory (MUST) level element to an entry, which
    the base spec never required.

    From: Michael
    To: Jay, Example Working Group
    Subject: Re: Pushing back on Modified Property Consensus Call

    Hmm, upon further review, while this proposal did have some friendly
    comment, "lots of support" might have been overstating it.   I seem
    to have counted at least one person twice.  And Jay's point below
    about the collision with the base spec seems pretty telling.  Would
    anyone like to jump up and shout in favor of saving it?

6.3.  Overturning Consensus Call Outcomes

   Consensus calls need not be final.  However, there can be some harm
   in overturning a consensus call.

   o  A new consensus necessarily takes more time.

   o  New discussions can be frustrating to those who participated in
      prior consensus calls, particular if long discussions were
      involved then.

   o  A change can be destabilizing to the documents and editing process

   o  The later consensus call can represent quite a different group of
      people, perhaps because new people are alerted to the issue, but
      perhaps because long-standing participants have given up or run
      out of time to dedicate.

   However, the harm may at times be more than balanced by the good that
   comes of making a decision that participants have more confidence in.
   Chairs need to be very explicit about voiding the consensus so that
   people know to speak up again.

Dusseault                 Expires June 6, 2008                 [Page 19]

Internet-Draft                  Consensus                  December 2007

   One of the most difficult situations to handle is when a WG has
   consensus, but the WG document proves not to have IETF consensus or
   IESG approval.  Both "community consensus" (which can include anybody
   since IETF and WG membership are not limited) and IESG approval are
   required by [RFC2026], whereas WG consensus is not mentioned (see
   also [RFC4677]).  The first step is to allow the WG an opportunity to
   evaluate the new input.  If the consensus on the WG mailing list
   remains the same, it becomes difficult to weight the IETF Last Call
   input to decide whether it falls in the "rough" part of rough
   consensus.  We can rule out weighting the new input at zero as well
   as weighting the original WG consensus at zero, but somewhere in
   between those two extremes is a difficult judgement call and a large
   region where more consensus-developing effort is required.  It can
   certainly take time to get the differing parties talking, but a
   standoff can take even more time and a standoff doesn't progress
   towards a good, well-approved technical standard.

7.  Recommendations for Individual Participants

   Participants are naturally important in determining rough consensus
   when they voice opinions.  Participants can be even more valuable
   helping chairs gauge and reach consensus by listening, explaining,
   mediating, proposing clear actions, helping others participate and so
   on.  This section provides some specific tips or ideas to consider.
   See also [RFC3184] for the IETF Guidelines for Conduct.

7.1.  What if you don't agree?

   It can be difficult to find oneself in the "rough" part of rough
   consensus.  Strongly held personal convictions must sometimes make
   way for the consensus of the group.  These are some approaches to be
   considered once a participant has already attempted to voice their
   opinion and explain the technical basis for it, and still finds
   themselves dissatisfied enough to take further action.

   Can convictions be assuaged by stating or restating them?

      "I'd like to state for the record that I still believe this
      feature is unnecessary, but I won't argue any further."

   Is it possible to seek elaboration either to become convinced or show
   those in the consensus so far that they don't necessarily agree?

      "I don't understand if this decision is being made based on a
      belief that language negotiation is too difficult, or based on not
      seeing the need for negotiation.  Although Linda already declared
      the consensus call, it would help me understand whether it's

Dusseault                 Expires June 6, 2008                 [Page 20]

Internet-Draft                  Consensus                  December 2007

      worthwhile trying to convince people that it's easier than it
      looks, or if that's a wasted effort".

   Finally, it's each participant's job to build consensus rather than
   to demand it.  It can really help to talk to other individuals
   privately and find out why they agree or disagree with you.

7.2.  Avoiding blocked consensus

   It helps not to state positions so strongly that one feels one's
   reputation is staked on a particular outcome!

      BAD: "It's not acceptable to change this header in a way that's
      not backwards-compatible."

      ALSO BAD: "I won't allow..." or "we can't" (when there's no strict
      technical infeasibility.)

      BETTER: "I strongly feel that we should not change this header
      unless we can do so in a way that is backwards-compatible."

      EVEN BETTER: "Is there some way we can do this without breaking
      backward compatibility?"

      ALSO GOOD: "Why do people feel strongly enough about this to break
      backwards compatibility?  I don't think I understand that

   Making an issue personal can bake people into firm oppositional
   positions.  Avoid the temptation to make personal accusations or to
   oppose a person per se.  Oppose the proposal, not the proposer.  One
   specific tactic to reduce knee-jerk opposition is to ask somebody to
   explain the other position to show they understand it.

7.3.  Questioning the process

   First, remember that it looks bad for your technical position to
   challenge the outcome on a process basis!  Often challenging the
   process can be avoided by suggesting a process rather than
   criticizing what happened.  Example:

      "Can we take a hum on that issue?  I'm not sure everybody is
      really going along with Vlad's proposal."

   Often, a participant who disagrees with the way a decision was made
   also disagrees with the decision itself.  It helps to address these
   separately.  The best way to dispute the decision being made is to
   offer a technical or other reasonable opinion, perhaps with explicit

Dusseault                 Expires June 6, 2008                 [Page 21]

Internet-Draft                  Consensus                  December 2007

   notes about tradeoff preferences, and ideally with new information.
   In contrast, the best way to dispute the way the decision was reached
   is to question the process and appeal to principles of fairness and

   When the situation merits criticizing the process, the critic needs
   to be clear about what went wrong or what needs to be remedied.
   Cries of "unfair" are not usually helpful without more detail.
   Again, to avoid making the issue personal, one can typically simply
   ask the chair to remedy the situation (and explain why) rather than
   accuse them of errors.  Example:

      "I'd like to ask the chair to take that consensus call to the
      list, from scratch.  I think this proposal is too complicated for
      us to really be able to hum for consensus right now."

7.4.  Final tips

   It helps to state why one is rejecting a proposal when the consensus
   call is yay/nay on a single proposal.

      "I'm -1 on this proposal.  We'll have to deal with difficult i18n
      concerns if we head down this path."

   When accepting a proposal it's fine to be very brief.


   It helps to state on what basis one chooses between two proposals.

      "I prefer the stateless approach over the token approach.
      Generally I like pushing the work to servers, but in this case
      keeping state can degrade performance noticeably."

8.  Acknowledgements

   Thanks to Harald Alvestrand, Mary Barnes, Steve Bellovin, Tim Bray,
   Joe Gregorio, Tony Hansen, and Cullen Jennings.  Some provided
   comments directly, and others provided examples of good consensus
   practices or expressed its principles nicely on discussion lists.

9.  IANA Considerations

   There are no IANA considerations introduced in this document.

Dusseault                 Expires June 6, 2008                 [Page 22]

Internet-Draft                  Consensus                  December 2007

10.  Security Considerations

   There are no security considerations arising from the information in
   this document.

11.  Informative References

   [AA]       Alonzo, M. and M. Aiken, "Flaming in electronic
              communication", Decision Support Systems, Vol. 36, No. 3.,
              pp. 205-213. , January 2004.

   [BUJ]      Center for Conflict Resolution, "Building United Judgement
              -- A Handbook for Consensus Decision Making", 1981.

   [Hol]      Hollingshead, A., "The Rank-Order Effect in Group Decision
              Making", Organizational Behavior and Human Decision
              Processes, Vol. 68, No. 3., pp. 181-193. , December 1996.

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

   [RFC3184]  Harris, S., "IETF Guidelines for Conduct", BCP 54,
              RFC 3184, October 2001.

   [RFC3929]  Hardie, T., "Alternative Decision Making Processes for
              Consensus-Blocked Decisions in the IETF", RFC 3929,
              October 2004.

   [RFC4677]  Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
              Guide to the Internet Engineering Task Force", RFC 4677,
              September 2006.

Author's Address

   Lisa Dusseault
   169 University Ave.
   Palo Alto, CA  94301

   Phone: 1-650-279-7365
   Email: ldusseault@commerce.net

Dusseault                 Expires June 6, 2008                 [Page 23]

Internet-Draft                  Consensus                  December 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Dusseault                 Expires June 6, 2008                 [Page 24]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/