Re: Musing on draft-resnick-on-consensus-01

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

 



Just to level set: I had not really intended for this document to be discussed on the IETF general list quite yet. It still has quite a few gaping holes. So even though it is posted as an I-D, I'm inclined to have people send comments to me individually for the time being. If and when I think it is ready for wide-ranging discussion, I'll be sure to solicit comments here. If you do insist on discussing it here, understand that sometimes the answer will be, "Yep; gotta think about that. Not done yet."

Also note the disclaimer in the document:

      Note: This document contains the musings of an individual.  Right
      now, it is just some rough notes and has lots of holes that need
      to be filled in.  Even if those holes are filled, in its current
      form, it is not intended to be published as an RFC, let alone
      being a BCP for a change of IETF policy.  If it evolves into such
      a thing, great.  If it simply sparks discussion as an Internet
      Draft, that's a perfectly fine outcome.

That said, I'll answer some of SM's comments publicly since he posted publicly:

On 2/14/13 5:02 PM, SM wrote:

The above is about working group consensus. I suggest adding some text in the Introduction Section which mentions that it is about that. The "We only require rough consensus" can be misunderstood as being the bar in an IETF-wide call.

No, "We only require rough consensus" *is* the bar in an IETF-wide call. If I need to make that clearer in the document, I shall. We use exactly the same decision criteria for working groups and for the IETF writ-large.

The IAB recently had a discussion about "bottom-up organizational modes". If I am not mistaken (please correct me) the IETF is the only organization that uses "humming". I would say that it works in the IETF as it is part of the culture; it cannot be grafted on an organization. There are cases when a show of hands can be used. The sentence that follows the quoted text explains when to use "humming".

Melinda addressed this quite well. "Humming" is simply a practice meant to reinforce that we use consensus rather than voting as our basis for decision making. But as the document says, it is possible to "hum" when what you are really doing is voting, and it is possible to use a show of hands to help guide consensus. (See section 4, paragraph 4.) The practice of humming is not *really* what's important; it's getting consensus and not allowing majority rule. Another organization could adopt humming *if* it was interested in consensus-based decision making.

  "The key is to separate those choices that are simply unappealing
   from those that are truly problematic."

I leave it to you to see whether you want to use the following:

Thanks. One of the big holes I haven't attempted to fill is more specific practical advice. That might serve usefully.

I read "compromise" as something intermediate between two things. Consensus is used for conflict resolution. It's not possible to resolve an issue if the two sides are not ready to compromise. If you have two sides you end up with a King Solomon scenario. It is very difficult to resolve the issue then. Maybe "conciliatory" may be a better term to express the idea (see text quoted above).

Yes, a couple of people have brought up this section, and I will need to expand. The main point is that neither "giving up" (i.e., believing that an issue is a real problem, but no longer being willing to discuss it) nor "horse trading" (i.e., "I'll let you put your broken thing in the document if you let me put my thing into the document that you think is broken") is coming to consensus. "Giving up" and "horse trading" are failures of consensus. (I distinguish "giving up" from "deciding that the document has made a good engineering tradeoff" and "horse trading" from "discovering common ground", the latter of which in each case are *good* things.) I have to figure out how to make that point more clearly.

The draft uses "objection" and "objector" in discussing about consensus. That works in a formal or legalistic context. In an IETF context you end up being the person standing out as you raised an objection. Arguments do not have to be for or against (objection). It's difficult for me to find the words to explain this. I see that you used the word "concerns" in Section 4.

Note the title of section 2. Figuring out the objections is the important part of coming to consensus. "Thoughts" or "concerns" are often distracting to figuring out consensus. I'll try to explicate in the document.

In Section 3:

  "If the chair finds, in their technical judgement, that the issue
   has truly been considered, and that the vast majority of the working"

Is it "technical judgement" or "the technical issue has been considered"? For the former, the chair ends up taking a technical decision. For the latter, the chair only has to use judgement.

I really meant "technical judgement". This is one of the trickiest bits of *rough* consensus. There are times where a chair is truly going to have to use their technical judgement to figure out whether the WG has truly addressed an outstanding issue that someone maintains is still a problem. This is hard. And it requires the good faith of the chair, and the trust of *all* of the participants (including the person(s) who end up in the rough). And it's where appeals can happen. And it's a cornerstone of how rough consensus works. More text necessary.

RFC 3929 broaches consensus from a different angle.

Quite. 3929 is much more about practical advice. I am likely to get to some of that (and will cite/incorporate from 3929 as I can when I do so). But mine is more of a "getting our minds around the issue" document. And there are certain things in 3929 that I think are serious points of disagreement (on the theory) between Ted and I. Those I'll also likely need to address.

Rough consensus is the lesser barrier when consensus is not possible.

That's not quite right. See the discussion re: chair's judgement above. When the consensus is rough, it is much more precarious and much harder to determine. It's not a lesser barrier; majority rule would be a lesser barrier. I'll have to find some words to express this.

Lack of disagreement can also be a sign that the working group has not carefully considered the question.

That goes back to the "everyone working in good faith" premise. If a working group has not carefully considered a question, that's a failure across a huge number of people, from participants up through the IESG.

Thank you for your comments.

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]