On Consensus and Humming in the IETF
draft-resnick-on-consensus-07

I'm setting aside the issue of whether AD-sponsored is appropriate for
this document. It is somewhat ironic that this document about consensus
has debatable consensus on its content because it is basically Pete's
views. 

But we need to have the wider debate about this issue and not pin it to
any one I-D in the pipe. 

So here is my "No Objection".

---

Thanks to Pete for some long conversations about this document. It
leaves me with a list of issues that I think are basically editorial
and can be worked through. I trust Pete as author to make the necessary
changes, and I believe he and I understand the changes necessary.

---

It may help to draw out (further) the disctinction between issues and 
people. That is, consensus is not just the agreement of people to  
continue on a specific path (e.g., publish this document whatever its
contents) but also requires that issues have been recognised and 
handled.

As an example, if tourist who really doesn't care about the fate of the
work raises an issue. It is not enough for the tourist to say "I don't
care" - that might give consensus to move ahead, but the issue also 
needs to be addressed.

---

I do feel that the document mixes (confuses?) the decision-making
process with the decision-evaluation mechanism. While the two are hard
to separate, I think that it would be very valuable to do so.

This is really a question of how we reach/drive consensus, how we 
track and address issues, and how we listen to opinions.

I'm afraid I can't come up with a specific change to help with this.
but maybe it would help to talk about what chairs should be doing to
help the WG reach consensus.

---

The statement of intent for this document in the Abstract is altogether
too wishy-washy. Contrast with the final paragraph of the Introduction
that is much more clear (although see separate comments about it).

My main concern with the Abstract is that you have nothing here we can
build consensus around. Does "it is a collection of thoughts" mean that
the IETF has consensus that it is a collection of thoughts? I don't
think that is what you want - I think that, per your note (to be
removed) is much more helpful about describing the purpose which is
that "this document contains a collection of principles about rough
consensus and how it can and does operate within the IETF."

I also think that "this Infomational document does not change any IETF
processes" is important to retain in the Abstract.

---

Section 1

   Almost every IETF participant knows the aphorism from Dave Clark's
   1992 plenary presentation [Clark] regarding how we make decisions in
   the IETF:

I actually doubt this, and I bet you have no evidence for it. Maybe just
a simple re-wording such as "A well-known aphorism..."


---

Section 1

s/(kings and presidents)/(king or president)

---

Section 1

I would replace

   nor should decisions be made by a
   simple vote of the majority

with

   nor should decisions be made by a
   vote

since "simple vote" implies decisions can be made by complex vote,
and "of the majority" implies decisions can be made by some other
portion of the whole.

---

Section 1

   This document attempts

Maybe a bit more positive to strike "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 proscribe 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

Strike "expected to be"

   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

Strike "are meant to"

   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 or trying to assess consensus.


Just a specific quesiton on this: While you might be happy for anyone in
the IETF to read this document, it is not your intent to be specifically
providing guidance to IETF participants trying to participate in
consensus-building processes nor to understand how consensus might have
been judged?

---

In section 2 I found that

   We might have to compromise processor speed for lower
   power consumption, or compromise throughput for congestion
   resistance.  Those sorts of compromises are among engineering
   choices, and they are expected and essential.  We always want to be
   weighing tradeoffs and collectively choosing the best set.

Did not sit well.
I think it was "best set" that caused me trouble. "Best" has become the
enemy of "compromise" and I would recommend dodging that bullet by
cutting the last sentence after "tradeoffs".

---

In section 2 you say...
   the word "compromise" gets used in two
   different ways
...and then you list three ways

---

Section 3 final para

A technical error is always a valid basis for an appeal.

s/error/objection/

---

I don't think your use of "appease" is right in Section 2. And I don't
think capitulation is necessarily involved either. Both of those words
seem more in line with the "horse-trading" than the walking away.

How about saying

"walked away for whatever reason"

---

Section 3

   If the chair finds, in
   their technical judgement, that the issue has truly been considered,
   and that the vast majority of the working group has come to the
   conclusion that the tradeoff is worth making, even in the face of
   continued objection from the person(s) who raised the issue, the
   chair can declare that the group has come to rough consensus.

That'll be a vote, then :-)

Let me pretend to be an insufferable pedant for a moment. Is "vast
majority" more than 65%? More than 75%? 

It isn't really a matter of the vastness of the majority. Rephrase?

---

I don't think that saying that "in the rough" comes from golf and is a
play on words helps people understand the meaning. How about...

   ("In the rough" is terminology from golf.  The rough is the longer
   grass at the side of the fairway, and if your ball has landed in the
   rough you are off course and away from the normal direction of play.
   The phrase gets used quite a bit in the IETF as a play on words to
   complement "rough consensus" meaning that you are in the rough if you
   find yourself not agreeing with the rough consensus.)

