Skip to main content

Contractual Compliance Monthly Update | Issue 1

About this Newsletter

Welcome to the inaugural ICANN Contractual Compliance Newsletter.

Each month, the newsletter will cover:

  • Enforcement statistics
  • An in-depth look at some part of the compliance process
  • Proactive compliance: audits and studies
  • New advisories for registries and registrars (if any; none in this issue)
  • Upcoming events

ICANN has been engaged in compliance work since its inception, and formed a dedicated compliance department in early 2007. Ensuring contractual compliance is a major ICANN community goal. Compliance on behalf of all contracted parties is a cornerstone of registrant protection. In general, contracted parties want to see tough and fair compliance to promote an even playing field among competitors. Business users of the Internet and intellectual property owners have a strong interest in breaches of ICANN contracts being actively pursued and quickly cured.

ICANN's goal is that this newsletter becomes an important way to continue community dialogue regarding contractual compliance. Please send your comments regarding the newsletter, and especially topics of interest you would like to see covered in the future to To subscribe to this newsletter, go to:

For more information about the Contractual Compliance Program mission and details, please visit

About Compliance at ICANN

ICANN enforces contracts with registries and registrars in order to protect domain name registrants and benefit Internet users as a whole. In addition to enforcing contractual compliance, the ICANN compliance function enforces decisions reached through the Uniform Domain Name Dispute Resolution Procedure (UDRP).

There are two primary sources of actionable information that lead to enforcement activities:

  • pro-active enforcement, e.g. surveys and compliance audits, providing advisories to registries and registrars to clarify their obligations and producing statistical information and reports about compliance;
  • responding to complaints received by phone and email, ensuring response systems like the Whois Data Problem Reporting System (WDPRS) are functioning well, and problems are being addressed.

When potential non-compliance is identified, ICANN:

  • establishes the facts and relevance to ICANN's contracts
  • resolves the issue at the lowest level where possible
  • escalates and resolve when necessary
  • follows up in all cases.

1. Enforcement Statistics

Consumer Complaint Analysis

ICANN records the number of complaints received by the Marina del Rey, California front desk and complaints lodged through ICANN's Registrar Problem Report form ( (Complaints are received in several languages at ICANN's Brussels office and other email addresses.)

A total of 639 complaints were processed in January 2008 and 422 complaints were processed in February 2008.

The five most frequently recorded complaint categories were:

  • Registrar Transfers
  • Reseller/Webhost issues
  • Whois
  • Registrar Customer Service
  • Domain Name Disputes

The table below shows how many of each type of complaint ICANN received in each of the top 5 categories during January and February, 2008.

2. The Compliance Process

Each month, the Compliance Newsletter will outline a portion of the compliance process in some detail. This first newsletter looks at the top-level view: proactive compliance activities, complaint response, and enforcement activities.

How ICANN enforces its contracts

Investigations into possible non-compliance are triggered by proactive enforcement activities or registrant complaints. When there is possible non-compliance, ICANN contacts the contracted party by email, and demands proof that the violation has been cured. Typically, 72% of initial enforcement notes result in corrective action by the registrar or registry, and no further enforcement action is required.

The table below shows how many enforcement notices were sent between October 2007 and February 2008.

Month Complaint Related Enforcement Notices Audit Related Enforcement Notices Total
February 2008 74 141 215
January 2008 106 996 1102
December 2007 180 954 1134
November 2007 8 37 45
October 2007 112 902 1114

If the Registrar does not provide proof of compliance after they have received a notice of non-compliance, ICANN initiates the breach process. This involves sending a notice of breach of contract. Roughly 75% of the time, registrars cure the breach cited in these notices within fifteen days as required by the Registrar Accreditation Agreement.

ICANN sent 171 breach notices to registrars between January 2007 and February 2008. The table of 164 notices sent in 2007 shows the increase in enforcement activity as the compliance efforts ramped up during 2007 with the creation of the Compliance department.

