[CCWG-ACCT] Nomenclature re "Empowered Community": ICANN Board comments - Recommendation 3 - Fundamental Bylaws

Seun Ojedeji seun.ojedeji at gmail.com
Wed Jan 27 14:20:57 UTC 2016


Hello Kavous,

I don't understand what other study is required in this. The lawyers have
provided the clarification required(indicating theroles and the relevant
vehicles to exercise them) and if the 3 you mentioned have a different
opinion then they would have indicated it (I note that Greg already
acknowledged the response from legal).

I don't think there is need(neither is it economical) to further utilise
legal hours on this unless you specifically indicate what area is not clear
to you as a person (which is yet to be explained).

Regards
On 27 Jan 2016 14:58, "Kavouss Arasteh" <kavouss.arasteh at gmail.com> wrote:

> Dear Holly
> Dear  Rosemary
> Thank you very much for definition
> However, the problem that was raised was not the definition but the scope
> of responsibility and mandate
> There were three options
> View one; From Bruce
> View Two  FromGrec
> View three;From Jordan
> Please kindly carefully study these three and comment in favour of one or
> other or a combination of those three.
> The three designator came first from you in APRIL 2015
> tHE eMPOWERED cOMMUNITY CASE FROM THE ccwg discussion.
> I agree that the latter is more appropriate but the problem raised was
> different as described above.
> Either you wish to reply or not but please kindly reply to the question
> raised
> Regards
> Kavouss
>
>
>
> 2016-01-27 6:53 GMT+01:00 Seun Ojedeji <seun.ojedeji at gmail.com>:
>
>> Thanks a lot Rosemary that answers my question perfectly.
>>
>> Regards
>> On 27 Jan 2016 6:47 a.m., "Rosemary E. Fei" <rfei at adlercolvin.com> wrote:
>>
>>> Dear Sean and all:
>>>
>>>
>>>
>>> You are correct.  The power to designate (and correspondingly to remove)
>>> directors is one of the powers that will be given to the Empowered
>>> Community in the Bylaws.  You could also say that acting as ICANN’s “sole
>>> designator” is one of the Empowered Community’s roles in the proposed
>>> accountability structure, along with other roles and powers that will also
>>> be given to the Empowered Community in the Bylaws.
>>>
>>>
>>>
>>> The Empowered Community could be given the other powers (except the
>>> removal right) without giving it the power to designate directors – those
>>> other powers can legally be given to any third party, not just one that
>>> holds designator powers.
>>>
>>>
>>>
>>> I hope that answers your question.
>>>
>>>
>>>
>>> Rosemary
>>>
>>>
>>>
>>> *From:* Seun Ojedeji [mailto:seun.ojedeji at gmail.com]
>>> *Sent:* Tuesday, January 26, 2016 9:41 PM
>>> *To:* Holly Gregory
>>> *Cc:* Thomas Rickert; ACCT-Staff; ICANN-Adler; Sidley ICANN CCWG;
>>> accountability-cross-community at icann.org; León Felipe Sánchez Ambía;
>>> Mathieu Weill
>>> *Subject:* Re: [CCWG-ACCT] Nomenclature re "Empowered Community": ICANN
>>> Board comments - Recommendation 3 - Fundamental Bylaws
>>>
>>>
>>>
>>> Thank you Holly for the clarification. This has been my understanding as
>>> well.
>>>
>>> One other thing that I would appreciate if clarified is to know whether
>>> the "empowered community" is able to carry out the other roles (like
>>> approval of bylaws et all) because it is the designator or just because it
>>> is the unincorporated entity setup as the third party to perform those
>>> roles in the bylaw.
>>>
>>> In other words the unincorporated entity doubles as both the designator
>>> (with the power as described under California law) and the "enhanced
>>> community" (with the other powers as described in the bylaw).
>>>
>>> Regards
>>>
>>> On 26 Jan 2016 9:38 p.m., "Gregory, Holly" <holly.gregory at sidley.com>
>>> wrote:
>>>
>>> Dear CCWG-ACCT Co-Chairs, Members, Participants and Staff,
>>>
>>>
>>>
>>> We have been monitoring the recent discussion on the CCWG-ACCT listserv
>>> about the use of the terms “community”, “Empowered Community”, and “Sole
>>> Designator” in the draft Proposal, and we wish to share our understanding
>>> of these terms.
>>>
>>>
>>>
>>> We agree that the word “community” as used in the draft
>>> Proposal encompasses not only ICANN’s Board and all of its SOs and ACs and
>>> their individual members, but also those who participate in ICANN meetings
>>> and processes, as explained by Bruce Tonkin in his January 24 email.
>>>
>>>
>>>
>>> “Empowered Community” is the name to be given to an unincorporated
>>> association to be created in ICANN’s Bylaws.  This new entity has also been
>>> described as the “Sole Designator,” but that term -- which arose from the
>>> new entity’s function as ICANN’s sole designator -- does not adequately
>>> describe the other important roles for the new entity, which extend well
>>> beyond the rights given to designators by California corporate law.
>>> Therefore,  the “Empowered Community” is a more appropriate reference, and
>>> it has been used interchangeably with “Sole Designator” to date.
>>>
>>>
>>>
>>> As a global final edit, we recommend using “Empowered Community”
>>> consistently to refer to the new legal entity, after the first discussion
>>> of the sole designator concept.
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Hlly and Rosemary
>>>
>>>
>>>
>>>
>>>
>>> *HOLLY* *GREGORY*
>>> Partner
>>>
>>> *Sidley Austin LLP*
>>> +1 212 839 5853
>>> holly.gregory at sidley.com
>>>
>>>
>>>
>>> *From:* accountability-cross-community-bounces at icann.org [mailto:
>>> accountability-cross-community-bounces at icann.org] *On Behalf Of *Greg
>>> Shatan
>>> *Sent:* Monday, January 25, 2016 11:42 PM
>>> *To:* Jordan Carter
>>> *Cc:* accountability-cross-community at icann.org
>>> *Subject:* Re: [CCWG-ACCT] ICANN Board comments - Recommendation 3 -
>>> Fundamental Bylaws
>>>
>>>
>>>
>>> Recommendation 1 states:
>>>
>>>
>>>
>>> . The entity created using the Sole Designator model will be referred to
>>> as the “Empowered Community.”
>>>
>>> (Summary, Page 1, bullet point 3).
>>>
>>>
>>>
>>> In other words the Sole Designator is the Empowered Community, and vice
>>> versa.  You are introducing a dichotomy where none exists.
>>>
>>>
>>>
>>> Greg
>>>
>>>
>>>
>>> On Mon, Jan 25, 2016 at 5:39 PM, Jordan Carter <jordan at internetnz.net.nz>
>>> wrote:
>>>
>>> This isn't quite right - as far as I am aware the entity that is the
>>> Sole Designator will have the right to appoint and remove directors, and be
>>> the 'third party' that can approve changes to Icann fundamental bylaws or
>>> block changes to Icann standard bylaws.
>>>
>>>
>>>
>>> I'm not sure this is a revelation of any sort, or causes any confusion
>>> at all. These powers along with all the others will be set out in the
>>> bylaws, as has been the case all along. The only distinguishing feature is
>>> that the legislation in California gives designators the director rights,
>>> and gives the right of the articles / bylaws to include third party
>>> approvals.
>>>
>>>
>>>
>>> Even if people are confused about this, there is no problem in substance
>>> to resolve.
>>>
>>>
>>>
>>>
>>>
>>> Cheers
>>>
>>> Jordan
>>>
>>>
>>>
>>> On Monday, 25 January 2016, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
>>>
>>> Hi Greg,
>>>
>>> I don't think we are in disagreement in the substance of all these. It's
>>> just the naming we are in disagreement upon and I am still of the opinion
>>> that a designator only has the statutory power to remove/add board members.
>>>
>>> All other powers/process we have managed to put in the bylaw may need to
>>> be called/named something else as they are not made possible because of the
>>> designator but rather because of the fact that they are now written in the
>>> bylaw and the board normally would want to respect such a document.
>>>
>>> In anycase, unless there is any other change you think has been proposed
>>> other than giving inspection rights to the community (which you and I are
>>> in agreement) that affects the current proposal,  I don't see any reason to
>>> still consider this open as such.
>>>
>>> Regards
>>>
>>> On 24 Jan 2016 18:02, "Greg Shatan" <gregshatanipc at gmail.com> wrote:
>>>
>>> Seun,
>>>
>>>
>>>
>>> You misunderstand me.  The Designator does more than "enforce" powers.
>>> Under our proposal, the designator is also the vehicle for *exercising* a
>>> number of the powers (e.g., approving/rejecting bylaws).  The exercise of
>>> the new powers by the designator will be a much more common occurrence than
>>> the enforcement of those powers by removing directors.  I anticipate the
>>> latter will rarely (if ever) occur, though the fact it can occur is part of
>>> our accountability framework.  There are other reasons for the Board to
>>> comply with the community's exercise of its powers, aside from sheer terror
>>> at being removed.  For one thing, these powers are enshrined in the bylaws,
>>> and the Board (like any Board) will not take the prospect of violating our
>>> Bylaws lightly.
>>>
>>>
>>>
>>> We have had a tendency to overemphasize the enforcement end of things,
>>> and I think this is one more action in that vein.  Let's try to avoid
>>> that.  Just like our proposal is about far more than "enforcement," so is
>>> the Single Designator.
>>>
>>>
>>>
>>> So, no, your statement did not "close this particular item."  Rather, it
>>> demonstrates exactly why this item is not really closed.
>>>
>>>
>>>
>>> Greg
>>>
>>>
>>>
>>> On Sun, Jan 24, 2016 at 10:48 AM, Seun Ojedeji <seun.ojedeji at gmail.com>
>>> wrote:
>>>
>>> On 24 Jan 2016 16:15, "Greg Shatan" <gregshatanipc at gmail.com> wrote:
>>> >
>>> > I agree with the result the Board came to (at least in part), but not
>>> the reasoning.  Each SO or AC should have the right to inspect.  However,
>>> the role of the Designator is not merely to "add or remove Board members."
>>> The Designator plays a critical role in the exercise of several of the
>>> powers, in addition to its role in enforcing those powers via director
>>> removal.
>>> >
>>> SO: I guess Bruce was rightly mentioning the powers of the designator. I
>>> believe we we will only be getting those powers enforced as a result of the
>>> "add/remove" power of the designator.
>>>
>>> So in summary we don't get enforcement of the various powers because
>>> it's a role of the designator but on the basis that the designator may use
>>> its only statutory power, which is to add/remove board members.
>>>
>>> I generally agree with the result and would have even preferred that a
>>> threshold be required for inspection. However, on the basis that each SO/AC
>>> may need access to certain information to make informed/independent
>>> decisions, it makes sense to allow such right to each SO/AC.
>>>
>>> Hopefully this close this particular item.
>>>
>>> Regards
>>>
>>>   on Recommendation 1.
>>> >>
>>> >> Just to provide a little more context in response to questions on the
>>> list.
>>> >>
>>> >> The role of the designator is to add or remove Board directors.
>>>  This role is enforceable under California law.
>>> >>
>>> >> The inspection right is a right for the ACs and SOs.   An AC or SO
>>> can exercise this right independently of the legal entity that will be the
>>> sole designator.     If ICANN doesn't respond to an appropriate request
>>> from an SO or AC, it would be in breach of its bylaws.   The community can
>>> then use the IRP to get a binding decision.    In the unlikely event that
>>> the Board does not comply with the outcome of the IRP decision, then the
>>> designator has the power to remove Board members.
>>> >>
>>> >> In the bylaws we want to make sure that we don't confuse the role of
>>> the designator (add or remove Board members) with the various roles of the
>>> SO and ACs in the bylaws.   The bylaws are primarily enforced by the IRP,
>>> and then the designator (via removal of Board directors) if the IRP is not
>>> complied with, and then the courts if the decision of the designator is not
>>> complied with.   This is a clear escalation path that applies to all bylaws.
>>> >>
>>> >> Regards,
>>> >> Bruce Tonkin
>>> >>
>>> >> _______________________________________________
>>> >> Accountability-Cross-Community mailing list
>>> >> Accountability-Cross-Community at icann.org
>>> >> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=Od00qP2XTg0tXf_H69-T2w&r=1-1w8mU_eFprE2Nn9QnYf01XIV88MOwkXwHYEbF2Y_8&m=du2OD2nYZAU6l2XqEbv_LKsFVqwjXyksiXMKhZ3VDQk&s=v4A3ZwzM9FERJEYcFy5L5NNJvUY3v00O8niOIrVLuSg&e=>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Accountability-Cross-Community mailing list
>>> > Accountability-Cross-Community at icann.org
>>> > https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=Od00qP2XTg0tXf_H69-T2w&r=1-1w8mU_eFprE2Nn9QnYf01XIV88MOwkXwHYEbF2Y_8&m=du2OD2nYZAU6l2XqEbv_LKsFVqwjXyksiXMKhZ3VDQk&s=v4A3ZwzM9FERJEYcFy5L5NNJvUY3v00O8niOIrVLuSg&e=>
>>> >
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jordan Carter
>>> Chief Executive, InternetNZ
>>>
>>> +64-21-442-649 | jordan at internetnz.net.nz
>>>
>>> Sent on the run, apologies for brevity
>>>
>>>
>>>
>>>
>>>
>>>
>>> ****************************************************************************************************
>>> This e-mail is sent by a law firm and may contain information that is
>>> privileged or confidential.
>>> If you are not the intended recipient, please delete the e-mail and any
>>> attachments and notify us
>>> immediately.
>>>
>>>
>>> ****************************************************************************************************
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160127/ad4d5c33/attachment-0001.html>


More information about the Accountability-Cross-Community mailing list