Re: Last calling draft-resnick-on-consensus

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

 



AB,

I'm very close to take offense by the statement "...WGs' Chair just
follow room's consensus, or f2f participants arguments".

We have maybe 200+ working group chairs, ADs and other people that
need at a rate, from several times a week to maybe once a months make a
"consensus calls". I'm certain that all of does "just" consider the
meeting room  when doing so. I believe that we have a fairly good view
of what rough consensus is, the method to get there and that we are
consistently successful in making the consensus calls, the entire
working group included.

What Pete very successfully and carefully does is that he, investigates
a number of parameters that wg chairs and others need to consider
before/when making a consensus call. Not discussing "the room" would
be a bad thing, but I can't find that anyone is "excluded". You are
here discussing, aren't you?

One thing that I could have a concern about with Pete's document is
that the wg mailing lists are only mentioned twice, but I don't
consider that a proposal from Pete to move away from doing most of
our work on the mailing lists.

/Loa

On 2013-10-11 16:50, Abdussalam Baryun wrote:
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 <presnick@xxxxxxxxxxxxxxxx
<mailto:presnick@xxxxxxxxxxxxxxxx>> 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
    <tel:%2B1%20%28858%29651-4478>



--


Loa Andersson                        email: loa@xxxxxxxxxxxxxxxxx
Senior MPLS Expert                          loa@xxxxx
Huawei Technologies (consultant)     phone: +46 739 81 21 64




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]