<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    You are right Michael. <br>
    <br>
    Though there is a chance that this is covered more in-depth in part
    2?<br>
    <br>
    Theo <br>
    <br>
    <div class="moz-cite-prefix">On 25-10-2017 23:55, <a class="moz-txt-link-abbreviated" href="mailto:michael@palage.com">michael@palage.com</a>
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0ef601d34ddb$f29f5060$d7ddf120$@palage.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
p.m-59333515633959626m7775193058745579155m7299029587959283055msoplaintext, li.m-59333515633959626m7775193058745579155m7299029587959283055msoplaintext, div.m-59333515633959626m7775193058745579155m7299029587959283055msoplaintext
        {mso-style-name:m_-59333515633959626m_7775193058745579155m_7299029587959283055msoplaintext;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
span.m-59333515633959626apple-converted-space
        {mso-style-name:m_-59333515633959626apple-converted-space;}
span.EmailStyle22
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle23
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle24
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle25
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle26
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle27
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:windowtext">Hello All, <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:windowtext">I must admit
            it has been hard to keep up with the flood of recent list
            traffic.  However, I would like to interject a legal issue
            raised in the Hamilton Memo which I do not believe has been
            properly discussed to date. Specifically, Hamilton’s
            determination that both ICANN and Registration Authorities
            (Registries and Registrars) are Joint Controllers, see
            Paragraph 3.4.4 of Hamilton Memo. <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:windowtext">Article 26
            of the GDPR on the issue of Joint Controller states that “</span>Where
          two or more controllers jointly determine the purposes and
          means of processing, they shall be joint controllers.”  For
          the purpose of this analysis I will focus exclusively on
          Registries as well as the fact that there seems to have been a
          lot of list traffic in connection with the recent actions of
          .AMSTERDAM and .FRL.  Prior to ICANN, the legacy gTLDs were
          thin registries. Over the years ICANN has mandated through
          various RFPs/Applicant Guidebooks the requirement that a TLD
          be operated in a thick format.   But for a Consensus Policy
          mandating VeriSign to convert .COM and .NET from thin to thick
          there was no desire or need for Verisign to have access to
          this data. How can parties be “joint” controllers, when one
          party has the unilateral right to impose its will on the
          other?<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I am puzzled why Hamilton made this legal
          determination and whether it knew of these historical data
          points. I am also puzzled why Hamilton believes that ICANN as
          a Joint Controller can unilaterally undertake a DPIA without
          consultation with the other joint controllers.  I would submit
          that history and this action, point toward ICANN being the
          sole Data Controller, and “most” registries being a Data
          Processor. As evidenced by VeriSign, most gTLD registries do
          not need thick data to perform their core business functions.
          They are only deemed a Joint Controller because ICANN has
          mandated that they collect and process the PII of registrants.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I would welcome any additional insight on
          this Article 26 issue.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Best regards,<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Michael<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
    </blockquote>
    <br>
  </body>
</html>