[gnso-rds-pdp-wg] ICANN Meetings/Conversations with Data Protection and Privacy Commissioners
theo geurts
gtheo at xs4all.nl
Thu Sep 28 14:11:25 UTC 2017
Agreed Michael,
I can only imagine some sort of access to a database that contains
anonymised data, yet folks who deal with botnets can obtain valuable
info from that database.
What would those data points be for a botnet?
Thanks,
Theo
On 28-9-2017 15:58, Dotzero wrote:
> Stephanie,
>
> Please correct me if I'm wrong, but I don't believe that any of the
> data elements being discussed as possible candidates for inclusion in
> RDS would be considered "sensitive personal data" as defined under
> GDPR. We aren't asking for political beliefs, sexual orientation,
> trade union membership or any of the other categories specified.
>
> If you had stated "Making personal data public does not, by legal
> definition, change its character as personal data." then we could
> perhaps find agreement and move on to a discussion as to which data
> elements are truly personal data, whether the collection and
> publication is justified based on the purpose/activity and things like
> proportionality.
>
> My sense is that unless we (collectively) work to find areas of common
> understanding, this effort is doomed to failure.
>
> We should be asking ourselves questions like:
>
> If this data/information is not available (publicly/gated), what are
> potential impacts (positive or negative) on the security and stability
> of DNS and the Internet?" What are the impacts to individuals and what
> are the impacts to the ecosystem as a whole? We cannot answer
> questions like proportionality without considering these sorts of
> questions.
>
> I would pose this question to the group: If you knew with some
> certainty that limiting availability of information that allows
> individuals, groups and organizations to mitigate abuse at scale would
> wreak havoc on the stability, security and overall usefulness of the
> Internet, would you advocate the limitations currently being advocated?
>
> At the other end of the spectrum I would pose this question:
> Recognizing privacy concerns (whether legal or ethical), what
> mechanisms might be implemented within the proposed RDS that would
> protect individual privacy of legitimate users but still allow abuse
> mitigation techniques based on DNS information of Internet abuse?
>
> I think this (to some extent) stakes out the 2 extremes and asks how
> to address the key issue(s) presented by proponents of the other extreme.
>
> Let's try thinking outside the box.
>
> Michael Hammer
>
> On Thu, Sep 28, 2017 at 9:36 AM, Stephanie Perrin
> <stephanie.perrin at mail.utoronto.ca
> <mailto:stephanie.perrin at mail.utoronto.ca>> wrote:
>
> Making sensitive data public does not, by legal definition, change
> its character as personal data.
>
> Stephanie P
>
>
> On 2017-09-28 09:34, John Bambenek via gnso-rds-pdp-wg wrote:
>> Public data cannot, by definition, be breached.
>>
>> J
>>
>> --
>> John Bambenek
>>
>> On Sep 28, 2017, at 08:29, theo geurts <gtheo at xs4all.nl
>> <mailto:gtheo at xs4all.nl>> wrote:
>>
>>> Indeed privacy prevents a lot of consumers being exploited.
>>>
>>> Privacy by design usually plays a significant role when setting
>>> up security around databases. Often, less is more, data that is
>>> not present cannot cause a data breach. The GDPR had to set a
>>> whole bunch of rules around data breaches and response times and
>>> accounting. Though given the number of weekly data breaches,
>>> most likely for the best, yet it is still a load of rules to
>>> deal with.
>>>
>>> Theo
>>>
>>> On 28-9-2017 15:19, John Bambenek via gnso-rds-pdp-wg wrote:
>>>> Thankfully there are people who donate their time and talent
>>>> tackling the privacy and security risks that are seeking to
>>>> exploit consumers. ;)
>>>>
>>>> --
>>>> John Bambenek
>>>>
>>>> On Sep 28, 2017, at 03:08, Volker Greimann
>>>> <vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>>
>>>> wrote:
>>>>
>>>>> The role of ICANN to ensure the stability and security of the
>>>>> internet is a technical role, not one of being an internet
>>>>> policeman. That role is already filled by internet policemen.
>>>>>
>>>>> Volker
>>>>>
>>>>>
>>>>> Am 27.09.2017 um 20:05 schrieb Chuck:
>>>>>>
>>>>>> Without at all minimizing ICANN’s role with regard to
>>>>>> security and stability of the Internet because I do believe
>>>>>> that is a critical role, I do want to point out that that
>>>>>> also is a limited role. Here is a copy of the first part of
>>>>>> ICANN’s mission from its Bylaws:
>>>>>>
>>>>>> “Section 1.1. MISSION
>>>>>>
>>>>>> (a) The mission of the Internet Corporation for Assigned
>>>>>> Names and Numbers ("*ICANN*") is to ensure the stable and
>>>>>> secure operation of the Internet's unique identifier systems
>>>>>> as described in this _Section 1.1(a)_ (the "*Mission*").
>>>>>> Specifically, ICANN:
>>>>>>
>>>>>> (i) Coordinates the allocation and assignment of names in the
>>>>>> root zone of the Domain Name System ("*DNS*") and coordinates
>>>>>> the development and implementation of policies concerning the
>>>>>> registration of second-level domain names in generic
>>>>>> top-level domains ("*gTLDs*"). In this role, ICANN's scope is
>>>>>> to coordinate the development and implementation of policies:
>>>>>>
>>>>>> ·For which uniform or coordinated resolution is reasonably
>>>>>> necessary to facilitate the openness, interoperability,
>>>>>> resilience, security and/or stability of the DNS including,
>>>>>> with respect to gTLD registrars and registries, policies in
>>>>>> the areas described in Annex G-1 and Annex G-2; and
>>>>>>
>>>>>> ·That are developed through a bottom-up consensus-based
>>>>>> multistakeholder process and designed to ensure the stable
>>>>>> and secure operation of the Internet's unique names systems.
>>>>>>
>>>>>> The issues, policies, procedures, and principles addressed in
>>>>>> Annex G-1 and Annex G-2 with respect to gTLD registrars and
>>>>>> registries shall be deemed to be within ICANN's Mission.
>>>>>>
>>>>>> . . .”
>>>>>>
>>>>>> Note in (a) and the second bullet under (i) that it says “to
>>>>>> ensure the stable and secure operation of the Internet's
>>>>>> unique identifier systems”. ICANN’s security and stability
>>>>>> role is limited to its responsibilities involving the
>>>>>> ‘Internet's unique identifier systems’. I am pretty sure
>>>>>> everyone understands that but wanted to make sure. For our
>>>>>> purposes in this WG, ICANN has a clear mandate to ensure
>>>>>> security and stability of the generic domain names system.
>>>>>>
>>>>>> 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
>>>>>> *John Bambenek via gnso-rds-pdp-wg
>>>>>> *Sent:* Wednesday, September 27, 2017 9:12 AM
>>>>>> *To:* gnso-rds-pdp-wg at icann.org
>>>>>> <mailto:gnso-rds-pdp-wg at icann.org>
>>>>>> *Subject:* Re: [gnso-rds-pdp-wg] ICANN Meetings/Conversations
>>>>>> with Data Protection and Privacy Commissioners
>>>>>>
>>>>>> Except that the domain name system is not YOUR system, it is
>>>>>> ICANN's who has a very clear mandate for the security and
>>>>>> stability of the internet.
>>>>>>
>>>>>> The purpose is NOT letting registrants get domains and
>>>>>> helping registries get paid. It never has been.
>>>>>>
>>>>>> On 09/27/2017 09:52 AM, Volker Greimann wrote:
>>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> I think we need to dig down even deeper initially.
>>>>>> Instead of RDS, the core of the matter is the need for
>>>>>> the data when defining the purpose for collection.
>>>>>>
>>>>>> This is very easy to answer for registrars: "We need
>>>>>> (certain elements of) the data to be able to properly
>>>>>> provide the business, invoice the customer, collect his
>>>>>> payments, send reminders and notices, protect the rights
>>>>>> of the customers in case of business failure, comply with
>>>>>> legal requirements like record-keeping, etc.". I am
>>>>>> leaving out any contractual requirements, as they do not
>>>>>> matter for the registrars' own purpose. These are
>>>>>> external purposes that the registrar would have to
>>>>>> execute without having an own, direct need for.
>>>>>>
>>>>>> For registries, it gets fuzzier as they do not have a
>>>>>> direct connection to the registrants. From a service
>>>>>> provision perspective, registries have no need for the
>>>>>> data, and no right to it, except maybe for purposes of
>>>>>> eligibility verification.
>>>>>>
>>>>>> When going beyond registries to the general public, there
>>>>>> is no purpose that connects to the provision of the
>>>>>> service to the registrant directly. There also (in most
>>>>>> countries) is no legal requirement to collect and publish
>>>>>> this data. Yet there is still a need for the data, as we
>>>>>> have discussed in great detail.
>>>>>>
>>>>>> So our first question always must be the following:
>>>>>>
>>>>>> "How do we serve the needs of the general public that has
>>>>>> an interest in the ability of obtaining such data without
>>>>>> violating any applicable laws or the rights of the
>>>>>> registrant to the privacy of his data?"
>>>>>>
>>>>>> This has to be the basis of any design decision and any
>>>>>> argument made in this group.
>>>>>>
>>>>>> Arguing that certain laws are unreasonable or unworkable
>>>>>> is a dangerous question as it effectively proposes to
>>>>>> ignore laws that we as a community do not like, at the
>>>>>> risk of contracted parties and to the detriment of the
>>>>>> beneficiaries of such laws. just because there has not
>>>>>> been any enforcement action in the past does not mean we
>>>>>> can ignore the law applicable to the individual
>>>>>> contracted parties. And we are not talking about
>>>>>> jaywalking here, some of these laws have significant
>>>>>> penalties attached to them, as we have also discussed
>>>>>> before.
>>>>>>
>>>>>> I agree with Greg that the ability of contracted parties
>>>>>> to be free to make business decisions cannot be absolute.
>>>>>> It has to be bound on the one side by ICANN policies and
>>>>>> the other side by applicable law. And these two external
>>>>>> pressures should not be in conflict with each other. If
>>>>>> we can achieve that while answering the basic question
>>>>>> above, our work is done. At least for the time being, as
>>>>>> laws may obviously change, but that can be taken into
>>>>>> account as well. Any discussion that seeks to circumvent
>>>>>> this basic question will ultimately lead to the failure
>>>>>> of our work and by extention to the end of whois. The
>>>>>> latter due to the incompatibility of current whois with
>>>>>> applicable law.
>>>>>>
>>>>>> I think with our initial "purpose definition" exercise,
>>>>>> we already went a great way in determining what those
>>>>>> needs are and our current work to discuss data points
>>>>>> goes into that question as well, even though personally I
>>>>>> feel that by defining data points at this point and going
>>>>>> into the sticks in some of the discussions we are wasting
>>>>>> time. The question should never be "Do we need a Facebook
>>>>>> contact in the RDS?" and always be "What contacts are
>>>>>> needed as bare minimum to achieve needs X, Y, Z, ...".
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Volker
>>>>>>
>>>>>> Am 27.09.2017 um 16:00 schrieb Greg Shatan:
>>>>>>
>>>>>> The "data controllers" here do not exist in a
>>>>>> vacuum. While registrars and registries need to be
>>>>>> free to make many types of decisions in their own
>>>>>> business judgment, that cannot be an absolute rule.
>>>>>> This is at odds with the ICANN model, consensus
>>>>>> policy, etc. In this case, the data controllers are
>>>>>> part of a larger ecosystem, and the "needs" go beyond
>>>>>> the individual business needs of each data
>>>>>> controller. (Indeed, the individual data controller
>>>>>> has its own database of information for its business
>>>>>> needs.)
>>>>>>
>>>>>> As I previously noted, we are going back to first
>>>>>> principles -- which is not necessarily a bad thing.
>>>>>> Why does ICANN (and by extension, the Internet) need
>>>>>> WHOIS/RDS? That is the question. Not "why does a
>>>>>> particular [registrar/registry] need WHOIS/RDS?"
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>> On Wed, Sep 27, 2017 at 5:12 AM, Volker Greimann
>>>>>> <vgreimann at key-systems.net
>>>>>> <mailto:vgreimann at key-systems.net>> wrote:
>>>>>>
>>>>>> So when will you start advocating the collection
>>>>>> and publication of WHOIS for internet users?
>>>>>> Because they would be connecting to your network
>>>>>> all the time...
>>>>>>
>>>>>> Volker
>>>>>>
>>>>>> Am 26.09.2017 um 20:48 schrieb John Bambenek via
>>>>>> gnso-rds-pdp-wg:
>>>>>>
>>>>>> "As for privacy proxy solving the problem, it
>>>>>> does not. Over collection is not solved by
>>>>>> providing a proxy in the third party
>>>>>> disclosure mechanism. It is still
>>>>>> over-collection, disproportionate to needs."
>>>>>>
>>>>>> I fundamentally disagree because the purpose
>>>>>> of ICANN is not the mere facilitation of
>>>>>> domain from registry to registrant. The
>>>>>> purpose is the security and stability of the
>>>>>> internet and that means I have a need to
>>>>>> verify who is connecting to my network and
>>>>>> have a means of contacting them. That point
>>>>>> has never been made, to my knowledge, to them.
>>>>>>
>>>>>> The point that removing that ability of me
>>>>>> being able to contact domain owners does far
>>>>>> MORE to REDUCE the privacy of the registrants
>>>>>> than does publishing said information. We
>>>>>> talk often about verification out-of-band for
>>>>>> sensitive communications. How can I do that
>>>>>> without a phone number?
>>>>>>
>>>>>> I will loudly and vigorously argue that the
>>>>>> path advocated will make the problem FAR
>>>>>> worse and not better. Hopefully we don't get
>>>>>> to the point where I have actual data to
>>>>>> prove that.
>>>>>>
>>>>>> On 9/26/2017 1:34 PM, Stephanie Perrin wrote:
>>>>>>
>>>>>> As for privacy proxy solving the problem,
>>>>>> it does not. Over collection is not
>>>>>> solved by providing a proxy in the third
>>>>>> party disclosure mechanism. It is still
>>>>>> over-collection, disproportionate to needs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>> John Bambenek
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> 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>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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
>>>>>> <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>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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
>>>>>> <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>
>>>>>
>>>>> --
>>>>> 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
>>>>> <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
> 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/20170928/69db2a04/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list