Summary

  • RFC 2418 made rough consensus the working-group rule and said a 51% majority was not enough; the chair had to assess the discussion.
  • The same 1998 guidance allowed humming, a show of hands, or another agreed signal, but it treated the signal as one input to judgment.
  • RFC 7282, published as an Informational RFC in 2014, warned that a hum was becoming an anonymous vote and said it should start a conversation, not end one.
  • The document asked chairs and participants to identify technical objections, examine whether they had been answered, and explain why an unresolved objection would not change the result.
  • RFC 7282 described existing principles; it expressly did not change IETF procedures or establish a new binding process.

A room could show direction without deciding the question

A working group needed ways to understand whether a proposal had support. In a meeting, a chair might ask the room to hum for or against an option rather than raise hands. That made a general sense of the room audible without turning the exercise into a count of ballots. It could help locate a disagreement, or show that one proposal had drawn more interest. It could not reveal why participants held those views or whether a technical objection remained unanswered.

The distinction had been present in IETF guidance before 2014. RFC 2418, the 1998 working-group guidelines, called rough consensus the core way a group accepted a technical choice. It explicitly said that 51 percent did not qualify. The chair was responsible for deciding whether the group had reached rough consensus, and the RFC warned that message volume alone was a poor measure: a few people could generate much of the traffic. It also observed that mailing lists could reach more interested people than meeting attendance, which imposed travel and time costs.

The 2014 document RFC 7282 revisited the gap between that principle and how people used the ritual. Its author, Pete Resnick, described participants treating a hum as a secret ballot or as a shortcut to closure. The document’s central correction was practical: a hum should begin a discussion about what the group must resolve. The loudest side does not become the decision merely because it was louder.

The work was in the objections

RFC 7282 shifted attention from counting agreement to finding the unresolved issue. A chair might ask what prevents someone from living with a proposal, then identify whether the concern is a genuine engineering problem, a preference, or a trade-off the group has already considered. That does not require every objection to be accommodated. It does require the group to understand the objection and give a reasoned account of its choice.

The chair’s role is therefore neither a mechanical tally nor an unlimited personal veto. The chair must know the group’s technical goals well enough to evaluate the issue, summarize the rationale, and allow an appeal if the decision missed a technical requirement. A large majority saying an objection is wrong cannot substitute for addressing it. Conversely, one participant cannot halt work indefinitely by repeating a concern that the group has examined and answered.

The older RFC 1603 and RFC 2418 had described several possible ways to sense a group, including balloting and humming. RFC 7282 challenged the idea that any such signal could decide the substance by itself. A show of hands, a poll, or a hum can help expose the shape of discussion. The decision still depends on reasons, the working group’s requirements, and the chair’s judgment.

Why the 2014 document stopped short of a new rule

RFC 7282 was deliberately published as Informational. It said it was not a standards-track specification, did not propose process changes, and was not a Best Current Practice. That status matters: the text tried to clarify how participants should understand an existing IETF tradition; it did not amend the rules or establish a new authority over working groups.

The surrounding process also mattered. RFC 2418 required face-to-face decisions on topics not previously discussed—or decisions materially different from the mailing-list discussion—to be reviewed on the list. RFC 7282 said final decisions were supposed to be taken there. This made the room one place to test a view, while the asynchronous record gave absent participants a chance to see the reasoning and object.

The limits are just as important as the procedure. These RFCs document guidance for IETF working groups. They do not measure who participated, establish that every affected network operator was represented, or show whether any resulting protocol was adopted. A process that hears objections can improve a technical decision; it cannot claim authorization from people who were never part of that process. That distinction keeps a room’s signal within the task it was designed to serve.