<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><font face="Lucida Grande">This is indeed an
interesting approach....not sure exactly what data elements
individual access requestors really need, and how much
transactional data they want for criminal investigative
purposes (eg payment info, ip address, etc). That
transactional data as I understand it is currently either held
by the registrar or escrowed (and at least theoretically not
accessed). But as others have said, we should perhaps park
this discussion for future debate. <br>
</font></font></p>
<p><font size="+1"><font face="Lucida Grande">There are many
contractual carveouts for credit card data, with respect to Data
Protection law, to allow for free flow of info. Not sure we
could permit that for this data....but again, we are getting
ahead of ourselves.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Thanks!</font></font></p>
<p><font size="+1"><font face="Lucida Grande">STephanie Perrin</font></font><br>
</p>
<br>
<div class="moz-cite-prefix">On 2016-07-16 4:05, Sivasubramanian M
wrote:<br>
</div>
<blockquote
cite="mid:CAHyAo0GMT=SYd7VAMUVz51nYPRBDrvmttcc2rvK08s+8EGA_9A@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:#333333">Dear
Stephanie Perrin and Andrew,</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:#333333"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:#333333">(inline)</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Jul 16, 2016 at 10:42 AM,
Stephanie Perrin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:stephanie.perrin@mail.utoronto.ca"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:stephanie.perrin@mail.utoronto.ca">stephanie.perrin@mail.utoronto.ca</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><font face="Lucida Grande">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.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">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 </font></font></p>
</div>
</blockquote>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><font face="Lucida Grande">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?</font></font></p>
</div>
</blockquote>
<div><br>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51);display:inline">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.</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51);display:inline"><br>
</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">The
question "where data resides" 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.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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. </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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: </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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)</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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. </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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. </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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. </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">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.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">Sivasubramanian
M </div>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><font face="Lucida Grande">Cheers
Stephanie</font></font><br>
</p>
<div>
<div class="h5"> <br>
<div>On 2016-07-16 1:00, Andrew Sullivan wrote:<br>
</div>
<blockquote type="cite">
<pre>Thanks, Stephanie, for the quick issue list. There's one thing that I
want to draw out here so that we can keep it foremost when thinking of
issues:
On Sat, Jul 16, 2016 at 12:05:10AM -0400, Stephanie Perrin wrote:
</pre>
<blockquote type="cite">
<pre> * Where the RDS (whether a central database or federated or completely
disaggregated) resides becomes important for law enforcement access.
</pre>
</blockquote>
<pre>This "where data resides" issue is bound to vex us, no matter what
kind of policy we come up with. But it's really important to keep in
mind that the different styles of system design will yield very
different properties.
In the taxonomy I offered before
(<a moz-do-not-send="true" 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>),
models I and V have a clear since answer to, "Where does the data
reside?" because they have a single database backing them up. In
models II-IV, however, the answer to, "Where does the data reside?" is
actually not entirely meaningful. There are multiple places where the
data are, and for data with respect to any given domain name each
datum might be in a different place. (Indeed, part of the design of
RDAP is precisely to make such arrangements easier to deal with.)
It is therefore better to try to find a way, consistent with all of
the various requirements documents, to answer some other questions.
I think these might be helpful in building use cases:
1. For any given datum, who has control of and access to the datum?
2. For any given datum, what are the conditions under which the
datum ought to be accessible?
3. For any given set of related data, how can it be accessed?
Notice that answering (3) will provides use cases for data access,
whereas (1) and (2) provide for limit conditions on how and when use
cases might be apply.
I hope these framing questions are helpful in figuring out which use
cases we can bring to bear on requirements.
Best regards,
A
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>