[gnso-rds-pdp-wg] Proposed Agreement for Original Registration Date

Thu Sep 21 15:40:35 UTC 2017

Please remember that our work relates to gTLDs not ccTLDs.

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:22 AM
To: Maxim Alzoba <m.alzoba at gmail.com>; Volker Greimann
<vgreimann at key-systems.net>
Cc: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original Registration
Date

And, of course there is the issue of obtaining the data to fill the field
with a meaningful data element.  It would require a link to historical data
that may or may not exist, particularly at the ccdld level.

Paul

On 9/21/17, 5:10 PM, "Maxim Alzoba" <gnso-rds-pdp-wg-bounces at icann.org on
behalf of m.alzoba at gmail.com> wrote:

>Is it better to make it list of previous periods of registration?
>like dd/mm/yy-dd1/mm1/yy1 ?
>
>the bad thing is, most of old domain names will have something like 
>unknown, dd/mm/yy-dd1/mm1/yy1 (if we decide to have this field at all)
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>m. +7 916 6761580(+whatsapp)
>skype oldfrogger
>
>Current UTC offset: +3.00 (.Moscow)
>
>> On Sep 21, 2017, at 17:54, Volker Greimann 
>><vgreimann at key-systems.net>
>>wrote:
>> 
>> My issue with the counter is that it is just as prone to errors than 
>>the originally proposed date. If you overlooked an old registration, 
>>the count is wrong. So i prefer the y/n/u approach (if we take in the 
>>field at all).
>> 
>> Volker
>> 
>> 
>> Am 21.09.2017 um 16:48 schrieb Andrew Sullivan:
>>> 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
>>> 
>> 
>> --
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> 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