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