Respecting the IETF rough consensus process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Folks,

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 process.

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.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]