ICANN | Letter From Ross Wm. Rader to Stuart Lynn Regarding Registrar-to-Registrar Transfers

  ICANN Logo
Letter From Ross Wm. Rader to Stuart Lynn Regarding Registrar-to-Registrar Transfers

25 July 2001


Tucows LogoRoss Wm. Rader
Director, Innovation & Research
Tucows Inc.
96 Mowat Avenue
Toronto, Canada

M6K 3M1
t. 416.535.0123
f. 416.531.5584
e. ross@tucows.com

July 25, 2001

Mr. Stuart Lynn
President and Chief Executive Officer
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA


via email

Dear Mr. Lynn;

I write on behalf of Tucows in response to Roger Cochetti of Verisign Inc.'s letter dated July 16th, 2001 and to outline Tucows' concerns regarding the letter and the issue of registrar-to-registrar transfers.

At the outset, I wish to emphasize Tucows' belief that this issue is not about transfers between registrars but about the ability of registrants to conduct their affairs efficiently and effectively in a secure and reliable environment. The often unspoken secondary concern, which is of interest only to the registrar community, is the impact of transfers on each registrars market share.

Easy transfers facilitate competitiveness in the market and accordingly benefit consumers1, requiring registrars to court clients on the basis of service and price. Reduced transaction costs benefit consumers by allowing them to easily change their suppliers in order that they may appropriately manage their affairs2. This has all been achieved in a highly secure fashion without fear of "slamming".

Analogies to the telephone business are neither helpful nor accurate. A domain name is neither dial tone nor a telephone number. IP connectivity is the closest analog to dial tone. An IP address is the closest analog to the phone number, which the DNS was designed to mask for the benefit of the end-user. And "slamming", the practice of switching a telephone service provider without authorization, has not been occurring, as we shall see.

Based on their statements and actions, Verisign appears confused as to why the world is not conforming to what has become an antiquated domain registration model. It is no longer the norm that there be a direct service relationship between the registrar and registrant. In today's world, the registrant often contracts with the registrar through a series of intermediaries.

The policy on domain name transfers, as expressed in Exhibit B to the Verisign Registrar License & Agreement3 facilitated competition and was originally drafted to minimize the residual power of the incumbent monopoly. Transfers went through unless the losing registrar had specific objections. It appears that Verisign and Register.com adhered to this policy until they began to be seriously concerned about significant numbers of net outbound transfers. In response, they have instituted practices designed to slow the erosion of their customer base by any means.

Dealing with the assertions of Mr. Cochetti's letter

Let us clarify our points of agreement with Verisign:

"These new procedures should make the interests of customers paramount, and ensure that the customer's choice of a registrar is respected and protected." Agreed. We believe that the current transfer policy and the realities of paying for a transfer ensure that the will of the customer is carried out.

"They should also require the use of technology tools that permit the most efficient approaches to verifying customers' intentions." Agreed. We believe that laying money on the deal is the most effective verification. Registrars are almost uniform in requiring payment before requesting a transfer.

Our agreement ends with these two passages.

Tucows is convinced that improper transfers are not occurring in the epidemic proportions that Verisign would have us believe exists.

Registrars that have arbitrarily extended the influence of their transfer processes have done so under the pretext that a significant number of domain name transfers have been unauthorized.

Lack of authorization by registrants is presumed to have occurred by Verisign when the official name holders have claimed to be unaware that they have moved away from Verisign.

Mr. Cochetti offers three "studies" to support the basis of Verisign's claims that unauthorized transfers have occurred.4 The methods used and the results obtained by these studies have never been subject to public scrutiny5. We have requested copies, but have not been provided with same. We have also communicated to Verisign on numerous occasions that we would be happy to work with them on any specific transfers that they feel were unauthorized.

It is interesting to note that, as of the ICANN-Stockholm meetings, Dan Halloran of your office had received no complaints about the practice of slamming6.

