Malcolm,

On Mon, Jan 18, 2016 at 5:48 AM, Malcolm Hutty <malcolm@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 ca​nnot 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

contract.

​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 contracting.
 

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?

No.

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

Bylaws.

​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

Greg.

​

--

        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@icann.org

https://mm.icann.org/mailman/listinfo/accountability-cross-community

_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community