<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Which is why its past time to get third-party independent legal advice instead of relying on activists and those with economic conflicts of interest telling us what is compliant.&nbsp;<br><br>Sent from my iPhone</div><div><br>On Jun 1, 2017, at 04:21, Volker Greimann &lt;<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  
  
    <p>Well, if whatever we develop is not in compliance with privacy
      laws, we are all wasting our time and working for the wastepaper
      basket. Anything we develop must be compliant or it will be
      unimplementable...<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Am 31.05.2017 um 22:26 schrieb Chen,
      Tim:<br>
    </div>
    <blockquote type="cite" cite="mid:CA+dThxfDRnx501Tjver1tDzpy+SqFFvn9GeeT0vUSk9CyTDYHQ@mail.gmail.com">
      <div dir="ltr">I am compelled to point out that making sure ICANN
        is compliant with privacy laws is not "the purpose of this WG".&nbsp;
        And I believe statements like that, which I hope and believe was
        made in brevity and not in fact, contribute to the belief shared
        by some here that others have distressingly myopic viewpoints as
        to what the outcome of all this work is meant to be.&nbsp; We are
        trying to solve a complex equation [sidebar, this thin whois
        piece should not be the hard part] not simply protect ICANN from
        the broad category of 'privacy laws' despite that being an
        important consideration.
        <div><br>
        </div>
        <div>Marika has been very clear in repeatedly pointing all of us
          to the original charter docs.&nbsp; This is how she (not me)
          summarized it weeks ago:</div>
        <div><br>
        </div>
        <div>
          <p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt
            0.5in;font-size:12pt;font-family:&quot;Times New
            Roman&quot;"><span style="font-size:11pt;font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:&quot;Times
                New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span><span style="font-size:11pt;font-family:Calibri">What are the
              fundamental requirements for gTLD registration data? When
              addressing this question, the PDP WG should consider, at a
              minimum, users and purposes and associated access,
              accuracy, data element, and privacy requirements.</span></p>
          <p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt
            0.5in;font-size:12pt;font-family:&quot;Times New
            Roman&quot;"><span style="font-size:11pt;font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:&quot;Times
                New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span><span style="font-size:11pt;font-family:Calibri">Is a new policy
              framework and next-generation RDS needed to address these
              requirements?</span></p>
          <p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt
            1in;font-size:12pt;font-family:&quot;Times New Roman&quot;"><span style="font-size:11pt;font-family:&quot;Courier New&quot;">o<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:&quot;Times
                New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span><span style="font-size:11pt;font-family:Calibri">If yes, what
              cross-cutting requirements must a next-generation RDS
              address, including coexistence, compliance, system model,
              and cost, benefit, and risk analysis requirements?</span></p>
          <p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt
            1in;font-size:12pt;font-family:&quot;Times New Roman&quot;"><span style="font-size:11pt;font-family:&quot;Courier New&quot;">o<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:&quot;Times
                New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span><span style="font-size:11pt;font-family:Calibri">If no, does the
              current WHOIS policy framework sufficiently address these
              requirements? If not, what revisions are recommended to
              the current WHOIS policy framework to do so?</span></p>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, May 31, 2017 at 12:01 PM,
          nathalie coupet via gnso-rds-pdp-wg <span dir="ltr">&lt;<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div>
              <div style="color:#000;background-color:#fff;font-family:Helvetica
                Neue,Helvetica,Arial,Lucida
                Grande,sans-serif;font-size:13px">
                <div id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414957" dir="ltr"><span id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414982">Benefits:
                    making sure ICANN is in compliance with privacy
                    laws. Isn't it the purpose of this WG? Issues
                    pertaining to cost and protection of IP address I
                    will leave other to answer. But it seems to me that
                    pseudonimization, randomization and encryption could
                    be candidate solutions.&nbsp;</span></div>
                <div id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414955"><br>
                </div>
                <div id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414953">&nbsp;</div>
                <div class="m_-4668158133892165091signature" id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414926">Nathalie&nbsp;</div>
                <div class="m_-4668158133892165091qtdSeparateBR"><br>
                  <br>
                </div>
                <div class="m_-4668158133892165091yahoo_quoted" style="display:block">
                  <div style="font-family:Helvetica
                    Neue,Helvetica,Arial,Lucida
                    Grande,sans-serif;font-size:13px">
                    <div style="font-family:HelveticaNeue,Helvetica
                      Neue,Helvetica,Arial,Lucida
                      Grande,sans-serif;font-size:16px">
                      <div dir="ltr"><font size="2" face="Arial"> On
                          Wednesday, May 31, 2017 2:48 PM, John Bambenek
                          via gnso-rds-pdp-wg &lt;<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>&gt;
                          wrote:<br>
                        </font></div>
                      <br>
                      <br>
                      <div class="m_-4668158133892165091y_msg_container">
                        <div id="m_-4668158133892165091yiv7219839472">
                          <div>
                            <div>This applies a web interface... would
                              an API be exposed for those of us who use
                              the command-line? Would there be a central
                              point of query or would a consumer have to
                              google it? Who pays for constructing such
                              a system and what is the commensurate
                              return on the investment for them paying
                              to make all this? If you are asking for
                              this information, surely you are also
                              getting source data (for instance consumer
                              IP, which can be PII), how will all that
                              be protected?</div>
                            <div>There is a whole lot of complexity, in
                              general, and costs for
                              registries/registrars, specifically.&nbsp; What
                              problem does this solve that it makes
                              sense to engineer a solution for it?<br clear="none">
                            </div>
                            <br clear="none">
                            <div class="m_-4668158133892165091yiv7219839472yqt6697870565" id="m_-4668158133892165091yiv7219839472yqtfd98173">
                              <div class="m_-4668158133892165091yiv7219839472moz-cite-prefix">On
                                5/31/2017 1:40 PM, nathalie coupet via
                                gnso-rds-pdp-wg wrote:<br clear="none">
                              </div>
                              <blockquote type="cite"> </blockquote>
                            </div>
                          </div>
                          <div class="m_-4668158133892165091yiv7219839472yqt6697870565" id="m_-4668158133892165091yiv7219839472yqtfd07002">
                            <div>
                              <div>Hi Chuck,</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
                              </div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature">My
                                position was and is to secure
                                unauthenticated access to thin data for
                                all.&nbsp;</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature">I
                                envisioned access to RDS through 3 chock
                                points to weed out bad actors as much as
                                possible:&nbsp;</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature">An
                                end-user would need to check the first
                                box for authenticated/unauthenticated
                                access, then another box for consumer
                                and a third would be to select the
                                purpose or a default purpose would be
                                selected for him (maybe no purpose could
                                also be possible).&nbsp;</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature">Consumers
                                don't need all the thin data to be
                                published for their simple queries,
                                since - in my mind - they want to make
                                sure the website is legitimate or they
                                want to identify the author in case of
                                abuse (such as defamation, abuse or
                                threats).&nbsp;</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature">If
                                the principle of proportionality doesn't
                                apply to most other cases, that's fine.
                                But I think it does apply for simple
                                consumer queries.&nbsp;</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature">This
                                is an interesting debate, but I never
                                thought it would lead to people actually
                                proposing to drop vital data for the
                                functioning of the Internet.</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature">I
                                had in mind the other principle that you
                                do not volunteer data when it is not
                                required. It should be useful. Not
                                because it is PPI, but out of caution.</div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
                              </div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
                              </div>
                              <div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
                                Sent from my iPhone</div>
                              <div><br clear="none">
                                On May 31, 2017, at 2:21 PM, Gomes,
                                Chuck &lt;<a rel="nofollow" shape="rect" href="mailto:cgomes@verisign.com" target="_blank" moz-do-not-send="true">cgomes@verisign.com</a>&gt;
                                wrote:<br clear="none">
                                <br clear="none">
                              </div>
                              <blockquote type="cite">
                                <div> </div>
                              </blockquote>
                            </div>
                            <div>
                              <div class="m_-4668158133892165091yiv7219839472WordSection1">
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">Nathalie,</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">
                                  &nbsp;</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">Thank
                                  you for your suggestion that the
                                  principle of proportionality be
                                  added.&nbsp; That has generated a very
                                  lively discussion.</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">
                                  &nbsp;</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">As
                                  I am sure you have seen, a lot of WG
                                  members have stated that they do not
                                  believe that the principle of
                                  proportionality applies to thin data
                                  and have provided what I think is
                                  pretty good rationale in support of
                                  their position.&nbsp; As the originator of
                                  the suggestion, do you still maintain
                                  that the principle applies to thin
                                  data?&nbsp; If so, how would you counter
                                  the arguments that have been made to
                                  the contrary?</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">
                                  &nbsp;</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">All
                                  – If anyone else thinks that the
                                  principle of proportionality applies
                                  to think data, please speak up and
                                  provide your counters to the arguments
                                  that have been made to the contrary.</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">
                                  &nbsp;</div>
                                <div class="m_-4668158133892165091yiv7219839472MsoNormal">Chuck</div>
                              </div>
                              <br clear="none">
                              <fieldset class="m_-4668158133892165091yiv7219839472mimeAttachmentHeader"></fieldset>
                              <br clear="none">
                              <pre>______________________________<wbr>_________________
gnso-rds-pdp-wg mailing list
<a rel="nofollow" shape="rect" class="m_-4668158133892165091yiv7219839472moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>
<a rel="nofollow" shape="rect" class="m_-4668158133892165091yiv7219839472moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a></pre>
                              <br clear="none">
                            </div>
                          </div>
                        </div>
                        <div class="m_-4668158133892165091yqt6697870565" id="m_-4668158133892165091yqtfd49125">______________________________<wbr>_________________<br clear="none">
                          gnso-rds-pdp-wg mailing list<br clear="none">
                          <a shape="rect" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br clear="none">
                          <a shape="rect" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a></div>
                        <br>
                        <br>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
            <br>
            ______________________________<wbr>_________________<br>
            gnso-rds-pdp-wg mailing list<br>
            <a href="mailto:gnso-rds-pdp-wg@icann.org" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
            <a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
          </blockquote>
        </div>
        <br>
      </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>
    <pre class="moz-signature" cols="72">-- 
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>

Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken 
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a> 

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>

Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>

Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken 
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a> 

This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.



</pre>
  

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>gnso-rds-pdp-wg mailing list</span><br><span><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a></span><br><span><a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></span></div></blockquote></body></html>