Versign's study was self-interested and accordingly has no probative value. While we cannot analyze data that we are not privy to, we can discuss the authorizations of 32 supposedly problematical transfers, which Verisign requested us to confirm as described in Mr. Cochetti's letter. He explicitly stated that the registrar's responses to Verisign's inquiry were tardy, inconclusive and/or "peculiar". Tucows responded within 24 hours, with documentation showing the SLD registrant of record, the registrant contact person, the email address of confirmation, the date of original request to transfer, the date of authorization to transfer, the IP address whence came the confirmation; the date the request was filed with the registry, and a unique identifier number.

In order to confirm that these transfers were indeed legitimate, Tucows successfully contacted 19 of the 32 transferors over the past few days to inquire whether they knew they had left Verisign, why they left, and whether they knew their new registrar was Tucows7. 18 have responded. In each case, the registrant, or their agent, knew that they no longer had a business relationship with Verisign pursuant to the transfer. As to whether they knew which registrar they were going with, their answers were extremely clear. Either they were aware they had moved to a reseller supplied on a wholesale basis by the Tucows registrar operation and were happy with that decision or the transfer was initiated by an agent who subsequently supplied Tucows with verification of their authority to transfer the domain.

Most of them have supplied reasons for their transfer that would embarrass Verisign, such as "badly designed website," "why pay $35 when you can pay less?," "I will never deal with their service people again." We note that these are the people who Mr. Cochetti claimed confirmed twice they did not know. We also note that this clearly discredits the use of the studies referred to as justification for the policies adopted by Verisign.

"As a consequence, [of the discredited survey data]" wrote Mr. Cochetti, "we believe that it is now time for the ICANN community to address this problem and define the procedures under which registrants can transfer their registrations from one registrar to another, and be assured that their rights are protected."

The difference between the registrars and Verisign is that we believe such procedures and protections already exist, and that they simply need to be enforced.

The way forward

We are very concerned that a minority of influential registrars is intent upon overriding and circumventing ICANN's processes of policy formation. In Tucows' view, adoption of a default n'ack procedure changes the plain intention of the NSI-Registrar License and Agreement, which favors customer choice without compromising security, to require an expensive, inconvenient proof from the customer, of a decision that has already been confirmed. The domain name business seems to be reverting to procedures more suited to facilitating nineteenth century land transactions. We trust that ICANN is fully aware of how much is resting on the preservation and use of ICANN's bottom-up consensus process. This is an important test.

We have been working within the Registrars Constituency to move forward with a draft transfer policy proposal, take it up through the DNSO via the Names Council to ensure an appropriate consultation with the other constituencies. Ideally, this will conclude with the submission of a consensus policy to the Board of ICANN. That transfer policy will be quite simple and will likely retain the current language on transfers in reinforcement of the following principles:

  • The permission of the registrant must be obtained, and electronic conveyance of this permission to the gaining registrar is authoritative;

  • The losing registrar transfers when requested to do so by the gaining registrar;

  • The losing registrar has the right not to transfer for a specific, limited set of circumstances, which shall be enumerated. The losing registrar may request evidence of the authorization by the registrant for a specific, limited set of reasons;

  • The losing registrar shall accept the evidence of the authorization to transfer from the registrant, which shall be given to him by the gaining registrar when he is requested to do so.

There will be plenty of opportunity in the coming months to clarify these principles and add to them if necessary, both by the registrars and by the other constituencies.

What we seek from ICANN

1. Leadership

We seek ICANN's support for the processes that the vast majority of registrars have adopted. We are aware that ICANN claims no statutory power or governmental power. For that reason, it must exercise moral suasion and leadership. The Internet works by means of technical cooperation, and this time-honoured approach should also work in the DNS. The language of ICANN's articles of incorporation state:

"4. The Corporation shall operate for the benefit of the Internet community as a whole, carrying out its activities in conformity with relevant principles of international law and applicable international conventions and local law and, to the extent appropriate and consistent with these Articles and its Bylaws, through open and transparent processes that enable competition and open entry in Internet-related markets."

