Skip to main content
Resources

Preliminary Report | Regular Meeting of the ICANN Board

Formal Minutes are still to be approved by the ICANN Board.

Note: This Preliminary Report has not been approved by the Board and does not constitute minutes. It does set forth the unapproved reporting of the resolutions from that meeting. Details on voting and abstentions will be provided in the Minutes, when approved at a future meeting.

NOTE ON ADDITIONAL INFORMATION INCLUDED WITHIN PRELIMINARY REPORT – ON RATIONALES – Where available, a draft Rationale for each of the Board's actions is presented under the associated Resolution. A draft Rationale is not final until approved with the minutes of the Board meeting.

A Regular Meeting of the ICANN Board of Directors was held telephonically on 25 March 2021 at 21:30 UTC.

Maarten Botterman, Chair, promptly called the meeting to order.

In addition to the Chair, the following Directors participated in all or part of the meeting: Becky Burr, Ron da Silva, Sarah Deutsch, Avri Doria, Rafael Lito Ibarra, Danko Jevtović, Akinori Maemura, Göran Marby (President and CEO), Mandla Msimang, Ihab Osman, Patricio Poblete, Nigel Roberts, León Sánchez (Vice Chair), Matthew Shears, and Tripti Sinha.

The following Board Liaisons participated in all or part of the meeting: Harald Alvestrand (IETF Liaison), Manal Ismail (GAC Liaison), Merike Käo (SSAC Liaison), and Kaveh Ranjbar (RSSAC Liaison).

Secretary: John Jeffrey (General Counsel and Secretary).

  1. Consent Agenda:
    1. RSSAC028: Technical Analysis of the Naming Scheme Used For Individual Root Servers
    2. RSSAC047: RSSAC Advisory on Metrics for the DNS Root Servers and the Root Server System
    3. Appointment of Independent Auditors for FY21
  2. Main Agenda:
    1. Acceptance of the Second Organizational Review of the Security and Stability Advisory Committee (SSAC2) Final Implementation Report
    2. Accepting Name Collision Analysis Project (NCAP) Study 1 and Proceeding with Study 2
    3. Operational Design Phase for System for Standardized Access/Disclosure to Non-Public Registration Data (SSAD)
    4. AOB

 

  1. Consent Agenda:

    The Chair opened the meeting and introduced the items on the Consent Agenda. After discussion, the Board took the following actions:

    The following items on the Consent Agenda are approved:

    1. RSSAC028: Technical Analysis of the Naming Scheme Used For Individual Root Servers

      Whereas, on 3 August 2017, the Root Server Advisory Committee (RSSAC) published RSSAC028: Advisory on Technical Analysis of the Naming Scheme Used For Individual Root Servers.

      Whereas, the work called for in RSSAC028 falls under ICANN's remit in ensuring the stable and secure operation of the Internet's system of unique identifiers as part of ICANN's mission.

      Whereas, ICANN org has evaluated the feasibility of the RSSAC's advice in RSSAC028 and developed implementation recommendations for each advice item.

      Whereas, the Board has considered ICANN org implementation recommendations relating to RSSAC028's Recommendations.

      Resolved (2021.03.25.01), the Board accepts Recommendation 1, calling for the current naming scheme used in the root server system to remain unchanged until more studies have been conducted.

      Resolved (2021.03.25.02), the Board accepts Recommendation 2, relating to conducting a study to understand the current behavior of DNS resolvers and how each naming scheme discussed in this document would affect these behaviors, and directs the ICANN President and CEO, or designee(s), to commence such a study.

      Resolved (2021.03.25.03), the Board accepts Recommendation 3, relating to conducting a study to understand the feasibility and impact of node re-delegation attacks, and directs the ICANN President and CEO, or designee(s), to commence such a study.

      Rationale for Resolutions 2021.03.25.01 – 2021.03.25.03

      Why is the Board addressing the issue?

      The Board is taking this action at the recommendation of the RSSAC.

      The RSSAC's remit is to advise the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's root server system. This includes communicating on matters relating to the operation of the root servers and their multiple instances with the technical and ICANN community; gathering and articulating requirements to offer those engaged in technical revisions of the protocols and best common practices related to the operation of DNS servers; engaging in ongoing threat assessment and risk analysis of the root server system; and recommending any necessary audit activity to assess the current status of root servers and the root zone.

      What is the proposal being considered?

      The RSSAC Caucus Root Server Naming Work Party investigated possible changes to the current root server naming scheme. This naming scheme has worked well for root servers and the Internet community at large for over two decades. However, given today's Internet environment, the RSSAC has studied the naming scheme used for individual root servers and considered the consequences of making changes.

      The Work Party concluded that there may be a benefit to adopting one of the other schemes described in RSSAC028 after more in-depth research, but it was also recommended that no immediate changes to root server names be made at the time of the Advisory's publication (Recommendation 1).

      The document recommends that DNS researchers should investigate four topics: the acceptable response size for priming queries; how resolvers respond when given answers with a shortened set of glue records; how resolvers that validate priming responses behave when faced with broken responses; and whether search lists affect priming behavior (Recommendation 2).

      In addition, the RSSAC recommended that a study should be conducted to understand the feasibility and impact of node re-delegation attacks as it was recognised that more in-depth research is required to understand node re-delegation attacks, the costs and benefits of signing the A and AAAA records for the root servers, and the effects of increasing the priming query response size (Recommendation 3).

      Recommendation 4 calls for the RSSAC to study priming responses sent under specific circumstances. There is no action for the ICANN Board associated with this recommendation.

      Recommendation 5 is labeled as "speculative" and contains suggested actions that only apply if node redelegation attacks pose a serious risk that needs to be mitigated. On 28 September 2020, the RSSAC confirmed that there is no action for the ICANN Board related to this recommendation at this time.

      Which stakeholders or others were consulted?

      Under the RSSAC's remit mentioned above, the RSSAC formed a Caucus Work Party that was responsible for publishing material leading up to and including RSSAC028.

      What concerns or issues were raised by the community?

      None at this time.

      What significant materials did the Board review?

      The Caucus Work Party published their Statement of Work and Scope for History and Technical Analysis of the Naming Scheme used for Individual Root Servers on 9 July 2015. This document provided direction in the form of five key points. The first point was, "document the technical history of the names assigned to individual root servers since the creation of the root server system", which lead to RSSAC's issuing RSSAC023: History of the Root Server System. The remaining four scope points provided the foundation for this Advisory, RSSAC028.

      What factors did the Board find to be significant?

      This research facilitates continued evolution of the root server system.

      Are there positive or negative community impacts?

      ICANN org could perform the investigation required by RSSAC028 to aid the community in deciding whether or not to recommend changing the root server naming scheme.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      The resources required for the studies in both Recommendation 2 and 3 (it is more efficient to run the studies together) will require staff and budget not currently allocated.

      ICANN org estimates completing the Recommendation 2 study will require approximately six months of a researcher's time at a cost of approximately USD 150,000 along with some minimal project management and administrative support. This study has not been budgeted for FY21.

      ICANN org estimates completing this study contemplated in Recommendation 3 would require approximately two months of a researcher's time at a cost of approximately USD 50,000 along with some minimal project management and administrative support. This study has not been budgeted for FY21.

      Are there any security, stability or resiliency issues relating to the DNS?

      The research recommended by RSSAC028 is directly related to ensure the future stability of the root server system.

      Is this decision in the public interest and within ICANN's mission?

      This falls directly under ICANN's Mission Statement, from Bylaws Section 1.1. MISSION:

      "(a) The mission of the ICANN is to ensure the stable and secure operation of the Internet's unique identifiers

      (ii) Facilitates the coordination of the operation and evolution of the DNS root name server system."

      In addition, the implementation of this advice aligns with item "1.2 Strengthen DNS root server operations governance in coordination with the DNS root server operators" from the ICANN Strategic Plan for Fiscal Years 2021-2025.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      The action recommended by RSSAC028 does not require a public comment as it is only research. However, once the research is published there will be future decisions requiring community input.

    2. RSSAC047: RSSAC Advisory on Metrics for the DNS Root Servers and the Root Server System

      Whereas, RSSAC047, RSSAC Advisory on Metrics for the DNS Root Servers and the Root Server System, published on 12 March 2020, recommends a set of metrics for the Domain Name System (DNS) root servers as well as for the root server system (RSS) and recommends the development of systems to collect those metrics.

      Whereas, ICANN org has developed a prototype measurement system to provide data to the RSSAC Caucus to allow an informed recommendation on the metric thresholds, and the RSSAC and the RSSAC Caucus agreed upon four types of metrics to most accurately measure the performance of the root server operators (RSOs).

      Whereas, the recommendations in RSSAC047 fall under ICANN org's remit to ensure the stable and secure operation of the Internet's unique identifier systems; and implementing the recommendations would further preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet and ensure that new gTLDs are introduced in a secure and stable manner.

      Resolved (2021.03.25.04), the Board accepts Recommendation 1, which calls for implementing a prototype measurement system for RSOs, and thanks ICANN org for already developing such a system to assist with defining the metrics outlined in RSSAC047.

      Resolved (2021.03.25.05), the Board accepts Recommendation 2 to implement a more permanent measurement system after establishing and using the prototype measurement system from Recommendation 1, and directs the ICANN President and CEO, or designee(s), to implement such a system.

      Resolved (2021.03.25.06), the Board directs the President and CEO, or his designee(s), to implement and operate the measurement system described in Recommendation 2.

      Rationale for Resolutions 2021.03.25.04 – 2021.03.25.06

      Why is the Board addressing the issue?

      The Board is taking this action in response to the advice of the RSSAC.

      What is the proposal being considered?

      RSSAC047 defines measurements, metrics, and thresholds that root server operators (RSOs) meet to provide a minimum level of performance. The thresholds are based on technical metrics designed to assess the performance, availability, and quality of service that each root server identifier (RSI) provides. The thresholds and the metrics on which they are based are included as the RSSAC's input to a yet-to-be defined evaluation process for current and future RSOs. The metrics defined in RSSAC047 provide a way to show when RSOs are, or are not, meeting minimum performance levels. They also provide a way to show that the RSS as a whole is, or is not, meeting performance levels.

      RSSAC047 has three (3) Recommendations:

      RSSAC047's Recommendation 1 calls for initial implementation of the measurement and analysis systems described in the Advisory. This work has already been completed.

      The metrics are based on a strategy of taking external measurements of each root server identifier, collecting those measurements, and then collating them into monthly reports. The reports are given as pass/fail for each metric against a set of thresholds listed in the document.

      RSSAC047's Recommendation 2 describes a later long-term service. The operational details of the long-term service can be determined after there is sufficient experience with the initial prototype implementation described in Recommendation 1. Based on this operational experience with the prototype system, ICANN org can determine how and when the official implementation will be put in place. It is possible that ICANN org will determine that the prototype system meets all the requirements described in RSSAC047 and is suitable for long-term use.

      RSSAC047's Recommendation 3 calls for additional work in the future, so there is no action for the Board at this time. The future work would be initiated by the RSSAC (or a successor organization as a result of implementing the recommendations in RSSAC038), and would be performed in collaboration with ICANN org and the Internet community.

      Which stakeholders or others were consulted?

      RSSAC047 was created and edited by the RSSAC Caucus, which consists of dozens of experts from the wider community. The RSSAC submitted this Advisory in its capacity of advising the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's root server system.

      There was strong agreement in the RSSAC Caucus that the four types of metrics identified in the document are the correct set for external measurements of the RSOs.

      ICANN org has already worked with the RSSAC on a prototype measurement system of RSO performance to provide data for consideration to aid in the development of the metrics outlined in RSSAC047.

      What concerns or issues were raised by the community?

      No concerns.

      What significant materials did the Board review? What factors did the Board find to be significant?

      The impetus for this work comes from RSSAC037: A Proposed Governance Model for the DNS Root Server System. While not dependent on the implementation of RSSAC037, this work can inform the implementation work on RSSAC037 in the following ways:

      • A future manifestation of the Performance Monitoring and Measurement Function (PMMF) could use the technical metrics and thresholds defined in this report as a starting point to define its rules to assess the performance, availability, and quality of service that each RSO provides, thus bringing technical accountability to the RSOs.
      • RSSAC037 states that Service Level Expectations (SLEs) should exist between the stakeholders that provide funding and RSOs that receive funding. Metrics and thresholds for the RSOs defined in this report can be used as a starting point for further discussions on the technical and performance requirements in the SLE.

      Secondly, while this report focuses on only minimal performance expectations, the RSSAC recognizes that, with the evolution of the governance model, RSOs may enter into future service contracts which could include Service Level Agreements (SLAs). The RSSAC expects that the metrics defined here will be useful in an SLA context. Based on discussions during the preparation of this report, the RSSAC further expects that any SLA thresholds would be stricter (if possible) than the ones provided here.

      Thirdly, the metrics and thresholds defined in this report can also be used by RSOs and others to identify situations where the RSS as a whole is degrading in performance, and actions need to be taken collectively.

      What factors did the Board find to be significant?

      ICANN org has already worked with the RSSAC on a prototype measurement system of RSO performance to provide data for consideration to aid in the development of the metrics outlined in RSSAC047.

      Are there positive or negative community impacts?

      The metrics defined here allow the community to determine if there are RSOs not meeting minimum performance levels. The community can then work with the RSSAC, or through other community mechanisms, to address the issue.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      Implementation of Recommendation 1 and, eventually Recommendation 2, requires ICANN org time and a small amount of ongoing operational expenditure. These costs are incorporated into OCTO's budget as part of OCTO's normal activities.

      Are there any security, stability or resiliency issues relating to the DNS?

      The metrics defined here provide a way to show that the RSS as a whole is, or is not, meeting performance levels. Implementing this advice is within ICANN's remit because it involves setting up systems that the community can use to make assessments of the RSS.

      Is this decision in the public interest and within ICANN's mission?

      Yes. RSSAC047 defines measurements, metrics, and thresholds that root server operators (RSOs) meet to provide a minimum level of performance. This falls directly under ICANN's Mission Statement, from Bylaws Section 1.1. MISSION:

      "(a) The mission of the ICANN is to ensure the stable and secure operation of the Internet's unique identifiers

      (ii) Facilitates the coordination of the operation and evolution of the DNS root name server system."

      In addition, the implementation of this advice aligns with item "1.2 Strengthen DNS root server operations governance in coordination with the DNS root server operators" from the ICANN Strategic Plan for Fiscal Years 2021-2025.

    3. Appointment of Independent Auditors for FY21

      Whereas, Article 22, Section 22.2 of the ICANN Bylaws (http://www.icann.org/general/bylaws.htm) requires that after the end of the fiscal year, the books of ICANN must be audited by certified public accountants, which shall be appointed by the Board.

      Whereas, the Board Audit Committee has discussed the engagement of the independent auditor for the fiscal year ending 30 June 2021 and has recommended that the Board authorize the President and CEO, or his designee(s), to take all steps necessary to engage BDO USA, LLP and BDO member firms.

      Resolved (2021.03.25.07), the Board authorizes the President and CEO, or his designee(s), to take all steps necessary to engage BDO USA, LLP and BDO member firms as the audit firm(s) for the financial statements for the fiscal year ending 30 June 2021.

      Rationale for Resolution 2021.03.25.07

      The audit firm BDO USA, LLP and BDO member firms have been ICANN's independent audit firms since the audit of fiscal year 2014. In 2019, there was a partner rotation and a new audit partner was assigned to the ICANN engagement. Based on the report from the organization and the Audit Committee's evaluation of the work performed, the committee has recommended that the Board authorize the President and CEO, or his designee(s), to take all steps necessary to engage BDO USA, LLP and BDO member firms as ICANN's independent audit firm(s) for fiscal year 2021 for any annual independent audit requirements in any jurisdiction.

      This furthers ICANN's accountability to its Bylaws and processes, and the results of the independent auditors' work will be publicly available. Taking this decision is both consistent with ICANN's Mission and in the public interest as the engagement of an independent auditor is in fulfilment of ICANN's obligations to undertake an audit of ICANN's financial statements and helps serve ICANN's stakeholders in a more accountable manner.

      This decision will have a fiscal impact on ICANN, which is accounted for in the ICANN Operating Plan and Budget. This decision should not have any direct impact on the security, stability and resiliency of the domain name system.

      This is an Organizational Administrative Function not requiring public comment.

    All members of the Board present voted in favor of Resolutions 2021.03.25.01 – 2021.03.25.03, 2021.03.25.04 – 2021.03.25.06, and 2021.03.25.07. The Resolutions carried.

  2. Main Agenda:

    1. Acceptance of the Second Organizational Review of the Security and Stability Advisory Committee (SSAC2) Final Implementation Report

      Avri Doria introduced the agenda item and led the Board in a discussion about the Final Implementation Report for the second Organizational Review of the Security and Stability Advisory Committee (SSAC). She noted that the SSAC has been working diligently to implement the recommendations from the review and has been reporting to the Board Organizational Effectiveness Committee during this time. The proposed action before the Board is to accept the Final Implementation Report. After discussion, the Board took the following action:

      Whereas, on 12 March 2020 the Board accepted the SSAC2 Review Detailed Implementation Plan and directed the SSAC2 Review Work Party to provide the Board with regular reporting on the implementation efforts.

      Whereas, the Security and Stability Advisory Committee Review Work Party (SSAC2 RWP), with SSAC approval and oversight, provided the Board via the Board Organizational Effectiveness Committee (OEC) with semi-annual updates on the progress of implementation efforts until such time that the implementation efforts concluded.

      Whereas, the SSAC2 RWP, submitted a Final Implementation Report on 3 December 2020, detailing the completion of implementation of the recommendations arising out of the second SSAC Review and documenting that three recommendations1 have limited components that are not yet fully implemented. The OEC acknowledged that the remaining steps of the SSAC2's implementation work have dependencies beyond the control of the SSAC.

      Whereas, the OEC recommends that the Board accept the SSAC2 Review Final Implementation Report issued by the SSAC2 RWP and approved by the SSAC on 3 December 2020, thereby completing the second SSAC Review; and requests that the SSAC provide a written or oral update to the OEC by 30 June 2021 on the three recommendations with limited components for which implementation is not yet fully completed and, if not completed by then, every six months thereafter until all implementation is completed.

      Resolved (2021.03.25.08), the Board accepts the Final Implementation Report of the second SSAC Review issued by the SSAC RWP approved by the SSAC, which marks the completion of this organizational review in accordance with Bylaws Article 4 Section 4.4. The Board encourages the SSAC to continue monitoring the impact of the implementation of the recommendations from the second Review of the SSAC as part of its continuous improvement process.

      Resolved (2021.03.25.09), the Board acknowledges the SSAC RWP's implementation work aimed at improving the SSAC's effectiveness, transparency, and accountability, in line with the proposed timeline as set out in the adopted SSAC2 Review Detailed Implementation Plan.

      Resolved (2021.03.25.10), the Board requests the SSAC to provide the OEC with a written or oral progress update on the remaining components of the three recommendations for which the implementation is not fully completed. In the event that implementation is not completed by 30 June 2021, the SSAC shall continue to provide such updates to the OEC on a six-monthly basis until such time that the implementation efforts conclude.

      All members of the Board present voted in favor of Resolutions 2021.03.25.08 – 2021.03.25.10. The Resolutions carried.

      Rationale for Resolutions 2021.03.25.08 – 2021.03.25.10

      Why is the Board addressing the issue?

      ICANN organizes independent reviews of its supporting organizations and advisory committees as prescribed in Article 4 Section 4.4 of the ICANN Bylaws, to ensure ICANN's multistakeholder model remains transparent and accountable, and to improve its performance.

      This action completes the second review of the SSAC and is based on the Final Implementation Report, as approved by the SSAC.

      Following the assessment of all pertinent documents by the Organizational Effectiveness Committee (OEC), the Board is now in a position to consider and accept the Final Implementation Report.

      Background: The independent examiner began its work in March 2018 and issued its Final Report in December 2018, including 30 recommendations. The SSAC published its Feasibility Assessment and Initial Implementation Plan in May 2019, with the Board accepting both and directing the implementation planning to start in June 2019. The Board accepted the Detailed Implementation Plan in March 2020. Note that six recommendations and/or the underlying issues provided by the independent examiner were not supported by the SSAC and consequently, these recommendations were not included in the Detailed Implementation Plan nor the Final Implementation Report (recommendations 7, 13, 17, 21, 22, and 23).

      What is the proposal being considered?

      The SSAC RWP submitted its Final Implementation Report to the OEC on 3 December 2020. The Final Implementation Report indicates that all 24 recommendations accepted by the Board have now been either completed, or integrated into ongoing SSAC processes, as documented in the SSAC Operational Procedures.

      Particularly, the implementation work for twelve recommendations resulted in the amendment several sections of the SSAC Operational Procedures issued on 12 February 2020: Sections 2.1.2 (Withdrawals and Dissents)2, 2.3 (New Member Selection)3, 2.5 (Annual Review Process)4, 2.6.1 (Affirmation of Confidentiality and Non-disclosure)5, 2.8.1 (SSAC Roles – Chair)6, 2.8.3 (SSAC Roles – SSAC Outward liaisons)7, 3.1 (SSAC Publication Procedures - Proposing, Selecting, and Planning a Work Product)8, 3.2.4 (SSAC Publication Procedures – Study and Primary Work – Preliminary Review)9, 3.4 (Publication, Promulgation, and Publicizing)10, 3.5 (Tracking, Review, and Follow-Up)11, Appendix B and F12.

      These twelve recommendations cover various aspects of SSAC operations:

      • documenting reviews and feedback from Board Liaison (recommendation 3),
      • capturing of information in the Board Action Request Register (ARR) (recommendation 4),
      • reviewing the implementation state of past and future advice provided to the ICANN Board (recommendation 5),
      • formalizing an annual process to set research priorities and identify SSR threats (recommendations 8),
      • updating skills in the SSAC's membership and recruitment processes (recommendation 9),
      • communicating on its decisions (recommendation 10),
      • explicitly discussing who affected parties may be in SAC-series document (recommendation 16),
      • identifying skills gap in the current membership (recommendation 24),
      • developing a formalized process to estimate its current and desired diversity (recommendation 25),
      • ensuring ensure that the effectiveness of an external liaison and the individual in the role are reviewed on a regular basis (recommendation 26),
      • and limiting SSAC's leadership to two, three-year terms, and imposing no term limits on non-leadership members (recommendation 27).

      In addition, the implementation of recommendation 28 resulted in a Bylaws amendment for there to be term limits on the SSAC Chair. This suggests that the impact of the implementation of these recommendations will continue on as part of the ongoing processes, supporting the continuous improvement orientation of the SSAC as they operationalize and continue to follow the modified procedures on a go forward basis.

      SSAC RWP reported that eight recommendations (1, 2, 11, 14, 15, 19, 20, 30) did not require implementation work because the recommended steps are already part of the SSAC processes and operations.

      Moreover, limited components of implementation work for recommendations 18, 24 and 25, are dependent on factors beyond the control of the SSAC. The recommendations pertain to consolidating information online and increasing transparency (recommendation 18), identifying skills gap in the current membership (recommendation 24), developing a formalized process to estimate its current and desired diversity (recommendation 25) and while significant work was implemented, components of these recommendations could not be considered fully implemented due to the non-publication of photographs of SSAC members on the SSAC public-facing webpage (recommendation 18), and the lack of face-to face opportunities due to the COVID-19 cancellations of ICANN meetings (recommendations 24, 25). However, SSAC is planning to address the last component of recommendation 18 once the new SSAC public-facing webpage is published, and will also approach ICANN regional staff to assist with outreach pertaining to implementation of recommendation 24 and 25.

      Which stakeholders or others were consulted?

      The Board, through the OEC, consulted with the SSAC2 RWP, who was responsible for the implementation, and monitored the progress of the review as well as the progress of the implementation of review recommendations.

      What concerns, or issues were raised by the community?

      The implementation work conducted by the SSAC followed its standard best practices to ensure transparency and accountability. No concerns were voiced by the community.

      What significant materials did the Board review?

      The Board reviewed relevant Bylaws sections, Organizational Review Process documentation, SSAC2 Review Implementation Plan, its first six-monthly implementation progress report and the final implementation report.

      What factors did the Board find to be significant?

      The Board found several factors to be significant, contributing to the effective completion of the implementation work:

      • SSAC's commitment to its continuous improvement.
      • Convening a dedicated group that oversees the implementation of Board-accepted recommendations.
      • Adherence to the implementation plan that included a timeline for the implementation, definition of desired outcomes, as well as ways to measure current state and progress toward the desired outcome.
      • Timely and thorough reporting on the progress of implementation.

      Are there positive or negative community impacts?

      This Board action is expected to have a positive impact on the community by acknowledging and highlighting an effective completion of implementation of SSAC2 Review Recommendations. The completed implementation of the SSAC2 organizational review demonstrates SSAC's commitment to continuous improvement.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      This Board action is anticipated to have no additional fiscal impact. The Board notes that most recommendations require the help of the ICANN org SSAC support staff to execute, which would be done as part of support staff's standard duties. The ramifications of this resolution on the ICANN organization, the community and the public are anticipated to be positive, as this Board action signifies an important milestone for organizational reviews.

      Are there any security, stability or resiliency issues relating to the DNS?

      This Board action is not expected to have a direct effect on security, stability or resiliency issues relating to the DNS.

      How is this action within ICANN's mission and what is the public interest served in this action?

      The Board's action is consistent with ICANN's commitment pursuant to Article 4, Section 4.1 of the Bylaws to ensure ICANN's multistakeholder model remains transparent and accountable, and to improve the performance of its supporting organizations and advisory committees. This action will serve the public interest by fulfilling ICANN's commitment to maintaining and improving its accountability and transparency.

      Is public comment required prior to Board action?

      This is an Organizational Administrative Function not requiring public comment.

    2. Accepting Name Collision Analysis Project (NCAP) Study 1 and Proceeding with Study 2

      Akinori Maemura introduced the agenda item and provided the Board with an update about the studies associated with the Name Collision Analysis Project. He stated that the Board Technical Committee has been examining the project and is recommending that the Board proceed with initiating a redesigned version of Study 2.

      Merike Käo explained the changes that are part of the redesigned Study 2, noting the removal of two original study goals and the expansion and added detail of other study goals. She also stated that as part of the redesigned Study 2, the NCAP discussion group would undertake most of the work, which was slated to be completed by paid contractors in the original version of Study 2.

      After discussion, the Board took the following action:

      Whereas, in 2017 the Board passed resolutions 2017.11.02.29 - 2017.11.02.31 asking a series of questions about name collisions.

      Whereas, the ICANN Security and Stability Advisory Committee (SSAC) responded with a proposal for three studies intended to address the Board's questions.

      Whereas, SSAC and the Office of the Chief Technology Officer (OCTO) within ICANN org worked together to produce a mutually agreed revised proposal for NCAP Study 1.

      Whereas, in April 2019 the Board directed ICANN org to proceed with NCAP Study 1 and authorized the associated expenditures for that purpose.

      Whereas, ICANN org engaged Scarfone Cybersecurity, an independent contractor, to research and write NCAP Study 1.

      Whereas, on 30 June 2020, ICANN org sent the final version of NCAP Study 1 to the Board Technical Committee (BTC) after two public comment periods on the draft and final versions of the report.

      Whereas, NCAP Study 1 recommended that NCAP Studies 2 and 3 not proceed as currently designed.

      Whereas, the NCAP Discussion Group (DG) revised the design of NCAP Study 2 to take into account the issues raised by NCAP Study 1.

      Whereas, on 5 February 2021, the NCAP DG leadership presented the revised design of NCAP Study 2 to the BTC for approval.

      Resolved (2021.03.25.11), the Board reiterates its thanks to the SSAC for its work in responding to the November 2017 resolution and developing an initial proposal for the NCAP and subsequent revisions to that proposal.

      Resolved (2021.03.25.12), the Board thanks the NCAP DG for its contributions to NCAP Study 1.

      Resolved (2021.03.25.13), the Board affirms the continued relevance of the nine questions related to name collisions presented in Board resolutions 2017.11.02.29 - 2017.11.02.31, especially questions (7) and (8) concerning criteria for identifying collision strings and determining if collision strings are safe to be delegated.

      Resolved (2021.03.25.14), the Board directs the NCAP DG to proceed with Study 2 as redesigned, and directs the President and CEO, or his designee(s), to participate in Study 2 in the manner indicated in the redesigned proposal.

      All members of the Board present voted in favor of Resolutions 2021.03.25.11 – 2021.03.25.14. The Resolutions carried.

      Rationale for Resolutions 2021.03.25.11 – 2021.03.25.14

      Name collision refers to the situation where a name that is defined and used in one namespace may also appear in another. A "namespace" in this context refers to all possible names that can be resolved, e.g., the public DNS namespace as administered by ICANN through the IANA functions or a "private" namespace that is limited to an enterprise network. Users and applications intending to use a name in one namespace may attempt to use it in a different one (typically accidentally due to misconfigurations), and unexpected behavior may result where the intended use of the name is not the same in both namespaces. An example of name collision outside the DNS would be calling out a common person's name in a closed environment like a company lunch room versus calling out that name in a crowded public space: in the first case, the intended person is likely to respond whereas in the latter case, multiple people may respond.

      On 2 November 2017, the ICANN Board passed resolutions 2017.11.02.29 - 2017.11.02.31 requesting SSAC to conduct studies to present data, analysis, and points of view, and provide advice to the Board regarding the risks posed to users and end systems if .CORP, .HOME, .MAIL strings were to be delegated in the root, as well as possible courses of action that might mitigate the identified risks. The Board also asked nine questions related to the definition of name collision, user experience and possible harm, causes of collisions, potential risks, and possible mitigations, among other topics related to name collisions.

      Following the Board resolution, the SSAC began project planning in December 2017 for the work necessary to address the Board's requests. In January 2018, the SSAC NCAP Work Party ("NCAP WP") was formed and prepared a plan calling for three studies. Also created was the NCAP Administration ("NCAP Admin"), a smaller group comprising the NCAP WP leadership and SSAC leadership, which guides the NCAP effort both within SSAC and in the larger ICANN community.

      In June 2018, the ICANN organization's CEO, after input from the Board, assigned OCTO to be responsible for completing the NCAP studies since SSAC did not have the administrative infrastructure or the resources to undertake and manage such a large project.

      In September 2018, SSAC published "SSAC Proposal for the Name Collision Analysis Project", which proposed three consecutive studies to address the Board's request. OCTO proposed minor changes to the proposal and, after discussion between SSAC and OCTO, an updated version of the proposal was published in February 2019.

      In April 2019, the NCAP DG was formed to allow interested members of the larger ICANN community to also participate in the NCAP effort. The NCAP DG consists of both the SSAC NCAP WP and any interested community members.

      Due to resource constraints, OCTO chose to outsource the completion of Study 1 to a contractor. An RFP for the work was published on 9 July 2019 and in September 2019, Scarfone Cybersecurity was selected in accordance with ICANN org's standard procurement processes. Study 1 was the result of a collaborative effort between Scarfone Security, NCAP DG and ICANN org. Every draft of the study during each Public Comment proceedings was met with various comments and points of discussion before the publication of the final report. The final Study 1 report was published on 19 June 2020.

      The major findings of Study 1 can be summarized as follows:

      1. Name collisions have been a known problem for decades but published work only began to appear starting in 2012. The only known work on name collisions in the past few years has been done within the ICANN community by the NCAP DG and the New gTLD Subsequent Procedures PDP Working Group ("SubPro WG").
      2. Few instances of name collisions were reported to ICANN or publicly since controlled interruption was instituted. Only one of the reports to ICANN necessitated action by a registry, and none of the public reports surveyed mentioned major harm to individuals or organizations.
      3. There are several root causes of name collisions but these have typically been found researching a specific leaked TLD, not by examining datasets.
      4. No gaps or other issues were identified in accessing datasets that would be needed for Studies 2 and 3.

      Study 1 goes on to state:

      Given these findings, the recommendation is that Studies 2 and 3 should not be performed as currently designed. Regarding Study 2, analyzing datasets is unlikely to identify significant root causes for name collisions that have not already been identified. New causes for name collisions are far more likely to be found by investigating TLD candidates for potential delegation on a case by case basis. Regarding Study 3, controlled interruption has already proven an effective mitigation strategy, and there does not appear to be a need to identify, analyze, and test alternatives for the vast majority of TLD candidates. (Executive Summary, p. v)

      In response to the findings of Study 1, the NCAP DG redesigned Study 2 and made several major changes: (1) the removal of two original study goals, (2) the expansion and added detail of other study goals, and (3) having the NCAP DG undertake most of the work which was slated for paid contractors in the original version of the Study 2 proposal. These modifications dramatically reduce the scope, level of effort, total costs, and resources required to execute Study 2.

      NCAP DG will undertake a significant portion of the work in the redesigned Study 2, while ICANN will provide project management support and engage a technical writer and a technical investigator to assist with preparation of the Study. The estimated costs to ICANN org for the redesigned Study 2 fall below the threshold required for Board approval and are therefore not described further here.

      The BTC affirms that the questions related to name collisions posed in Board resolutions 2017.11.02.29 - 2017.11.02.31 are still relevant. The BTC emphasizes the particular importance of questions (7) and (8) regarding the criteria for identifying collision strings and determining if collision strings are safe to be delegated.

      The Board's action is expected to have a positive impact on the security, stability and resiliency of the Internet's DNS, as it is designed to continue to study name collisions. This action also serves ICANN's mission in ensuring a secure and stable operation of the Internet's unique identifier systems. This resolution is in the public interest in meeting ICANN's core value of preserving and enhancing the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet.

      The Board's action is an Organizational Administrative Function not requiring public comment.

    3. Operational Design Phase for System for Standardized Access/Disclosure to Non-Public Registration Data (SSAD)

      Becky Burr introduced the agenda item. She explained that in September 2020, the GNSO Council approved the recommendations from the Final Report of Phase 2 of the Expedited Policy Development Process concerning the Temporary Specification for gTLD Registration Data. Becky noted that the that policy recommendations contain many complex issues, including recommendations 1 through 18 regarding a system for standardized access disclosure, or SSAD, to handle requests for nonpublic registration data. She stated that the Board could benefit from additional due diligence and information when making a decision about whether to approve the policy recommendations, which could be accomplished by having ICANN org proceed with the recently developed process called the Operational Design Phase (ODP). Becky highlighted that the ODP would produce an operationally focused assessment, and that the proposed Board action to initiate the ODP would not foreclose the ongoing public comment period on the Final Report.

      Göran Marby thanked the community for their interaction and feedback in developing the ODP. Sarah Deutsch acknowledged concerns raised by potential users of the SSAD about the system being effective for its stated purpose and widely used. She noted that the Board would take these concerns into account along with the Final Report, the public comments, and the assessment from the ODP.

      After discussion, the Board took the following action:

      Whereas, on 24 September 2020 the GNSO Council voted to approve all of the recommendations in its Final Report on the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP) Phase 2.

      Whereas, the Board has begun its deliberations to consider whether the recommendations in the EPDP Phase 2 Final Report are in the best interests of ICANN community or ICANN.

      Whereas, the Board wishes to utilize the newly developed Operational Design Phase process to assess the recommendations and to gather more information as part of its deliberations.

      Whereas, the Board notes that on 5 May 2020 a Discussion Paper: ICANN org Cost Estimate for EPDP Phase 2 Team's Proposed System for Standardized Access/Disclosure was provided to the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP) Phase 2 Working Group by ICANN org that included an estimate of the costs associated with the start-up and ongoing operations related to the team's proposed system requirements during the Policy Development Process.

      Resolved (2021.03.25.15), the Board directs the President and CEO, or his designee(s), to proceed with the Operational Design Phase for GNSO Council-approved recommendations (#1-18) from the EPDP Phase 2 Final Report on the System for Standardized Access and Disclosure.

      Resolved (2021.03.25.16), the Board directs the President and CEO, or his designee(s), to conduct the Operational Design Phase by addressing the questions outlined in the System for Standard Access/Disclosure to Non-Public Registration Data Operational Design Phase Scoping Document and that the final Operational Design Assessment be delivered to the Board six months from the date of the Board's request, provided that there are no unforeseen legal or other matters that could affect the timeline. In the event that unforeseen circumstances arise, the Board directs the President and CEO, or his designee(s), to notify and discuss such with the Board and provide an updated timeline for the appropriate next steps with respect to the Operational Design Assessment.

      Resolved (2021.03.25.17), the Board directs the President and CEO, or his designee(s), to consider the 5 May 2020 ICANN org Cost Estimate Discussion Paper during the Operational Design Phase for GNSO Council-approved recommendations (#1-18) from the EPDP Phase 2 report on the System for Standardized Access and Disclosure.

      All members of the Board present voted in favor of Resolutions 2021.03.25.15 – 2021.03.25.17. The Resolutions carried.

      Rationale for Resolutions 2021.03.25.15 – 2021.03.25.17

      Why is the Board addressing the issue?

      Due to the resource investment and complexity that would likely be required to implement the SSAD-related policy recommendations in a timely and predictable manner, initiating an ODP is essential to inform the Board's deliberations, including whether the recommendations are in the best interests of the ICANN community or ICANN. The ODP work will assess the potential risks, anticipated costs, resource requirements, timelines, and other matters related to implementation of the SSAD-related recommendations. It will also transparently provide the Board with relevant information regarding the recommendations in support of the Board's obligation to act on the GNSO recommendations in accordance with the Bylaws. Additionally, the GNSO Council in its 22 January 2021 letter recommended the Board review the original "cost estimate discussion paper" published by ICANN org on 20 May 2020, and subsequently requested a consultation with the ICANN Board to discuss "whether a further cost-benefit analysis should be conducted before the ICANN Board considers all SSAD-related recommendations for adoption." The initiation of the Operational Design Phase will aid in the Board's consultation with the GNSO Council.

      What is the proposal being considered?

      The Board is taking action at this time to initiate the ODP and directs ICANN org to prepare an assessment of the operational requirements and impact of the SSAD-related recommendations as per the scope specified by the Board for the purpose of informing the Board's deliberation of the recommendations.

      Which stakeholders or others were consulted?

      The EPDP Phase 2 Team published its Initial Report on priority 1 recommendations on 7 February 2020 and the Addendum to the Initial Report, covering Priority 2 recommendations, on 26 March 2020. Both the Initial Report and Addendum to the Initial Report were subject to Public Comment Proceedings. The Final Report was delivered to the GNSO Council on 31 July 2020. Minority Statements from stakeholder groups were accepted through 24 August 2020, and all statements received by the deadline were incorporated into the Final Report.

      In its 29 October 2020 letter transmitting the EPDP Phase 2 team's recommendations to the Board, the GNSO Council requested a consultation with the ICANN Board regarding recommendations #1-18, which outlines the policy for the SSAD. In its 1 December 2020 letter, the Board "acknowledged the GNSO Council's request for a consultation on the SSAD-related recommendations" and noted its plan to "initiate an Operational Design Phase to assess the operational impact of the GNSO Council-approved consensus recommendations." On 8 February 2021, the Board initiated the public comment forum on the SSAD-related recommendations. The public comment forum is expected to close on 30 March 2021.

      Additionally, the ODP is a new process that was developed with community input. The first iteration of the ODP concept was published on 1 October 2020. The community and ICANN org discussed the contents of the concept paper during ICANN69. The second version of the ODP was published on 17 December 2020. The ICANN org conducted a community webinar on 13 January 2021 to facilitate a discussion on the updates provided in the subsequent draft of ODP and to receive additional community feedback.

      What concerns or issues were raised by the community?

      The community provided extensive feedback regarding the SSAD, including its financial implications. The following concerns were among those shared in public comments and minority statements on the EPDP Phase 2 Final Report, as well as in correspondence received by ICANN org, and in other settings:

      • The SSAD does not fulfill the needs of the community by providing access to specific accurate non-public data in a timely predictable manner.
      • The SSAD bears significant operational costs and lacks flexibility to ensure it is suitable.
      • The SSAD falls short of addressing the security, stability, reliability of the DNS system.
      • The SSAD includes insufficient mechanisms for evolution.
      • The SSAD may disrupt a stable, predictable and workable access mechanism for the non-public WHOIS information.

      The community also provided feedback during the development of the ODP raising the following concerns:

      • The ODP could provide an opportunity for stakeholder groups to reopen or revisit policy questions that were already settled during the policy development process.
      • The ODP would alter the roles and responsibilities of ICANN org and the Implementation Review Team that is formed after the Board has adopted the GNSO council recommendations.
      • The ODP would modify the role of the GNSO Council as the manager of the Policy Development Process.

      What significant materials did the Board review?

      The Board reviewed the following materials

      • The 5 May 2020 cost analysis discussion paper, produced by ICANN org for the EPDP Phase 2 team, which provides an estimate of the costs associated with the start-up and ongoing operations related to the proposed system requirements.
      • The 24 September 2020 GNSO Council resolution of the EPDP Phase 2 Final report recommendations.
      • The EPDP Phase 2 Final report, received from the GNSO Council, which includes recommendations #1-18 which addresses the System for Standardized Access and Disclosure (SSAD).
      • The GNSO Council 29 October 2020 correspondence requesting a Board and GNSO Council consultation prior to the Board's deliberations on the policy recommendations.
      • The GNSO Council's 22 January 2021 letter recommended the Board review and update the original cost estimate discussion paper along with suggested topics for operational impact assessment.

      What factors did the Board find to be significant?

      The Board considered factors outlined in the cost estimate analysis and the complexity of the SSAD-related recommendations as they propose a new system for ICANN. The Board understands from the community that there are concerns regarding the financial implications and the cost versus benefit of the SSAD. The Board also understands from potential users of the SSAD in the community that there are concerns that such system be effective for its stated purpose and be widely used. The information collection effort will include consideration of the effectiveness of the SSAD and measures to ensure its broad adoption and use. If the recommendations are approved by the Board, the SSAD is a new system that ICANN org will build and potentially operate. The implementation and operation of the SSAD will require significant investments and resources. Furthermore, data protection laws such as the General Data Protection Regulation (GDPR) have significantly impacted ICANN org and WHOIS registration data. It is possible that other laws and legal uncertainties may arise during the ODP period that could also significantly impact ICANN org and WHOIS registration data. Thus, ICANN org needs to ensure that the SSAD is designed in a manner that complies with all laws and supports the DNS globally.

      Are there positive or negative community impacts?

      ICANN org will incorporate feedback mechanisms such as webinars to communicate with the community on the progress of the ODP thus enhancing the transparency of the Board consideration of the GNSO council-approved policy recommendations. The ODA will also provide further clarity on the policy recommendations, thus will likely reduce the time ICANN org and the Implementation Review Team spend on designing processes during the implementation phase.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      This resolution will involve dedicating significant organizational resources to completing the ODP during the time period outlined in the scoping document. The community will be asked to provide feedback throughout this time period.

      Are there any security, stability or resiliency issues relating to the DNS?

      The ODP will consider the impact the SSAD may have on the security, stability or resiliency of the DNS.

      Is this decision in the public interest and within ICANN's mission?

      In its evaluation, the Board will explore what, if any, are the public interest considerations within the EPDP Phase 2 recommendations. The mechanism for ascertaining the relevant public interest on a given recommendation will be the global public interest procedural framework that the Board is piloting in FY21. The framework will be used as an evaluative tool only for recommendations with public interest considerations.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      This is an Organizational Administrative Function that does not require public comment, but it should be noted that the Final Report of policy recommendations and the ODP framework were the subject of public comment as discussed above. Additionally, the ODP itself is an open and transparent process and it is foreseen that the public will be able to provide comments and feedback throughout the design phase.

    4. AOB

      The Chair provided an update on interactions between the Board and the GAC through the Board-GAC Interaction Group (BGIG) to address the ICANN69 GAC Communiqué. He noted that although there was no consensus advice in the Communiqué, the GAC identified three issues of importance. These issues were discussed on the BGIG conference call as well as procedural questions related to the Board/GAC Bylaw consultation process in relationship to protections for IGOs.

      The Chair noted these activities for the record and expressed respect and appreciation for the GAC and its work in producing the Communiqués. Becky Burr expressed thanks for the opportunities to engage during BGIG meetings. Manal Ismail thanked the Board for treating with due care the topics of importance identified in the GAC Communiqué, as well as the open channel between the Board and the GAC for productive interactions.

      The Chair called the meeting to a close.

Published on 6 April 2021


1 Recommendations 18, 24 and 25

2 Recommendation 29

3 Recommandations 24, 25, 29

4 Recommendation 29

5 Recommendation 29

6 Recommendation 27

7 Recommendation 26

8 Recommendations 8, 9, 10

9 Recommendation 16

10 Recommendation 3

11 Recommendations 4, 5

12 Recommendation 29

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