Skip to main content
Resources

IRTP Enforcement

In September 2010, ICANN conducted the first formal Inter-Registrar Transfer Policy ("IRTP") audit to assess registrar compliance with the policy, following a beta audit conducted earlier in May 2010. The report on the formal audit was posted in December 2010 at ICANN Contractual Compliance's webpage: http://www.icann.org/en/compliance/reports/irtp-audit-report-13dec10-en.pdf [PDF, 298 KB].

In this formal audit, we found nine (9) registrars deemed non-compliant with the IRTP. However, one of them turned out to be caused by a confusion over the use of terminology, which has since been clarified so the total number of non-compliant registrars now stands at eight (8).

On 20 January 2011, all 8 registrars were issued a non-compliance notice. Each notice set out the specific reasons for ICANN's assessment and requested the registrar to submit a proposed corrective action plan by 15 February 2011. Except one registrar that has not responded to ICANN, 7 registrars have responded with proposed action plans on or before the deadline of 15 February and all of them have implemented or in the process of implementing their proposed action plans.

Summary of ICANN's assessment and registrars' responses:

Rr # Rr Role Reasons for ICANN's Assessment Corrective Action Plan Proposed Corrective Action Plan Implemented
1 Losing registrar Wrongfully denying transfer requests based on non-payment of fees for pending or future registration periods during the Auto-Renew Grace Period Yes Yes
2 Losing registrar Wrongfully denying transfer requests on the basis that there was no affirmative confirmation from registrants Yes Yes
3 Gaining registrar Initiating transfers without FOAs No No
4 Gaining registrar Initiating transfers without FOAs Yes Yes
5 Registrar of record Employing "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." Yes Yes
6 Registrar of record Failure to provide "AuthInfo Code" within 5 calendar days due to reseller issues Yes TBA
7 Registrar of record Failure to provide "AuthInfo Code" within 5 calendar days due to reseller issues Yes March 2011
8 Registrar of record Failure to provide "AuthInfo Code" within 5 calendar days due to reseller issues Yes Mid March 2011

The IRTP is intended to provide domain portability and better consumer choice. Consistent with this policy goal, ICANN will continue to closely monitor and actively enforce registrar compliance with the IRTP To this end, in addition to conducting regular audits, we will continue to follow up with registrars regarding complaints or alleged violations that are brought to ICANN's attention (for example, through ICANN's consumer complaint ticketing system http://reports.internic.net/cgi/registrars/problem-report.cgi).

We hope these ongoing compliance efforts will improve registrars' overall understanding of and better compliance with their obligations under the transfer policy.

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""icann.org"" is not an IDN."