Skip to main content

Contractual Compliance Monthly Update | Issue 10

Cartagena, Colombia
Cartagena, Colombia: Location of ICANN's upcoming 39th International Meeting


This Newsletter is to inform readers and encourage community dialogue regarding ICANN's contractual compliance program. For more information please see link to past newsletter archive:

Important Updates:

The ICANN Registrant Protection Performance tracker has been updated. Go to and click on Registrant Protection to see how ICANN's Contractual Compliance department has been working for you.


We are soliciting questions/topic ideas that you would like to see reported in future newsletters. Please forward all questions/topic ideas to:

1. UDRP Compliance Update

Complaints for Failure to Implement UDRP Decisions

ICANN is pleased to report an upward trend in registrar compliance with the UDRP. Throughout the latter part of 2009 and continuing through July 2010, ICANN observed fewer complaints concerning registrars failing to implement UDRP decisions. At the same time, the number of UDRP decisions increased or remained steady. ICANN tracks cases in which prevailing complainants accuse registrars of failure to implement Provider decisions. During the first seven months of calendar year 2010, ICANN received two to four of these complaints per month. This is down from data from January 2009 through July 2009, when ICANN received on average seven to twelve of such complaints per month.

ICANN attributes the decrease in complaints to several factors. Some factors include registrar outreach and education, enhanced compliance tools such as the UDRP Intake Response System, and stricter monitoring and enforcement of UDRP compliance.

When ICANN is made aware of UDRP noncompliance, ICANN immediately contacts the concerned registrar. During this initial contact, ICANN requests the registrar provide data to justify not implementing the decision. In cases in which the registrar cannot justify its position, usually this contact is sufficient to bring the registrar into compliance. If not, ICANN sends a formal escalated compliance notice. In rare instances when registrars still fail to comply, ICANN issues a breach notice to the registrar. Failing to remedy a breach notice for failure to comply with the UDRP is a strong factor in favor of terminating a Registrar Accreditation Agreement between ICANN and the registrar.

ICANN also receives complaints alleging a registrar failed to implement a decision, when the registrar has in fact transferred the name to the prevailing complainant. Often the complainant is seeking to transfer the name to another registrar, but has not communicated that to the registrar. If a prevailing complainant seeks to transfer a name, then the complainant should notify the registrar and follow the Policy on Transfer of Registrations between Registrars (also known as the Inter-Registrar Transfer Policy) available at

ICANN looks forward to continuous improvement in registrar compliance with the UDRP.

2. Registrar Compliance with Inter-Registrar Transfer Policy

Transfer problems most consistently top all consumer complaints received by ICANN. Usually, they represent 20-30 percent of complaints that ICANN processes. To address this issue, an IRTP Audit Plan was designed and developed by Contractual Compliance with input and feedback from a number of key registrar representatives and various ICANN departments and a beta test on the IRTP Audit Plan was conducted in May 2010.


The primary purpose of the beta audit is to determine if the IRTP Audit Plan is methodologically and operationally sound. It was also designed to:

  • Gain a better understanding of the actual transfer problems encountered by consumers;
  • Gauge the level of registrar compliance with the IRTP; and
  • Raise registrar awareness of their obligations under the transfer policy and encourage future compliance.

Audit notices were sent to registrars who were subject to the beta-audit by both email and fax. A copy of the IRPT Audit Plan was attached to the audit notice.


Due to the vast number of transfers occurring each month and the large number of registrars involved, it was not feasible to examine each transfer transaction or each registrar's transfer practices. Instead, random selection mechanisms were used to select four groups of registrars to be audited:

  1. Transfer-losing-registrars with NACK rates exceeding 20% (maximum of 10 registrars)
  2. Transfer-gaining-registrars with NACK rates exceeding 40% (maximum of 5 registrars)
  3. Five registrars who received the most complaints by number
  4. Five registrars who received the most complaints by ratio ( see the calculation set out in the IRTP Audit Plan)

