Skip to main content
Resources

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: Danko Jevtovic and León Sanchez.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Amy Bivins (Counsel), Michelle Bright (Board Content Coordination Director), Franco Carrasco (Board Operations Specialist), David Conrad (Chief Technology Officer), Steve Conte (Office of the CTO Programs Director), Linna Hsii (Counsel), Paul Hoffman (Principal Technologist), Vinciane Koenigsfeld (Director, Board Operations), Matt Larson (VP Research, Office of the CTO), David Olive (SVP, Policy Development Support), Ashwin Rangan (SVP Engineering and Chief Information Officer), and Danielle Wright (Administrative Assistant, Office of the CTO).


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

  1. Action Items Review – After establishing the agenda for the meeting, the Committee reviewed the open action items to be addressed by the Committee. The open action items included the following:

    • The preliminary report from the 4 February 2019 Committee meeting – the Committee members discussed making a few clarifications within the preliminary report and requested an updated version be circulated for the Committee's approval.
    • Work with shepherds assigned to each priority item to align on timelines – this item is open and ongoing.
    • ICANN org to share the concept paper on the RSSAC037 implementation plan with the Root Server System Advisory Committee (RSSAC) and the Board Technical Committee for consideration – this item has been completed.
    • Plan a coordination meeting between the Committee Chair, the Name Collision Analysis Project (NCAP) shepherd and Office of the Chief Technology Officer (OCTO) to decide a way forward on the NCAP proposal – the meeting has taken place and an update will be provided during the meeting.
    • Share the Anti-Phishing Working Group (APWG) proposal with the Technical Study Group (TSG) on access to nonpolitical registration data to ask if they would like to take it up and assess its feasibility – this item has been completed and the response has been shared with the Committee Chair.
    • Inform the Expedited Policy Development Process (EPDP) group about the APWG proposal – this item is on hold pending further clarification.
    • Merike Kaeo to send the Chief Technology Officer (CTO) information about Security and the Stability Advisory Committee's (SSAC) advice that covers credential management for domain name registries and registrars – this item has been completed.
    • Plan a public session at ICANN64 in Kobe to look into overall DNS security beyond the Domain Name System Security Extensions (DNSSEC) – this item has been completed.
  2. ICANN org Technical Support Update – The SVP Engineering and Chief Information Officer (CIO) provided the Committee with an update on two topics. The first was an informational update about Board emails and documents. The Board decided to use Google Suite (G Suite) as the email service provider about two years ago. Prior to that, several Board members used other clients which made it difficult to offer any kind of security. Board emails are currently stored on Google servers which gets scanned for malware and viruses. Google also makes its own backups and encrypt it on their servers so that it cannot be reassembled. The CIO also gave the Committee an overview on deletion practices and ICANN's general agreement with Google regarding the deletion of emails and accounts. Apart from emails, Board documents are also made available with G suite. Currently, ICANN org accounts allow for unrestricted sharing amongst Board members.

    The second topic is decisional and has to do with the chat tool, Slack. About three or four years ago, a group of Board members helped define a set of must-haves and should-haves to choose an appropriate tool for Board chat purposes. The result of that exercise was the implementation of the chat tool, Skype. More recently, the state of technology has increased dramatically and new tools have surfaced. ICANN org chose to go with Slack and rolled it out over the last three months. After some further discussion, the CIO noted his team will be available to address any additional questions the Committee might have in Kobe and that it should be brought up as a discussion item with the full Board.

    • Action Item:

      • The CIO to provide the Committee members with visibility into which mailing lists each Committee member is a part of and what email ID is embedded in that mailing list.
  3. Update on RSSAC037 – The Committee received a brief update on the concept paper that was circulated to the Committee and RSSAC on 12 February 2019. Initial concerns from RSSAC members included issues related to Root Server Operators (RSO) independence, separation of functions and Service Level Expectations (SLEs). While most of these questions will be addressed in the next phase of work, there doesn't appear to be any opposition to the concept paper at the moment. The Committee briefly discussed the next steps for the concept paper which will require feedback from the Committee, and feedback from the RSSAC. Once the Committee and RSSAC sign off on the paper it will be submitted to the Board for consideration.
  4. SSAC and NCAP Proposal Update – The Chief Technology Officer (CTO) has shared its updated proposal with the Committee, and the Committee briefly discussed its plans on next steps. The Committee discussed the differences between the two proposals and noted that the major difference is whether the Committee would like to prepare for Study 2 in Study 1 with the understanding that if Study 2 doesn't happen, some work may be wasted. The Committee also noted that OCTO's proposal should not be treated as a competing proposal, but rather an input and/or assessment of the proposal that SSAC has submitted. After further discussion, the Committee is in agreement that Study 1 should proceed and that discussions surrounding Studies 2 and 3, including what to do with the data repository should continue.
  5. DNS Evolution & Security – The purpose for the DNS evolution and security overview is to prevent a blindside by the next threat. As such, there will be a 90-minute session on Wednesday in Kobe to discuss a high-level overview of the security context from a data perspective. There is also going to be a discussion about the attacks that have been occurring in the last four months as well as overall mitigation techniques. There will be speakers from the SSAC and possibly some external participants who have been involved with the attacks. The overall session will include a 20-minute block for questions and answers.
  6. Any Other Business (AOB) – First, the CTO noted that for the upcoming Technical Liaison Group (TLG) and Technical Experts Group (TEG) meeting, each member of the TLG was provided with a set of questions related to their area of expertise for their input. Thus far, the European Telecommunications Standards Institute (ETSI) and the Internet Architecture Board (IAB) have provided responses which will be presented and included as part of the TEG/TLG meeting agenda. Second, the Committee shepherd for the current critical communication with root server operators has requested background information on how to move forward. Lastly, the CTO noted that the Committee meeting scheduled for 1 April 2019 conflicts with the OCTO all-hands meeting and asked that the April meeting be deferred to May. The Committee did not voice any objections to skipping the April meeting.

    • Action Items:

      • The CTO to send the Committee the list of questions that was distributed to the TLG members.
      • The CTO to provide background information to the Committee shepherd on the critical communication with root server operators.

The Chair called the meeting to a close.

Published on 10 April 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."