---

Section 3

   In order to do this, the chair will need to have a good idea
   of the purpose and architecture of the work being done, perhaps
   referring to the charter of the working group or a previously
   published requirements document, and use their own technical
   judgement to make sure that the solution meets those requirements.
   What can't happen is that the chair bases their decision solely on
   hearing a large number of voices simply saying, "The objection isn't
   valid."  That would simply be to take a vote.  A valid justification
   needs to me made.

Pete and I debated "technical judegment" quite a bit. We agreed (I
think) that sometimes this judgement extends to delegated judgement. We
also agreed that the appealability of that judgement is important to
highlight.

---

I snarf when I see "traditional".

   It is important to recognize that this view of rough consensus is a
   change from the way it has been traditionally characterized in the
   IETF.  Rough consensus in the IETF is often talked about as the
   "dominant view" of the group, as RFC 1603 [RFC1603] described:

Note that RFC 1603 and Dave Clark's "we reject voting" are almost
contemporaneous. Yes one says "ballot good" and the other appears to
say "ballot bad".

Can I suggest cutting the first sentence.

Furthermore, in...
   The above does say that "volume" is not the basis for a determination
   of consensus, but over the years many IETF folks have thought of
   rough consensus as being primarily about the percentage of people who
   agree with a decision.
...I think you have misinterpretted how 1603 meant "volume". I believe
it was talking about loudness. That is why "volume" is grouped with
"persistence". It is saying that rough consensus is not about how loudly
Adrian shouts, but about how the bulk of the WG feels. In other words,
it is closer to the percentage argument than you make out.

[Not that I am saying that a straight percentage is all that counts, and
neither are you in this section (notwithstanding the fact that you
talked about the "vast majority" in earlier text). But I am saying that
it is a factor.]

---

   One of the strengths of a consensus model is that
   minority views are addressed

I do struggle with "addressed". I think it has more of an implication
of accommodation than is intended. I think "properly considered" is a
better forumlation.

---

   The chair (or whoever is responsible to hear an appeal)...

It counds like you are saying that the chair hears the appeal, but you
haven't said that (and you would have been wrong). Why not...

   The chair in making the consensus call (or whoever is responsible to
   hear an appeal)...

---

I like section 5. It stands against some of the other text, especially
the first sentence of section 6 which jars quite badly coming
immediately after section 5. 

The fix would be to try to reflect the message of section 5 into the
rest of the text.

---

The whole concept of humming applies, AFAICS, only to physical meetings.

The document could use consideration of humming on mailing lists and
how that kind of temperature guage can be used so that we don't have to
wait four months to move a discussion forward.

Curiously, Stewart just raised this exact question and a couple of ADs
made suggestions about how they have handled this.

---

Section 10 : something broken in

>  [Clark]    Clark, D., "A Cloudy Crystal Ball - Visions of the
>             Future", July 1992.
>
>             In

---

The RFC Editor will object to you including references without citing
them from your text. [IETF24] seems to be missing.

---

I appreciate you referencing Sheeran, but I note that there is no over-
riding intent in the IETF to reach consensus. Maybe that is a serious 
lack in the IETF. But, of course, we typically care more about our jobs
and welfare than about perfection of consensus and the welfare of the
Internet :-)

Maybe you also need to discuss timeliness of decisions in this context.
Should the IETF strive for consensus (rough or otherwise) in the face of
immediate need for a solution. Some might argue that our process is 
already slow enough (partly because of consensus). Others might argue
that quick and good are not usually compatible.

In discussing this point, Pete and I concluded that it may be helpful to
note that an acceptable way of moving forward with unresolved issues is
to note them in the RFC and have a plan to revist and resolve.

   Now, a conclusion of having only rough consensus relies heavily on
   the good judgement of the consensus caller.  The group must truly
   consider and weigh an issue before the objection can be dismissed as
   being "in the rough".  ("In the rough" is terminology from golf.  The
   phrase, which gets used quite a bit in the IETF, is just a play on
   words.) 

As a non native speaker, I had someone explained to me the  "to be in the rough" meaning.
And believe me, I searched the web. So, just telling it's a play on words without being precise on what it means is misleading, at the very minimum.
One might get it from "participant is not in the "rough" part of a rough consensus", but this document needs an explanation/definition within the IETF context.

-

   The chair in this case needs to understand what the responses mean;
   only sufficiently well-informed responses that justify the position
   taken can really "count".

Not sure I understand "well-informed".
I'm well-informed (because I'm the marketing guy for the feature I prefer), and my view is "I prefer A" is not what you mean.
You're after responses with 
	- well-argumented responses
	or even better:
	- well-argumented responses with new objections that have not addressed before.

"well-argumented" is better but I'm not totally happy with it ...