<div class="markdown">
<p dir="auto">On 22 Jan 2016, at 2:35, Thomas Corte wrote:</p>
<blockquote>
<p dir="auto">While, from a purist's standpoint, it seems entirely out of scope for<br>
registries, it does account for the fact that the end of the registrant's<br>
paid service period with the <em>registrar</em> is pretty much the <em>only</em> date<br>
the registrant needs to know.</p>
</blockquote>
<p dir="auto">I see things a bit differently.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">The inconsistency is a problem we have <em>today</em>, 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?</p>
<p dir="auto">Again IMO, this does not improve things. We’re making an already complex system, more complex while at the same time we all lose.</p>
</div>
<body style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><p style="font-family: 'Proxima Nova', Helvetica, Arial, sans-serif; line-height: 12px;"><span class="address-sep break" style="display: inline;"><b>Luis Muñoz</b><br></span><font color="#1e1e1e">Director, Registry Operations</font><br><span class="txt signature_jobtitle-input sig-hide" style="color: rgb(130, 130, 130); display: inline;">____________________________</span></p><p style="color: rgb(0, 0, 0); font-family: 'Proxima Nova', Helvetica, Arial, sans-serif; font-size: 10px; line-height: 14px;"><a href="http://www.uniregistry.link" class="clink sig-hide logo-container"><img src="http://static.uniregistry.net/assets/img/ur-logo@2x.png" alt="Uniregistry" class="sig-logo" height="40" border="0" width="165"></a></p><p style="color: rgb(0, 0, 0); font-family: 'Proxima Nova', Helvetica, Arial, sans-serif; font-size: 11px; line-height: 14px;"><span class="website-sep break" style="display: inline;">2161 San Joaquin Hills Road<br>Newport Beach, CA 92660</span></p><p style="color: rgb(0, 0, 0); font-family: 'Proxima Nova', Helvetica, Arial, sans-serif; font-size: 11px; line-height: 14px;"><span class="txt signature_officephone-input sig-hide" style="display: inline;">Office +1 949 706 2300 x 4242<br>lem@uniregistry.link</span></p></div></div></div></body>