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@xxxxxxxx mailing lists by 2013-11-04. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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. > > > >