Quarter 2007 Breach Notices
Oct – Dec 76
Jul – Sep 59
Apr – Jun 28
Jan – Mar 1
Total 164

To summarise, 72% of non-compliance is resolved after an enforcement notice. Of the outstanding 27% at that stage, 75% come into compliance after they receive a breach notice. If the breach is still not cured, ICANN can escalate to terminating the registrar's accreditation with ICANN. Over the past five years, thirteen of these agreements have been terminated. On an ongoing basis, ICANN is accelerating efforts towards more rapid problem closure: cure of breech or termination.

Further improvements in compliance and enforcement in 2008 and beyond will come from a number of areas. Improved contracts (including amendments to the RAA under consideration now), additional resources, and improved, clear processes for compliance work. In 2007, ICANN developed a uniform process of escalation and enforcement for non-compliance. The next issue of this newsletter will look in more detail at how ICANN handles escalation and enforcement.

3. Proactive compliance: studies and audits

ICANN performs regular studies and audits regarding specific contract obligations and will provide information about findings in this newsletter as well as in the official, semi-annual reports. Some current activities are described below.

3.1 Whois Data Accuracy Study

The accuracy of Whois data is of great importance to many ICANN stakeholders. In November 2007, ICANN launched a Whois Data Accuracy Study to provide useful information to ICANN constituencies and the Internet Community about Whois data accuracy. This study uses statistical sampling of a random sample of the gTLD population to assess the percentage of certain Whois data accuracy.

ICANN has engaged with a consultant to provide name and address verification services. This will take at least 90 days and results are expected by August, 2008. Further information about the study methodology and progress will be given in the next newsletter. A full report on the findings from this study is expected in October, 2008.

3.2 Registrar Whois Data Inaccuracy Investigation Audit

In December 2007, the Contractual Compliance Department initiated a Whois Data Inaccuracy Investigation Audit, pursuant to Section 3.7.8 of the RAA. This provision requires Registrars to take "reasonable steps" to investigate alleged Whois inaccuracies.

ICANN staff commenced reviewing reports of Whois inaccuracy filed through its Whois Data Problem Reports System. ICANN compiled complaints that met certain criteria, and then collated them by registrar. Next, staff assessed the total number of Whois inaccuracy complaints filed against a registrar, which met the criteria. As a result of that analysis, ICANN sent the certain registrars a "Notice of Concern."

The notice reminded registrars of their obligation to "take reasonable steps" to investigate alleged Whois inaccuracies. The notices also contained a sample of actual domain names from complaints filed through the WDPRS that met the criteria above.

ICANN directed those registrars to:

  • describe their policy and procedures for responding to Whois inaccuracies, and
  • detail steps they took to investigate the alleged inaccuracies ICANN cited, and if necessary, correct Whois information.

This audit is ongoing and complete results will be provided in the next semi-annual Contractual Compliance Audit Report.

3.3 Performance Specifications Audit of Registries

In November 2007, ICANN conducted the inaugural Performance Specifications audit to ensure Registry operators complied with contractual service availability and performance obligations between June and August 2007. Performance specifications are the standards in each Registry Agreement regarding availability, outages, processing times, and update frequencies.

According to Registry monthly reports and/or Registry representations, 12 of 14 Registries were substantially compliant with their contractually mandated performance specifications between June and August 2007. The two Registries that did not provide sufficient information have been asked to provide additional information to demonstrate compliance. Otherwise, escalated compliance action will be taken.

The next issue of the newsletter will include information about Registrar Whois Data Reminder Policy Survey and Compliance Audit and Registrar Insurance Verification.

4. Upcoming events

Contractual compliance with ICANN's agreements will be discussed at the following events:

North American Registrar/Registry Gathering (New Orleans, Louisiana, USA 30 April – 2 May)

ICANN's 32nd International Public Meeting (Paris, France 22 June - 27 June):

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."