Selection of groups 1 & 2 registrars was based on VeriSign's transactional report for the month of December 2009, while selection of groups 3 & 4 registrars was based on data from ICANN's C-ticket system for the month of March 2010. Using these two sets of data and the selection mechanisms, a total of 17 registrars were subject to the beta audit.

The total number of domain names sponsored by these 17 registrars was 71,491,626 (this represents 63% of total gTLD registrations of 113,802,218, as of 31 May 2010).


Eight registrars provided the information on or before the deadline of 24 May 2010, while others required one or two reminders. By 4 June 2010 all provided the information requested. All but one registrar were requested to provide ICANN with additional clarifications or information.

The table below is a summary of the findings based on the 4 registrar groups:

Group Description Registrars Audited Transfers/ Complaints Selected per Registrar Registrars Deemed Compliant* Registrars Deemed Non-compliant Compliant registrars by % in Group
1 Losing 4 10 or actual 2 2 50%
2 Gaining 5 10 or actual 5 0 100%
3 Complaints by number 4 5 2 2 50%
4 Complaints by ratio 4 5 3 1 75%

A registrar is deemed compliant if each of its transfer transactions that were subject to the audit was considered in compliance with the IRTP.

Of 119 transfer transactions reviewed, 27 were deemed non-compliant with the IRTP. This translates to 77% of transactions being compliant.

Most transfer-related complaints that were subject to the beta audit concerned either delays/inabilities to obtain the AuthInfo Code, or domains still locked by the registrar of record. The problems seem more prevalent when resellers are involved.

Based on the response provided by groups 3 & 4 registrars, ICANN noted that some of the delays were caused by authentication or validation processes employed by registrars. ICANN recognizes the need for authentication of the Registered Name Holder who requested the AutoInfo Code, but registrars must also be mindful of their obligation to provide the Code within five calendar days of the initial request.

They must also ensure that they do “not employ any mechanism for complying with a Registered Name Holder's request to obtain the applicable “AuthInfo Code” that is more restrictive than the mechanisms used for changing any aspect of the Registered Name Holder's contact or name server information” (see paragraph 5 of the IRTP).

Follow-up Actions:

ICANN has stated in its beta audit notice to registrars that “the findings of these beta-test audits are for information only and will not be used as the basis for enforcement action.”

Accordingly, ICANN does not intend to take “formal” compliance or enforcement action against those registrars that are deemed non-compliant with the IRTP or the RAA but Contractual Compliance staff has informed them of their non-compliance and worked with them to help bringing them into compliance with their IRTP obligations.

In addition, the beta audit has alerted a number of registrars about the deficiencies in their business practices and processes. Additional investigations may occur. The beta-audit has prompted a number of registrars to take the initiative of reviewing and/or improving their transfer practices.

Below are some of the comments received from registrars:

Comment from a group 1 registrar:

Your beta testing request alerted us to the high rate of Nack in December 2009 …our use of Nacking was not compliant with ICANN IRTP in December 2009. We have now reviewed our current procedures in order to correct this situation.”

Comments from two group 2 registrars:

“..., this process has highlighted to me some weaknesses in how we maintain this information.

