<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">See Malcolm’s discussion below, which clarifies a lot.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">However, I do not agree that we can rely entirely on the proposed bylaw change (which is actually paragraph 187 in the proposal, not paragraph 188). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think we should make an issue of this in our comments and insist that the language “</span>"provided,<br>
of course, that the policy itself being enforced contractually is one that lies within ICANN's Mission"<a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> be included in the final proposal<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">--MM<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Milton Mueller [mailto:mueller.syr.edu@gmail.com]
<br>
<b>Sent:</b> Thursday, August 20, 2015 3:34 PM<br>
<b>To:</b> Mueller, Milton L <milton.mueller@pubpolicy.gatech.edu><br>
<b>Subject:</b> Fwd: FW: "Limitations on ICANN's contracting authority."<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">---------- Forwarded message ----------<br>
From: <b>Malcolm Hutty</b> <<a href="mailto:malcolm@linx.net">malcolm@linx.net</a>><br>
Date: Wed, Aug 19, 2015 at 2:04 PM<br>
Subject: Re: FW: "Limitations on ICANN's contracting authority."<br>
To: Paul Rosenzweig <<a href="mailto:paul.rosenzweig@redbranchconsulting.com">paul.rosenzweig@redbranchconsulting.com</a>><br>
Cc: Milton L Mueller <<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>><br>
<br>
<br>
<br>
<br>
On 19/08/2015 17:50, Paul Rosenzweig wrote:<br>
><br>
> I’ve exceeded my understanding of this issue – do you have anything to<br>
> add that might assist in the discussion.<br>
<br>
I can explain the history of this text, if you like.<br>
<br>
<br>
As Milton says, the language<br>
"Without in any way limiting the foregoing absolute<br>
prohibition, ICANN shall not engage in or use its powers to<br>
attempt the regulation of services that use the Internet's<br>
unique identifiers, or the content that they carry or<br>
provide."<br>
<br>
was inserted precisely to make clear that ICANN could not use its<br>
contracting power with Registries and Registrars as a lever to engage in<br>
general regulation of Internet content and services.<br>
<br>
The concern that ICANN might one day try to do this, and should be<br>
restrained from doing it, was recorded in Stress Test #23.<br>
<br>
When this proposal was put out for the First Public Comment, the CCWG<br>
received input from some commercial stakeholders that expressed concern<br>
that this would interfere with the existing Contract Compliance<br>
programme. From memory, the stakeholders who raised this concern were<br>
members of the Business and Intelletual Property constituencies, and the<br>
Business Constituency itself supported this intervention.<br>
<br>
This prompted a discussion within the working party: what exactly were<br>
these stakeholders worried about? Did this intervention mean that they<br>
wanted ICANN to be able to regulate content and services generally?<br>
<br>
Steve Delbianco, on behalf of the Business Constituency, offered the<br>
example of .bank: as part of the creation of that TLD, it was proposed<br>
by the prospective registry that only registered banks would be allowed<br>
to register within that domain. This would form part of the Registry<br>
agreement, and the successful Registry would not be allowed to change<br>
their policy later and turn .bank into a free-for-all open registration<br>
policy domain. Should they try to do so, ICANN would enforce the<br>
Registry agreement, even though the restriction on registration in .bak<br>
originated not in an ICANN PDP policy, but in the voluntary proposal of<br>
the gTLD applicant. Steve said that the Business Constituency wanted to<br>
ensure that this enforcement would continue, and that the abovementioned<br>
text in the Bylaws should not prevent ICANN from stopping the Registry<br>
from changing its policy on registration after the TLD's initial delegation.<br>
<br>
(Some of) those that had proposed the abovementioned text responded that<br>
this was not intended to interfere with that behaviour by ICANN. They<br>
drew a distinction between using the Registry contract to enforce the<br>
terms on which the initial delegation was made, and introducing new<br>
policies intended to regulate the behaviour of end-user registrants.<br>
They (we) argued that defining the purpose of each gTLD, and creating<br>
policies so that those gTLDs achieved their purpose, was clearly within<br>
the scope of ICANN's proper Mission. Accordingly, enforcing those<br>
policies through ICANN's contracting power remains within ICANN's<br>
authorised powers. By contrast, if it were to create new policies to<br>
which registrants must aide, not for the purpose of defining the scope<br>
of a given domain, but with the intention of controlling user behaviour<br>
generally - that is, justified not by the need to ensure an open,<br>
interoperable, reliable and secure DNS but by its conception of the<br>
public interest more broadly, then that would indeed be outside ICANN's<br>
Mission and this clause would indeed restain ICANN from using its<br>
contracting authority in that manner.<br>
<br>
Accordingly, we argued, the concern raised by the Business Constituency<br>
was unwarranted: this clause would not act as a restain on ICANN's<br>
contracting authority as a means of enforcing ICANN's policy - provided,<br>
of course, that the policy itself is one that lies within ICANN's<br>
Mission. It was agreed that a note to this effect would be made in the<br>
Second Public Comment draft, and that this would be given as the reason<br>
why we had not changed the text to which some stakeholders objected.<br>
<br>
That is how paragraph 158 came about.<br>
<br>
In my view the omission of this last qualification in paragraph 158 of<br>
the public comment is indeed confusing (i.e. the omission of "provided,<br>
of course, that the policy itself being enforced contractually is one<br>
that lies within ICANN's Mission"). I can see how, lacking this<br>
qualification, the paragraph gave rise to Milton's "WTF moment".<br>
However, this is only explanatory text: the draft bylaw language is<br>
paragraph 188. The only real concern I would have would be if the<br>
lawyers, working from paragraph 158, sought to redraft paragraph 188.<br>
<br>
I hope that helps,<br>
<br>
Kind Regards,<br>
<br>
Malcolm.<br>
<br>
<span class="hoenzb"><span style="color:#888888">--</span></span><span style="color:#888888"><br>
<span class="hoenzb"> Malcolm Hutty | tel: <a href="tel:%2B44%2020%207645%203523">
+44 20 7645 3523</a></span><br>
<span class="hoenzb"> Head of Public Affairs | Read the LINX Public Affairs blog</span><br>
<span class="hoenzb"> London Internet Exchange | <a href="http://publicaffairs.linx.net/" target="_blank">
http://publicaffairs.linx.net/</a></span><br>
<br>
<span class="hoenzb"> London Internet Exchange Ltd</span><br>
<span class="hoenzb"> 21-27 St Thomas Street, London SE1 9RY</span><br>
<br>
<span class="hoenzb"> Company Registered in England No. 3137929</span><br>
<span class="hoenzb"> Trinity Court, Trinity Street, Peterborough PE1 1DA</span><br>
<br>
</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>