The Memorandum of Agreement between ICANN and the US Department of Commerce reminds us that ICANN was created in order to promote certain goals:

"2. Competition

This Agreement promotes the management of the DNS in a manner that will permit market mechanisms to support competition and consumer choice in the technical management of the DNS. This competition will lower costs, promote innovation, and enhance user choice and satisfaction.

 3. Private, Bottom-Up Coordination

This Agreement is intended to result in the design, development, and testing of a private coordinating process that is flexible and able to move rapidly enough to meet the changing needs of the Internet and of Internet users. This Agreement is intended to foster the development of a private sector management system that, as far as possible, reflects a system of bottom-up management."

The community is faced with a situation where market mechanisms may be slow to find a solution because the minority is using its influence to adopt a procedural approach to harm competition. This is a case where ICANN's intervention is appropriate.

Tucows believes that ICANN has a duty to consider the good of the whole Internet and the registrar/registry sector, and can instigate others to find a solution and expedite the consensus process. It is clear to us that without it, gaining consensus on this issue will be inexorably stalled to the detriment of Registrants.

2. A quick response to the Registrars' Letter

Acting on behalf of the Registrars Constituency, Michael Palage has, or will shortly, write you seeking a finding as to whether the issue is procedural, and might be solved without the development of a consensus policy, or one that requires a consensus policy. The Registrars need an indication, if you can give one, of the path to follow and the reasons why one might be preferred over another.

3. Require Verisign enforce the default transfer position

Tucows believes that the ICANN staff can instruct the gTLD registries to specifically enforce a "default ack" procedure pending the outcome of the consensus policy process. It is our belief that you have the full power to make this interim request based on the authority provided ICANN in its bylaws and the Joint Project Memorandum with the DOC. The current process employed by Register.com and Verisign is not consistent with ICANN's requirement to "promote[s] the management of the DNS in a manner that will permit market mechanisms to support competition and consumer choice in the technical management of the DNS. This competition will lower costs, promote innovation, and enhance user choice and satisfaction."

Further, by adopting arbitrary and unilateral policy that was clearly developed outside of the ICANN process, these registrars are working against the critical contractual requirement that ICANN "foster the development of a private sector management system that, as far as possible, reflects a system of bottom-up management.

If this issue continues to move forward as consensus policy, the Names Council will soon be involved. Requiring this interim procedure will allow the Names Council to carefully consider this issue and fully assess the input from all constituencies in order that they may make a considered policy recommendation to the ICANN Board in time for the ICANN-Montevideo meetings

In conclusion, ICANN needs to defend the integrity of itself and its processes here. This is a dispute among the principals who act as an important interface to the DNS. It is going to take your intervention and leadership to see us through

Yours sincerely,



Ross Wm. Rader
Director, Innovation & Research
Tucows Inc.

cc:

ICANN DNSO Names Council
ICANN Registrars Constituency
ICANN General Assembly


Attachment A - Customer Impact

If there are any doubts as to the impact and degree this issue is affecting users of the name space, we have compiled a sample of some of the email traffic Tucows has received regarding the aggravations that both current and former customers of Verisign have had in transferring away from them. It seems that there are two sources of aggravation.

    Complex transfer procedures, involving limited or non-existent periods during which the registered owner must respond to emails from Verisign, and in some cases;

The alleged charging of renewal fees before the expiry of the original term of the contract.

Coupled with what some customers experience as aggravating technical failures, the result is not producing customer satisfaction.

"NSI is rejecting our transfers. We have seen this lately on about 50% of our transfer attempts. This is obviously NOT accidental. Prior to initiating legal action I am asking Tucows to 'investigate' the problem. Here is what appears to happen. We submit a transfer request to Tucows. We respond to the (Tucows) email by logging in and approving the transfer. We receive an email from NSI. We respond positively to that email. A few days later we receive an email from NSI informing us that the transfer was not confirmed. We then have to start over and resubmit the original transfer. We have submitted our complaints to NSI (more than once) and have received an email form letter. There was one follow up email in which they apologized and told us to resubmit the transfer. I do not believe that these actions are accidental."

