<html>

  <head>

    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <p>Except that the domain name system is not YOUR system, it is

      ICANN's who has a very clear mandate for the security and

      stability of the internet.</p>

    <p>The purpose is NOT letting registrants get domains and helping

      registries get paid. It never has been.<br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 09/27/2017 09:52 AM, Volker Greimann

      wrote:<br>

    </div>

    <blockquote

      cite="mid:07dde2e8-2bd6-2a96-5825-0e7cc629b997@key-systems.net"

      type="cite">

      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

      <p>Hi Greg,</p>

      <p>I think we need to dig down even deeper initially. Instead of

        RDS, the core of the matter is the need for the data when

        defining the purpose for collection.</p>

      <p>This is very easy to answer for registrars: "We need (certain

        elements of) the data to be able to properly provide the

        business, invoice the customer, collect his payments, send

        reminders and notices, protect the rights of the customers in

        case of business failure, comply with legal requirements like

        record-keeping, etc.". I am leaving out any contractual

        requirements, as they do not matter for the registrars' own

        purpose. These are external purposes that the registrar would

        have to execute without having an own, direct need for. <br>

      </p>

      <p>For registries, it gets fuzzier as they do not have a direct

        connection to the registrants. From a service provision

        perspective, registries have no need for the data, and no right

        to it, except maybe for purposes of eligibility verification. <br>

      </p>

      <p>When going beyond registries to the general public, there is no

        purpose that connects to the provision of the service to the

        registrant directly. There also (in most countries) is no legal

        requirement to collect and publish this data. Yet there is still

        a need for the data, as we have discussed in great detail. <br>

      </p>

      <p>So our first question always must be the following:</p>

      <p>"How do we serve the needs of the general public that has an

        interest in the ability of obtaining such data without violating

        any applicable laws or the rights of the registrant to the

        privacy of his data?"</p>

      <p>This has to be the basis of any design decision and any

        argument made in this group. <br>

      </p>

      <p>Arguing that certain laws are unreasonable or unworkable is a

        dangerous question as it effectively proposes to ignore laws

        that we as a community do not like, at the risk of contracted

        parties and to the detriment of the beneficiaries of such laws.

        just because there has not been any enforcement action in the

        past does not mean we can ignore the law applicable to the

        individual contracted parties. And we are not talking about

        jaywalking here, some of these laws have significant penalties

        attached to them, as we have also discussed before.  <br>

      </p>

      <p>I agree with Greg that the ability of contracted parties to be

        free to make business decisions cannot be absolute. It has to be

        bound on the one side by ICANN policies and the other side by

        applicable law. And these two external pressures should not be

        in conflict with each other. If we can achieve that while

        answering the basic question above, our work is done. At least

        for the time being, as laws may obviously change, but that can

        be taken into account as well. Any discussion that seeks to

        circumvent this basic question will ultimately lead to the

        failure of our work and by extention to the end of whois. The

        latter due to the incompatibility of current whois with

        applicable law.<br>

      </p>

      <p>I think with our initial "purpose definition" exercise, we

        already went a great way in determining what those needs are and

        our current work to discuss data points goes into that question

        as well, even though personally I feel that by defining data

        points at this point and going into the sticks in some of the

        discussions we are wasting time. The question should never be

        "Do we need a Facebook contact in the RDS?" and always be "What

        contacts are needed as bare minimum to achieve needs X, Y, Z,

        ...". <br>

      </p>

      <p>Best,</p>

      <p>Volker<br>

      </p>

      <br>

      <div class="moz-cite-prefix">Am 27.09.2017 um 16:00 schrieb Greg

        Shatan:<br>

      </div>

      <blockquote type="cite"

