Skip to main content

Chair’s Blog: A Wrap-Up of the Vancouver Board Workshop

Over the weekend the ICANN Board met on 11-13 May in Vancouver, Canada. We held three public sessions and a public Board meeting, and I hope you were able to join some.

In the morning of the first day of the workshop, Friday, we began by meeting with the Root Server Security Advisory Committee (RSSAC) Co-Chairs to get a better understanding of their work, what issues they see coming down the road and their priorities. We then spent most of the day in sessions discussing our approach to strategic planning, long-term strategic outlook and trends, as part of the dialogue for the development with the community of the next iteration of ICANN's new Five-Year Strategic Plan for the period 2021-2025.

Göran Marby, President & CEO, ICANN, gave the Board a brief update on the anticipated timing of a proposed Temporary Specification for gTLD Registration Data. As you may have read in his blog post on this topic, we, as a Board, supported his recommendation to release the document to the community and the Board at the same time the evening of May 11th.

In order for us to devote the proper attention to reviewing a proposed Temporary Specification, we reorganized the workshop to accommodate a thorough review and discussion over the weekend. It was of the utmost importance to me, and the entire Board, that we have the time to digest, discuss and debate this document. We decided, therefore, to hold our planned public sessions, but the other sessions were rescheduled.  We also decided to push our start time on Saturday morning to 10:00 am so that we had time to read the document and identify questions and comments.

On Saturday we came together and started our discussions, with each Board member asking questions of, and raising points for, consideration to the ICANN org team. The discussions were broadly grouped into the following buckets:

  • How the proposed Temporary Specification facilitates compliance with GDPR
  • Guidance on addressing or incorporating interpretation of terms arising out of the GDPR
  • Potential for use of common anonymized email addresses across registrations
  • Access rights/accreditation mechanisms
  • Important issues for further community action, such as continued work to develop an accreditation model
  • The general need for a Temporary Specification
  • ICANN's compliance enforcement needs
  • The ability to update the Temporary Specification if needed

Our discussion was detailed, challenging issues were raised, and our debate was robust. We took as much time as we needed to review the proposed Temporary Specification, and at the end of the day we had framed a plan for continuing the discussion on Sunday.

We also held two public sessions on Saturday, one led by Akram Atallah, on the Trademark Clearinghouse regarding an ongoing discussion with the Registries Stakeholder Group, and another, led by Maarten Botterman, on the GAC scorecard, in response to the issues raised by the GAC in their San Juan Communique.

On Sunday morning, we reconvened, set our agenda for the day, and began by discussing the plan for revisions to the proposed Temporary Specification document. Full discussions and debate resumed, questioning and deliberating occurred in a very open and a constructive manner.  We wanted to ensure that all of our questions had been addressed and that there was a plan for continued incorporation of changes that reflected the issues we raised. You will be able to see the resulting changes in the revised Temporary Specification released by ICANN org here [PDF, 152 KB].

We then shifted gears to discuss the broader process around the potential adoption of a proposed Temporary Specification. We reflected and discussed if we, as a Board, had sufficient time to complete our conversation on a proposed Temporary Specification since its release on Friday 11 of May. On this point we decided "no". We had made strides by spending close to 16 hours of the Board workshop on this important topic, but we decided together to postpone our vote on adoption of a proposed Temporary Specification. This will allow us the opportunity to further our discussion, and to share with the community the revised proposed Temporary Specification reflecting our clarifications.

Then, as planned, Maarten Botterman led a public session on the progress made against the Board's operational priorities for FY18, highlighting the work that's been done on goals since I blogged about our priorities here.

We then discussed a path forward, if a proposed Temporary Specification is to be adopted. This included conversation on initiating a formal Board/GAC consultation and a new Policy Development Process to achieve recommendations on an ultimate model, as well as the ability to make interim changes to a Temporary Specification should they be necessary until the ultimate model is available.

As a group, we then discussed ideas about potential risks that could accompany either no action or adoption of a proposed Temporary Specification. We also discussed the best way to keep the community apprised of the progress and the process leading to the eventual decision we will take. One of the results of that conversation is the level of detail provided in this blog. We have also agreed with ICANN org to convene a community webinar on 15 May, from 09:15 to10:30 Pacific Daylight Time (16:15-17:30 UTC) to discuss this topic.

At the end of the day, at 17:00 local time, the Board held a full Board Meeting as we usually do. The Board passed a resolution noting our intent to take a decision on the adoption of a Temporary Specification on or about 17 May 2018. As indicated in the resolution, the Board intends to use this additional time to confirm that appropriate modifications are incorporated into the Temporary Specification prior to adoption. For more details on the workshop, including minutes from the public Board Meeting, please see the Board Page.

I appreciate the level of time, detail, discussion and consideration that the Board has given to this topic – it was a very instructive workshop. This was only possible because of the hard work of the ICANN community and ICANN org in getting us to this place, and for that, I thank you.

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