<div dir="ltr"><div dir="ltr"><div dir="ltr">Dear all, <div><br></div><div>I am in full agreement with Sarah on this. .@Trang I do think that merely referring 2013 RAA Data Retention Specification as, as noted by Sarah, does not provide the required review, detail, necessity as to Why ICANN requires, in it's base policy, it to be 'retained'. Just from a cursory review, it does appear that the document referenced does not make out a case in any of the noted elements for ICANN's need for retention, except for those matters that refer to transfers as 'example', and as such this is already covered by the TDRP and the 1 year period already defined and linked to the TDRP : </div><div><br></div><div><b>1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.7, 1.1.8, 1.2.1</b> : the 'legitimate purpose' is referred to as <i style=""><b>'registrar's internal use'</b></i> etc - ICANN cannot mandate this, as these elements are, as per the document a registrar internal matter. </div><div><br></div><div><b>1.1.6 -</b> This seems like it's a TDRP matter. Also I must note that the description of a 'for some period' as the retention period is far too anomalous and does not bode well for the though and specificity vis á vis Data protection. I'm unsure, nor is it apparent if the list of data noted here are actually required however by the TDRP - seems more like a kitchen sink approach, rather than a considered list of necessary elements.</div><div><br></div><div><br></div><div><b>1.2.2 , 1.2.3 - </b>Again the maintenance of such records are outside of ICANN's reach. Fraud prevention and billing disputes are private matters of the registrar. ICANN's base policy should not claim control over such retention, and if they do, the legal power to do so is certainly not made out. All matters referred to are matters of contract, and the reference to transfers is duplication of 1.1.6 and again merely is referring to the actual subset of powers that ICANN may claim, the TDRP. If ICANN claims ALL Billing records etc. are necessary, then much more review is required. </div><div><br></div><div>Therefore again, noting I defer to my registrar colleagues on the exigencies of their retention requirements, I agree with Sarah and say that ICANN should, to ensure completeness, undertake a review of all processes that request data from a registrar, to identify the full spectrum of data retention requirements and align them with ICANN Purposes coming out of the EPDP work.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Alan </div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br clear="all"><div><div dir="ltr" class="gmail_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." 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: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 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></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 29, 2019 at 3:06 PM Sarah Wyld <<a href="mailto:swyld@tucows.com">swyld@tucows.com</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">
<font size="-1"><font face="Verdana">Hello All,<br>
<br>
Thank you Trang for bringing up the 2013 RAA Data Retention
Specification.<br>
<br>
We need to identify the purpose and legal basis for every
instance of data retention; being included in the 2013 RAA Data
Retention Specification is not sufficient -- instead, each
instance of retaining data needs to be grounded in an EPDP
Purpose.<br>
<br>
Looking at the PDF you linked to, I notice that most of the
retained elements show a purpose of registrar's internal use and
billing issues. These are not purposes defined by the EPDP; if
the data is retained for these reasons it would be under the
Controller's own controllership and not due to an external
requirement.<br>
<br>
For other data elements there are a couple other purposes listed
in the PDF, but the only specific policy mentioned there is the
TDRP, otherwise it's all quite general and thus insufficient to
be counted as a purpose with a legal basis.<br>
<br>
I suggest we still need to leave the recommendation as Alan W
suggested, asking ICANN to undertake a review of all processes
that request data from a registrar, to identify the full
spectrum of data retention requirements and align them with
ICANN Purposes coming out of the EPDP work. </font></font><br>
<p><font size="-1"><font face="Verdana"><br>
</font></font></p>
<pre class="gmail-m_-7897523406009028189moz-signature" cols="72">--
Sarah Wyld
Domains Product Team
Tucows
+1.416 535 0123 Ext. 1392
</pre>
<div class="gmail-m_-7897523406009028189moz-cite-prefix">On 1/28/2019 8:50 PM, Trang Nguyen
wrote:</div>
<div class="gmail-m_-7897523406009028189moz-cite-prefix"><br>
</div>
<blockquote type="cite">
<div class="gmail-m_-7897523406009028189WordSection1">
<p class="MsoNormal">Dear All,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Regarding the revised text for
recommendation #11 that Alan Woods circulated, the text seems
to imply that retained data is only used for enforcement of
the TRDP. ICANN org would like to make the EPDP Team aware of
other reasons retained data are used, which are reflected in
the Description of 2013 RAA Data Retention Specification -
Data Elements, Legitimate Purposes for Collection/Retention
and Recipients of Data <
<a href="https://www.icann.org/en/system/files/files/raa-data-retention-elements-10aug15-en.pdf" target="_blank">
https://www.icann.org/en/system/files/files/raa-data-retention-elements-10aug15-en.pdf</a>>.
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Best,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Dan & Trang<u></u><u></u></p>
<p class="MsoNormal">ICANN Org Liaisons<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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">Alan Woods
<a class="gmail-m_-7897523406009028189moz-txt-link-rfc2396E" href="mailto:alan@donuts.email" target="_blank"><alan@donuts.email></a><br>
<b>Date: </b>Thursday, January 24, 2019 at 8:50 AM<br>
<b>To: </b>Theo Geurts <a class="gmail-m_-7897523406009028189moz-txt-link-rfc2396E" href="mailto:gtheo@xs4all.nl" target="_blank"><gtheo@xs4all.nl></a><br>
<b>Cc: </b>Trang Nguyen <a class="gmail-m_-7897523406009028189moz-txt-link-rfc2396E" href="mailto:trang.nguyen@icann.org" target="_blank"><trang.nguyen@icann.org></a>,
EPDP <a class="gmail-m_-7897523406009028189moz-txt-link-rfc2396E" href="mailto:gnso-epdp-team@icann.org" target="_blank"><gnso-epdp-team@icann.org></a><br>
<b>Subject: </b>[Ext] Re: [Gnso-epdp-team] EPDP
Recommendation 11 - email list discussion</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a name="m_-7897523406009028189__MailOriginalBody">And of course I meant <b>recommendation
11</b> not 7 .... sigh!
<u></u><u></u></a></p>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Alan<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<span></span><span></span>
<table class="gmail-m_-7897523406009028189MsoNormalTable" cellpadding="0" border="0">
<tbody>
<tr>
<td style="padding:0in 5.25pt 0in 0in">
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in"><span></span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.7812in; height: 0.7812in;" id="gmail-m_-7897523406009028189_x0000_i1039" alt="Image removed by
sender. Donuts Inc." width="75" height="75" border="0"></span>[donuts.domains]</span><span></span></a><span><u></u><u></u></span></p>
</td>
<td style="padding:0in 5.25pt 0in 0in">
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in;line-height:12.75pt"><span><b><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Alan
Woods</span></b><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in"><span><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Senior
Compliance & Policy
Manager, Donuts Inc.</span>
<u></u><u></u></span></p>
<span></span>
<div style="margin-top:7.5pt;margin-bottom:7.5pt">
<div class="MsoNormal" style="text-align:center" align="center"><span>
<hr width="99%" size="0" align="center">
</span></div>
<span></span></div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in"><span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">The
Victorians, </span><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in"><span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">15-18
Earlsfort Terrace<br>
Dublin 2, County Dublin</span></span><span><span><br>
</span></span><span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Ireland</span><br>
<br>
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1037" alt="Image removed
by sender." width="32" height="32" border="0"></span>[facebook.com]</span><span></span></a><span> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1036" alt="Image removed
by sender." width="32" height="32" border="0"></span>
[twitter.com]</span><span></span></a><span> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=" target="_blank"><span><span style="font-size:10.5pt;border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1035" alt="Image removed
by sender." width="32" height="32" border="0"></span>
[linkedin.com]</span><span></span></a><span><u></u><u></u></span></p>
</div>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><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. . 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><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span>On Thu, Jan 24,
2019 at 1:22 PM Theo Geurts <</span><a href="mailto:gtheo@xs4all.nl" target="_blank"><span>gtheo@xs4all.nl</span><span></span></a><span>> wrote:<u></u><u></u></span></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p><span>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<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span>On 24-1-2019
13:50, Alan Woods wrote:<u></u><u></u></span></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal"><span>Hey all, <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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: <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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. <u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
</div>
<blockquote style="margin:5pt 0in 5pt 30pt">
<div>
<div>
<div>
<p class="MsoNormal"><span><b>Recommendation
7 </b><u></u><u></u></span></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span><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>this
seems to imply that retained data is only
used for ICANN compliance purpose, but there
may be other purposes for which retained
data may be used, such as in cases of law
enforcement action, etc. retained pursuant
to board’s adopted policy (registrar
accreditation policy ) as set forth in
document used before to justify data
retention.
<u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span><b>2)
In the interim, the ePDP has recognized
that the Transfer 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 (FN: see TDRP
section 2.2) of the Transfer Policy (FN:
see Section 1.15 of TDRP). </b><u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span><b>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. Similarly,
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.</b><u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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]. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<span></span><span></span>
<table class="gmail-m_-7897523406009028189MsoNormalTable" cellpadding="0" border="0">
<tbody>
<tr>
<td style="padding:0in 5.25pt 0in 0in">
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in"><span></span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.7812in; height: 0.7812in;" id="gmail-m_-7897523406009028189_x0000_i1034" alt="Image
removed by
sender. Donuts
Inc." width="75" height="75" border="0"></span>[donuts.domains]</span><span></span></a><span><u></u><u></u></span></p>
</td>
<td style="padding:0in 5.25pt 0in 0in">
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in;line-height:12.75pt">
<span><b><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Alan
Woods</span></b><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Senior
Compliance
& Policy
Manager, Donuts
Inc.</span>
<u></u><u></u></span></p>
<span></span>
<div style="margin-top:7.5pt;margin-bottom:7.5pt">
<div class="MsoNormal" style="text-align:center" align="center"><span>
<hr width="99%" size="0" align="center">
</span></div>
<span></span></div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">The
Victorians, </span><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">15-18
Earlsfort
Terrace<br>
Dublin 2,
County Dublin</span><br>
</span><span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Ireland</span><br>
<br>
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1032" alt="Image
removed by
sender." width="32" height="32" border="0"></span>[facebook.com]</span><span></span></a><span> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1031" alt="Image
removed by
sender." width="32" height="32" border="0"></span>
[twitter.com]</span><span></span></a><span> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=" target="_blank"><span><span style="font-size:10.5pt;border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1030" alt="Image
removed by
sender." width="32" height="32" border="0"></span>
[linkedin.com]</span><span></span></a><span><u></u><u></u></span></p>
</div>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><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. . 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><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><span> <u></u><u></u></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span>On Wed,
Jan 23, 2019 at 2:53 PM Theo Geurts <</span><a href="mailto:gtheo@xs4all.nl" target="_blank"><span>gtheo@xs4all.nl</span><span></span></a><span>>
wrote:<u></u><u></u></span></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal"><span>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<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span>On
23-1-2019 15:38, Alan Woods wrote:<u></u><u></u></span></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal"><span>Dear
all, (noted these are my own musings and
my registry colleagues may have
additional / different thoughts and
comments)
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><b>1)
Retention period of 1 year </b><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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.) <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Should
we persist I see the issue is as
follows: <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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) <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>2)
R<b>etention of additional data
elements </b><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><b>I
would believe the minimal data
elements must be retained, and only
then related to the specific purpose
for the retention. </b><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> I
do not agree with Trang's assessment
of the necessity for billing contacts
and in particular the interpretation
of "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) ! <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Re
the other elements noted - I would
quickly note the following: <u></u><u></u></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal">
<span>Billing
contacts <span style="color:red">
- 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.</span>
<u></u><u></u></span></li>
</ul>
<ul type="disc">
<li class="MsoNormal">
<span>(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. <u></u><u></u></span></li>
<li class="MsoNormal">
<span>Full
Contact Information for Privacy
Proxy Registrations
<u></u><u></u></span></li>
</ul>
</div>
<blockquote style="margin:5pt 0in 5pt 30pt">
<div>
<p class="MsoNormal"><span><span style="color:red">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><u></u><u></u></span></p>
</div>
</blockquote>
<div>
<ul type="disc">
<li class="MsoNormal">
<span>Full
Contact Information for Registrants
who have Consented to Full Display -<span style="color:red"> This is a
matter for an assessment of what
data is needed for the reason
basing the retention. i.e. what
data is need currently for
performance of the TDRP - nothing
else. Again ICANN should
identify and justify the data
elements necessary for this. The
ePDP cannot be expected to do
this for ICANN. </span>
<u></u><u></u></span></li>
</ul>
<ul type="disc">
<li class="MsoNormal">
<span>(Data
Retention Specification 1.1.7.)
Types of domain name services
purchased for use in connection with
the Registration
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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.
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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; <u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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.
<u></u><u></u></span></li>
</ul>
</div>
</div>
<blockquote style="margin:5pt 0in 5pt 30pt">
<div>
<div>
<p class="MsoNormal"><span><span style="color:red">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 private 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><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<div>
<ul type="disc">
<li class="MsoNormal">
<span>(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);<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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;
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(RAA
3.4.2.3) records of the accounts of
all Registered Name Holders with
Registrar.
<u></u><u></u></span></li>
</ul>
</div>
</div>
<blockquote style="margin:5pt 0in 5pt 30pt">
<div>
<div>
<p class="MsoNormal"><span><span style="color:red">These are all
data that ICANN could possibly
mandate. But that being said, this
all seems aimed at litigation.
These are elements that
a Registrar, in its sole
controllership as a business,
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 disclosed to them unless by
court order or equivalent where
there is a dispute between Rr and
ICANN. </span><u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>I
think we need to be clear as to
necessity here and IMHO, a lot of
these elements are simply overreach. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Kind
regards,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Alan <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><br clear="all">
<u></u><u></u></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<span></span><span></span>
<table class="gmail-m_-7897523406009028189MsoNormalTable" cellpadding="0" border="0">
<tbody>
<tr>
<td style="padding:0in 5.25pt 0in 0in">
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span></span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.7812in; height: 0.7812in;" id="gmail-m_-7897523406009028189_x0000_i1029" alt="Image
removed by
sender. Donuts
Inc." width="75" height="75" border="0"></span>[donuts.domains]</span><span></span></a><span><u></u><u></u></span></p>
</td>
<td style="padding:0in 5.25pt 0in 0in">
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in;line-height:12.75pt">
<span><b><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Alan
Woods</span></b><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Senior
Compliance
& Policy
Manager, Donuts
Inc.</span>
<u></u><u></u></span></p>
<span></span>
<div style="margin-top:7.5pt;margin-bottom:7.5pt">
<div class="MsoNormal" style="text-align:center" align="center"><span>
<hr width="99%" size="0" align="center">
</span></div>
<span></span></div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">The
Victorians, </span><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">15-18
Earlsfort
Terrace<br>
Dublin 2,
County Dublin</span><br>
</span><span><span style="font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">Ireland</span><br>
<br>
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1027" alt="Image
removed by
sender." width="32" height="32" border="0"></span>[facebook.com]</span><span></span></a><span> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=" target="_blank"><span><span style="border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1026" alt="Image
removed by
sender." width="32" height="32" border="0"></span>
[twitter.com]</span><span></span></a><span> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=" target="_blank"><span><span style="font-size:10.5pt;border:1pt solid windowtext;padding:0in;text-decoration:none"><img style="width: 0.3333in; height: 0.3333in;" id="gmail-m_-7897523406009028189_x0000_i1025" alt="Image
removed by
sender." width="32" height="32" border="0"></span>
[linkedin.com]</span><span></span></a><span><u></u><u></u></span></p>
</div>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><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.
. 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><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span>On
Tue, Jan 22, 2019 at 11:43 PM Trang
Nguyen <</span><a href="mailto:trang.nguyen@icann.org" target="_blank"><span>trang.nguyen@icann.org</span><span></span></a><span>>
wrote:<u></u><u></u></span></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span>Dear All,<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span>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 (</span><a href="https://mm.icann.org/pipermail/gnso-epdp-team/2018-December/001125.html" target="_blank"><span>https://mm.icann.org/pipermail/gnso-epdp-team/2018-December/001125.html</span><span></span></a><span>).
We are flagging them here again for
the EPDP Team’s
consideration/discussion as you work
to finalize the recommendation.
<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span>The question/flags are:
<u></u><u></u></span></p>
<ol start="1" type="1">
<li class="MsoNormal">
<span>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?
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>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 <</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_policy-2Dstatement-2D2012-2D02-2D25-2Den&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=gSciXDCLwToip-KVqvqL5A4Yuch4VO2F0ALwpUeM0i8&e=" target="_blank"><span>https://www.icann.org/resources/pages/policy-statement-2012-02-25-en
[icann.org]</span><span></span></a><span>> requires a registrar to
receive a reasonable assurance of
payment prior to activating a
domain registration.
<u></u><u></u></span></li>
</ol>
<p class="MsoNormal"><span>Data elements currently required
to be collected, but are not
addressed in the Initial Report
include:<u></u><u></u></span></p>
<ul type="disc">
<li class="MsoNormal">
<span>Billing/Other
Contact ID (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact Name (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact Street (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact City (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact State/Province (where
available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact Postal Code (where
available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact Country (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact Email (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact Phone (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Billing/Other
Contact Fax (where available)
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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. <u></u><u></u></span></li>
<li class="MsoNormal">
<span>Full
Contact Information for Privacy
Proxy Registrations
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>Full
Contact Information for
Registrants who have Consented to
Full Display
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(Data
Retention Specification 1.1.7.)
Types of domain name services
purchased for use in connection
with the Registration
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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.
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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; <u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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.
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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);
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(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;
<u></u><u></u></span></li>
<li class="MsoNormal">
<span>(RAA
3.4.2.3) records of the accounts
of all Registered Name Holders
with Registrar.
<u></u><u></u></span></li>
</ul>
<p class="MsoNormal"><span>Best,<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span>Dan and Trang<u></u><u></u></span></p>
<p class="MsoNormal"><span>ICANN Org Liaisons<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></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"><span><b><span style="font-size:12pt;color:black">From:
</span></b></span><span><span style="font-size:12pt;color:black">Gnso-epdp-team <</span></span><a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank"><span><span style="font-size:12pt">gnso-epdp-team-bounces@icann.org</span></span><span></span></a><span><span style="font-size:12pt;color:black">> on behalf of Kurt Pritz <</span></span><a href="mailto:kurt@kjpritz.com" target="_blank"><span><span style="font-size:12pt">kurt@kjpritz.com</span></span><span></span></a><span><span style="font-size:12pt;color:black">><br>
<b>Date: </b>Tuesday, January
22, 2019 at 1:20 PM<br>
<b>To: </b>EPDP <</span></span><a href="mailto:gnso-epdp-team@icann.org" target="_blank"><span><span style="font-size:12pt">gnso-epdp-team@icann.org</span></span><span></span></a><span><span style="font-size:12pt;color:black">><br>
<b>Subject: </b>[Gnso-epdp-team]
EPDP Recommendation 11 - email
list discussion</span><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span><a name="m_-7897523406009028189_m_8083281215484174396_m_5652811889392503">Hi
Everyone:</a><u></u><u></u></span></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span><b>The current recommendation
states:</b><u></u><u></u></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”).<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span><b>Small Team Discussion</b><u></u><u></u></span></p>
<p class="gmail-m_-7897523406009028189gmail-m8083281215484174396gmail-m5652811889392503405gmail-m3816974776458959842gmail-m-4509328517319795434gmail-m6116739644868178947msolistparagraph" style="margin-left:0.25in">
<span>(1)
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. <u></u><u></u></span></p>
<p class="gmail-m_-7897523406009028189gmail-m8083281215484174396gmail-m5652811889392503405gmail-m3816974776458959842gmail-m-4509328517319795434gmail-m6116739644868178947msolistparagraph" style="margin-left:0.25in">
<span>(2)
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.<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span><b>Proposed updated language
recommendation 11 – data
retention</b> <u></u><u></u></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.<u></u><u></u></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
<p class="MsoNormal"><span><b>Actions</b><u></u><u></u></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span>Submit comments for support for
the amended Recommendation
or requesting edits to the
recommendation with rationale. <u></u><u></u></span></p>
<p class="MsoNormal"><span>Deadline: Friday, 24
January, additional email
discussion might follow
depending on responses.
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Thank you and best regards,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Kurt<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span> <u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span>_______________________________________________<br>
Gnso-epdp-team mailing list<br>
</span><a href="mailto:Gnso-epdp-team@icann.org" target="_blank"><span>Gnso-epdp-team@icann.org</span><span></span></a><span><br>
</span><a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank"><span>https://mm.icann.org/mailman/listinfo/gnso-epdp-team</span><span></span></a><span><u></u><u></u></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span><br>
<br>
<br>
<u></u><u></u></span></p>
<pre><span>_______________________________________________<u></u><u></u></span></pre>
<pre><span>Gnso-epdp-team mailing list<u></u><u></u></span></pre>
<pre><span></span><a href="mailto:Gnso-epdp-team@icann.org" target="_blank"><span>Gnso-epdp-team@icann.org</span><span></span></a><span><u></u><u></u></span></pre>
<pre><span></span><a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank"><span>https://mm.icann.org/mailman/listinfo/gnso-epdp-team</span><span></span></a><span></span><u></u><u></u></pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="gmail-m_-7897523406009028189mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-7897523406009028189moz-quote-pre">_______________________________________________
Gnso-epdp-team mailing list
<a class="gmail-m_-7897523406009028189moz-txt-link-abbreviated" href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a>
<a class="gmail-m_-7897523406009028189moz-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>
_______________________________________________<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>