Consensus in Internet Standards
Friday, 24 May 2024
This post is part of a series, The Nature of Internet Standards.
It’s common for voluntary technical standards developing organisations (SDOs such as the IETF and W3C) to make decisions by consensus, rather than (for example) voting. This post explores why we use consensus, what it is, how it works in Internet standards and when its use can become problematic.
Why consensus?
SDOs have several motivations for using consensus. Most often, consensus decisions are seen as a way to avoid the potential for gaming and politics that comes with voting systems. If everyone can live with the result, it’s more likely that the result reflects a diversity of viewpoints.
The IETF also has a pragmatic reason: since there is no formal membership in the IETF, there’s no way to determine who’s eligible to vote.
However, there’s also a less obvious policy motivation to use this approach. Several legal frameworks encourage or even require standards decisions to be made by consensus.
For example, OMB Circular 119-A encourages the US government to prefer consensus standards for the products they buy. US anti-trust laws regarding standards bodies also reference this document.
Annex II of EU Regulation 1025/2012 provides similar guidelines for standards adopted by the EU.
Even the WTO gets in on the act; their recommendations regarding technical barriers to trade state that ‘consensus procedures should be established that seek to take into account the views of all parties concerned and to reconcile any conflicting arguments.’
These legal encouragements strongly motivate SDOs to adopt consensus as the basis of their decision-making, and are reflected in the OpenStand principles adopted by the IETF, W3C, and IEEE.
What is consensus?
The OED definition of consensus is:
Agreement in opinion, feeling, or purpose among a group of people, esp. in the context of decision-making. Also: the collective unanimous opinion of…
Note that unanimity is one option, but not required. This mirrors OMB Circular 119-A’s explanation of consensus as:
[…] general agreement, but not necessarily unanimity. During the development of consensus, comments and objections are considered using fair, impartial, open, and transparent processes.
Likewise, in EU Regulation 1025/2012:
Consensus means a general agreement, characterised by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus does not imply unanimity.
These definitions share a characterisation of the nature of a consensus agreement and they also hint that the process used to achieve that consensus must have certain properties. However, they do not mandate a particular process.
In the IETF, RFC 2418: Working Group Guidelines and Procedures Section 3.3 says:
IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that “dominance” is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as “rough consensus” and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached.
Note especially the concept of ‘rough consensus’ here, which is judged by the chair and can be appealed to higher authorities.
Meanwhile, the W3C Process defines consensus as:
A substantial number of individuals in the set support the decision and there is no sustained objection from anybody in the set. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set.
In this more strict and mechanical definition, the emphasis is on the absence of any ‘sustained’ objection. In theory, one person can hold up the declaration of consensus; when this happens, W3C calls this ‘dissent’:
In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The Chair may record a decision where there is dissent so that the group can make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.
Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.
If a dissenter is dissatisfied with a decision, they can register their unhappiness as a Formal Objection, which invokes a new and somewhat onerous appeal process, in the formation of a Council.
How does consensus work?
Consensus is not easy or expedient: it requires everyone to listen, understand others’ positions, and be flexible in adapting to the needs of others. While some issues can be decided easily if there is significant common ground between participants, this is often not the case, and working through such differences can require significant time – both in discussion as well as away from others reflecting on what path forward might be viable.
Successful consensus requires a ‘good faith commitment to honest debate’: someone participating in bad faith (e.g., behaving inauthentically, strategically, or otherwise) can be catastrophically disruptive to this process. As a result, seasoned standards participants tend to be very sensitive to bad-faith arguments, and known to disregard or even shun those who appear to use them.
Used with nuance, consensus can be a powerful decision-making tool. People with positions that are fundamentally at odds with each other can iterate over their understanding of the problem and find shared ground and become bought into a shared solution. A consensus result is often one that no one is completely happy with, and some might be quite unhappy with it, but critically, they don’t contest the legitimacy of the outcome – often, it’s just enough that they have a chance to be heard and understood.
For example, during the standardisation of QUIC there was strong disagreement between some network operators and other parties (including both implementers and privacy advocates) about making information available to networks. Through extensive discourse and an iterative set of proposals, we were able to agree on including the ‘spin bit’ as an optional-to-implement feature. Neither side was enthusiastic about this outcome, but we were able to produce a standard that was satisfactory to all.
Good consensus can also show the humility and maturity of the group. When we were standardising HTTP/2, there were a few issues we went back and forth on extensively, before realising we didn’t have enough context to make an informed decision – even though a decision still need to be made to ship the protocol. In those cases, we decided that progress was more important than any faction ‘winning’, and so we came to a consensus to abide by the result of a coin flip.
Where can consensus go wrong?
When and how to determine consensus is very cultural: what people believe consensus is (and is not) has a significant effect on the outcome of a decision. Perhaps because of this, a few different failure modes for consensus in Internet standards setting are more common than they should be.
One kind of failure happens when the bar for consensus is set too high – effectively requiring unanimity instead of consensus. If everyone has to agree, one intransigent (or just disagreeable) person can withhold permission to progress.
The IETF explicitly addresses this kind of failure with the culture of ‘rough consensus’, which explicitly acknowledges that consensus need not be unanimous; the important factor is that the reason for disagreement is understood.
In contrast, the W3C’s characterisation of any dissent as a lack of consensus can be problematic if misapplied, because it risks creating a culture of avoiding dissent. While the Process document clearly indicates that dissent is manageable, the cultural expectations (as well as the potential for extra overhead if dissent turns into a Formal Objection) can cause a group to get ‘stuck’ on a decision.
Another common failure mode is encountered when a decision-maker falls into the trap of treating consensus-gathering like voting. While polls that gauge support or dissent for a proposal are a useful tool, they can’t be taken as indicators of consensus, and can’t alone decide the issue.
Pete Resnick’s excellent RFC 7282: On Consensus and Humming in the IETF is a fantastic exploration of the subtleties here, and well worth a read. For example:
Any finding of rough consensus needs, at some level, to provide a reasoned explanation to the person(s) raising the issue of why their concern is not going to be accommodated. A good outcome is for the objector to understand the decision taken and accept the outcome, even though their particular issue is not being accommodated in the final product.
Lack of engagement can easily be mistaken for consensus. As a chair, it’s sometimes difficult to know if everyone agrees but just can’t be bothered to speak up, or if no one is paying attention. Having proper notification, communication, and multiple process steps that check for engagement can mitigate this risk.
Inappropriate use of consensus on trivial matters ignores the considerable overhead of the consensus-gathering process. For example, decisions about purely editorial matters like document organisation, terminology, and presentation shouldn’t be determined by consensus, because good-faith participants will quickly become exhausted and lose interest.
That doesn’t mean that these decision-makers shouldn’t consult and respond to suggestions about these matters; only that the consensus process isn’t appropriate for them, and another decision-making structure (often, delegated authority) is more appropriate.
A final failing is often referred to as consensus by exhaustion. Too strong a drive for “perfect” consensus creates a culture where those who are willing to “stick it out” get to decide by default, because everyone else tires of waiting for a decision to be made. When this happens, the resulting decisions tend to favour those who are most invested in the work instead of the broader community.
Those are the failings of consensus that I’ve seen most often. If you can think of more or have other thoughts, I’d love to hear them.