<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Malcolm,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 18, 2016 at 5:48 AM, Malcolm Hutty <span dir="ltr">&lt;<a href="mailto:malcolm@linx.net" target="_blank">malcolm@linx.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 18/01/2016 01:54, Burr, Becky wrote:<br>
&gt;<br>
&gt; So if an applicant includes obligations in the application, it is ok for<br>
&gt; ICANN to enforce those commitments?<br>
<br>
</span>Not for purposes inconsistent with ICANN&#39;s Mission, no.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​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 &quot;bait-and-switch,&quot; stating a series of &quot;obligations&quot; in their application, only to drop them after the application is approved.</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">Frankly, I think it is entirely within ICANN&#39;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&#39;s commitments is inherently and fatally flawed.</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It shouldn&#39;t be surprising that ICANN cannot escape the limits of its<br>
Bylaws simply by placing something inconsistent with them into a<br>
contract. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​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. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If a Registry placed something in its application that would,<br>
if agreed, cause ICANN to act inconsistently with law that was<br>
applicable to ICANN, you wouldn&#39;t expect the contract to override<br>
applicable law. Nor should it override the governance of ICANN.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​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&#39;m not sure where that shift came from. </div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">I&#39;m not sure what &quot;real world&quot; 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 &quot;override the governance of ICANN&quot; seems to be meaningless (though it sure sounds bad).</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">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).</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
&gt; What¹s the principle - freedom of<br>
&gt; contract?<br>
<br>
</span>No.<br>
<br>
The Registry&#39;s freedom of contract is not limited, subject to applicable<br>
law. But ICANN&#39;s is freedom of contract is additionally limited by the<br>
Bylaws.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​We are talking about a single contract here -- between a registry operator and ICANN.  So if the registry&#39;s freedom of contract is not limited, perforce ICANN&#39;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&#39;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</div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">Greg.</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​</div><br>
--<br>
            Malcolm Hutty | tel: <a href="tel:%2B44%2020%207645%203523" value="+442076453523">+44 20 7645 3523</a><br>
   Head of Public Affairs | Read the LINX Public Affairs blog<br>
</span> London Internet Exchange | <a href="http://publicaffairs.linx.net/" rel="noreferrer" target="_blank">http://publicaffairs.linx.net/</a><br>
<span class="im HOEnZb"><br>
                 London Internet Exchange Ltd<br>
       Monument Place, 24 Monument Street, London EC3R 8AJ<br>
<br>
         Company Registered in England No. 3137929<br>
       Trinity Court, Trinity Street, Peterborough PE1 1DA<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
</div></div></blockquote></div><br></div></div>