<div dir="ltr">And of course I meant <b>recommendation 11</b> not 7 .... sigh! <div><br></div><div>Theo, Completely agree, but I am also thinking of those requirements that may be beyond the GDPR's reach. So I don't think the necessity of a "Waiver" situation is a reality that will go away anytime soon. </div><div><br></div><div><br></div><div>Alan</div><div><br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><table style="padding:0px;margin:10px 0;border:none"><tbody><tr><td style="vertical-align:middle;padding:0px 7px 0px 0px"><a href="http://donuts.domains" rel="nofollow" target="_blank"><img alt="Donuts Inc." height="75" src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png" width="75"></a></td><td style="vertical-align:middle;padding:0px 7px 0px 0px;text-align:left">
                        <div style="font-family:'tahoma',sans-serif;font-size:14px;line-height:17px;font-weight:bold;color:black"><span style="font-size:12px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:rgb(51,51,51)">Alan Woods</span></span></span></div>

                        <div><span style="font-size:12px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:#333333">Senior Compliance & Policy Manager, Donuts Inc.</span></span></span>

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

</blockquote></div>