<div class="markdown">
<p dir="auto">On 22 Jan 2016, at 10:03, Thomas Corte wrote:</p>

<blockquote>
<p dir="auto">Hello Luis,</p>
</blockquote>

<p dir="auto">Hello Thomas,</p>

<blockquote>
<p dir="auto">On 22/01/2016 18:18, Luis E. Muñoz wrote:</p>

<blockquote>
<p dir="auto">On 22 Jan 2016, at 2:35, Thomas Corte wrote:</p>

<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 /registrar/ is pretty much the /only/ date<br>
 the registrant needs to know.</p>

<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<br>
databases tracking the same object (the domain name) using (hopefully)<br>
the same rules to ascertain its life-cycle and expose it to the public,<br>
including the registrant.</p>

<p dir="auto">IMO, the two databases operate in rough agreement most of the time<br>
regarding the expiry date. Disagreement usually happens around the<br>
auto-renew date because the two databases might very well update their<br>
status at different times creating a window of inconsistency.</p>
</blockquote>

<p dir="auto">It's not just a matter of how auto-renewals are processed; the agreement<br>
highly depends on the registrar's billing policy.</p>
</blockquote>

<p dir="auto">Agree. I used the auto-renew as an example, but this does not invalidate the rest of the argument.</p>

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

<p dir="auto">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.</p>

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

<p dir="auto">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.</p>

<p dir="auto">Best regards</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>