Skip to main content
Resources

Minutes | Board Technical Committee (BTC) Meeting

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

Board Member with Apologies: Mandla Msimang and Nigel Roberts.

Other Board Members and Liaisons in Attendance: Manal Ismail.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Chris Bare (Director, Global Implementation and Operations), Franco Carrasco (Board Operations Specialist), David Conrad (Chief Technology Officer), Steve Conte (Office of the CTO Programs Director), Linna Hsii (Counsel), Kinga Kowalcyzk (OCTO Administrative Assistant), Matt Larson (VP, Research), Wendy Profit (Board Operations Senior Manager), Erika Randall (Associate General Counsel), Carlos Reyes (Strategic Policy Planning Director).

Invited Guests: James Galvin (Security and Stability Advisory Committee (SSAC) Name Collision Analysis Project (NCAP) Working Party (WP) co-chair and only present for agenda item no. 1.)


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

  1. BTC Session with the Name Collision Analysis Project (NCAP) Co-Chair – The Committee received an update on the NCAP work from James Galvin, the co-chair of the NCAP discussion group. He noted that future updates to the Committee about progress for Study 2 would be provided by members of ICANN's Office of the Chief Technology Officer (OCTO). Members of the OCTO team reported that the Board recently approved the Committee's recommendation about a revised Study 2, and the team has engaged a technical writer for Study 2. Work is underway to identify and engage a technical investigator to research the name collision reports that have been reported to ICANN since 2014.

    James Galvin left the meeting following the NCAP update.

  2. Action Items Review – The Committee Chair established the agenda for the meeting and noted there were no open action items for review.
  3. Action Request Register (ARR) Update – OCTO provided the Committee with an update on its plans to close out items on the ARR.  The ARR is designed to track advisories, or recommendations from the Supporting Organizations (SOs) and Advisory Committees (ACs).  Following receipt of an advisory, ICANN org reviews the advisory and prepares a statement of understanding about what is being requested in the advice. If the relevant Advisory Committee agrees, then ICANN org prepares a proposal for how to implement the recommendation for consideration by the Board.

    OCTO team members provided the Committee with a summary of recommendations from the following advisories that are ready to move forward for consideration by the Board: SAC045, SAC062, SAC063, SAC065, SAC070, SAC073, and SAC102.

    • SAC045 addresses invalid queries. After discussion with the SSAC, the SSAC agreed that the recommendations in SAC045 that had not already been addressed would be covered by the Name Collision Analysis Project. As a result, the recommendations in the advisory could be closed.
    • SAC063, SAC073, and SAC102 all concern the root zone KSK rollover. The Board acted on the SSAC recommendations in these advisories and in October 2018, ICANN org successfully completed the first rollover of the root zone KSK.
    • SAC065 is an advisory on DDoS attacks leveraging DNS infrastructure. ICANN org supported community efforts with several projects related to this advisory and SSAC agreed ICANN org had fulfilled the recommendation to the extent feasible.
    • SAC070 addressed the use of Static TLD / suffix lists. Several of the recommendations required no action for the Board, but based on discussions with the SSAC, the recommendations advising action for ICANN org (Recommendations 3, 4a, 5, and 6) have been completed by ICANN org.

    The OCTO team also briefed the Committee on some open advice items that are in the implementation phase, which include RSSAC047, relating to measuring the root name server system performance, and RSSAC028, which addresses the naming scheme for the root name servers.  The OCTO team noted that the studies called for by the Root Zone Evolution Review Committee (RZERC) in RZERC002 would likely be combined into one larger effort to avoid duplication.

    The Committee agreed to submit to the Board the corresponding briefing papers about closing out the open items of advice from the SSAC with a recommendation for Board approval.

    Given the amount of work that has been completed, the Committee also discussed whether additional communication was needed so that the community is aware of all of the activities.

    • Action Items:

      • The OCTO team to coordinate with the Committee Chair, Board SSAC Liaison and the ICANN org communications team about a potential Blog or other communication concerning the work undertaken to close out multiple items of advice from the SSAC to the Board in various SSAC advisories.
  4. Name Collision Analysis Project (NCAP) and the New gTLD Subsequent Procedures (SubPro) Policy Development Process (PDP) – The Chief Technology Officer (CTO) provided background on the status of the NCAP analysis, noting that an issue that will likely come before the Board is whether or not it is necessary to complete the proposed NCAP Study 3 prior to launching the next round of new gTLDs. The CTO presented some high-level options for discussion, including the possibility of the Committee recommending that the Board not move forward with launching the next round of new gTLDs until Study 3 is completed, as well as the Committee recommending that the Board begin the planning work for the next round in parallel with the NCAP work.

    Committee members exchanged views on the potential options presented. One Committee member inquired about the timing of the NCAP Study 2 and Study 3 as it relates to the work that is anticipated for the Operational Design Phase (ODP) for the SubPro policy recommendations. The Committee member asked whether it would be possible as part of the ODP to have an indication about whether or not it would be prudent to move forward with the next round without, or prior to, completing Study 3. OCTO team members noted that the generation of the results of Study 2 and the completion of ODP would probably happen around the same time.

    There was also a question about whether there is possibly a bias in the SSAC against moving forward with the next round of the new gTLD program given some of the recent recommendations in SSAC advisories. Members of the OCTO team and other Committee members highlighted that the SSAC's role for NCAP is that of a coordinator of the community group. Also, there are mechanisms within the NCAP Discussion Group are sufficiently robust as to avoid bias. As part of the discussion, it was noted that while the Board tasked the SSAC to come up with answers to its questions about name collisions, the SSAC has taken care to make sure that the NCAP work is a community effort. This adds to the overall transparency to the community about the project. The CTO highlighted that the OCTO team and the Committee also play a facilitation role and can monitor concerns about bias from a procedural perspective. OCTO team members observed that there are viewpoints from various sides that are contributing to the NCAP discussion, and there does not appear to be any bias. Another Committee member suggested that a bit more thought be given about the governance around the NCAP study so as to avoid even the perception of bias that might possibly come from the business interests of participants in the study.

    The Committee also engaged in a discussion about whether NCAP Study 2 would address whether there are indications that the current mitigation for name collisions (i.e., controlled interruption) has been effective. Members of the OCTO team noted that NCAP Study 2 is primarily about researching root causes of name collisions.  While the NCAP Discussion Group thinks they will be able to get some insight into some of the questions from the Board that deal with mitigations, that work is really envisioned for Study 3, were it to happen.

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

    • Root Server System Governance Working Group (RSS-GWG):  The ICANN Org team supporting the RSS-GWG has been working with the Board Caucus and the liaisons on identifying points of divergence from the current RSS-GWG proposal in RSSAC37.  The RSSAC and the root server operators are now taking a closer look at the current RSS-GWG proposal. When the proposal is more stable, it is expected to be the subject of dialogue with the different organizations that are appointing numbers to the RSS-GWG to help refine the proposal. The Board RSSAC Liaison also provided an update on the plan to have a series of meetings between representatives of root server operators (RSOs). The goal is to engage with the RSOs about how best to get information from its representative liaisons on the GWG and to coordinate on developing a consensus view of RSOs on issues that can be communicated back to the GWG.
    • ICANN Managed Root Server (IMRS) Strategy: The OCTO-016 report, which is part of ICANN's Office of the Chief Technical Officer (OCTO) document series, describes the IMRS strategy and implementation plan. The report was published for public comment, and the team is in the process of updating the report based on feedback from RSSAC and others. It is anticipated that the final report will be published within the next couple of months.
    • Root Zone Management (RZM) Evolution Project: ICANN org has completed the Request for Proposal to engage a contractor and has chosen JAS Global to conduct the study and work is underway, including requesting documentation from the IANA team as well as contacting TLD managers about a survey.  The study is still on schedule to be finished in late 2021 or early 2022.
    • Domain Name System Security Facilitation Initiative (DSFI) Technical Study Group: The DSFI Technical Study Group had its final workshop and is preparing to discuss the final recommendations that it will make to the ICANN CEO. The Study Group is looking to have a draft ready within the next six weeks and anticipates doing some community outreach, including a consultation period.
  6. Updates from Technical Liaisons – The Committee received an update from the following Board Technical Liaisons:

    • SSAC (Merike Käo): The SSAC is working through the process of how to appropriately share a risk matrix of the DNS ecosystem to the Board and/or relevant Board Committees, taking into account the sensitivity of the information.
    • RSSAC (Kaveh Ranjbar): Updates provided as part of the discussion of Agenda Item #5 – Root Server System Governance Working Group.
    • Internet Engineering Task Force (IETF) (Harald Alvestrand): The IETF has recently removed some Internet drafts from the Internet drafts repository that were deemed to be offensive.
  7. Any Other Business – The Chair provided an update about the Committee's outreach webinar, and the Committee discussed the proposed agenda and topics to be covered during the webinar.

The Chair called the meeting to a close.

Published on 07 June 2021

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