Subject: Last calling draft-resnick-on-consensus

From: Jari Arkko <[email-masked]>
Date: Mon, 7 Oct 2013 00:03:57 +0300

The document talks about ways in which consensus processes can be successfully run in the IETF. After the last few rounds of versions, I believe this document is ready to move forward. 

My goal is to publish it as an Informational RFC. It is an explanation of principles and how they can be applied to productively move IETF discussions forward. While there is no change to IETF processes or any presumption that guidance from this document must be followed, I have found the document very useful. It has been referred to numerous times in IETF and IESG discussions. Consensus is hard and many WG discussions have complex trade-offs and differing opinions. I believe having this document become an RFC would help us apply the useful principles even more widely than we are doing today.  

The abstract says:

   The IETF has had a long tradition of doing its technical work through
   a consensus process, taking into account the different views among
   IETF participants and coming to (at least rough) consensus on
   technical matters.  In particular, the IETF is supposed not to be run
   by a "majority rule" philosophy.  This is why we engage in rituals
   like "humming" instead of voting.  However, more and more of our
   actions are now indistinguishable from voting, and quite often we are
   letting the majority win the day, without consideration of minority
   concerns.  This document is a collection of thoughts on what rough
   consensus is, how we have gotten away from it, and the things we can
   do in order to really achieve rough consensus.

      Note (to be removed before publication): This document is quite
      consciously being put forward as Informational.  It does not
      propose to change any IETF processes and is therefore not a BCP.
      It is simply a collection of principles, hopefully around which
      the IETF can come to (at least rough) consensus.

The draft can be obtained from http://tools.ietf.org/html/draft-resnick-on-consensus

You should see a last call announcement soon, and both me and Pete look forward to your feedback.

Jari

---

From: Melinda Shore <[email-masked]>
Date: Sun, 06 Oct 2013 13:14:30 -0800

On 10/6/13 1:03 PM, Jari Arkko wrote:
> My goal is to publish it as an Informational RFC. It is an
> explanation of principles and how they can be applied to productively
> move IETF discussions forward. While there is no change to IETF
> processes or any presumption that guidance from this document must be
> followed, I have found the document very useful. It has been referred
> to numerous times in IETF and IESG discussions. Consensus is hard and
> many WG discussions have complex trade-offs and differing opinions. I
> believe having this document become an RFC would help us apply the
> useful principles even more widely than we are doing today.

Glad to hear it - I think this is an enormously useful document.
I'm wondering if wg chair training at an upcoming meeting can't
be spent on it.  Vancouver's too soon, but what about London?

Melinda

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Oct 2013 06:30:35 +0900

i have found it quite useful in venues other than the ietf.  go for it.

and thanks, pete.

randy

---

From: Scott Brim <[email-masked]>
Date: Sun, 6 Oct 2013 20:06:41 -0400

+1. I've referred people to earlier versions already.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Oct 2013 11:30:52 +1100

This is a VERY useful document, and I look forward to compelling my WG participants to read it, with a pop quiz afterwards.

The only issue I see is its length; while dedicated IETFers won't have a problem reading such a lengthy document, the people who could benefit most - new, potential or casual participants - will give up early, I fear.

Could we have someone take an editorial knife to it? Some of the descriptions of situations are quite long, and there's a fair amount of repetition in the document. Some of the paragraphs are quite long as well. I reckon 2-4 pages could be saved, making it appealing to a much wider audience.

Beyond that, the only suggestion I'd make is an alternate title -- "Why We Hum." Or maybe "The Things We Hum And Do Not Say" (apologies to Jerry Maguire).

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Pete Resnick <[email-masked]>
Date: Mon, 7 Oct 2013 00:45:12 -0500

> This is a VERY useful document, and I look forward to compelling my WG participants to read it, with a pop quiz afterwards.

I've been exceedingly satisfied to hear this sort of thing from you and 
the other folks who posted and talked to me about this.

