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