<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: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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Lucida Grande";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@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-family:"Verdana","sans-serif";color:#333333">Sivasubramanian,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">You are getting way ahead of where we are in our work plan.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">Chuck</span><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"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org]
<b>On Behalf Of </b>Sivasubramanian M<br>
<b>Sent:</b> Saturday, July 16, 2016 4:06 AM<br>
<b>To:</b> Stephanie Perrin<br>
<b>Cc:</b> gnso-rds-pdp-wg@icann.org<br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list )<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">Dear Stephanie Perrin and Andrew,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">(inline)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Sat, Jul 16, 2016 at 10:42 AM, Stephanie Perrin <<a href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank">stephanie.perrin@mail.utoronto.ca</a>> wrote:<o:p></o:p></p>
<div>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande","serif"">I think these are really important questions Andrew. Unfortunately when we talk about privacy and data control, we often use idioms that are technologically out of date (eg video surveillance,
which conjures up mental images of video tapes that have not been used in 15 years). To be clear, we need to talk about control of data elements. Fortunately, despite a lot of FUD to the contrary, the EU data protection authorities have focused on data controllers
and data processors, and we have good documents with summaries for those concepts. They have not changed with the new regulation, so they are still valid.</span><o:p></o:p></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande","serif"">If I understand RDAP correctly, it would permit duly authorized data access from anywhere, to elements that could be scattered. This would match current data mining techniques. The problem,
as I see it, and I beg to be corrected if I am wrong, is how do we manage a remote authorization scheme to individual data elements, if indeed
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande","serif"">some data is held by the registrar, some by the registry, and some (outside ICANN's remit, but an answer to LEA demands) by the ISP?</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#333333"></span><span style="font-family:"Verdana","sans-serif";color:#333333">I will start with the disclaimer that I am writing this WITHOUT a good understanding of the technical operations
concerning the present RDAP nor about the advances in data mining technology.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#333333"></span><span style="font-family:"Verdana","sans-serif";color:#333333">The question "where data resides"
</span><span style="font-family:"Arial","sans-serif";color:#333333"></span><span style="font-family:"Verdana","sans-serif";color:#333333">and if the design of RDAP is to make it easier to answer that question, and on a superficial level "data" here means Registration
Data, this is very much becomes a whois design question.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">If some data is held by Registrar, some by Registry and some by the ISP, there may be a way of streamlining this by modifying the manner in which Registrant data is gathered
and stored at the time of registration. Some attention to the VISA/MASTERCARD method of collecting and handling credit card information could help ICANN come up with a streamlined design for handling Registrant data. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">If such a model is to be emulated, a Registrant going to a sub-Reseller going through a Reseller going through a Registrar under a Registry would gather the Registrant data
on a secure form interjected by an operator like Verisign, -verisign here is not to be confused with Verisign the Registry, or Verisign the RZM operator, but that division of Verisign which serves the secure form-, independent of and regardless of the insecurity
of the Sub-Reseller's webspace. This could be verisign or even an IAB designed secure form. This verisign form ( I will call it the Verisign form, for illustration) could then be used to collect: <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">a) all Registrant data and then automatically distribute the basic data back to the Sub-Reseller and Reseller, basic + quasi-sensitive data to the Registrar under whom the Reseller
operates and retain a copy of the above + Sensitive data with the Registry, while ultra-sensitive data, if any so categorised by any name, together with all of the above would stay only with ICANN. (the categorization of data as basic etc is arbitrary. This
is a generalized description of how it would work, there may be existing classes and sub-classes or ICANN may come up with suitable sub-classes of Registrant data)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">b) The Sensitive and Ultra-sensitive user data alone could be gathered by the Verisign form after the basic data is collected by the Reseller in his own form that may be shared
with the Registrar. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">This would prevent Registrant data abuse in a situation where there are a multitude of Resellers. The Resellers would retain the basic contact information for them the opportunity
to maintain contact with their customers, Registrars would get a copy of whatever commercial data that they require from the Resellers or from their direct customers, the Registry would still retain most of the data with a copy for the ICANN in a database,
and only ICANN retain the ultra-sensitive data, if there is any part of Registrant data is ultra-sensitive by any other name. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">This would require assurances from ICANN that it would enforce a well designed process involving a highly ethical team of community members to screen requests from Law and Order
authorities anywhere to access data, and to determine what portion of data they would access. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">The caution needed here is that such a system may have to be well thought of, the privacy and security concerns to be examined in extensive detail, the commercial privileges
concerning Registrant data prevailing among Resellers, Registrars and Registries have be examined, the ability of ICANN / Internet Community to judge the validity of Law and Order requests and the strength of ICANN to deny some requests if deemed necessary
- all these aspects have to be examined in detail.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">If the question "where does data reside" extends beyond Registrant data, the answer would be far more complicated. That would draw the Internet Community's attention to questions
concerning content in a very interesting way.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#333333">Sivasubramanian M <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande","serif"">Cheers Stephanie</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 2016-07-16 1:00, Andrew Sullivan wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Thanks, Stephanie, for the quick issue list. There's one thing that I<o:p></o:p></pre>
<pre>want to draw out here so that we can keep it foremost when thinking of<o:p></o:p></pre>
<pre>issues:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>On Sat, Jul 16, 2016 at 12:05:10AM -0400, Stephanie Perrin wrote:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre> * Where the RDS (whether a central database or federated or completely<o:p></o:p></pre>
<pre> disaggregated) resides becomes important for law enforcement access.<o:p></o:p></pre>
</blockquote>
<pre>This "where data resides" issue is bound to vex us, no matter what<o:p></o:p></pre>
<pre>kind of policy we come up with. But it's really important to keep in<o:p></o:p></pre>
<pre>mind that the different styles of system design will yield very<o:p></o:p></pre>
<pre>different properties.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>In the taxonomy I offered before<o:p></o:p></pre>
<pre>(<a href="http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000951.html" target="_blank">http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000951.html</a>),<o:p></o:p></pre>
<pre>models I and V have a clear since answer to, "Where does the data<o:p></o:p></pre>
<pre>reside?" because they have a single database backing them up. In<o:p></o:p></pre>
<pre>models II-IV, however, the answer to, "Where does the data reside?" is<o:p></o:p></pre>
<pre>actually not entirely meaningful. There are multiple places where the<o:p></o:p></pre>
<pre>data are, and for data with respect to any given domain name each<o:p></o:p></pre>
<pre>datum might be in a different place. (Indeed, part of the design of<o:p></o:p></pre>
<pre>RDAP is precisely to make such arrangements easier to deal with.)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>It is therefore better to try to find a way, consistent with all of<o:p></o:p></pre>
<pre>the various requirements documents, to answer some other questions.<o:p></o:p></pre>
<pre>I think these might be helpful in building use cases:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> 1. For any given datum, who has control of and access to the datum?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> 2. For any given datum, what are the conditions under which the<o:p></o:p></pre>
<pre> datum ought to be accessible?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> 3. For any given set of related data, how can it be accessed?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Notice that answering (3) will provides use cases for data access,<o:p></o:p></pre>
<pre>whereas (1) and (2) provide for limit conditions on how and when use<o:p></o:p></pre>
<pre>cases might be apply.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I hope these framing questions are helpful in figuring out which use<o:p></o:p></pre>
<pre>cases we can bring to bear on requirements.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Best regards,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>A<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><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" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>