Notes on IETF Rough Consensus

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 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 . 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 . There are many difficult tradeoffs.

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

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.

Formal, classic consensus cultures 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 has extensive discussion and examples comparing majority rule to consensus.

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

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.

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 list. 2. A mailing list vote from a person who is not subscribed to the list. 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 editors. 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: "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. "

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. "There has been no additional discussion on this issue since draft -02 came out. This issue is now considered closed.

Once in a while the IETF also sees what may appear to be attempts to stack a vote. Some possibilities: bringing extra people to a meeting to hum on cue causing extra participants (perhaps even dummy accounts) to voice opinions in a Jabber room or mailing list humming into the microphone 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 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.

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. Note also that the IETF has rules about design teams .

We know from organizational psychology research that in-person decision-making has different characteristics than computer-mediated decision-making. Some examples: 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 memory. 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. Email tends to polarize and is prone to flames . Groups that solve problems in-person tend to share more hidden information than computer-mediated groups . 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: Can weigh opinions from informed partipants more heavily Might shame people who haven't read documents from expressing uninformed opinions in the first place Can gauge if there is enough expertise to even ask the consensus question and expect a good result 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 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.

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. e.g. "Will suggests we deprecate error code 410. Shall we do that then? [hears approval noises] Good" Alternatively: 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?"

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 proposal? [silence] Chair: Do we have a problem with the two alternatives? ... group explores more solutions

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. STRONG HUM Chair: Those who don't believe we're ready, hum. [silence] 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. STRONG 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, hum STRONG HUM Chair: Ok, so only on large messages. Those in favour of fragmentation allowed only on messages over 10,000...

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.

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.

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

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.

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 says that "Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list", 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.

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

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. Examples: "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." 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.

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. "Let the minutes note that the WG agreed to a plurality vote in order to make a decision on this issue"

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. 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 the favourite proposal for most. Will votes in the Jabber room be counted? Who will do the counting?

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.

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.

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.

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.

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?

Consensus calls need not be final. However, there can be some harm in overturning a consensus call. A new consensus necessarily takes more time. New discussions can be frustrating to those who participated in prior consensus calls, particular if long discussions were involved then. A change can be destabilizing to the documents and editing process 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. 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 , whereas WG consensus is not mentioned (see also ). 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.

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 for the IETF Guidelines for Conduct.

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

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

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

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. "+1". 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."

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.

There are no IANA considerations introduced in this document.

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