Re: Last Call: <draft-resnick-on-consensus-05.txt> (On Consensus and Humming in the IETF) to Informational RFC
2013-10-27 10:58:54
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. - +1 (858)651-4478
|
|