[gtld-tech] Registrar Expiration Date I-D
Luis E. Muñoz
lem at uniregistry.link
Fri Jan 22 18:15:03 UTC 2016
On 22 Jan 2016, at 10:03, Thomas Corte wrote:
> Hello Luis,
> 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
>> registries, it does account for the fact that the end of the
>> paid service period with the /registrar/ is pretty much the /only/
>> 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
>> the same rules to ascertain its life-cycle and expose it to the
>> 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
>> status at different times creating a window of inconsistency.
> It's not just a matter of how auto-renewals are processed; the
> 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
> payment cycle starts on 2016-07-01 and ends on 2018-07-01. The domain
> renewed by one year at the registry as part of the transfer, setting
> 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
> Currently, what our registrar system does instead is extend the domain
> 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.
Director, Registry Operations
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...
More information about the gtld-tech