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

[Pete Resnick <[e-mail]>]

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. - [phone]