[CCWG-ACCT] ICANN Board comments - Recommendation 3 - Fundamental Bylaws

[Greg Shatan]

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
> >
> >
> >
> > _______________________________________________
> > 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/20160124/b28816ca/attachment.html>