Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Board Activities and Meetings

View records of actions and decisions made by the ICANN Board from recent activities and meetings.

Minutes | Board Technical Committee (BTC) Meeting 28 January 2021

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

Board Member with Apologies: Mandla Msimang and Patricio Poblete.

Other Board Members in Attendance: Manal Ismail and Ron da Silva.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Terry Blaser (Sr. Manager, Enterprise Applications & Financial Systems), 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), Kinga Kowalcyzk (OCTO Administrative Assistant), Matt Larson (VP, Research), Erika Randall (Associate General Counsel), Ashwin Rangan (SVP Engineering & Chief Information Officer), Sam Suh (VP, IT ICANN Organization & Board Solutions Delivery), and 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 NCAP Co-Chair – James Galvin, the co-chair of the NCAP discussion group, provided the Committee with an update on their work. Since Study 1 ended, SSAC is now getting ready to kick off Study 2. While the revised Study 2 proposal is still being finalized, one item that resulted from SSAC's final review of the consensus out of the NCAP discussion group is the change in handling of conflict of interest, disclosure of interest, and statement of interest. As a result, there will be a dissent included as part of the revised proposal.

    The revised study proposal will also identify the four support roles needed for the project, which are a project manager, a technical writer, a technical investigator, and a project secretariat. The timeline for the revised study is slated to begin in January 2021 with a target end date around June 2022. James Galvin highlighted the 27% cost savings over what was originally proposed in Study 2, with most of the savings being attributed to the investigation work that is now being taken on by the discussion group itself.

    The Committee discussed whether Study 2 would provide answers to the questions the Board raised in its original resolution, which was the genesis of the work of the NCAP. Mr. Galvin noted that the proposed output of Study 2 would provide a set of guidelines within a framework that will allow the Board to evaluate name collisions in the future as well as make a final decision on .CORP, .HOME and .MAIL. James Galvin left the meeting following the NCAP update.

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

    • Office of the Chief Technology Officer (OCTO) to prepare a revised NCAP Board paper to reflect the Committee's feedback and discussion – this item has been completed.
    • ICANN org to prepare a draft Board resolution to continue to take all necessary steps to perform the KSK ceremony as provided in the contingency plans – this item has been completed.

  3. Next Steps for NCAP – After reviewing the revised NCAP Board paper, the Committee considered whether it was timely to make a recommendation to the Board about Study 2, or to wait for further review when there is a final version of the redesigned Study 2. After some discussion, the Committee agreed it would make a decision on the Board paper after receipt of the redesigned Study 2.

    The Committee also discussed whether NCAP Study 3 would be initiated. It was noted that the revised proposal indicates that after completion of Study 1, the Committee would make a recommendation about whether or not Study 2 was necessary, and after completion of Study 2, the Committee would further consider and make a recommendation about whether Study 3 was necessary.

  4. 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 AC agrees, then ICANN org prepares a proposal for how to implement the recommendation for consideration by the Board.

    OCTO provided the Committee with a summary of recommendations from two advisories that are ready to move forward: RSSAC028 and RSSAC047. RSSAC028 dates back to August 2017 and contains five recommendations about a naming scheme for root servers. The first recommendation suggests not making any changes to the root server names at this time, pending further study. ICANN org agrees. The second recommendation proposes a study to look into the consequences of changing the root name server names and proposes several different ways that the names could be changed along with the pros and cons for each change. ICANN org agrees that the study makes sense if there is interest in changing the root name server names. The third recommendation proposes another study to investigate the node redelegation attack, a variant on the cache poisoning attack. ICANN org agrees that it should be investigated and can be done so as part of the study proposed in the second recommendation. The fourth recommendation suggests that SSAC should study priming responses and how they behave under specific circumstances. This recommendation does not require any action from ICANN org. Recommendation five, labeled as a speculative recommendation, suggests additional actions if it turns out that node redelegation attach is an actual risk. At the moment, there is no action required from ICANN org.

    RSSAC047 is the result of extensive discussions by RSSAC on how to measure the behavior of the root server systems and coming up with several different metrics to measure both the performance of individual operators, as well as the performance of the root server system as a whole. The advisory has three recommendations. The first recommendation proposes that there be an initial implementation of a prototype system to measure all these metrics. This work has been completed. The second recommendation states that after the prototype is developed, a more permanent measuring system should be developed. Since the initial prototype is proving to be effective, OCTO can go back to refactor and operationalize it which can create a basis for a permanent measuring system. The third recommendation called for future work which is currently not applicable.

    After some discussion on budgeting and resources for RSSAC028 and RSSAC047, the Committee agreed to submit the corresponding Board briefing papers before the Board to recommend for approval.

  5. Engineering and Information Technology (E&IT): Concur and Single Sign-On for the Board – The SVP of Engineering & Chief Information Officer (CIO) provided the Committee with an overview of the anticipated changes to ICANN's travel management tool and the added feature of single sign-on. ICANN's travel management tool has been available to the Board for some time; however, the same instance of the tool is also being used by other parties within the ICANN ecosystem, including ICANN staff and community travelers. E&IT performed a review of the system and came to the conclusion both from a security and legal perspective that it would be prudent to split the instance into two separate instances, one devoted to ICANN staff and the other for Board and community. Since most of the work will take place in the backend, the impact to users will be minimal.

    The other suggested change is the use of a single sign-on tool for the Board to access various ICANN services. ICANN org has been using a single sign-on tool which E&IT has determined is technically feasible and economical to extend to the Board.

    In general, the suggested changes were well received by the Committee. One member asked about potential risks associated with using single sign-on and whether its use would introduce a potential single point of failure. The SVP of Engineering and CIO noted a few countermeasures that were instituted within the org, including multifactor authentication, to mitigate such risks. Following additional discussions between the Committee and ICANN org about the risks from both a legal and security perspective, the Committee provided its approval to move forward with the proposed changes.

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

    • Root Server System Governance Working Group (RSS-GWG): Following a Board workshop led by two members of the Committee (Tripti Sinha and Lito Ibarra) regarding updates on the latest RSS-GWG discussions, the RSS-GWG has continued these discussions with a meeting of the RSS Governance Caucus capturing a list of action items. The work has focused on providing an example of what new requirements Root Server Operators (RSOs) could receive potential funding for, and how that would fit into the flow of accountability.

    • 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, which closed on 5 January 2021. The paper received five comments, including comments from the Registry Stakeholders Group providing its support for putting in additional root server instances. Additionally, Verisign noted its opposition the use of encryption between the resolvers and root servers. Verisign also requested clear delineation within OCTO-016 between the IMRS strategy implementation plan and the root server system more generally. Additionally, ICANN org received from the Business Constituency (BC) who indicated its support root server instances in diverse locations and suggested that ICANN org pay for instances in areas where operators cannot afford them. ARTICLE 19 in Europe also indicated its support for root server instances in diverse locations as well as information sharing and capacity building. Finally, RSSAC provided input asserting OCTO-016 conflates ICANN org's role serving as a root server operator and as the body responsible for facilitating coordination of the root server system, that OCTO-016 implied poor performance of the root server system and expressed their view regarding hyperlocal root service.

      As a next step, OCTO will revise OCTO-016 to make the distinction between root server service and the root server system more explicit. Further clarification will be provided to indicate that the paper is discussing ICANN org's root server service strategy and implementation of that strategy, and not a strategy for the root server system as a whole. Other additions will include data documenting OCTO's assessment of the increasing risks associated with attacks against the root server system. With regards to the comments regarding encryption between resolvers and root servers, OCTO will clarify that it is largely dependent on the Internet Engineering Task Force (IETF) standardization efforts. Following these updates, OCTO will publish a second version of OCTO-016. Further, OCTO will also publish a detailed technical analysis of hyperlocal to help aid the Committee and Board looking at the questions raised by the Root Server System Advisory Committee.

    • Root Zone Management (RZM) Evolution Project: ICANN org has completed the Request for Proposal (RFP) to engage a contractor and has chosen JAS Global Advisors to conduct the study. The study is anticipated to begin in February 2021 and take about a year to complete.
    • Domain Name System Security Facilitation Initiative (DSFI) Technical Study Group: The DSFI Technical Study Group has been meeting consistently every month for a virtual three-hour workshop which has significantly improved the progress of the work.

  7. Updates from Technical Liaisons – The Committee received an update from the following Board Technical Liaisons:

    • SSAC (Merike Käo): The SSAC is in the final stages of completing its comments to New gTLD Subsequent Procedures Draft Final Report which should be published soon. The SSAC has initiated the routing-related work which received positive feedback from the Address Supporting Organization (ASO) Chair. The SSAC has also taken on the environmental scan work to study risks to the DNS ecosystem to inform and figure out how to better prioritize the work based on the security related priorities while also informing the membership committee as to where there might be gaps in membership. Finally, the SSAC is in the last stages of finalizing the DNS abuse paper.
    • RSSAC (Kaveh Ranjbar): Updates will be provided in the next Committee meeting.
    • Internet Engineering Task Force (IETF) (Harald Alvestrand): Recently, the IETF has published the largest number of Request for Comments (RFCs) in a single day, about 52 documents, with a majority describing the Web RTC protocols.

The Chair called the meeting to a close.

Published on 19 March 2021