Skip to main content
Resources

Minutes | Board Technical Committee (BTC) Meeting

Board Member and Liaison Attendees: Harald Alvestrand, Rafael Lito Ibarra, Merike Käo, Akinori Maemura (Chair), Kaveh Ranjbar, and Tripti Sinha.

Other Board Members in Attendance: León Sánchez.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Franco Carrasco (Board Operations Specialist), David Conrad (Chief Technology Officer), Steve Conte (Office of the CTO Programs Director), John Crain (Chief Security, Stability & Resiliency Officer), Samantha Eisner (Deputy General Counsel), Linna Hsii (Counsel), Matt Larson (VP, Research), Erika Randall (Associate General Counsel), Ashwin Rangan (SVP Engineering & Chief Information Officer) and Carlos Reyes (Strategic Policy Planning Director).

Invited Guests: James Galvin and Patrik Fältström (Security and Stability Advisory Committee (SSAC) Name Collision Analysis Project (NCAP) Working Party (WP) co-chairs and only present for agenda items no. 1 and 2.)


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

  1. Committee Session with Name Collision Analysis Project (NCAP) Co-Chairs – Matt Larson, the VP of Research provided the Committee with a history on the formation of the NCAP Working Party (WP) and the NCAP Administration, a small group the NCAP WP leadership, SSAC leaders and the larger ICANN community. In 2018, the Office of the Chief Technology Officer (OCTO) took responsibility for completing the three studies outlined in the NCAP. The design for the studies was initially published by SSAC in 2018 and was revised following a discussion with OCTO about the scope of Study 1. The Board approved a resolution to proceed with Study 1 in March 2019. In June 2019, the NCAP Discussion Group was formed consisting of SSAC NCAP WP as well as anyone from the community who is interested in participating. In July 2019, ICANN org opened an RFP and eventually selected Scarfone Cybersecurity to complete the work on Study 1. Study 1 had three goals: 1) document prior work on name collision; 2) assess the availability of data sets that could be used to study name collision; and 3) make a recommendation on whether Studies 2 and 3 should be pursued.

    The results of Study 1 had four major findings: 1) name collisions have been a known problem for decades; 2) since controlled interruption was instituted, there have been very few instances of problems reported to ICANN or publicly through any forums; 3) prior work on name collision indicated that there are several types of root causes typically found by researching a particular leaked TLD; and 4) Studies 2 and 3 should proceed but not in the way in they are currently designed. The primary purpose of Study 2 is to find root causes for name collisions; but according to Scarfone Cybersecurity's findings, analyzing datasets is unlikely to yield new root causes for name collisions and instead suggested it may be more beneficial to research particular candidate strings on a case-by-case basis. The purpose of Study 3 was to research and propose mitigation techniques; but since controlled interruption has already proven effective, Scarfone Cybersecurity did not think it was necessary to spend additional time and resources on researching other mitigation techniques. Given these findings, OCTO recommends seeking input from the community on any revised proposals for Studies 2 and 3 and ensuring any studies that eventually take place are tailored to address the questions asked by the Board in its 2017 NCAP resolution.

    Jim Galvin, co-chair of the SSAC NCAP WG, expressed the NCAP Discussion Group's agreement with Scarfone Cybersecurity's findings and, specifically, on the need to revisit the proposals for Studies 2 and 3. Jim also added a few additional considerations. First, he noted that the DNS and Internet infrastructure has changed a great deal in the three years since the NCAP project first began and that, in turn, may impact the availability of data. Second, Jim acknowledged the need for additional work to be done but indicated the NCAP Discussion Group is careful about managing the work and being cost effective.

    Patrik Fältström, co-chair of the SSAC NCAP WG, also added that SSAC may seek clarification on some of the questions posed by the Board in its 2017 NCAP resolution. For example, further clarification on defining name collisions may be needed. Patrik also noted that actual name collisions are much wider than what is publicly known through datasets.

    The Committee and the NCAP WP co-chairs engaged in a discussion about next steps. The SSAC NCAP WG co-chairs will revise and reframe the NCAP Study 2 proposal and seek feedback from the Committee on any specific questions or concerns.

  2. Approval of Minutes – The Committee approved the Minutes of the 5 June 2020 meeting.
  3. Action Items Review – There are no new action items and the recurring action items will be discussed during today's Committee meeting.
  4. Committee Discussion on NCAP's Next Steps – Matt Larson, the VP of Research recapped the NCAP co-chairs' presentation and noted that the NCAP Discussion Group intends on addressing the questions posed by the 2017 NCAP Board resolutions unless the Committee provides guidance otherwise. The Committee discussed the need to revisit the 2017 NCAP Board resolutions to ensure the questions posed in the resolutions still apply given the conclusions reached at the end of Study 1. The Committee expressed varying opinions on the need to continue with Study 2. The Committee also discussed getting community feedback to get more perspective on Studies 2 and 3.

    • Action Item:

      • OCTO to prepare a new Board paper that takes into consideration the Committee's input and provide it to the Committee to make a recommendation to the Board.

  5. Priority Project Updates – The Committee received an update on the following projects:

    • Root Server System Governance Working Group (RSS-GWG): The RSS-GWG has been focusing on the community portion of the strategy, architecture and policy function and how it relates to other functions. The RSS-GWG reviewed two proposals and decided to pursue the public root services proposal. The RSS-GWG is working to deconstruct the proposal to ensure it aligns with the principals outlined by the Root Server System Advisory Committee (RSSAC). The proposal will be shared with the Committee upon publication.
    • ICANN Managed Root Server (IMRS): OCTO is in its final stages of reviewing the high-level IMRS strategy paper and expects to publish it in the OCTO document series.
    • Root Zone Management (RZM) Evolution Project: the IANA Stewardship Transition Coordination Group (ICG) for the IANA transition called for a study to examine the root zone management process and look for single points of failure in an effort to offer recommendations on how to reduce and/or eliminate these failures. ICANN org has put out a Request for Proposal (RFP) to engage a contractor to conduct the study. Multiple bids have been received, and ICANN org intends to select a contractor in due course.
  6. Updates from Technical Liaisons – The Committee received an update from the following technical liaisons:

    • DNS Security Facilitation Initiative Technical Study Group (DSFI-TSG) (Merike Käo): the nine members of the Technical Study Group now has a regular cadence of meeting every two weeks. The group is in the process of finalizing its scope and charter. Once they are finalized, they will be shared with the Committee.
    • SSAC (Merike Käo): the DNS Abuse Working Party is making progress and will provide the Committee with an update on its work. The environmental scan work is resuming after being usurped by other working party priorities and community review comments.
    • RSSAC (Kaveh Ranjbar): RSSAC will be providing input to the RSS-GWG draft language for its Service Level Expectations (SLEs) and Service Level Agreement (SLAs) between the Root Server Operators and the entity (entities) the GWG identifies on the other end.
    • Internet Engineering Task Force (IETF) (Harald Alvestrand): no new updates.
  7. AOB – Matt Larson, the VP of Research, provided the Committee with an update on the items being tracked on the Action Request Registry (ARR). There are three (3) recommendations from RSSAC28 that deal with root server naming and three (3) recommendations from RSSAC47 that deal with root server metrics measurement. OCTO has completed feasibility assessments on these recommendations and will be sharing these assessments with the Committee for review and approval.

    In the implementation phase, there are three items that are currently on hold and being deferred. First, there is an item related to root scaling that's pending completion of all the RSSAC reorganization in RSSAC037 and RSSAC038. Second, there is an item related to name collision that's being deferred pending completion of the NCAP project. Lastly, there is an item from SAC101 about access to domain name registration data which is pending assignment between OCTO and Global Domains Division (GDD). The remaining 11 items are ready to close.

The Chair called the meeting to a close.

Published on 3 November 2020

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