Respecting the IETF rough consensus process

Dave Crocker <> Wed, 06 November 2013 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF3021E8124 for <>; Wed, 6 Nov 2013 07:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SV78V6e3zl5x for <>; Wed, 6 Nov 2013 07:24:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D50B11E8141 for <>; Wed, 6 Nov 2013 07:24:02 -0800 (PST)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id rA6FNv2p014942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Wed, 6 Nov 2013 07:24:01 -0800
Message-ID: <>
Date: Wed, 06 Nov 2013 07:23:36 -0800
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: IETF Discussion <>
Subject: Respecting the IETF rough consensus process
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 06 Nov 2013 07:24:01 -0800 (PST)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2013 15:24:07 -0000


During the discussion about development of an anti-harassment policy, a 
number of senior folk -- including some principal actors -- have 
privately reported to me their own belief -- or the belief of other 
principals -- that the IESG has needed to impose the decision to adopt 
the policy, without going through an explicit IETF rough consensus 

Their premise is that the community would never converge on a consensus 
position.  That view is widely held in the community and has been 
frequently expressed over the years.  And they claim its truth has often 
been demonstrated, with respect to changes in IETF process or structure.

I believe their conclusion is fundamentally wrong.  The base of 
experience they cite has been marked by a distinct lack of management in 
the consensus process, instead leaving convergence to chance.

In the face of an undisciplined environment, yes it is nearly always 
certain that the IETF discussion will fail to converge.  Too many of us 
are distracted by bright shiny side-points and too many of use choose 
competing goals.  And that won't change.

Besides general mayhem in the style of discussion that happens on the 
IETF list when there is no structured facilitation, we tend to confuse 
"some people still object" with "we have no rough consensus".  (See Pete 
Resnick's emerging paper on consensus.)  That is, the assessment filter 
of the folks deciding whether we've got consensus is broken.

Lastly there is the problem that a rough consensus process for any 
interesting topic is always messy, and many folk don't want the hassle. 
  Unfortunately, the making of an IETF consensus sausage does not 
tolerate process vegetarians.  If we are going to say we still believe 
in rough consensus, we need to exercise its process engine, whether we 
like it or not.  It takes time.  It takes very careful effort.  It's 
frustrating.  But it /can/ work.

The solution is quite simple and effective:

      When there is a proposal in front of the IETF community, assign a 
facilitator whose job it is to actively assist the discussion in seeking 
consensus.  The techniques for this are well-established and working 
groups often use it (but not nearly enough, in my view.)

      At a minimum, the facilitator will record and track issues, 
summarize discussion segments, and prompt the community to focus on 
specific issues, to get them resolved.

      As a discussion convenience, the facilitator can also attempt to 
judge rough consensus on the issues, although they do not need to be 
given formal authority to assert its presence.

For the anti-harassment policy, we happen to have pretty obvious and 
massively strong community support for developing the policy.  That we 
also have plenty of evidence that some folk will never be satisfied with 
whatever text emerges is a distraction.  Once those folk have had their 
say and the group has discussed their concnerns constructively and hass 
attempted to resolve the concerns, we are not obligated to please such folk.

If we really do respect our core precept of rough consensus, we are 
obligated to apply it to our own structure and process change efforts.

The IETF community really is the higher authority for the IETF.

Dave Crocker
Brandenburg InternetWorking