<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"\@SimSun";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 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";
        color:black;}
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;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@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 bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">This focus is much too narrow, to the extent that it is limited to the business/institutional needs of ICANN and its contracted parties for data.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">There is a big world out there of people and institutions, who are neither ICANN nor its contracted parties, who have relied for decades upon access to registration
 data for a myriad of lawful and productive purposes.&nbsp; They also have an interest in how we answer the question “why we need an RDS.”&nbsp;
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">To answer that question we first need to decide who is “we”.&nbsp; &nbsp;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Steve Metalitz
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#88162E"><o:p>&nbsp;</o:p></span></b></p>
</div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext"> gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org]
<b>On Behalf Of </b>Sam Lanfranco<br>
<b>Sent:</b> Wednesday, May 11, 2016 11:54 AM<br>
<b>To:</b> TXVB; ajs@anvilwalrusden.com; gnso-rds-pdp-wg@icann.org<br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] [renamed] Key early questions<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Just a quick short &quot;keep it simple&quot; comment on both TXVB's and Andrew Sullivan's postings:<br>
<br>
The &quot;why we_need_an_RDS&quot; is a legitimate question and it has two parts. <br>
<br>
Part one is why does ICANN need what data, and beyond that, and largely outside ICANN's remit, part two is why do Registries and Registrars need data.
<br>
<br>
As far as ICANN is concerned the question is only around the data ICANN needs and the terms under which it is provided, stored, private and secure, terms of access by legal authorities etc.
<br>
ICANN can impose data requirements via its contracts with contracted parties and those may or may not be allowed to stand by the authorities in the countries where registries and registrars are located.<br>
<br>
As the Irish have pointed out, some of what ICANN requires in its contracts is contrary to national law, even though enforcement has been lax. That is unlikely to continue, so whatever ICANN thinks it needs as it works through this gnso-rds-pdp-wg process,
 looking over the ICANN remit &quot;fence&quot; at legislation elsewhere is a judicious idea.<br>
<br>
As for Andrew's point that operators have need for data to conduct their business, that &quot;need&quot; breaks down into three categories:
<br>
1. There is the data needed to meet ICANN's contracted requirements. <br>
2. There is the data needed to conduct the business of dealing with clients as registrants (invoices, billing, payment, etc.).<br>
3. There is desired data to conduct other marketing and innovative aspects of being a contracted operator (registry, registrar).<br>
<br>
ICANN's focus should be primarily on category #1, with due respect to the costs and compatibilities with Registry and Registrar needs.<br>
Category #2 is up to the contracted parties and they can compete or share best practices as they see fit, like any other industrial sector.<br>
The only interest ICANN should have in Category #3 is to remain alert to data uses that may compromise the integrity of the DNS system and engage contracted parties when issues arise.<br>
<br>
Rest assured that national and regional authorities will be also watching all of this with greater diligence.&nbsp; &nbsp;
<br>
<br>
Sam <o:p></o:p></p>
<div>
<p class="MsoNormal">On 5/11/2016 7:07 AM, TXVB wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">I have this concern also. That was the #1 item to consider, per the charter before plowing ahead.<br>
<br>
<br>
<br>
<br>
<br>
<br>
-------- Original Message --------<br>
On May 10, 2016, 1:16 PM, Andrew Sullivan wrote: <o:p></o:p></p>
<p class="MsoNormal"><br>
Hi, <br>
<br>
I'm slightly concerned that we are forgetting in this discussion why <br>
we _need_ an RDS in the first place. <br>
<br>
On Tue, May 10, 2016 at 10:59:29AM -0400, Sam Lanfranco wrote: <br>
&gt; <br>
&gt; ICANN has business interests in defining what data to collect, accessible by <br>
&gt; whom and under what conditions. It also has business interests, from within <br>
&gt; its remit, in the data relationship with its contracted parties. <br>
&gt; However, ICANN’s contracted parties reside within national jurisdictions, <br>
&gt; and the relevant data is hosted within national jurisdictions, so ICANN <br>
&gt; cannot unilaterally define what constitutes legitimate data policy within <br>
&gt; its business interests. <br>
<br>
All of the above is something I agree with, but there's another <br>
important point. For good, sound, plain old technical reasons, it's <br>
important that operators be able to contact each other outside of the <br>
Internet, so that when stuff breaks it's at least logically possible <br>
that one could try to fix it. <br>
<br>
The key point is that this is not some peculiar business interest of <br>
ICANN, but instead a fundamental interest of anyone who uses the DNS <br>
(i.e. approximately anyone who uses the Internet). It's basic to why <br>
we have ICANN at all. <br>
<br>
None of this is an argument that _all_ the information in any <br>
particular RDS policy is what ought to be in the RDS. But at the same <br>
time, it seems to me that some views about RDS treat every data field <br>
as if it's a simple matter of political negotiation or something like <br>
that. They're not all that way. As an operator of actual technical <br>
infrastructure, I need to be able to contact someone who is causing <br>
problems on my network, and that ability to contact had better not <br>
depend on the Internet since the problem in question is likely to <br>
result from some sort of interoperation failure in the first place. <br>
Therefore, <br>
<br>
&gt; Some will brand this as the “fracturing of the Internet”. It is in fact <br>
&gt; other jurisdictions taking responsibility for Internet governance outside <br>
&gt; ICANN’s remit, but within their remit. <br>
<br>
I don't think that all of this is just about &quot;Internet governance&quot;, <br>
any more than (say) port number allocations are a matter for Internet <br>
governance. Some of it is just a fundamental part of having an <br>
Internet at all. Remember, it's an inter-net because of the network <br>
of networks part. Interoperation is a fundamental part, not something <br>
you get to choose or not from a menu of available policy options. <br>
<br>
Best regards, <br>
<br>
A <br>
<br>
-- <br>
Andrew Sullivan <br>
<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a> <br>
_______________________________________________ <br>
gnso-rds-pdp-wg mailing list <br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a> <br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a>
<br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>gnso-rds-pdp-wg mailing list<o:p></o:p></pre>
<pre><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><o:p></o:p></pre>
<pre><a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>------------------------------------------------<o:p></o:p></pre>
<pre>&quot;It is a disgrace to be rich and honoured<o:p></o:p></pre>
<pre>in an unjust state&quot; -Confucius<o:p></o:p></pre>
<pre> <span lang="ZH-CN" style="font-family:SimSun">邦有道,贫且贱焉,耻也。邦无道,富且贵焉,耻也</span><o:p></o:p></pre>
<pre>------------------------------------------------<o:p></o:p></pre>
<pre>Dr Sam Lanfranco (Prof Emeritus &amp; Senior Scholar)<o:p></o:p></pre>
<pre>Econ, York U., Toronto, Ontario, CANADA - M3J 1P3<o:p></o:p></pre>
<pre>email: <a href="mailto:Lanfran@Yorku.ca">Lanfran@Yorku.ca</a>&nbsp;&nbsp; Skype: slanfranco<o:p></o:p></pre>
<pre>blog:&nbsp; <a href="http://samlanfranco.blogspot.com">http://samlanfranco.blogspot.com</a><o:p></o:p></pre>
<pre>Phone: &#43;1 613-476-0429 cell: &#43;1 416-816-2852<o:p></o:p></pre>
</div>
</body>
</html>