[gtld-tech] Registrar Expiration Date I-D

[Luis E. Muñoz]

On 22 Jan 2016, at 10:03, Thomas Corte wrote:

> Hello Luis,

Hello Thomas,

>
> On 22/01/2016 18:18, Luis E. Muñoz wrote:
>
>> On 22 Jan 2016, at 2:35, Thomas Corte wrote:
>>
>>  While, from a purist's standpoint, it seems entirely out of scope 
>> for
>>  registries, it does account for the fact that the end of the 
>> registrant's
>>  paid service period with the /registrar/ is pretty much the /only/ 
>> date
>>  the registrant needs to know.
>>
>> I see things a bit differently.
>>
>> The issue at hand is that in essence, we have two completely separate
>> databases tracking the same object (the domain name) using 
>> (hopefully)
>> the same rules to ascertain its life-cycle and expose it to the 
>> public,
>> including the registrant.
>>
>> IMO, the two databases operate in rough agreement most of the time
>> regarding the expiry date. Disagreement usually happens around the
>> auto-renew date because the two databases might very well update 
>> their
>> status at different times creating a window of inconsistency.
>
> It's not just a matter of how auto-renewals are processed; the 
> agreement
> highly depends on the registrar's billing policy.

Agree. I used the auto-renew as an example, but this does not invalidate 
the rest of the argument.

> However, for transferred-in domains it could be vastly different.
> Let's say a domain is created by a different registrar on January 1st,
> 2016 with a 1-year period (expiring on 2017-01-01). It is then
> transferred to us on July 1st, 2016, meaning that our registrar 
> (2-year)
> payment cycle starts on 2016-07-01 and ends on 2018-07-01. The domain 
> is
> renewed by one year at the registry as part of the transfer, setting 
> its
> registry expiration date to 2018-01-01. However, our *registrar*
> expiration date is 2018-07-01, six months later.

Perhaps I’m missing some important information, but shouldn’t you 
consider the creation / expiration dates at time of transfer and use 
that in your billing cycle computation? I would think that this scheme 
would always result in being out of phase with the domain’s life 
cycle.

> Currently, what our registrar system does instead is extend the domain 
> by
> another year (bumping the registry expiration date to 2019-01-01), so
> that the registrant won't worry about losing it on 2018-01-01.
> This premature renewal could be avoided with the proposed extension.

The premature renewal would also be avoided by adjusting your policy to 
account for this use case, without all the rest having to write code and 
deploy resources to address the changes.

Best regards

Luis Muñoz
Director, Registry Operations
____________________________

http://www.uniregistry.link/
2161 San Joaquin Hills Road
Newport Beach, CA 92660

Office +1 949 706 2300 x 4242
lem at uniregistry.link
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160122/72435a8b/attachment.html>