<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" 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="moz-cite-prefix">On 23-1-2019 15:38, Alan Woods wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPQ5EHC6RbtXmfwBG-Yq+5=Vc5AsFDcQ4EQSsJUFHDHnu3MovQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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_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_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_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 style=""
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_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
style="" 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_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_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_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_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_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:0 0 0 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_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_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:0 0 0 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_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"
moz-do-not-send="true"><img
alt="Donuts Inc."
src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png"
moz-do-not-send="true"
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
style="color:rgb(214,214,214);font-family:"open
sans";font-size:12px;background-color:rgb(34,34,34)">
<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"
moz-do-not-send="true"><img
src="http://storage.googleapis.com/signaturesatori/icons/facebook.png"
moz-do-not-send="true"></a> <a
href="https://twitter.com/DonutsInc" rel="nofollow" target="_blank"
moz-do-not-send="true"><img
src="http://storage.googleapis.com/signaturesatori/icons/twitter.png"
moz-do-not-send="true"></a> </span><a
href="https://www.linkedin.com/company/donuts-inc" rel="nofollow"
target="_blank"
moz-do-not-send="true"><span
style="font-size:14px"><img
src="http://storage.googleapis.com/signaturesatori/icons/linkedin.png"
moz-do-not-send="true"></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_attr">On Tue, Jan 22, 2019 at 11:43
PM Trang Nguyen <<a href="mailto:trang.nguyen@icann.org"
moz-do-not-send="true">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_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" moz-do-not-send="true">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_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_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" moz-do-not-send="true">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_6116739644868178947MsoListParagraph">Billing/Other
Contact ID (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Name (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Street (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact City (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact State/Province (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Postal Code (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Country (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Email (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Phone (where available)</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other
Contact Fax (where available)</li>
<li class="gmail-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_6116739644868178947MsoListParagraph">Full
Contact Information for Privacy Proxy Registrations</li>
<li class="gmail-m_6116739644868178947MsoListParagraph">Full
Contact Information for Registrants who have Consented
to Full Display</li>
<li class="gmail-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_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_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_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_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_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_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_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" moz-do-not-send="true">gnso-epdp-team-bounces@icann.org</a>>
on behalf of Kurt Pritz <<a
href="mailto:kurt@kjpritz.com" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">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_6116739644868178947__MailOriginalBody"
moz-do-not-send="true">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_6116739644868178947MsoListParagraphCxSpFirst"
style="margin-left:0.25in">
<span>(1)</span><span><span
style="font-size:7pt;font-family:"Times New
Roman"">
</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_6116739644868178947MsoListParagraphCxSpLast"
style="margin-left:0.25in">
<span>(2)</span><span><span
style="font-size:7pt;font-family:"Times New
Roman"">
</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"
moz-do-not-send="true">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Gnso-epdp-team mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gnso-epdp-team@icann.org">Gnso-epdp-team@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></pre>
</blockquote>
</body>
</html>