<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Good question Tom, and I guess we will have to see how the
      providers of services will deal with it. I certainly do not
      remember giving consent in the required form when I joined
      Facebook or was auto-joined to Google Plus...</p>
    <p>VG<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Am 01.06.2017 um 18:17 schrieb Tom
      Lancaster:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAO2t5r4Fre3XoHZ20qPVoWPyNX8ML9tq3_pJ=anMS7AYVfcYhw@mail.gmail.com">
      <div dir="ltr">
        <div><span style="font-size:12.8px">How do other fields get
            around this? WHOIS data is not the first domain where by
            participating the participant will have to publish a small
            amount of data that could be considered PII for the world to
            see....</span><br>
        </div>
        <div><span style="font-size:12.8px"><br>
          </span></div>
        <div><span style="font-size:12.8px">For example, if I create
            pretty much any social media account, my username/profile
            name could be considered PII, and by default it (and likely
            a whole bunch of other data) would be visible to anyone who
            searches for it on that social media platform... How is
            creating a domain different in terms of the privacy
            regulations and public visibility of the data therein?</span></div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 1 June 2017 at 17:08, 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>As it has been brought up by Dotzero in a very reckless
                manner, I feel it is important to point out what
                "consent" actually means in the context of the GDPR:</p>
              <p>First, implied consent is no longer sufficient under
                the current regulation. The GDPR requires that the data
                subject signals agreement to the specific and defined
                use of its data by "a statement or a clear affirmative
                action".</p>
              <p>In other words, an explicit and seperate opt-in is
                required, where the action of providing consent is
                clearly distinguishable from any other matters in a
                written document. This may be ticking a seperate box on
                a website or choosing specific technical settings, but
                in all cases it must be based on an explanation of what
                it is that the data subject is agreeing to. Silence,
                pre-ticked boxes or inactivity is insufficient. Hiding
                the consent clauses in the registration agreement is
                insufficient.<br>
              </p>
              <p>This consent must be "freely given, specific, informed
                and unambiguous."</p>
              <p>Fun stuff comes in the next bit:</p>
              <p><span class="m_-2603083178053328424md">The controller
                  is required to provide “accurate and full information
                  on all relevant issues,” including the nature of the
                  data that will be processed, the purposes of
                  processing, the identity of the controller, and<b> the
                    identity of any other recipients of the data</b>.</span></p>
              <p><span class="m_-2603083178053328424md">I will highlight
                  the salient part again: "ANY OTHER RECIPIENTS OF THE
                  DATA." So no expansion of those with access at a later
                  data, because that would immediately invalidate the
                  consent given.</span></p>
              <p><span class="m_-2603083178053328424md">Finally, this:</span></p>
              <p><span class="m_-2603083178053328424md">"</span><span
                  class="m_-2603083178053328424md">Importantly, a
                  controller may not make a service conditional upon
                  consent, unless the processing is necessary for the
                  service." <br>
                  So no consent can be construed for any uses beyond the
                  functioning of the service, the internet and any other
                  use tied directly to the service. All those nice uses
                  that whois data is currently put to that have nothing
                  to do with the service that is provided to the data
                  subject? Say goodbye to them now!<br>
                </span></p>
              Further reading for those so inclined:<br>
              <a class="m_-2603083178053328424moz-txt-link-freetext"
