[gtld-tech] Registrar Expiration Date I-D

[Francisco Obispo]

RYs auto-renew names, so there’s nothing that the RAR needs to do when the anniversary of a registration arrives.

If we add this field, when the registrant renews a name in the RAR, a new command will need to be sent to update the RAR-expiry date at the registry. By itself it sounds simple, but multiply this by millions of registrations and we soon get into a situation where there will be a lag between the RAR and RY dates.

Also, implementing a new extension requires time, dev time, setting up a timeframe to roll it out, project management, time to contact all RARs through the communications channel (people sending emails, following up, etc.), setting up testing in OT&E platforms, dealing with support, etc.

At the end of the day, if we execute it perfectly, we will still have 2 dates, and one place where it is potentially out of sync.

So the amount of effort for the gain is very little.

Someone once told me.. the road to hell is paved with good intentions, and this could just be an example of that.

regards,

—
Francisco Obispo
Uniregistry Inc.
On 26 Jan 2016, at 13:22, Andrew Newton wrote:

> Can you elaborate? To me it seems that if you are going through the expense of transmitting registrant data for the conversion from thin to thick, that this one date field is easy enough to add on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160126/d4b4ef8d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160126/d4b4ef8d/signature.asc>