<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Milton,<br>
<br>
Thank you kindly for forwarding this.<br>
<br>
It raises 2 points, I think. First, if the explanatory note says
something very different from the actual provision, then that should
be an easy fix. It should say that ICANN can use its regulatory
infrastructure to enforce contracts entered into between registrars
and other parties even if those contracts regulate content in some
manner. Leaving it as is can lead to problems down the road.<br>
<br>
But second of course is the question of whether it's appropriate for
ICANN to do so, or whether such disputes are best left to other
regulatory mechanisms. I can see arguments on either side, but much
of it would depend on the scope of the intended exception. Take the
relatively innocuous .bank example. Are we saying that ICANN can
prevent registrars from pulling the rug out from under regsitrants
through a contract change that affects content? (After 10 years of
operation, .bank removes the obligation on registrants to be
financial institutions). That might be ok, and doesn't really get
too deep into content issues. But are we also saying that ICANN can
adjudicate on Registrar-registrant contracts that affect content? Ie
can I complain to ICANN that my bitcoin.bank was refused? Can Bank
of America complain to it because my bitcoin.bank was accepted? Can
states have ICANN ban questionable payment intermediaries from .bank
because these states believe are funding rogue operations like
wikileaks? The latter seems potentially more problematic, because
then we're leaving it to ICANN arb panels to determine what a 'bank'
is, which is precisely what the prohibition on content is trying to
avoid.<br>
<br>
Not sure where this process is at, but I think it might be
worthwhile to get some clarification on these points.<br>
<br>
Best,<br>
Tamir<br>
<br>
<br>
<div class="moz-cite-prefix">On 8/20/2015 4:45 PM, Mueller, Milton L
wrote:<br>
</div>
<blockquote
cite="mid:BY2PR07MB58219D003DADC65C70C7372AC660@BY2PR07MB582.namprd07.prod.outlook.com"
type="cite">
<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]-->
<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
moz-do-not-send="true" 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 [<a class="moz-txt-link-freetext" href="mailto:mueller.syr.edu@gmail.com">mailto:mueller.syr.edu@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, August 20, 2015 3:34 PM<br>
<b>To:</b> Mueller, Milton L
<a class="moz-txt-link-rfc2396E" href="mailto:milton.mueller@pubpolicy.gatech.edu"><milton.mueller@pubpolicy.gatech.edu></a><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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:paul.rosenzweig@redbranchconsulting.com">paul.rosenzweig@redbranchconsulting.com</a>><br>
Cc: Milton L Mueller <<a moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>