cite="mid:CA+aOHUR2P3ETq727xJsbsiztsTUEYFXN8F3NuWv7HHKsCp7nqA@mail.gmail.com">

        <div dir="ltr">

          <div class="gmail_default"

            style="font-family:verdana,sans-serif">The "data

            controllers" here do not exist in a vacuum.  While

            registrars and registries need to be free to make many types

            of decisions in their own business judgment, that cannot be

            an absolute rule.  This is at odds with the ICANN model,

            consensus policy, etc.  In this case, the data controllers

            are part of a larger ecosystem, and the "needs" go beyond

            the individual business needs of each data controller.

            (Indeed, the individual data controller has its own database

            of information for its business needs.)</div>

          <div class="gmail_default"

            style="font-family:verdana,sans-serif"><br>

          </div>

          <div class="gmail_default"

            style="font-family:verdana,sans-serif">As I previously

            noted, we are going back to first principles -- which is not

            necessarily a bad thing.  Why does ICANN (and by extension,

            the Internet) need WHOIS/RDS?  That is the question.  Not

            "why does a particular [registrar/registry] need WHOIS/RDS?"</div>

          <div class="gmail_default"

            style="font-family:verdana,sans-serif"><br>

          </div>

          <div class="gmail_default"

            style="font-family:verdana,sans-serif">Greg</div>

          <div class="gmail_default"

            style="font-family:verdana,sans-serif"><br>

          </div>

        </div>

        <div class="gmail_extra"><br>

          <div class="gmail_quote">On Wed, Sep 27, 2017 at 5:12 AM,

            Volker Greimann <span dir="ltr">&lt;<a

                href="mailto:vgreimann@key-systems.net" target="_blank"

                moz-do-not-send="true">vgreimann@key-systems.net</a>&gt;</span>

            wrote:<br>

            <blockquote class="gmail_quote" style="margin:0 0 0

              .8ex;border-left:1px #ccc solid;padding-left:1ex">

              <div text="#000000" bgcolor="#FFFFFF">

                <p>So when will you start advocating the collection and

                  publication of WHOIS for internet users? Because they

                  would be connecting to your network all the time...</p>

                <span class="HOEnZb"><font color="#888888">

                    <p>Volker<br>

                    </p>

                  </font></span>

                <div>

                  <div class="h5"> <br>

                    <div class="m_7250297442223400888moz-cite-prefix">Am

                      26.09.2017 um 20:48 schrieb John Bambenek via

                      gnso-rds-pdp-wg:<br>

                    </div>

                  </div>

                </div>

                <blockquote type="cite">

                  <div>

                    <div class="h5">

                      <p>"<font size="+1"><font face="Lucida Grande">As

                            for privacy proxy solving the problem, it

                            does not.  Over collection is not solved by

                            providing a proxy in the third party

                            disclosure mechanism.  It is still

                            over-collection, disproportionate to needs."</font></font></p>

                      <p><font size="+1"><font face="Lucida Grande">I

                            fundamentally disagree because the purpose

                            of ICANN is not the mere facilitation of

                            domain from registry to registrant. The

                            purpose is the security and stability of the

                            internet and that means I have a need to

                            verify who is connecting to my network and

                            have a means of contacting them. That point

                            has never been made, to my knowledge, to

                            them.</font></font></p>

                      <p><font size="+1"><font face="Lucida Grande">The

                            point that removing that ability of me being

                            able to contact domain owners does far MORE

                            to REDUCE the privacy of the registrants

                            than does publishing said information.  We

                            talk often about verification out-of-band

                            for sensitive communications. How can I do

                            that without a phone number?</font></font></p>

                      <p><font size="+1"><font face="Lucida Grande">I

                            will loudly and vigorously argue that the

                            path advocated will make the problem FAR

                            worse and not better. Hopefully we don't get

                            to the point where I have actual data to

                            prove that.<br>

                          </font></font></p>

                      <br>

                      <div class="m_7250297442223400888moz-cite-prefix">On

                        9/26/2017 1:34 PM, Stephanie Perrin wrote:<br>

                      </div>

                      <blockquote type="cite"><font size="+1"><font

                            face="Lucida Grande">As for privacy proxy

                            solving the problem, it does not.  Over

                            collection is not solved by providing a

                            proxy in the third party disclosure

                            mechanism.  It is still over-collection,

                            disproportionate to needs.</font></font></blockquote>

                      <br>

                      <pre class="m_7250297442223400888moz-signature" cols="72">-- 

--

John Bambenek</pre>

                      <br>

                      <fieldset

                        class="m_7250297442223400888mimeAttachmentHeader"></fieldset>

                      <br>

                    </div>

                  </div>

                  <span class="">

                    <pre>______________________________<wbr>_________________

gnso-rds-pdp-wg mailing list

<a class="m_7250297442223400888moz-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 class="m_7250297442223400888moz-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>

                </span></blockquote>

              <div>

                <div class="h5">

                  <pre class="m_7250297442223400888moz-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.: <a href="tel:+49%206894%209396901" value="+4968949396901" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 901</a>

Fax.: <a href="tel:+49%206894%209396851" value="+4968949396851" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 851</a>

Email: <a class="m_7250297442223400888moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net" target="_blank" moz-do-not-send="true">vgreimann@key-systems.net</a>

Web: <a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.key-systems.net" target="_blank" moz-do-not-send="true">www.key-systems.net</a> / <a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.RRPproxy.net" target="_blank" moz-do-not-send="true">www.RRPproxy.net</a>

<a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.domaindiscount24.com" target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a> / <a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.BrandShelter.com" target="_blank" moz-do-not-send="true">www.BrandShelter.com</a>

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:

<a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a>

<a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems" target="_blank" moz-do-not-send="true">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="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.keydrive.lu" target="_blank" moz-do-not-send="true">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.

------------------------------<wbr>--------------

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.: <a href="tel:+49%206894%209396901" value="+4968949396901" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 901</a>

Fax.: <a href="tel:+49%206894%209396851" value="+4968949396851" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 851</a>

Email: <a class="m_7250297442223400888moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net" target="_blank" moz-do-not-send="true">vgreimann@key-systems.net</a>

Web: <a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.key-systems.net" target="_blank" moz-do-not-send="true">www.key-systems.net</a> / <a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.RRPproxy.net" target="_blank" moz-do-not-send="true">www.RRPproxy.net</a>

<a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.domaindiscount24.com" target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a> / <a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.BrandShelter.com" target="_blank" moz-do-not-send="true">www.BrandShelter.com</a>

Follow us on Twitter or join our fan community on Facebook and stay updated:

<a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a>

<a class="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems" target="_blank" moz-do-not-send="true">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="m_7250297442223400888moz-txt-link-abbreviated" href="http://www.keydrive.lu" target="_blank" moz-do-not-send="true">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>

              </div>

            </div>

            ______________________________<wbr>_________________

            gnso-rds-pdp-wg mailing list

            <a href="mailto:gnso-rds-pdp-wg@icann.org" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>

            <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>

          </blockquote>

        </div>

      </div>

      <fieldset class="mimeAttachmentHeader"></fieldset>

      <pre wrap="">_______________________________________________

gnso-rds-pdp-wg mailing list

<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>

<a moz-do-not-send="true" 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>

    <pre class="moz-signature" cols="72">-- 