> Could we have someone take an editorial knife to it? Some of the descriptions of situations are quite long, and there's a fair amount of repetition in the document. Some of the paragraphs are quite…

I would be really disappointed by this. Indeed, my primary target was 
not at all new or casual participants; it was really intended for the 
dedicated folks and the chairs. I hope this is the start of a serious 
discussion in the IETF, not a primer for how the IETF works at a high 
level. For newer folks, I'm fine with the idea that some of this can be 
either incorporated into the Tao or the newcomer's orientation, or 
separated into a smaller primer document. But I really believe the long 
form is needed for real discussions among folks in the community.

> Beyond that, the only suggestion I'd make is an alternate title -- "Why We Hum." Or maybe "The Things We Hum And Do Not Say" (apologies to Jerry Maguire).

And here I was originally paying homage to Wittgenstein, though it even 
got too long for that. Taken under advisement.

Now, off to tackle Dave's excellent (and extensive) review.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Oct 2013 20:57:30 +1100

On 07/10/2013, at 4:45 PM, Pete Resnick <[email-masked]> wrote:

> I would be really disappointed by this. Indeed, my primary target was not at all new or casual participants; it was really intended for the dedicated folks and the chairs. I hope this is the start of a serious discussion in the IETF, not a primer for how the IETF works at a high level. For newer folks, I'm fine with the idea that some of this can be either incorporated into the Tao or the newcomer's orientation, or separated into a smaller primer document. But I really believe the long form is needed for real discussions among folks in the community.

WFM; the Tao seems like a good first stop.

Thanks again,

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 7 Oct 2013 12:00:41 +0100

I agree with Melinda, IETF WG Chair is the key to practice guiding the
group to clear consensus, otherwise guide them to best/productive
discussions related to improvements in the work or in the consensus.

AB

---

From: Lou Berger <[email-masked]>
Date: Mon, 07 Oct 2013 08:48:29 -0400

Hi,

I definitely agree that this is a really useful document. Lots of good
background and general considerations. But I think it misses two
important points that should be addressed prior to publication:

1)  The role WG/IETF mailing lists play in building and
     gauging consensus

The draft leaves me with an impression that mailing lists don't play any
substantive role.  (Said another way: if I'm participating remotely, or
miss a meeting, how do I hum/participate?)  Clearly this is the wrong
conclusion!

I suspect/hope that with all the recent discussion on remote
participation that I really don't need to elaborate on this point any
further.

2) That some participants/chairs/I*s like seeing hands, and that's okay

There are different ways to achieve and determine consensus.  As stated
in RFC2418:
   Consensus
   can be determined by a show of hands, humming, or any other means on
   which the WG agrees (by rough consensus, of course).  Note that 51%
   of the working group does not qualify as "rough consensus" and 99% is
   better than rough.  It is up to the Chair to determine if rough
   consensus has been reached.

I've been in and run many WG sessions where a show of hands is used to
help gauge consensus of those present.  I can't speak for others, but
hands are my preference for a pretty simple reason: my hearing is such
that in a large room, hums just don't provide me any real input -- I can
gauge silence vs hums, but that's about it.  I know that I've been in
rooms where my conclusion of which hummed response was "greater"
differed from others. Perhaps based on where we were each sitting,
perhaps based on hum frequency, perhaps on my/our hearing.  I just don't
know.

I think a show of hands can provide the same input into the consensus
principles described in the draft, and this should be mentioned.  Even
just quoting the 1st sentence from RFC2418 listed above in the draft
should help. Adding some words on how a show of hands differs from a
formal vote would be even better.

Lou

---

From: Jari Arkko <[email-masked]>
Date: Mon, 7 Oct 2013 16:27:45 +0300

> be spent on it.  Vancouver's too soon, but what about London?

Good idea.

Jari

---

From: t.p. <[email-masked]>
Date: Tue, 8 Oct 2013 14:56:32 +0100

