<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 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.EmailStyle17
{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;}
/* List Definitions */
@list l0
{mso-list-id:1874533756;
mso-list-template-ids:-2006407164;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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">Greg:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Alas, it is not an accurate formulation. It is far too specific, invokes technologies that may be superseded or not conform to future architectures, etc. What
does it mean to regulate a “web server” anyway? Configure its technology? ICANN could do all kinds of things we don’t want it to do without doing that.
<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">There is nothing wrong with the concept of “services” as the thing that we don’t want ICANN to regulate, with the obvious exception of domain name registry and
registrar services. <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">--MM<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<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"> accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org]
<b>On Behalf Of </b>Greg Shatan<br>
<b>Sent:</b> Wednesday, November 11, 2015 12:33 PM<br>
<b>To:</b> Malcolm Hutty <malcolm@linx.net><br>
<b>Cc:</b> Accountability Community <accountability-cross-community@icann.org>; ACCT-Staff <acct-staff@icann.org><br>
<b>Subject:</b> Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">Based on Malcolm's explanations, here's a possible alternate formulation:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Verdana",sans-serif">"ICANN shall not regulate web servers, mail servers and other devices that are located using the Internet's unique identifiers, or the content they carry."</span></b><span style="font-family:"Verdana",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span style="font-family:"Verdana",sans-serif">This clarifies what was meant by "service" by using more concrete terminology (It's clear that "service" isn't working here, just based on the limited responses on this thread.)<o:p></o:p></span></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span style="font-family:"Verdana",sans-serif">It also clarifies what is meant by "use" in a way that I think is more clear than an earlier offering by Malcolm intended to do the same thing (the "reachability" proposal)<o:p></o:p></span></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span style="font-family:"Verdana",sans-serif"> I removed the word "provide," since it's not entirely clear to me what is being referred to as the "content" "provided" by an Internet-connected device. I thought about substituting "generate," but if we are
talking about "device-generated" data, then there may be some need for "regulation" (or at least "standardization") by ICANN (and IETF) in order to maintain data flow (and thus SSR). Also, I think the current draft formulation, which essentially refers to
regulating "services" that "provide" "content", is the basis for much of the misunderstanding we have about the meaning of this proposal, and thus should be avoided.<o:p></o:p></span></li></ul>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">I'm not saying I "agree" with this formulation, but I think it's a clearer statement (and I support my changes in that regard). If there are those that fundamentally disagree that this is
an accurate statement of the current proposal, it's important to know that.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">Greg<o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Nov 11, 2015 at 11:14 AM, Malcolm Hutty <<a href="mailto:malcolm@linx.net" target="_blank">malcolm@linx.net</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
<br>
On 11/11/2015 15:45, Silver, Bradley wrote:<br>
> Malcolm, even if ICANN's ability to enforce agreements with<br>
> contracted parties is enshrined in the language below, how would we<br>
> address an argument that the prohibition against regulation precludes<br>
> such contracts having a downstream effect on non-contracted parties<br>
> (and content)? As Becky alludes, the URDP and WHOIS requirements are<br>
> examples of those downstream effects.<br>
<br>
When answering such a question, it's very important to analyse the text<br>
itself, not various loose paraphrasings of the text we have all been<br>
using in more casual conversation. While "the prohibition against<br>
regulation" and "precludes contracts having a downstream effect on<br>
non-contracted parties" are broad descriptions of the kind of thing this<br>
clause is intended to prohibit, they are not sufficiently precise to<br>
give an accurate answer to your question. To answer it, we have to look<br>
at the precise wording itself.<br>
<br>
The text as proposed only says that ICANN may not:<br>
<br>
"regulate of services that use the Internet's unique identifiers [to<br>
enable or facilitate their reachability over the Internet], nor shall it<br>
regulate the content that those services carry or provide"<br>
<br>
When we analyse this closely, we will see that this prohibition is not<br>
as broad as the paraphrasing.<br>
<br>
So let's split this into parts:<br>
<br>
1. Who does this apply to?<br>
"The services that use the Internet's unique identifiers to enable or<br>
facilitate their reachability over the Internet".<br>
<br>
These services are things like web servers, mail servers and so forth.<br>
Services are a technical thing. They're not companies: companies are the<br>
*providers* of such services.<br>
<br>
2. What is ICANN prohibited from doing?<br>
a) regulating those services; or<br>
b) regulating the content that those services carry or provide<br>
<br>
So ICANN is, by this text, precluded from regulating the services<br>
themselves, but is not explicitly prohibited from regulating the<br>
providers of those services in ways that do not entail the regulation of<br>
those services (although it will have to find authorisation for doing<br>
that elsewhere in its mission)*.<br>
<br>
Now, let's apply that to WHOIS requirements.<br>
<br>
"WHOIS requirements", loosely stated, require registrants to disclose<br>
certain information for publication in the WHOIS system.<br>
<br>
You could argue about whether that's a form of "regulation" of<br>
registrants, but even if it is, it's not regulation of a web service or<br>
a mail service. It doesn't say "the web service must do this" or "the<br>
web service must not do that". Web services don't register domains;<br>
companies and individuals do.<br>
<br>
Nor is this regulation of the content that those services carry or<br>
provide. The things you do when you register a domain are not web<br>
content, they're actions taken by the registrant. The WHOIS requirement<br>
says things like "If ACME corporation wishes to register ACME.com, it<br>
must disclose its name and address for WHOIS publication". Nothing in<br>
that is regulation of what appears on ACME's web site, in any way.<br>
<br>
It would be up to someone who wanted to challenge the UDRP or the WHOIS<br>
requirements to prove that this text precludes those requirements. They<br>
will be unable to do so.<br>
<br>
If you would like me to walk you through the same analysis with UDRP, I<br>
can do so, but I think the above answers your question.<br>
<br>
Kind Regards,<br>
<br>
Malcolm.<br>
<br>
* NB: This is an important point, with important ramifications. ICANN is<br>
not prohibited by this clause from any form of regulation of domain<br>
registrants at all. That may disappoint some (perhaps in civil society).<br>
I think it shows that this clause is balanced.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
> -----Original Message----- From:<br>
> <a href="mailto:accountability-cross-community-bounces@icann.org">accountability-cross-community-bounces@icann.org</a><br>
> [mailto:<a href="mailto:accountability-cross-community-bounces@icann.org">accountability-cross-community-bounces@icann.org</a>] On Behalf<br>
> Of Malcolm Hutty Sent: Wednesday, November 11, 2015 10:26 AM To:<br>
> Burr, Becky; Robin Gross Cc: ACCT-Staff; Accountability Community<br>
> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding<br>
> Mission and Contract<br>
><br>
><br>
><br>
> On 11/11/2015 14:47, Burr, Becky wrote:<br>
>> Could I get you to expand on one point Robin, Paul and others? To<br>
>> the extent ICANN obligates registrars to make registrants agree to<br>
>> submit to a UDRP, is that regulation of parties not in privity of<br>
>> contract with ICANN? What about the requirement that registrants<br>
>> provide accurate WHOIS Information.<br>
><br>
> Perhaps I can take that.<br>
><br>
> The proposal that we frame this as a prohibition on "regulation of<br>
> parties not in privity of contract with ICANN" is a proposal from BC<br>
> and USCIB. It is one form of wording that aims at the same basic<br>
> intent as the original wording.<br>
><br>
> For myself, I think this alternative wording is intended to resolve<br>
> one fear (that an excessively broad interpretation of "regulate"<br>
> might result in ICANN being unable to form contracts of any sort),<br>
> but it introduces problems of its own. If the BC's wording were used,<br>
> I think UDRP and WHOIS requirements would be in jeopardy. I wouldn't<br>
> want to do that, not do I see any public comment that suggests this<br>
> is anybody's aim, least of all BC. That's why, when we sought a<br>
> compromise that would address that concern, we did not adopt the BC<br>
> wording, but instead added the following:<br>
><br>
> "ICANN shall have the ability to negotiate, enter into and enforce<br>
> agreements with contracted parties in service of its Mission."<br>
><br>
> I think this is a good faith effort to accomodate the point that BC<br>
> and USCIB raised, without reneging on the basic attempt to prevent<br>
> the downstream content regulation, a principle that BC, USCIB have<br>
> been clear that they also support. In other words, if we keep the<br>
> Second Draft Report text and adopt the above sentence in addition, I<br>
> believe we can in good conscience say that we have accommodated BOTH<br>
> those that supported the original language AND the BC/USCIB input.<br>
> Such reconciliation is surely what we should be aiming at, is it<br>
> not?<br>
><br>
> So the answer to your question is that if we go with the Second Draft<br>
> Report language (with or without the additional sentence), I don't<br>
> think there is any problem with continuing UDRP or WHOIS. If we<br>
> adopted the BC text as an alternative solution, I think that would<br>
> make the UDRP ultra vires (which is surely accidental on BC's part).<br>
><br>
>> What about the new gTLD applicant guidebook prohibition on Strings<br>
>> at the top level that advocate behavior that violateS globally<br>
>> accepted human rights standards?<br>
><br>
>> These examples are things that ICANN does right now. Are they ultra<br>
>> vires under the regulatory prohibition? If not, why not?<br>
><br>
><br>
> Again, we need to distinguish between the BC text and the Second<br>
> Draft Report text.<br>
><br>
> I think that BC text would create a conflict here too.<br>
><br>
> The Second Draft Report text (with or without the additional sentence<br>
> quoted above) would not conflict with those rules. The reason is that<br>
> the text does not restrain ICANN in its choices as to which top-level<br>
> domains to approve or decline to approve in any way.<br>
><br>
> The text only restricts ICANN from seeking to regulate the services<br>
> (such as web servers) that use the DNS. Declining to approve the<br>
> delegation of a controversial string could not credibly be said to be<br>
> an example of regulating the services (such as web servers) that use<br>
> the DNS. Any attempt to mount such a claim in an IRP challenge would<br>
> be doomed to failure. Indeed, assuming the IRP adopts procedures for<br>
> the swift dismissal of claims with no reasonable prospect of success,<br>
> as we recommend elsewhere in our report, such an ill-founded claim<br>
> would be dismissed rapidly.<br>
><br>
> That said, Alan Greenberg has said he doesn't consider this point to<br>
> be as unequivocally clear as I claim. Alan and I are entirely in<br>
> agreement that this clause should not restrain ICANN's unlimited<br>
> discretion as to which strings to approve as new gTLDs, but Alan<br>
> thinks there is room for confusion on whether our text successfully<br>
> achieves that. I would be happy to add a drafting note to our lawyers<br>
> that the final text must not bring this into question.<br>
><br>
> In conclusion, as long as we proceed with the text that has been<br>
> published, scrutinised, commented upon and widely suppored, we need<br>
> have no fear concerning the points you raise.<br>
><br>
> Your questions do, however, point up the dangers of unforeseen<br>
> consequences in making, at this late stage, substantial changes to<br>
> the text we have previously published.<br>
><br>
> Kind Regards,<br>
><br>
> Malcolm.<br>
><br>
><br>
>> Sent from my iPad<br>
>><br>
>>> On Nov 11, 2015, at 8:30 AM, Robin Gross <<a href="mailto:robin@ipjustice.org">robin@ipjustice.org</a>><br>
>>> wrote:<br>
>>><br>
>>> I do not agree that there lacks consensus on including the text<br>
>>> which states ICANN won't regulate content. There IS consensus on<br>
>>> that point, but not full consensus because a small minority<br>
>>> disagrees with that position (IPC). Some in the BC don't even<br>
>>> take this extreme IPC position.<br>
>>><br>
>>> Many different parts of the community have commented that this is<br>
>>> a crucial component to our proposed accountability plan, so<br>
>>> taking it out at this stage, simply because the IPC won't relent<br>
>>> is unacceptable. The other parts of the community have to accept<br>
>>> that we don't always get everything we want, and I find it<br>
>>> difficult to understand why the same standard doesn't apply to<br>
>>> the IPC - why we continue to go in circles until the IPC is<br>
>>> satisfied. These extra bites at the apple must stop. We need<br>
>>> some strength and backbone in our chairs and rapporteurs to not<br>
>>> allow a small minority to impose this on the rest of the<br>
>>> community, simply by refusing to relent until time runs out.<br>
>>><br>
>>> Deleting this point, which has been repeatedly stated as crucial<br>
>>> for such a wide segment of the community will create much more<br>
>>> trouble for the acceptance of our report than not allowing the<br>
>>> IPC to get everything it wants.<br>
>>><br>
>>> Robin<br>
>>><br>
>>>> On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>>> On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al:<br>
>>>>><br>
>>>>> I have to agree that the 11 comments appended by Malcolm<br>
>>>>> express strong support for the notion that ICANN should not<br>
>>>>> use its contractual authority to ³regulate services that use<br>
>>>>> the DNS or the regulation of content these services carry or<br>
>>>>> provide² and that ICANN should not attempt to establish<br>
>>>>> obligations on non-contracted parties.² But the very<br>
>>>>> commenters cited (BC, USCIB, etc.)<br>
>>>><br>
>>>> Do you mean to imply that more than those two did?<br>
>>>><br>
>>>>> also request clarification regarding ICANN¹s authority to<br>
>>>>> enforce its contracts. What are we to make of this?<br>
>>>><br>
>>>> That's misleading. They didn't make a generalised, open-ended<br>
>>>> request for clarification that opens the door to you to<br>
>>>> construct an entirely new principle inconsistent with the main<br>
>>>> principle. They had a proposal of their own.<br>
>>>><br>
>>>> BC said:<br>
>>>><br>
>>>> BC strongly support the proposition that ICANN should not<br>
>>>> attempt to establish obligations on non-contracted parties.<br>
>>>> Paragraph 60 should be clarified and we propose that it should<br>
>>>> read as follows: "ICANN shall not engage in or use its powers<br>
>>>> to attempt to establish contractual obligations on companies<br>
>>>> with which it is not in privity of contract and shall not<br>
>>>> attempt to establish contractual obligations on contracted<br>
>>>> parties that are not agreed by such parties."<br>
>>>><br>
>>>> Similarly, USCIB said:<br>
>>>><br>
>>>> Indeed, ICANN's entire multi-stakeholder structure is built on<br>
>>>> a self-regulatory system implemented through contractual<br>
>>>> obligations and thus ICANN can only establish contractual<br>
>>>> obligations on parties with which it has privity through a<br>
>>>> negotiated and mutually agreeable contract/amendment with such<br>
>>>> parties. Therefore, para 60 should be clarified and we propose<br>
>>>> that it should read as follows: "ICANN shall not engage in or<br>
>>>> use its powers to attempt to establish contractual obligations<br>
>>>> on companies with which it is not in privity of contract and<br>
>>>> shall not attempt to establish contractual obligations on<br>
>>>> contracted parties that are not agreed by such parties."<br>
>>>><br>
>>>><br>
>>>> This new language is simply not consistent with the proposition<br>
>>>> that ICANN should have any ability to enter into contracts with<br>
>>>> Registries for the purpose of regulating (or controlling, or<br>
>>>> any-of-a-number-of-other-verbs) the companies who register<br>
>>>> domain names, their business models or the content those<br>
>>>> companies carry on their web sites. Doing any of those things<br>
>>>> would entail "establishing contractual obligations on companies<br>
>>>> with which it [ICANN] is not in privity of contract", which is<br>
>>>> precisely what they say ICANN must not do.<br>
>>>><br>
>>>><br>
>>>>> With all due respect Malcolm, I will take a back seat to no<br>
>>>>> one as a consistent and ardent defender of ICANN¹s limited<br>
>>>>> mission.<br>
>>>><br>
>>>> Take care, Becky. You are starting to make it sound as though<br>
>>>> your own self-image as the defender of ICANN's limited mission<br>
>>>> is getting in the way of recognising other input with that same<br>
>>>> aim, but with which you personally disagree.<br>
>>>><br>
>>>>> So I will restate the specific questions for the CCWG:<br>
>>>>><br>
>>>>> 1. Do you agree or disagree with the following statement: "To<br>
>>>>> the extent that registry operators voluntarily assume<br>
>>>>> obligations with respect to registry operations as part of<br>
>>>>> the application process, ICANN should have the authority to<br>
>>>>> enforce those commitments.²<br>
>>>><br>
>>>> The expressed view of these 11 commenters (including, I note,<br>
>>>> the formal submission of the BC) clearly gives their answer to<br>
>>>> this question as "disagree", at least inasmuch as those<br>
>>>> obligations impose further obligations on third parties<br>
>>>> (registrants) that limit what content they may carry or provide<br>
>>>> on their web sites and suchlike services.<br>
>>>><br>
>>>> There is simply no fair reading of these 11 commenters'<br>
>>>> submissions that could answer this question as "agree", without<br>
>>>> first adding very substantial qualifications to the generality<br>
>>>> of your proposition.<br>
>>>><br>
>>>>> 2. Do you agree or disagree with the following statement:<br>
>>>>> "ICANN shall not regulate services that use the Internet's<br>
>>>>> unique identifiers, or the content that such services carry<br>
>>>>> or provide.² - Wherever you land, please explain what you<br>
>>>>> mean by ³regulate² and ³services."<br>
>>>><br>
>>>> 9 of these 11 have said they agree, and accept the wording - so<br>
>>>> they don't accept your suggestion that the words "regulate" or<br>
>>>> "services" are unclear in the context used in the Draft<br>
>>>> Report.<br>
>>>><br>
>>>> 2 of these 11 have also said they agree, but propose alternate<br>
>>>> wording to achieve that; you may consider this wording, quoted<br>
>>>> above, as responsive to your question about defining<br>
>>>> "regulate" and "services".<br>
>>>><br>
>>>><br>
>>>>> I would be very interested in responses to these specific an<br>
>>>>> limited questions.<br>
>>>><br>
>>>> -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs<br>
>>>> | Read the LINX Public Affairs blog London Internet Exchange |<br>
>>>> <a href="http://publicaffairs.linx.net/" target="_blank">http://publicaffairs.linx.net/</a><br>
>>>><br>
>>>> London Internet Exchange Ltd Monument Place, 24 Monument<br>
>>>> Street, London EC3R 8AJ<br>
>>>><br>
>>>> Company Registered in England No. 3137929 Trinity Court,<br>
>>>> Trinity Street, Peterborough PE1 1DA<br>
>>>><br>
>>>><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" target="_blank">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
>>><br>
><br>
>>>><br>
> --<br>
>>>><br>
> Malcolm Hutty | tel: <a href="tel:%2B44%2020%207645%203523">+44 20 7645 3523</a> Head of Public Affairs | Read<br>
> the LINX Public Affairs blog London Internet Exchange |<br>
> <a href="http://publicaffairs.linx.net/" target="_blank">http://publicaffairs.linx.net/</a><br>
><br>
> London Internet Exchange Ltd Monument Place, 24 Monument Street,<br>
> London EC3R 8AJ<br>
><br>
> Company Registered in England No. 3137929 Trinity Court, Trinity<br>
> Street, Peterborough PE1 1DA<br>
><br>
><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" target="_blank">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
><br>
> =================================================================<br>
> This message is the property of Time Warner Inc. and is intended only<br>
> for the use of the addressee(s) and may be legally privileged and/or<br>
> confidential. If the reader of this message is not the intended<br>
> recipient, or the employee or agent responsible to deliver it to the<br>
> intended recipient, he or she is hereby notified that any<br>
> dissemination, distribution, printing, forwarding, or any method of<br>
> copying of this information, and/or the taking of any action in<br>
> reliance on the information herein is strictly prohibited except by<br>
> the intended recipient or those to whom he or she intentionally<br>
> distributes this message. If you have received this communication in<br>
> error, please immediately notify the sender, and delete the original<br>
> message and any copies from your computer or storage system. Thank<br>
> you.<br>
> =================================================================<br>
><br>
<br>
--<br>
Malcolm Hutty | tel: <a href="tel:%2B44%2020%207645%203523">+44 20 7645 3523</a><br>
Head of Public Affairs | Read the LINX Public Affairs blog<br>
London Internet Exchange | <a href="http://publicaffairs.linx.net/" target="_blank">
http://publicaffairs.linx.net/</a><br>
<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>
_______________________________________________<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" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>