Dealing with rebel baloney (1.Viewing)

Hi Brett, thanks so much for following up, that is much appreciated!

I recommended Rebel to someone who was buying their first .ca domains. But we've run into a couple of issues that I didn't know would be a problem at Rebel, as its not an issue at other registrars. Chatting with the online support just provided us with incorrect information too.

Here is what happened:

1.My friend signed up at Rebel and registered a single .ca domain name. Later that day, they then bought a second .ca from a third party and transferred it to their Rebel account. First minor complaint, why would the transfer take a day to complete when nearly every other registrar transfers .CA domains instantly? It just added confusion because I told them .CA transfers are instantaneous. So there I am trying to figure out what went wrong over the phone with my friend and it turns out its just Rebel's way of doing things I guess... For the record - not a fan of that.

2. The domain eventually transferred into Rebel under the seller's Registrant info, but then Rebel gives no way to allow their own customer to update the registrant information. It just said the contact was locked. So I tell my friend, oh, they might just lock it by default on your behalf for security reasons, but that there is most certainly an unlock button/option somewhere! Nope. After searching high and low, no option to unlock was found. In fact it just said the Registrant specifically was locked, but didn't explain how long or why.

3. That led to contacting chat support and they said the Registrant is now locked for 60 days - preventing any changes to the Registrant. Wrong! Only TRANSFERS to another registrar are locked, not changes to Registrant details.

So, the domain in question has the following EPP status codes set for the newly transferred domain. They are:

clientTransferProhibited
clientUpdateProhibited
serverTransferProhibited

The serverTransferProhibited status is set by the registry after a domain transfer, preventing the domain from being transferred to a new registrar, NOT preventing anything else, such as updating the registrant.

All client*Prohibited epp status codes are set by the Registrar, i.e. Rebel. That also means you can unlock it.

The real problem here is that Rebel isn't allowing their own customer to update their own domain with their own registrant info. Seems messed up, no? Depending on the situation, you could be putting either the old owner, or the new owner at legal risk. This is why we were concerned about correcting this Registrant info asap. What if a CDRP is filed on this domain?? The domain gets locked with the wrong Registrant info! I can only imagine the mess this would cause. If this happened, it would be 100% Rebel's fault! Maybe you're thinking, what are the chances of that?? But I'm thinking, what are the consequences?

So now I just asked this person to log in again today and see if the "unlock" option has come up anywhere yet. Now it says the Registrant is locked until Nov 12, which is 7 days after the transfer. Obviously that is better than the 60 days. If the website had been clear about that from the beginning, that would have been nice and would have saved a lot of frustration. And clearly the support people don't know what they're talking about either - they insisted it was locked for 60 days, causing more concern.

But even the 7 days is kinda baloney, if you ask me. I'm guessing that Rebel has just made it their policy (that is not disclosed anywhere that I saw), to use the clientUpdateProhibited epp status code to make up their own rules for locking domains. While I could understand you might Lock domains by default on behalf of the client for security purposes, the client should absolutely be allowed to unlock it, any time.

Just so I could see what was going on, I tested out the transfer-in logic at Rebel, and there does appear to be an option to change the Contacts for the incoming domain transfer during the check-out process (at least for me) and it pre-populates the contact info for the incoming domain with our own contact information from a previous Contact in our account (not defaulted to the old owner's information). So if that is the case, how did my friend have their incoming transfer default to the old owner's contact info?? Had it defaulted to the contact already in their account (from the .ca registration made earlier in the day), this wouldn't have happened either. So I don't even understand how this happened to begin with. But regardless of how it happened, the client should always be allowed to update their registrant details (unless of course it is the Registry setting the lock, i.e., the server*Prohibited status codes, which is not the case here).

So anyways, I'm just wondering what your perspective is on this. I personally don't think its Rebel's right to refuse to unlock any client*Prohibited epp status codes, ever. It seems self-evident that those are intended to be set at the client's direction, not the Registrar's whim, nor for any registrar to be able to refuse to unlock. Is there some sort of 7-day loophole in the CIRA regulations that Rebel is using to justify this?

Thanks!
 
While we're on the subject...

Forcing automatic renewal payments 45 days prior to the expiry period, with no option to turn off auto-renew, is baloney too (imo). Especially when you have nearly 80 domains there.

I understand it can help some people save domains they don't want to let expire, but the post-expiry period with cira is already 75 days to begin with, which means there are 75 days to help registrants renew/recover their domain even after the domain expires.

At GoDaddy I can wait 75 after the expiry date before I need to decide wether to renew or not, and at no additional cost. In other words, and the way that I look at it, is that Rebel forces me to decide on renewals 120 days earlier than at GoDaddy (i.e. the 45 days prior to expiry + 75 days after expiry = 120 days).
 

Sponsors who contribute to keep dn.ca free for everyone.

Sponsors who contribute to keep dn.ca free.

Members who recently read this topic: 1

Back
Top Bottom