Skip to main content

Enhancing Transparency in Contractual Compliance Reporting

In an earlier blog, Enhancing Transparency in Contractual Compliance, I briefed the community on the Contractual Compliance department's initiative to enhance transparency around our reporting. I'd like to briefly update you on this initiative's latest developments.

Our enhanced monthly reports now provide more detailed information on complaints related to the Governmental Advisory Committee (GAC) Category 1 Safeguards and Public Interest Commitments. This report builds on the contractual compliance-related recommendations from the Competition, Consumer Choice, and Consumer Trust Review Team draft report and the Governmental Advisory Committee's Copenhagen Communique [PDF, 190 KB].

Consistent with the advice we received from the GAC, specific safeguards apply to registry operators of a broad category of top-level domains (TLDs) related to consumer protection, sensitive strings, and regulated or professional sectors (GAC Category 1 TLDs). The complaints identified in this category are related to TLDs or second level domains in TLDs on the GAC Category 1 list. Information about the GAC Category 1 Safeguards advice, categories, and implementation framework can be found here. The new enhanced reporting will be published in March 2018 and take effect from January 2018. Information about the subject matter of complaints is available on the monthly Dashboard Explanation page.

In addition, we have added two new quarterly reports based on input from ICANN community members. The goal is to provide more detailed reporting about complaint resolution and closure code. The two new reports are "Registrar Closed Complaints by Closure Code" and "Registry Closed Complaints by Closure Code." The closure codes are categorized into three groups: Resolved, Out of Scope, and ICANN Issue. This report completes the complaint lifecycle, from ticket receipt to closure.

Over the past year or so, the compliance team has enhanced the transparency regarding the subject matter of complaints in ICANN's publicly available compliance reports for Whois Inaccuracy by the three categories of Syntax, Operability, and Identity; DNS Abuse; Transfer Policy;  and reported data by legacy gTLDs and new gTLDs. The team has also created several quarterly and annual reports that include all complaint types based on the type of gTLD at issue in the complaint (legacy or new gTLDs), a breakdown of reporter categories, enforcement, and resolution of complaints.

We hope that with these enhancements, Contractual Compliance has addressed not only the CCTRT's "…recommendations for practical reform within ICANN Contractual Compliance," and the findings that the "data available from ICANN Contractual Compliance are insufficient," but also the other recommendations from the Public Safety Working Group and the broader ICANN community.

Contractual Compliance Performance Reports are made available on We always welcome any feedback you may have. Please contact ICANN Contractual Compliance at if you have any questions, or would like to submit feedback.


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