Skip to main content
Resources

Minutes | Board Technical Committee Meeting

Board Member and Liaison Attendees: Ron da Silva, Avri Doria, Rafael Lito Ibarra, Akinori Maemura, Ram Mohan, Kaveh Ranjbar (Chair), and George Sadowsky.

Board Member and Liaison Apologies: Cherine Chalaby and Jonne Soininen.

Other Board Members in Attendance: Léon Sanchez.

ICANN Organization Attendees: Michelle Bright (Director, Board Content Coordination), Sara Caplis (Manager, Meetings Technical Services), Samantha Eisner (Deputy General Counsel), Aaron Jimenez (Senior Coordinator, Board Operations), Matt Larson (VP Research, Office of the CTO), and Wendy Profit (Senior Manager, Board Operations).


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

  1. SSAC Proposal for Name Collision Analysis Project – The Committee received an update on the SSAC Proposal for Name Collision Analysis Project (NCAP). As part of the update, it was noted that meetings and discussions took place at ICANN62 in Panama City regarding the bidding process, bugeting, and project planning on the first phase of the project. Comments regarding the project were also received from the community through public engagement, and the NCAP team have reviewed the comments and are working to update the project plan and budget to address them.

    The Committee was informed that members of the Office of the Chief Technical Officer (OCTO) had resolved the issue of potential conflicts of interest regarding the bidding processes.

    The Committee was also updated on budgeting for the project. It was noted that the OCTO has still yet to determine whether a budget would be structured based on continuing milestones, or split up into several separate budgets, as specifics of the proposal and the potential associated costs are still being determined. The Committee was informed that, as a key consideration in determing cost, the OCTO would be looking at name collision studies previously prepared for ICANN by JAS Global Advisors and Interisle Consulting Group. It was noted that in addition to the content of those studies being relevant to the NCAP, their costs are worth bringing into comparison given that both studies cover similar, though distinct, subjects.

    The Committee discussed whether the project was on track, or whether there were any issues or concerns that the Committee should be tracking more closely. The Committee's liaisons to the NCAP noted that they would continue to monitor the progress of the project, but no major concerns are present at the moment.

  2. SAC101: SSAC Advisory Regarding Access to Domain Name Registration Data – The Committee received a briefing on the SSAC Advisory Regarding Access to Domain Name Registration Data (SAC101). SAC101 provides advice to the Board about access to registration data directory services (RDDS), with a particular focus on rate limiting. The briefing to the Committee included an overview of each chapter of the report, which included highlights of the previous SSAC advice documents about RDDS, potential harms that could result from rate limiting access to RDDS, and whether the Temporary Specification on gTLD Registration Data ("Temporary Specification") meets ICANN's stated goal of preserving WHOIS to the greatest extent possible that is consistent with the law. The briefing also incuded discussion of the seven recommendations made by the SSAC in SAC101.

    The Committee's briefing on SAC101 also included discussion of the potential interdependent efforts in the community that are underway that may be relevant to consider alongside of the SSAC's advice. For example, it was noted that some of the SSAC's recommendations are being addressed through the Expedited Policy Development Process that is considering the issues in Temporary Specification as consensus policy. Additionally, some of the recommendations may be relevant to ongoing community discussions about a unified access model for continued access to full RDDS data.

    The Committee then engaged in discussions on a timeline and process for drafting recommendations for the Board's consideration about a possible course of action to address the SSAC's advice. Committee members suggested various approaches, which included identifying items of advice that may need to be referred to other ICANN supporting oganizations or to ICANN org for further handling. For example, some advice may potentially need to be referred to the GNSO Council for consideration as part of a consensus policy development process, or to ICANN org to address through the contract amendment processes for the Registry Agreements and Registrar Accreditation Agreement. Committee members suggested that if such an approach was adopted, additional outreach with the relevant groups may be needed to ensure proper coordination of the issues, in particular with the GNSO Council if the recommended approach may result in changes to the Temporary Specification.

    A member of the Committee noted that SAC101 seems to reveal a more general concern that perhaps further engagement with the SSAC in the future on matters related to technical and operational security would be beneficial. For example, one topic that could be addressed in additional engagement efforts is explaining the role of the Board role versus the role of other parties in the ICANN ecosystem so that SSAC would have a better understanding when developing advice of what the Board is empowered to do. Another general concern raised during the Committee's discussion focused on whether procedural and structural changes may be needed to ICANN's advisory committees to allow for earlier intervention into work being undertaken by the community.

    Finally, the Committee agreed to do further detailed analysis of SAC101 and developing recommendations from the Committee to the Board.

    • Action Item:
      • The Chair to prepare and deliver a letter to the SSAC acknowledging receipt of SSAC101 and reporting that the recommendations are actively being addressed.
      • Akinori Maemura to further analyze the advice in SAC101 and draft recommendations for the Board's consideration. The recommendations to the Board should identify whether the Committee proposes that the Board: (A) accept the advice as is, (B) refer the advice to another process, or (C) not accept the advice. The draft recommendations to the Board should be circulated to Committee members for comment and then submitted to the Board for consideration.
      • Going forward, guidance to the Board regarding recommendations received from advisory committees will be qualified to include Committee's recommendation about whether to accept the advice as is, refer the advice to another process, or not accept the advice.
  3. RSSAC037 and RSSAC038: A Proposed Governance Model for the DNS Root Server System - Advice from the RSSAC – The Committee discussed the development of a response and comments for the Board regarding the Root Server System Advisory Committee (RSSAC)'s proposed governance model for the Domain Name System (DNS), and agreed on who would take the lead on the project. The Committee also discussed the importance of an appropriate, encouraging, and substantive acknowledgement to the RSSAC pending the Committee's further analysis, given the significance of the work completed by the RSSAC.

    The Committee considered whether to request that the Board dedicate time during its upcoming workshop to discuss RSSAC037 and RSSAC038 in order to probe the governance models in a focused and timely fashion.

    • Action Item:
      • Lito Ibarra and Léon Sanchez to prepare briefing for the Committee on advice given by the RRSAC regarding the proposed governance model for the DNS in RSSAC037 and RSSAC038.
      • Lito Ibarra to prepare and deliver an acknowledgement of receipt and response to the RRSAC regarding RSSAC037 and RSSAC038 noting that their work is appreciated, understood, and is being actively considered.
  4. Board Technical Committee Work Plan, Calendar and Possible Need for Admin Support from Org – The Committee reviewed its work processes, and discussed the potential of changing the shape of the Committee's leadership to bring it into alignment with other committees. The Committee discussed possibly centralizing the Chair's function, or at least clarifying its role, in order to harmonize the end work product with what the Board receives from other committees.

    The Committee discussed three suggested objectives to improve its work processes. First, come up with a list of important and necessary tasks that the Committee should be undertaking every year, for example reviewing up and coming technologies, or threats to the root server system, and document these in a workplan. Second, the Committee should have a calendar created scheduling when certain actions should be taking place, and rating their importance. Third, the Committee should decide on a model of delegation of authority within the Committee itself, either centralized through the Chair, or decentralized depending on who the leads are for a particular set of advice.

    The Committee then engaged in a discussion regarding the three suggestions, and the members noted that the Committee should seek out administrative support from the Board, and ICANN org to achieve these objectives. It was also noted that any delegation of authority, or partly decentralized work-flow model, should be documented publicy so that parties that interact with the Committee would understand how things work.

    To move this project forward, it was suggested that at the upcoming Board workshop in Genval, the Committee could meet and discuss each suggestion in a workshop format, with one workshop dedicated to the subject of formation of a formal work plan and calendar, and a second workshop dedicated to discussing formation of a standard work model document that could be published, potentially as a blog. The importance of time management and efficient management of workflow was discussed and reaffirmed. The Committee also identified the general ambiguities regarding lead roles within the Committee in contrast to the Board, and the Committee acknowledged the need to clarify this, either by adopting a standard work model, or at least an advisory that communicates clearly the unique manner in which authority is delegated in the Committee.

    • Action Item:
      • The Chair to contact Board Operations to request scheduling of one-and-a-half hour session at the Board workshop in Genval to discuss planning for a published work plan, calendar, and standard work model document.
  5. Any Other Business (Open to Community) – The Committee discussed approval of the preliminary report of the 9 March 2018 Committee meeting and received approvals from members who had not previously provided them. The Committee noted that the report was well-prepared and that the same service provider should be engaged to prepare Committee reports in the future.

    The Committee was informed that members of the OCTO team provided comments on the Root Zone Key Signing Key Rollover Process in a document the Committee was asked to review and comment on. The document outlines the OCTO team's thinking regarding the KSK Rollover Process and why they feel confident in the plan. The Committee was also advised that the SSAC is currently engaged in a work party examining the plan and would provide advice within a couple of weeks. The Committee identified the need for additional advice from the Root Server System Advisory Committee (RRSSAC), and the Root Zone Evolution Review Committee (RZERC) by the end of August, which would allow the Committee and the OCTO sufficient time to identify potential issues, and take any necessary action in providing advice to the Board, if needed, given the October deadline for the KSK roll.

    The Committee also received an update on security vulnerabilities associated with Adobe Conntect, which had previously been identified by members of the SSAC. The Committee identified the importance of having an informed understanding of the systems being implemented for group interaction and collaboration to ensure that those systems are secure and have appropriately resolved security and other vulnerability concerns that have been identified. As part of that discussion, the Committee also considered its roll in providing guidance on all technical security-related issues for ICANN, and examined its own Charter with respect to the three high-level mandates assigned to the Committee. The Committee discussed whether advice to the Board or to ICANN org regarding these matters is appropriately within the Committee's scope of authority.

    The Committee considered what their role (and the Board Risk Committee's role) is in operational security issues specifically, and overall security issues more generally, and considered whether the day-to-day details of operational security were more appropriately left with the ICANN org members. The Committee agreed, however, that when there are tools used extensively by the community, or operational or security matters that specifically require the Committee's input, the Committee should be briefed and have some level of oversight to ensure that ICANN org has been properly advised. The Committee agreed this should be part of its standard operations, perhaps memorialized in a manual and institutionalized in the near future.

    • Action Item:
      • Committee to review document of OCTO's comments on the KSK Rollover Plan and provide comments/questions.
      • The Chair to schedule time on the agenda for OCTO to review comments by RSSAC, SSAC, and RZERC on KSK Rollover Plan in August 2018.

The Chair called the meeting to a close.

Published on 28 November 2018

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