Fabulous auto renew (2 Viewing)

2) letting a domain expire, renewing it, then transfering it to another registrar will lose the renewal

Click to expand...

I didn't see this before, but it seems quite problematic.

By "Expired" so you mean Auto-Renew Grace Period or Redemption Grace Period?

If I renew a domain that's been expired for a few days in order to sell it, does that mean I effectively lose the money I paid for the renewal and the buyer loses a year off what they thought would be the new renewal date?

@bmetal

CanSpace said:

With their new changes, domains that have been manually and explicitly renewed by our clients are now in an "auto renewed" state, which from our perspective is a logical inaccuracy. They have not been "automatically" renewed, they were manually renewed.

Click to expand...

Yes, agreed, as a registrant renewing a recently expired domain, there is no indication in Whois that it was done, the "updated" date is not updated, etc. There is no way for the registrant to verify that the registrar completed its obligation to "renew" (i.e. plan to not delete the domain). Under every other circumstance, Whois is the definitive last word in what the status of your domain is - but for this one scenario, CIRA prefers this silly method which is ambiguous.

At least MyID, Baremetal, CanSpace and possibly others used an alternative process of issuing the "delete" and then issuing an immediate "restore", which caused the domain to be renewed on the spot and be reflected as such in Whois. As both a registrant and a registrar, it seems most would agree that this is the better method because it removes all ambiguity.

CanSpace said:

There are many other problems with this model as you've pointed out (no renewal emails sent out, a year being lost on transfer even if it was explicitly paid for with us, etc).

Click to expand...

OK, just to make sure I understand this scenario, I'm going to review it here.

So I assume this whole "year being lost" issue is due to CIRA giving no way for a registrar to lock in a domain renewal while it is in auto-renew-grace status, thus when it gets transferred while still in auto-renew-grace, CIRA just "assumes" it wasn't paid for, therefore they don't transfer that year of credit with the domain. But you'd think if that was true, CIRA would also automatically refund the losing registrar so they are made whole, and if the registrant did pay for the renewal, then the registrar could refund the registrant too. Thus there is nothing lost for anyone (but I understand this is a big pain in the arse for the losing registrar, which seems unfair to put that onus on them).

