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
<jari(_dot_)arkko(_at_)piuha(_dot_)net> 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