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

[Pete Resnick <presnick@xxxxxxxxxxxxxxxx>]

Finally getting back to this. Overall, I hope that the new version which I'm about to submit (Jari has given clearance to post during the blackout given that this is not being discussed in Vancouver) addresses these (and others') comments. Some specifics:

On 10/8/13 3:03 AM, Ted Hardie wrote:

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.

I appreciate that.

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.

I will leave it to Jari and the other members of the IESG to make the call on this. However, I do think some of these points have solidified to the point that having a stable reference is good. I wouldn't object in principle to it being published in the the form of a web page a la the Tao, or some Edu Team documents, but I think having an Informational RFC does give it some wider viewing. I've already heard from people who, due to the Last Call, are looking at this document in other organizations and find the discussion useful and interesting. I also don't harbor the fears that Ted does about it being treated as dogma. It is true that people latch on to all sorts of things as dogma, but they already have plenty of them that disagree with the notions in this document, so the counterbalance doesn't seem so bad. But again, I only have a personal leaning at this point toward publication, and I'm inclined to leave it to Jari to make the call.

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 hope I have this clarified. Here's the paragraph I've now got in the intro:

This document attempts to explain some features of rough consensus, explain what is not rough consensus, discuss some new ways to think about rough consensus, and suggest ways that we might achieve rough consensus and judge it in the IETF. Though this document describes some behaviors of working groups and chairs, it does so in broad brushstrokes and it does not specific procedures. Rather, this document is intended to foster understanding of the underlying principles of IETF consensus processes. While it may be of general interest to anyone interested in the IETF consensus processes, the primary audience for this document is expected to be those who have experience working in the IETF, and it is particularly aimed at generating thought and discussion among those who might lead a consensus discussion. Although most of the examples in this document talk about working group chairs, these principles are meant to apply to any person who is trying to lead a group to rough consensus, whether a chair, a design team leader, a document editor, an IESG area director, or any community member who is facilitating a discussion.

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.

Some of this is addressed by the things I have done to address Dave's concerns: I've tried to make it clear what is a new view of consensus versus what we've actually been doing. However, in one sense I actually believe the opposite of what Ted says here: To claim that the what we are "really" doing at core is simply to make sure that there are no known technical issues and that there is "sufficient" support is to reject that idea that consensus (rough or otherwise) is important at all. All you need to determine that things are for the "good of the network" is to have a (perhaps benevolent) president or king. We reject that. We believe that coming to a meeting of the minds (of whoever is participating at the moment) over the technical issues is actually important.

Now, at the end of the day, I don't think Ted and I are really that far apart. In the end, we expect everyone to be working toward no known technical issues and the good of the network, so putting all of those heads to get a consensus is pretty likely to get the right technical outcome. But I think more often than not it *is* the objections that cause a group to rethink the consensus technical decision it may have arrived at (in good faith), and it is the re-forming of consensus around the objection, or the acceptance of the objection and placing it "in the rough" that really should be how we view our process.

Either way, I've tried to adjust the language a bit along these lines. I don't know that we're going to completely agree, but see if the changes make things any better in your view.

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*.

This I disagree with. Or we might be in violent agreement: The ideal is to come up with a solution that *everyone who might come along* agrees is the right technical solution. You don't need to count heads (or know which heads you're counting) to do that. Of course this is a theoretical ideal: You can't know that you've ever satisfied everyone who might come along. But that's OK. The only thing we can do is say, "We've addressed all known technical problems and made all known correct engineering tradeoffs. If others come along, we'll deal with them." That's the only criteria we can really use. I don't see how the theoretical ideal of everyone agreeing is a problematic concept.

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.

Yup. I've added a paragraph to talk about just that.

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.

I've added a bit about this. But I am also somewhat wary of going too far with it. As I say in the document, hums (or shows of hands) have the potential to sway a working group due to herd mentality: Someone may be dissuaded from raising what could be an essential concern if they somehow feel that the group is overwhelmingly for a particular position, or some folks may decide to "hum along with the crowd" even though they're not committed to the outcome. I've mentioned the positive and the negative of this case.

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.

Thanks for that, and all of the comments.

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478