Skip to main content

Six Weeks in Contractual Compliance and Consumer Safeguards

At the start of 2017, I took over for Allen Grogan as the head of ICANN's Contractual Compliance and Consumer Safeguards department. As part of my on-the-job training, I spend a lot of my time on community outreach, which is critical to success in this role.

This week, I had the pleasure of speaking before the intersessional meeting of the Non-Contracted Party House (NCPH). This was my first meeting, in my new role, with an ICANN structure, and I was grateful for the invitation. To begin, I shared a narrative on the purpose of the department, which I've included at the end of this blog. At the meeting, participants shared helpful and constructive feedback on their experiences with contractual compliance. While I spent most of the session listening, I also shared some initiatives that the department is considering pursuing:

  • Creation of a community-wide ad hoc working group on contractual compliance and consumer safeguards issues. Such a forum would allow for an open and transparent dialogue to help build awareness and community-wide understanding of these issues. It would also identify ways for the organization to strengthen its performance of its contractual compliance functions.
  • Identify ways that the department can play a more active role in combatting DNS infrastructure abuse arising from malware. These may include contract enforcement tools and collaboration with anti-abuse organizations outside ICANN.
  • Identify ways to provide increased transparency around compliance activities, including more granular data on individual complaints and the rationale for their resolution.
    The CCT-Review Team is likely to have similar recommendations for ICANN.

The Contracted Parties House will meet at the upcoming Global Domains Division (GDD) Summit in Madrid, Spain. I look forward to participating and gathering feedback from the contracted parties, just as I was able to do in Reykjavik with the NCPH. These opportunities to meet and interact with stakeholders from all corners of the ICANN community will help me and the department as we work to enhance our performance.

Finally, I hope to hire a director of consumer safeguards very soon. The objectives for that role are described in the narrative below, and the job posting is available here.

The meeting with the NCPH was only the first of many interactions I hope to have with the ICANN community. If you have any ideas or concerns regarding contractual compliance and consumer safeguards, please share them with me. I'll be in Copenhagen and look forward to talking to many of you then. In the meantime, you can reach me at jamie.hedlund at icann.org.

Purpose of the Contractual Compliance and Consumer Safeguards Department:

ICANN's legitimacy and the credibility of its multistakeholder model depend in large part on ICANN org's enforcement of its contracts with registries and registrars. If we perform these obligations poorly, we lose the community's trust in our commitment to ensure the stability and security of the DNS, faithfully implement the community's policies and enforce our agreements. In order to carry out ICANN's mission, we must have a robust contractual compliance function. 1

We must also demonstrate a commitment to safeguarding the interests of consumers in the domain name space. This means ensuring awareness and understanding of the safeguards that exist, facilitating discussion of additional safeguards that might be helpful, and distinguishing between potential safeguards that are within and outside of ICANN's remit. While the former could (theoretically) be incorporated into ICANN's agreements with contracted parties, the latter would exist outside of ICANN's purview. The role of the director of consumer safeguards will be to engage with the ICANN community to raise awareness of existing safeguards; facilitate discussions with external stakeholders on the perceived adequacy of existing safeguards, the potential need for additional safeguards and to convey the substance of those discussions internally, and to facilitate discussions among stakeholders regarding the voluntary adoption of consumer safeguards that are not within ICANN's remit.


1 The ICANN Mission recognizes the responsibility of ICANN org to "ensure the stable and secure operation of the Internet's unique identifier systems." We do this in part through coordinating the "development and implementation of policies concerning the registration of second-level domain names in generic top-level domains ("gTLDs")." The Mission also authorizes ICANN org to "negotiate, enter into and enforce agreements, including public interest commitments, with any party in service of its Mission." ICANN Bylaws, Art. 1., Sec. 1.1(a)(i) & (d)(iv).

Comments

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