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
ietf(_at_)ietf(_dot_)org mailing lists by 2013-11-04. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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.