[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
jonathan matkowsky
jonathan.matkowsky at riskiq.net
Wed May 31 15:37:06 UTC 2017
Good point -- DNS records may be cached, and it is important to query the
authoritative nameservers from the whois thin data.
On Wed, 31 May 2017 at 18:11 Michael Peddemors <michael at linuxmagic.com>
wrote:
> Agreed.. outside of the discussion ...
> However, for the record, there is a difference in the information which
> is available from the SOA record, which is why our engineers use whois
> information quite extensively. DNS records may be cached, and it is
> important to query the nameservers listed in the whois thin data.
>
> And regarding the thread on spam auditors using the date of
> registration, as part of their threat assessment. We should not argue
> on the validity of his/her methods, that is also outside the scope of
> the discussion. It is enough to show that there are use cases for the
> ability to access that data.
>
> We do it all the time, and often with automated tools as part of our
> threat assessment tool kits.
>
> So we have valid cases for, can anyone show valid cases where that data
> should not be available, and so far the only real cases shown in these
> discussions are issues regarding privacy laws, which should be hashed
> out of course, but haven't seen a case yet where a simple declaration
> that if you wish to operate a domain, you accept that this is how your
> data will be used (eg a privacy policy) and a proper privacy policy
> should alleviate concerns about regarding regulations.
>
> Most privacy laws are simply designed to ensure that the users whose
> data it is, understand the implications, and the data will not be used
> for other purposes. If a 3rd party decides to collect/use that data, in
> a manner without the holder of that information agreeing to it, then it
> is the 3rd party that should be responsible, not ICANN or the registrars.
>
> You 'might' want to create a new thread around what the privacy policy
> might look like, but that should not affect the conversation about
> 'what' thin data is available, and how it can be accessed.
>
> There are a myriad amount of reasons (a lot already pointed out) on why
> that information needs to be freely accessible to all parties without
> prejudice..
>
> On 17-05-31 07:51 AM, jonathan matkowsky 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
> > <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
> >>>>>
> >>>>>
> >>>>> *FollowLegitScript*: 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
> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> >
>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170531/74975cd4/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list