Skip to main content

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: Ron da Silva and León Sanchez.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Michelle Bright (Board Content Coordination Director), 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), Melinda Meadows (Executive Assistant to CTO), Wendy Profit (Senior Manager, Board Operations), Erika Randall (Associate General Counsel), Ashwin Rangan (Chief Information Officer), Lisa Saulino (Board Operations Senior Coordinator), and Christine Willett (VP, gTLD Operations).

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

  1. Action Items Review – Members of the Office of the Chief Technology Officer (OCTO) engaged the Committee in a review of the open action items to be addressed by the Committee. The open action items included the following:

    • Processing recommendations from the SSAC in SAC101 — It was noted that the SSAC is in the final review process of providing updates and clarifications to its original recommendations in SAC101 while not changing the substance of the recommendations. The Committee discussed that SAC101 would be handled through the Board's Action Request Register process, which will require ICANN org to evaluate the advice before it is considered by the Committee and the Board.
    • Processing recommendations from the RSSAC in RSSAC037 and RSSAC038 – It was noted that the Committee would begin discussions on the recommendations from the RSSAC during the current meeting and at subsequent meetings.
    • Scheduling a joint meeting with the Board Risk Committee – In light of previous information presented by the Chief Information Officer to the Board, the Committee determined that the action item to schedule a joint session with the Board Risk Committee to discuss the process that was followed to act on the security incident that recently affected Adobe Connect should be marked as "complete".
    • Reviewing the proposed Name Collision Analysis Project (NCAP) – It was noted that the Committee would take up this action item during the current meeting.
    • Coordination between the Committee and the RSSAC – The Committee noted that discussion was still needed to formalize regular interactions with the RSSAC on issues related to Root Server Systems.
  2. BTC Work Plan – Members of the Office of the Chief Technology Officer (OCTO) presented the Committee with a draft work plan for discussion. The work plan, which is intended to guide the overall activity of the Committee, is organized into three areas of activity: (1) ICANN org technical oversight, (2) community engagement and external relations, and (3) strategic and forward thinking.

    The Committee engaged in a discussion about the draft work plan. Some Committee members asked for clarification about whether dates had been assigned for each of the action items and noted that it would be useful to reflect these details into the plan so that Committee ensures that it remains on task and it is addressing the issues before it in a timely manner. OCTO team members explained the purpose of the action plan and how other Board Committees use action plans to guide their overall work. To make the plan for useful to the Committee, the OCTO team commented that they could provide the Committee with project plans for each of the specific projects identified in the work plan as appropriate.

    The Committee also considered including upcoming meeting dates in the proposed work plan and discussed the possibility of a face-to-face meeting during the Board's workshop in January and upcoming ICANN meetings. The Chair reported on conversations with the Board Chair on scheduling face-to-face meetings, and members of the OCTO team indicated that they would work with the Board Operations team to determine the availability of Committee members for a telephone conference meeting in January or a face-to-face meeting at the Board's workshop.

    After discussion, the Committee approved the work plan.

    Action Items:

    • At the next meeting, the OCTO team to provide the Committee with project plans for the specific projects identified in the Committee's work plan, including target completion dates and dependencies.
    • The OCTO team to work with Board Operations to schedule a January meeting of the Committee.
  3. ICANN Org Technical Oversight – The Committee received an update from the Chief Information Officer (CIO) about the steps ICANN org is taking to harden its IT systems. As part of his update, the CIO indicated that the ICANN President and CEO published a Blog during the ICANN meeting in Barcelona in this regard. ICANN org's proposed steps to harden its systems are in part a response to conclusions from an annual third-party cybersecurity audit, as well as two system issues that were identified by a community member that have been resolved. The CIO noted that the ICANN org's Engineering and Information Technology teams are working to deploy some improvements in advance of the next ICANN meeting in Kobe, Japan, as well as implementing other measures that are commonplace with software company environments, such as crediting those who disclose vulnerabilities to ICANN and making use of "white hats" to help vet ICANN's systems.
  4. Board Action Request Register – The Committee received a briefing from the Global Domains Division (GDD) regarding the Board's Action Request Register. The Action Request Register is a framework intended to improve the process for the Board's consideration of recommendations to the ICANN Board, including advice from its Advisory Committees. The Action Request Register also incorporates transparency measures, as it provides a view into the Board's progress throughout the lifecycle of addressing advice. The Action Request Register takes a five-phase approach to addressing advice items sent to the Board: 1) receive and acknowledge the advice, 2) understand the advice, 3) evaluate and consider the advice, 4) implement the advice, and 5) close the advice.

    Committee members asked questions about the process for the Board's consideration of advice from the Advisory Committees. One member asked whether any of the advice items had made it through all five phases of the process. GDD team members explained that ICANN org conducted a review of historical advice items going back to 2010 and provided a report to each Advisory Committee with an inventory of how each item of advice was implemented. ICANN org gained agreement with each Advisory Committee whether or not the items in the inventory should be considered as closed.

    Committee members also asked about the role of the Committee in helping to consider the advice, and whether the process deals with what happens if the Board decides not to follow the advice of an Advisory Committee. GDD team members indicated that the Committee may be involved at phases two and three of the process, where the Board is ensuring that it understands the advice from the advisory committee and is evaluating the advice. The GDD team also indicated that if the Board decides not to follow the advice, this evaluation would happen in phase three of the process.

    As part of the presentation from the GDD team, the Committee was provided with an update of open items in the Board Action Request Register that concern the work of the Committee, including advice from SAC101, RSSAC037 and RSSAC038.

  5. Draft Assessment of the SSAC Proposal for the Name Collision Analysis Project – The CTO engaged the Committee in a discussion regarding the SSAC Proposal for the proposed Name Collision Analysis Project (NCAP). As requested by the Committee, the OCTO team prepared a draft assessment of the SSAC proposal. The CTO reported that based in its initial assessment, the OCTO team recommended that the Committee support moving forward with the first study outlined in the SSAC proposal, in particular with tasks 1 – 5, which would include an analysis of past work done by ICANN and other community studies on the issue of name collisions. Completing this work could help identify whether the questions posed by the Board in its resolution leading to the creation of the NCAP are answerable.

    For proposed Study 2 (root cause and impact analysis) and Study three (analysis of mitigation options), the OCTO assessment expressed some concerns with agreeing to move forward with this work at this time, noting that it may not be feasible to determine root causes for all possible name collisions. The CTO stated that while it may be possible to identify classes of root causes, but it may not be likely that the issue could be traced to a single root cause. Also, there is a concern that undertaking Studies 2 and 3 may not yield any more information than what is gained by undertaking Study 1. Given cost and timeline associated with Studies 2 and 3, the CTO indicated that the OCTO team was not in a position to recommend moving forward with Studies 2 and 3 at this time. Instead, the OCTO team's recommendation is to move forward with Study 1 and then make a decision about whether or not the questions (even those asked by the Board in its October 2017 resolution) are questions that are ultimately answerable with the data collection mechanisms and analysis mechanisms that are available, or whether an alternative approach should be considered.

    The Committee considered the OCTO team's draft assessment and expressed appreciation for the work that the SSAC undertook at the request of the Committee for the proposal, as well as the work of OCTO to analyze the proposal. A Committee member noted that the studies suggested in the SSAC proposal seem reasonable and having a base of information would be useful for longitudinal studies and analyzing changes over time. However, in light of OCTO's draft assessment, Committee members suggested that this information be shared with the SSAC to provide the SSAC an opportunity to provide additional information and address concerns raised in the OCTO's draft assessment.

    Some Committee members expressed concern about the amount of time that it is taking to get started with the project and discussed ways to possibly move forward in parallel on next steps. A Committee member suggested that the Committee at least provisionally move forward with initiating the budgeting process for this project while the SSAC is reviewing the OCTO assessment. It was also suggested that the SSAC could be given some amount of flexibility to begin work, with caveats that additional discussion is needed to clarify with the differences of opinion between OCTO and the SSAC on the studies to be undertaken as part of the project.

    A Committee member also asked about whether there is a proposed budget for Study 1, and the CTO indicated that there is a proposed budget for the proposed studies, but it will depend upon which tasks are undertaken in each of the studies.

    The Committee discussed next steps on how to move forward with the project. The Chair noted that he could engage with the Chief Financial Officer and the Chair of the Board Finance Committee to determine how to move forward with financing work for the NCAP. Additionally, the CTO suggested that it could forward its draft assessment of the SSAC proposal to the SSAC consideration.

    Action Items:

    • The OCTO team to provide a breakdown of costs for Study 1 by tasks.
    • The Committee Chair to engage in discussions with the CFO and Chair of the Board Finance Committee on how to move forward with getting budget approval for work associated with NCAP.
    • The OCTO team to forward its draft assessment of the SSAC Proposal for the NCAP to the SSAC for consideration. Additional feedback from the SSAC to be discussed with the Committee at a subsequent meeting before presenting to the full Board for consideration.
  6. 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. As part of the report, it was noted that the RSSAC037 is an initial proposal for a governance model for the Root Server System, while RSSAC038 is the RSSAC advice itself. The GDD team noted that the advice is in the evaluation and consideration phase of the Board Action Advice Register.

    The GDD team reported that its overall assessment is that the RSSAC advice is feasible to implement. The team highlighted a few considerations for the Committee's attention. First, it was noted that there is an expectation that the model included in RSSAC037 would go through a community process, and that a future ICANN community body will take over further expanding the specifics of the proposal with the exact form of that body to be decided by the ICANN Board with community input. Second, there is a recommendation concerning cost estimates. The GDD team proposed that the cost estimates could occur in parallel with the development of the model within the six-month timeline described in the RSSAC advice. However, the cost estimates would continue to iterate over time in parallel as development of a final model progresses. Third, the RSSAC advice assumes after there is an agreed upon model through the community process, it would be presented to the Board for approval. This assumes that there is bandwidth in the community to undertake this work and to agree upon a final model for consideration by the Board.

    Committee members asked questions about the work plan and dates for implementing the RSSAC advice, and the GDD team noted that initial drafts of a work plan are available for discussion. Committee members also asked about next steps, and the Committee was informed that ICANN org is on track to provide the feasibility assessment to the Board by the end of calendar year 2018 if it receives comments from the RSSAC on the feasibility assessment in the next couple of weeks.

    Action Items:

    • The OCTO team to (1) provide the RSSAC with the draft feasibility assessment of how ICANN org proposes to implement RSSAC037 and RSSAC038, (2) incorporate feedback into the feasibility assessment as appropriate, and (3) forward to the Board for consideration when finalized.
  7. Any Other Business – Given the scope of the Committee's work described in the work plan, Committee members made suggestions for structuring the Committee's meeting agenda for upcoming meetings and suggested that meeting notes and action items be circulated as soon as possible to keep the work of the Committee on track.

The Chair called the meeting to a close.

Published on 9 January 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"""" is not an IDN."