Back

Domain management’s going to be a tough job

Author: Valeria van der Poel
0 MIN READ TIME
4/6/2016
Uncategorized

Update: on the 3rd of June, ICANN announced that the effective date for this policy change has been postponed to the 1st of December 2016.

Many registries send out annual registrar surveys: do you like us, what do we need to improve, those kind of questions. Not rarely they want us to compare them with other registries: are we doing worse/similar/better than registry x? Among thosex‘es, there’s always a gTLD registry like .com. While gTLDs are not perfect either, in general they are not worse than other registries.

Things are about to change, however, with the latest announced update to ICANN’stransfer policy. Working on it since at least 2012, the new policy will become effective on the 1st of August, this summer.

Changes to transfers

Registrar transfers – pretty complex but too mainstream to cause confusion nowadays – are not really going to change. They will still require four security measures:

  • submission of an authorization code,
  • disabling of the transfer lock,
  • confirmation of the transfer by the domain holder or administrative contact
  • and finally, the notification from the old registrar once the transfer has actually been started (introduced in the last update of the transfer policy,back in 2012).

The most important changes is the requirement to invalidate a “Form of Authorization” (FOA, the e-mail that Openprovider sends to the domain holder to confirm the transfer) if the domain has expired in the meantime or the holder data has changed.

Changes to trades

So what’s the big thing that will make gTLDs worse than they are now? ICANN has created policies for registrant transfers as well – at Openprovider better known astrades or owner changes.

While in the recent past more and more registries have adopted more relaxed procedures for changing a domain holder (in many cases it is just an update of the ‘owner contact’), ICANN moves the other way. It might not be as bad as some exotic registries that require signed formal documents to be sent by courier, but things are definitely going to be more complex.

If you want to change the owner’s data (being defined as a change to company name, contact name or e-mail address), explicit consent is required from both the prior and the new contact. This consent will be gathered by e-mail, similar to the current transfer approvals.

Although we strive towards self-regulation as much as possible and although I cannot remember any escalated case about a disputed owner in the history of Openprovider, I can understand, from a legal point of view, why a change of the physical holder of a domain name (being the company name or in case of an individual, that person’s name) may need more control. So far, so good. But requiring a full procedure only for changing an e-mail address… that just does not make sense to me.

When does somebody want to change his e-mail? If the current e-mail is no longer functional for example! This is even a requirement that ICANN puts upon the domain holder: “The Registered Name Holder shall provide to Registrar accurate and reliable contact details and correct and update them within seven (7) days of any change” (RAA section 3.7.7.1).

Creating a policy is one thing; thinking about obvious problems and cooperating in finding a solution is clearly not ICANN’s favorite business.

What Openprovider does

I am in close contact with ICANN to get as many details as possible about this change and to find, together with them, ways to overcome obvious deadlock situations. In a couple of days, ICANN 55 will start in Marrakech and this certainly will be a topic to be addressed with the different stakeholders.

From a functional point of view, we are actively investigating the best way to implement the new policy. This will certainly include our advanced white label toolsand there are some clauses in the policy that allow for work-arounds, for example using designated agents.

Feel assured that we will polish our processes in such a way that they will be as smooth as possible, but also be prepared for these changes as they will probably affect you and all of your customers! Keep an eye on our newsletters, website and blogs for more information. One tip: you may want to verify your customer’s data before August while updating them is still pretty simple!

0 Views
0 Likes

Share this:

More Topics Like This

Openprovider response to the vulnerability in Apache Log4j

Openprovider is not vulnerable to CVE-2021-44228 as we don't use Log4j. Learn more about the Log4j vulnerability and its impact on other services.

Read more

Our statement on Net4India’s current situation

The past days, some inaccurate news has been spread regarding Openprovider and Net4India. Read Openprovider's statement on the situation here.

Read more

Follow us on

;
Image not found

Not a Member yet?

Become a Member today and get access to exclusive deals.