[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access

Gomes, Chuck cgomes at verisign.com
Wed May 31 17:45:09 UTC 2017


Stephanie,



Do you consider any of the thin data elements as we have defined them so far to be 'personal data'?



Chuck



From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Stephanie Perrin
Sent: Wednesday, May 31, 2017 12:45 PM
To: gnso-rds-pdp-wg at icann.org
Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access



I think it is a very good summary.  One issue which we do not discuss very often is the fact that end users who register a domain name do not understand very well (if at all) what the implications for their privacy are.  A requirement of most data protection law is to provide transparency with respect to what happens to personal data.  This job, in my view, has not been tackled by ICANN in the required way.  So while I agree with the summary, it raises the issue, for those of us who do not understand what an SOA record is, what thin data is, how the DNS operates, etc. there is an obligation on ICANN, through its contractual control of the registries and registrars, to provide greater clarity about how personal data is managed, and what the risks might be for the individual.  Simply saying "Let's remember we are talking about the public, open Internet here. Nobody has to participate that doesn't want to, just like if I don't want anyone to see my license plate number on the road, I don't have to drive a car either. "  is not adequate.  (Licence registries, by the way, have become private in most jurisdictions because of the risk to registrants, so the chances of being stalked by some nut with road rage have mercifully decreased).

 Stephanie Perrin





On 2017-05-31 11:07, Gomes, Chuck via gnso-rds-pdp-wg wrote:

   I am open to disagreement, but it seems to me that Jonathan provides a good summary and maybe even a fair conclusion of the extensive discussion that has occurred on this thread since Tuesday.  Rather than continuing the extensive back and forth, which in my assessment is mostly repeating things that have already been said several times, I request that anyone who disagrees with Jonathan's conclusions to identify what you disagree with and provide your reasoning.



   Chuck



   From: gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of jonathan matkowsky
   Sent: Wednesday, May 31, 2017 10:52 AM
   To: Dotzero <dotzero at gmail.com><mailto:dotzero at gmail.com>; Volker Greimann <vgreimann at key-systems.net><mailto:vgreimann at key-systems.net>
   Cc: RDS PDP WG <gnso-rds-pdp-wg at icann.org><mailto:gnso-rds-pdp-wg at icann.org>
   Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access



   I think the discussion here reflects confusion between what's available in DNS based on the domain name alone, and Thin Whois data. The fact of whether SOA records or A records may contain PII  is a totally separate issue than Thin Whois data elements.



   Based on a domain name alone, one can use it to query DNS for record elements that may contain PII or when combined with other data, can be used to obtain PII. But all of this PII is in the public domain voluntarily by their owners, and more importantly, is outside the framework of discussion, which is limited to Whois database--not DNS. They are simply not the same.



   So the fact that you can get SOA records from the domain name alone begs the question of whether the domain name needs to be protected because when combined with other data elements, can be used to obtain PII.



   But the domain names are publicly available on the internet by virtue of being in the zone files. So the fact you can obtain the domain from thin Whois doesn't make it any more available than it is from the zone files. It is outside the framework of discussion.



   The thin Whois database is not what is making domain names available--so the SOA records for the domain is not a good example, even if someone put PII in that field--as that is an issue of domain names being publicly available together with DNS. Totally outside the framework of discussion.



   The creation date of a domain, the NS records, when the domain was last updated, and the registrar of record are simply not by any stretch of the imagination arguably PII by virtue of Whois. This is information that was voluntarily made public by virtue of using the public Internet which relies on DNS.



   Privacy enthusiasts can use .Onion if they want to. But if they want to use the open Internet, that means some basic data by definition is publicly available in the DNS. If they want to protect their privacy, then they need to use common sense and not put information they dont want to be made public into the public.



   The creation date is as a matter of fact, used as one of several indicators to show a domain engaged in malicious activity was unlikely a victim of being compromised. It is a critical piece of data but also not by any stretch of the wildest imagination PII.



   The principle of proportionality doesn't apply to thin data unless you want to argue it applies to the very fact a domain name record was created in the public Internet. By creating the record, a user has chosen to make that record's existence public--regardless of whether they use privacy protection or not. If I register my name and birthday as a domain name, it is PII, but PII that I chose to be made publicly available by virtue of creating the domain and putting it into the zone. Does that mean I am somehow entitled to have all the RFCs re-written for me and for the public  Internet to be made private? Of course not. So when people make things public voluntarily by virtue of participating in society, the principles of data protection apply differently. Let's remember we are talking about the public, open Internet here. Nobody has to participate that doesn't want to, just like if I don't want anyone to see my license plate number on the road, I don't have to drive a car either.







   On Wed, 31 May 2017 at 16:50 Dotzero <dotzero at gmail.com<mailto:dotzero at gmail.com>> wrote:

      Translation (per Google translate) of what Volker posted:

      "On the basis of the ECJ ruling, the factual feature" personal data "of § 12 (1) and (2) TMG in conjunction with § 3 (1) BDSG must be interpreted in accordance with the guidelines: a dynamic IP address provided by a provider of online media services In the case of access by a person to a website, which is made generally accessible by the provider, constitutes a (protected) personal date for the provider.

      The IP address can only be stored as a personal date under the prerequisites of § 15 (1) TMG. This provision is to be applied in accordance with the provisions of Article 7 (f) of Directive 95/46 EC, as interpreted by the Court of Justice, to the effect that a provider of on-line media services may collect personal data of a user without the consent of the user of the services To the extent that their collection and use is necessary to ensure the general functioning of the services. However, there is a need to balance the interests and the basic rights and freedoms of the users. "



      On Wed, May 31, 2017 at 9:47 AM, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>> wrote:

         Why, just this month the German Bundesgerichtshof confirmed this in a review of a decision of the state court Berlin ( Az. VI ZR 135/13):

         http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py?Gericht=bgh&Art=pm&Datum=2017&Sort=3&nr=78289&pos=0&anz=74

         It followed the decision of the European Court from October last year:

         C-582/14, NJW 2016, 3579

         The German explanation:

         "Auf der Grundlage des EuGH-Urteils ist das Tatbestandsmerkmal "personenbezogene Daten" des § 12 Abs. 1 und 2 TMG in Verbindung mit § 3 Abs. 1 BDSG richtlinienkonform auszulegen: Eine dynamische IP-Adresse, die von einem Anbieter von Online-Mediendiensten beim Zugriff einer Person auf eine Internetseite, die dieser Anbieter allgemein zugänglich macht, gespeichert wird, stellt für den Anbieter ein (geschütztes) personenbezogenes Datum dar.

         Als personenbezogenes Datum darf die IP-Adresse nur unter den Voraussetzungen des § 15 Abs. 1 TMG gespeichert werden. Diese Vorschrift ist richtlinienkonform entsprechend Art. 7 Buchst. f der Richtlinie 95/46 EG - in der Auslegung durch den EuGH - dahin anzuwenden, dass ein Anbieter von Online-Mediendiensten personenbezogene Daten eines Nutzers dieser Dienste ohne dessen Einwilligung auch über das Ende eines Nutzungsvorgangs hinaus dann erheben und verwenden darf, soweit ihre Erhebung und ihre Verwendung erforderlich sind, um die generelle Funktionsfähigkeit der Dienste zu gewährleisten. Dabei bedarf es allerdings einer Abwägung mit dem Interesse und den Grundrechten und -freiheiten der Nutzer."

         Hope this helps.



         Am 31.05.2017 um 15:38 schrieb Paul Keating:

               See: recent Europrean court decisions on IP addresses as PII.



            Can you please provide the citations?  I a-m not aware of any court decision issuingsuch a broad ruling.



            Thanks,



            Paul

            Sent from my iPad


            On 31 May 2017, at 12:20, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>> wrote:

               In some cases the ability to use data set A in combination with data set B to enable one to identify an individual turns data set A into PII.

               See: recent Europrean court decisions on IP addresses as PII.

               I am with you in viewing thin data as rather unlikely to be defined as PII, but depending on how this data is used it is not inconceivable that it may be found to contain PII depending on the use. Unlikely, but not impossible.

               Volker



               Am 30.05.2017 um 23:40 schrieb Paul Keating:

                  Im sorry but i don't see the logic here (or the legal constraint)



                  Privacy laws protect personal data of INDIVIDUALS.  They do t protect non-personal data or data from non-individuals.



                  Nothing on the list below is personal data.  And no e of the principles given by Natalie apply.



                  The fact that i could use the data to obtain other data is irrelevant.  I can use a car to rob a bank but that itself is not a reason to restrict access to automobiles.



                  Me thinks you are trying to create a scarcity for some reason.

                  Sent from my iPad


                  On 30 May 2017, at 23:22, Chris Pelling <chris at netearth.net<mailto:chris at netearth.net>> wrote:

                     ok - a thought :



                     Thin data includes nameservers, being able to mass collect thin data gaining NS information then allows you to do a DIG of a SOA record on the DNS service to gain the email address of the hostmaster :



                     Some examples (radomly picked from the list)  :

                     gmail.com<http://gmail.com> :

                     SOA     ns1.google.com<http://ns1.google.com>. dns-admin.google.com<http://dns-admin.google.com>. 157458041 900 900 1800 60
                     netearthone.com<http://netearthone.com>

                     SOA     ns1.netearth.net<http://ns1.netearth.net>. root.netearthone.com<http://root.netearthone.com>. 2016090201<tel:%28201%29%20609-0201> 14400 3600 1209600 86400

                     law.es<http://law.es>

                     SOA     ns1.eurodns.com<http://ns1.eurodns.com>. hostmaster.eurodns.com<http://hostmaster.eurodns.com>. 2016061402<tel:%28201%29%20606-1402> 43200 7200 1209600 86400

                     riskiq.net<http://riskiq.net>

                     SOA     ns-1754.awsdns-27.co.uk<http://ns-1754.awsdns-27.co.uk>. awsdns-hostmaster.amazon.com<http://awsdns-hostmaster.amazon.com>. 1 7200 900 1209600 86400



                     Now as you can see - those above examples allow you to get (or build) an email list.  Most will normally point to the providers service, but, some that are DIY'ing their hosting, it might not be.



                     Kind regards,

                     Chris




                       _____


                     From: "allison nixon" <elsakoo at gmail.com<mailto:elsakoo at gmail.com>>
                     To: "nathalie coupet" <nathaliecoupet at yahoo.com<mailto:nathaliecoupet at yahoo.com>>
                     Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>
                     Sent: Tuesday, 30 May, 2017 21:52:32
                     Subject: Re: [gnso-rds-pdp-wg] Principle on Proportionality for "Thin        Data"access



                     so can you name one specific example of how someone could abuse thin data?



                     On Tue, May 30, 2017 at 4:50 PM, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>> wrote:

                        Abuse is the improper usage or treatment of an entity<https://en.wikipedia.org/wiki/Entity>, often to unfairly<https://en.wikipedia.org/wiki/Distributive_justice> or improperly gain benefit. In our context, abuse is the improper usage of WHOIS/RDS to unfairly or improperly gain access to information or to game the system.



                        Here are some of the overarching principles which should guide us when building RDS:



                        DATA LIFECYCLE                        PRIVACY PRINCIPLE                                       PROTECTION MEASURE

                        Collection                       Proportionality and purpose specification                     Data minimisation, Data quality

                        Storage                   Accountability, Security measures, Sensitive data               Confidentiality, Encryption, Pseudonomisation

                        Sharing and processing Lawfulness and fairness, Consent, Right of access  Data access control, Data leakage prevention

                        Deletion                               Openness, Right to erasure                                        Retention, Archival, Erasure





                        If such principles are not respected, ICANN will be liable. Consumers don't need to have all the thin data when making a query. This could protect them and enable them to have access to the RDS without raising much opposition.



                        Now, we could discuss the possibility for broader query types. These principles would still apply, but would be contextualized in order to take into account new sets of parameters for each broader query. By increasing granularity as much as possible, while applying these aformentioned principles, we just might find a way to accomodate everyone.







                        Nathalie



                        On Tuesday, May 30, 2017 4:00 PM, John Horton <john.horton at legitscript.com<mailto:john.horton at legitscript.com>> wrote:



                        I was going to reply to Natalie's email as well, but Paul's comments capture my thoughts, so: +1.




                        John Horton
                        President and CEO, LegitScript



                        Follow LegitScript: LinkedIn<http://www.linkedin.com/company/legitscript-com>  |  Facebook<https://www.facebook.com/LegitScript>  |  Twitter<https://twitter.com/legitscript>  |  Blog<http://blog.legitscript.com/>  |  Google+<https://plus.google.com/112436813474708014933/posts>





                        On Tue, May 30, 2017 at 12:57 PM, Paul Keating <paul at law.es<mailto:paul at law.es>> wrote:

                           Natalie,



                           Thank you for the email.  Im copying the list because i see others have replied to your comment.



                           I strenuously object to the concept.  We are discussing THIN DATA ONLY HERE.  Unless someone can explain to me why any of this data set has privacy concerns this is a non-issue.  I would certainly appreciate someone explaining what, if any, privacy issues are perceived to be at issue here.



                           Moreover, while you suggest that the idea escapes the need to declare a purpose, it does nothing but reinforce a subjective criteria based system in which the declared purpose is used to somehow limit the data being retrieved.



                           If i am missing something please let me know.


                           Paul


                           Sent from my iPad


                           On 30 May 2017, at 21:08, nathalie coupet via gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>> wrote:

                              Hi Paul,



                              In the context of thin data, in view of the opposition of some to allow unauthenticated access to all the thin data, the principle of proportionality serves as an over-arching principle at this particular phase in our work in order to protect data from abuse while not restricting access.

                              Thin data must be proportionate to the query, be useful for that particular query. All and any other thin data foreign to this query should not be shared. This principle potentially avoids having to resort to 'legitimate purposes' which cannot be verified for unauthenticated access.





                              Nathalie



                              On Tuesday, May 30, 2017 2:44 PM, "Gomes, Chuck via gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>> wrote:



                              Because Nathalie was the originator and was unable to speak on the call, I encourage her to describe the nature of the issue on this thread.



                              Chuck



                              From: gnso-rds-pdp-wg-bounces at icann. org<mailto:gnso-rds-pdp-wg-bounces at icann.org> [mailto:gnso-rds-pdp-wg- bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org>] On Behalf Of Paul Keating
                              Sent: Tuesday, May 30, 2017 2:17 PM
                              To: Lisa Phifer <lisa at corecom.com<mailto:lisa at corecom.com>>; RDS PDP WG <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>
                              Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access



                              Im sorry to have missed the call but had a client engagement.



                              Can someone briefly describe the nature of the issue?



                              Thanks

                              Paul



                              From: <gnso-rds-pdp-wg-bounces@ icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org>> on behalf of Lisa Phifer <lisa at corecom.com<mailto:lisa at corecom.com>>
                              Date: Tuesday, May 30, 2017 at 7:52 PM
                              To: RDS PDP WG <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>
                              Subject: [gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access



                                 All, per today's call action item:

                                 Action Item: Nathalie Coupet and any other WG members who wish to do so to propose to the WG list a new principle on proportionality for "thin data." All WG members to comment on that proposed principle in advance of next call.

                                 we are starting a new thread here which anyone may reply to if they wish to propose (or respond to) a new principle on proportionality for "thin data" access.

                                 Best, Lisa

                                 ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org> https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg<https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>

                              ______________________________ _________________
                              gnso-rds-pdp-wg mailing list
                              gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
                              https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg<https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>



                              ______________________________ _________________
                              gnso-rds-pdp-wg mailing list
                              gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
                              https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg<https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>


                           ______________________________ _________________
                           gnso-rds-pdp-wg mailing list
                           gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
                           https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg<https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>






                        _______________________________________________
                        gnso-rds-pdp-wg mailing list
                        gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
                        https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg




                     --

                     _________________________________
                     Note to self: Pillage BEFORE burning.


                     _______________________________________________
                     gnso-rds-pdp-wg mailing list
                     gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
                     https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

                     _______________________________________________
                     gnso-rds-pdp-wg mailing list
                     gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
                     https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg



                  _______________________________________________
                  gnso-rds-pdp-wg mailing list
                  gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
                  https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg






               --
               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<tel:+49%206894%209396901>
               Fax.: +49 (0) 6894 - 9396 851<tel:+49%206894%209396851>
               Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

               Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
               www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

               Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
               www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
               www.twitter.com/key_systems<http://www.twitter.com/key_systems>

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

               Member of the KEYDRIVE GROUP
               www.keydrive.lu<http://www.keydrive.lu>

               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<tel:+49%206894%209396901>
               Fax.: +49 (0) 6894 - 9396 851<tel:+49%206894%209396851>
               Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

               Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
               www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

               Follow us on Twitter or join our fan community on Facebook and stay updated:
               www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
               www.twitter.com/key_systems<http://www.twitter.com/key_systems>

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

               Member of the KEYDRIVE GROUP
               www.keydrive.lu<http://www.keydrive.lu>

               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.




               _______________________________________________
               gnso-rds-pdp-wg mailing list
               gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
               https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg






         --
         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<tel:+49%206894%209396901>
         Fax.: +49 (0) 6894 - 9396 851<tel:+49%206894%209396851>
         Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

         Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
         www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

         Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
         www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
         www.twitter.com/key_systems<http://www.twitter.com/key_systems>

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

         Member of the KEYDRIVE GROUP
         www.keydrive.lu<http://www.keydrive.lu>

         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<tel:+49%206894%209396901>
         Fax.: +49 (0) 6894 - 9396 851<tel:+49%206894%209396851>
         Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

         Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>
         www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

         Follow us on Twitter or join our fan community on Facebook and stay updated:
         www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>
         www.twitter.com/key_systems<http://www.twitter.com/key_systems>

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

         Member of the KEYDRIVE GROUP
         www.keydrive.lu<http://www.keydrive.lu>

         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.





         _______________________________________________
         gnso-rds-pdp-wg mailing list
         gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
         https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg



      _______________________________________________
      gnso-rds-pdp-wg mailing list
      gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
      https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

   --

   jonathan matkowsky, vp - ip & head of global brand threat mitigation






   _______________________________________________
   gnso-rds-pdp-wg mailing list
   gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
   https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170531/c6c51060/attachment-0001.html>


More information about the gnso-rds-pdp-wg mailing list