Greg and all,
in the
early stage of the ICG there was an extensive discussion on how to make decision
and in particular with regards to finding consensus. As a basis I’ve introduced
the related GNSO process you and others are referring to.
It turned
out that this approach wasn’t fully acceptable by ICG members, and the result is
the “ICG Guidelines for Decision Making“
which you may find here: https://www.icann.org/en/system/files/files/icg-guidelines-decision-making-17sep14-en.pdf
Transparency of
the consensus building process of the various groups providing proposals for
IANA stewardship transition is of utmost importance.
Best regards
Wolf-Ulrich
Best regards
Wolf-Ulrich
From: Greg Shatan
Sent: Tuesday, March 24, 2015 6:18 PM
To: Kavouss Arasteh
Subject: Re: [CCWG-ACCT] Meeting with CCWG
Advisors
Dear
Kavouss,
Thank you for
your email. I am sorry you disagree with the decision that was made a number of
years ago to adopt that level of consensus in the GNSO and to call it
"consensus." However, this definition of "consensus" is a fact -- this is
the de jure standard for consensus in the GNSO. While one can
disapprove of a fact, I'm not sure that one can disagree with a fact (at least,
not with any effect). Since it is a fact, we will need to deal with it as
such. In order to communicate between sectors of the community about
consensus, we need to make sure we know what one means when one says
consensus. Since we don't all mean the same thing, we need modifiers to
avoid ambiguity and misunderstanding.
As to whether
this matches any international practice, I believe it matches the practice of
the IETF; although they call it "rough consensus," it is their general
decision-making threshold ("We believe in rough consensus and running
code...."). So, at least in this corner of the world, we are not
alone.
Best
regards,
Greg
.
On Tue, Mar 24, 2015 at 3:35 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Dear GregSorry to be late in replying to your message.I regret that I disagree with definition of "consensus" as used by GNSOThat is an inappropriate invention which does not match any international practice due to the fact that even when a minority disagree to an issue under discussion it is no longer fit with the general understanding of the sense of " consensus" which simply describe a case in which while a minority disagree with a conclusion but they do not express any objection yo that conclusion i.e. That minority COULD LIVE with that conclusionRegardsKavouss
Sent from my iPhoneWhether we use modifiers before "consensus," we just need to have a common understanding of what is meant in a given situation when we say "consensus."Within the GNSO, we typically don't use a modifier before "consensus." We know what is meant by "consensus" in the GNSO, particularly in the PDP context. It's defined in Section 3.6 of the GNSO Working Group Guidelinesl: "Consensus - a position where only a small minority disagrees, but most agree" http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-13nov14-en.pdfWhen we get out of the GNSO (like Hobbits leaving the Shire), we know that not everyone else defines "consensus" that way, so we resort to modifiers, to make sure that we are clearly understood.If we are going to create new definitions of consensus for particular groups or processes, we need to be clear what they are, and make sure they can be identified in a way that distinguishes that "consensus" from GNSO "consensus" or GAC "consensus" or IETF "consensus." If we are going to borrow existing consensus definitions, we still need to make sure they can be identified and distinguished from other variant forms of "consensus." Modifiers seem like a straightforward way to do so. If there are other ways to do so, I am open to hearing about them. If certain kinds of modifiers create problems, we can avoid those modifiers. We could even use colors -- the modifiers just need to lead us to the right meaning, they don't need to have meaning in and of themselves.Greg ShatanOn Mon, Mar 23, 2015 at 9:02 AM, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
thanks to allI do nit believe that for every community we need to define modifier.I am not in favour of copying and definition from any communityWe should deal with each subject based on its merits snd in a case by case basisKavouss
Sent from my iPhoneHi,
In ICANN, we do have modifiers before Consensus. And varying definitions depending on which of the SOAC or processes we are talking about.
In GNSO PDP processes we talk about Full Consensus versus Consensus and that definiton of Consensus is not all that diffferent from the IETF defintion of rough consensus; though we often use polls instead of humming to help figure out how to continue the discussion toward consensus.
The GNSO definition is different from the GAC deffintion which I wont presume to define.
And in defining ICANN Consensus Policy, we have yet another definition which often depends on voting thresholds.
Personally I find it hard to talk about Consensus in ICANN without using modifiers of some sort.
As for an ICG definition of Consensus, that is beyond my pay grade to try and fathom.
avri
On 22-Mar-15 20:57, Kavouss Arasteh wrote:Dear All,Some relevant questions and good reply.I strongly oppose any adjustive before consensus whether it is " rough " or " Soft" or any thing else.We are CCWG and not IETF.In ICG that term even though proposed was abandonnnedPls kindly do not interpret " CONSENSUS"RegardsKavouss2015-03-22 19:18 GMT+01:00 Rahul Sharma <wisdom.stoic@gmail.com>:
Hi Arun,Just thinking aloud on the substance pointer raised - can multistakholder model be evolved in a manner that ensures proportional representation in communities, forums, structures and Board. When I say proportional, I mean proportional to Internet population of the country.
Regards,Rahul SharmaOn 22 March 2015 at 15:04, Arun Sukumar <arun.sukumar@nludelhi.ac.in> wrote:_______________________________________________Valerie D'Costa, an advisor to the CCWG, raised a couple of interesting and important questions on process and substance. I hope this is a faithful reproduction.On process:1. What should be the role of advisors? Should they offer advice on the basis of unanimity or "rough consensus", or just provide input independently?2. Should advisors restrict their role to responding to questions that have been flagged by the CCWG and routed through the chairs? Or should they/ can they flag issues they feel are important - weighed from their expertise.On substance:1. How is the accountability process taking stock of the evolving "global internet community", given that it is going to be driven by numbers from the developing world?2. Taking off from Q1, is the CCWG evaluating the future capacity of ICANN to be truly representative in the years to come?arun--
-Senior Fellow, Centre for Communication GovernanceNational Law University, New DelhiPh: +91-9871943272
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
This email has been checked for viruses by Avast antivirus software.
www.avast.com_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
--
Gregory S. Shatan ï Abelman Frayne & Schwab
Partner | IP | Technology | Media | Internet
666 Third Avenue | New York, NY 10017-5621
Direct 212-885-9253 | Main 212-949-9022
Fax 212-949-9190 | Cell 917-816-6428
ICANN-related: gregshatanipc@gmail.com
_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community