Skip to main content

Contractual Compliance Monthly Update | Issue 2

Welcome to the second issue of the ICANN Contractual Compliance Newsletter. It will provide up-to-date statistics, advisories, and other information regarding ICANN's Contractual Compliance program.

In response to comments from the community, this issue contains information regarding the Whois Data Problem Report System (WDPRS), and recent concerns over the service.

The newsletter aims to inform readers and encourage dialogue on ICANN's compliance activities, as well as foster an attitude of compliance within the registrar and registry communities by sharing information on enforcement.

If you have any comments or suggestions regarding this newsletter, please contact us at You can find more compliance information and subscribe to this newsletter at:

1. WDPRS: Purpose, System Developments and Planned Improvements

ICANN developed the Whois Data Problem Report System (WDPRS) in 2002 to assist registrars in complying with their obligation to investigate Whois data inaccuracy claims.

The WDPRS allows the public to file reports of Whois inaccuracy regarding active domain names at The WDPRS transmits Whois inaccuracy reports, via email, to the sponsoring registrars.

In 2004, after eighteen months of experience operating the WDPRS, ICANN made some improvements:

  • All gTLDs under contract with ICANN were included
  • Reports were automatically processed
  • Reporting was streamlined, and reporters were given the opportunity, via an automated follow-up email, to review the registrar's handling of each report submitted.

Under the current WDPRS, approximately 45 days after the WDPRS transmits a Whois inaccuracy report to the registrar of record, the reporter receives an email message from ICANN asking them to provide information regarding the domain name's Whois information. Specifically, the email inquires whether the inaccurate data was "corrected", whether the domain name was "deleted", whether there was no change or whether there was some other disposition.

ICANN receives over 50,000 reports of Whois inaccuracy a year through the WDPRS (nearly 90 percent of the reports are filed by ten individuals), and reports those results annually.

Due to an exceptionally high level of activity by a single reporter, sometime in February 2008, ICANN's WDPRS database reached its maximum capacity. As a result, the system stopped accepting new reports. For a short period, ICANN began receiving WDPRS failure complaints from the community. In order to address the issue in the near term, staff:

  1. Created a new database to allow processing of WDPRS reports;
  2. Raised the report limiter to accommodate an increased number of reports; and
  3. Monitored (and continues to monitor) daily activity for system response and capacity.

As part of a long-term solution, ICANN is conducting a system redesign that will improve operational effectiveness, data processing, accuracy, data recovery, and increase data capacity.

ICANN's 2008-9 budget also includes a provision for dedicated staff within the Contractual Compliance Department to analyze and assess:

  1. Whether reports filed through the WDPRS are valid as opposed to spam or other unrelated complaints; and
  2. Whether registrars investigate Whois data inaccuracy claims filed through the WDPRS as required by Section 3.7.8 of the RAA.

2. Enforcement Statistics

Consumer Complaint Analysis

During the past two years, ICANN has experienced an increase in the volume of inquires and complaints received via phone, fax, postal mail and email, which ICANN attributes to more and better educated registrants and, in part, to additional registrars.

Statistics on complaints received at ICANN's headquarters and through the Registrar Problem Report form are routinely captured. In the first quarter of 2008, 1675 complaints were received.

ICANN acts on every complaint. Most are forwarded directly to the registrar or registry involved for handling. As an aside, 1021 of the 1675 complaints - 61 percent - concerned issues, such as low customer service levels, that ICANN has no contractual authority to address.

The pie charts below illustrate the volume and types of complaints received. In each case, ICANN either forwarded the consumer complaint to the appropriate registrar or registry for investigation and corrective action, or resolved the complaint by providing the Complainant with requested information or action.

Complaint Process System Q1 2008

The chart below illustrates a three month comparative analysis of the top five recurring complaint categories: 1008 of the 1675 complaints (60 percent) received during the first quarter fall within the top five complaint categories.

Complaint Process System Q1 2008

Enforcement Notices Transmitted

Every month ICANN investigates alleged non-compliance reported by various entities, via complaints, regarding the activities of registrars and registries.

Additionally, regular conducts registrar and registry contractual compliance audits are conducted. As part of the investigative process for alleged non-compliance and the contractual compliance audit follow-up process, ICANN often transmits enforcement notices to registrars and registries.

Enforcement notices include:

  • Notices citing non-compliance
  • Notices escalating compliance action
  • Notices of breach of contract
  • Notices of termination

Each month, ICANN will report the number of enforcement notices transmitted to registrars and registries. For comparative purposes, notices sent during the prior two months will be provided as well. Please note, the number of enforcement notices transmitted on a monthly basis will vary based on the number and type of contractual compliance audits underway at the time of reporting.

