<div dir="ltr">>><span style="font-size:12.8px"> 'what' that information can or may be used for</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Enforced how? WHOIS is not the only outlet for information collected by registrars. And even if WHOIS thin data was put behind a EULA, the rest of it can't be. You can't put a DNS query behind a EULA. We can't pretend there are restrictions on this data.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 31, 2017 at 12:59 PM, Michael Peddemors <span dir="ltr"><<a href="mailto:michael@linuxmagic.com" target="_blank">michael@linuxmagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 and a good enough statement to propose a discussion consensus around.<br>
<br>
o Because it cannot be assured that in some jurisdictions, information contained in 'Thin Data' may be considered 'personal information', and thus fall under various privacy regulations, it is a requirement by ICANN and registrars to get 'informed consent' from the party or parties registering a domain name.<br>
<br>
But I don't think that is yet in the time-line of discussions.<br>
<br>
We can however work on forming a statement of 'what' that information can or may be used for, to help form the basis of disclosure needed for that informed consent<span class=""><br>
<br>
<br>
On 17-05-31 09:49 AM, jonathan matkowsky wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I agree with Stephanie that the way to address the concerns are to make<br>
sure users have provided informed consent. The registration agreement<br>
should have a provision under applicable law.<br>
<br>
On Wed, 31 May 2017 at 19:40 Stephanie Perrin<br>
<<a href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank">stephanie.perrin@mail.utoront<wbr>o.ca</a><br></span><span class="">
<mailto:<a href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank">stephanie.perrin@mail.<wbr>utoronto.ca</a>>> wrote:<br>
<br>
I think it is a very good summary. One issue which we do not<br>
discuss very often is the fact that end users who register a domain<br>
name do not understand very well (if at all) what the implications<br>
for their privacy are. A requirement of most data protection law is<br>
to provide transparency with respect to what happens to personal<br>
data. This job, in my view, has not been tackled by ICANN in the<br>
required way. So while I agree with the summary, it raises the<br>
issue, for those of us who do not understand what an SOA record is,<br>
what thin data is, how the DNS operates, etc. there is an obligation<br>
on ICANN, through its contractual control of the registries and<br>
registrars, to provide greater clarity about how personal data is<br>
managed, and what the risks might be for the individual. Simply<br>
saying "Let's remember we are talking about the public, open<br>
Internet here. Nobody has to participate that doesn't want to, just<br>
like if I don't want anyone to see my license plate number on the<br>
road, I don't have to drive a car either. " is not adequate.<br>
(Licence registries, by the way, have become private in most<br>
jurisdictions because of the risk to registrants, so the chances of<br>
being stalked by some nut with road rage have mercifully<br></span>
decreased).____<br>
<br>
__ Stephanie Perrin<br>
__<span class=""><br>
<br>
<br>
On 2017-05-31 11:07, Gomes, Chuck via gnso-rds-pdp-wg wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
I am open to disagreement, but it seems to me that Jonathan<br>
provides a good summary and maybe even a fair conclusion of the<br>
extensive discussion that has occurred on this thread since<br>
Tuesday. Rather than continuing the extensive back and forth,<br>
which in my assessment is mostly repeating things that have<br>
already been said several times, I request that anyone who<br>
disagrees with Jonathan’s conclusions to identify what you<br></span>
disagree with and provide your reasoning.____<br>
<br>
__ __<br>
<br>
Chuck____<br>
<br>
__ __<br>
<br>
*From:*<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">gnso-rds-pdp-wg-bounces<wbr>@icann.org</a><br>
<mailto:<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">gnso-rds-pdp-wg-bounce<wbr>s@icann.org</a>><br>
[mailto:<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">gnso-rds-pdp-wg-bounce<wbr>s@icann.org</a>] *On Behalf Of *jonathan<br>
matkowsky<br>
*Sent:* Wednesday, May 31, 2017 10:52 AM<br>
*To:* Dotzero <<a href="mailto:dotzero@gmail.com" target="_blank">dotzero@gmail.com</a>> <mailto:<a href="mailto:dotzero@gmail.com" target="_blank">dotzero@gmail.com</a>>;<br>
Volker Greimann <<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>><br>
<mailto:<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.<wbr>net</a>><br>
*Cc:* RDS PDP WG <<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>><br>
<mailto:<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.<wbr>org</a>><br>
*Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] Principle on<br>
Proportionality for "Thin Data"access____<br>
<br>
__ __<span class=""><br>
<br>
I think the discussion here reflects confusion between what's<br>
available in DNS based on the domain name alone, and Thin Whois<br>
data. The fact of whether SOA records or A records may contain PII<br></span>
is a totally separate issue than Thin Whois data elements.____<br>
<br>
__ __<span class=""><br>
<br>
Based on a domain name alone, one can use it to query DNS for<br>
record elements that may contain PII or when combined with other<br>
data, can be used to obtain PII. But all of this PII is in the<br>
public domain voluntarily by their owners, and more importantly,<br>
is outside the framework of discussion, which is limited to Whois<br></span>
database--not DNS. They are simply not the same.____<br>
<br>
__ __<span class=""><br>
<br>
So the fact that you can get SOA records from the domain name<br>
alone begs the question of whether the domain name needs to be<br>
protected because when combined with other data elements, can be<br></span>
used to obtain PII.____<br>
<br>
__ __<span class=""><br>
<br>
But the domain names are publicly available on the internet by<br>
virtue of being in the zone files. So the fact you can obtain the<br>
domain from thin Whois doesn't make it any more available than it<br></span>
is from the zone files. It is outside the framework of discussion.____<br>
<br>
__ __<span class=""><br>
<br>
The thin Whois database is not what is making domain names<br>
available--so the SOA records for the domain is not a good<br>
example, even if someone put PII in that field--as that is an<br>
issue of domain names being publicly available together with DNS.<br></span>
Totally outside the framework of discussion.____<br>
<br>
__ __<span class=""><br>
<br>
The creation date of a domain, the NS records, when the domain was<br>
last updated, and the registrar of record are simply not by any<br>
stretch of the imagination arguably PII by virtue of Whois. This<br>
is information that was voluntarily made public by virtue of using<br></span>
the public Internet which relies on DNS. ____<br>
<br>
__ __<span class=""><br>
<br>
Privacy enthusiasts can use .Onion if they want to. But if they<br>
want to use the open Internet, that means some basic data by<br>
definition is publicly available in the DNS. If they want to<br>
protect their privacy, then they need to use common sense and not<br></span>
put information they dont want to be made public into the public. ____<br>
<br>
__ __<span class=""><br>
<br>
The creation date is as a matter of fact, used as one of several<br>
indicators to show a domain engaged in malicious activity was<br>
unlikely a victim of being compromised. It is a critical piece of<br></span>
data but also not by any stretch of the wildest imagination PII. ____<br>
<br>
__ __<span class=""><br>
<br>
The principle of proportionality doesn't apply to thin data unless<br>
you want to argue it applies to the very fact a domain name record<br>
was created in the public Internet. By creating the record, a user<br>
has chosen to make that record's existence public--regardless of<br>
whether they use privacy protection or not. If I register my name<br>
and birthday as a domain name, it is PII, but PII that I chose to<br>
be made publicly available by virtue of creating the domain and<br>
putting it into the zone. Does that mean I am somehow entitled to<br>
have all the RFCs re-written for me and for the public Internet<br>
to be made private? Of course not. So when people make things<br>
public voluntarily by virtue of participating in society, the<br>
principles of data protection apply differently. Let's remember we<br>
are talking about the public, open Internet here. Nobody has to<br>
participate that doesn't want to, just like if I don't want anyone<br>
to see my license plate number on the road, I don't have to drive<br></span>
a car either. ____<br>
<br>
__ __<br>
<br>
__ __<br>
<br>
__ __<span class=""><br>
<br>
On Wed, 31 May 2017 at 16:50 Dotzero <<a href="mailto:dotzero@gmail.com" target="_blank">dotzero@gmail.com</a><br></span>
<mailto:<a href="mailto:dotzero@gmail.com" target="_blank">dotzero@gmail.com</a>>> wrote:____<span class=""><br>
<br>
Translation (per Google translate) of what Volker posted:<br>
<br>
"On the basis of the ECJ ruling, the factual feature" personal<br>
data "of § 12 (1) and (2) TMG in conjunction with § 3 (1) BDSG<br>
must be interpreted in accordance with the guidelines: a<br>
dynamic IP address provided by a provider of online media<br>
services In the case of access by a person to a website, which<br>
is made generally accessible by the provider, constitutes a<br>
(protected) personal date for the provider.<br>
<br>
The IP address can only be stored as a personal date under the<br>
prerequisites of § 15 (1) TMG. This provision is to be applied<br>
in accordance with the provisions of Article 7 (f) of<br>
Directive 95/46 EC, as interpreted by the Court of Justice, to<br>
the effect that a provider of on-line media services may<br>
collect personal data of a user without the consent of the<br>
user of the services To the extent that their collection and<br>
use is necessary to ensure the general functioning of the<br>
services. However, there is a need to balance the interests<br></span>
and the basic rights and freedoms of the users. "____<br>
<br>
__ __<span class=""><br>
<br>
On Wed, May 31, 2017 at 9:47 AM, Volker Greimann<br></span>
<<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a> <mailto:<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.<wbr>net</a>>><br>
wrote:____<span class=""><br>
<br>
Why, just this month the German Bundesgerichtshof<br>
confirmed this in a review of a decision of the state<br></span>
court Berlin ( Az. VI ZR 135/13):____<br>
<br>
<a href="http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py?Gericht=bgh&Art=pm&Datum=2017&Sort=3&nr=78289&pos=0&anz=74____" rel="noreferrer" target="_blank">http://juris.bundesgerichtshof<wbr>.de/cgi-bin/rechtsprechung/<wbr>document.py?Gericht=bgh&Art=<wbr>pm&Datum=2017&Sort=3&nr=78289&<wbr>pos=0&anz=74____</a><span class=""><br>
<br>
It followed the decision of the European Court from<br></span>
October last year:____<br>
<br>
C-582/14, NJW 2016, 3579____<br>
<br>
The German explanation:____<br>
<br>
/"Auf der Grundlage des EuGH-Urteils ist das<span class=""><br>
Tatbestandsmerkmal "personenbezogene Daten" des § 12 Abs.<br>
1 und 2 TMG in Verbindung mit § 3 Abs. 1 BDSG<br>
richtlinienkonform auszulegen: Eine dynamische IP-Adresse,<br>
die von einem Anbieter von Online-Mediendiensten beim<br>
Zugriff einer Person auf eine Internetseite, die dieser<br>
Anbieter allgemein zugänglich macht, gespeichert wird,<br>
stellt für den Anbieter ein (geschütztes)<br></span>
personenbezogenes Datum dar. /____<br>
<br>
/Als personenbezogenes Datum darf die IP-Adresse nur unter<span class=""><br>
den Voraussetzungen des § 15 Abs. 1 TMG gespeichert<br>
werden. Diese Vorschrift ist richtlinienkonform<br>
entsprechend Art. 7 Buchst. f der Richtlinie 95/46 EG – in<br>
der Auslegung durch den EuGH – dahin anzuwenden, dass ein<br>
Anbieter von Online-Mediendiensten personenbezogene Daten<br>
eines Nutzers dieser Dienste ohne dessen Einwilligung auch<br>
über das Ende eines Nutzungsvorgangs hinaus dann erheben<br>
und verwenden darf, soweit ihre Erhebung und ihre<br>
Verwendung erforderlich sind, um die generelle<br>
Funktionsfähigkeit der Dienste zu gewährleisten. Dabei<br>
bedarf es allerdings einer Abwägung mit dem Interesse und<br></span>
den Grundrechten und -freiheiten der Nutzer."/____<br>
<br>
Hope this helps.____<br>
<br>
__ __<br>
<br>
Am 31.05.2017 um 15:38 schrieb Paul Keating:____<span class=""><br>
<br>
See: recent Europrean court decisions on IP<br></span>
addresses as PII.____<br>
<br>
__ __<span class=""><br>
<br>
Can you please provide the citations? I a-m not aware<br></span>
of any court decision issuingsuch a broad ruling. ____<br>
<br>
__ __<br>
<br>
Thanks,____<br>
<br>
__ __<br>
<br>
Paul<br>
<br>
Sent from my iPad____<span class=""><br>
<br>
<br>
On 31 May 2017, at 12:20, Volker Greimann<br>
<<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a><br></span>
<mailto:<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.<wbr>net</a>>> wrote:____<span class=""><br>
<br>
In some cases the ability to use data set A in<br>
combination with data set B to enable one to<br></span>
identify an individual turns data set A into PII. ____<span class=""><br>
<br>
See: recent Europrean court decisions on IP<br></span>
addresses as PII.____<span class=""><br>
<br>
I am with you in viewing thin data as rather<br>
unlikely to be defined as PII, but depending on<br>
how this data is used it is not inconceivable that<br>
it may be found to contain PII depending on the<br></span>
use. Unlikely, but not impossible.____<br>
<br>
Volker____<br>
<br>
__ __<br>
<br>
Am 30.05.2017 um 23:40 schrieb Paul Keating:____<span class=""><br>
<br>
Im sorry but i don't see the logic here (or<br></span>
the legal constraint)____<br>
<br>
__ __<span class=""><br>
<br>
Privacy laws protect personal data of<br>
INDIVIDUALS. They do t protect non-personal<br></span>
data or data from non-individuals.____<br>
<br>
__ __<span class=""><br>
<br>
Nothing on the list below is personal data.<br>
And no e of the principles given by Natalie<br></span>
apply.____<br>
<br>
__ __<span class=""><br>
<br>
The fact that i could use the data to obtain<br>
other data is irrelevant. I can use a car to<br>
rob a bank but that itself is not a reason to<br></span>
restrict access to automobiles.____<br>
<br>
__ __<span class=""><br>
<br>
Me thinks you are trying to create a scarcity<br>
for some reason.<br>
<br></span>
Sent from my iPad____<span class=""><br>
<br>
<br>
On 30 May 2017, at 23:22, Chris Pelling<br>
<<a href="mailto:chris@netearth.net" target="_blank">chris@netearth.net</a><br></span>
<mailto:<a href="mailto:chris@netearth.net" target="_blank">chris@netearth.net</a>>> wrote:____<br>
<br>
ok - a thought :____<br>
<br>
__ __<span class=""><br>
<br>
Thin data includes nameservers, being able<br></span>
to *_mass_* collect thin data gaining NS<span class=""><br>
information then allows you to do a DIG of<br>
a SOA record on the DNS service to gain<br></span>
the email address of the hostmaster : ____<br>
<br>
__ __<span class=""><br>
<br>
Some examples (radomly picked from the<br></span>
list) :____<br>
<br>
<a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a> <<a href="http://gmail.com" rel="noreferrer" target="_blank">http://gmail.com</a>> :____<br>
<br>
SOA <a href="http://ns1.google.com" rel="noreferrer" target="_blank">ns1.google.com</a><br>
<<a href="http://ns1.google.com" rel="noreferrer" target="_blank">http://ns1.google.com</a>>.<br>
<a href="http://dns-admin.google.com" rel="noreferrer" target="_blank">dns-admin.google.com</a><br>
<<a href="http://dns-admin.google.com" rel="noreferrer" target="_blank">http://dns-admin.google.com</a>>. 157458041<br>
900 900 1800 60<br>
<a href="http://netearthone.com" rel="noreferrer" target="_blank">netearthone.com</a> <<a href="http://netearthone.com" rel="noreferrer" target="_blank">http://netearthone.com</a>>____<br>
<br>
SOA <a href="http://ns1.netearth.net" rel="noreferrer" target="_blank">ns1.netearth.net</a><br>
<<a href="http://ns1.netearth.net" rel="noreferrer" target="_blank">http://ns1.netearth.net</a>>.<br>
<a href="http://root.netearthone.com" rel="noreferrer" target="_blank">root.netearthone.com</a><br>
<<a href="http://root.netearthone.com" rel="noreferrer" target="_blank">http://root.netearthone.com</a>>. <a href="tel:2016090201" value="+12016090201" target="_blank">2016090201</a><br>
<tel:%28201%29%20609-0201> 14400 3600<br>
1209600 86400____<br>
<br>
<a href="http://law.es" rel="noreferrer" target="_blank">law.es</a> <<a href="http://law.es" rel="noreferrer" target="_blank">http://law.es</a>>____<br>
<br>
SOA <a href="http://ns1.eurodns.com" rel="noreferrer" target="_blank">ns1.eurodns.com</a><br>
<<a href="http://ns1.eurodns.com" rel="noreferrer" target="_blank">http://ns1.eurodns.com</a>>.<br>
<a href="http://hostmaster.eurodns.com" rel="noreferrer" target="_blank">hostmaster.eurodns.com</a><br>
<<a href="http://hostmaster.eurodns.com" rel="noreferrer" target="_blank">http://hostmaster.eurodns.com</a><wbr>>.<br>
<a href="tel:2016061402" value="+12016061402" target="_blank">2016061402</a> <tel:%28201%29%20606-1402><br>
43200 7200 1209600 86400____<br>
<br>
<a href="http://riskiq.net" rel="noreferrer" target="_blank">riskiq.net</a> <<a href="http://riskiq.net" rel="noreferrer" target="_blank">http://riskiq.net</a>>____<br>
<br>
SOA <a href="http://ns-1754.awsdns-27.co.uk" rel="noreferrer" target="_blank">ns-1754.awsdns-27.co.uk</a><br>
<<a href="http://ns-1754.awsdns-27.co.uk" rel="noreferrer" target="_blank">http://ns-1754.awsdns-27.co.u<wbr>k</a>>.<br>
<a href="http://awsdns-hostmaster.amazon.com" rel="noreferrer" target="_blank">awsdns-hostmaster.amazon.com</a><br>
<<a href="http://awsdns-hostmaster.amazon.com" rel="noreferrer" target="_blank">http://awsdns-hostmaster.amaz<wbr>on.com</a>>. 1<br>
7200 900 1209600 86400____<br>
<br>
__ __<span class=""><br>
<br>
Now as you can see - those above examples<br>
allow you to get (or build) an email<br>
list. Most will normally point to the<br>
providers service, but, some that are<br></span>
DIY'ing their hosting, it might not be.____<br>
<br>
__ __<br>
<br>
Kind regards,<br>
<br>
Chris____<br>
<br>
__ __<br>
<br>
------------------------------<wbr>------------------------------<wbr>------------<br>
<br>
*From: *"allison nixon" <<a href="mailto:elsakoo@gmail.com" target="_blank">elsakoo@gmail.com</a><br>
<mailto:<a href="mailto:elsakoo@gmail.com" target="_blank">elsakoo@gmail.com</a>>><br>
*To: *"nathalie coupet"<br>
<<a href="mailto:nathaliecoupet@yahoo.com" target="_blank">nathaliecoupet@yahoo.com</a><br>
<mailto:<a href="mailto:nathaliecoupet@yahoo.com" target="_blank">nathaliecoupet@yahoo.c<wbr>om</a>>><br>
*Cc: *"gnso-rds-pdp-wg"<br>
<<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<mailto:<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.<wbr>org</a>>><br>
*Sent: *Tuesday, 30 May, 2017 21:52:32<br>
*Subject: *Re: [gnso-rds-pdp-wg] Principle<br>
on Proportionality for<br>
"Thin Data"access____<br>
<br>
__ __<span class=""><br>
<br>
so can you name one specific example of<br></span>
how someone could abuse thin data?____<br>
<br>
__ __<span class=""><br>
<br>
On Tue, May 30, 2017 at 4:50 PM, nathalie<br>
coupet via gnso-rds-pdp-wg<br>
<<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br></span>
<mailto:<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.<wbr>org</a>>> wrote:____<br>
<br>
*Abuse* is the improper usage or<br>
treatment of an entity<br>
<<a href="https://en.wikipedia.org/wiki/Entity" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Entity</a>>, often<br>
to unfairly<br>
<<a href="https://en.wikipedia.org/wiki/Distributive_justice" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Distributive_justice</a>> or<span class=""><br>
improperly gain benefit. In our<br>
context, abuse is the improper usage<br>
of WHOIS/RDS to unfairly or improperly<br>
gain access to information or to game<br></span>
the system. ____<br>
<br>
__ __<span class=""><br>
<br>
Here are some of the overarching<br>
principles which should guide us when<br></span>
building RDS: ____<br>
<br>
__ __<br>
<br>
DATA LIFECYCLE<br>
PRIVACY PRINCIPLE<br>
PROTECTION MEASURE____<span class=""><br>
<br>
Collection<br>
Proportionality and purpose<br>
specification Data<br></span>
minimisation, Data quality____<span class=""><br>
<br>
Storage<br>
Accountability, Security measures,<br>
Sensitive data<br>
Confidentiality, Encryption,<br></span>
Pseudonomisation____<span class=""><br>
<br>
Sharing and processing Lawfulness and<br>
fairness, Consent, Right of access<br>
Data access control, Data leakage<br></span>
prevention____<span class=""><br>
<br>
Deletion<br>
Openness, Right to erasure<br>
Retention,<br></span>
Archival, Erasure____<br>
<br>
__ __<br>
<br>
__ __<span class=""><br>
<br>
If such principles are not respected,<br>
ICANN will be liable. Consumers don't<br>
need to have all the thin data when<br>
making a query. This could protect<br>
them and enable them to have access to<br>
the RDS without raising much<br></span>
opposition. ____<br>
<br>
__ __<span class=""><br>
<br>
Now, we could discuss the possibility<br>
for broader query types. These<br>
principles would still apply, but<br>
would be contextualized in order to<br>
take into account new sets of<br>
parameters for each broader query. By<br>
increasing granularity as much as<br>
possible, while applying these<br>
aformentioned principles, we just<br>
might find a way to accomodate<br></span>
everyone. ____<br>
<br>
__ __<br>
<br>
__ __<br>
<br>
____<br>
<br>
Nathalie ____<br>
<br>
__ __<span class=""><br>
<br>
On Tuesday, May 30, 2017 4:00 PM, John<br>
Horton <<a href="mailto:john.horton@legitscript.com" target="_blank">john.horton@legitscript.com</a><br></span>
<mailto:<a href="mailto:john.horton@legitscript.com" target="_blank">john.horton@legitscrip<wbr>t.com</a>>><br>
wrote:____<br>
<br>
__ __<span class=""><br>
<br>
I was going to reply to Natalie's<br>
email as well, but Paul's comments<br></span>
capture my thoughts, so: *+1. *____<br>
<br>
<br>
____<br>
<br>
John Horton<br>
President and CEO, LegitScript____<br>
<br>
____<br>
<br>
__ __<br>
<br>
*Follow****Legit**Script*: LinkedIn<br>
<<a href="http://www.linkedin.com/company/legitscript-com" rel="noreferrer" target="_blank">http://www.linkedin.com/compa<wbr>ny/legitscript-com</a>><br>
| Facebook<br>
<<a href="https://www.facebook.com/LegitScript" rel="noreferrer" target="_blank">https://www.facebook.com/Legi<wbr>tScript</a>> |<br>
Twitter<br>
<<a href="https://twitter.com/legitscript" rel="noreferrer" target="_blank">https://twitter.com/legitscri<wbr>pt</a>> |<br>
_Blog<br>
<<a href="http://blog.legitscript.com/" rel="noreferrer" target="_blank">http://blog.legitscript.com/</a>><wbr>_ | Google+<br>
<<a href="https://plus.google.com/112436813474708014933/posts" rel="noreferrer" target="_blank">https://plus.google.com/11243<wbr>6813474708014933/posts</a>>____<br>
<br>
__ __<br>
<br>
____<br>
<br>
__ __<span class=""><br>
<br>
On Tue, May 30, 2017 at 12:57 PM, Paul<br>
Keating <<a href="mailto:paul@law.es" target="_blank">paul@law.es</a><br></span>
<mailto:<a href="mailto:paul@law.es" target="_blank">paul@law.es</a>>> wrote:____<br>
<br>
Natalie,____<br>
<br>
__ __<span class=""><br>
<br>
Thank you for the email. Im<br>
copying the list because i see<br>
others have replied to your<br></span>
comment.____<br>
<br>
__ __<span class=""><br>
<br>
I strenuously object to the<br>
concept. We are discussing THIN<br>
DATA ONLY HERE. Unless someone<br>
can explain to me why any of this<br>
data set has privacy concerns this<br>
is a non-issue. I would certainly<br>
appreciate someone explaining<br>
what, if any, privacy issues are<br></span>
perceived to be at issue here.____<br>
<br>
__ __<span class=""><br>
<br>
Moreover, while you suggest that<br>
the idea escapes the need to<br>
declare a purpose, it does nothing<br>
but reinforce a subjective<br>
criteria based system in which the<br>
declared purpose is used to<br>
somehow limit the data being<br></span>
retrieved.____<br>
<br>
__ __<span class=""><br>
<br>
If i am missing something please<br></span>
let me know. ____<br>
<br>
<br>
Paul____<br>
<br>
<br>
Sent from my iPad____<span class=""><br>
<br>
<br>
On 30 May 2017, at 21:08, nathalie<br>
coupet via gnso-rds-pdp-wg<br>
<<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br></span>
<mailto:<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.<wbr>org</a>>> wrote:____<br>
<br>
Hi Paul,____<br>
<br>
__ __<span class=""><br>
<br>
In the context of thin data,<br>
in view of the opposition of<br>
some to allow unauthenticated<br>
access to all the thin data,<br>
the principle of<br>
proportionality serves as an<br>
over-arching principle at this<br>
particular phase in our work<br>
in order to protect data from<br>
abuse while not restricting<br></span>
access. ____<span class=""><br>
<br>
Thin data must be<br>
proportionate to the query, be<br>
useful for that particular<br>
query. All and any other thin<br>
data foreign to this query<br>
should not be shared. This<br>
principle potentially avoids<br>
having to resort to<br>
'legitimate purposes' which<br>
cannot be verified for<br></span>
unauthenticated access. ____<br>
<br>
____<br>
<br>
____<br>
<br>
Nathalie ____<br>
<br>
__ __<span class=""><br>
<br>
On Tuesday, May 30, 2017 2:44<br>
PM, "Gomes, Chuck via<br>
gnso-rds-pdp-wg"<br>
<<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br></span>
<mailto:<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.<wbr>org</a>>><br>
wrote:____<br>
<br>
__ __<span class=""><br>
<br>
Because Nathalie was the<br>
originator and was unable to<br>
speak on the call, I encourage<br>
her to describe the nature of<br></span>
the issue on this thread.____<br>
<br>
____<br>
<br>
Chuck____<br>
<br>
____<br>
<br>
*From:*gnso-rds-pdp-wg-bounces<wbr>@icann.<br>
<mailto:<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank">gnso-rds-pdp-wg-bounce<wbr>s@icann.org</a>><br>
<br>
</blockquote><span class="">
--<br>
jonathan matkowsky, vp - ip & head of global brand threat mitigation<br>
<br>
<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/gnso-rds-pdp-wg</a><br>
<br>
</span></blockquote>
<br>
<br>
<br>
-- <br>
"Catch the Magic of Linux..."<br>
------------------------------<wbr>------------------------------<wbr>------------<br>
Michael Peddemors, President/CEO LinuxMagic Inc.<br>
Visit us at <a href="http://www.linuxmagic.com" rel="noreferrer" target="_blank">http://www.linuxmagic.com</a> @linuxmagic<br>
------------------------------<wbr>------------------------------<wbr>------------<br>
A Wizard IT Company - For More Info <a href="http://www.wizard.ca" rel="noreferrer" target="_blank">http://www.wizard.ca</a><br>
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.<br>
------------------------------<wbr>------------------------------<wbr>------------<br>
<a href="tel:604-682-0300" value="+16046820300" target="_blank">604-682-0300</a> Beautiful British Columbia, Canada<br>
<br>
This email and any electronic data contained are confidential and intended<br>
solely for the use of the individual or entity to which they are addressed.<br>
Please note that any views or opinions presented in this email are solely<br>
those of the author and are not intended to represent those of the company.<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/gnso-rds-pdp-wg</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">_________________________________<br>Note to self: Pillage BEFORE burning.</div>
</div>