[gtld-tech] Registrar Expiration Date I-D

[luvingnc at aol.com]

Maybe this is a dumb question, but why not require registrars to display the registry expiration date?  They already have it, it requires no EPP extensions, and it's the registrar that's confusing (if things are confused) by exposing a different date than is held by the registry.


Nowadays, registrants go to either the registrar or the registry to consult the expiration date — I would think that most go to the registrar, where they’re seeing the “Registrar Expiration Date” and probably leave happy knowing their domain is safe and sound for the year they just were charged for.
The proposal calls for the registrar to send their version of the expiration date so that the registry displays it.




Ann Hammond



-----Original Message-----
From: Luis E. Muñoz <lem at uniregistry.link>
To: Thomas Corte <Thomas.Corte at knipp.de>
Cc: gtld-tech <gtld-tech at icann.org>
Sent: Fri, Jan 22, 2016 12:18 pm
Subject: Re: [gtld-tech] Registrar Expiration Date I-D



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.
Nowadays, registrants go to either the registrar or the registry to consult the expiration date — I would think that most go to the registrar, where they’re seeing the “Registrar Expiration Date” and probably leave happy knowing their domain is safe and sound for the year they just were charged for.
The proposal calls for the registrar to send their version of the expiration date so that the registry displays it. Of course, the update itself will have some time delay in being processed — besides of being an additional transformative operation, that will be coming at a time separate from the moment the registry finishes processing the automatic renewal. Basically we’re left in a worst place than we started. By exposing both dates at the same place, all of a sudden the registrant is made aware of a non-issue that she can do nothing about. This will result in more tickets opened at both, registrars and registries, claiming that the dates are different as well as unnecessary stress on the registrants. The resolution of those tickets will likely be some variation of “just wait a little and the dates will again magically match. Thank you”, causing the impression that there is some sort of confusion in the way the domain name is being managed by the registrar / registry.
The inconsistency is a problem we have today, and by all means it self-corrects. It’s a classical distributed systems problem with no easy / perfect solution, by the way, simply because of the model we have in place. Why do we want to expose and amplify the impact of this non-issue by including third parties that cannot do anything to help resolve the situation?
Again IMO, this does not improve things. We’re making an already complex system, more complex while at the same time we all lose.


Luis Muñoz
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...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160122/a2cf066c/attachment-0001.html>