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

Alan Greenberg alan.greenberg at mcgill.ca
Wed Jan 27 05:45:42 UTC 2016


Thanks Holly and Rosemary,
e
Somewhere in the archives I wrote a note 
suggesting that we reserve the term Sole 
Designator just for the Board member powers and 
that we not use it to describe the overall 
community powers. In fact, we could have TWO UAs, 
one for enforcing the community powers, and one 
for the Sole Designator, but for simplicity, we 
are using the Empowered Community UA (which is a superset of the SD).

Alan

At 26/01/2016 03:37 PM, Gregory, Holly 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
><mailto:holly.gregory at sidley.com>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 
><<mailto:jordan at internetnz.net.nz>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 
><<mailto:seun.ojedeji at gmail.com>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" 
><<mailto:gregshatanipc at gmail.com>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 
><<mailto:seun.ojedeji at gmail.com>seun.ojedeji at gmail.com> wrote:
>
>On 24 Jan 2016 16:15, "Greg Shatan" 
><<mailto:gregshatanipc at gmail.com>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
> >> 
> <mailto:Accountability-Cross-Community at icann.org>Accountability-Cross-Community at icann.org
> >> https://mm.icann.org/mailman/listinfo/accountability-cross-community
> >
> >
> >
> > _______________________________________________
> > Accountability-Cross-Community mailing list
> > 
> <mailto:Accountability-Cross-Community at icann.org>Accountability-Cross-Community at icann.org
> > https://mm.icann.org/mailman/listinfo/accountability-cross-community
> >
>
>
>
>--
>Jordan Carter
>Chief Executive, InternetNZ
>
><tel:%2B64-21-442-649>+64-21-442-649 | 
><mailto:jordan at internetnz.net.nz>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160127/bb133071/attachment-0001.html>


More information about the Accountability-Cross-Community mailing list