<html><body><div style="font-family: Arial; font-size: 12pt; color: #000000"><div>John as previously mentioned the ICANN listing software does not make it easy to see "who says what", please make sure your iPhone signs who you are. :)<br></div><div><br data-mce-bogus="1"></div><div data-marker="__SIG_PRE__">Kind regards,<br><br>Chris</div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>From: </b>"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org><br><b>To: </b>"Volker Greimann" <vgreimann@key-systems.net><br><b>Cc: </b>"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org><br><b>Sent: </b>Friday, 2 June, 2017 14:59:07<br><b>Subject: </b>Re: [gnso-rds-pdp-wg] The principle for thin data (was Re: Principle on Proportionality for "Thin Data"access)<br></div><div><br></div><div data-marker="__QUOTED_TEXT__"><div>So its an educational problem then? Ok, let's just solve that. Maybe create a page on ICANN translated into "all the languages" that explain in normal-person-language what all this means. Registrars can point to that, then get consent, and we can all move on already. <br><br>Sent from my iPhone</div><div><br>On Jun 2, 2017, at 08:19, Volker Greimann <<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>> wrote:<br><br></div><blockquote><div>
<p>Hi Greg, <br>
</p>
<p>you are correct, but:</p>
<p>The way it has been done is no longer sufficient. Simply
providing notice and getting consent through the RA no longer
works. The purposes now have to be clearly defined, not vague and
indescript as in the past. <br>
</p>
<p>So yes, the basic idea is the same but the implementation and
actual requirements of doing so have changed significantly.</p>
<p>Best,</p>
<p>Volker</p>
<p><br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Am 02.06.2017 um 15:14 schrieb Greg
Aaron:<br>
</div>
<blockquote cite="mid:BN6PR13MB184359FA37EE1C3A30E8483AD9F70@BN6PR13MB1843.namprd13.prod.outlook.com">
<style><!--
@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:"Lucida Grande";
        panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-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;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.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;}
