Ross
Wm. Rader July 25, 2001 Mr. Stuart Lynn
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 letterLet us clarify our points of agreement with Verisign:
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:
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 ICANN1. LeadershipWe 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 cc: ICANN DNSO
Names Council 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.
Coupled with
what some customers experience as aggravating technical failures, the
result is not producing
customer satisfaction.
- Verisign Registrant (and Tucows Reseller)
- Tucows Reseller and Verisign Registrant
- 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
- Tucows Reseller
- Tucows Reseller
- Tucows Reseller
- Verisign Registrant to a Tucows Reseller
- Verisign Registrant to a Tucows Reseller
- Verisign Registrant (and Tucows Reseller)
- Verisign Registrant
- Verisign Registrant
- Verisign Registrant
- Tucows Reseller
- Tucows Reseller
- Verisign Registrant and Tucows Reseller
- Tucows Reseller
- Tucows Reseller
- 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. 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. 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 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 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 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." (As per Cochetti's letter). 5 Although
Verisign claims that the telephone survey they conducted was made available
to ICANN last year.
(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
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;
Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.
(c) 2001 The Internet Corporation for Assigned Names and Numbers All rights reserved. |