[CCWG-ACCT] Meeting with CCWG Advisors

Tue Mar 24 18:57:41 UTC 2015

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

From: Greg Shatan 
Sent: Tuesday, March 24, 2015 6:18 PM
To: Kavouss Arasteh 
Cc: accountability-cross-community at icann.org 
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 at gmail.com> wrote:

  Dear Greg
  Sorry to be late in replying to your message.
  I regret that I disagree with definition of "consensus" as used by GNSO
  That 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 conclusion
  Regards
  Kavouss

  Sent from my iPhone

  On 23 Mar 2015, at 22:45, Greg Shatan <gregshatanipc at gmail.com> wrote:

    Whether 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.pdf

    When 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 Shatan

    On Mon, Mar 23, 2015 at 9:02 AM, Kavouss Arasteh <kavouss.arasteh at gmail.com> wrote:

      thanks to all
      I do nit believe that for every community we need to define modifier.
      I am not in favour of copying and definition from any community
      We should deal with each subject based on its merits snd in a case by case basis
      Kavouss

      Sent from my iPhone

      On 22 Mar 2015, at 21:52, Avri Doria <avri at acm.org> wrote:

        Hi,

        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 abandonnned
          Pls kindly do not interpret  " CONSENSUS" 
          Regards
          Kavouss 

          2015-03-22 19:18 GMT+01:00 Rahul Sharma <wisdom.stoic at 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 Sharma

            On 22 March 2015 at 15:04, Arun Sukumar <arun.sukumar at 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

              -- 

              - 
              @arunmsukumar
              Senior Fellow, Centre for Communication Governance
              National Law University, New Delhi
              Ph: +91-9871943272

              _______________________________________________
              Accountability-Cross-Community mailing list
              Accountability-Cross-Community at icann.org
              https://mm.icann.org/mailman/listinfo/accountability-cross-community

            _______________________________________________
            Accountability-Cross-Community mailing list
            Accountability-Cross-Community at icann.org
            https://mm.icann.org/mailman/listinfo/accountability-cross-community

_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community at 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 at icann.org
        https://mm.icann.org/mailman/listinfo/accountability-cross-community

      _______________________________________________
      Accountability-Cross-Community mailing list
      Accountability-Cross-Community at 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

    gsshatan at lawabel.com

    ICANN-related: gregshatanipc at gmail.com

    www.lawabel.com

--------------------------------------------------------------------------------
_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community at icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150324/2b89e38d/attachment.html>