Skip to main content
Resources

Minutes | Board Technical Committee (BTC) Meeting

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

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Susanna Bennett (SVP Chief Operating Officer), Michelle Bright (Board Content Coordination Director), Franco Carrasco (Board Operations Specialist), James Caufield (VP, Risk Management), David Conrad (Chief Technology Officer), Steve Conte (Office of the CTO Programs Director), John Crain (Chief Security Stability & Resiliency Officer), Linna Hsii (Counsel), Vinciane Koenigsfeld (Director, Board Operations), Matt Larson (VP Research, Office of the CTO), Wendy Profit (Senior Manager, Board Operations), Ashwin Rangan (SVP Engineering & Chief Information Officer), and Carlos Reyes (Strategic Policy Planning Director).

Invited Guests: Jim Galvin (SSAC NCAP WP Co-Chair and only present for the NCAP update discussion)


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

  1. Name Collision Analysis Project (NCAP) Update – The Committee received an update from the Office of the Chief Technology Officer (OCTO) on the progress of the NCAP discussion group. OCTO noted that the statement of work for Study One has been developed and finalized by the discussion group and turned over to OCTO. OCTO is now preparing the documentation necessary to run the standard ICANN Request for Proposal (RFP) process to engage a contractor to perform the work. The Committee engaged in a brief discussion on how to ensure the RFP process is open, fair and objective.

  2. Action Items Review – Following the NCAP update, the Chair established the agenda for the meeting, and the Committee reviewed the open action items and addressed the following:

    • Ensure the Committee receives regular NCAP updates during each meeting – this item has been implemented.

    • The Committee Chair to informally share with SSAC what the Committee has identified as priority or important topics for them to look into from the list that they have shared with the Board in Kobe – this item will be discussed in today's meeting (and the priority topics will be shared with SSAC during the face-to-face meeting in Marrakech).

    • The Committee members to review the DNS ecosystem risk assessment table on an ongoing basis, note and discuss changes as they arise, and call to the Board's attention if any action is required – a new and update version of the assessment table was shared with the Committee, this item is ongoing.

    • The Committee members to review and provide comments to the Root Server Operators Crisis Communication Plan – this item is still open.

  3. Review of BTC/Board Priorities & BTC Roadmap for S2-2019 – The Committee briefly reviewed the five items listed on the Committee priority list which consists of the L-root strategy, the root server crisis communication plan, the root server system governance, DNS evolution and security, and NCAP. The Committee then reviewed the work plan and briefly discussed the two new activities that were added. The first is the RSSAC and SSAC update and the need to reach an agreement on the meeting preparation process. The second is the hyperlocal service provided by ICANN org and to keep the Committee informed on how ICANN org proceeds on the matter.

  4. DNS Ecosystem Security – The Committee reviewed the work plan for the DNS evolution and security project and the associated table detailing the ecosystem elements, risks associated with these elements, mitigation measures and implementation notes. The Committee made suggestions on how to improve the format of the table and discussed whether the table should be presented to the Board.

    • Action Item:

      • The Committee intends to set up an informal meeting in Marrakech with the Board Risk Committee (BRC) to discuss how to harmonize the activities on DNS evolution and security project table with BRC activities.

  5. Root Server Crisis Communication Plan – There has been no further updates since the last report and the root operators has yet to agree on a final version of the root server crisis communication plan.

  6. Status of Technical Recommendation in ARR – The Committee received an update from OCTO about the items listed in the Action Request Registrar (ARR), which provides a centralized system for tracking and managing At-Large Advisory Committee (ALAC), Root Server System Advisory Committee (RSSAC) and Security and Stability Advisory Committee (SSAC) advice. OCTO had several meetings with Merike Kaeo and the ARR team to discuss and align on the status of the various items.

  7. BTC @ ICANN65 – When the Board met with SSAC at ICANN64, SSAC shared with the Board a list of seven areas of work. Of the seven areas identified, the Committee identified two priority areas: 1) risks associated with DOH and DoT from a privacy perspective; and 2) assessment of the pros and cons of a hyperlocal root. The Committee briefly discussed their plan to cover these priority items in their joint meeting with SSAC at ICANN65.

  8. RSSAC037/RSSAC038 Implementation Process Update – The Committee received an update from the Strategic Policy Planning Director on the implementation process update for RSSAC037 and RSSAC038. Currently, RSSAC037, the concept paper, and the Root Server System Governance Working Group operating procedures and work plan are published for public comment until 9 August 2019. Following the public comment proceeding, the Strategic Policy Planning Director will prepare a report summarizing the submissions. The public comment proceeding specifically addresses recommendation one from RSSAC038, and the Strategic Policy Planning Director is working on recommendation two, which is to estimate the cost of the root server system and developing the governance model.

  9. AOB – The Committee briefly discussed how often and to what extent they would like to receive an update from the Information Transparency Initiative (ITI) team.

    • Action Item:

      • The Committee requested to have a demo of the ITI platform in an upcoming Committee meeting.

Published on 6 August 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."