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.
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
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.
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.arkko@xxxxxxxxx> 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