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

[Pete Resnick <[e-mail]>]

Last of the messages in my list:

On 10/8/13 3:56 PM, S Moonesamy wrote:
> The intended status of draft-resnick-on-consensus-05 is 
> Informational.  What we have here is a document about consensus which 
> will reflect the consensus of the IETF.  Should the document reflect 
> the consensus of the IETF or not?

See other messages. I think the intention is to make it a consensus 
Informational document.

> ...Section 1...introduces the term "full consensus".  I took a quick 
> look and I found at least one occurrence of the term in IETF 
> discussions [3].  However, none of the IETF process documents use that 
> term.

See my reply to PSA. I don't think that there's a real need for a formal 
definition. I've thrown in the word "unanimity" to clarify.

>   "If the chair of a working group determines that a technical issue
>    brought forward by an objector has been truly considered by the
>    working group, and the working group has made an informed decision
>    that the objection has been answered or is not enough of a
>    technical problem to prevent moving forward, the chair can declare
>    that there is rough consensus to go forward, the objection
>    notwithstanding."
>
> The word "objector" emphasizes that there is one person who dissents.  
> My preference is to consider the objection and address it instead of 
> viewing the issue as dissent from one person.

That's what the example above says. It is the *objection* that is 
answered, not the objector. It is, after all, a hypothetical.

>    "This document attempts to explain some features of rough consensus,
>     explain what is not rough consensus, and suggest ways that we might
>     achieve rough consensus and judge it in the IETF."
>
> The title of the document is "on consensus and humming in the IETF".  
> According to the above sentence the document attempts to discuss about 
> rough consensus.  In my opinion there a nuance between "consensus" and 
> "rough consensus".

It's more than an nuance. It is the distinction made between sections 2 
and 3.

> As a quick reaction I would say that rough consensus provides a faster 
> path to shape up a proposal.  It helps to cut down on document 
> delivery time to the IESG.  The consensus part is sought by getting a 
> broader perspective.

I'm not clear on what if any change you intend here.

> Section 2 sounds like objection-based processing.  A binary choice 
> (re. technical question) can end up polarizing a discussion.  The 
> section provides a good discussion about lack of disagreement.

See my response to Ted on this point. I think objection-based processing 
is part of how we come to consensus (rough or otherwise). And I think 
this section does talk about the problems of posing binary choices. I've 
added text to section 5 on this.

> One of the questions I wondered about is whether the person making the 
> determination should use technical judgement or whether the person 
> should only make a determination about the comments received.  I 
> mentioned in an unrelated discussion that if it is the consensus of 
> the group that the sky is green, that's what goes in the document.  
> The person making the determination can flag it as an issue as a 
> matter of technical judgement.

I think section 3 is pretty clear that the chair must exercise technical 
judgment in many cases. Your hypothetical is the extreme case not 
mentioned in the document. If the group says that the sky is green, 
*and* nobody questions that assertion, *and* the chair suspects the sky 
is not green, I believe it is reasonable for the chair to pose the 
question to the WG: "Are we sure the sky is green?" If the working group 
simply says "Yes" without explanation, I think the chair is within 
bounds to say, just as they are if someone else had raised the issue, "I 
don't think the group has truly considered and weighed this issue such 
that I can declare (rough) consensus on this point." But this must be 
done *extremely* carefully. Chairs who insert their technical judgment 
too often or too heavy-handedly risk losing the confidence of the group 
as an impartial consensus caller. Better might be for the chair to 
(perhaps quietly) solicit a review from a sky color expert from another 
working group, asking for them to comment on this sky being green issue. 
But having the document go forward with a technical issue that the chair 
knows about but that the rest of the working group hasn't noticed is, I 
think, to shirk responsibility as a member of the community.

All that said, I wonder if it's necessary to say this in the document. 
It's a more general comment about the chair role rather than about 
consensus per se.

> I'll highlight a point from Section 3:
>
>   "Remember, if the objector feels that the issue is so essential that it
>    must be attended to, they always have the option to file an appeal."
>
> There are very few people who exercise that option.

I think (hope) that if we start thinking about consensus the way the 
document describes, appeals (at least in the early form, where it's 
simply discussing the issue with the chair or the AD) would not be 
nearly so fraught.

> According to the title of Section 4 humming should be the start of a 
> conversation, not the end.  BCP 25 states that:
>
>   "Consensus can be determined by a show of hands, humming, or any
>    other means on which the WG agrees (by rough consensus, of course)."
>
> I am not sure whether hums are for a starting point or not.  It can be 
> argued in different ways, for example, see Section 4.  Humming helps 
> to get a sense of the room without people making a decision under 
> duress.  It is a useful way to resolve a controversy.  I would say 
> that it ties in Section 5, i.e. consensus is the path, not the 
> destination.  A show of hands is a disguised way to vote [4].

Yup. See my response to Russ, and some of the changes I've made in the 
document. I think this is handled more clearly.

> Section 5 identifies a few issues with the way people talk about 
> "consensus".  I understand what Pete Resnick wrote as he has explained 
> that to me in an unrelated discussion.  The text discusses about 
> "making the call".  I don't know whether the reader will easily 
> understand the meaning of that.

I've added a bit to section 5. Send text if you think it is not sufficient.

> Section 6 and Section 7 attempt to explain that a high percentage of 
> votes in a direction does not necessarily mean that there is rough 
> consensus for that.  I agree with the conclusion in Section 8.

Excellent.

With that, I will send out a new version ASAP. As I said earlier, Jari 
has pushed the magic "please let it through" buttons so that I can post 
this week.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]