href="https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-3-consent/"
                target="_blank" moz-do-not-send="true">https://iapp.org/news/a/top-<wbr>10-operational-impacts-of-the-<wbr>gdpr-part-3-consent/</a><br>
              <br>
              <span class="m_-2603083178053328424md">Also note that the
                consent provided by current registrant does not satisfy
                the requirements, so what happens with legacy data with
                regard to its import into any RDS system will be a whole
                new nightmare down the road.</span><br>
              <br>
              <div class="m_-2603083178053328424moz-cite-prefix">Am
                01.06.2017 um 17:41 schrieb Michael Peddemors:<br>
              </div>
              <blockquote type="cite">+1 <br>
                <br>
                On 17-06-01 07:47 AM, Dotzero wrote: <br>
                <blockquote type="cite">The issue you raise is addressed
                  simply enough by requiring a privacy <br>
                  disclosure be displayed at the time of domain
                  registration. This <br>
                  requirement can be incorporated into the ICANN
                  registry agreements. Note <br>
                  that this does not resolve the issue for CC domains. <br>
                  <br>
                  Michael Hammer <br>
                  <br>
                  On Thu, Jun 1, 2017 at 10:43 AM, Stephanie Perrin <br>
                  &lt;<a
                    class="m_-2603083178053328424moz-txt-link-abbreviated"
                    href="mailto:stephanie.perrin@mail.utoronto.ca"
                    target="_blank" moz-do-not-send="true">stephanie.perrin@mail.<wbr>utoronto.ca</a>
                  <br>
                  <a class="m_-2603083178053328424moz-txt-link-rfc2396E"
                    href="mailto:stephanie.perrin@mail.utoronto.ca"
                    target="_blank" moz-do-not-send="true">&lt;mailto:stephanie.perrin@mail.<wbr>utoronto.ca&gt;</a>&gt;
                  wrote: <br>
                  <br>
                      I certainly agree that if people enter personal
                  information as part <br>
                      of their DNS registration or their motor vehicle
                  licence <br>
                      registration, it is done with implied consent...
                  as long as there is <br>
                      sufficient information to permit them to
                  understand just how the <br>
                      data is being used and where it is going. 
                  However, as I tried to <br>
                      say with respect to registering a domain name, I
                  really don't think <br>
                      the average non-expert citizen who might want to
                  register a domain <br>
                      name would get enough information to truly
                  understand how far <br>
                      his/her information goes, and how difficult it is
                  to get it removed <br>
                      once it has appeared in the public record.  We
                  should build this <br>
                      system so that everyone understands it, not just
                  the experts. <br>
                  <br>
                      cheers Stephanie <br>
                  <br>
                  <br>
                      On 2017-06-01 05:18, jonathan matkowsky wrote: <br>
                  <blockquote type="cite">    Stephanie, <br>
                    <br>
                        ​I agree with you that we should not conflate
                    collection <br>
                        limitation principles with openness principles.
                    <br>
                    <br>
                        I respectfully disagree with most of what you
                    wrote in the first <br>
                        paragraph of your post script. <br>
                        Here we are talking about users potentially
                    entering personal or <br>
                        pseudonymous information when they are not being
                    asked for it (nor <br>
                        is it required) to begin with, and it is not
                    required for purposes <br>
                        of which it's being collected.​ That is the <br>
                    <br>
                        ​scope <br>
                         of what needs to be assessed <br>
                        ​if at all and how the scope needs to be <br>
                         defined from the beginning <br>
                        ​ if you were to conduct a PIA​ <br>
                        . <br>
                        ​ ​ <br>
                    <br>
                        ​ <br>
                         ​ <br>
                        Personal information is not being used or
                    intended to be used just <br>
                        because a person decides to enter personal
                    information into a field. <br>
                        ​ <br>
                        The example of how you can combine databases to
                    re-identify a <br>
                        person based on the SOA record is the equivalent
                    of protecting <br>
                        domain names as personal information because a
                    person <br>
                        can register their driver's license <br>
                        ​ or name and date of birth​ <br>
                        as a domain name. <br>
                        ​ <br>
                        I would argue no PIA should be required <br>
                        ​as a result ​ <br>
                        even in accordance even with best practices. <br>
                        ​ <br>
                        A PIA needs to be conducted in a manner that is
                    commensurate with <br>
                        the level of privacy risk identified <br>
                        ​. <br>
                    <br>
                        I respectfully disagree with ​you that thin data
                    is personal. We <br>
                        are talking about identifiers (codes or strings
                    that represent an <br>
                        individual or device).  Many labels can be used
                    to point to <br>
                        individuals. Some are precise and most,
                    imprecise or vague. <br>
                        There's no question that an IP address is a
                    device identifier. <br>
                        Device IDs, MAC addresses can be a source for
                    user tracking.  But <br>
                        ​i <br>
                        ​dentifiers can be strong or weak depending on
                    how precise they <br>
                        are as well as the context. It cannot be
                    measured without taking <br>
                        linkability into consideration.  For that
                    reason, name servers are <br>
                        not the same as IP addresses or MAC addresses
                    any more so than the <br>
                        existence of a domain name is an identifier. If
                    a person chooses <br>
                        to use identifiable information when it is not
                    being asked for or <br>
                        required for purposes of which the data is being
                    collected, that <br>
                        does that mean we need to classify all the data
                    according to that <br>
                        unlikely scenario. Those setting up their own
                    DNS would be <br>
                        relatively speaking, sophisticated Internet
                    users that presumably <br>
                        know the basics of how DNS operates in any case,
                    so by entering <br>
                        the information in that way, they are choosing
                    to customize their <br>
                        DNS in a personal way similar to a person that
                    chooses to show <br>
                        personal information on their license plate
                    number. <br>
                    <br>
                        ​I know that the motor vehicle registry is
                    restricted now in most <br>
                        places so that you would need a subpoena to get
                    that kind of <br>
                        personal information. This is also true of an IP
                    address though <br>
                        and IP providers. The fact is a person can put
                    their name and date <br>
                        of birth on a license plate if they want to
                    customize it. And then <br>
                        they get on the road. That does not mean the
                    license plate numbers <br>
                        are all personal information. It's pseudonymous
                    data. It is true <br>
                        that it is a stronger identifier than an IP
                    address insofar as if <br>
                        you subpoena the motor vehicle registry
                    operator, you will get the <br>
                        personal information behind that license plate
                    number. If you <br>
                        subpoena the ISP, you MIGHT get the personal
                    information depending <br>
                        on the nature of the IP address. It's still true
                    that to drive a <br>
                        car, you need to show your license plate number
                    on the vehicle. <br>
                    <br>
                        I would argue that thin Whois data is
                    pseudonymous or personal <br>
                        data to the same extent that a person can choose
                    to _customize_ a <br>
                        license plate if they want to, and put personal
                    or psuedonymous <br>
                        data into fields <br>
                        for which the data being collected does not ask
                    for or require <br>
                        them to do so. <br>
                        ​ <br>
                    <br>
                        A <br>
                         person can register their driver's license as a
                    domain name. <br>
                        They can use a personal email in their SOA
                    record, or personal NS. <br>
                        Just because it's theoretically possible for
                    someone to enter <br>
                        pseudonymous (or even personal) data into
                    multiple databases when <br>
                        they are not being asked for it, and those
                    combination of choices <br>
                        make it possible to identify them, does not mean
                    one of the sets <br>
                        (Thin Whois) should be classified as personal
                    information subject <br>
                        to a PIA. <br>
                    <br>
                        ​ <br>
                    <br>
                        Jonathan Matkowsky, <br>
                        VP – IP &amp; Brand Security <br>
                        USA:: <a href="tel:%28347%29%20467-1193"
                      value="+13474671193" target="_blank"
                      moz-do-not-send="true">1.347.467.1193</a> <a
                      class="m_-2603083178053328424moz-txt-link-rfc2396E"
                      href="tel:%28347%29%20467-1193" target="_blank"
                      moz-do-not-send="true">&lt;tel:%28347%29%20467-1193&gt;</a>
                    | Office:: <br>
                        <a href="tel:+972%208-926-2766"
                      value="+97289262766" target="_blank"
                      moz-do-not-send="true">+972-(0)8-926-2766</a> <a
