[gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from Next-Generation RDS PDP Working Group Call - 17 May 2017
Paul Keating
Paul at law.es
Thu May 18 09:42:43 UTC 2017
Hi Volker,
First, the person listed in the WHOIS is in fact the ³title² owner. This is
specified in the relevant ICANN rules and this is the presumption used by
all judicial authorities. There may be a ³beneficial Owner² but that
ownership remains to be proven by appropriate evidence.
In the case of privacy, the privacy company is clearly acting as a disclosed
agent which means the entry in the WHOIS is public notice that there is a
beneficial owner who is not listed. However, the title is actually held by
the privacy company. (Note: this is why privacy companies must be separate
legal entities form registrars otherwise the registrar would be
contracting with itself which is legally impossible).
This of course means that the listed title owner (the one in the WHOIS) may
or may not be the beneficial owner. However, that is an issue between the
party listed in the WHOIS as registrant and the party claiming to in fact be
the beneficial owner.
No WHOIS service can ³correct² for the above situation. None of this,
however, impacts harvesting or presents a case against third parties
assembling a complete whois database containing both current and historical
data relative to domain name ownership.
I hope this helps.
Paul
From: Volker Greimann <vgreimann at key-systems.net>
Date: Thursday, May 18, 2017 at 10:57 AM
To: Chris Pelling <chris at netearth.net>, Paul Keating <paul at law.es>
Cc: Greg Shatan <gregshatanipc at gmail.com>, gnso-rds-pdp-wg
<gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from
Next-Generation RDS PDP Working Group Call - 17 May 2017
>
>
>
> Ultimately, not even the data _we_have in our database is always correct.
> Domains are sold all the time without the acquirer bothering to update the
> whois records. Or people register domain names for the companies they work for
> in their own name as they just do not know any better. I could go on and on.
>
>
>
> Ultimately, the person in the whois may not be the legal title holder for any
> number of cases. We usually treat him as such, but as the whois is a private
> not a public (as in government sponsored) register, it carries no legally
> authoritative (sorry for using that word here, but it fits in this case) power
> like a trade register or a land register does.
>
>
> Best,
>
>
> Volker
>
>
>
> Am 17.05.2017 um 19:02 schrieb Chris Pelling:
>
>
>>
>>
>> Paul,
>>
>>
>>
>>
>> I totally disagree with you with regards "whats the problem with harvesting"
>> - just the other day as an example we ended up spending an hour telling a
>> registrant that information held by domaintools is not correct - just because
>> they say it is. Even providing a whois from the registry to the registrant
>> was not proof enough.
>>
>>
>>
>>
>> There is no point debating that though as we will simply disagree.
>>
>>
>>
>>
>> Kind regards,
>>
>> Chris
>>
>>
>>
>>
>> From: "Paul Keating" <Paul at law.es> <mailto:Paul at law.es>
>> To: "Greg Shatan" <gregshatanipc at gmail.com> <mailto:gregshatanipc at gmail.com>
>> , "Volker Greimann" <vgreimann at key-systems.net>
>> <mailto:vgreimann at key-systems.net>
>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
>> <mailto:gnso-rds-pdp-wg at icann.org>
>> Sent: Wednesday, 17 May, 2017 17:13:55
>> Subject: Re: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from
>> Next-Generation RDS PDP Working Group Call - 17 May 2017
>>
>>
>>
>>
>> What is the problem with harvesting?
>>
>>
>> This is public data. There is no Intellectual Property right in the data
>> itself.
>>
>>
>> Asking for ME.
>>
>>
>> Paul
>>
>>
>> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Greg Shatan
>> <gregshatanipc at gmail.com>
>> Date: Wednesday, May 17, 2017 at 6:02 PM
>> To: Volker Greimann <vgreimann at key-systems.net>
>> Cc: RDS PDP WG <gnso-rds-pdp-wg at icann.org>
>> Subject: Re: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from
>> Next-Generation RDS PDP Working Group Call - 17 May 2017
>>
>>
>>
>>>
>>>
>>> Why do we want to prevent harvesting? Asking for a friend.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Greg Shatan
>>> C: 917-816-6428
>>> S: gsshatan
>>> gregshatanipc at gmail.com <mailto:gregshatanipc at gmail.com>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 17, 2017 at 11:58 AM, Volker Greimann
>>> <vgreimann at key-systems.net> wrote:
>>>
>>>>
>>>>
>>>>
>>>> I can see dozens of legitimate reasons for restricting access that are not
>>>> related to the efficiencies of the data retrieval system, first of which is
>>>> harvesting prevention.
>>>>
>>>>
>>>>
>>>> Volker
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 17.05.2017 um 17:55 schrieb Paul Keating:
>>>>
>>>>
>>>>>
>>>>> ³There must be no RDS policies that prevent RDS operators from applying
>>>>> operational controls such as rate limiting and CAPTCHA, provided that they
>>>>> do not unreasonably restrict legitimate access.³,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Caveat. The rate controls must be related to controlling the
>>>>> efficiiciencies of the underlying data retrieval system and not for o
>>>>> there purposes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> PRK
>>>>>
>>>>> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Amr Elsadr
>>>>> <amr.elsadr at icann.org>
>>>>> Date: Wednesday, May 17, 2017 at 9:48 AM
>>>>> To: "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
>>>>> Subject: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from
>>>>> Next-Generation RDS PDP Working Group Call - 17 May 2017
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear Working Group Members,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please find below the action items and notes from today¹s Working Group
>>>>>> call.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Amr
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> These high-level notes are designed to help PDP WG members navigate
>>>>>> through the content of the call and are not meant as a substitute for the
>>>>>> transcript and/or recording. The MP3, transcript, and chat are provided
>>>>>> separately and are posted on the wiki here:
>>>>>> https://community.icann.org/x/HMPRAw
>>>>>> <https://community.icann.org/x/HMPRAw>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Action Items:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1. Newcomers to RSVP to Newcomer Tutorial invitation if you plan to
>>>>>> attend
>>>>>>
>>>>>> 2. Staff to launch poll the test revised item 2) in statement of purpose
>>>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDel
>>>>>> iberation-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838
>>>>>> 376&api=v2> and revised 2 May agreement:
>>>>>>
>>>>>> a. The test revised item 2) in statement of purpose
>>>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDel
>>>>>> iberation-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838
>>>>>> 376&api=v2> : "2) A purpose of RDS is to facilitate dissemination of gTLD
>>>>>> registration data of record, such as domain names and their domain
>>>>>> contacts and name servers, in accordance with applicable policy.²
>>>>>>
>>>>>> b. Revised 2 May agreement: "gTLD registration "thin data" must be
>>>>>> accessible without requestor identification, authentication, or stated
>>>>>> purpose"
>>>>>>
>>>>>> WG members to participate in poll by COB Saturday 20 May.
>>>>>>
>>>>>> 3. Rod Rasmussen and Vaibhav Aggarwal to work together to define what
>>>>>> "unreasonably restrict legitimate access" means in the context of this
>>>>>> statement ³There must be no RDS policies that prevent RDS operators from
>>>>>> applying operational controls such as rate limiting and CAPTCHA, provided
>>>>>> that they do not unreasonably restrict legitimate access.³, and propose
>>>>>> that definition to WG mailing list, preferably before next week's WG call
>>>>>>
>>>>>>
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1) Roll Call/SOI Updates
>>>>>>
>>>>>> * Attendance will be taken from AC
>>>>>> * Please remember to state your name before speaking and remember to mute
>>>>>> your microphones when not speaking
>>>>>> * SOI updates: none
>>>>>>
>>>>>> 2) Brief updates
>>>>>> a) Newcomer tutorial plans:
>>>>>>
>>>>>> * Tuesday 23 May, immediately following WG Call
>>>>>> * Recording to be available for on-demand replay
>>>>>>
>>>>>> Action Item: Newcomers to RSVP to Newcomer Tutorial invitation if you
>>>>>> plan to attend
>>>>>>
>>>>>> b) ICANN59 meeting plans:
>>>>>>
>>>>>> * Monday 26 June Cross-Community Session on RDS
>>>>>> * Tuesday 27 June Face-to-Face RDS PDP WG Session
>>>>>>
>>>>>> 3) Review proposed-final definition(s) to replace "authoritative" in
>>>>>> Statement of Purpose, Item 2):
>>>>>>
>>>>>> *
>>>>>> https://community.icann.org/download/attachments/64078620/DataOfRecord-Pr
>>>>>> oposal.pdf
>>>>>> * Recommendation on how to proceed with replacement term for
>>>>>> "authoritative"
>>>>>> * Starting with poll results from 28 March for Statement of Purpose item
>>>>>> 2) - substitute term "Data of Record" so that item will read:
>>>>>> * "2) A purpose of RDS is to facilitate dissemination of gTLD
>>>>>> registration data of record, such as domain names and their domain
>>>>>> contacts and name servers, in accordance with applicable policy.²
>>>>>> * Definition: "the data set at a given time relevant to a given
>>>>>> registration object that expresses the data provided in the then-current
>>>>>> registration for that object.²
>>>>>> * Can still later consider "source of record" but does not appear needed
>>>>>> to convey intent of this item in the statement of purpose
>>>>>>
>>>>>> Proposed WG Agreement (to test with poll): "2) A purpose of RDS is to
>>>>>> facilitate dissemination of gTLD registration data of record, such as
>>>>>> domain names and their domain contacts and name servers, in accordance
>>>>>> with applicable policy.² (including footnoted definition above)
>>>>>>
>>>>>> 4) Continue deliberation on the charter question 5: What steps should be
>>>>>> taken to control "thin data" access?
>>>>>>
>>>>>> * See handout
>>>>>> https://community.icann.org/download/attachments/64078620/Charter%20Quest
>>>>>> ion%205%20-%20Handout%20-%20For17MayCall%20v2.pdf
>>>>>> * Full results available at
>>>>>> https://community.icann.org/download/attachments/64078620/SummaryResults-
>>>>>> Poll-from-9MayCall.pdf
>>>>>>
>>>>>> a) Is "thin data" access authentication required or allowed?
>>>>>>
>>>>>> * Proposed answer: Based on Poll Question 2) Option e)
>>>>>> * "Thin data elements must be accessible without requestor
>>>>>> authentication."
>>>>>> * With 33 responses, option e) had greatest support and least opposition
>>>>>> - but not rough consensus
>>>>>> * Does "inquirers identifying themselves" or "authentication" imply a
>>>>>> person rather than a machine making the request?
>>>>>> * First proposed change "gTLD registration "thin data" should be
>>>>>> accessible without inquirer identification or stating purpose".
>>>>>> * Consider combining option e) with this agreement, and using "requestor"
>>>>>> instead of "inquirer" for consistency
>>>>>> * Revised/combined proposed change "gTLD registration "thin data" must be
>>>>>> accessible without requestor identification, authentication, or stated
>>>>>> purpose".
>>>>>>
>>>>>> Proposed WG Agreement (to test with poll): "gTLD registration "thin data"
>>>>>> must be accessible without requestor identification, authentication, or
>>>>>> stated purpose".
>>>>>>
>>>>>> b) Is "thin data" access anonymity required or allowed?
>>>>>>
>>>>>> * Proposed answer: Based on Poll Question 2) Comment 9:
>>>>>> * "Access to thin registration data must be provided to anonymous
>>>>>> requestors."
>>>>>> * Does anyone think we must refer to anonymity or is proposed agreement
>>>>>> in a) sufficient?
>>>>>> * Introduces a new term that may be problematic.
>>>>>> * Why do we need to define anonymous now? Thick data for LEA we may need
>>>>>> to define anonymous and untraceable and a whole slew of things but we are
>>>>>> only on thin data now, right?
>>>>>> * The current proposal (under a above) says what the requestor does _not_
>>>>>> have to give, rather than trying to create an attribute of the requestor
>>>>>>
>>>>>> c) Do we need to define "authentication"?
>>>>>>
>>>>>> * We might need to define it later (since we say that there is no
>>>>>> authentification required for thin data) - may need to define it for
>>>>>> thick data
>>>>>> * Is "according to policy" implicit in WG agreements? We haven't yet
>>>>>> agreed on specific "thin data" elements yet
>>>>>>
>>>>>> Action Item: Staff to launch poll the test revised item 2) in statement
>>>>>> of purpose and revised 2 May agreement (the two Proposed WG Agreements
>>>>>> above). WG members to participate in poll by COB Saturday 20 May.
>>>>>>
>>>>>> d) Should policies allow or prevent application of operational controls?
>>>>>>
>>>>>> * Rough consensus WG Agreement (75%) on Poll Question 3):
>>>>>> * "There must be no RDS policies that prevent RDS operators from applying
>>>>>> operational controls such as rate limiting and CAPTCHA, provided that
>>>>>> they do not unreasonably restrict legitimate access."
>>>>>> * Need to define specific policy for "reasonable" and "legitimate" during
>>>>>> Phase 2 of this PDP?
>>>>>> * Is there a need for an explicit statement like this? If the information
>>>>>> is public, is it necessary to limit to prevent scraping? Or is rate
>>>>>> limiting being used to limit legitimate access - can't ignore this
>>>>>> gaming/artificial limit possibility.
>>>>>> * Note 2013 RAA 3.3.5 states "Registrar shall permit use of data it
>>>>>> provides in response to queries for any lawful purposes except to...(b)
>>>>>> enable high volume, automated, electronic processes that send queries or
>>>>>> data to the systems of any Registry Operator or ICANN-Accredited
>>>>>> registrar, except as reasonably necessary to register domain names or
>>>>>> modify existing registrations."
>>>>>> * Perhaps rather than saying something about rate-limiting per se, we
>>>>>> need an SLA about the level of access that must be supported.
>>>>>> * Remaining silent on this point may lead to policies that interfere with
>>>>>> use of operational controls - but using "unreasonably restrict legitimate
>>>>>> access" may leap this too open ended
>>>>>> * Agreed to put this rough consensus point on hold, pending definition of
>>>>>> what "unreasonably restrict legitimate access" means
>>>>>>
>>>>>> Action Item: Rod Rasmussen and Vaibhav Aggarwal to work together to
>>>>>> define what "unreasonably restrict legitimate access" means in the
>>>>>> context of this statement and propose that definition to WG mailing list,
>>>>>> preferrably before next week's WG call.
>>>>>>
>>>>>> e) Review all of charter question 5 sub-questions with goal to complete
>>>>>> first pass deliberation on "thin data" access in May
>>>>>>
>>>>>> * DEFERRED TO 23 MAY WG MEETING
>>>>>>
>>>>>> 5) Confirm action items and proposed decision points
>>>>>>
>>>>>> * Proposed WG Agreement (to test with poll): "2) A purpose of RDS is to
>>>>>> facilitate dissemination of gTLD registration data of record, such as
>>>>>> domain names and their domain contacts and name servers, in accordance
>>>>>> with applicable policy.² (including footnoted definition above)
>>>>>> * Proposed WG Agreement (to test with poll): "gTLD registration "thin
>>>>>> data" must be accessible without requestor identification,
>>>>>> authentication, or stated purpose".
>>>>>> * Action Item: Newcomers to RSVP to Newcomer Tutorial invitation if you
>>>>>> plan to attend
>>>>>> * Action Item: Staff to launch poll the test revised item 2) in statement
>>>>>> of purpose and revised 2 May agreement (the two Proposed WG Agreements
>>>>>> above). WG members to participate in poll by COB Saturday 20 May.
>>>>>> * Action Item: Rod Rasmussen and Vaibhav Aggarwal to work together to
>>>>>> define what "unreasonably restrict legitimate access" means in the
>>>>>> context of this statement and propose that definition to WG mailing list,
>>>>>> preferably before next week's WG call.
>>>>>>
>>>>>> 6) Confirm next meeting date: 23 May 2017 at 16:00 UTC
>>>>>>
>>>>>>
>>>>>>
>>>>>> Meeting Materials
>>>>>>
>>>>>> * Data of Record Proposal
>>>>>> <https://community.icann.org/download/attachments/64078620/DataOfRecord-P
>>>>>> roposal.pdf?version=1&modificationDate=1494989338000&api=v2>
>>>>>> * Charter Question 5 - Handout - For17MayCall.pdf
>>>>>> <https://community.icann.org/download/attachments/64078620/Charter%20Ques
>>>>>> tion%205%20-%20Handout%20-%20For17MayCall%20v2.pdf?version=1&modification
>>>>>> Date=1494961615000&api=v2>
>>>>>> * KeyConceptsDeliberation-WorkingDraft-9May2017.pdf
>>>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDel
>>>>>> iberation-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838
>>>>>> 376&api=v2> and doc
>>>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDel
>>>>>> iberation-WorkingDraft-9May2017.docx?version=1&modificationDate=149437285
>>>>>> 3897&api=v2>
>>>>>>
>>>>>> * 9 May Call Poll Results -
>>>>>>> * PDF of Poll Questions: Poll-from-9MayCall.pdf
>>>>>>> <https://community.icann.org/download/attachments/64078610/Poll-from-9Ma
>>>>>>> yCall.pdf?version=1&modificationDate=1494374689000&api=v2>
>>>>>>> * SurveyMonkey Summary Poll Results:
>>>>>>> SummaryResults-Poll-from-9MayCall.pdf
>>>>>>> <https://community.icann.org/download/attachments/64078620/SummaryResult
>>>>>>> s-Poll-from-9MayCall.pdf?version=1&modificationDate=1494787660000&api=v2
>>>>>>> >
>>>>>>> * SurveyMonkey Raw Data Poll Results:
>>>>>>> RawDataResults-Poll-from-9MayCall.zip
>>>>>>> <https://community.icann.org/download/attachments/64078620/RawDataResult
>>>>>>> s-Poll-from-9MayCall.zip?version=1&modificationDate=1494787676000&api=v2
>>>>>>> > and XLS
>>>>>>> <https://community.icann.org/download/attachments/64078620/RawDataResult
>>>>>>> s-Poll-from-9MayCall.xls?version=1&modificationDate=1494787693000&api=v2
>>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ gnso-rds-pdp-wg mailing
>>>>>> list gnso-rds-pdp-wg at icann.org
>>>>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> gnso-rds-pdp-wg mailing list
>>>>> gnso-rds-pdp-wg at icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pd
>>>>> p-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
>>>>
>>>> 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
>>>>
>>>> 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
>>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>>
>>>
>>>
>>>
>>> _______________________________________________ gnso-rds-pdp-wg mailing
>>> list gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>
>>
>>
>
>
> --
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Volker A. Greimann
> - Rechtsabteilung -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: 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
> Fax.: +49 (0) 6894 - 9396 851
> Email: 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170518/3c60c407/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list