- Verisign Registrant (and Tucows Reseller)

"We are a reseller of your services and are very pleased to be able to offer this service to our customers.  Approximately three weeks ago, I attempted to transfer a domain, actually owned by my company, from Network Solutions to Tucows.  It is expiring in August, so the need to move quickly was becoming important.  I sent in a request to Tucows, received a request to authorize the change from Tucows, and then authorized the change.  This was on I believe a Wednesday morning.  Apparently on Friday afternoon (late enough in the day that I did not see the E-mail), I received an authorization request from Network Solutions.  By Monday morning, when I read the mail, the authorization request had expired and I had to wait and re-initiate the whole process again.  This, by the way, was for a domain name owned by my company. 

I recently transferred another name owned by my company, but this time I was ready.  The E-mail came again late in the day, but I was watching for it and caught it before it expired. 

Network Solutions seems to be awfully concerned about giving a tiny window of time to authorize a transfer."

- Tucows Reseller and Verisign Registrant

[Here is the correspondence between the] "registrant and NSI for confirming this transfer to us.  Despite the confirmation on-time, the transfer was denied.

- Tucows Reseller


"I just received this.  I have e-mailed you my response.  I e-mailed them their confirmation with the correct numbers etc. they wanted me to insert.  Now they are saying I didn't.  Why are they jerking me around?"

- Verisign Registrant


"This may not be "denied" but it did fail because NSI was too slow."

- Tucows Reseller

"One of my customers requested to transfer his domain xxxx.COM a week prior to the end of his current registration period with NSI.  During the transfer confirmation period, he received the following message from NSI. It seems that NSI is holding his domain hostage to get another years worth of money out of him for no reasons. The registrant confirmed the transfer request prior to his expiration period, i.e. 12 June 2001. Can you advise and interfere with NSI to release the domain to OPENSRS."

- Tucows Reseller

"Repeatedly over the last two weeks we have had domains time out awaiting registry approval. Now we have 4 more about to expire as their 9 days is up and they still have not been approved by Network Solutions. Should we cease accepting transfer until such time as OpenSRS can assure that NSI will actually approve transfers which meet all requirements in their request. Apparently all we are doing now is billing and refunding customers, causing ill will over tying up their domain for a couple weeks."

- Tucows Reseller

"Somehow I feel something is wrong here as nothing has yet happened. I have transferred many domains from networksolutions to you-never has it been more than hours or maximum a day. The domain management option does not work for me and as I see networksolutions still has my domain."

- Verisign Registrant to a Tucows Reseller

"NETWORKS SOLUTIONS IS PLAYING SOME STUPID GAMES. THIS IS THE THIRD TIME THEY ARE FAILING TO MAKE A CHANGE.  WHAT CAN WE DO ABOUT THIS.  DO I NEED TO CONTACT MY ATTORNEY?"

- Verisign Registrant to a Tucows Reseller

"NSI is rejecting our transfers. We have seen this lately on about 50% of our transfer attempts. This is obviously NOT accidental. Prior to initiating legal action I am asking Tucows to 'investigate' the problem. Here is what appears to happen. We submit a transfer request to Tucows. We respond to the (Tucows) email by logging in and approving the transfer. We receive an email from NSI. We respond positively to that email (example below). A few days later we receive an email from NSI informing us that the transfer was not confirmed. We then have to start over and resubmit the original transfer. We have submitted our complaints to NSI (more then once) and have received an email form letter. There was one follow up email in which they apologized and told us to resubmit the transfer. I do not believe that these actions are accidental."

- Verisign Registrant (and Tucows Reseller)

"Great, I just got 3 more domains back today that they denied xfers and never sent me an ack email.


