<div dir="ltr">And of course I meant <b>recommendation 11</b> not 7 .... sigh! <div><br></div><div>Theo, Completely agree, but I am also thinking of those requirements that may be beyond the GDPR's reach. So I don't think the necessity of a "Waiver" situation is a reality that will go away anytime soon. </div><div><br></div><div><br></div><div>Alan</div><div><br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><table style="padding:0px;margin:10px 0;border:none"><tbody><tr><td style="vertical-align:middle;padding:0px 7px 0px 0px"><a href="http://donuts.domains" rel="nofollow" target="_blank"><img alt="Donuts Inc." height="75" src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png" width="75"></a></td><td style="vertical-align:middle;padding:0px 7px 0px 0px;text-align:left">
<div style="font-family:'tahoma',sans-serif;font-size:14px;line-height:17px;font-weight:bold;color:black"><span style="font-size:12px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:rgb(51,51,51)">Alan Woods</span></span></span></div>
<div><span style="font-size:12px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:#333333">Senior Compliance & Policy Manager, Donuts Inc.</span></span></span>
<hr><span style="font-size:11px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:#333333">The Victorians, </span></span></span></div><div><font color="#333333" face="arial, helvetica, sans-serif"><span style="font-size:11px">15-18 Earlsfort Terrace<br style="background-color:rgb(34,34,34)">
Dublin 2, County Dublin</span></font><br style="color:rgb(214,214,214);font-family:'open sans';font-size:12px;background-color:rgb(34,34,34)"><font color="#333333" face="arial, helvetica, sans-serif"><span style="font-size:11px">
Ireland</span></font><br>
<span style="font-size:11px"><span style="font-family:'arial','helvetica',sans-serif"></span></span><br>
<span style="line-height:36px"><a href="https://www.facebook.com/donutstlds" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/facebook.png"></a> <a href="https://twitter.com/DonutsInc" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/twitter.png"></a> </span><a href="https://www.linkedin.com/company/donuts-inc" rel="nofollow" target="_blank"><span style="font-size:14px"><img src="http://storage.googleapis.com/signaturesatori/icons/linkedin.png"></span></a></div>
</td></tr></tbody></table><br>
</div><div><span style="font-size:12pt;font-family:Cambria,serif">Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . </span><span style="font-size:12pt;font-family:Cambria,serif">Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.</span><br></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 24, 2019 at 1:22 PM Theo Geurts <<a href="mailto:gtheo@xs4all.nl">gtheo@xs4all.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Thanks Alan, <br>
<br>
Regarding waivers, I think we need to figure out what their actual
use is?<br>
Back in the day, the 95/46 directive was implemented differently
across Europe, as such a bit messy.<br>
But this is no longer the case, the data retention directive has
been invalidated and the GDPR has replaced the 95/46 directive. <br>
<br>
Best, <br>
Theo Geurts CIPP/E<br>
</p>
<div class="gmail-m_8083281215484174396moz-cite-prefix">On 24-1-2019 13:50, Alan Woods wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hey all, </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">To perhaps make my last email a bit more
'actionable' I wish to put a suggestion as to the potential
wording of an updated recommendation. NOTE: it's not an easy
task, as the point is that we have not yet been armed with
adequate data to create a wholly considered retention period
that will allow for ICANN to insist upon a retention period,
for certain data elements, for a justifiable and reasonable
period of time. therefore the recommendation is a bit
"hedging our bets" somehow: </div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><span style="font-family:Calibri,sans-serif;font-size:14.6667px">To
be clear, due to speed with which we are moving, this is
tabled as to kick off the <b>discussion/drafting</b>. I have
not run this by even my teammates in the RYSG and I am under
no illusions that this is the 'final' text - merely a
suggested path.</span> <br>
<div>
<div><br>
</div>
</div>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>
<div>
<div><b>Recommendation 7 </b></div>
</div>
</div>
<div>
<div><b><br>
</b></div>
</div>
<div>
<div><b>1) The EPDP team recommends that ICANN, as soon as
is practicable, undertakes a review of all its active
process and procedures so as to identify and document
the instances in which personal data is requested from a
registrar, outside of the normal retention period of the
'life of the registration'. Identified retention
periods, for specific data elements should be then
documented and be relied upon to establish, the required
relevant and specific, minimum data retention
expectations for registrars. </b></div>
</div>
<div>
<div><b><br>
</b></div>
</div>
<div>
<div><b>2) In the interim, the ePDP has recognized that the
T<font face="Calibri, sans-serif"><span style="font-size:14.6667px">ransfer Dispute
Resolution Policy (“TDRP”) has been identified as
one such process. The ePDP team therefore recommends
that ICANN should direct registrars to retain only
those data elements as deemed necessary for the
purposes of the TDRP, for a period of one year
following the life of the registration. This
retention is grounded on the stated
policy stipulation within the TDRP, that claims
under the policy may only be raised for a period of
12 months after the alleged breach </span></font></b><b><font face="Calibri, sans-serif"><span style="font-size:14.6667px">(FN: see TDRP section
2.2)</span></font></b><b><font face="Calibri,
sans-serif"><span style="font-size:14.6667px"> of the
Transfer Policy (FN: see Section 1.15 of TDRP). </span></font></b></div>
</div>
<div>
<div><b><font face="Calibri, sans-serif"><span style="font-size:14.6667px"><br>
</span></font></b></div>
</div>
<div>
<div><b><font face="Calibri, sans-serif"><span style="font-size:14.6667px">3) The ePDP recognizes
that Contracted Parties may have needs or
requirements for longer retention periods in line
with local law or other requirements. The ePDP
recommends that nothing in this recommendation, or
in separate ICANN mandated policy, should prohibited
contracted parties from setting their own
limitation periods beyond that which is expected in
ICANN policy. S</span></font><span style="font-size:14.6667px;font-family:Calibri,sans-serif">imilarly,
should local law prevent retention for the period of
one year, the ePDP recommends that there are waiver
procedures in place that can address such situations.</span></b></div>
</div>
</blockquote>
<div dir="ltr">
<div><span style="font-size:14.6667px;font-family:Calibri,sans-serif"><br>
</span></div>
<div><font face="Calibri, sans-serif"><span style="font-size:14.6667px">NOTE: the waiver procedure
is a pet peeve of mine. It make no legal sense to me
that should a single registry / registrar can prove that
a law local or otherwise is incompatible with a
retention period, that ICANN then continues, having
actual notice of an incompatibility, enforces that
retention period against every other contracted party
who may be similarly subject to that law, until that
party makes a separate and full application for a
waiver. I appreciate that ICANN cannot possibly assess
jurisdiction of applicability of laws for individual
CPs, however the process should not be obtuse as to
ignore it;s own precedent. I don't know if it is in our
power to do so, however perhaps we should also recommend
that any successful waiver application process should
provide a reasonable period of time whereby other CPs
may 'join' themselves to a waiver upon presentation of
sufficient proof of being subject to a particular law or
requirement that grounded the original application [a
fast track waiver process so to speak]. </span></font></div>
<div><font face="Calibri, sans-serif"><span style="font-size:14.6667px"><br>
</span></font></div>
<div><br>
</div>
<div><br>
</div>
<div><font face="Calibri, sans-serif"><span style="font-size:14.6667px"><br>
</span></font></div>
<div><font face="Calibri, sans-serif"><span style="font-size:14.6667px"><br>
</span></font></div>
<div><font face="Calibri, sans-serif"><span style="font-size:14.6667px"><br>
</span></font></div>
<div><font face="Calibri, sans-serif"><span style="font-size:14.6667px"><br>
</span></font></div>
<div>
<div>
<div dir="ltr" class="gmail-m_8083281215484174396gmail-m_5652811889392503405m_3816974776458959842gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<table style="padding:0px;margin:10px 0px;border:none">
<tbody>
<tr>
<td style="vertical-align:middle;padding:0px 7px 0px 0px"><a href="http://donuts.domains" rel="nofollow" target="_blank"><img alt="Donuts Inc." src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png" width="75" height="75"></a></td>
<td style="vertical-align:middle;padding:0px 7px 0px 0px;text-align:left">
<div style="font-family:tahoma,sans-serif;font-size:14px;line-height:17px;font-weight:bold;color:black"><span style="font-size:12px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">Alan
Woods</span></span></span></div>
<div><span style="font-size:12px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">Senior
Compliance & Policy
Manager, Donuts Inc.</span></span></span>
<hr><span style="font-size:11px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">The
Victorians, </span></span></span></div>
<div><font face="arial,
helvetica, sans-serif" color="#333333"><span style="font-size:11px">15-18
Earlsfort Terrace<br style="background-color:rgb(34,34,34)">
Dublin 2, County Dublin</span></font><br>
<font face="arial, helvetica,
sans-serif" color="#333333"><span style="font-size:11px">
Ireland</span></font><br>
<span style="font-size:11px"><span style="font-family:arial,helvetica,sans-serif"></span></span><br>
<span style="line-height:36px"><a href="https://www.facebook.com/donutstlds" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/facebook.png"></a> <a href="https://twitter.com/DonutsInc" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/twitter.png"></a> </span><a href="https://www.linkedin.com/company/donuts-inc" rel="nofollow" target="_blank"><span style="font-size:14px"><img src="http://storage.googleapis.com/signaturesatori/icons/linkedin.png"></span></a></div>
</td>
</tr>
</tbody>
</table>
<br>
</div>
<div><span style="font-size:12pt;font-family:Cambria,serif">Please
NOTE: This electronic message,
including any attachments, may
include privileged, confidential and/or
inside information owned by Donuts
Inc. . </span><span style="font-size:12pt;font-family:Cambria,serif">Any
distribution or use of this
communication by anyone other than the
intended recipient(s) is strictly
prohibited and may be unlawful. If
you are not the intended recipient,
please notify the sender by replying
to this message and then delete it
from your system. Thank you.</span><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail_attr">On
Wed, Jan 23, 2019 at 2:53 PM Theo Geurts <<a href="mailto:gtheo@xs4all.nl" target="_blank">gtheo@xs4all.nl</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> Thanks, Alan,<br>
<br>
From my point of view, your observations are all accurate
including the registrar ones.<br>
<br>
And yes you cannot pick a random number for retention. There
is a purpose, you balance it, and then you get your period
for retention. Your purpose and how you balanced it are part
of your documentation to meet the requirement of Art 5.2.
Though usually, you cover this process through Art 35. <br>
<br>
Theo<br>
<div class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434moz-cite-prefix">On
23-1-2019 15:38, Alan Woods wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Dear all, (noted these are my own musings
and my registry colleagues may have additional /
different thoughts and comments)
<div><br>
</div>
<div><b>1) Retention period of 1 year </b></div>
<div>Can we be clear that where data is retained for 1
year, and such an extra retention period is stated
as being for use under the TDRP, than retained data
may <b><u>ONLY</u></b> be used for that purpose
(See the RYSG comment). Based upon this
recommendation, should a Registrar use the retained
data for any other purpose, the will be doing so
under their own controllership stem (Hence why the
clarification in the NOTE is exceptionally
important.) </div>
<div><br>
</div>
<div>To be even clearer, ICANN would <b>NOT</b> be
able to use the retained data for any other purpose
other than the TDRP under the current
recommendation. This is the core of what the EDPB
have repeatedly told ICANN, you can't just
arbitrarily pick a retention period, the retention
period just be reasoned and the use of that data
must be grounded to that reason. The EDPB will be
equally as upset about setting a retention period
based on one process,then using data for something
wholly unrelated to that process. </div>
<div><br>
</div>
<div>Should we persist I see the issue is as follows: </div>
<div><br>
</div>
<div>ICANN (Compliance or otherwise) does not hold the
data themselves, and this data will be requested
from the registrar. This disclosure request will
state the reason as X purpose; unless the stated
purpose is for in furtherance of the TDRP, a
registrar should (read MUST) decline to disclose, as
the disclosure is incompatible with the stated
reason for retention (i.e. the TDRP) </div>
<div><br>
</div>
<div>Only ICANN, have the knowledge of why they
require retention for specific processes and
procedures. They must provide the base policy reason
as to why they require, in the contract, a retention
period. The TDRP is a good single example, but it
is one single example and ICANN, should then need it
for any other reason, must tell the ePDP what, why
and for how long the data is necessary. </div>
<div><br>
</div>
<div><br>
</div>
<div>2) R<b>etention of additional data elements </b></div>
<div><b><br>
</b></div>
<div><b>I would believe the minimal data elements must
be retained, and only then related to the specific
purpose for the retention. </b></div>
<div><br>
</div>
<div> I do not agree with Trang's assessment of the
necessity for billing contacts and in particular the
interpretation of "<font face="Calibri, sans-serif"><span style="font-size:14.6667px">requires a registrar
to receive a reasonable assurance of payment
prior to activating a domain registration." In
this instance the proof of assurance should not,
considering data protection, rise to the actual
provision of actual billing data but would more
functionally refer to, in a normal
business sense, assurances that the
registrar remains solvent and this does not rise
to an ICANN expectation that the
registrant ultimately pays (that's
the registrar's business) ! </span></font></div>
<div><br>
</div>
<div>Re the other elements noted - I would quickly
note the following: </div>
<div>
<ul style="margin-bottom:0in" type="disc">
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">Billing
contacts <font color="#ff0000">- I defer to my
registrar colleagues friends here but ICANN
does not ever bill registrants. Should a
registrar fail and registrations are
transferred, then the gaining registrar will
need to establish contact again and discern
should the registrant wish to continue the
relationship with the Registrar. I would
opine that this is achieved via registrant
contact and a private contract between
registrar and registrant. Frankly it has
nothing to do with ICANN and is none of their
data processing business.</font></li>
</ul>
<ul style="margin-bottom:0in" type="disc">
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(RAA
3.4.1.5) the name, postal address, e-mail
address, and voice telephone number provided by
the customer of any privacy service or licensee
of any proxy registration service, in each case,
offered or made available by Registrar or its
Affiliates in connection with each registration.</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">Full
Contact Information for Privacy Proxy
Registrations</li>
</ul>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="Calibri, sans-serif"><font color="#ff0000"><span style="font-size:14.6667px">For both the
above, again I defer to my registrar
colleagues, but again, this data is
currently completely remote from ICANN's
sphere of influence. The registrant makes a
private contract with a P&P provider.
Such a contract will have stipulations in
the event of a failure of the P&P
provider. Use of such providers is at the
risk of the registrant, and ICANN cannot
interfere here. IF a P&P gets sunk, the
registrant will need to deal with their
choice and claim relief under their contract
etc. - it may be messy but ICANN cannot
claim to have a right to this underlying
data, as their influence extends to only the
data of the registrant (which in this
instance will be presented as the P&P
holder). ICANN may claim further power via
appropriate policy development perhaps but
regardless, surely this is a matter for the
PPSAI. </span></font></font></div>
</blockquote>
<div>
<ul style="margin-bottom:0in" type="disc">
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in"><font face="Calibri, sans-serif"><span style="font-size:11pt">Full Contact
Information for Registrants who have
Consented to Full Display -</span></font><font color="#ff0000"><font face="Calibri,
sans-serif"><span style="font-size:11pt">
This is a matter for an assessment of what
data is needed for the reason basing the </span><span style="font-size:14.6667px">retention</span><span style="font-size:11pt">. i.e. what </span><span style="font-size:14.6667px">data</span><span style="font-size:11pt"> is </span><span style="font-size:14.6667px">need</span><span style="font-size:11pt"> currently for
performance of the TDRP - nothing else. </span><span style="font-size:14.6667px">Again</span><span style="font-size:11pt"> ICANN should </span><span style="font-size:14.6667px">identify</span><span style="font-size:11pt"> and justify the
data elements necessary for this. The
ePDP cannot be expected to do this for
ICANN. </span></font></font></li>
</ul>
<ul style="margin-bottom:0in" type="disc">
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(Data
Retention Specification 1.1.7.) Types of domain
name services purchased for use in connection
with the Registration</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(Data
Retention Specification 1.1.8.) To the extent
collected by Registrar, "card on file," current
period third party transaction number, or other
recurring payment data.</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(Data
Retention Specification 1.2.1) Information
regarding the means and source of payment
reasonably necessary for the Registrar to
process the Registration transaction, or a
transaction number provided by a third party
payment processor;</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(Data
Retention Specification 1.2.2) Log files,
billing records and, to the extent collection
and maintenance of such records is commercially
practicable or consistent with industry-wide
generally accepted standard practices within the
industries in which Registrar operates, other
records containing communications source and
destination information, including, depending on
the method of transmission and without
limitation: (1) Source IP address, HTTP headers,
(2) the telephone, text, or fax number; and (3)
email address, Skype handle, or instant
messaging identifier, associated with
communications between Registrar and the
registrant about the Registration; and</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(Data
Retention Specification 1.2.3 ) Log files and,
to the extent collection and maintenance of such
records is commercially practicable or
consistent with industry-wide generally accepted
standard practices within the industries in
which Registrar operates, other records
associated with the Registration containing
dates, times, and time zones of communications
and sessions, including initial registration.</li>
</ul>
</div>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div dir="ltr">
<div><span style="font-family:Calibri,sans-serif;color:rgb(255,0,0);font-size:14.6667px">I'm
minded to wholly defer this particular ...
issue... to our registrar colleagues. But to the
Casual observer none of this data is in ICANN's
remit to retain. This is all part of the </span><span style="font-family:Calibri,sans-serif;color:rgb(255,0,0);font-size:14.6667px">private</span><font face="Calibri, sans-serif" color="#ff0000"><span style="font-size:14.6667px"> contract with the
registrant and registrar and ICANN has no
legal claim, basis or expectation to this
data. If ICANN believes that they have a right
to this data, then it is for them to assert it
and justify why they need to mandate something
as the harvesting and retention to data wholly
unrelated to the registration of a domain
name. Let us provide a simple example If a
registrant doesn't pay the registrar for a
domain (declined card or other), ICANN will
still likely get paid because that is the
contract they have with the CPs; the
registry will still get paid as that is the
contract with the registrar. Neither registry
or registrar may, nor should go after the
registrant for such a payment, as we have no
right to do so as that is not the intended
legal nature of our relationship. Therefore
why would ICANN have a right to the
information regarding cards on file or client
communications? </span></font></div>
<div><br>
</div>
</div>
</blockquote>
<div dir="ltr">
<div>
<ul style="margin-bottom:0in" type="disc">
<li>(RAA 3.4.2.1) the submission date and time,
and the content, of all registration data
(including updates) submitted in electronic form
to the Registry Operator(s);<br>
</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(RAA
3.4.2.2) all written communications constituting
registration applications, confirmations,
modifications, or terminations and related
correspondence with Registered Name Holders,
including registration contracts; </li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph" style="margin-left:0in;margin-right:0in;font-size:11pt;font-family:Calibri,sans-serif">(RAA
3.4.2.3) records of the accounts of all
Registered Name Holders with Registrar.</li>
</ul>
</div>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div dir="ltr">
<div><font face="Calibri, sans-serif" color="#ff0000"><span style="font-size:11pt">These
are all data that ICANN could possibly
mandate. But that being said, this all seems
aimed at litigation. These are elements that
a </span><span style="font-size:14.6667px">Registrar</span><span style="font-size:11pt">, in its sole
controllership as a </span><span style="font-size:14.6667px">business</span><span style="font-size:11pt">, would be crazy not to
retain for the purposes of litigation
impending or actual etc. Regardless, in truth
I can't see how ICANN would EVER have such
data </span><span style="font-size:14.6667px">disclosed</span><span style="font-size:11pt"> to them unless by
court order or equivalent where there is a
dispute between Rr and ICANN. </span></font></div>
</div>
</blockquote>
<div dir="ltr">
<div> </div>
<div>I think we need to be clear as to necessity here
and IMHO, a lot of these elements are simply
overreach. </div>
<div><br>
</div>
<div>Kind regards,</div>
<div><br>
</div>
<div>Alan </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<table style="padding:0px;margin:10px 0px;border:none">
<tbody>
<tr>
<td style="vertical-align:middle;padding:0px 7px 0px 0px"><a href="http://donuts.domains" rel="nofollow" target="_blank"><img alt="Donuts Inc." src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png" width="75" height="75"></a></td>
<td style="vertical-align:middle;padding:0px 7px 0px 0px;text-align:left">
<div style="font-family:tahoma,sans-serif;font-size:14px;line-height:17px;font-weight:bold;color:black"><span style="font-size:12px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">Alan Woods</span></span></span></div>
<div><span style="font-size:12px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">Senior
Compliance &
Policy
Manager, Donuts
Inc.</span></span></span>
<hr><span style="font-size:11px"><span style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(51,51,51)">The
Victorians, </span></span></span></div>
<div><font face="arial,
helvetica,
sans-serif" color="#333333"><span style="font-size:11px">15-18 Earlsfort Terrace<br style="background-color:rgb(34,34,34)">
Dublin 2, County
Dublin</span></font><br>
<font face="arial,
helvetica,
sans-serif" color="#333333"><span style="font-size:11px"> Ireland</span></font><br>
<span style="font-size:11px"><span style="font-family:arial,helvetica,sans-serif"></span></span><br>
<span style="line-height:36px"><a href="https://www.facebook.com/donutstlds" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/facebook.png"></a> <a href="https://twitter.com/DonutsInc" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/twitter.png"></a> </span><a href="https://www.linkedin.com/company/donuts-inc" rel="nofollow" target="_blank"><span style="font-size:14px"><img src="http://storage.googleapis.com/signaturesatori/icons/linkedin.png"></span></a></div>
</td>
</tr>
</tbody>
</table>
<br>
</div>
<div><span style="font-size:12pt;font-family:Cambria,serif">Please
NOTE: This electronic message,
including any attachments, may
include privileged, confidential and/or inside information owned by
Donuts Inc. . </span><span style="font-size:12pt;font-family:Cambria,serif">Any
distribution or use of this
communication by anyone other
than the intended recipient(s)
is strictly prohibited and may
be unlawful. If you are not
the intended recipient, please
notify the sender by replying
to this message and then
delete it from your system.
Thank you.</span><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail_attr">On
Tue, Jan 22, 2019 at 11:43 PM Trang Nguyen <<a href="mailto:trang.nguyen@icann.org" target="_blank">trang.nguyen@icann.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947WordSection1">
<p class="MsoNormal">Dear All,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Regarding data retention,
ICANN org has previously identified a question
and some areas that we wanted to flag for the
EPDP Team, which we sent to the mailing list on
22 December 2018 (<a href="https://mm.icann.org/pipermail/gnso-epdp-team/2018-December/001125.html" target="_blank">https://mm.icann.org/pipermail/gnso-epdp-team/2018-December/001125.html</a>).
We are flagging them here again for the EPDP
Team’s consideration/discussion as you work to
finalize the recommendation. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">The question/flags are: </p>
<ol start="1" type="1">
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">There
are several data elements that are currently
required to be retained, but are not addressed
in the Initial Report. Should the retention
obligation for these data elements remain or
be discontinued?</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">If
billing and payment-related data is no longer
required to be collected, retained, and (with
respect to billing contact data) escrowed,
this could impact continuity of service to
registrants and availability of this data in
the event of a payment dispute or related
investigation. ICANN org also notes that the
ICANN Registrar Accreditation Policy <<a href="https://www.icann.org/resources/pages/policy-statement-2012-02-25-en" target="_blank">https://www.icann.org/resources/pages/policy-statement-2012-02-25-en</a>>
requires a registrar to receive a reasonable
assurance of payment prior to activating a
domain registration.</li>
</ol>
<p class="MsoNormal">Data elements currently
required to be collected, but are not addressed
in the Initial Report include:</p>
<ul type="disc">
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact ID (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Name (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Street (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact City (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact State/Province (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Postal Code (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Country (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Email (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Phone (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Fax (where available)</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(RAA
3.4.1.5) the name, postal address, e-mail
address, and voice telephone number provided
by the customer of any privacy service or
licensee of any proxy registration service, in
each case, offered or made available by
Registrar or its Affiliates in connection with
each registration.</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Full
Contact Information for Privacy Proxy
Registrations</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">Full
Contact Information for Registrants who have
Consented to Full Display</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(Data
Retention Specification 1.1.7.) Types of
domain name services purchased for use in
connection with the Registration</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(Data
Retention Specification 1.1.8.) To the extent
collected by Registrar, "card on file,"
current period third party transaction number,
or other recurring payment data.</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(Data
Retention Specification 1.2.1) Information
regarding the means and source of payment
reasonably necessary for the Registrar to
process the Registration transaction, or a
transaction number provided by a third party
payment processor;</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(Data
Retention Specification 1.2.2) Log files,
billing records and, to the extent collection
and maintenance of such records is
commercially practicable or consistent with
industry-wide generally accepted standard
practices within the industries in which
Registrar operates, other records containing
communications source and destination
information, including, depending on the
method of transmission and without limitation:
(1) Source IP address, HTTP headers, (2) the
telephone, text, or fax number; and (3) email
address, Skype handle, or instant messaging
identifier, associated with communications
between Registrar and the registrant about the
Registration; and</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(Data
Retention Specification 1.2.3 ) Log files and,
to the extent collection and maintenance of
such records is commercially practicable or
consistent with industry-wide generally
accepted standard practices within the
industries in which Registrar operates, other
records associated with the Registration
containing dates, times, and time zones of
communications and sessions, including initial
registration.</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(RAA
3.4.2.1) the submission date and time, and the
content, of all registration data (including
updates) submitted in electronic form to the
Registry Operator(s);</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(RAA
3.4.2.2) all written communications
constituting registration applications,
confirmations, modifications, or terminations
and related correspondence with Registered
Name Holders, including registration
contracts;</li>
<li class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraph">(RAA
3.4.2.3) records of the accounts of all
Registered Name Holders with Registrar.</li>
</ul>
<p class="MsoNormal">Best,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Dan and Trang</p>
<p class="MsoNormal">ICANN Org Liaisons</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">Gnso-epdp-team
<<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>>
on behalf of Kurt Pritz <<a href="mailto:kurt@kjpritz.com" target="_blank">kurt@kjpritz.com</a>><br>
<b>Date: </b>Tuesday, January 22, 2019 at
1:20 PM<br>
<b>To: </b>EPDP <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>><br>
<b>Subject: </b>[Gnso-epdp-team] EPDP
Recommendation 11 - email list discussion</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal"><a name="m_8083281215484174396_m_5652811889392503405_m_3816974776458959842_m_-4509328517319795434_m_6116739644868178947__MailOriginalBody">Hi Everyone:</a></p>
<p class="MsoNormal"><span>There were several
items (Recommendations) that we agreed to
discuss via email with the idea that we
could close on them without taking time
for discussion in a meeting. This email
concerns Recommendation 11, addressing the
data retention period.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><b>The current
recommendation states:</b></span></p>
<p class="MsoNormal"><span>The EPDP Team
recommends that Registrars are required to
retain the herein-specified data elements
for a period of one year following the
life of the registration. This retention
period conforms to the specific statute of
limitations within the Transfer Dispute
Resolution Policy (“TDRP”).</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><b>Small Team
Discussion</b></span></p>
<p class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraphCxSpFirst" style="margin-left:0.25in"> <span>(1)</span><span><span>
</span>The small team noted that “statute
of limitation” as used in the
Recommendation was probably an
inappropriate use of a legal term of art
and should be replaced with more
appropriate language. This point is
addressed in the proposed updated
Recommendation below. </span></p>
<p class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434gmail-m_6116739644868178947MsoListParagraphCxSpLast" style="margin-left:0.25in"> <span>(2)</span><span><span>
</span>Some on the small team advocated
for a longer retention period, suggesting
that a longer retention period could be
anchored in existing ICANN policy
requirements or other outside
requirements. (The current retention
period is anchored is the Transfer DRP as
the “tall pole” among all the other
purposes for processing registration
data.) The updated language below,
proposed by small team B, clarifies that
the proposed data retention period is for
ICANN related requirements and different
retention periods may apply as a result of
local requirements or circumstances.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><b>Proposed updated
language recommendation 11 – data
retention</b> </span></p>
<p class="MsoNormal"><span>The EPDP Team
recommends that: Registrars are required
to retain the herein-specified data
elements for ICANN-related requirements
for a period of one year following the
life of registration. This minimum
retention period is consistent the
requirements of the Transfer Dispute
Resolution Procedure, which has the
longest retention requirement of any of
the enumerated Purposes for Processing
Registration Data.</span></p>
<p class="MsoNormal"><span>Note, Contracted
Parties may have needs or requirements for
longer retention periods in line with
local law or other requirements. This is
not prohibited by this language.
Similarly, should local law prevent
retention for the period of one year,
there are waiver procedures in place that
can address such situations.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><b>Actions</b></span></p>
<p class="MsoNormal"><span>Those supporting a
retention greater than one year generally
should submit rationale for such a
retention period including related ICANN
policy requirements to which this could be
anchored. These submissions will be
discussed via email.</span></p>
<p class="MsoNormal"><span>Submit comments for
support for the amended Recommendation
or requesting edits to the recommendation
with rationale. </span></p>
<p class="MsoNormal"><span>Deadline: Friday,
24 January, additional email discussion
might follow depending on responses. </span></p>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Thank you and
best regards,</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Kurt</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></blockquote>
</div>
<br>
<fieldset class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434moz-quote-pre">_______________________________________________
Gnso-epdp-team mailing list
<a class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434moz-txt-link-abbreviated" href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a>
<a class="gmail-m_8083281215484174396gmail-m_5652811889392503405gmail-m_3816974776458959842gmail-m_-4509328517319795434moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>