[gnso-rds-pdp-wg] Proposed Agreement for Original Registration Date
Paul Keating
Paul at law.es
Tue Oct 10 14:21:10 UTC 2017
Agreed,
Additionally, I doubt that any registry maintains sufficient data to track
prior ³instances of registration². Nor can I see a reason why they would
want to expend the resources to do so.
Paul
From: Volker Greimann <vgreimann at key-systems.net>
Date: Tuesday, October 10, 2017 at 3:48 PM
To: Paul Keating <paul at law.es>, Chuck <consult at cgomes.com>, 'jonathan
matkowsky' <jonathan.matkowsky at riskiq.net>, 'Sara Bockey'
<sbockey at godaddy.com>, <gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original Registration
Date
>
>
>
> Hi Paul,
>
>
>
> I don't disagree. A domain registration RDS entry should list the data
> pertaining to the current registration, not that of previous registrations.
> The differentiation here is between the Creation Date as used in todays RDS
> and the Original Creation data, as proposed by the EWG. The latter would
> pertain to previous registrations of the same string, not the current one and
> therefore would be the "odd man out".
>
>
>
> This additional field might also open the door to a complete history of
> previous registrations, complete with previous registrants of previous domains
> as well as previous registrants of the current domain. I hope we will never go
> there.
>
>
> The Created Date should only refer to the current registry object (domain
> registration), e.g. the time and date the "AddDomain" was processed by the
> registry. Transfers and ownership updates obviously do not influence this
> date, neither would deletions followed by a restore. But deletions followed by
> a new registration would.
>
>
> Volker
>
>
>
> Am 10.10.2017 um 15:36 schrieb Paul Keating:
>
>
>>
>> Volker,
>>
>>
>>
>>
>> You wrote below:
>>
>>
>>
>>
>>
>>
>>>
>>>>
>>>>
>>>> I still think that the only date that should be included is the creation
>>>> date of a domain name as all potential previous registrations of the same
>>>> string refer to a different domain object.
>>>>
>>>>
>>>> A domain that once existed and has been permanently deleted at the registry
>>>> level is not the same as a domain registered when the string became
>>>> available again, and we should not try to conflate both into one object.
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>> Volker
>>>>
>>>
>>
>>
>>
>> The problem I have is that we need to be very careful with terminology. As
>> used today, Creation Date signifies the first date of a domain name¹s CURRENT
>> registration cycle. If a domain expires AND is deleted and THEN newly
>> registered again, this new registration will result in a NEW CREATION DATE.
>> A domain name that ³expires² but is purchased during a drop auction is not
>> deleted and thus the Creation Date will remain the same. This is because the
>> registration merely transfers (since of course domains are intangibles and
>> evidenced only by registration records).
>>
>>
>>
>>
>> Given that this is the case I do not see any need for an "Original
>> Registration Date² unless its purpose is to track whether or not a domain
>> name has been registered, deleted and re-registered.
>>
>>
>>
>>
>> If this is a semiotical issue then I believe that ³Creation Date² is much
>> more accurate as it references the creation of the instance of registration.
>> Original Registration Date would imply that it served a purpose by showing
>> the first date upon which a domain was registered, even if it had expired AND
>> been deleted. I see no purpose in such data but am open to being convinced.
>>
>>
>>
>>
>> Furthermore, I do not believe that registries maintain the data necessary to
>> determine whether or not the domain had ever been registered.
>>
>>
>>
>>
>>
>>
>>
>> Paul
>>
>>
>>
>>
>> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Chuck
>> <consult at cgomes.com>
>> Date: Tuesday, October 10, 2017 at 2:59 PM
>> To: 'jonathan matkowsky' <jonathan.matkowsky at riskiq.net>, 'Sara Bockey'
>> <sbockey at godaddy.com>, 'Volker Greimann' <vgreimann at key-systems.net>,
>> <gnso-rds-pdp-wg at icann.org>
>> Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original Registration
>> Date
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> Jonathan,
>>>
>>>
>>>
>>> What do you mean when you say RDS?
>>>
>>>
>>>
>>> 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: Tuesday, October 10, 2017 2:24 AM
>>> To: Sara Bockey <sbockey at godaddy.com>; Volker Greimann
>>> <vgreimann at key-systems.net>; gnso-rds-pdp-wg at icann.org
>>> Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original Registration
>>> Date
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi. Yes but this is the RDS.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 10, 2017 at 2:09 AM Volker Greimann <vgreimann at key-systems.net>
>>> wrote:
>>>
>>>
>>>>
>>>>
>>>> Hi Jonathan,
>>>>
>>>>
>>>>
>>>> the domain object ID is indeed part of the whois:
>>>>
>>>>
>>>>
>>>> From the Whois of a .org domain -> Registry Domain ID: D104189961-LROR
>>>>
>>>> From the Whois of a .com domain -> Registry Domain ID:
>>>> 4065057_DOMAIN_COM-VRSN
>>>>
>>>> From the Whois of a .Saarland domain -> Registry Domain ID:
>>>> 8932212620_DOMAIN-SAAR
>>>>
>>>>
>>>>
>>>> It is a unique identifier for a registration.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Volker
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 10.10.2017 um 05:18 schrieb jonathan matkowsky:
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Is the Domain Object ID displayed?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 9, 2017 at 3:34 PM Sara Bockey <sbockey at godaddy.com> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree with Volker.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sara
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> sara bockey
>>>>>>
>>>>>> sr. policy manager | GoDaddy
>>>>>>
>>>>>> sbockey at godaddy.com 480-366-3616
>>>>>>
>>>>>>
>>>>>>
>>>>>> skype: sbockey
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This email message and any attachments hereto is intended for use only by
>>>>>> the addressee(s) named herein and may contain confidential information.
>>>>>> If you have received this email in error, please immediately notify the
>>>>>> sender and permanently delete the original and any copy of this message
>>>>>> and its attachments.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Volker Greimann
>>>>>> <vgreimann at key-systems.net>
>>>>>> Date: Monday, October 9, 2017 at 1:13 AM
>>>>>> To: "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original
>>>>>> Registration Date
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I still think that the only date that should be included is the creation
>>>>>> date of a domain name as all potential previous registrations of the same
>>>>>> string refer to a different domain object.
>>>>>>
>>>>>>
>>>>>> A domain that once existed and has been permanently deleted at the
>>>>>> registry level is not the same as a domain registered when the string
>>>>>> became available again, and we should not try to conflate both into one
>>>>>> object.
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>>
>>>>>> Volker
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 02.10.2017 um 05:28 schrieb jonathan matkowsky:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The point is that without it, you run the risk of misunderstandings of
>>>>>>> what the creation date implies for starters. While that could be
>>>>>>> mitigated arguably with disclaimers, there¹s no personal information in
>>>>>>> indicating whether there are known prior registration dates and the
>>>>>>> expert working group recommended that original registration date be
>>>>>>> included. This is just more accurate. Plus the Whois is the most direct
>>>>>>> evidence without necessarily having to ask for documents that would
>>>>>>> include personal information. So this potentially reduces the need for
>>>>>>> personal information disclosure. If someone wants to get their domain
>>>>>>> back that inadvertently lapsed, there would be an indicator that it was
>>>>>>> previously registered without having to necessarily prove it. Plus
>>>>>>> records can more easily be forged. This couldn¹t be.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Sep 30, 2017 at 12:30 PM Stephanie Perrin
>>>>>>> <stephanie.perrin at mail.utoronto.ca> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Surely there are many other ways an individual could prove the original
>>>>>>> registration date of a domain, other than it being in the WHOIS?
>>>>>>>
>>>>>>>
>>>>>>> Stephanie Perrin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2017-09-28 18:22, jonathan matkowsky wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There is a lot going on in the last week, and I am *still* playing catch
>>>>>>> up.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I apologize with the religious high holidays at the end of last week and
>>>>>>> my travel right before that, I dropped the ball, but I want to emphasize
>>>>>>> that the poll that was circulated framing the issue as to whether there
>>>>>>> is a requirement for the Original Registration Date in the EWG Final
>>>>>>> Report is not the issue in my humble opinion. The issue is whether it
>>>>>>> was recommended. And it was. Very clearly. And for good reasons. Some of
>>>>>>> those were specified in the EWG Final Report on page 132, and
>>>>>>> illustrated in the annex thereto.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There are many very important reasons why this recommendation was being
>>>>>>> made from my perspective. I'm not going to re-hash them. I am convinced
>>>>>>> that the reasons why the EWG as a whole made this recommendation would
>>>>>>> be best satisfied by the counter and indicator of unknown or yes status.
>>>>>>> To just focus on the technical reasons why they could have done a better
>>>>>>> job defining the Original Registration Date element as a justification
>>>>>>> to dismiss the *importance* of the element on the basis it was not
>>>>>>> required would be unfortunate.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Domains may be registered and deleted throughout the day literally
>>>>>>> within fifteen minutes apart. Others who lose their domain inadvertently
>>>>>>> and then want to use that original registration date as a point of
>>>>>>> reference in domain recovery should not lose that opportunity. On the
>>>>>>> flip side, to be fair, someone who is the subject of a UDRP deserves the
>>>>>>> opportunity to point to the original registration date as evidence the
>>>>>>> domain was allowed to lapse. When valuating domain names for sale, it is
>>>>>>> important that there be a public record that there may be a cloud on the
>>>>>>> title. etc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The fact that it's unknown there is a prior existing registration is
>>>>>>> important information. It let's people know that the creation date does
>>>>>>> not mean it is the first time the string has ever been created while at
>>>>>>> the same time letting us know when we know for sure that there has been
>>>>>>> such a prior registration in the future when deletions are tracked.
>>>>>>> While technically that may be obvious to us here, that is not
>>>>>>> necessarily obvious to many who rely on Whois. So the fact it is set to
>>>>>>> unknown serves a very important purpose. Furthermore, when it is
>>>>>>> actually known, that is vital information to provide (nobody said
>>>>>>> registry operators have to gather historical data that is burdensome or
>>>>>>> that some might not even have). I am not convinced it is too much to ask
>>>>>>> registry operators to keep track of deletions in the future. Doing so
>>>>>>> may not be hard to implement and would meet the recommendations of the
>>>>>>> EWG. Part of the work we are doing here has to have long-term vision and
>>>>>>> not just whether it is helpful in the short term for our personal or
>>>>>>> commercial purposes at hand. A lot of people in future generations are
>>>>>>> counting on us.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The particular date is not as important to meet the underlying
>>>>>>> objectives of the EWG in coming up with this recommendation. I would
>>>>>>> also not dismiss outright how this counter will eventually serve an
>>>>>>> important function as an indicator of severe abuse that is taking place
>>>>>>> behind the scenes that nobody has easy access to see but can be in the
>>>>>>> future would be more readily apparent from following the EWG's
>>>>>>> recommendation in this regard (albeit, interpreting their recommendation
>>>>>>> more liberally to satisfy the policy considerations and purposes they
>>>>>>> identified).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> All of that said, I recognize and respect that others may disagree on
>>>>>>> this. I would at least then recommend that we ensure that the specific
>>>>>>> ID number that must be collected anyway from an engineering perspective
>>>>>>> is required to actually be *displayed* to tenuously meet the objectives
>>>>>>> of the EWG indirectly since its being exposed in a protocol anyway by
>>>>>>> definition. While this is a lot more work and not as helpful to many
>>>>>>> Internet users as the compromised suggestion to meet their
>>>>>>> recommendation, at least we have protection assuming there are
>>>>>>> historical records as readily available as today and that people can
>>>>>>> point out the different object ID numbers for these strings and explain
>>>>>>> what that means.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Okay, I'm moving on unless there is a group that feels based on what
>>>>>>> I've said, that we should at least re-visit briefly. I recognize that
>>>>>>> there are *many* on this string with a lot more experience than me and
>>>>>>> knowledge coming from different vantage points, but feel it is important
>>>>>>> to at least lay this out in case others agree, as I wasn't on the call
>>>>>>> and couldn't chime in, in as a timely manner for which I express my
>>>>>>> regrets.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jonathan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 22, 2017 at 7:45 AM, Chuck <consult at cgomes.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> I want to request that any members who think there is value in the
>>>>>>> 'counter'
>>>>>>> data element to please answer Paul's question: " So the utility of
>>>>>>> the
>>>>>>> counter seems highly limited. Does it even
>>>>>>> deliver the usefulness that its proponents want it to?" Please share
>>>>>>> what
>>>>>>> you think that value is on this list by Monday of next week.
>>>>>>>
>>>>>>> Chuck
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: gnso-rds-pdp-wg-bounces at icann.org
>>>>>>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Paul Keating
>>>>>>> Sent: Thursday, September 21, 2017 8:32 AM
>>>>>>> To: Greg Aaron <gca at icginc.com>; Andrew Sullivan
>>>>>>> <ajs at anvilwalrusden.com>;
>>>>>>> gnso-rds-pdp-wg at icann.org
>>>>>>> Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original
>>>>>>> Registration
>>>>>>> Date
>>>>>>>
>>>>>>> And what is the intended purpose sought to be achieved?
>>>>>>>
>>>>>>> On 9/21/17, 5:15 PM, "Greg Aaron" <gnso-rds-pdp-wg-bounces at icann.org on
>>>>>>> behalf of gca at icginc.com> wrote:
>>>>>>>
>>>>>>>> >The upshot is that the counter would probably start at "Unknown" for
>>>>>>>> >all existing domains.
>>>>>>>> >* Once implemented, the feature has little usefulness until years in
>>>>>>>> >the future, when some domains get re-registered and those strings
>>>>>>>> >accumulate some history.
>>>>>>>> >* But many domains get renewed year after year. Those wouldn't
>>>>>>>> >accumulate counter history, and would be set to Unknown either
>>>>>>>> forever,
>>>>>>>> >or for long periods if they are ever allowed to expire and if they
>>>>>>>> are
>>>>>>>> >then re-registered. This is a significant portion of domains. For
>>>>>>>> >example .COM has an renewal rate of around 72%.
>>>>>>>> >
>>>>>>>> >So the utility of the counter seems highly limited. Does it even
>>>>>>>> >deliver the usefulness that its proponents want it to?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >-----Original Message-----
>>>>>>>> >From: gnso-rds-pdp-wg-bounces at icann.org
>>>>>>>> >[mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Andrew
>>>>>>>> Sullivan
>>>>>>>> >Sent: Thursday, September 21, 2017 10:49 AM
>>>>>>>> >To: gnso-rds-pdp-wg at icann.org
>>>>>>>> >Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original
>>>>>>>> >Registration Date
>>>>>>>> >
>>>>>>>> >On Thu, Sep 21, 2017 at 02:28:39PM +0000, Greg Aaron wrote:
>>>>>>>>> >> The alternate proposal is a simple marker that says whether there
has
>>>>>>>>> >>been a known previous iteration of the domain string, having been
>>>>>>>>> >>registered with a different ROID.
>>>>>>>>> >>
>>>>>>>> >
>>>>>>>> >Or a counter, of course, rather than just the marker. From the point
>>>>>>>> >of view of implementation in a database, I think these two options
>>>>>>>> are
>>>>>>>> >approximately the same, so I prefer the counter because it provides an
>>>>>>>> >additional bit of data (that is, that the domain is changing -- you
>>>>>>>> can
>>>>>>>> >watch it happen).
>>>>>>>> >
>>>>>>>>> >> And it still presents the same operational problem: the registry
has
>>>>>>>>> >>to figure out whether a string has existed before. That is
>>>>>>>>> something
>>>>>>>>> >>registries are not designed to do. And they may not have the
>>>>>>>>> >>necessary historical records. See the notes below.
>>>>>>>>> >>
>>>>>>>> >
>>>>>>>> >Well, no, that's part of the point of the new proposal: the registry
>>>>>>>> >_doesn't_ have to figure that out, because the counter can be set to
>>>>>>>> >"unknown" (in a SQL database, you'd probably use NULL). To support
>>>>>>>> >this feature, however, the registry would have to track deletions of
>>>>>>>> >domain names in the future. So it wouldn't be free, but it also
>>>>>>>> >wouldn't be hard to implement. (Any real SQL database, for instance,
>>>>>>>> >could do this with an ON DELETE trigger.)
>>>>>>>> >
>>>>>>>> >Best regards,
>>>>>>>> >
>>>>>>>> >A
>>>>>>>> >
>>>>>>>> >--
>>>>>>>> >Andrew Sullivan
>>>>>>>> >ajs at anvilwalrusden.com
>>>>>>>> >_______________________________________________
>>>>>>>> >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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gnso-rds-pdp-wg mailing list
>>>>>>> gnso-rds-pdp-wg at icann.org
>>>>>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *******************************************************************
>>>>>>> This message was sent from RiskIQ, and is intended only for the
>>>>>>> designated recipient(s). It may contain confidential or proprietary
>>>>>>> information and may be subject to confidentiality protections. If you
>>>>>>> are not a designated recipient, you may not review, copy or distribute
>>>>>>> this message. If you receive this in error, please notify the sender by
>>>>>>> reply e-mail and delete this message. Thank
>>>>>>> you.*******************************************************************
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jonathan Matkowsky
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *******************************************************************
>>>>>>> This message was sent from RiskIQ, and is intended only for the
>>>>>>> designated recipient(s). It may contain confidential or proprietary
>>>>>>> information and may be subject to confidentiality protections. If you
>>>>>>> are not a designated recipient, you may not review, copy or distribute
>>>>>>> this message. If you receive this in error, please notify the sender by
>>>>>>> reply e-mail and delete this message. Thank
>>>>>>> you.*******************************************************************
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> 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
>>>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=g
>>>>>> mail&source=g>
>>>>>>
>>>>>> 66386 St. Ingbert
>>>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=g
>>>>>> mail&source=g>
>>>>>>
>>>>>> 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
>>>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=g
>>>>>> mail&source=g>
>>>>>>
>>>>>> 66386 St. Ingbert
>>>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=g
>>>>>> mail&source=g>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> gnso-rds-pdp-wg mailing list
>>>>>> gnso-rds-pdp-wg at icann.org
>>>>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Matkowsky
>>>>>
>>>>>
>>>>>
>>>>> *******************************************************************
>>>>> This message was sent from RiskIQ, and is intended only for the
>>>>> designated recipient(s). It may contain confidential or proprietary
>>>>> information and may be subject to confidentiality protections. If you are
>>>>> not a designated recipient, you may not review, copy or distribute this
>>>>> message. If you receive this in error, please notify the sender by reply
>>>>> e-mail and delete this message. Thank
>>>>> you.*******************************************************************
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> 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
>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=gma
>>>> il&source=g>
>>>>
>>>> 66386 St. Ingbert
>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=gma
>>>> il&source=g>
>>>>
>>>> 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
>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=gma
>>>> il&source=g>
>>>>
>>>> 66386 St. Ingbert
>>>> <https://maps.google.com/?q=Im+Oberen+Werk+1%0D+66386+St.+Ingbert&entry=gma
>>>> il&source=g>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> Jonathan Matkowsky
>>>
>>>
>>>
>>> *******************************************************************
>>> This message was sent from RiskIQ, and is intended only for the designated
>>> recipient(s). It may contain confidential or proprietary information and may
>>> be subject to confidentiality protections. If you are not a designated
>>> recipient, you may not review, copy or distribute this message. If you
>>> receive this in error, please notify the sender by reply e-mail and delete
>>> this message. Thank you.
>>>
>>> *******************************************************************
>>>
>>>
>>>
>>> _______________________________________________ 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/20171010/331bffaa/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list