<html>
<body>
Thanks Holly and Rosemary,<br>
e<br>
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).<br><br>
Alan<br><br>
At 26/01/2016 03:37 PM, Gregory, Holly wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">Dear CCWG-ACCT Co-Chairs,
Members, Participants and Staff, <br>
<br>
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.<br>
<br>
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.<br>
<br>
“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.
<br>
<br>
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. <br>
<br>
Kind regards, <br>
Hlly and Rosemary<br>
<br>
<br>
<b>HOLLY</b> <b>GREGORY</b><br>
Partner<br><br>
<b>Sidley Austin LLP<br>
</b>+1 212 839 5853<br>
<a href="mailto:holly.gregory@sidley.com">holly.gregory@sidley.com</a><br>
<br>
<b>From:</b> accountability-cross-community-bounces@icann.org
[<a href="mailto:accountability-cross-community-bounces@icann.org" eudora="autourl">
mailto:accountability-cross-community-bounces@icann.org</a>] <b>On Behalf
Of </b>Greg Shatan<br>
<b>Sent:</b> Monday, January 25, 2016 11:42 PM<br>
<b>To:</b> Jordan Carter<br>
<b>Cc:</b> accountability-cross-community@icann.org<br>
<b>Subject:</b> Re: [CCWG-ACCT] ICANN Board comments - Recommendation 3 -
Fundamental Bylaws<br>
<br>
Recommendation 1 states:<br>
<br>
. The entity created using the Sole Designator model will be referred to
as the “Empowered Community.”<br>
(Summary, Page 1, bullet point 3).<br>
<br>
In other words the Sole Designator is the Empowered Community, and vice
versa. You are introducing a dichotomy where none exists.<br>
<br>
Greg<br>
<br>
On Mon, Jan 25, 2016 at 5:39 PM, Jordan Carter
<<a href="mailto:jordan@internetnz.net.nz">jordan@internetnz.net.nz</a>
> wrote:<br>
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.<br>
<br>
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.<br>
<br>
Even if people are confused about this, there is no problem in substance
to resolve.<br>
<br>
<br>
Cheers<br>
Jordan <br><br>
<br>
On Monday, 25 January 2016, Seun Ojedeji
<<a href="mailto:seun.ojedeji@gmail.com">seun.ojedeji@gmail.com</a>
> wrote:<br><br>
Hi Greg,<br><br>
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. <br><br>
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.<br><br>
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.<br><br>
Regards<br>
On 24 Jan 2016 18:02, "Greg Shatan"
<<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
> wrote:<br>
Seun,<br>
<br>
You misunderstand me. The Designator does more than
"enforce" powers. Under our proposal, the designator is
also the vehicle for <u>exercising</u> 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.<br>
<br>
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.<br>
<br>
So, no, your statement did not "close this particular
item." Rather, it demonstrates exactly why this item is not
really closed.<br>
<br>
Greg<br>
<br>
On Sun, Jan 24, 2016 at 10:48 AM, Seun Ojedeji
<<a href="mailto:seun.ojedeji@gmail.com">seun.ojedeji@gmail.com</a>
> wrote:<br><br>
On 24 Jan 2016 16:15, "Greg Shatan"
<<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
> wrote:<br>
><br>
> 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. <br>
><br>
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. <br><br>
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.<br><br>
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.<br><br>
Hopefully this close this particular item.<br><br>
Regards<br><br>
on Recommendation 1.<br>
>><br>
>> Just to provide a little more context in response to questions
on the list.<br>
>><br>
>> The role of the designator is to add or remove Board
directors. This role is enforceable under California
law.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> Regards,<br>
>> Bruce Tonkin<br>
>><br>
>> _______________________________________________<br>
>> Accountability-Cross-Community mailing list<br>
>>
<a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
>>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Accountability-Cross-Community mailing list<br>
>
<a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br>
><br>
<br><br>
<br>
-- <br>
Jordan Carter<br>
Chief Executive, InternetNZ<br><br>
<a href="tel:%2B64-21-442-649">+64-21-442-649</a> |
<a href="mailto:jordan@internetnz.net.nz">jordan@internetnz.net.nz</a><br>
<br>
Sent on the run, apologies for brevity<br>
<br><br>
<br><br>
****************************************************************************************************<br>
This e-mail is sent by a law firm and may contain information that is
privileged or confidential.<br>
If you are not the intended recipient, please delete the e-mail and any
attachments and notify us<br>
immediately.<br><br>
****************************************************************************************************<br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
Accountability-Cross-Community@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote></body>
</html>