It also sounds like this "restore" (or is it "redeem"?) command causes a domain in redemption-grace (which comes after auto-renew-grace), to "lock-in" the renewal (so it can't be deleted) and DOES properly update the Whois record reflecting that the domain was renewed, correct?

So it seems to me that CIRA could resolve several big issues (the lost year, not being able to lock-in a renewal, and ambiguous whois info) with one simple change. And that change would be to allow that restore/redeem command to be issued DURING auto-renew-grace. This would allow the registrar to indicate that the renewal fee had been recovered by the registrar (and therefore there will be no need for a future "delete" command by the registrar in order to get their refund), and furthermore, this would update Whois to accurately reflect the new status of "OK" rather than the ambiguous auto-renew-grace state, AND it gives a new Whois updated-date. This would remove all ambiguity and would allow a registrant to verify via Whois that the renewal was completed and they don't have to just take the registrar's word for it (which could be and has been wrong).

@CanSpace @bmetal @FM @CatchDrop @namesproCA - is my understanding of the situation correct? Would the simple solution of allowing a restore/redeem command during auto-renew-grace fix these long-standing issues like I think it would?

rlm said:

OK, just to make sure I understand this scenario, I'm going to review it here.

So I assume this whole "year being lost" issue is due to CIRA giving no way for a registrar to lock in a domain renewal while it is in auto-renew-grace status, thus when it gets transferred while still in auto-renew-grace, CIRA just "assumes" it wasn't paid for, therefore they don't transfer that year of credit with the domain.

Click to expand...

Correct.

We've known it as the 45 day rule in the .com world for ages. (Possibly since the 90s?)

The situation usually comes up as a registrant forgets to renew their domain (possibly due to out of date contact info), and then decides they want to either consolidate or centralize their domain(s).... We generally advise them to wait the 45 days to the end of the autorenewal period, at which point they've often forgotten about it.

CIRA's policy seems to be that registrars should look for and detect this situation, and refund the clients for the cancelled "auto" renewal.

(We're "good", but we're not that good.)

-Tom

bmetal said:

Correct.

Click to expand...

Okay, so how do you sell .CA domains that have recently expired and are in redemption? You can't?

The reason I ask is most sales venues auto-check to make sure you are at least 30-days left before expiry. Otherwise they tell you to renew and let them know when to check again.

rlm said:

So it seems to me that CIRA could resolve several big issues (the lost year, not being able to lock-in a renewal, and ambiguous whois info) with one simple change. And that change would be to allow that restore/redeem command to be issued DURING auto-renew-grace. This would allow the registrar to indicate that the renewal fee had been recovered by the registrar (and therefore there will be no need for a future "delete" command by the registrar in order to get their refund), and furthermore, this would update Whois to accurately reflect the new status of "OK" rather than the ambiguous auto-renew-grace state, AND it gives a new Whois updated-date. This would remove all ambiguity and would allow a registrant to verify via Whois that the renewal was completed and they don't have to just take the registrar's word for it (which could be and has been wrong).

@CanSpace @bmetal @FM @CatchDrop @namesproCA - is my understanding of the situation correct? Would the simple solution of allowing a restore/redeem command during auto-renew-grace fix these long-standing issues like I think it would?

Click to expand...

Something along those lines would be preferable, yes. The idea that domains that have been explicitly renewed by a client are still in an "auto renewed" state is flawed to me (and other registrars evidently), since it was not "automatically" renewed by any means - we explicitly submitted a renew command (or at least, we did previously).

rlm said:

So it seems to me that CIRA could resolve several big issues (the lost year, not being able to lock-in a renewal, and ambiguous whois info) with one simple change. And that change would be to allow that restore/redeem command to be issued DURING auto-renew-grace. This would allow the registrar to indicate that the renewal fee had been recovered by the registrar (and therefore there will be no need for a future "delete" command by the registrar in order to get their refund), and furthermore, this would update Whois to accurately reflect the new status of "OK" rather than the ambiguous auto-renew-grace state, AND it gives a new Whois updated-date. This would remove all ambiguity and would allow a registrant to verify via Whois that the renewal was completed and they don't have to just take the registrar's word for it (which could be and has been wrong).

Click to expand...

Yes/no.

It's not about being able to run the restore commands. You can delete a domain in auto-renew-grace. That pushes it into redemption period (immediately), at which point you can restore it... But with the "bug fix", you're just back to where you started... a domain back in auto-renew-grace. (Before the bug fix, the domain came back is a normal registration, with an expiry date in the past, which you could run a normal renewal command on.)

As far as I know, restoring a domain without deleting it ... would be a fairly significant departure from the EPP standard.

(It's quite possible/likely that the folks who wrote the EPP standard have discussed these issues. Chasing them/that down might be a good idea if someone has time/energy ... rather than inventing ad hoc solutions here.)

I don't believe CIRA sees a problem here. This is what they meant/wanted to implement when they switched over to an EPP registry. e.g. "industry standard" ... which I expect they hoped would bring more registrars, and more registrations.

-Tom

bmetal said:

Yes/no.

It's not about being able to run the restore commands. You can delete a domain in auto-renew-grace. That pushes it into redemption period (immediately), at which point you can restore it... But with the "bug fix", you're just back to where you started... a domain back in auto-renew-grace. (Before the bug fix, the domain came back is a normal registration, with an expiry date in the past, which you could run a normal renewal command on.)

As far as I know, restoring a domain without deleting it ... would be a fairly significant departure from the EPP standard.

Click to expand...

Ah, ok, that does bring some additional clarity. So what they really need is just an additional command that simply allows a registrar to remove the auto-renew-grace status while simultaneously updating the Whois Updated date stamp.

bmetal said:

(It's quite possible/likely that the folks who wrote the EPP standard have discussed these issues. Chasing them/that down might be a good idea if someone has time/energy ... rather than inventing ad hoc solutions here.)

I don't believe CIRA sees a problem here. This is what they meant/wanted to implement when they switched over to an EPP registry. e.g. "industry standard" ... which I expect they hoped would bring more registrars, and more registrations.

Click to expand...

So in your opinion, what would the impact be to registries and registrars if CIRA added an optional command to FURY, implemented at the registry level (a configuration setting), allowing a registrar of said registry to effectively lock-in a renewal when in auto-renew-grace (which presumably would be to simply remove the auto-renew-grace status and update the Updated timestamp). A registry who buys/leases FURY from CIRA could simply choose to implement or not implement that individual feature, no? I'm not sure I understand why CIRA would be resistant to what seems to be a simple solution. What would be the potential problems with such a solution? Of course CIRA tries to shun any accountability for anything, but if a registrar issued that "lock-in" command by mistake, that's on them, not CIRA. I can't really see a negative from CIRA's perspective of any unintended consequences, can you? But the benefits seem to be well documented.

I understand what's going from a technical POV, but I'm still very confused as to what happens in the real-world under certain scenarios.

Such as:

I receive an bundle offer on 10 domains that have recently expired. I renew the domains, We take the transaction for Dan for the 5% escrow, but how long will it take these 10 domains to renew and not set off the 30-days-left escrow requirement?
Is the data on WHOIS immediately post-renewal enough to pass the 30-day litmus test?
Can you even sell expired-then-renewed domains on marketplaces under this renewal system? You must be able to if it's used with .COM et al.

I guess I'll find out when I hit those scenarios one by one.

DomainRecap said:

I understand what's going from a technical POV, but I'm still very confused as to what happens in the real-world under certain scenarios.

Such as:

I receive an bundle offer on 10 domains that have recently expired. I renew the domains, We take the transaction for Dan for the 5% escrow, but how long will it take these 10 domains to renew and not set off the 30-days-left escrow requirement?
Is the data on WHOIS immediately post-renewal enough to pass the 30-day litmus test?
Can you even sell expired-then-renewed domains on marketplaces under this renewal system? You must be able to if it's used with .COM et al.

I guess I'll find out when I hit those scenarios one by one.

Click to expand...

I'm not familiar enough with any of those services to be able to answer. At this point, renewing a domain in auto-renew-grace doesn't do anything, so it comes down to how these various services interpret dates and status flags. And renewing a domain in Redemption period throws it back into auto-renew-grace.

DomainRecap said:

Okay, so how do you sell .CA domains that have recently expired and are in redemption? You can't?

The reason I ask is most sales venues auto-check to make sure you are at least 30-days left before expiry. Otherwise they tell you to renew and let them know when to check again.

Click to expand...

The "logical answer" is you have to wait for the auto-renew-grace period to expire... which apparently gets reset to 0 when a redemption is is done, I just looked at an example of this... a namespro domain that was deleted shortly after expiry, and then renewed 19ish days into redemption period. Unfortunately that timer (stage end) isn't shown in whois, a registrar sees it from a domain:info command.

status : clientTransferProhibited
life stage : autoRenewPeriod
stage end : 2023-06-12 (2023-06-12T22:15:30.912Z)
expiry : 2024-04-09 (2024-04-09T19:48:07.336Z)
updated : 2023-04-28 (2023-04-28T22:15:30.878Z)

The key bit being that "stage end" (06-12) is 45 days after 04-28, not 45 days after 04-09

But that "logical answer" is just me guessing how these services work.

---
And looking at the RFCs, CIRA's "bug fix" is strictly correct. The redemption period grace and restore commands are detailed in rfc 3915, and item 2.7 of that rfc
explicitly states that the restore command should return the domain to whatever state it was in when the domain was deleted.

RFC 3915: Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)

So, if you are a domain investor who receives offers at random times that are under a "30+ days before expiry" transfer requirement, it would behoove you to never let a .CA domain expire (even for a day) under this new system.

That's how I'm reading it.

rlm said:

Ah, ok, that does bring some additional clarity. So what they really need is just an additional command that simply allows a registrar to remove the auto-renew-grace status while simultaneously updating the Whois Updated date stamp.

Click to expand...

The whois update comes for free with removing the auto-renew-grace status.

rlm said:

So in your opinion, what would the impact be to registries and registrars if CIRA added an optional command to FURY, implemented at the registry level (a configuration setting), allowing a registrar of said registry to effectively lock-in a renewal when in auto-renew-grace (which presumably would be to simply remove the auto-renew-grace status and update the Updated timestamp). A registry who buys/leases FURY from CIRA could simply choose to implement or not implement that individual feature, no? I'm not sure I understand why CIRA would be resistant to what seems to be a simple solution. What would be the potential problems with such a solution? Of course CIRA tries to shun any accountability for anything, but if a registrar issued that "lock-in" command by mistake, that's on them, not CIRA. I can't really see a negative from CIRA's perspective of any unintended consequences, can you? But the benefits seem to be well documented.

Click to expand...

It's just special purpose code that needs to be maintained, and probably wouldn't be widely used ... e.g. GD isn't likely to modify their systems to optimize .CA handling.

A domain restore is actually two commands: a restore request (simple, short), and a restore report which has a whole bunch of data fields in it that don't seem to be used. It would seem simple enough to add some special case handling for flags in that report to shortcut the auto-renew-period timer, and set it to something FAR shorter than 45 days. (But that would still require a delete, and then the two restore commands. An extension to domain:update would be another option.)

I'm still trying to wade through the RFCs, but it is slow going and I'm not at my best today (race day yesterday).

DomainRecap said:

So, if you are a domain investor who receives offers at random times that are under a "30+ days before expiry" transfer requirement, it would behoove you to never let a .CA domain expire (even for a day) under this new system.

That's how I'm reading it.

Click to expand...

It depends on how accommodating these buyers are. If the offers are "today or never" then you are correct.

To be honest I never really understood the logic behind letting a domain get suspended for days/weeks and then renewing it... you're paying for 12 months of registration, but the domain is only live for 10 or 11.

.... I have heard the explanation that folks get interested in domains that appear to be expiring.

You'll have to figure out how to balance those conflicting goals ... unless or until we can persuade CIRA to impliment a way to clear that autoRenewPeriod flag

bmetal said:

The whois update comes for free with removing the auto-renew-grace status.

It's just special purpose code that needs to be maintained, and probably wouldn't be widely used ... e.g. GD isn't likely to modify their systems to optimize .CA handling.

A domain restore is actually two commands: a restore request (simple, short), and a restore report which has a whole bunch of data fields in it that don't seem to be used. It would seem simple enough to add some special case handling for flags in that report to shortcut the auto-renew-period timer, and set it to something FAR shorter than 45 days. (But that would still require a delete, and then the two restore commands. An extension to domain:update would be another option.)

I'm still trying to wade through the RFCs, but it is slow going and I'm not at my best today (race day yesterday).

Click to expand...

Ah, well, don't put too much thought into it. I'm just assuming there should be a solution that would be best for everyone, because if this is how the system works for all tlds, then it should be a nagging problem for all tlds.

And you possibly hinted at another solution. Just remove the auto-renew-grace period altogether? I believe that 0 to 45 day period is entirely optional at the registrar level? Is that a master setting for your registrar (i.e. not something you can set on a per-domain basis?). Of course that has negative consequences too, namely, your domain stops working the day after it expires, rather than 0 to 45 days later...

rlm said:

And you possibly hinted at another solution. Just remove the auto-renew-grace period altogether? I believe that 0 to 45 day period is entirely optional at the registrar level? Is that a master setting for your registrar (i.e. not something you can set on a per-domain basis?). Of course that has negative consequences too, namely, your domain stops working the day after it expires, rather than 0 to 45 days later...

Click to expand...

Yes, deleting the domain early and getting it out of autoRenewPeriod sounds promising at a glance. But AFAICS all it does is move the "go to TBR" date forward. If you restore the domain, it still goes back to autoRenewPeriod.

In more detail, when a registrar deletes domains and sends them into Redemptionperiod is a something setup at the registrar (part of our nightly cron jobs). Likewise, when a domain stops working is also registrar policy decision. We set clientHold when domains expire (which pulls the DNS delegation out of the .CA nameservers), and we issue the domain:delete command about 35 days after expiry. I'm sure there are registrars that delay the clientHold, and I know there are registrars which delete the domains pretty much immediately. Deleting a domain sets serverHold, so there is some overlap.