[Hyperledger Project TSC] Rough Consensus in IETF

Ram Jagadeesan (rjagadee)



Some info on rough consensus in IETF working groups.

How are your humming skills?







“Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The exact method of determining rough consensus varies from Working Group to Working Group. Sometimes consensus is determined by "humming" — if you agree with a proposal, you hum when prompted by the chair. Most "hum" questions come in two parts: you hum to the first part if you agree with the proposal, or you hum to the second part if you disagree with the proposal. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus.

The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that invites all interested individuals to participate, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.

A related problem is that some people think that their proposals should be discussed in the WG even when the WG Chairs do not. For example, if the proposed work is not really part of the charter, the WG Chairs may constrain the discussion of the proposal in order to keep the WG focused on the chartered work. Individuals who think that a WG should bring up a topic that is considered off-charter by the WG Chairs can bring their concerns to the responsible AD; the AD may agree to add the topic to the charter, or that it is already covered in the charter, or that the WG Chairs are correct and that the participant should work on the proposal outside the WG.

When a WG document has been fully discussed, it usually goes through Working Group Last Call (often abbreviated as "WGLC"). This is a hopefully-final time fo the WG to iron out issues. Sometimes, WGLC will bring out so many issues that there will be a second WGLC after the revisions have been incorporated. There are no formal rules for how a WGLC happens, or even if a WGLC is needed: it is up to the WG chairs.”

More detailed discussion: “On Consensus and Humming in the IETF”


Having full consensus, or unanimity, would be ideal, but we don't

   require it: Requiring full consensus allows a single intransigent

   person who simply keeps saying "No!" to stop the process cold.  We

   only require rough consensus: If the chair of a working group

   determines that a technical issue brought forward by an objector has

   been truly considered by the working group, and the working group has

   made an informed decision that the objection has been answered or is

   not enough of a technical problem to prevent moving forward, the

   chair can declare that there is rough consensus to go forward, the

   objection notwithstanding.”


Join toc@lists.hyperledger.org to automatically receive all group messages.