Re: Last Call: <draft-resnick-on-consensus-05.txt> (On Consensus and Humming in the IETF) to Informational RFC

[Ted Hardie <[e-mail]>]

First, I am always happy when folks take the time to think deeply about the
IETF's processes and share those thoughts with the community.  I think the
conversation this has already started has been useful, and I hope that the
last call conversation is the same.

That said, I do not think this document is ready for publication as an RFC,
and I personally suspect that it wouldn't be the best fate for it even it
were.  On the second point, the truth is that informational RFCs are
treated as actual requests for comments much any more, but are taken as
fixed; if the points this raises are to be maintained as items of
conversation (which is my personal preference), then incorporating pieces
of it into the Tao, Edu Team documents, or WG training may be appropriate
instead.  That is, put this into some form where folks will not take it as
an item of dogma, but as the start of a conversation, and the community
will be better served.  Even as an Informational document, if it is
published as an RFC by a sitting AD via the IETF stream, it may not get
that treatment.

If the IESG does believe that this should be published as an RFC, I think
it continues to need serious work before publication.  At the very base, I
think it needs a much stronger sense of its audience (advice to WG chairs
and those that deal with them? new participants in the IETF? those who want
to understand the workings of the IETF from the outside?) and a structure
which relates to that audience.  I note, for example, that the document
references none of the IETF's process documents or discussions that arose
out previous work in this area; that's fine for some audiences but is going
to be missed by folks who might get handed this as an explanatory document
on how things work (or ought to) in the IETF.

Once it has that audience, some of the issues with the current document may
fall out, but among those with which I have personal disagreements:

The document consistently describes a test for objection model of document
processing; that's a fair summary of how the IETF works, but shoe-horning
the description into "rough consensus" because we like the slogan is not
really helping folks understand the IETF.  The core of the IETF is a
participatory process which is meant to be cooperative rather than
adversarial; to that extent it is fair to describe it in consensus terms.
Beyond that, however, we are really not seeking the consent of all parties,
even as an ideal.  We are trying to make sure that there are no known
technical issues with a proposal and that there is sufficient support to
believe that it will be implemented and deployed to the good of the
network.  Encouraging folks to believe that the ideal is full consensus is
highly problematic, for exactly the reasons that Pete later raises with
regards to voting:  it is very difficult to determine when you have the
consent of all parties if you cannot limit the parties in some way.  We
cannot name our members, so we cannot either count votes *or count all of
them as consenting*.

The document has vastly improved its description of compromise over its
previous iterations, for which Pete should be commended.  But it remains
problematic in its description of participation. In the section "Five
people for
and one hundred people against might still be rough consensus", the
document describes what can occur when one proposal is favoured over
another by a working group's active participants:  one set of participants
may recruit new voices to add to their preferences.  The difficulty with the
given description is that it is a strawman compared to that actual
complexity
of dealing with this situation, because it posits sales and marketing folks
being the new voices.  The far more difficult reality is that the voices
often
come from members of an impacted technical community who generally do
not attend or participate in the IETF.  Were they known participants in the
IETF process, it is clear that their message "I agree with X's points" would
be heard in one way, where them being new participants causes them, in
this approach, to be discounted entirely if they raise no new points.
Novelty
is the wrong test here, as is length of participation; the test that WG
chairs
must use is the much messier judgement call of what the impact of the
objections is on the likely implementation and deployment of the system
under
discussion.

Lastly, I think Pete has failed to capture that one reason for using
humming or hands is that it is easy for very active participants to
dominate a conversation
but much less easy for them to pretend to be a large group.  Particularly
in BoFs, using those methods to indicate the likely breadth of interest is
critical.  The same method can be used, with some of the caution Pete
recommends, to gauge whether an issue which appears to be contentious based
on a mic line is actually a problem.  It can also, in some cases, be a
valuable method of reinforcing the resolve a room that has already likely
come to a broad agreement.  That does not contravene Pete's point that this
should not be used to silence objections, but there are cases where it is
important in its own right.

Again, I believe this is a valuable conversation and one that ought to keep
going; my recommendation against publication should also be taken as a
recommendation both to Pete to keep working on these ideas and to the
General Area Director to support a forum for that discussion.

regards,

Ted Hardie



On Mon, Oct 7, 2013 at 9:48 AM, The IESG <[e-mail]> wrote:

>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'On Consensus and Humming in the IETF'
>   <draft-resnick-on-consensus-05.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2013-11-04. Exceptionally, comments may be
> sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    The IETF has had a long tradition of doing its technical work through
>    a consensus process, taking into account the different views among
>    IETF participants and coming to (at least rough) consensus on
>    technical matters.  In particular, the IETF is supposed not to be run
>    by a "majority rule" philosophy.  This is why we engage in rituals
>    like "humming" instead of voting.  However, more and more of our
>    actions are now indistinguishable from voting, and quite often we are
>    letting the majority win the day, without consideration of minority
>    concerns.  This document is a collection of thoughts on what rough
>    consensus is, how we have gotten away from it, and the things we can
>    do in order to really achieve rough consensus.
>
>       Note (to be removed before publication): This document is quite
>       consciously being put forward as Informational.  It does not
>       propose to change any IETF processes and is therefore not a BCP.
>       It is simply a collection of principles, hopefully around which
>       the IETF can come to (at least rough) consensus.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-resnick-on-consensus/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-resnick-on-consensus/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>