Excuse .MOI? Registrar comment.

So Amazon wants to add the following to their contract for .MOI

And as such things go, when a Registry operator wants to change or add a contract section, the Registrar Stakeholder Group gets to review it and is then able to post a comment. Personally, I had some issues with the above amendment due to the fact it was not clear what this authentication platform entails.

Sure such authentication platforms are not new. Like when you apply for a .BANK domain name you have to go through a vetting process, as only registered banks can order a domain name for that .TLD. Common sense in my opinion.

So the amendment was not clear to begin and as such a few Registrars came up with the following joined comment. As being one of the people on the drafting team it will come not as a surprise that Realtime Register fully supports this comment.

The Registrars appreciate the opportunity to file a comment.

Innovation is no strange concept amongst the registrars and is often a competing element. As such, the Registrars welcomes the innovational efforts displayed by Amazon Registry Services, Inc. (“Amazon”). Likewise, we acknowledge the vertically-integrated nature of someTLDs,
and the competitive environment surrounding value added tools & services. This is now a function of our industry, and if properly managed, can enhance the choices available to
Regarding the proposed amendment for .MOI, the Registrars observed and identified the following, click here to continue reading.

Another take on this amendment can be read here and is from Kieren McCarthy called :”Amazon attempts rule fudge to take exclusive control of new dot-words”.

Welcome To Hotel California, Room IRTP-C. The Change of Registrant Policy.

You might have heard some horror stories about the upcoming change of registrant policy, effective starting this August.
Some of these stories tell a tale about certain hotel California Registrars, easy to check in your domain names, but you will never be able to transfer them out.

Hotel California

Hotel California (Photo credit: Wikipedia)

Now as a member of the ICANN group, IRTP-C IRT, who actually spend a lot of time drafting this policy, let me be the first to debunk some myths regarding this policy.

Transfers will not be impossible, but they will be harder if the current email address is incorrect due to the fact that you will need to update the email address and this will trigger a change of registrant procedure. Depending how well or badly your Registrar implements this, it will either be a rather simple procedure or a complete nightmare. So if you plan to transfer your domain names, now is a good time to do so. As the policy currently does not apply.

The following will trigger a Change of Registrant procedure

  • Change of email address
  • Change of the first name and last name
  • Change of the organization name


What are the requirements for a Registrar when the above scenario is being triggered.

– Process the change of registrant through a secure mechanism
– Send a confirmation to the old and new registrant.

In a nutshell, that is actually what the change of registrant entails.


First of all, do you as a reseller want to process the change of registrant or do you want us, Realtime Register do it?

We at Realtime Register look at it this way and though I am going to mention some numbers here, they are by no means set in stone. So they are only examples for now.

Scenario One; Let Realtime Register do the work 

Imagine a reseller has 1000 domain names in his portfolio. How many times would there be a change of registrant where the domain name remains with the same reseller? I expect maybe once a month?

So in this scenario, you would like to have Realtime Register to provide the secure mechanism. First of all, you do not have to invest any money or time in a secure mechanism if you do not offer one, second if you do have one you do not have to check if your secure mechanism is up to par with certain RFC’s and best practices that deal with usernames and passwords and security in general. As this is actually the spirit of the policy.

Using the Realtime Register secure mechanism works as follows. You change the registrant for a domain name, Realtime Register will send a confirmation email to the old and new registrant, as soon both agree we will process the change and send a confirmation to the old and the new registrant. So make sure your branding is up to date.

Scenario Two; DIY

Scenario one might be problematic if you have a lot of domain names. Most likely this will create support pressure.  If your control panels that you offer to your customers/registrants are secure then you can become a designated agent.

The solution, become a designated agent. This solution can be used by most hosting companies who offer control panels to their customers to allow domain name operations and or other services and always require a registrant to log into a secure environment.

A designated agent according to the policy is an entity that can operate on behalf of the old and new registrant if they acquired explicit consent from the old and new registrant. So in order to be able to process these changes, you must make sure that your registration agreements contain this language and make sure your customers have given consent. Most likely you want to record this in the case of an audit you can easily demonstrate compliance with the policy.

This also means that you need to make sure that control panels you offer to your clients are secure enough. You do not have to start offering two-factor authentication (even though that would be nice) as one-factor authentication is also considered to be a secure mechanism. Provided you use best practices.

Best practices and common sense

Best practices do not allow usernames and password to have a length of 4 characters, so that is a no go. Microsoft has a good article about strong passwords wich you can read here.

Now with the above in mind, a change of registrant can be executed as follows. You send the change of registrant to our system through the API and you will send an extra API tag so our system knows that you acquired consent from the old and new registrant. The domain name will be updated and we will not send emails where the registrants have to agree to. The email that the change has been processed to the old and new registrant will still be sent as this is a requirement of the policy. Dutch Resellers might find this notification requirement similar to the Dutch Registry notifications who have a similar process in place.

The above procedure will also be available through the domain manager.

In the weeks to come, I will post more on how we are going to deal with transfers, privacy protect and other fun stuff.

The entire IRTP-C policy is located here

Last but not least, as mentioned earlier, it will be critical that you have up to date data and working email addresses for your customers in the future. So avoid a lot of hassles and make sure the data is correct. At Realtime Register things will be made easy, I can, however, not predict how other Registrars will implement this policy. So make sure that your data is up to date if all of your domain names are not at Realtime Register.


If you have any questions, let me know and shoot me an email at support@realtimeregister.com