I think that this I-D is flawed and should not become an RFC.  It has
several implicit presumptions that I think wrong.

1) It does not state its target audience until, perhaps, the reference
in the Conclusions, to WG Chairs.  It makes no mention of the consensus
calls made by ADs, such as at IETF Last Call, which I think far more
important.  If a WG Chair calls it wrong, there are ADs and IESG who may
put
things right.  When an AD does so, it may be time to abandon hope; and
it is some, a few, of the consensus calls made by ADs at IETF Last Call
that I have thought plain wrong, more so than those by WG Chairs.  Are
ADs assumed to be above and beyond the considerations in this I-D:-(

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?  The
fundamental rule of the IETF, for me, is that business is conducted on
the mailing list.  What happens at meetings some find useful, and it may
be the quickest way to make progress on thorny issues, but the consensus
call belongs on the mailing list.  Unless this I-D is intending to
subvert that.

3) References to working groups with 100 active participants sound like
a chimera.  I track quite a number of lists, and some have about five
active participants.  (Some Working Group Last Calls attract one or even
zero responses; the reactions of chairs to this is interesting and
varies widely).  Even the busiest lists, v6ops and tcpm, for me, do not
remotely approach 100 active participants.

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.  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.

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.

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.

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.

Tom Petch

----- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 07, 2013 6:45 AM
Subject: Re: Last calling draft-resnick-on-consensus

> > This is a VERY useful document, and I look forward to compelling my
WG participants to read it, with a pop quiz afterwards.
> > The only issue I see is its length; while dedicated IETFers won't
have a problem reading such a lengthy document, the people who could
benefit most - new, potential or casual participants - will give up
early, I fear.
> >
> > Could we have someone take an editorial knife to it? Some of the
descriptions of situations are quite long, and there's a fair amount of
repetition in the document. Some of the paragraphs are quite long as
well. I reckon 2-4 pages could be saved, making it appealing to a much
wider audience.
> > Beyond that, the only suggestion I'd make is an alternate title --
"Why We Hum." Or maybe "The Things We Hum And Do Not Say" (apologies to
Jerry Maguire).

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Oct 2013 20:05:49 -0600

On 10/08/2013 07:56 AM, t.p. wrote:
> varies widely).
Although I see Pete's draft more as conceptual than as a handbook for 
every possible situation, I do think that working groups with very few 
participants are a hard case that we need to think about.

Peter

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 9 Oct 2013 08:04:03 +0200 (CEST)

> forward to your feedback.

As a semi-newbie (2 meetings, a few years worth of remote participation), 
I found this document useful. It clearified my understanding of "rough 
consensus".

I am sure the document can be made even better (there have been good 
suggestions in this thread), but I fully support a document of this kind 
being published in some manner (I don't have an opinion if it should be 
BCP or Informational RFC or something else).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Avri Doria <[email-masked]>
Date: Wed, 9 Oct 2013 13:04:07 -0400

Hi,

I think this is an excellent draft and have already sent a pointer of it to colleagues in other organizations as  stuff to consider.

And although it has been eons since I chaired anything in the IETF, it perfectly matches my recollection of what humming  and rough consensus was all about.

thanks

avri

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Oct 2013 09:25:22 +1300

On 10/7/2013 10:03 AM, Jari Arkko wrote:
> The abstract says:
>
> The IETF has had a long tradition of doing its technical work
> through a consensus process, taking into account the different views
> among IETF participants and coming to (at least rough) consensus on
> technical matters.  In particular, the IETF is supposed not to be
> run by a "majority rule" philosophy.  This is why we engage in
> rituals

As I noted in my review of the draft, the document has a core flaw in
its sense of history.  It has invented an interpretation of "rough
consensus" that was not part of its original formulation.

I consider the current focus on reconciling minority views to be quite 
an excellent enhancement to that original interpretation, but it really 
is an addition.  In classic IETF fashion, documenting that enhancement 
flows from common -- though not universal -- IETF practice that has 
emerged, and it likely to produce better consistency to the current, ad 
hoc behavior.  But we need to stop asserting the meaning of "rough 
consensus" to have always or obviously included this.

