[CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion
gregshatanipc at gmail.com
Tue Jan 19 03:32:25 UTC 2016
On Mon, Jan 18, 2016 at 5:48 AM, Malcolm Hutty <malcolm at linx.net> wrote:
> On 18/01/2016 01:54, Burr, Becky wrote:
> > So if an applicant includes obligations in the application, it is ok for
> > ICANN to enforce those commitments?
> Not for purposes inconsistent with ICANN's Mission, no.
If (in your view) ICANN cannot enforce obligations that an applicant
includes in its application, who can enforce those obligations? If no one
can enforce these obligations, then how can they even be called
obligations? What keeps applicants from pulling a "bait-and-switch,"
stating a series of "obligations" in their application, only to drop them
after the application is approved.
Frankly, I think it is entirely within ICANN's mission to enforce
obligations set out in applications. ICANN is the entity running the
application process, and the credibility of the enterprise rests in part on
holding applicants/registry operators to their promises. An interpretation
that says that ICANN can only enforce some of the applicant's commitments
is inherently and fatally flawed.
> It shouldn't be surprising that ICANN cannot escape the limits of its
> Bylaws simply by placing something inconsistent with them into a
However, this is not what Becky postulated. She postulated obligations
placed in the agreement by the registry operator, not obligations placed
in the agreement by ICANN. Once these obligations are placed in a contract
between two parties, the obligations made by one party are enforceable by
the other, and vice versa. This concept is at the very heart of
> If a Registry placed something in its application that would,
> if agreed, cause ICANN to act inconsistently with law that was
> applicable to ICANN, you wouldn't expect the contract to override
> applicable law. Nor should it override the governance of ICANN.
This answer only muddies the waters. We seem to have shifted somehow from
potential obligations placed on the applicant to potential obligations
placed on ICANN in the application that would then become part of the RA.
I'm not sure where that shift came from.
I'm not sure what "real world" examples of this there would be -- where a
registry puts new obligations on ICANN. I think this is so rare as to be
essentially not worth considering. As such, the idea that a registry
operator could place something in an application that would "override the
governance of ICANN" seems to be meaningless (though it sure sounds bad).
Of course, if an application did require ICANN to break the law, I would
expect that application to be rejected or modified, rather than having that
obligation placed into an agreement. Indeed, if it were to ever get that
far, a contractual provision that violated the law would be void as against
public policy (at least under US law).
> > What¹s the principle - freedom of
> > contract?
> The Registry's freedom of contract is not limited, subject to applicable
> law. But ICANN's is freedom of contract is additionally limited by the
We are talking about a single contract here -- between a registry operator
and ICANN. So if the registry's freedom of contract is not limited,
perforce ICANN's ability to enforce that same contract is not limited
either. To say that a registry can agree to perform certain actions in a
contract with ICANN, but that ICANN can't enforce the contract to ensure
that the registry performs those action is essentially saying that the
contract is not a contract and the obligations are not obligations. In
that event, these are merely gratuitous statements without the force of
contract, and thus essentially worthless. Such a result makes no sense
> Malcolm Hutty | tel: +44 20 7645 3523
> Head of Public Affairs | Read the LINX Public Affairs blog
> London Internet Exchange | http://publicaffairs.linx.net/
> London Internet Exchange Ltd
> Monument Place, 24 Monument Street, London EC3R 8AJ
> Company Registered in England No. 3137929
> Trinity Court, Trinity Street, Peterborough PE1 1DA
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Accountability-Cross-Community