Also,  If they are putting people on an unpaid status when they send an invoice that seems to violate basic GAAP (accounting) principles. The idea here is how can you put me in an unpaid status when my prepaid account has not expired?"

- Verisign Registrant

"Please be advised that those rat bastards over at network solutions denied [this transfer], despite the fact that I inititated it, and of course they continue to incessantly spam me about their supposedly new TLD's. In fact, it has gotten so bad that I have changed my general email address to [deleted] and forwarded it from [deleted] to yahoo?"

- Verisign Registrant

"I sent a transfer request for the domain [deleted] and got a message from NSI to confirm that transfer within 3 calendar days so I sent them a confirmation but I received another mail dated 2 days after they sent the original message that the transfer was denied, and then I tried again but of coarse it was denied that I must pay first their invoice, what shall I do now?"

- Verisign Registrant

"NetworkSolutions recently denied a transfer for a customer of mine because my customer didn't answer their redundant email within the allotted time. After consulting with support@opensrs.net, I was informed of this second required step, and let my customer know to keep an eye on his email for the second transfer confirmation. This process only served to annoy my customer, as he had to re-request the transfer, and then go through an added step.  I think network solutions should be held liable for needlessly delaying the transfer."

- Tucows Reseller

"At the moment I am loosing business here... what was a quick and efficient system to transfer domainnames, has become now a burden both for the client and me.

In three individual cases, transfers have gone wrong in the past 14 days or so. Maybe you will value 'only' three as not much; however, we work with clients very closely together to disseminate their information, which is sensitive and part of international civic activities, and they choose me as provider because they trust me to seek out good, cheap and fast ways to get done what needs to get done. Tucows OpenSRS fits in that category, but now with the new policy of NSI, things are a lot more difficult, especially because at the client side, un-understandable things have to be done (like replying to the NSI guardian mails)."

- Tucows Reseller

"We have experienced great difficulty in transferring domain names from Verisign to Tucows.

It is nearly always the case that when a domain name is one or two months away from its renewal date that the transfer request "times out" at the Losing Registrar (Verisign).

This happens until Verisign issue an invoice for the domain name 30 days before the renewal date. Then the only option we have is to lose another $35 dollars to Verisign so that we can then transfer the domain name to Tucows. This is despicable, money grabbing behavior."

- Verisign Registrant and Tucows Reseller

"Even if we start the transfer process before the expiration date, or due date of their bill, they are refusing the transfer because it is in an unpaid status at their end. They refuse to listen to reason and they refuse to release the domain to the new registrar."

- Tucows Reseller

"NSI denied one request based on a claim that the domain owner did not approve the some non-existent request. They sent the following email, yet this domain owner swears he NEVER got any request to approve the transfer. My customer can't be held to approve some request he never got. This is absurd. Either NSI is technically inept or devious or both."

- Tucows Reseller

"At the beginning of July, a long time trusted customer with [reseller] submitted these domain names as transfers through our online registration system.  This registration system has been custom designed by [reseller] to meet our customers specific needs, but is built on the OpenSRS RCI API.

The customer promptly paid for the three transfers via our online credit card payment system.  The system, also using the OpenSRS API automatically submitted the transfers.  Within a few hours, the registrant had confirmed the three domain names by following the instructions contained in the e-mails he received at the Administrative Contact e-mail address from OpenSRS.

9 days elapsed and the three domain names had the status of 'Pending Registry Approval'.  They timed out due to lack of registrar response.

After contacting our long time trusted customer inquiring as to the status of the e-mails he should have received from NSI using their own approval system - he claims he NEVER received such transfer notices. NOTHING at ALL from NSI.  The only notices he received were from OpenSRS, which he responded to promptly.

We then submitted the transfers AGAIN.  He approved the OpenSRS notices immediately, he STILL hasn't received any NSI notices at ALL.  The second attempts were made 7 days ago...

