12 Rough consensus, and why the room hums

12.1 Why the question of voting comes up at all

Every body that decides things has to answer one question: when the room disagrees, what settles it?

3GPP's answer is institutional. A working group agrees, a plenary approves, and each document leaves with a recorded verdict §4.6.4, §9.2. Who may carry that decision, and with what weight, is written down one level above the working methods, in the 3GPP Working Procedures ^[5] — a document this course cannot read for you.

The IETF's answer is a refusal, and it is the most quoted sentence the organisation has ever produced.

12.2 What it actually is

The word "rough" is doing precise work, and RFC 7282 spends a whole document on it. The core is one long sentence.

Unpack it and there are four conditions, all of which have to hold before the chair may declare anything:

• the objection is a technical issue, not a preference;

• it has been truly considered by the group, rather than heard and ignored;

• the group has made an informed decision about it;

• that decision is either that the objection has been answered, or that it is not enough of a technical problem to stop the work.

Only then may the chair go forward over the objection. Nothing in that test asks how many people hold the objection.

12.3 What it is not

The companion document is blunter, and it is the sentence to quote at anybody who tries to run an IETF working group like a committee.

Read those three clauses in order. A bare majority is explicitly not enough. Near-unanimity is more than the bar requires. And the decision about where between those two the room actually sits belongs to one person.

Working groups decide this way as a matter of rule, not as a habit.

12.4 Why the room hums

If the chair's job is to judge the sense of the room, the chair has to sample it somehow. Asking for hands produces a number, and a number looks like a vote.

Humming exists to avoid exactly that. It lets a chair take the sense of a room without a show of hands, which would look too much like the thing the organisation refuses to do RFC 7282.

A hum has two properties a show of hands does not. It has volume as well as count, so a room can express strength of feeling rather than a tally. And it is anonymous in practice, so nobody is registering their employer's position on the record.

12.5 What rests on one person

Both documents put the decision in the chair's hands, in as many words. RFC 2418 says it is up to the chair to determine whether rough consensus has been reached ^[3], and RFC 7282 hangs the whole judgement on what the chair determines about an objection ^[2]. That is a great deal of discretion, and it is deliberate: the alternative is a countable threshold, which is a vote by another name.

The protections around it are procedural rather than numerical. The whole process is open, so anybody may take part in the discussion the chair is judging ^[6]. And the working group's recommendation is not the end of the road: it goes to an area director, and then to an IETF-wide Last Call in which anybody at all may object before publication RFC 2026. A chair's misjudgement inside one working group has one more gate to get through.

12.6 The same word in 3GPP

"Consensus" is not absent from 3GPP. It appears at a precise and revealing point: a plenary may approve a category B or C change to a frozen specification if it is the consensus of the meeting that such an exceptional action is justified §4.6.2.

So 3GPP reaches for consensus exactly where its written rule runs out — as the authority for an exception. In the IETF, consensus is the ordinary mechanism and there is no other.

The one place the two bodies clearly behave alike is between meetings, where both settle things by email. In 3GPP, silence during the allowed period grants agreement automatically §8.6. In the IETF, the Last Call is itself an email procedure, open to anyone RFC 2026. Both use the inbox; one asks you to notice, the other asks you to speak.

12.7 The other half of the sentence

The credo has two halves and the second is usually forgotten. "Running code" is not a slogan about enthusiasm; it is the other check on a chair's judgement.

It appears among the five principles the IETF names for itself, as one item: rough consensus and running code, taken together RFC 3935. And it has teeth at the top of the standards track, where an Internet Standard requires multiple independent interoperable implementations with substantial operational experience ^[7].

So an argument that cannot be settled in the room can be settled outside it. Two implementations that fail to interoperate are an objection nobody has to adjudicate. Nothing equivalent exists in the 3GPP procedure, where approval is a decision of a plenary and no clause asks whether anybody has built the thing §4.1.1.

12.8 What this course cannot show you

Everything above is the written rule. How it plays out in a real working group — who objects, how a chair handles somebody who will not be answered, what a contentious hum sounds like — is not in the archive on this machine, which holds RFCs and nothing else. There are no charters, no minutes and no mailing list archives here.

So this chapter quotes the procedure and stops there. For the current list of working groups and how to reach their discussions, the place to go is the IETF website ^[8].

12.9 Where this leads

MUST, SHOULD and MAY — three words, one short document is what the agreed text is then written in, and The two cultures, side by side and on the evidence compares this way of deciding with the plenary and the status value, fairly and on the evidence.