class="m_-2603083178053328424moz-txt-link-rfc2396E"
                      href="tel:+972%208-926-2766" target="_blank"
                      moz-do-not-send="true">&lt;tel:+972%208-926-2766&gt;</a>
                    <br>
                        Emergency mobile:: <a
                      href="tel:+972%2054-924-0831"
                      value="+972549240831" target="_blank"
                      moz-do-not-send="true">+972-(0)54-924-0831</a> <a
class="m_-2603083178053328424moz-txt-link-rfc2396E"
                      href="tel:+972%2054-924-0831" target="_blank"
                      moz-do-not-send="true">&lt;tel:+972%2054-924-0831&gt;</a>
                    <br>
                        Company Reg. No. 514805332 <br>
                        11/1 Nachal Chever, Modiin Israel <br>
                        Website <a
                      class="m_-2603083178053328424moz-txt-link-rfc2396E"
                      href="http://www.riskiq.co.il" target="_blank"
                      moz-do-not-send="true">&lt;http://www.riskiq.co.il&gt;</a>
                    <br>
                        RiskIQ Technologies Ltd. (wholly-owned by
                    RiskIQ, Inc.) <br>
                    <br>
                        On Thu, Jun 1, 2017 at 12:02 AM, Stephanie
                    Perrin <br>
                        &lt;<a
                      class="m_-2603083178053328424moz-txt-link-abbreviated"
                      href="mailto:stephanie.perrin@mail.utoronto.ca"
                      target="_blank" moz-do-not-send="true">stephanie.perrin@mail.<wbr>utoronto.ca</a>
                    <br>
                        <a
                      class="m_-2603083178053328424moz-txt-link-rfc2396E"
                      href="mailto:stephanie.perrin@mail.utoronto.ca"
                      target="_blank" moz-do-not-send="true">&lt;mailto:stephanie.perrin@mail.<wbr>utoronto.ca&gt;</a>&gt;
                    wrote: <br>
                    <br>
                            Your summary today was great Andrew. <br>
                    <br>
                            I am not arguing about the disclosure of
                    thin data.  We <br>
                            already voted on unauthenticated mandatory
                    disclosure, weeks <br>
                            ago (or at least it feels like weeks ago). 
                    Lets please move <br>
                            on.  We are debating this yet again, because
                    people keep <br>
                            asking, is thin data personal?  [lots of
                    people missed the <br>
                            last call]  The answer is yes (IMHO).  Does
                    that mean it <br>
                            cannot be disclosed?  The answer is no. 
                    Does the <br>
                            proportionality principle apply?  Yes.  Have
                    we already gone <br>
                            through this?  Yes.  Can we come back to
                    it?  Yes, but <br>
                            hopefully only if we have to.....we will
                    have to when we get <br>
                            to data elements. <br>
                    <br>
                            cheers Stephanie <br>
                            PS a fundamental problem here is that people
                    try to categorize <br>
                            information that in their view should be
                    disclosed, as not <br>
                            personal information.  This fight has gone
                    on for years over <br>
                            IP address, for instance.  The important
                    question is not <br>
                            actually whether it is personal data or not,
                    it is "do you <br>
                            need to disclose it to make things
                    work?"....and if the answer <br>
                            is yes then you try to mitigate the
                    disclosure and try to keep <br>
                            it minimized to what is absolutely
                    required.  Hence the PIA, <br>
                            which should employ both data minimization
                    and the test in the <br>
                            proportionality principle as techniques to
                    evaluate data elements. <br>
                            A good and really simple example is a phone
                    number.  IS it <br>
                            personal info?  (the telcos fought for
                    years, trying to claim <br>
                            they owned it and it was not personal). 
                    Obviously it pertains <br>
                            to you, people feel strongly that it is
                    personal (culturally <br>
                            relative of course but...) and yet if noone
                    ever learns your <br>
                            number your phone won't ever receive a
                    call.  That does not <br>
                            mean you have to disclose it
                    everywhere.....only where <br>
                            necessary.  And it should mean that it does
                    not have to follow <br>
                            you everywhere, but that is becoming
                    increasingly hard to <br>
                            manage.... <br>
                    <br>
                            By the way, informed consent is not the same
                    as transparency <br>
                            requirements.  Transparency requirements are
                    exactly <br>
                            that....you have to be transparent about
                    what you are doing <br>
                            with data.  Let us not conflate that with
                    consent. <br>
                    <br>
                            I will quit now and stop trying to answer
                    questions.  I would <br>
                            like to humbly suggest, however, that we
                    have a real shortage <br>
                            of basic understanding of how data
                    protection law works and is <br>
                            interpreted.  If there is a data protection
                    law expert that <br>
                            folks might listen to, we should hire that
                    person to advise <br>
                            us.  It might save a lot of time. <br>
                    <br>
                    <br>
                            On 2017-05-31 16:00, Andrew Sullivan wrote:
                    <br>
                    <blockquote type="cite">        Hi, <br>
                      <br>
                              On Wed, May 31, 2017 at 03:20:59PM -0400,
                      Stephanie Perrin wrote: <br>
                      <blockquote type="cite">        That does not mean
                        we need to protect it, it means we have to
                        examine it in <br>
                                terms of DP law.  May I repeat the
                        suggestion that Canatacci made in <br>
                                Copenhagen in response to a
                        question.....(I forget the precise question he <br>
                                was asked, sorry). If you want to figure
                        out whether you have to protect <br>
                                something or not, do a privacy impact
                        assessment. <br>
                      </blockquote>
                              As I think I've said more than once in
                      this thread, I think we _have_ <br>
                              done that assessment and I think the
                      answers are obvious and I think <br>
                              therefore that there is nothing more to
                      say about this principle in <br>
                              respect of thin data: <br>
                      <br>
                                  - the data is either necessary for the
                      operation of the system <br>
                                    itself or else necessary for
                      distributed operation and <br>
                                    troubleshooting on the Internet. <br>
                      <br>
                                  - the data does not expose identifying
                      information about anyone, <br>
                                    except in rather strained examples
                      where the identifying <br>
                                    information is already completely
                      available via other means. <br>
                      <br>
                              What more is one supposed to do? <br>
                      <br>
                              Best regards, <br>
                      <br>
                              A <br>
                      <br>
                    </blockquote>
                    <br>
                    <br>
                            ______________________________<wbr>_________________
                    <br>
                            gnso-rds-pdp-wg mailing list <br>
                            <a
                      class="m_-2603083178053328424moz-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_-2603083178053328424moz-txt-link-rfc2396E"
                      href="mailto:gnso-rds-pdp-wg@icann.org"
                      target="_blank" moz-do-not-send="true">&lt;mailto:gnso-rds-pdp-wg@icann.<wbr>org&gt;</a>
                    <br>
                            <a
                      class="m_-2603083178053328424moz-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>
                    <br>
                            <a
                      class="m_-2603083178053328424moz-txt-link-rfc2396E"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
                      target="_blank" moz-do-not-send="true">&lt;https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg&gt;</a>
                    <br>
                    <br>
                    <br>
                  </blockquote>
                  <br>
                  <br>
                      ______________________________<wbr>_________________
                  <br>
                      gnso-rds-pdp-wg mailing list <br>
                      <a
                    class="m_-2603083178053328424moz-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_-2603083178053328424moz-txt-link-rfc2396E"
                    href="mailto:gnso-rds-pdp-wg@icann.org"
                    target="_blank" moz-do-not-send="true">&lt;mailto:gnso-rds-pdp-wg@icann.<wbr>org&gt;</a>
                  <br>
                      <a
                    class="m_-2603083178053328424moz-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>
                  <br>
                      <a
                    class="m_-2603083178053328424moz-txt-link-rfc2396E"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
                    target="_blank" moz-do-not-send="true">&lt;https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg&gt;</a>
                  <br>
                  <br>
                  <br>
                  <br>
                  <br>
                  ______________________________<wbr>_________________ <br>
                  gnso-rds-pdp-wg mailing list <br>
                  <a
                    class="m_-2603083178053328424moz-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>
                  <br>
                  <a class="m_-2603083178053328424moz-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>
                  <br>
                  <br>
                </blockquote>
                <br>
                <br>
                <br>
              </blockquote>
              <br>
              <pre class="m_-2603083178053328424moz-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_-2603083178053328424moz-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_-2603083178053328424moz-txt-link-abbreviated" href="http://www.key-systems.net" target="_blank" moz-do-not-send="true">www.key-systems.net</a> / <a class="m_-2603083178053328424moz-txt-link-abbreviated" href="http://www.RRPproxy.net" target="_blank" moz-do-not-send="true">www.RRPproxy.net</a>
<a class="m_-2603083178053328424moz-txt-link-abbreviated" href="http://www.domaindiscount24.com" target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a> / <a class="m_-2603083178053328424moz-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_-2603083178053328424moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a>
<a class="m_-2603083178053328424moz-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_-2603083178053328424moz-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_-2603083178053328424moz-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_-2603083178053328424moz-txt-link-abbreviated" href="http://www.key-systems.net" target="_blank" moz-do-not-send="true">www.key-systems.net</a> / <a class="m_-2603083178053328424moz-txt-link-abbreviated" href="http://www.RRPproxy.net" target="_blank" moz-do-not-send="true">www.RRPproxy.net</a>
<a class="m_-2603083178053328424moz-txt-link-abbreviated" href="http://www.domaindiscount24.com" target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a> / <a class="m_-2603083178053328424moz-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_-2603083178053328424moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a>
<a class="m_-2603083178053328424moz-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_-2603083178053328424moz-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>
            <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>
    </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>
  </body>
</html>