Re: Last calling draft-resnick-on-consensus

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:
> 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).
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.
> 3) The document does not mention the destinations of *consensus paths* 
> 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*.
> Please amend the abstract:
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.
> 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).
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