<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body 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 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>
<p><font size="+1"><font face="Lucida Grande">Cheers Stephanie</font></font><br>
</p>
<br>
<div class="moz-cite-prefix">On 2016-07-16 1:00, Andrew Sullivan
wrote:<br>
</div>
<blockquote cite="mid:20160716050024.GI32398@mx2.yitter.info"
type="cite">
<pre wrap="">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 wrap=""> * Where the RDS (whether a central database or federated or completely
disaggregated) resides becomes important for law enforcement access.
</pre>
</blockquote>
<pre wrap="">
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 class="moz-txt-link-freetext" href="http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000951.html">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>
</body>
</html>