Subject: Re: Last calling draft-resnick-on-consensus

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Oct 2013 11:40:23 +0100

Reviewer: Abdussalam Baryun
Date: 11.10.2013
Last Call For the General Area
I-D reviewed: draft-resnick-on-consensus-05
++++++++++++++++++++++++++++++++++
Hi Pete and Jari,
The documents provide important examples which are real within IETF, and
needs to be studied/analysed more as case studies. Such real examples
should be documented by historical documents which will help future work
like this to refer to as real incidents. However, I support the idea of the
draft subject to the below five requirements (the sixth is recommendation):
1) The draft should include remote participants input to the consensus
process or path. The mailing list should be the main place for consensus
measuring its roughness in the Internet community (not in only rooms or in
hidden design teams).
2) The document does not mention the editor's task and how to work with
discussions or chairs. If the editors are 5 most active participants in the
WG then they are ruling the WG, and they can even discourage inputs by just
disagreeing. I in MANET WG experienced many examples mentioned in your
document, which I think will help future new participants to make better
impacts on ietf WGs. I request explaining editors input and Chair's in such
examples/situations. Editors and Chair are the ones facilitating on the
path (i.e. consensus, as mentioned in draft).
3) The document does not mention the destinations of *consensus paths*
within IETF. What you mean by destination? For me the destination is to
submit the best document to IESG, or to Adopt an interesting document as WG
document. Many individuals may not get to thoes destinations because of
IETF WG Chair's methods. I recommend as you solve the *path* as it is
consensus, but also correcting the path to get to correct destination only
if we identify the destination. I request to define the destination and to
define what is engineering reasons in agreeing and disagreeing (in IETF
some times discussions are only politics not engineering, which makes
problems in document qualities).
4) In the abstract you use *WE*, I object to use that word only if defined;
do you mean all community or you mean majority, or minority, or management,
or f2f participants or remote participants, or WG chairs, or ADs, etc. In
my thoughts the meeting humming majority are the North America participants
(i.e. check ietf statistics), but if you include remote participants of
IETF in the draft then becomes diversified majority. Humming is used only
in meetings not on lists, you may think of another way to do it on the
list. Suggest/request to add in the abstract that this document should be
as information to the training of WG Chairs. Also the abstract should
include what is mentioned in the conclusion of *the way of thinking to get
to participation decisions*.
Please amend the abstract:
draft-05>Abstract:
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.
AB>amend>
The IETF has had a long tradition of doing its technical work through
a WG consensus process [reference], taking into account the different views
among
IETF participants and coming to better (at least rough) consensus on
technical and procedural matters. In particular, the IETF is supposed not
to be run
by a "majority rule" philosophy but an engineering community rule
philosophy. This is why particpants engage in rituals
like "humming" instead of voting within meetings. The results of consensus
should have good engineering reasons. However, more and more of the IETF
discussions/actions are now indistinguishable from voting, and quite often
Chairs are
letting the majority win the day, without much consideration of minority
concerns. This document is a collection of thoughts on what a fair rough
consensus is like, how IETF participants have gotten away from it, and the
things they should do in order to really friendly guide for rough consensus
achievement. The point of this document is to get all community to
think about how IETF community is coming to better decisions in the IETF,
to make sure participants avoid the dangers of "majority rule" and actually
get to friendly rough consensus decisions with the best technical outcomes.

Note (to be removed before publication): This document is quite
consciously being put forward as Informational that can be used for WG
chairs training. It does not
propose to change any IETF processes and is therefore not a BCP.
It is simply a collection of principle understandings, hopefully around
which
the IETF can come to better (at least rough) consensus.
5) I request to see the word *polite*, *friendly*, *encourage*, and other
positive ways of thinking that helps (i.e. don't mean formal or informal
writting on the list) , because I see some negative thinking in some
participations of IETF WGs, so I request the draft to mention friendly
efforts. For example, many of my experience while getting negative
posts made me positive because our ADs are very positive and friendly when
solving issues, and they do advise nicely, so we need more
friendly/positive thinkings in the IETF among f2f participants, remote
participants, and old-comer participants.

6) Not understood the information on the draft's ideas on process of
consensus path or paths or the number of its practices, and how the Chair
should use different paths or methods to get to better consensus (i.e. each
time measures consensus the chair tries to gain a better one not worse
one). People think of what will happen if some disagree with our draft, so
they think how to use such path, so your draft makes me think of what are
my friendly or informal options. I recommend to make more work if possible
of solutions/guidances for the consensus facilitators (editors, chairs,
ADs).
++++++++++++++++++
Best Regards
AB

On Sun, Oct 6, 2013 at 10:03 PM, Jari Arkko <[email-masked]> wrote:

> 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: Scott O Bradner <[email-masked]>
Date: Fri, 11 Oct 2013 08:15:52 -0400

As Dave Crocker pointed out, this document is, at best, revisionist history.  Dave's original RFC 1603 text (that I carried forward into RFC 2418) bears little resemblance to the process/considerations described in this ID.
 
