<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Michael, <br>
<br>
You are comments regarding "thin" whois are spot on. <br>
<br>
Though it will warrant further discussion for the WG, the data
minimisation principle under the GDPR is, in my opinion, not
something to be easily dismissed, we all can read each week about
some company who had a data breach. It is a scary number. Data
breaches under the GDPR and many other data protection laws carry
a considerable burden. <br>
<br>
I think the argument to pass data to a registry is somewhat weak
when you consider that the oldest and largest registry only
requires the following data elements for domain registrations. <br>
<br>
-domain name<br>
-nameservers<br>
-registration period<br>
<br>
Best, <br>
<br>
Theo Geurts<br>
</p>
<br>
<div class="moz-cite-prefix">On 13-1-2018 19:50, Michael Palage
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:05ca01d38c9f$54554740$fcffd5c0$@palage.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
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.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hello All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So ICANN in a traditional Friday night news
dump has published its long awaited three GDPR Interim
Compliance Models, see <a
href="https://www.icann.org/news/blog/data-protection-and-privacy-update-seeking-community-feedback-on-proposed-compliance-models"
moz-do-not-send="true">https://www.icann.org/news/blog/data-protection-and-privacy-update-seeking-community-feedback-on-proposed-compliance-models</a>
. Before diving into the substance of this document and the
specifics of the three models, I would like to offer some high
level commentary.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">During the ICANN meeting in Abu Dhabi
meeting Göran made reference to models that ICANN was
evaluating but which he did not disclose at that meeting.
Given the quickly evolving nature of all things GDPR I wanted
to give ICANN’s CEO the benefit of the doubt. However, after
the typical post ICANN meeting recovery period, I was
disappointed when there was still no sharing of the ICANN
models. During the ICANN IGF Session in Geneva last month, I
specifically asked remotely about ICANN sharing its current
best thinking on the three models so that the community could
have maximum time to evaluate ICANN’s thinking.
Unfortunately, Göran was non-responsive to my question/request
about sharing these models. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Further disappointing from a
process/transparency standpoint is that ICANN staff has
proposed to only provide a seventeen (17) day comment period.
I appreciate the tight timeline that ICANN is under given the
looming May compliance date set forth in the GDPR. However, I
myself and others would have been a little more understanding
if ICANN would have shared their preliminary models with the
community sooner as opposed to later. Again this was clearly
the point of my second intervention during the ICANN IGF
session last month. An additional disappointment is that it
does not appear that ICANN staff took the time to analyze and
provide feedback into the third party models that were
submitted by the January 10<sup>th</sup> deadline. The fact
that ICANN staff did not disclose these Models earlier, is
proposing to act inconsistently with it stated public comment
policy, and does not appear to have properly analyzed the
models and legal analysis submit by the community conveys the
impression that the final outcome is already a fait accompli.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Substantive Comments<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In the section entitled “Commonalities
Across All Models” I found it incredibly odd that ICANN used
the word “may collect” and “may transfer” in points 1, 2 and
3. For those lawyers, and those that play ones within ICANN’s
PDP, the use of the words “may”, “shall”, “must” and “should”
have significant legal significance. My initial reading, and
I am open to being corrected by ICANN staff or other community
members, is that ICANN is looking to remove itself from
mandating that its contracting parties collect any data.
However, when I got to Appendix #1, that document explicitly
states that the Full Thick Data Set would be transferred from
Registrars to Registries, and from Registrars and Registries
to Escrow Agents. I really think ICANN legal needs to clarify
this choice of word and whether it is seeking to extricate
itself from the Data Controller label that the Hamilton and
WSGR bestowed upon it. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While I appreciate the contributions made
by three Hamilton memos, I was confused by how Hamilton in
most circumstances would take incredibly conservative
positions regarding most issues expect for in connection with
the GDPR requirements concerning Data Minimization. The
question which I personally have not received a satisfactory
answer to is the following, VeriSign has shown in connection
with the operational of the .COM and .NET TLDs, that “most”
registries do not need thick whois/RDS data so how can ICANN
and the community defend its consensus policy calling for
mandatory thick whois? <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Territorial Applicability of the Different
Models:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As part of its analysis ICANN attempts to
distinguish each model on the basis of its territorial
applicability. Model 3 and Model 2B are touted as applying to
all registrations on a global basis, whereas Models 1 and 2A
undergo a three prong test. However, when you look at the
extraterritorial scope of the GDPR, i.e. registry/registrars
established in EEA; registry/registrar providing services
targeting registrants in EEA; or process located within EEA,
the net effect is the vast majority of gTLD domain name
registrations being covered. Therefore, it is probably best
that ICANN move forward with any model(s) covering all
registrations, as a piecemeal approach would likely lead to
consumer confusion and business uncertainty for all economic
actors in the eco-system. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Access to Non-Public Information (e.g.
Tiered Access)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Unlike the territorial applicability
discussed above which really provide little variation, there
is a more substantial deviation among the models regarding
access to non-public information. There are three basic
variations discussed in the three models: self-certification
(Model 1); formal accreditation (Model 2); legal due process
(Model 3). While ICANN has chosen to limit each type of
non-public access programs to a specific model class, there
appears to be no reason why different programs (e.g.
self-certification/formal/legal-due process) could not apply
to each Model.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Model 1 and Model 2 state” [r]egistries and
registrars <b>may</b>, <b>but would not be required by
ICANN, to provide additional access to non-public WHOIS</b>
as long as it complies with GDPR and other applicable laws
(emphasis added). This language appears to conflict with the
preceding paragraph in Model 1 which stated that “[t]o access
registration data not published in the public WHOIS,
registries and registrars <b>would respond to requests</b>.”
Model 2 has similar qualifying language, e.g. “would provide
access.” Again I want everyone to focus on ICANN’s use of the
word “would”, not “shall” or “must.” If providing access to
additional non-public WHOIS is optional, what is the incentive
for Registries/Registrars to do so, other that charging for it
as a value added service? Why would a Registry/Registrar do so
voluntarily and potentially expose themselves to liability,
because some self-certifying third party made a mistake in
connection with their disclosure request. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My personal opinion, is that given that the
future of WHOIS/RDS will be founded upon RDAP, it is probably
best that all access to Registrant Data WHOIS/RDAP be done
through a common set of credentials. Instead of law
enforcement, IP attorneys, network operators having to create
a set of credentials with thousands of registrars and
registries, they should be able to obtain one set of
credentials from ICANN that could be used across all
registration authorities. I would propose that ICANN be
tasked with providing credentials to third parties and that
the verification process would require both email and phone
verification. This type of verification could be largely
automated as is happens today with many major internet service
offering. Registrants, Registrars, and Registries would also
have the ability to challenge a third party’s credential if
they were able to establish a violation of the terms of use.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Another personal comment is that instead of
trying to distinguish between self-certification and formal
accreditation, a better demarcation would be between one-off
lookup queries and more complex queries (i.e. multi-field,
wild card, multiple results, etc.). With one-off lookup
queries using a universal credential issued by ICANN there is
less of a chance of data mining that takes place today, plus
the ability of a third party to lose their credential if they
abuse their access which registrars and registries would now
be able to more closely monitor. The specifics of the program
involving more complex queries and how to grant access to
these entities (including a potential bonding requirement) is
something that is highly unlikely to take place in the near
team, i.e. prior to May 2018. However, the self-certification
framework discussed above could provide ICANN valuable
experience on how to design/implement such a program.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Registrant Consent<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Both Models 1 and 2 include the text
“unless the registrant otherwise grants permission, registrars
and registries would be required to display the following
minimum data in public WHOIS.” I think this needs to be
rewritten to provide more clarity about the Registrant’s right
to withhold consent initially, and if the Registrant’s changes
its mind at a later date. I believe the data retention
policies in all models may need to be adjusted ASAP once the
registrant withdraws its previously given consent. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Model 1 <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While not as complex to implement as Model
3, the need to distinguish between Natural and Legal persons
is not a solution that can quickly be implemented across the
whole domain name industry on an interim basis. Specifically
in connection with the need for Registries to track consent at
the registry level, i.e. when it is given and when it is
withdrawn. In connection with Legal persons, Model 1 proposes
to make all “thick” registrant data available just as it is
available today, whereas Natural persons would be able to
withhold the following Registrant data fields: (i) email and
phone number of registrant AND (ii) name and postal address of
technical and administrative contacts. However, if ICANN
permits registrars to withhold data transfers to registries
(as discussed above), what data would registries be required
to display in their WHOIS/RDS output? This model also does
not seem to account for the need to protection personal data
associated with employees of Legal persons who may appear in
public WHOIS. Additionally, while Legal person registrants
often make a distinction between Registrant and Administrative
contacts, most individual registrants as such myself do not.
Therefore, as an proposed “interim” solution I do not see how
this is the most conservative approach for contracting parties
to minimize their legal exposure. I believe it would be
prudent to engaged with all available DPA to see if this
proposal is sufficient as a lowest common denominator before
imposing substantial costs on Registrars and Registries for
less than compliant interim Model.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Model 2 <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is the most conservative legal
approach for Registries and Registrars concerned about
potential legal exposure, allowing for the publication of the
email for the Administrative and Technical contacts. This is
also potentially the quickest to implement from a data
publication perspective. However, as noted above for many
individuals (myself included), personal PII may still be
included in these data fields when registering a domain name.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Model 3 <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This model seems to be nothing more than a
straw man put forward by ICANN staff. The technical and
administrative burdens to analyze each individual data element
and then make a determination if it includes personal data as
part of an “interim” solution implemented by May 2018 is
beyond herculean. In fact, it borders on nonsensical. The
proposed framework for access to non-public registrant data is
also very draconian, and appears to be an attempt to alienate
legal, LEA and business interests. Because this model has
almost ZERO chance of receiving support from Registration
Authorities (registries and registrars) it is hard to justify
spending any additional time trying to analyze this model. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Final Thoughts<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Sadly, given these models as presented I
see little chance of the ICANN community reaching a consensus
on a single model. Therefore, Göran will need to make a legal
decision to minimize ICANN Inc.’s legal exposure. If you have
been reading the tea leaves, and then take into account how
ICANN has been less than forth coming in the publication of
these models over the last couple of months, if I was a
betting man I would probably place my GDPR bet on a modified
Model 2. Specifically, ICANN permits the withholding of
Registrant personal data in the public whois, but instead
implements the self-certification model for access to
non-public whois while throwing a bone to the IP and LEA
community that it will diligently work on a formal
accreditation process (do not hold your breath). <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The more likely result of this less than
optimal solution is that European Registries and Registrars
will wait until they complete their DPIAs and for ICANN to
state its public position before engaging directly with their
respective DPAs under Article 36. An interesting question
that may be posed to ICANN is - has it taken the suggestion
posed in one of the Hamilton memos about engaging directly
with a DPA to seek advice/guidance? Since the ICANN bylaws
require a minimum 21 day public comment period before the
ICANN Board takes an action on a public policy decision (i.e.
I would submit a compliance waiver from consensus policies
should require Board approval), I do not see ICANN making any
final statement before the Puerto Rico meeting in March. That
will then result in a bunch of chaotic negotiations between
contracting parties and DPAs shortly thereafter, or potential
before. In fact it would not surprise me if one of more DPAs
wanted to proactively comment on ICANN’s compliance Model. Net
result, less clarity and less business predictability. This is
truly a test that will rock the foundation of the ICANN
bottom-up multi-stakeholder model. And while not intending
to be the bearer of bad news, these types of national law
conflicts are likely to occur with more regularity. I would
encourage list participants to watch the IGF session on data
localization as this is the next crisis that will be
confronting ICANN, and it would be extremely prudent for ICANN
to consider how any solution it adopts for national privacy
laws also scales to meet the evolving national data
localization requirements.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Michael Palage<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">P.S. Just to be clear these are my own
personal opinions and not on behalf of any current, past or
future client. Also please excuse any typos as most of this
analysis was written between 12 AM and 4 AM Saturday morning.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
</body>
</html>