ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

This policy is dangerous and should be recinded

  • To: transfer-comments-g@xxxxxxxxx
  • Subject: This policy is dangerous and should be recinded
  • From: Jim Archer <jarcher@xxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 31 Jan 2005 22:21:09 -0500


Registration Technologies suggests that this policy be discontinued immediately. This policy places great and completely unnecessary burdens on registrars and, most important, places names of registrants in jeopardy. Additionally, mandating the exact wording of communications between a registrar and it?s customers removes a registrars ability to distinguish itself and brings the customer service quality of all registrars down to a common, low level.

Tasking the Gaining Registrar with Verification Makes no Sense


This policy requires that the gaining registrar contact the domain name registrant to verify the transfer. In order to do this, a gaining registrar must query the whois server of the losing registrar, parse the data and then generate an email.

First, reliably parsing the varying whois formats of approximately 400 registrars is a significant technical challenge and burden. It is only possible to do if the whois server of the losing registrar is operating, if the data is correct and if the data is not hidden by ?private registration.?

Once all this happens, the losing registrar is essentially required to trust that the gaining registrar actually did all this and got permission to submit the transfer. It?s true that the losing registrar can send an email to their customer asking them to verify the transfer, but of the customer does not reply the name must be released.

A Registrar's Customer Can No Longer Rely On Them For Protection

The most important duty a domain name registrar owes it?s customers is the protection of their property. Certainly the SEX.COM disaster has taught us that, as if it was not immediately obvious. This policy almost completely removes the ability of a registrar to protect the interests of their registrant customers.

Registrars are now required to trust another registrar, regardless of who that registrar is, where they are located or how long they have been in business, regardless of their reputation and what legal jurisdiction they are located in. If the losing registrar sends an email to a customer and that email gets trapped in a SPAM filter, or if the recipient is on vacation or out sick, or even if they just miss the email in their inbox, they can easily lose not just a valuable domain name, but significant business opportunities and other benefits associated with control of their online presence. Once a domain name is stolen, the new registrant can impersonate the prior owner, intercept their email and cause no end of trouble. Although the transfer can be undone, damage done in the meantime will be severe.

Once a domain name is stolen, is the losing registrar held liable? Will a losing registrar?s customer, who depended upon his or her registrar to protect their property, then sue? If they do, will they win? Does ICANN indemnify all registrars against this kind of liability?

How This Should Work

The only reasonable way to verify a transfer request is for the losing registrar to contact their own customer and verify the request. Every registrar knows how to contact their own customers without having to parse whois data. Having the losing registrar verify the transfer would greatly simplify the entire process and make complex transfer reversal processes unnecessary.

This policy seems to have been motivated by a small number of registrars who made an outbound transfer difficult. As a result of their unethical actions, all registrars are burdened with this unreasonable. The proper way to deal with this problem is simply to punish registrars that engage in this behavior. Punishing all registrars makes no sense and will not be an effective remedy to the problem.

Further, mandating a common whois data format and dictating other business practices will not solve this problem, but will only create other problems.

James W. Archer

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy