Notes on IETF Rough Consensus

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

Abstract

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.

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

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.

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] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.). 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".

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

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.

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:

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

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.

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

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.

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

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

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

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.

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:

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

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

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:

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:

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

3.2. Fine-tuning consensus calls

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.

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
   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] (Hoffman, P. and S. Harris, “The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force,” September 2006.) says that "Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list", [RFC2418] (Bradner, S., “IETF Working Group Guidelines and Procedures,” September 1998.) 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 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 assignment).

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.

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

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.

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.

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

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.

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.

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] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.), whereas WG consensus is not mentioned (see also [RFC4677] (Hoffman, P. and S. Harris, “The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force,” September 2006.)). 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] (Harris, S., “IETF Guidelines for Conduct,” October 2001.) 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.

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

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!

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:

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

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:

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.

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

10. Security Considerations

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

11. Informative References

Author's Address

Full Copyright Statement

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 “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

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 http://www.ietf.org/ipr.

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 ietf-ipr@ietf.org.

[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 (TXT).
[RFC2418]	Bradner, S., “IETF Working Group Guidelines and Procedures,” BCP 25, RFC 2418, September 1998 (TXT, HTML, XML).
[RFC3184]	Harris, S., “IETF Guidelines for Conduct,” BCP 54, RFC 3184, October 2001 (TXT).
[RFC3929]	Hardie, T., “Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF,” RFC 3929, October 2004 (TXT).
[RFC4677]	Hoffman, P. and S. Harris, “The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force,” RFC 4677, September 2006 (TXT).

	Lisa Dusseault
	CommerceNet
	169 University Ave.
	Palo Alto, CA 94301
	US
Phone:	1-650-279-7365
Email:	ldusseault@commerce.net

Notes on IETF Rough Consensusdraft-dusseault-consensus-00

Status of this Memo