Re: Last calling draft-resnick-on-consensus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]