<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>A short follow up to Ayden's comment "..do not see a need for
      this issue to be dealt with jurisdiction-by-jurisdiction". <br>
    </p>
    <p>Of course ICANN should not put itself in a position to have to
      deal "jurisdiction-by-jurisdiction". But, there is no way to
      reduce that interaction to zero on the part of Registrars
      operating in various national jurisdictions. However, ICANN can
      reduce the burden on Registrars by (a) a minimalist approach to
      what data to collect, and (b) building that minimal set while
      remaining aware of the state data privacy legislation. This is a
      good area to apply the KISS principle, or more properly the KISSP
      (Keep it Simple Smart People) principle. <br>
    </p>
    <p>Sam L. <br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 1/16/2018 5:02 AM, Ayden Férdeline
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:EnM0wMAk4BLGfpIersDtY5Gf2pVrPPRq5f-LYJtbepoQVMhoT9-I6jQl7rL-dPqkoUirmqGuI77juJjWo94RqYJY5HRQnHOkFIKKS6xCyAk=@ferdeline.com">
      <div>I too do not see a need for this issue to be dealt with
        jurisdiction-by-jurisdiction. As Rafik and Stephanie have said,
        there is already a common data protection standard — and I would
        like to introduce a piece of research which says that it is
        indeed the GDPR.<br>
      </div>
      <div><br>
      </div>
      <div><a
          href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3102810"
title="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3102810"
          rel="nofollow" moz-do-not-send="true">In a paper</a> opened
        for peer review today by Professor Graham Greenleaf, he begins
        by quoting a White Paper released by the Committee of Experts on
        a Data Protection Framework for India:<br>
      </div>
      <div><br>
      </div>
      <div><i>"there are two distinct models in the field of data
          protection’ (an EU model, and a US model) (p. 10), and ... the
          ‘EU model appears to be the preferred mode in several
          countries who have adopted data protection legislations
          recently’ (p. 12)."</i><br>
      </div>
      <div><br>
      </div>
      <div>Greenleaf responds to this statement by noting:<br>
      </div>
      <div><br>
      </div>
      <div><i>"This is a considerable understatement and a
          misunderstanding. Over 120 countries have now enacted data
          privacy laws that meet or exceed the ‘1st generation’ standard
          of the 1980s OECD Guidelines and Council of Europe Convention
          108. Of the 67 of these 120 countries outside Europe their
          average implementation of the ten ‘2nd Generation’ ‘European’
          principles (ie those in the EU Directive of 1995 that go
          beyond the OECD Guidelines), is at least 6/10 principles...
          The reality, therefore, is that <b>the current global
            standard of data privacy laws even outside Europe, is closer
            to the EU Directive than the OECD Guidelines. The US, with
            no general data privacy laws, is completely out of step with
            the rest of the world. There is one global standard </b>–
          and then there is the US, increasingly isolated."</i><br>
      </div>
      <div><br>
      </div>
      <div>Emphasis added. References and supporting documents are in
        the <a
          href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3102810"
title="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3102810"
          rel="nofollow" moz-do-not-send="true">open access paper</a>.<br>
      </div>
      <div><br>
      </div>
      <div>WHOIS complying with the GDPR would not see ICANN setting new
        privacy standards; in most cases, it would simply see ICANN
        complying with the letter of the law.<br>
      </div>
      <div><br>
      </div>
      <div class="protonmail_signature_block">
        <div class="protonmail_signature_block-user">
          <div>— Ayden  <br>
          </div>
        </div>
        <div class="protonmail_signature_block-proton
          protonmail_signature_block-empty"><br>
        </div>
      </div>
      <div><br>
      </div>
      <blockquote class="protonmail_quote" type="cite">
        <div>-------- Original Message --------<br>
        </div>
        <div>Subject: Re: Data Protection and Privacy Update: Seeking
          Community Feedback on Proposed Compliance Models<br>
        </div>
        <div>Local Time: 15 January 2018 10:32 PM<br>
        </div>
        <div>UTC Time: 15 January 2018 21:32<br>
        </div>
        <div>From: <a class="moz-txt-link-abbreviated" href="mailto:lanfran@YORKU.CA">lanfran@YORKU.CA</a><br>
        </div>
        <div>To: <a class="moz-txt-link-abbreviated" href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU">NCSG-DISCUSS@LISTSERV.SYR.EDU</a><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <p>John, et. al., <br>
        </p>
        <p>I don't see a conflict here. The name, WHOIS, RDS, etc. is
          not the issue, nor are accuracy and public access. The "data
          base" (let's call it RDS for short) needs to indeed be
          accurate, and we are mainly talking about the ungated (public)
          version. The basic issue is what constitutes an adequate
          accurate publicly accessible "RDS".  The push for a minimal
          set of fields is specifically a strategy to "...<i>stay as
            close to that as possible in every national jurisdiction
            where that (that data) is legally allowed</i>". Does this
          leave issues for registrars to sort out in various
          jurisdictions? Sure, just as that is true for other businesses
          in other fields. A minimal data set reduces the scope for
          ICANN's contracts to get tangled up in regulations,
          jurisdiction by jurisdiction. <br>
        </p>
        <p>Another issue, where I am odd person out, is the distinction
          between what are legitimate reasons for collection, and what
          are legitimate reasons for use. I sort of have "form follows
          function" baked into my strategy bones. I would have preferred
          reversing the process and starting with legitimate uses and
          working back to what to collect, but that boat left port a
          long time ago. <br>
        </p>
        <div>Sam L.<br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div class="moz-cite-prefix">On 1/15/2018 2:03 PM, John Carr
          wrote:<br>
        </div>
        <blockquote type="cite">
          <div class="WordSection1">
            <p class="MsoNormal"><span class="colour"
                style="color:windowtext">In the “Affirmation of
                Commitments”” didn’t ICANN promise to maintain WHOIS as
                an accurate and public data base? Shouldn’t the
                objective be to stay as close to that as possible in
                every national jurisdiction where that is legally
                allowed?</span><br>
            </p>
            <p class="MsoNormal"><span class="colour"
                style="color:windowtext"> </span><br>
            </p>
            <p class="MsoNormal"><span class="colour"
                style="color:windowtext">Or has ICANN decided that the
                promise it made in the Affirmation should now be
                formally abandoned or changed?</span><br>
            </p>
          </div>
        </blockquote>
      </blockquote>
      <div><br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
------------------------------------------------
"It is a disgrace to be rich and honoured
in an unjust state" -Confucius
 邦有道,贫且贱焉,耻也。邦无道,富且贵焉,耻也
------------------------------------------------
Dr Sam Lanfranco (Prof Emeritus & Senior Scholar)
Econ, York U., Toronto, Ontario, CANADA - M3J 1P3
email: <a class="moz-txt-link-abbreviated" href="mailto:Lanfran@Yorku.ca">Lanfran@Yorku.ca</a>   Skype: slanfranco
blog:  <a class="moz-txt-link-freetext" href="https://samlanfranco.blogspot.com">https://samlanfranco.blogspot.com</a>
Phone: +1 613-476-0429 cell: +1 416-816-2852</pre>
  </body>
</html>