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

Michael Peddemors michael at linuxmagic.com
Thu Jun 1 16:52:59 UTC 2017


To facilitate, Chuck can you summarize those conclusions, point form, it 
might keep the conversation on track, as their is some opinion as well 
as conclusions in there.. Best a 3rd party re-iterate those, so as to 
keep it clear..

On 17-05-31 08:07 AM, 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] *On Behalf Of *jonathan matkowsky
> *Sent:* Wednesday, May 31, 2017 10:52 AM
> *To:* Dotzero <dotzero at gmail.com>; Volker Greimann
> <vgreimann at key-systems.net>
> *Cc:* RDS PDP WG <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****Legit**Script*: 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.


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