<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Bruce,</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 7:41 PM, Bruce Tonkin <span dir="ltr">&lt;<a href="mailto:Bruce.Tonkin@melbourneit.com.au" target="_blank">Bruce.Tonkin@melbourneit.com.au</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Greg,<br>
<span class=""><br>
&gt;&gt; ICANN shall not impose regulations on services (i.e., any software process that accepts connections for the Internet) that use the Internet&#39;s unique identifiers, or the content that such services carry or provide.<br>
<br>
</span>I think as Andrew Sullivan pointed out - I would consider most of the processes that registries and registries use to register domain names as services that use the Internet&#39;s unique identifiers.   That is a very general statement.<br>
<br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​GS: Bruce, if you are talking about the software processes that underlie the websites and email systems used by registries and registrars, I believe that&#39;s correct.  But what do you believe is the impact of that?  Do you think that what ICANN currently does or hopes to do would constitute &quot;imposing regulations on&quot; these software processes?    ​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;&gt;  • &quot;Some existing registry agreements may be out of compliance with ICANN&#39;s responsibilities if this change is adopted&quot;: I, for one, had that concern about the language that appears in the November 15 formal update.  I believe that the current language actually resolves, rather than causes this problem.  If the Board disagrees, I think a far more specific discussion is needed -- one that clearly identifies the language (or change/deletion of language) that causes the Board&#39;s concern, and which provisions in which existing registry agreements might be out of compliance.  Dealing in abstract concerns is not particularly helpful.  As far as I know, it was not the intention of any of the drafters to nullify or expose to challenge any provisions of any registry or registrar agreements.  Of course, this should be clarified, and if the Board has identified a &quot;land mine&quot; in the language that has been planted in anticipation of a later attempt to challenge provisions of existing agreements, that land mind should be extracted and de-fused.<br>
<br>
I have asked the legal staff at ICANN to provide some examples.<br>
<br>
Here is one that occurs to me though.   The current new gTLD registry agreements in Specification 5   (<a href="http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm" rel="noreferrer" target="_blank">http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm</a>) have a provision that restrict the ability of a registrant to register a country or territory name, or names relating to the International Olympic Committee; International Red Cross and Red Crescent Movement.<br>
<br>
These are examples of content in domain names that have some restrictions.   There are no technical or security reasons for such restrictions.   The restrictions have been put in place on the basis of &quot;public policy&quot; advice from the GAC.<br>
<br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​GS: Bruce, I think you have (re)surfaced a couple of potentially significant interpretive errors in looking at these provisions.  <b>First, domain names are <u>not</u> &quot;content.&quot;</b>  If we start treating domain names as content, that opens up a whole Pandora&#39;s Box.  But even if we avoid that larger issue, I think it is clear from the provision that domain names are not &quot;content&quot; for the purposes of this provision.  Domain names are clearly among the &quot;Internet&#39;s unique identifiers&quot; in this provision, so they can&#39;t also be the &quot;content&quot; that is &quot;carried&quot; or &quot;provided&quot; by the &quot;service.&quot;  I think that if we could expressly associate &quot;content&quot; with &quot;datagram(s)&quot; this would be clearer.  Alan Greenberg has raised this &quot;domain names are not content&quot; (or perhaps more restrictively, &quot;domain names are not &quot;content&quot;&quot; here) issue more than once, with unclear results.  This needs to be clarified, at least in connection with this provision</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
&gt;&gt;  • The use of the word regulate (which occurs on both the November 15 and November 17 language, so I assume the Board&#39;s concern covers both versions).<br>
<br>
Yes - this is mostly a concern from ICANN legal staff.   My understanding is that &quot;regulate&quot; has a specific meaning in the US law context and applies to the role of governments.   I think it is possible to find another term that aligns with our practices.   Ie ICANN develops policies, and incorporates those policies in  registry, registrar and registrant (through their agreements with registrars) agreements.   ICANN has a compliance team to ensure that registries, registrars, and registrants comply with those policies.     An alternative formulation of the text could therefore be:  ICANN does not impose &quot;contractual terms&quot; ...<br>
<br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​GS: Bruce, this is the second potentially significant interpretive error you surface.  While &quot;regulation&quot; is most often used to describe governmental/public entity action, it is not limited to that sphere.  But if we look at U.S. government regulation as a guide, regulations are rules and standards that are unilaterally imposed by the government in order to implement laws (e.g., the Americans with Disabilities Act is a law, but there are government-issued regulations that specify what must be done to comply with that law).  That should be the definition that is carried over into this provision.  I think it would be wrong and dangerous to consider the policies developed by ICANN through the various policy development processes as a form of &quot;regulation.&quot;  Similarly, it would be wrong and dangerous to consider the registry and registrar agreements to be forms of regulation, especially given how they are developed.  Contractual terms are by definition not &quot;imposed.&quot;  They are agreed to (unless you are talking about &quot;contracts of adhesion,&quot; which is a very narrow category of forced contract).  <b>Thus, I would very strongly reject the idea that &quot;ICANN does not impose contractual terms&quot; is in any way an alternative statement of &quot;ICANN does not impose regulations.&quot; </b> If we go down that road, then virtually everything ICANN does is regulation, and that is clearly not the intent of this text.  That said, if there is any danger that one will be interpreted as synonymous with the other, that needs to be clearly and explicitly stopped.  If some as well-informed as yourself can stumble into that mistake, then I think this is a clear and present danger, and one that must be resolved before this provision is finalized.</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;&gt;  • The definition of services: This is discussed above and in my prior email, so I won&#39;t reiterate here.  While it could be improved. but it clearly points in the right direction and away from the wrong one -- and that is critical.<br>
<br>
The Board certainly agrees with the intent of the language.   It just needs refinement.   Probably the best the group can do is to clearly define the intent, and allow time for appropriate language to be developed.<br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">​</div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Part of clarifying the intent is to give clear examples of what ICANN should not be doing as part of its role.<br>
<br>
Regards,<br>
Bruce Tonkin<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div class="gmail_default" style="font-family:verdana,sans-serif">​Greg​</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
_______________________________________________<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>