<html>
<body>
Thanks Jonathan. You beat me to it.<br><br>
The temp spec is what it is, and we may want to change it based on what
we believe are "user" needs. I do not believe that the temp
spec nor the EPDP need principles that echo what is in the GDPR. They are
the premise under which this work will be done. So, for instance, the
blurb below on consent is simply tailoring the GDPR consent rules to
WHOIS (mentioning escrow, and registries). That is effectively a given
(of course, consent applies ONLY to data that we cannot claim is
essential to collect).<br><br>
Jonathan's bullet point is the lead-in. The first question we need to
address is WHY we want to or feel we need to contribute to this process.
Or to be clearer, why do USERS (not registrants) even care how we
implement GDPR with respect to WHOIS?<br><br>
Alan<br><br>
At 10/07/2018 05:27 PM, Jonathan Zuck wrote:<br><br>
<blockquote type=cite class=cite cite="">Thanks Holly for getting this
started. I guess what we’re after are some basic principles on
our <i>perspective</i> on the GDPR. The temp spec is the temp spec so
some of this will apply for sure, if we reach some consensus on these but
there are areas that are simply part of the law over which we don’t
have influence. A principle might be something like<br>
<ol>
<li>The ALAC feels responsible to represent the interests of
non-registrants more so than registrants as they represent the majority
of users.
</ol>I’m not saying we’ve agreed to that but that’s the kind of
filter we could send our reps in with?<br>
Jonathan<br>
<br>
<br>
<b>From: </b>ALAC <alac-bounces@atlarge-lists.icann.org> on behalf
of "h.raiche@internode.on.net"
<h.raiche@internode.on.net><br>
<b>Reply-To: </b>"h.raiche@internode.on.net"
<h.raiche@internode.on.net><br>
<b>Date: </b>Tuesday, July 10, 2018 at 5:22 PM<br>
<b>To: </b>ALAC List <alac@atlarge-lists.icann.org>, A t
<staff@atlarge.icann.org><br>
<b>Subject: </b>[ALAC] Draft Principles for GDPR<br>
<br>
Folks<br>
<br>
Since we all think principles are a good idea, I have set down the basics
from the Temporary Spec - very simplistic, but it's a start. What
we need now is discussion on the principles.<br>
<br>
Evin - I'm not sure if you have a new wiki page for discussion on the
temporary spec, but if not, would you create on.<br>
<br>
And Olivier - the Temporary Spec necessarily will deal with access - at
the least, guiding principles, so whoever is on the EPDP will have some
guidance on our red lines on access.<br>
<br>
So please everyone - comments<br>
<br>
Thanks<br>
<br>
Holly<br>
<br><br>
<b>Temporary Specification for gTLD Registration Data <br>
</b> <br>
<br>
<b>Principles for requirements to replace the RAA/Registry
Requirements<br>
</b><i>(within the context of compliance with the GDPR)<br>
<br>
</i><b>Purpose of Collection of Data<br>
</b><br>
Quoting from the Temporary Spec which is quoting from the ICANN
Bylaws:<<br><br>
<i>purpose is to coordinate the bottom-up, multistakeholder development
and implementation of policies “[f]or which uniform or coordinated
resolution is reasonably necessary to facilitate the openness,
interoperability, resilience, security and/or stability of the DNS
including, with respect to gTLD registrars and registries” <br>
Purpose includes<br>
</i><br>
· resolution of disputes
regarding the registration of domain names (as opposed to the use of such
domain names, but including where such policies take into account use of
the domain names); <br><br>
· maintenance of and access to
accurate and up-to-date information concerning registered names and name
servers; <br><br>
· procedures to avoid
disruptions of domain name registrations due to suspension or termination
of operations by a registry operator or a registrar (e.g., escrow); and
<br><br>
· the transfer of registration
data upon a change in registrar sponsoring one or more registered names.
<br><br>
<br><br>
the Bylaws specifically obligate ICANN, in carrying out its mandate, to
“adequately address issues of competition, consumer protection,
security, stability and resiliency, malicious abuse issues, sovereignty
concerns, and rights protection” <br>
<i> <br>
</i><b>Geographic Coverage of EPDP Outcome:<br>
</b><br>
· Apply globally <b>or<br>
</b><br>
· Apply only to European Economic Area
(the coverage of the GD<br>
R) and otherwise lesser requirements (existing RAA requirements?)<br>
<br>
<b>Data Collected<br>
</b><br>
· ‘Thick Whois” – based on the
differing uses of the data is listed in the purpose above OR<br><br>
· Some lesser amount of information<br>
<br>
<b>Consent<br>
</b><br>
· Registrants must be told, at the time of
collection, what personal information is collected, why the collection
is necessary to achieve the purposes, who will have access and in
what circumstances access will be given to what information, and
all circumstances in which the data will be transferred (to Registry,
Escrow) and where heldThey must also be told their consent can be
withdrawn at any time (and consequences of withdrawal) and how to
withdraw consent<br>
<br>
<b>Access to Data Tiered access (largelly what is in the Technical
Specification)<br>
</b><br>
· Applies to all Registrants natural or
corporatte persons<br><br>
· Information generally publicly
available<br><br>
o Registrant name<br><br>
o Anonymised email or other anonymous contact means<br><br>
· Access to other personal information
<br><br>
o Only to accredited entities (not individuals) <br><br>
o Only in specific circumstances that warrant access<br><br>
<br>
_______________________________________________<br>
ALAC mailing list<br>
ALAC@atlarge-lists.icann.org<br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/alac" eudora="autourl">
https://atlarge-lists.icann.org/mailman/listinfo/alac</a><br><br>
At-Large Online:
<a href="http://www.atlarge.icann.org/" eudora="autourl">
http://www.atlarge.icann.org</a><br>
ALAC Working Wiki:
<a href="https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC" eudora="autourl">
https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC</a>
)</blockquote></body>
</html>