<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 type="disc" style="margin-bottom:0in"><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 type="disc" style="margin-bottom:0in"><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<u></u><u></u></li></ul></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="Calibri, sans-serif"><font color="#ff0000" style=""><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 type="disc" style="margin-bottom:0in"><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 color="#ff0000" style=""><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 type="disc" style="margin-bottom:0in"><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<u></u><u></u></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.<u></u><u></u></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 color="#ff0000" face="Calibri, sans-serif"><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 type="disc" style="margin-bottom:0in"><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; <u></u><u></u></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 color="#ff0000" face="Calibri, sans-serif"><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"><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><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">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,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></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.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The question/flags are: <u></u><u></u></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?<u></u><u></u></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">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.<u></u><u></u></li></ol>
<p class="MsoNormal">Data elements currently required to be collected, but are not addressed in the Initial Report include:<u></u><u></u></p>
<ul type="disc">
<li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact ID (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact Name (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact Street (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact City (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact State/Province (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact Postal Code (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact Country (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact Email (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact Phone (where available)<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Billing/Other Contact Fax (where available)<u></u><u></u></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.<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Full Contact Information for Privacy Proxy Registrations<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">Full Contact Information for Registrants who have Consented to Full Display<u></u><u></u></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<u></u><u></u></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.<u></u><u></u></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;<u></u><u></u></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<u></u><u></u></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.<u></u><u></u></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);<u></u><u></u></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;<u></u><u></u></li><li class="gmail-m_6116739644868178947MsoListParagraph">(RAA 3.4.2.3) records of the accounts of all Registered Name Holders with Registrar.<u></u><u></u></li></ul>
<p class="MsoNormal">Best,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Dan and 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>
<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">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<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><a name="m_6116739644868178947__MailOriginalBody">Hi Everyone:<u></u><u></u></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.<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_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. <u></u><u></u></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.<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>
_______________________________________________<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>