This ID may be describing how we should start to view the meaning of the term "rough consensus" , but I do wish that the ID took care to propose it as new concept rather than pretend that it has always been what the IETF has done.  The process in the ID is not what was followed when I was an AD and it not what I have described by the meaning of the term "rough consensus" in my newcomers tutorials (which I have been giving since at least IETF 57 in 2003). 
 
Thus I do not consider this ID ready for publication and call for it to be revised to clearly state that it is proposing a redefinition of the concept and term "rough consensus" then re-last called.
 
Scott

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Oct 2013 13:11:42 -0400

On Oct 11, 2013, at 8:15 AM, Scott O Bradner <[email-masked]> wrote:
> The process in the ID is not what was followed when I was an AD and it not what I have described by the meaning of the term "rough consensus" in my newcomers tutorials (which I have been giving since at least IETF 57 in 2003). 

Perhaps I should be embarrassed to ask this question, but how _do_ you describe the meaning of the term "rough consensus?"

---

From: Pete Resnick <[email-masked]>
Date: Sun, 27 Oct 2013 06:24:45 -0500

Overall, I think some of your points are well-taken and I think the 
edits I've made to address everyone's comments should address your 
comments as well. However, I think you also want this document to be 
more generally about IETF process and to require participants to to 
certain things. I think those items are beyond the purpose of the 
document. Details below.

On 10/11/13 5:40 AM, Abdussalam Baryun wrote:
> process or path. The mailing list should be the main place for 
> consensus measuring its roughness in the Internet community (not in 
> only rooms or in hidden design teams).

I think this is a good point, and I've made sure to elaborate the 
examples that are specifically about mailing lists a bit. I don't want 
to go much further into the specific process points (e.g., that the 
mailing list is the final place for the WG taking decisions), as those 
are already addressed in other documents, and this document is really 
about the nature of consensus, not specific processes in the IETF.

> 2) The document does not mention the editor's task and how to work 
> with discussions or chairs. If the editors are 5 most active 
> participants in the WG then they are ruling the WG, and they can even 
> discourage inputs by just disagreeing. I in MANET WG experienced many 
> examples mentioned in your document, which I think will help future 
> new participants to make better impacts on ietf WGs. I request 
> explaining editors input and Chair's in such examples/situations. 
> Editors and Chair are the ones facilitating on the path (i.e. 
> consensus, as mentioned in draft).

I've certainly clarified that editors can lead consensus discussions, 
but I don't think that's what you're getting at. You seem to be 
concerned that editors can abuse their position. But if a chair does 
take seriously the notion about open unaddressed issues, this shouldn't 
happen. I don't think this document should be trying to address every 
process failing in the IETF.

> within IETF. What you mean by destination?

This is mentioned in the first sentence of section 5: The destination is 
"the best technical (and sometimes procedural) outcome when we make 
decisions."

> For me the destination is to submit the best document to IESG, or to 
> Adopt an interesting document as WG document.

This is too specific for this document. And to a certain extent it 
sounds wrong: The *document* is not the goal, and "interesting" is 
certainly not the right criteria. The deployed protocol is the goal and 
technical correctness (or at least some good engineering tradeoff) is 
the right criteria.

> 4) In the abstract you use *WE*, I object to use that word only if 
> defined; do you mean all community or you mean majority, or minority, 
> or management, or f2f participants or remote participants, or WG 
> chairs, or ADs, etc.

I definitely mean the entire IETF community, and I think that's 
perfectly clear in the document.

> Suggest/request to add in the abstract that this document should be as 
> information to the training of WG Chairs.

I have added some text about the intended audience in the introduction.

> Also the abstract should include what is mentioned in the conclusion 
> of *the way of thinking to get to participation decisions*.

I've updated the abstract (and the introduction) to hopefully capture 
what you desire. Your suggested text was a bit too detailed for an 
abstract in my opinion. And again, remember that this document is *not* 
proscribing process.

> 5) I request to see the word *polite*, *friendly*, *encourage*, and 
> other positive ways of thinking that helps (i.e. don't mean formal or 
> informal writting on the list) , because I see some negative thinking 
> in some participations of IETF WGs, so I request the draft to mention 
> friendly efforts.

Again, though I certainly agree that such values are good and important 
in discussions, I think this starts to go beyond the discussion of what 
consensus is and how it works, and delves more into the general behavior 
of IETF participants.

> consensus path or paths or the number of its practices, and how the 
> Chair should use different paths or methods to get to better consensus 
> (i.e. each time measures consensus the chair tries to gain a better 
> one not worse one). People think of what will happen if some disagree 
> with our draft, so they think how to use such path, so your draft 
> makes me think of what are my friendly or informal options. I 
> recommend to make more work if possible of solutions/guidances for the 
> consensus facilitators (editors, chairs, ADs).

If I understand you correctly, you are recommending that the document 
say more about how leaders can progress and get closer to consensus as 
they do their work. I hope some of the expansions and clarification I 
have put in the document do some of that.

Thanks for your feedback.

pr

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