Skip to main content

SSR2 Review Team: Seven Highlights from Our Meeting at ICANN63

The Second Security, Stability, and Resiliency (SSR2) Review Team has continued to make significant progress since restarting our work in June 2018. We held our most recent face-to-face meeting over two days at ICANN63 in Barcelona, Spain. While there, we also held a public outreach session and met with various ICANN groups. Below are seven highlights from our productive few days.

During ICANN63, we:

  1. Completed our assessment of ICANN's implementation of 25 of the 28 SSR1 recommendations. We expect to wrap up the first draft of this part of our report by the end of November 2018.
  2. Planned out specific topics we intend to review under each of the three other areas of our focus, listed in this blog below.
  3. Updated our work plan based on the Team's progress and planning efforts. We are preparing a final version for the team's adoption and submission to the ICANN Board.
  4. Met with members of the Competition, Consumer Trust, and Consumer Choice (CCT) Review Team to discuss intersections between the CCT and SSR2 Review Team mandates.
  5. Conducted several community outreach sessions.
  6. Continued to work together productively and reaffirmed our commitment to our aggressive timeline.
  7. Began planning to meet face-to-face again in early 2019, ahead of ICANN64 in Kobe, Japan.

Our Areas of Focus

We are addressing relevant mandates of ICANN's Bylaws as they relate to four key areas:

  • ICANN's implementation of 28 recommendations from the first SSR review in 2012.
  • ICANN's key security, stability, and resiliency activities.
  • Activities that impact the security, stability, and resiliency of the unique identifier system (that ICANN contributes to and facilitates).
  • Strategic challenges to the secure and resilient operation of the unique identifiers system.

We will investigate and analyze all considerations with a clear intent to produce specific, measurable, attainable, relevant, and time-based (SMART) recommendations that fall within ICANN's purview.

Share Your Views

The SSR2 Review Team views our work as a community-focused review and we encourage everyone to share their views throughout our work. We welcome feedback at any time, including your thoughts on questions such as:

  • Do our topics cover all the necessary elements for the SSR2 review?
  • Is the material and focus of our team what you think SSR2 should be investigating?

We hope that community members will send their feedback and input any time to (publically archived). Visit our wiki for the latest news, updates, and opportunities to take part, including how to become a review team observer.

Our Next Steps

In the coming months, we will finish gathering facts and drafting our recommendations. We aim to meet face-to-face in January or February 2019, and present our draft recommendations to the community during ICANN64 in Kobe.


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