Part of the confusion about the history is over-interpreting the context 
the phrase was used.  Dave Clark drew a contrast against 'voting'. 
Voting is a mechanical counting process, with formal lines of 
distinction, whether a simple model like 51% or 67%, or the like, or 
something more complex.  But it's based on a strict counting of votes 
and a strict model for using them.

By contrast, the phrase "rough consensus" simply meant that there is 
massive support, and leaves the determination of 'massive' to subjective
processes.  If something has massive support, it is likely to get
implemented, deployed and used.  If it doesn't, the formalities of a
voting mechanism won't help it succeed in the marketplace.  The idea 
that voting will suffice for this concern by simply moving the thresh 
hold to some sort of super-majority imposes an artificial precision; the 
idea behind rough consensus is the subject sense that there is obviously 
'enough' support.

I believe the IETF has only two documents that talk about the meaning of
rough consensus.  The first is Working Group Guidelines and Procedures
that was originally written by Erik Huizer and myself; Scott Bradner's
update to the document didn't change this part of it.  And the relevant
text was something I wrote rather carefully, since the construct was new 
and quite unusual for a standards group:

      http://tools.ietf.org/html/rfc1603#section-3.2

> 3.3. Session management
>
>
> Working groups make decisions through a "rough consensus" process.
> IETF consensus does not require that all participants agree although
> this is, of course, preferred.  In general the dominant view of the
> working group shall prevail.  (However, it must be noted that
> "dominance" is not to be determined on the basis of volume or
> persistence, but rather a more general sense of agreement.) Consensus
> can be determined by balloting, humming, or any other means on which
> the WG agrees (by rough consensus, of course).

The other document is recent versions of the Tao of the IETF. It did not 
originally discuss the issue but Sue Harris added discussion of
it in 2001, and the latest text on the Tao web page seems to have the 
same text.[*]

      http://tools.ietf.org/html/rfc3160

> 3.2 Getting Things Done in a Working Group
...
> Another aspect of Working Groups that confounds many people is the
> fact that there is no formal voting.  The general rule on disputed
> topics is that the Working Group has to come to "rough consensus,"
> meaning that a very large majority of those who care must agree.

And the simple focus on a strongly dominant group preference was what 
was presented in the original Working Group Chair training I initiated 
also in the early 90s:

      http://bbiw.net/presentations/ietf-stds-4.pdf

So, folks, please do press for Pete's document to move towards readiness 
to be published.  But let's not invent history and thereby fail to 
understand the difference between 'clarifying' and 'enhancing'.

d/

[*]  Small observation about the current fashion of moving things to web 
pages rather than RFCs:  We completely lose version tracking, and being 
able to review the history of the document.  While one might add a 
mechanism to remedy this, note that we don't do that now.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Oct 2013 23:37:47 +0300

> I consider the current focus on reconciling minority views to be quite an excellent enhancement to that original interpretation, but it really is an addition.

Ok. I was not there at the time to witness the history. Thanks for the clarification.

Jari

---

From: Scott Brim <[email-masked]>
Date: Thu, 10 Oct 2013 18:42:12 -0400

True, it was mostly a reaction to the IETF's tendency to over-proceduralize
everything, and an inclination to voting. The main issue I have been
concerned with since then, and something this draft helps with, is
redefinition of "rough consensus" to manipulate WG outcomes.  WGs need to
get beyond the primitive basic concept of rough consensus, to get more
nuance in the principles of how they are run. I like this draft as
contributing to that.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 10 Oct 2013 17:04:33 -0700

A small comment in-line.

On Thu, Oct 10, 2013 at 1:25 PM, Dave Crocker <[email-masked]> wrote:

