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.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.
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
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.
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
regards,
Ted Hardie
On Mon, Oct 7, 2013 at 9:48 AM, The IESG <iesg-secretary@xxxxxxxx> 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.