Month Complaint Related Enforcement Notices Audit Related Enforcement Notices Total
Mar 08 75 515 590
Feb 08 74 141 215
Jan 08 106 996 1102

In an attempt to obtain registrar compliance with contractual compliance audits and RAA requirements, ICANN often transmits more than two enforcement notices to registrars.

In the interest of gaining greater compliance with RAA requirements, the RAA amendments under consideration regarding specific audit provisions are encouraging, particularly the proposed liquidated damages amendments for noncompliance and other enforcement provisions.

3. Complaint Escalation Process

How does ICANN determine whether to send notices of enforcement, including notices of breach to registrars and registries?

In 2007, ICANN implemented internal procedures for consistent processing of complaints concerning violations of registrar and registry agreements.

These procedures resulted in improved processing times and organizational efficiencies. The different processes vary based on the type of violation.

The nature, extent and effects of a violation determine which option ICANN may pursue. A process for pursuing compliance issues follows:

Complaint escalation process

All complaints regarding alleged RAA violations are analyzed on a case-by-case basis. The process outlined above allows ICANN flexibility to determine the most appropriate action, or actions, to take based on a thorough analysis of the facts and circumstances surrounding a particular complaint.

In some cases, complaints are based on incorrect information or assumptions, and are not pursued. To ensure sufficient attention is given to instances of registrar non-compliance, senior staff members are involved in the decision making process.

4. Recent Registrar/Registry Audit Activity:

ICANN's Contractual Compliance Program takes a pro-active approach to compliance through targeted surveys and audits. As audits progress, ICANN will provide findings and statistics through this newsletter.

While the department will provide comprehensive audit information in Contractual Compliance reports, this newsletter will summarize audit activity monthly to keep the community informed.

Registrar Whois Data Reminder Policy Survey and Compliance Audit

  • The Contractual Compliance Department conducted the 2007 Whois Data Reminder Policy (WDRP) Survey and Compliance Audit (WDRP Audit) to evaluate registrar compliance.
  • The WDRP requires all ICANN-accredited registrars that actively sponsor domain names to send an annual reminder to registrants to maintain accurate Whois records.
  • Of the 901 ICANN-accredited registrars audited, 825 were required to comply with the WDRP as they were actively sponsoring domain names at the time of the WDRP Audit. Of those, 32 failed to respond to the WDRP Audit.
  • Approximately 98 percent of all audit responders complied with the form and content requirements for reminder notices sent by registrars.
  • This represents a significant improvement in registrar compliance with WDRP requirements since ICANN began auditing in this area.
  • Several follow-up notices were sent to registrars that failed to respond to the request for WDRP Audit information. Escalated action is planned for registrars that failed to provide sufficient information to prove compliance within the period specified in the follow-up notices.

5. Contractual Compliance Advisory

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.

Registrar Data Escrow Requirements

Section 3.6 of the RAA requires registrars to submit to ICANN, or at the registrar's election and expense, to a reputable escrow agent, a copy of the electronic database maintained by the registrar in accordance with paragraph 3.4.1 of the RAA on a schedule, under the terms, and in the format specified by ICANN.

In November 2007, Iron Mountain Intellectual Property Management, Inc. (Iron Mountain) was chosen to provide escrow services under ICANN's Registrar Data Escrow (RDE) Program, and began enrolling registrars immediately.

Registrars that elected to use Iron Mountain's escrow services were required to enter into a standardized agreement with ICANN and Iron Mountain. Registrars that elected to use an escrow agent other than Iron Mountain were required to have the proposed escrow agent apply for approval as a Third Party Provider.

As of 22 April 2008, approximately 90 percent of all ICANN-accredited registrars have elected to use Iron Mountain's escrow services.

ICANN and Iron Mountain developed a rolling data deposit schedule and registrars were informed of required initial deposit dates. Approximately 230 registrars were required to commence data deposits by either 1 March or 1 April 2008. ICANN observed that 149 registrars failed to submit required data deposits by their respective deadlines. Registrars identified as non-compliant with RAA data escrow requirements were notified and directed to come into compliance or request an extension of their deadlines. Over half of the non-compliant registrars either began depositing data or secured an extension of their deposit deadline. Of the remaining non-compliant registrars, many have taken demonstrable steps toward compliance. Continued failure to deposit the required data will result in escalated enforcement action by ICANN, including notice of breach and possible termination of accreditation.

To avoid escalated compliance action, ICANN encourages each registrar to review Section 3.6 of the RAA regarding data escrow requirements as well as any documents transmitted by ICANN regarding the registrar's data escrow deposit date.

Upcoming Events

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