Skip to main content
Resources

Minutes | Board Technical Committee Meeting

Board Member and Liaison Attendees: Harald Alvestrand, Avri Doria, Rafael Lito Ibarra, Merike Kaeo, Akinori Maemura (Chair), Kaveh Ranjbar, and Tripti Sinha.

Other Board Members in Attendance: Cherine Chalaby, Danko Jevtovic, and León Sanchez.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Franco Carrasco (Board Operations Specialist), David Conrad (Chief Technology Officer), John Crain (Chief Security, Stability & Resiliency Office), Paul Hoffman (Principal Technologist), Vinciane Koenigsfeld (Director, Board Operations), Matt Larson (VP Research, Office of the CTO), Karen Lentz (Director, Operations & Policy Research), Wendy Profit (Senior Manager, Board Operations), Erika Randall (Associate General Counsel), and Lisa Saulino (Board Operations Senior Coordinator).


The following is a summary of discussions, actions taken, and actions identified:

  1. Action Items Review – After establishing the agenda for the meeting, the Committee reviewed the open action items to be addressed by the Committee. The open action items included the following:

    • The Committee to send a substantive acknowledgement to advice from the SSAC and RSSAC – It was noted that the Committee would discuss SAC101, RSSAC037, and RSSAC038 during the meeting and a substantive response could be prepared after the discussion.
    • The Committee to work with the Office of the Chief Technology Officer (OCTO) to review the SSAC Proposal for the proposed Name Collision Analysis Project (NCAP) and make a recommendation to the Board on the way forward – It was noted that this item would be discussed during the meeting.
    • ICANN org to intensify the search and identify candidates for the position of technical coordinator for NCAP – The Committee received an update that this item was on hold pending a decision on the path forward on the NCAP studies.
    • OCTO to liaise with the Board Finance Committee and the ICANN org finance department to assess available funds to support the studies proposed in the NCAP – The OCTO team reported that this work is in progress and the assessment should be available soon.

    The Chair noted that work would be done to identify owners for all of the open action items to make the action items list more useful. Another Committee member suggested that the action item list also include expected due dates.

    Action Item:

    • By the next Committee meeting, the OCTO and Board Operations teams to assign owners and due dates to the open items on the action items list.
  2. Proposed Implementation Process for RSSAC037 and RSSAC038 – A member of the GDD team provided a report to the Committee about the feasibility of implementing RSSAC037 and RSSAC038. The focus of the presentation was on implementation options and an initial feasibility assessment of the options.

    As part of the discussion, it was reported that the RSSAC submitted comments on the initial feasibility assessment, and these comments have been taken into account in a revised version of the assessment. The ICANN org Executive Team is currently reviewing the assessment.

    The Committee also received an overview about the various phases of the project to address the RSSAC advice. It was reported that the RSSAC037 outlined five functions as part of an initial framework for a proposed governance model for the Root Server System. Based on the advice, it is expected that that initial framework would go through a community process to develop a final model. Currently, the project is in phase one, which is intended to define the process.

    The report to the Committee included a discussion of the assumptions for how the process would work. One assumption is that a group would need to be created specifically for this project as there is no existing group within the ICANN community that would be appropriate to carry out the work. Also, it is assumed that the Board would convene the group, and thus the deliverable of the group would be submitted to the Board for consideration. It is expected that the group would operate in an open and transparent manner, and that the group would establish engagement and communications plans to ensure broad stakeholder input.

    Additional topics of discussion by the Committee focused on the proposed selection method for members of the group and the scope and role of the group. The current thinking proposed by ICANN org is that stakeholder groups would designate members, but other options were presented to the Committee for consideration, including creating a nominating pool where stakeholder groups would be asked to nominate several candidates and the Board would select group members based on subject matter coverage and global representation. With respect to the scope and role of the group, it was suggested that the group would take the form of a task force or working group as opposed to an ongoing committee or a steering group.

    As a starting place, the potential composition of the group would be the primary stakeholders of the Root Server System that are identified in RSSAC037, which are the IETF and IAB, the ICANN community, and the root server operators. Committee members commented that it was important to make clear that the RSSAC's identification of the primary stakeholders for the group was a starting place, but there needed to be a step in the plan to identify other relevant stakeholders.

    Committee members asked questions about how the group would make decisions, and the GDD team stated that once the group is formed, the group would decide what sort of working procedures and what definition of consensus it wants to use for its decision-making.

    Committee members also asked questions about the next steps, and the Committee considered discussing the matter further at the upcoming Board workshop in January. The timing of this work was also a topic of discussion, and Committee members asked whether the RSSAC had a specific timeline in mind to complete this work and whether there was any urgency to complete the work. Committee members familiar with the RSSAC reported that the RSSAC does not have a specific timeline in mind but would like to see viable progress on the project. The urgency for the work to be completed is not with respect to an individual Root Server Operators, but rather the sense of urgency arises because within the current model there is not responsibility or accountability for the whole root server system.

    Action Item:

    • Members of the OCTO team and GDD to refine the proposal for how to address RSSAC037. The proposal will be further discussed by the Board at the upcoming workshop in Los Angeles.
    • The Committee Chair to send letter to the RSSAC to provide an update on the progress made to consider RSSAC037.
  3. Update on the SSAC Proposal for the Name Collision Analysis Project – The Chief Technology Officer (CTO) provided the Committee an update on the work to assess the SSAC Proposal for the proposed Name Collision Analysis Project (NCAP), including an update on the work coordinate on budgetary questions associated with the project. The CTO reported that the SSAC responded to the draft written assessment of the SSAC proposal prepared by OCTO. The SSAC's response provided a number of points for clarification and additional information.

    Among the points addressed in the SSAC's response were clarification about the role of the data repository, and whether the ultimate goal of the NCAP studies is to produce a set of questions and guidelines that the Board needs to ask to make a decision about whether or not certain strings can be delegated, or whether the goal is to answer the series of questions the Board outlined in its November 2017 resolution. The Committee engaged in a discussion on the goal of the NCAP studies. Some members noted that it would not be possible for the SSAC to produce a list of strings that should not be delegated, but rather, the SSAC's role is to answer the question of what data, analyses, and processes should be used by the Board to make a decision about which strings should not be delegated. Other Committee members asked questions about whether the projected cost of the project is commensurate with the proposed end product expected to be delivered. It was also noted that one of the deliverables of the project would result in a simulation system that would allow for experimentation with proposed mitigations for name collisions.

    The CTO reported that additional points raised in the SSAC's response focused on mitigation research and the proposal to gather new data from resolvers to be analyzed as part of the study.

    Some Committee members noted that there are variances between what OCTO feels is appropriate for the NCAP study and the view of SSAC but suggested there may be ways to bridge the gap and move forward. In particular, some Committee members suggested that ICANN should move forward with Study 1, and review whether Studies 2 and 3 should be undertaken as Study 1 progresses. The CTO agreed that Study 1 should move forward, with some additional work associated with undertaking the gap analysis referenced within items 6 through 15 of the SSAC's proposal. The CTO suggested that the remaining studies proposed for the project should be reevaluated to see whether the questions originally asked by the Board need to be modified or whether the project needs to be rescoped or cancelled.

    Action Items:

    • Merike Kaeo to: (1) liaise with the SSAC to get clarification on questions raised during the Committee meeting about the SSAC's response, including clarification about some of the goals of the studies and the proposed simulation system to test mitigation measures; and (2) coordinate a meeting between the Committee and SSAC on the NCAP proposal.
  4. Technical Briefing on DNS over HTTPS – The OCTO team provided a briefing to the Committee about DNS over HTTPS (DoH). Overall, the briefing noted that it is too early to tell what the operational and privacy challenges are going to be because the browser vendors have not yet deployed DoH in a way that anyone can see, and the browser vendors are seemingly hesitant to do so.

    The Chair asked whether the OCTO team had any insight into the impact of the DoH for the entire DNS, and OCTO team members noted that it will depend on how DoH is implemented in browsers before an assessment could be made about the impact on the DNS.

The Chair called the meeting to a close.

Published on 7 February 2019

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