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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. - +1 (858)651-4478





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]