<html>
<body>
I strongly support Greg's position. This is exactly the type of thing
that the ALAC was concerned about when we raised a general caution on the
mission changes being contemplated and the concern that one of ICANN's
prime responsibilities, being a good custodian of the gTLD space, could
be subverted.<br><br>
Alan<br><br>
At 18/01/2016 10:32 PM, Greg Shatan wrote:<br>
<blockquote type=cite class=cite cite="">Malcolm,<br><br>
On Mon, Jan 18, 2016 at 5:48 AM, Malcolm Hutty
&lt;<a href="mailto:malcolm@linx.net">malcolm@linx.net</a>&gt;
wrote:<br>

<dl><br>

<dd>On 18/01/2016 01:54, Burr, Becky wrote:<br>

<dd>&gt;<br>

<dd>&gt; So if an applicant includes obligations in the application, it
is ok for<br>

<dd>&gt; ICANN to enforce those commitments?<br><br>

<dd>Not for purposes inconsistent with ICANN's Mission, no.<br><br>

</dl><br>
​If (in your view) ICANN ca​nnot enforce obligations that an
applicant includes in its application, who can enforce those
obligations?&nbsp; If no one can enforce these obligations, then how can
they even be called obligations?&nbsp; What keeps applicants from pulling
a &quot;bait-and-switch,&quot; stating a series of
&quot;obligations&quot; in their application, only to drop them after the
application is approved.<br><br>
Frankly, I think it is entirely within ICANN's mission to enforce
obligations set out in applications.&nbsp; 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.&nbsp; An
interpretation that says that ICANN can only enforce some of the
applicant's commitments is inherently and fatally flawed.<br>

<dl><br>

<dd>It shouldn't be surprising that ICANN cannot escape the limits of
its<br>

<dd>Bylaws simply by placing something inconsistent with them into a<br>

<dd>contract. <br><br>

</dl><br>
​However, this is not what Becky postulated.&nbsp; She postulated
obligations ​placed in the agreement by the registry operator, not
obligations placed in the agreement by ICANN.&nbsp; 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.&nbsp;
This concept is at the very heart of contracting. <br>
&nbsp;<br>

<dl>
<dd>If a Registry placed something in its application that would,<br>

<dd>if agreed, cause ICANN to act inconsistently with law that was<br>

<dd>applicable to ICANN, you wouldn't expect the contract to
override<br>

<dd>applicable law. Nor should it override the governance of
ICANN.<br><br>

</dl><br>
​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. <br><br>
I'm not sure what &quot;real world&quot; examples of this there would be
-- where a registry puts new obligations on ICANN.&nbsp; I think this is
so rare as to be essentially not worth considering.&nbsp; As such, the
idea that a registry operator could place something in an application
that would &quot;override the governance of ICANN&quot; seems to be
meaningless (though it sure sounds bad).<br><br>
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.&nbsp; 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).<br>

<dl><br>

<dd>&gt; What¹s the principle - freedom of<br>

<dd>&gt; contract?<br><br>

<dd>No.<br><br>

<dd>The Registry's freedom of contract is not limited, subject to
applicable<br>

<dd>law. But ICANN's is freedom of contract is additionally limited by
the<br>

<dd>Bylaws.<br>
<br>

</dl><br>
​We are talking about a single contract here -- between a registry
operator and ICANN.&nbsp; So if the registry's freedom of contract is not
limited, perforce ICANN's ability to enforce that same contract is not
limited either.​&nbsp;&nbsp; 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.&nbsp; In that event, these are merely
gratuitous statements&nbsp; without the force of contract, and thus
essentially worthless.&nbsp; Such a result makes no sense<br><br>
Greg.<br>

<dl>
<dd>​<br><br>

<dd>--<br>

<dd>&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;   Malcolm Hutty | tel:
<a href="tel:%2B44%2020%207645%203523">+44 20 7645 3523</a><br>

<dd>&nbsp;&nbsp; Head of Public Affairs | Read the LINX Public Affairs
blog<br>

<dd>&nbsp;London Internet Exchange |
<a href="http://publicaffairs.linx.net/">
http://publicaffairs.linx.net/</a><br><br>

<dd>&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp; London
Internet Exchange Ltd<br>

<dd>&nbsp;  &nbsp;&nbsp;&nbsp; Monument Place, 24 Monument Street, London
EC3R 8AJ<br><br>

<dd>&nbsp;  &nbsp;&nbsp;  &nbsp; Company Registered in England No.
3137929<br>

<dd>&nbsp;  &nbsp;&nbsp;&nbsp; Trinity Court, Trinity Street,
Peterborough PE1 1DA<br><br>
<br>

<dd>_______________________________________________<br>

<dd>Accountability-Cross-Community mailing list<br>

<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>

<dd>
<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>

</dl><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>