[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
Greg Shatan
gregshatanipc at gmail.com
Wed May 31 15:15:17 UTC 2017
Briefly --
Thank you to Andrew Sullivan (in particular) for reminding us that an
essential purpose of this data is the operability of the Internet.
If court decisions seem to (or can be used to) interfere with that
operability, we need to look for technical, legal and/or policy methods to
overcome that interference. Unquestioning submission to the most
oppressive interpretation of a law or a court decision is bad
law/business/policy.
We're not trying to design a privacy-prioritized RDS (much less DNS, much
less Internet). We're trying to design (or protect) an
operabiliity-prioritized Internet and one that prioritizes security,
stability, resiliency and trust. Some privacy concepts are consistent with
those goals, others are anathema to them. Following applicable laws is
also a basic concept, but over-adherence to the law makes about as much
sense as avoiding skin cancer by hiding under your bedcovers.
I think an attempt to import the principle of proportionality and apply it
to thin data falls into the anathema column. Or as Jonathan said more
simply "The principle of proportionality doesn't apply to thin data."
Greg
On Wed, May 31, 2017 at 10:51 AM, jonathan matkowsky <
jonathan.matkowsky at riskiq.net> wrote:
> 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> 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> 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>
>>> 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> 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 :
>>> SOA ns1.google.com. dns-admin.google.com. 157458041 900 900 1800 60
>>> netearthone.com
>>> SOA ns1.netearth.net. root.netearthone.com. 2016090201
>>> <(201)%20609-0201> 14400 3600 1209600 86400
>>> law.es
>>> SOA ns1.eurodns.com. hostmaster.eurodns.com. 2016061402
>>> <(201)%20606-1402> 43200 7200 1209600 86400
>>> riskiq.net
>>> SOA ns-1754.awsdns-27.co.uk. 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>
>>> *To: *"nathalie coupet" <nathaliecoupet at yahoo.com>
>>> *Cc: *"gnso-rds-pdp-wg" <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> 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> 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> 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> 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> 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
>>>> <gnso-rds-pdp-wg-bounces at icann.org> [mailto:gnso-rds-pdp-wg-
>>>> bounces at icann.org <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>; RDS PDP WG <
>>>> 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
>>>> <gnso-rds-pdp-wg-bounces at icann.org>> on behalf of Lisa Phifer <
>>>> lisa at corecom.com>
>>>> *Date: *Tuesday, May 30, 2017 at 7:52 PM
>>>> *To: *RDS PDP WG <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 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
>>>> 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
>>>> 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
>>>> 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
>>>> 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
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>
>>>
>>>
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing listgnso-rds-pdp-wg at icann.orghttps://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 <+49%206894%209396901>
>>> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
>>> Email: vgreimann at key-systems.net
>>>
>>> Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
>>>
>>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
>>>
>>> Geschäftsführer: Alexander Siffrin
>>> Handelsregister Nr.: HR B 18835 - Saarbruecken
>>> Umsatzsteuer ID.: DE211006534
>>>
>>> Member of the KEYDRIVE GROUPwww.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 <+49%206894%209396901>
>>> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
>>> Email: vgreimann at key-systems.net
>>>
>>> Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
>>>
>>> Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
>>>
>>> CEO: Alexander Siffrin
>>> Registration No.: HR B 18835 - Saarbruecken
>>> V.A.T. ID.: DE211006534
>>>
>>> Member of the KEYDRIVE GROUPwww.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
>>> 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 <+49%206894%209396901>
>>> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
>>> Email: vgreimann at key-systems.net
>>>
>>> Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
>>>
>>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
>>>
>>> Geschäftsführer: Alexander Siffrin
>>> Handelsregister Nr.: HR B 18835 - Saarbruecken
>>> Umsatzsteuer ID.: DE211006534
>>>
>>> Member of the KEYDRIVE GROUPwww.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 <+49%206894%209396901>
>>> Fax.: +49 (0) 6894 - 9396 851 <+49%206894%209396851>
>>> Email: vgreimann at key-systems.net
>>>
>>> Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
>>>
>>> Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
>>>
>>> CEO: Alexander Siffrin
>>> Registration No.: HR B 18835 - Saarbruecken
>>> V.A.T. ID.: DE211006534
>>>
>>> Member of the KEYDRIVE GROUPwww.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
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> 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
> 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/99638d3b/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list