So let's sum it up here.  The Verisign Registry is manipulating ICANN with this 'hate mail' obviously directed towards Tucows/OpenSRS.  They claim you are transferring domain names without registrant's permission so they were 'forced' to implement the new approval policy, which is of course rather redundant and just confuses the customer MORE.  But let's just hold on a little minute here, they aren't actually SENDING THESE THINGS OUT! Heh, wow, I thought they were making ENOUGH money still charging $35.00 USD/Year, but now they are not even sending out such approval notices, so it's impossible for them to lose a customer!  Talk about MONOPOLY."

- Tucows Reseller



Attachment B - Verisign Registry Transfer Policy

Exhibit B

Policy on Transfer of Sponsorship of Registrations Between Registrars

 

Registrar Requirements.

The registration agreement between each Registrar and its SLD holder shall include a provision explaining that an SLD holder will be prohibited from changing its Registrar during the first 60 days after initial registration of the domain name with the Registrar. Beginning on the 61st day after the initial registration with the Registrar, the procedures for change in sponsoring registrar set forth in this policy shall apply. Enforcement shall be the responsibility of the Registrar sponsoring the domain name registration.

For each instance where an SLD holder wants to change its Registrar for an existing domain name (i.e., a domain name that appears in a particular top-level domain zone file), the gaining Registrar shall:

1) Obtain express authorization from an individual who has the apparent authority to legally bind the SLD holder (as reflected in the database of the losing Registrar).

a) The form of the authorization is at the discretion of each gaining Registrar.
b) The gaining Registrar shall retain a record of reliable evidence of the authorization.

2) In those instances when the Registrar of record is being changed simultaneously with a transfer of a domain name from one party to another, the gaining Registrar shall also obtain appropriate authorization for the transfer. Such authorization shall include, but not be limited to, one of the following:

a) A bilateral agreement between the parties.
b) The final determination of a binding dispute resolution body.
c) A court order.

3) Request, by the transmission of a "transfer" command as specified in the Registry Registrar Protocol, that the Registry database be changed to reflect the new Registrar.

a) Transmission of a "transfer" command constitutes a representation on the part of the gaining Registrar that:

(1) the requisite authorization has been obtained from the SLD holder listed in the database of the losing Registrar, and
(2) the losing Registrar will be provided with a copy of the authorization if and when requested.

In those instances when the Registrar of record denies the requested change of Registrar, the Registrar of record shall notify the prospective gaining Registrar that the request was denied and the reason for the denial.

Instances when the requested change of sponsoring Registrar may be denied include, but are not limited to:

1) Situations described in the Domain Name Dispute Resolution Policy
2) A pending bankruptcy of the SLD Holder
3) Dispute over the identity of the SLD Holder
4) Request to transfer sponsorship occurs within the first 60 days after the initial registration with the Registrar

In all cases, the losing Registrar shall respond to the e-mail notice regarding the "transfer" request within five (5) days. Failure to respond will result in a default "approval" of the "transfer."

Registry Requirements.

Upon receipt of the "transfer" command from the gaining Registrar, the Registry will transmit an e-mail notification to both Registrars.

The Registry shall complete the "transfer" if either:

1) the losing Registrar expressly "approves" the request, or
2) the Registry does not receive a response from the losing Registrar within five (5) days.

When the Registry's database has been updated to reflect the change to the gaining Registrar, the Registry will transmit an email notification to both Registrars.

Records of Registration.

Each SLD holder shall maintain its own records appropriate to document and prove the initial domain name registration date, regardless of the number of Registrars with which the SLD holder enters into a contract for registration services.


Notes:

1 Tucows previously outlined its prior position on this issue in a formal statement to the DNSO Registrars constituency that can be found at http://www.dnso.org/clubpublic/registrars/Arc01/msg00706.html

2 In order to ensure that the extent of the negative customer impact is appropriately understood, we have reproduced a compilation of complaints filed by registrants and resellers as Attachment A to this document.

