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