The audit exercise has highlighted a couple of issues for us:

  • The way that our data records are labeled (we gave you invalid details as a result)
  • The way that our system automatically re-attempts to transfer a domain that has been NACKed. (We shouldn't be doing this).

I am actively addressing both of these issues within our organization to rectify immediately.

Comments from two group 3 registrars:

We have paid close attention to this matter and discussed the measures to let our transfer policy to comply with the ICANN Inter-Registrar Transfer Policy. There may be a period for us to make a new transfer policy and adjust our system.”

If our transfer process as described above needs change or improvement, please let us know and we will do our upmost to become compliant as soon as possible.”

Comment from a group 4 registrar:

We will introduce a “3 strikes, you are out reseller policy” to make sure our resellers respond to customers' requests for EPP codes in time, as required by the IRTP.”

Further changes to IRTP Audit Plan after the beta audit and formal audits:

A registrar in group 1 suggested some changes to the requested documents/information (as set out in the IRTP Audit Plan). ICANN will incorporate those suggestions, in addition to some changes for clarity in light of registrars' responses to the beta audit. ICANN plans to conduct two rounds of formal audit in accordance with the updated IRTP Audit Plan, with one during the remainder of 2010 and one in the first half of 2011.

3. Contractual Compliance Advisories

In order to help registries and registrars understand their contractual obligations, this newsletter will occasionally include advisory information intended to clarify RAA and Registry Agreement provisions.

For more information please see link to the RAA:

Updating Public and Primary Contact Information

  • Section 3.16 of the RAA requires registrars to provide on their web sites accurate contact details, including a valid email and mailing address.
  • Section 5.11 of the RAA states that all primary contact information updates must be made in writing and faxed, delivered in person, or sent via an internationally recognized courier service to ICANN.

It is important for registrars to keep their primary and public contact information up-to-date. Registrars can update their public contact information online by logging into the ICANN registrar database at Primary contact information cannot be updated online and must be done in writing, using a form available when registrars log into the registrar database.

4. Outreach Efforts

World Map


Asia Pacific:

Pam Little, Senior Director, Asia Pacific attended the INET Asia Regional Conference held in Hong Kong on 13-14 April 2010. The theme of the conference was “the opportunities and challenges in the next generation Internet.” After attending the conference, Pam travelled to Xiamen, China and held meetings with three registrars: OnlineNIC Inc., Xiamen eName Network Technology Co. Ltd. and HooYoo Information Technology Co. Ltd.

The Asia Pacific Event of ICANN-Accredited Registrars and gTLD Registries was held in Tokyo, Japan on 26-27 August 2010. Further details of the event and the presentations by Contractual Compliance and others are available at

The Beijing Office of Asian Domain Name Dispute Resolution Centre hosted a conference on Domain Name Dispute Resolution in Beijing on 15 October 2010. Pam Little gave a presentation on “the role of registrars in the domain name dispute resolution process.” Pam also took the opportunity to meet and discuss transfer issues with two ICANN-accredited registrars in Beijing.”


Contractual Compliance staff also conducted a workshop on the Whois Data Accuracy Study conducted by NORC and made presentations to the following stakeholder groups' meetings during ICANN's 38 th International Meeting in Brussels in June 2010:

  • ALAC Policy Issues Discussion Part 1 Meeting
  • Registrar Stakeholder Group
  • CBUC Meeting
  • IPC Meeting


Latin America:

Information regarding ICANN's Contractual Compliance Program, such as compliance statistics, updated audit schedules and audit results, will be shared with meeting attendees at ICANN's 39 th International Public meeting in Cartagena, Colombia, 5-10 December 2010.

5. Consumer Complaint Update

Consumer Complaint Analysis: January-September 2010. Total Complaints - 8,468

ICANN has a C-Ticket System (see ) that captures and tracks complaints filed by the general public. The chart above provides details concerning the categories and number of complaints processed during the first nine months of 2010.

ICANN follows up on all complaints received regarding suspected RAA violations and Registry Agreement violations.

ICANN does not, however, have contract authority to address complaints regarding content, SPAM, data protection, web hosting, data privacy, and financial transactions.

Instead, ICANN forwards complaints to the appropriate parties for handling. ICANN encourages each party to investigate the complaint and report its findings to the complainant and ICANN.

ICANN is working with law enforcement authorities to assist, when possible, in their investigations and prosecution of domain name abuse.

6. Recent Staff Changes

There have been some staff changes within ICANN's Contractual Compliance department.

William McKelligott, Senior Auditor, resigned from his position in May 2010. Senior Director David Giza also left the company in July 2010.

A comprehensive search for their replacements has begun, and in the interim, Pam Little, the Senior Director, Asia Pacific, is acting as head of the department.

In addition, ICANN is also searching for a Contractual Compliance Manager who will be primarily responsible for a WHOIS compliance program. This is a newly created position reporting to the Senior Director of Contractual Compliance and the position will be based in Marina del Rey, CA.

7. Contacts

Below are the current members of ICANN's Contractual Compliance department:

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."