3 Reproduced for your convenience as Attachment B to this letter.

4 First, a telephone survey; second, a more formal telephone survey by a research firm; and third, a set of inquiries made to the larger gaining registrars about the time of the Stockholm ICANN conference.

1. "These initial surveys, conducted in the Fall and Winter of 2000-2001, produced strong statistical evidence that as many as one of three of the customers who were reported to have authorized a transfer from the Verisign Registrar to another registrar were actually customers who had not made any such authorization."

2. "The research firm contacted a statistically representative sample of over 800 former Verisign Registrar customers during May and June of this year. They found that over 24% did not ever request to be transferred out of the Verisign Registrar and nearly one third indicated they did not even know that they had been transferred out from the Verisign Registrar (based on combined responses of those who did not request transfers, as well as those who were unaware that their accounts had indeed been transferred) This failure to obtain express authorization may have resulted from what is known in the telecommunications industry as "slamming"-transferring customers to their registrar without any notification whatsoever."

3. "More recently, to further understand and document the problem, the Verisign Registrar contacted the five largest gaining registrars as disclosed by the above-noted surveys, requesting individual verification (as provided under the Registry-Registrar Agreement) of a sample population of 140 transfers from the past twelve months."

(As per Cochetti's letter).

5 Although Verisign claims that the telephone survey they conducted was made available to ICANN last year.

"Wolford said the survey results are the only thing competitors will see, unless ICANN decides to release the results in the future. Officials at the governing body were given the detailed reports last year."

- Internet News, July 20, 2001

(http://www.internetnews.com/isp-news/article/0,,8_805601,00.html)

One can only assume they are referring to the results of last year's telephone survey as feedback from the registrants surveyed indicated that Verisign first contacted them concerning their transfer of registration only a few short months ago.

Feedback from these discussions also discovered that the surveying party did not specifically identify themselves as a representative of Verisign and that the registrant was under the impression that they were undertaking a discussion with a representative of Tucows.

6 On Tue, 24 Jul 2001 17:28:19 -0700 Dan Halloran clarified his remarks (the complete text of which can be found at http://www.dnso.org/clubpublic/registrars/Arc01/msg00894.html ). He specifically indicated

"My statement in Stockholm that I "was not aware of any complaints that ICANN had received about domain name slamming" referred only to my own knowledge, and to complaints by losing registrars.  In fact ICANN has received reports of unauthorized transfers (usually associated with domain "hijacking.")"

It is important to note that the terms "hijacking" and "slamming" represent two completely different behaviors. "Hijacking" is a behavior undertaken by a rogue end-user and "slamming" is a behavior undertaken by a registrar. "Hijacking" usually occurs when a registrar is duped by a "hijacker" into changing the contact records for a domain name to allow the "hijacker" to essentially take possession of the domain name. If the "hijacker" then transfers the domain name to another registrar in an attempt to cover his or her tracks, then the gaining registrar will naturally approve the transfer. This is due to the fact that the records of the losing registrar (which the gaining registrar relies on being accurate) have been falsified.

Further to this point, while rare, it has been documented that registrars have undertaken a transfer without a registrants consent due to administrative error by the registrar. In all cases that Tucows has been aware of, the problem was resolved quickly and without injury to the registrant. Accordingly, it is difficult to classify these incidents as "slamming" as well.

7 Specifically, each registrant was asked;

a) [example.sld] was initially registered with Network Solutions. Is this also your understanding?

b) The domain name is currently registered through another registrar. Is this also your understanding?

c) (If yes) Did you specifically initiate this transfer?

d) (If yes) Roughly when did you undertake this transfer?

e) (If yes) To whom did you transfer the registration to?

f) Were you aware when you undertook this transfer that you would no longer have a formal business relationship with Network Solutions as it relates to this specific domain name?"


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 02-Feb-2012
(c) 2001 The Internet Corporation for Assigned Names and Numbers All rights reserved.