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

Volker Greimann vgreimann at key-systems.net
Wed May 31 16:48:11 UTC 2017


I never claimed the latter, just that it is near impossible to know for 
sure when doing business over the internet.

What happens to the records when a registrar goes out of business? 
Depends on their local legal obligations to keep records, plus the 
Registrar data escrow, which of course only covers whois details. Users 
of privacy services not affiliated with a registrar are basically 
screwed unless the departure from the business includes some form of a 
clean handover to the successor-registrar. Not an ideal situation, and 
one the PPSAI-WG tried to solve, or is still trying to solve in the 
implementation team.

But essentially, registry/registrar data escrow is probably going to 
stay in some form as it has a clearly defined purpose and very specific 
release conditions, but even there there may be some changes required, 
such as a change of escrow providers for European data subjects or a 
tweak of the release conditions. And yes, even this very limited escrow 
may possibly require changes in how the permission of the data subjects 
to do so is obtained and maintained.

Best,

Volker


Am 31.05.2017 um 18:03 schrieb allison nixon:
> Domain hijacking is and has been a continuing issue. When a hacker 
> logs in and changes all the records, does the registrar keep enough 
> logs to settle the dispute in a sane manner? When a registrar goes out 
> of business, do records of ownership exist, or does their entire 
> customer base descend into chaos? If we're going to be so gung-ho 
> about not keeping logs and not collecting data, then I wonder how 
> normal business is supposed to continue when companies have no idea 
> who their customers are and are enthusiastic about not finding out.
>
> On Wed, May 31, 2017 at 11:57 AM, Volker Greimann 
> <vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>> wrote:
>
>
>
>     Am 31.05.2017 um 17:43 schrieb allison nixon:
>>
>>     Domains are generally not as valuable, but there is another
>>     debate here- it is not purely an issue of privacy vs security. It
>>     is an issue of privacy vs the concept of property ownership. If
>>     your identity is not associated with your domain in any
>>     verifiable way, do you have a valid claim to the property? If it
>>     is all up to the registrar saying "trust me", what assurances
>>     exist against a hack, hijack, ownership dispute, or malicious
>>     registrar?
>     The same assurances as exist in any other transaction: You can
>     always sue the other party for breach of contract.
>
>     But you are right, there is no reliable surefire verifiable way to
>     associate the registrant of a domain name with his legal rights to
>     that name. As registrar, we have to trust - to a certain extent -
>     that the information provided by the registrant about himself is
>     correct.
>
>     Whenever he uses the right access credentials to his account, we
>     have to trust he is the person who owns that account and is
>     authorized to make modifications to the domains. When he opens an
>     account, we have to trust he is who he says he is. When he
>     registers a domain for himself or a third party, we have to trust
>     his identity or right to request that registration.
>
>     When he uses a payment method, we have to trust that the security
>     of that payment method has not been breached / that payment method
>     is used by the person entitled to use it.
>
>     Unless you require people walking into the registrars' officies
>     for every transaction, this is a fact of life.
>
>     Best,
>     Volker
>
>
>
>>
>>     Broader issues exist than only privacy. The overemphasis on
>>     privacy by this group is beyond absurd
>>
>>     On Wed, May 31, 2017 at 11:20 AM, Chris Pelling
>>     <chris at netearth.net <mailto:chris at netearth.net>> wrote:
>>
>>         John,
>>
>>         I refer you to my original email, the question was how could
>>         it be abused, I gave an answer, I did not expect hours or
>>         reading on that answer - but it was a fair answer, maybe an
>>         edge case, but still a correct answer.
>>
>>         I have not said anything about privacy, all I said was this
>>         can gain you an email address by working the system.
>>
>>         Similar someone (I think you Paul) said there is no
>>         correlation between IP address and getting personal data
>>         (something along that line) - thats wrong too, as the RIR's
>>         hold records, LIRs populate that date held by RIRs and
>>         depending on how and when this was updated, could provide
>>         personal information (more likely company / corporate info)
>>         because in the old days (talking 20 years ago now) records
>>         and even 30 years ago for ARIN personal information *could*
>>         have been used.
>>
>>         For those who do not know how to lookup an IP:  whois <ip>
>>         ie. jwhois 80.251.17.0
>>
>>         For those who do not know the accronyms :
>>
>>         RIR:
>>         Regional Internet Registries (*RIRs*) are nonprofit
>>         corporations that administer and register Internet Protocol
>>         (IP) address space and Autonomous System (AS) numbers within
>>         a defined region. *RIRs*also work together on joint projects.
>>
>>         LIR:
>>         A *local Internet registry*(*LIR*) is an organization that
>>         has been allocated a block of IP addresses by a *regional
>>         Internet registry*(RIR), and that assigns most parts of this
>>         block to its own customers.
>>
>>         ARIN:
>>         The American Registry for Internet Numbers is the Regional
>>         Internet Registry for Canada, the United States, and many
>>         Caribbean and North Atlantic islands.  (first RIR if memory
>>         serves)
>>
>>         Kind regards,
>>
>>         Chris
>>
>>         ------------------------------------------------------------------------
>>         *From: *"John Bambenek" <jcb at bambenekconsulting.com
>>         <mailto:jcb at bambenekconsulting.com>>
>>         *To: *"Chris Pelling" <chris at netearth.net
>>         <mailto:chris at netearth.net>>
>>         *Cc: *"Paul Keating" <paul at law.es <mailto:paul at law.es>>,
>>         "gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org
>>         <mailto:gnso-rds-pdp-wg at icann.org>>
>>         *Sent: *Wednesday, 31 May, 2017 15:50:25
>>         *Subject: *Re: [gnso-rds-pdp-wg] Principle on Proportionality
>>         for "Thin Data"access
>>
>>         It is still stored by the provider in a service operated by
>>         the provider and edited with an interface created by the
>>         provider using whatever business logic or validation that is
>>         written by the provider.  Fine, control is not the precise word.
>>
>>         All that being said, if SOA is ok even when editable only by
>>         an interface by the provider then so is all WHOIS data which
>>         is entered by the consumer.  It really is either/or here. 
>>         You can't on one hand say there are no privacy implications
>>         of SOA and then turn around when you have an almost identical
>>         set of facts and cry privacy foul over whois.
>>
>>         j
>>
>>         On 5/31/2017 9:46 AM, Chris Pelling wrote:
>>
>>             John,
>>
>>             You are entirely wrong in your statement : Point in fact,
>>             for consumers, SOA is NOT under control of the consumer.
>>
>>             Yet many of the largest and paid service allow you to
>>             edit just that record as the consumer.
>>
>>             Kind regards,
>>
>>             Chris
>>
>>             ------------------------------------------------------------------------
>>             *From: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
>>             <mailto:gnso-rds-pdp-wg at icann.org>
>>             *To: *"Paul Keating" <paul at law.es> <mailto:paul at law.es>
>>             *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
>>             <mailto:gnso-rds-pdp-wg at icann.org>
>>             *Sent: *Wednesday, 31 May, 2017 15:14:53
>>             *Subject: *Re: [gnso-rds-pdp-wg] Principle
>>             on        Proportionality
>>                for        "Thin        Data"access
>>
>>             Point in fact, for consumers, SOA is NOT under control of
>>             the consumer. I would bet a very rare set of consumers
>>             who own domains actually run their own DNS servers. They
>>             are either using the registrar or their hosting provider.
>>
>>             Sure they put in the data. But that is also true of
>>             whois/rds. No one does this for the consumer. They put in
>>             all their own data. Considering the number of domains
>>             under the control of various registrars that still accept
>>             all 0s for phone number, no one verifies that data either.
>>
>>             This does, however, reinforce that making whois for free
>>             solves almost all of this issue. If consumers have a true
>>             choice that's free and the choices are explained, all of
>>             these privacy issues almost completely are resolved.
>>
>>             J
>>
>>             Sent from my iPhone
>>
>>             On May 31, 2017, at 08:38, Paul Keating <paul at law.es
>>             <mailto:paul at law.es>> wrote:
>>
>>                 +1!
>>
>>                 Sent from my iPad
>>
>>                 On 31 May 2017, at 11:38, Victoria Sheckler
>>                 <vsheckler at riaa.com <mailto:vsheckler at riaa.com>> wrote:
>>
>>                     +1
>>
>>                     *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 *Andrew Sullivan
>>                     *Sent:* Tuesday, May 30, 2017 10:36 PM
>>                     *To:* Chris Pelling <chris at netearth.net
>>                     <mailto:chris at netearth.net>>
>>                     *Cc:* gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org
>>                     <mailto:gnso-rds-pdp-wg at icann.org>>
>>                     *Subject:* Re: [gnso-rds-pdp-wg] Principle on
>>                     Proportionality for "Thin Data"access
>>
>>                     Hi,
>>
>>                     This is a pretty strained example, since the RDS
>>                     is irrelevant here. You can get the SOAs in the
>>                     examples as soon as you know the domain name. 
>>                     You have no need to consult RDS at all.  And the
>>                     SOA is completely under the control of the DNS
>>                     operator, and in the absence of Internet Protocol
>>                     Police you can put whatever you want in there for
>>                     your own zones.  No real dns admin has trusted
>>                     that field for years.
>>
>>                     This repetitious and always fruitless discussion
>>                     of whether anyone can get any data to "abuse" out
>>                     of the thin data seems to miss the point of why
>>                     we started with thin data: it was supposed to be
>>                     easy.  I've yet to hear even one remotely
>>                     plausible issue with respect to any of this data,
>>                     because it's all needed by virtue of creating a
>>                     name space on the Internet. That's what domain
>>                     name registrations do, so if you don't want to
>>                     expose this much data you shouldn't register
>>                     domain names.  Unless someone can come up with a
>>                     single concrete example of something problematic,
>>                     I'd like us to move on to a topic where there's
>>                     some substance to discuss.
>>
>>                     Best regards,
>>
>>                     A
>>
>>                     -- 
>>
>>                     Andrew Sullivan
>>
>>                     Please excuse my clumbsy thums.
>>
>>
>>                     On May 30, 2017, at 17: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
>>                             <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
>>                         <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
>>             <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>
>>
>>
>>
>>
>>     -- 
>>     _________________________________
>>     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
>>     <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>
>
>
>
>
> -- 
> _________________________________
> Note to self: Pillage BEFORE burning.

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

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

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
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

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

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

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
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

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.



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


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