On 10/8/13 8:56 AM, t.p. wrote:
1) It does not state its target audience until, perhaps, the reference
in the Conclusions, to WG Chairs. [...] Are
ADs assumed to be above and beyond the considerations in this I-D:-(
An excellent point. No, *every* consensus caller in the IETF should in
my view be taking these points into consideration, ADs and chairs alike.
The examples are full of WG/chair stories, but exactly the same kinds of
things should happen, IMO, when ADs make consensus calls.
As I said elsewhere, my primary (though not sole) audience is IETF
leadership (ADs, chairs, editors, secretaries, etc.) and experienced
IETFers who already understand the basics of our process and/or might
some day wish to be in such roles. Hopefully the document is somewhat
accessible to newer or once-in-a-blue-moon participants, but I hope the
main consumers of this document are folks who need to make consensus
calls or might some day.
2) There is an extensive discussion on the show of hands and the hum.
What technology allows you to conduct those on a mailing list?
I don't really talk about mailing lists, and I think you're right that
it's worth spending at least a bit of time on in the document. In fact,
neither a "hum" or a show of "hands" (messages?) on a mailing list makes
a bunch of sense. Methodologically, I think the best way for chairs (or
ADs) to deal with a mailing list is to checkpoint every so often,
summarizing issues and perhaps even keeping an issues list, and then
explicitly calling the consensus: "I hear that people are in favor of X
and I haven't heard strong objections. Unless there's anyone who can't
live with X, I am going to say that we have consensus for it." It's the
same sort of thing I describe for f2f conclusions of consensus. I think
that's worth pointing out.
3) References to working groups with 100 active participants sound like
a chimera.
The only place where there's mention of large groups is in the last two
sections, which are specifically the extreme examples. They are
illustrative examples of the worst case scenario, not meant to be
representational of the common case.
4) "Five people for and one hundred people against might still be rough
consensus". Can you see the presumption in that? Read on and the
following text makes it clear that five are 'right' and one hundred
'wrong', but you are presuming that "for" is the right answer.
Yes, that's the example I've used. In this example, the five people have
made their case for a technical solution, one person has made an
objection, the five people fully address the objection, and therefore
there is rough consensus. So in this case consensus was "for". The
example is meant to show that 100 people blindly piling on the "against"
side does not make them "right" and does not change the consensus.
The
right answer to a consensus call is a consensus,which can be "against",
as much as "for", something that does not seem to be contemplated here.
Sure. But that would be a different example.
I don't understand your concern here.
5) Good WG chairs, and happily there are plenty of them, make their
presumptions plain, as in asking for information about implementations
at or around judging consensus. The views of someone who has
independently produced rough code is then likely to outweigh those of a
dozen people who have not, so three such expressing a view in one
direction will prevail over several dozen who have not in the opposite
direction. (This is all right as far as it goes, but I would like the
views of users and operators to count for even more, since it is they
who have the most to gain or lose; but sadly, their representation here
is small and often not apparent). You quote Dave Clark's aphorism but
then ignore half of it.
Two things about this:
1. This document is about how we can come to consensus, not about the
criteria around which we get that consensus (of which running code is
one). And interesting document could be written about how we do (and
sometimes don't) take running code into account, but it's not this document.
2. I take issue with one thing you do say above: "The views of someone
who has independently produced rough code is then likely to outweigh
those of a dozen people who have not". I think this is actually wrong:
It is not that the implementer's view is given more weight *because it
came from the implementer*; that would be an ad hominem judgement. The
implementer's view is given more weight when it contains a solid
technical case based on implementation experience. If an implementer
says, "I've implemented this code and I can tell you that the way you
are proposing won't interoperate", and someone with no implementation
experience is able to say, "I can point you to implementations X Y and Z
that implemented it my way and do interoperate", the fact that it's an
implementer should make no difference at all. It is the existence of the
implementation and how well it works that's the trump card, not who
talks about it.
6) The document is strangely silent about what the vast mass of the
IETF who are not WG Chairs might do to help reach a consensus,
such as express an opinion, clearly, technically; else, perhaps, keep
quiet.
I think the document is useful without this discussion. I certainly
would not object to adding such a section in the future, but I don't
think it's necessary in this version. Again, this is mostly aimed at
discussions of how leaders can facilitate getting to consensus.
7) As has been said before when documents like this are up for
discussion, the IETF is an organisation of engineers and, for the most
part, we do it rather well. Managing and leading loose and diverse
groups of people is more psychology or sociology than technology, at
which we are mostly amateurs. We then go beyond our capabilities and
get it wrong. As here.
I'm not clear on how the discussions of how to manage and lead consensus
discussion that are presented in the document you think "gets it wrong".
Quite a few folks have found it useful and productive. More specifics
welcome.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478