--></style>
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose">BTW, disclosure and permission have
been required in ICANN contracts for years; registrants
agree to it and receive the details in their registration
contracts. The latest version is in the 2013 RAA:</a><br data-mce-bogus="1"></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"></span><a href="https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en" target="_blank"><span style="mso-bookmark:_MailEndCompose">https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en</span><span style="mso-bookmark:_MailEndCompose"></span></a><span style="mso-bookmark:_MailEndCompose"></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Some
of the relevant language is:</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"> </span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">“3.7.7.4
Registrar shall provide notice to each new or renewed
Registered Name Holder stating:</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.4.1
The purposes for which any Personal Data collected from the
applicant are intended;</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.4.2
The intended recipients or categories of recipients of the
data (including the Registry Operator and others who will
receive the data from Registry Operator);</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.4.3
Which data are obligatory and which data, if any, are
voluntary; and</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.4.4
How the Registered Name Holder or data subject can access
and, if necessary, rectify the data held about them.</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.5
The Registered Name Holder shall consent to the data
processing referred to in Subsection 3.7.7.4.</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.6
The Registered Name Holder shall represent that notice has
been provided equivalent to that described in Subsection
3.7.7.4 to any third-party individuals whose Personal Data
are supplied to Registrar by the Registered Name Holder, and
that the Registered Name Holder has obtained consent
equivalent to that referred to in Subsection 3.7.7.5 of any
such third-party individuals.</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.7
Registrar shall agree that it will not process the Personal
Data collected from the Registered Name Holder in a way
incompatible with the purposes and other limitations about
which it has provided notice to the Registered Name Holder
in accordance with Subsection 3.7.7.4 above.</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.8
Registrar shall agree that it will take reasonable
precautions to protect Personal Data from loss, misuse,
unauthorized access or disclosure, alteration, or
destruction.</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">3.7.7.9
The Registered Name Holder shall represent that, to the best
of the Registered Name Holder's knowledge and belief,
neither the registration of the Registered Name nor the
manner in which it is directly or indirectly used infringes
the legal rights of any third party.”</span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"> </span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"> </span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt">**********************************</span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt">Greg Aaron</span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt">Vice-President, Product
Management</span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt">iThreat Cyber Group /
<a href="http://Cybertoolbelt.com" target="_blank">Cybertoolbelt.com</a></span></span><br data-mce-bogus="1"></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt">mobile: +1.215.858.2257</span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt">**********************************</span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt">The information contained in this
message is privileged and confidential and protected from
disclosure. If the reader of this message is not the
intended recipient, or an employee or agent responsible
for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution
or copying of this communication is strictly prohibited.
If you have received this communication in error, please
notify us immediately by replying to the message and
deleting it from your computer.</span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"> </span></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<p class="MsoNormal"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">gnso-rds-pdp-wg-bounces@icann.org</a>
[<a class="moz-txt-link-freetext" href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Dotzero<br>
<b>Sent:</b> Thursday, June 1, 2017 10:48 AM<br>
<b>To:</b> Stephanie Perrin
<a class="moz-txt-link-rfc2396E" href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank"><stephanie.perrin@mail.utoronto.ca></a><br>
<b>Cc:</b> RDS PDP WG <a class="moz-txt-link-rfc2396E" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank"><gnso-rds-pdp-wg@icann.org></a><br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] The principle for thin
data (was Re: Principle on Proportionality for "Thin
Data"access)</p>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The issue
you raise is addressed simply enough by requiring a
privacy disclosure be displayed at the time of domain
registration. This requirement can be incorporated into
the ICANN registry agreements. Note that this does not
resolve the issue for CC domains.</p>
</div>
<p class="MsoNormal">Michael Hammer</p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Thu, Jun 1, 2017 at 10:43 AM,
Stephanie Perrin <<a href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank">stephanie.perrin@mail.utoronto.ca</a>>
wrote:</p>
<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">I certainly agree that if people
enter personal information as part of their DNS
registration or their motor vehicle licence
registration, it is done with implied consent... as
long as there is sufficient information to permit
them to understand just how the data is being used
and where it is going. However, as I tried to say
with respect to registering a domain name, I really
don't think the average non-expert citizen who might
want to register a domain name would get enough
information to truly understand how far his/her
information goes, and how difficult it is to get it
removed once it has appeared in the public record.
We should build this system so that everyone
understands it, not just the experts.</span></p>
<p><span style="font-size:13.5pt;font-family:"Lucida
Grande",serif">cheers Stephanie</span></p>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On 2017-06-01 05:18, jonathan
matkowsky wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Stephanie,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">I
agree with you that we should not
conflate collection limitation
principles with openness principles.</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">I
respectfully disagree with most of what
you wrote in the first paragraph of your
post script. </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">Here
we are talking about users potentially
entering personal or pseudonymous
information when they are not being
asked for it (nor is it required) to
begin with, and it is not required for
purposes of which it's being collected.
That is the</span></p>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">scope</span></p>
</div>
<p class="MsoNormal"> of what needs to be
assessed </p>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">if
at all and how the scope needs to be</span></p>
</div>
<p class="MsoNormal"> defined from the
beginning </p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">
if you were to conduct a PIA</span></p>
</div>
<p class="MsoNormal">. </p>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">
</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif"></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">Personal
information is not being used or
intended to be used just because a
person decides to enter personal
information into a field. </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif"></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">The
example of how you can combine databases
to re-identify a person based on the SOA
record is the equivalent of protecting
domain names as personal information
because a person </span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">can
register their driver's license
</span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">
or name and date of birth</span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">as
a domain name.</span>
</p>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif"> </span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">I
would argue no PIA should be required </span>
</p>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">as
a result </span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">even
in accordance even with best practices.</span>
</p>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif"> </span></p>
</div>
<p class="MsoNormal">A PIA needs to be
conducted in a manner that is commensurate
with the level of privacy risk identified
</p>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">. </span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif"> </span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">I
respectfully disagree with you that
thin data is personal. We are talking
about identifiers (codes or strings
that represent an individual or
device). Many labels can be used to
point to individuals. Some are precise
and most, imprecise or vague. There's
no question that an IP address is a
device identifier. Device IDs, MAC
addresses can be a source for user
tracking. But </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">i</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif">dentifiers
can be strong or weak depending on how
precise they are as well as the
context. It cannot be measured without
taking linkability into
consideration. For that reason, name
servers are not the same as IP
addresses or MAC addresses any more so
than the existence of a domain name is
an identifier. If a person chooses to
use identifiable information when it
is not being asked for or required for
purposes of which the data is being
collected, that does that mean we need
to classify all the data according to
that unlikely scenario. Those setting
up their own DNS would be relatively
speaking, sophisticated Internet users
that presumably know the basics of how
DNS operates in any case, so by
entering the information in that way,
they are choosing to customize their
DNS in a personal way similar to a
person that chooses to show personal
information on their license plate
number. </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">I
know that the motor vehicle registry
is restricted now in most places so
that you would need a subpoena to get
that kind of personal information.
This is also true of an IP address
though and IP providers. The fact is a
person can put their name and date of
birth on a license plate if they want
to customize it. And then they get on
the road. That does not mean the
license plate numbers are all personal
information. It's pseudonymous data.
It is true that it is a stronger
identifier than an IP address insofar
as if you subpoena the motor vehicle
registry operator, you will get the
personal information behind that
license plate number. If you subpoena
the ISP, you MIGHT get the personal
information depending on the nature of
the IP address. It's still true that
to drive a car, you need to show your
license plate number on the vehicle. </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">I
would argue that thin Whois data is
pseudonymous or personal data to the
same extent that a person can choose
to
<span data-mce-style="text-decoration: underline;" style="text-decoration: underline;">customize</span> a license plate if
they want to, and put personal or
psuedonymous data into fields
</span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">for
which the data being collected does
not ask for or require them to do
so. </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">A</span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"> person
can register their driver's license as
a domain name.
</span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">They
can use a personal email in their
SOA record, or personal NS. </span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">Just
because it's theoretically possible
for someone to enter pseudonymous (or
even personal) data into multiple
databases when they are not being
asked for it, and those combination of
choices make it possible to identify
them, does not mean one of the sets
(Thin Whois) should be classified as
personal information subject to a
PIA. </span></p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"></span></p>
</div>
<p class="MsoNormal"><br clear="all">
</p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Jonathan
Matkowsky,<br>
VP – IP & Brand Security<br>
USA:: <a href="tel:%28347%29%20467-1193" target="_blank">1.347.467.1193</a>
| Office::
<a href="tel:+972%208-926-2766" target="_blank">+972-(0)8-926-2766</a><br>
Emergency mobile:: <a href="tel:+972%2054-924-0831" target="_blank">+972-(0)54-924-0831</a><br>
Company Reg. No. 514805332 <br>
11/1 Nachal Chever, Modiin Israel<br>
<a href="http://www.riskiq.co.il" target="_blank">Website</a><br>
RiskIQ Technologies Ltd.
(wholly-owned by RiskIQ, Inc.)</p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Thu, Jun 1, 2017
at 12:02 AM, Stephanie Perrin <<a href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank">stephanie.perrin@mail.utoronto.ca</a>>
wrote:</p>
<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">Your summary
today was great Andrew.</span></p>
<p><span style="font-size:13.5pt;font-family:"Lucida
Grande",serif">I am not
arguing about the disclosure of
thin data. We already voted on
unauthenticated mandatory
disclosure, weeks ago (or at least
it feels like weeks ago). Lets
please move on. We are debating
this yet again, because people
keep asking, is thin data
personal? [lots of people missed
the last call] The answer is yes
(IMHO). Does that mean it cannot
be disclosed? The answer is no.
Does the proportionality principle
apply? Yes. Have we already gone
through this? Yes. Can we come
back to it? Yes, but hopefully
only if we have to.....we will
have to when we get to data
elements.</span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">cheers
Stephanie<br>
<span style="font-size:13.5pt">PS a
fundamental problem here is that
people try to categorize
information that in their view
should be disclosed, as not
personal information. This fight
has gone on for years over IP
address, for instance. The
important question is not actually
whether it is personal data or
not, it is "do you need to
disclose it to make things
work?"....and if the answer is yes
then you try to mitigate the
disclosure and try to keep it
minimized to what is absolutely
required. Hence the PIA, which
should employ both data
minimization and the test in the
proportionality principle as
techniques to evaluate data
elements.<br>
A good and really simple example
is a phone number. IS it personal
info? (the telcos fought for
years, trying to claim they owned
it and it was not personal).
Obviously it pertains to you,
people feel strongly that it is
personal (culturally relative of
course but...) and yet if noone
ever learns your number your phone
won't ever receive a call. That
does not mean you have to disclose
it everywhere.....only where
necessary. And it should mean
that it does not have to follow
you everywhere, but that is
becoming increasingly hard to
manage....<br>
<br>
By the way, informed consent is
not the same as transparency
requirements. Transparency
requirements are exactly
that....you have to be transparent
about what you are doing with
data. Let us not conflate that
with consent.<br>
<br>
I will quit now and stop trying to
answer questions. I would like to
humbly suggest, however, that we
have a real shortage of basic
understanding of how data
protection law works and is
interpreted. If there is a data
protection law expert that folks
might listen to, we should hire
that person to advise us. It
might save a lot of time.<br>
<br>
</span></p>
<div>
<p class="MsoNormal">On 2017-05-31
16:00, Andrew Sullivan wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Hi,</pre>
<pre> </pre>
<pre>On Wed, May 31, 2017 at 03:20:59PM -0400, Stephanie Perrin wrote:</pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>That does not mean we need to protect it, it means we have to examine it in</pre>
<pre>terms of DP law. May I repeat the suggestion that Canatacci made in</pre>
<pre>Copenhagen in response to a question.....(I forget the precise question he</pre>
<pre>was asked, sorry). If you want to figure out whether you have to protect</pre>
<pre>something or not, do a privacy impact assessment.</pre>
</blockquote>
<pre>As I think I've said more than once in this thread, I think we _have_</pre>
<pre>done that assessment and I think the answers are obvious and I think</pre>
<pre>therefore that there is nothing more to say about this principle in</pre>
<pre>respect of thin data:</pre>
<pre> </pre>
<pre> - the data is either necessary for the operation of the system</pre>
<pre> itself or else necessary for distributed operation and</pre>
<pre> troubleshooting on the Internet.</pre>
<pre> </pre>
<pre> - the data does not expose identifying information about anyone,</pre>
<pre> except in rather strained examples where the identifying</pre>
<pre> information is already completely available via other means.</pre>
<pre> </pre>
<pre>What more is one supposed to do? </pre>
<pre> </pre>
<pre>Best regards,</pre>
<pre> </pre>
<pre>A</pre>
<pre> </pre>
</blockquote>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"><br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">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><br data-mce-bogus="1"></p>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"> </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" target="_blank">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><br data-mce-bogus="1"></p>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br data-mce-bogus="1"></pre>
</blockquote>
<br>
<pre class="moz-signature">--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net" target="_blank">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net" target="_blank">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com" target="_blank">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com" target="_blank">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems" target="_blank">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems" target="_blank">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu" target="_blank">www.keydrive.lu</a>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net" target="_blank">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net" target="_blank">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com" target="_blank">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com" target="_blank">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems" target="_blank">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems" target="_blank">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu" target="_blank">www.keydrive.lu</a>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
</pre>
</div></blockquote><blockquote><div><span>_______________________________________________</span><br><span>gnso-rds-pdp-wg mailing list</span><br><span><a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a></span><br><span><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></span><br data-mce-bogus="1"></div></blockquote><br>_______________________________________________<br>gnso-rds-pdp-wg mailing list<br>gnso-rds-pdp-wg@icann.org<br>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<br></div></div></body></html>