Skip to main content

Improving Contractual Compliance

About ten days ago, members of the Registry Stakeholder Group (RySG) and the Intellectual Property Constituency (IPC) submitted a document entitled, “Joint Recommendations for ICANN Compliance.”  A few months into my new role leading Contractual Compliance and Consumer Safeguards, I appreciated the constructive input from these two constituencies.

At a session at the Non-Contracted Parties House Intercessional 2017 in Reykjavik, in sessions at the ICANN58 Community Forum with the At-Large Community, the Registry Stakeholder Group, the Registrar Stakeholder Group, the Security and Stability Advisory Committee, the Business Constituency, the Intellectual Property Committee, and the Governmental Advisory Committee in Copenhagen, and during formal and informal calls with community members, there were lively discussions regarding the need for improvements in Contractual Compliance.

To help us succeed in making desired changes, I asked for examples of where we could do better, as well as specific and concrete recommendations that we could implement. I was specifically asking for more than general statements such as “ICANN isn’t transparent” or “ICANN is bad at compliance”. The RySG-IPC Joint submission, which I understand was underway before these recent discussions, includes recommendations that are clear and specific and can be assessed for feasibility, cost and effort. And that’s just what we in Contractual Compliance will do.

There is another effort underway that also recommends improvements to Contractual Compliance. In the “Competition, Consumer Trust and Consumer Choice Review Team Draft Report of Recommendations for New gTLDs,” the Review Team seeks input on recommendations related to Contractual Compliance. In particular, Recommendation 23 urges ICANN to “Include more detailed information on the subject matter of complaints in ICANN publicly available compliance reports.”  The draft recommendations are now out for public comment. This is an excellent opportunity for community members to provide input just as RySG and IPC representatives have done. (Full disclosure – I am a member of the CCT-RT).

If you have examples of where Contractual Compliance could improve, especially on its commitment to transparency, and specific and concrete recommendations on how to improve ICANN’s Contractual Compliance function, please consider submitting them to the CCT-RT Public Comment forum. Alternatively, please submit them by email to me at jamie.hedlund at Once the public comment period on the CCT-RT’s closes, we will review all of the input we receive and provide a report on changes that we will undertake as well as a rationale for not undertaking others. Please send us your good ideas!


    Sheena Rustomji  00:26 UTC on 14 April 2017

    Nicea and good

    John Caswell  22:49 UTC on 14 April 2017

    Its helpful.

    irulaz  21:21 UTC on 29 May 2017


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