> I consider the current focus on reconciling minority views to be quite an
> excellent enhancement to that original interpretation, but it really is an
> addition.  In classic IETF fashion, documenting that enhancement flows from
> common -- though not universal -- IETF practice that has emerged, and it
> likely to produce better consistency to the current, ad hoc behavior.  But
> we need to stop asserting the meaning of "rough consensus" to have always
> or obviously included this.
>
> the phrase was used.  Dave Clark drew a contrast against 'voting'. Voting
> is a mechanical counting process, with formal lines of distinction, whether
> a simple model like 51% or 67%, or the like, or something more complex.
>  But it's based on a strict counting of votes and a strict model for using
> them.
>
> voting mechanism won't help it succeed in the marketplace.  The idea that
> voting will suffice for this concern by simply moving the thresh hold to
> some sort of super-majority imposes an artificial precision; the idea
> behind rough consensus is the subject sense that there is obviously
> 'enough' support.
>
> rough consensus.

In addition to the two you cite, RFC 3929  does, primarily in Section 2 but
also 3.3 and a few other places.  As the author of that Experimental RFC, I
will note that I am not aware of any case in which any of its proposals has
been carried out, though it has been discussed as a possibility more than
once.

The first thing most readers note is that using one of its methods does not
get you out of building consensus--it requires you to build consensus for
an alternate approach when consensus on a technical matter cannot be
reached by the baseline process (and it is clear that it is not trying to
change the baseline).

regards,

Ted

---

From: Pete Resnick <[email-masked]>
Date: Thu, 10 Oct 2013 22:02:42 -0500

On 10/8/13 8:56 AM, t.p. wrote:
> in the Conclusions, to WG Chairs.  [...]  Are

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.

> 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.

> 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.

> '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

Sure. But that would be a different example.

I don't understand your concern here.

> is small and often not apparent).  You quote Dave Clark's aphorism but

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.

> such as express an opinion, clearly, technically; else, perhaps, keep

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.

> which we are mostly amateurs.  We then go beyond our capabilities and

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

---

From: Pete Resnick <[email-masked]>
Date: Thu, 10 Oct 2013 22:08:33 -0500

On 10/7/13 7:48 AM, Lou Berger wrote:
> I think it misses two

Yeah, as I just replied to Tom, I think this is worth adding, probably 
in section 2 or 3.

> 2) That some participants/chairs/I*s like seeing hands, and that's okay

Yes, this is directly said in section 4, paragraphs 4 & 5. What do you 
think is missing?

>     consensus has been reached.

As I said in my reply to Dave, there's part of the above that I disagree 
with, or at least think is an oversimplification. But it definitely need 
citing.

pr

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Oct 2013 09:50:16 +0100

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 <[email-masked]>wrote:

> 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.
>
> 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.
>
>
> 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.
>
>
> 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
> 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.
>
>
> 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.
>
>
> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
> >

---

From: Loa Andersson <[email-masked]>
Date: Fri, 11 Oct 2013 17:55:28 +0800

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     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.
>
>
>     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
>     describe for f2f conclusions of consensus. I think that's worth
>     pointing out.
>
>
>     The only place where there's mention of large groups is in the last
>     two sections, which are specifically the extreme examples. They are
>     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
>     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.
>
>
>     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/>>
>     <tel:%2B1%20%28858%29651-4478>
>
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Oct 2013 10:13:59 -0400

Pete,

> Yeah, as I just replied to Tom, I think this is worth adding, probably

great.

> Yes, this is directly said in section 4, paragraphs 4 & 5. What do you

It says hum+hands. My point is hands-only is okay and can be essentially
equivalent to the "humming" described in your document.  I think it
would be valuable to make this point explicitly, as I essentially
everything else you say in the document.  And I completely agree with
your point that a show of hands (& a poll on the list) are not votes.

> with, or at least think is an oversimplification. But it definitely need

got it, but as you say this document is Informational and doesn't
propose any change to IETF process, while RFC2418 is a BCP which does
define process.

Lou