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

[Eliot Lear <[e-mail]>]

Pete,

As usual, I really like your writing style, and I think you're
addressing a very important issue.  There are two aspects that I would
suggest require further exploration, both having to do with the role of
the chair (the whole document has to do with the role of the chair, I
suppose):

1.  No matter how you slice the definition of rough consensus, if the
chair does not act in a fair and balanced way, the outcome will be
incorrect.  This is what the appeals process is for, and I would suggest
mentioning it, perhaps in some detail.

2.  The case of Section 7 is, as you say, a mind bender.  I would
suggest adding another use case: what if those 100 people write their
own draft.  Can they use the exact same process to get the draft adopted
and approved, so long as they answer the technical issues that arise? 
In other words, if there are multiple valid alternatives, and one suits
one vendor group and another suits another, can there be just one
standard?  At the neck of the hourglass, perhaps so?  What happens in
this case, from your point of view?  What makes group (a) more special
than group (b)?

Eliot


On 10/7/13 12:48 PM, The IESG 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.
>
>
>
>