Hi Pete, I object if the draft excludes remote participants opinions/feedbacks, the IETF WG list is the main place for measuring consensus not a physical limited room located in a region. Some WGs' Chair just follow room's consensus, or f2f participants arguments, which is not best practice relating to IETF procedures. The most important facility of IETF is that it works/decides remotely with individuals signatures/confirmations.
AB On Fri, Oct 11, 2013 at 4:02 AM, Pete Resnick <presn...@qti.qualcomm.com>wrote: > 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/<http://www.qualcomm.com/~presnick/> > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > >
