Skip to main content
Resources

Approved Board Resolutions | Special Meeting of the ICANN Board

  1. Consent Agenda:
    1. Singapore Office Lease Renewal
    2. Payment of Legal Invoices
    3. IANA Naming Function Review (IFR) Final Report
    4. SAC045: SSAC Advisory on Invalid Top Level Domain Queries at the Root Level of the Domain Name System (DNS)
    5. SAC062: Advisory Concerning the Mitigation of Name Collision
    6. SAC065: SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure
    7. SAC070: Security and Stability Advisory Committee (SSAC) Advisory on the Use of Static TLD / Suffix Lists
  2. Main Agenda:
    1. FY22-26 Operating and Financial Plan and FY22 Operating Plan and Budget Approval
    2. Transfer to Reserve Fund and Creation of Supplemental Fund for Implementation of Community Recommendations (SFICR)
    3. SAC063, SAC073 and SAC102 regarding the DNSSEC Key Rollover in the Root Zone
    4. GAC Advice: ICANN70 Communiqué (25 March 2021)

 

  1. Consent Agenda:

    1. Singapore Office Lease Renewal

      Whereas, ICANN's Singapore office lease is expiring in September 2021 and ICANN org recommends remaining at the current Singapore office location and entering into a new [TERM REDACTED FOR NEGOTIATION PURPOSES] lease.

      Whereas, the Board Finance Committee has reviewed the financial implication of the [TERM REDACTED FOR NEGOTIATION PURPOSES] lease.

      Whereas, both ICANN organization and the Board Finance Committee have recommended that the Board authorize the President and CEO, or his designee(s), to take all actions necessary to execute a new [TERM REDACTED FOR NEGOTIATION PURPOSES] lease for ICANN's current Singapore office location with [REDACTED FOR NEGOTIATION PURPOSES], and to make all necessary disbursements pursuant to the lease.

      Resolved (2021.05.12.01) the Board authorizes the President and CEO, or his designee(s), to take all necessary actions to execute a new [TERM REDACTED FOR NEGOTIATION PURPOSES] lease for ICANN's current Singapore office location with [REDACTED FOR NEGOTIATION PURPOSES], and to make all necessary disbursements pursuant to the lease.

      Resolved (2021.05.12.02), specific items within this resolution shall remain confidential for negotiation purposes pursuant to Article 3, section 3.5(b) of the ICANN Bylaws until the President and CEO determines that the confidential information may be released.

      Rationale for Resolutions 2021.05.12.01 – 2021.05.12.02

      ICANN organization believes face to face interaction, including that which occurs at regional offices, is essential to carry out its work and mission. Although the org has been effectively operating remotely during pandemic, the goal is to return to offices to support staff, and eventually community, collaboration at ICANN's physical office locations.

      ICANN has occupied [REDACTED FOR NEGOTIATION PURPOSES] of the South Beach Tower in Singapore since October 2018. The 3-year lease previously signed [REDACTED FOR NEGOTIATION PURPOSES] is at a rental rate of [REDACTED FOR NEGOTIATION PURPOSES]. That lease is expiring in September 2021. After collaborating with a local broker, surveying other properties, and negotiating rental rates, ICANN organization recommends staying at the existing location with the square feet unchanged.

      The proposed agreement is for a [REDACTED FOR NEGOTIATION PURPOSES] This equates to [REDACTED FOR NEGOTIATION PURPOSES] which is a nominal increase over the [REDACTED FOR NEGOTIATION PURPOSES] that ICANN organization currently incurs for the Singapore office.

      The size of the space is sufficient because there are no plans to materially increase headcount at the Singapore office. After a 3-year lease at the current location, ICANN org recommends a [REDACTED FOR NEGOTIATION PURPOSES] lease to achieve favorable rental terms and to provide stability for the Singapore staff. Over the past seven months, ICANN org engaged a local broker and evaluated multiple properties and office spaces. Rental costs at comparable properties are in line with those reflected in the new lease. Therefore, moving to a new location would not provide significant cost savings, especially after factoring the time and cost to relocate. In addition, the costs reflected in the new lease are affordable as they are nearly the same as the prior rental costs that ICANN incurred.

      Executing the new Singapore lease is in the public interest as it maintains ICANN a presence in the APAC region, including the ability to eventually host meetings and collaborate with local stakeholders and community members.

      The fiscal impact is a nominal [REDACTED FOR NEGOTIATION PURPOSES] increase in average costs per month. There is no anticipated impact to the security, stability, and resiliency of the domain name system as a result of this action.

      This is an Organizational Administrative function that does not require public comment.

    2. Payment of Legal Invoices

      Whereas, there has been, and will continue to be until conclusion, extensive activity in the [REDACTED – PRIVILEGED AND CONFIDENTIALFOR NEGOTIATION PURPOSES], resulting in significant outside legal counsel fees and IRP Panel fees.

      Whereas, ICANN org and the Board Accountability Mechanisms Committee have recommended that the Board approve a tranche of money in the amount of [REDACTED – PRIVILEGED AND CONFIDENTIAL] in the [REDACTED – PRIVILEGED AND CONFIDENTIAL] to pay upcoming outside legal invoices and IRP Panel fees, and authorize the President and CEO, or his designee(s), to make disbursements up to this amount.

      Resolved (2021.05.12.03), the Board hereby approves a tranche of money in the amount of [REDACTED – PRIVILEGED AND CONFIDENTIAL] in the [REDACTED – PRIVILEGED AND CONFIDENTIAL] to pay upcoming outside legal fees and IRP Panel fees, and authorizes the President and CEO, or his designee(s), to make disbursements up to this amount, and of any amount of fees and costs that exceeds this tranche unless they exceed or are expected to exceed an additional US$500,000 in the matter.

      Resolved (2021.05.12.04), specific items within this resolution shall remain confidential pursuant to Article 3, sections 3.5(b) and (d) of the ICANN Bylaws.

      Rationale for Resolutions 2021.05.12.03 – 2021.05.12.04

      When required, ICANN must engage outside legal counsel to help prepare for and defend against all types of disputes that are brought against ICANN. When those disputes become highly contentious, they often require significant involvement during a certain time period by outside counsel and that significant amount of time also results in significant fees and related expenses.

      Per ICANN's Contracting and Disbursement policy (https://www.icann.org/resources/pages/contracting-disbursement-policy-2015-08-25-en), if any invoice calls for disbursement of more than $500,000, Board approval is required to make the payment. In furtherance of the new process for legal invoice approval developed to enhance transparency and predictability to the Board, the organization has provided the Board with an explanation of the upcoming activity in the [REDACTED – PRIVILEGED AND CONFIDENTIAL], including anticipated workload and expected billing amounts for the remainder of the proceeding. Accordingly, the Board has been asked by the organization to approve a tranche of money to pay estimated upcoming outside legal fees and IRP Panel fees in the [REDACTED – PRIVILEGED AND CONFIDENTIAL], which the Board Accountability Mechanisms Committee has reviewed and recommended, and which the Board has done through this resolution.

      The Board is comfortable that ICANN organization, including ICANN's General Counsel's Office, is properly monitoring the work performed and expenses incurred by outside legal counsel to ensure that all fees and costs are appropriate under the given circumstances at any given time. Therefore, the Board is comfortable taking this decision.

      Taking this Board action fits squarely within ICANN's mission and the public interest in that it ensures that payments of large amounts for one matter are reviewed and evaluated by the Board as appropriate in accordance with ICANN's Contracting and Disbursement Policy. This ensures that the Board is overseeing large disbursements and acting as proper stewards of the funding ICANN receives from the public.

      While this will have a fiscal impact on ICANN, it is an impact that was contemplated in the FY21 budget and will be included in upcoming budgets as appropriate. This decision will not have an impact on the security, stability or resiliency of the domain name system.

      This is an Organizational Administrative Function that does not require public comment.

    3. IANA Naming Function Review (IFR) Final Report

      Whereas, on 16 September 2018, the first IANA Naming Function Review (IFR) was convened by the ICANN Board, in compliance with Article 18 of the ICANN Bylaws which state: "The Board, or an appropriate committee thereof, shall cause periodic and/or special reviews (each such review, an "IFR") of PTI's performance of the IANA naming function against the contractual requirements set forth in the IANA Naming Function Contract and the IANA Naming Function SOW to be carried out by an IANA Function Review Team ("IFRT") established in accordance with Article 18."

      Whereas, the IANA Naming Function Review Team (IFRT) received no objections to the recommendations in the Initial Report published in a Public Comment that ended on 02 December 2020.

      Whereas, the IFRT submitted an IFR Final Report containing four (4) recommendations to the ICANN Board for consideration on 8 April 2021.

      Whereas, the IFR Final Report is the culmination of thirteen (13) months of work by sixteen (16) community members and liaisons.

      Whereas, one of the IFR recommendations is for an amendment to the IANA Naming Function Contract. Section 18.6 of the ICANN Bylaws sets out procedural requirements before the Board may consider such an amendment. Each of those procedural requirements has been met, including public comment; ccNSO Council supermajority approval on 18 February 2021; and GNSO Council supermajority approval on 24 March 2021. The Board now has 45 days within which to consider the Recommendation.

      Resolved (2020.05.12.05) the Board acknowledges the IFRT's Final Report and thanks the members and liaisons for their efforts.

      Resolved (2020.05.12.06) the Board accepts all four of the Recommendations within the IFR Final Report, as each is in the best interests of ICANN and the global public interest. The Board directs the ICANN President and CEO, or his designee(s) to take all necessary steps to implement the recommendations after any applicable Empowered Community process concludes.

      Rationale for Resolutions 2021.05.12.05 – 2021.05.12.06

      Why the Board is addressing the issue?

      Board consideration of the recommendations of the IANA Naming Function Review (IFR) is a required and essential step of the IFR Process. The Board welcomes the work of the very first of the IFR teams, and thanks them for their work and diligence in the first testing of the IFR process. Additionally, under the Bylaws, the Board must take action on Recommendation 4, regarding an amendment to the IANA Naming Function Agreement, within 45 days of the last procedural requirement to support the Board's action. That last requirement was met on 24 March 2021 when the GNSO Council approved the proposed amendment. The Board now is acting on all of the IFR recommendations as set out in the scorecard, "Final IFR Recommendations for Board Action".

      What is the proposal being considered?

      The IFRT issued four (4) recommendations, set out below and in detail in the scorecard, "Final IFR Recommendations for Board Action":

      Recommendation 1: that PTI publishes the IANA functions transition plan as required by the IANA Naming Function Contract.

      Recommendation 2: that the Annual Attestation that PTI has complied with the requirements of Section 6.1 of the IANA Naming Function Contract be posted on https://www.iana.org/ annually.

      Recommendation 3: The IFRT, in conjunction with the CSC, has identified a duplication in the ICANN Bylaws. The remedial action procedures as generated by the CSC and PTI are referred to as components in the initiation of the Special IFR as outlined in Section 18.12.a of the ICANN

      Bylaws. However, the CSC and the IFRT have identified that section 18.12.a (ii) is redundant as the RAP and the IANA problem resolution process were combined into a single set of procedures (the RAPs) by the CSC. The recommendation is that the ICANN Board consider removing the redundant section 18.12.a (ii).

      Recommendation 4: In Article 7 Section 7.1 (a), the IFRT recommends that this statement, "The relevant policies under which the changes are made shall be noted within each monthly report [Root Operations Audit Reports]," be removed from the contract as it is a legacy statement from the National Telecommunications and Information Administration (NTIA) contract that is no longer required. Implementation of this requirement has long been recognized as being operationally impracticable ever since the time of the NTIA contract, and the IFRT is satisfied that its continued inclusion in the contract adds no value to the reports.

      ICANN org identifies no concerns with the recommendations as proposed by the IFR. Recommendations 1 and 2, related to publication of existing documentation, have already been completed by ICANN org as part of its commitment to transparency. To the extent applicable, the Board understands that ICANN org's implementation of those recommendations will identify how to bring those publication practices into standard operating procedures.

      ICANN org recommended to the Board's Organizational Effectiveness Committee (OEC), that it is appropriate for all recommendations to be accepted, and the OEC, in March 2021, agreed to recommend the same to the Board.

      Which stakeholders or others were consulted?

      The IFRT consulted with IANA functions subject matter experts, and on multiple occasions with the CSC. Personnel from the IANA Functions served as liaison to the IFR and contributed to the deliberations. The IFRT also convened a public comment on the Initial Draft of the Report.

      Under the ICANN Bylaws, Recommendation 4 required additional consultations as it requires a IANA Naming Function Contract amendment. Per ICANN Bylaws, Article 18, Section 18.5.d.(a):

      "The IFRT may recommend, among other things to the extent reasonably related to the IFR responsibilities set forth in Section 18.3, amendments to the IANA Naming Function Contract, IANA Naming Function SOW and/or the CSC Charter. The IFRT shall, at a minimum, take the following steps before an amendment to either the IANA Naming Function Contract, IANA Naming Function SOW or CSC Charter is proposed:

      (i) Consult with the Board (such consultation to be conducted in parallel with other processes set forth in this Section 18.6(a)) and PTI;

      (ii) Consult with the CSC;

      (iii) Conduct a public input session for ccTLD and gTLD registry operators; and

      (iv) Seek public comment on the amendments that are under consideration by the IFRT through a public comment period that complies with the designated practice for public comment periods within ICANN."

      The IFRT consulted regularly with PTI through Kim Davies, Vice President, IANA Functions, who served as a liaison to the IFR. The IFRT also consulted with the CSC, with the ICANN Board, and performed a community webinar. The CSC and the Board responded that there were no concerns, while no issues were brought up during the community webinar.

      Two public comments were held. The first, from 8 October 2020 to 2 December 2020, requested input on the IFRT's Initial Report and all the recommendations. That public comment forum received six comments, with all six supporting all of the IFR's recommendations with no objections stated.From 10 February 2021 to 22 March 2021 a public comment was held specifically on Recommendation 4. Three comments were submitted, all of which approved of the recommendation, with no objections stated.

      In parallel with the second public comment, the ccNSO Council and GNSO Council were consulted and each approved Recommendation 4 with a supermajority vote.

      What concerns or issues were raised by the community?

      No substantive issues were raised during the two (2) public comments or through other engagements.

      Under the Bylaws, the Empowered Community will have an opportunity to consider whether it will reject the Board's acceptance of Recommendation 4, which represents a final opportunity for the community to raise concerns.

      What significant materials did the Board review?

      The Board reviewed the IFRT's Final Report.

      What factors did the Board find to be significant?

      ICANN org, including the IANA team, recommended all four recommendations be approved by the Board. Additionally, both the public comment for the Initial Report and the public comment for Recommendation 4 received support from all the comments submitted.

      Are there positive or negative community impacts?

      Taking action on these recommendations will contribute to ensuring ICANN meets its commitments relative to its performance of the IANA naming function. The first two recommendations ensure that the performance of the IANA naming function is in full compliance with the IANA Naming Function Contract by publishing all documents as required by the contract.

      Recommendation three (3) and four (4) each focus on a misalignment against current practices that occur within the Bylaws and the IANA Naming Function Contract and call for minor corrections.

      Together, all four (4) recommendations ensure that the IANA Naming Function is performed in alignment with all obligations defined within the IANA Naming Function Contract and the Bylaws.

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

      No fiscal impacts or ramifications on ICANN, the community, or the public are expected as a result of implementing the IFRT's recommendations.

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

      No security, stability or resiliency issues relating to the DNS are expected as a result of implementing the IFRT's recommendations.

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

      This action is within ICANN's Mission and mandate as it is a critical part of how ICANN performs its mission based role of coordinating the allocation and assignment of names in the root zone of the Domain Name System. This is in the public interest as it a fulfillment of a Bylaws' mandate to convene and consider the recommendations of an IANA Naming Function Review Team.

      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?

      Two public comments were completed, and no further public comments are needed.

    4. SAC045: SSAC Advisory on Invalid Top Level Domain Queries at the Root Level of the Domain Name System (DNS)

      Whereas, on 2 November 2010, the ICANN Board passed a Name Collision related Resolution, requesting ICANN's Security and Stability Advisory Committee (SSAC) to develop a plan for Board approval setting out studies of the issue of name collision, with many elements detailed.

      Whereas, on 15 November 2010 the SSAC Advisory, SAC045: SSAC Advisory on "Invalid Top Level Domain Queries at the Root Level of the Domain Name System" was received by ICANN org.

      Whereas, on 10 December 2010, the ICANN Board passed Resolution 2010.12.10.22, which directed ICANN org's Chief Executive Officer (CEO) to implement SAC045.

      Whereas, on 2 November 2017, developments in the New Generic Top Level Domain (gTLD) Program caused the ICANN Board to request, through resolutions 2017.11.02.29 and 2017.11.02.31, that SSAC develop a new plan for Board approval setting out studies of the issue of name collision.

      Whereas, in January 2018, the SSAC Name Collision Analysis Project (NCAP) Work Party ("NCAP WP") was formed and prepared a plan calling for three studies.

      Whereas, on 28 February 2018, SSAC published "SSAC Proposal for the Name Collision Analysis Project", which proposed three consecutive studies to address the Board's request.

      Whereas, the Office of the Chief Technical Officer (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.

      Whereas, in June 2018, after input from the Board, the ICANN org CEO assigned OCTO to be responsible for completing the NCAP studies.

      Whereas, in November 2019, during a meeting with representatives of OCTO and SSAC, the SSAC representatives agreed that the remaining actions called for by SAC045 are covered by the NCAP.

      Resolved (2021.05.12.07), the Board finds that the actions called for in SAC045 can be considered resolved by the NCAP and that the remaining item related to SAC045 being tracked in the ICANN org Action Request Registry may therefore be completed.

      Rationale for Resolutions 2021.05.12.07

      1. Why is the Board addressing the issue?

      On 2 November 2010, the ICANN Board passed a Name Collision related Resolution, requesting ICANN's Security and Stability Advisory Committee (SSAC) to develop a plan for Board approval setting out studies of the issue of name collision, with many elements detailed.

      On 15 November 2010 the SSAC Advisory, SAC045: SSAC Advisory on Invalid Top Level Domain Queries at the Root Level of the Domain Name System was received by ICANN org. The Security and Stability Committee (SSAC) identified certain technical considerations of strings that they proposed for use by applicants and recommended specific actions with regard to applications for those strings.

      On 10 December 2010, the ICANN Board immediately directed implementation of SAC045 with Resolution 2010.12.10.22,:

      The Board directs the Chief Executive Officer (CEO) to:

      1. Analyze and amend the Domain Name System (DNS) Stability Review described in the Applicant Guidebook to allow the option to prohibit the delegation of problematic strings, as appropriate, to address the potential technical and stability issues discussed in SAC045; and,
      2. Develop a mechanism to alert potential applicants for new generic top-level domains (gTLDs) about the issues raised in SAC045.

      Due to further developments on the new gTLD program, on 02 November 2017, the ICANN Board passed resolutions (2017.11.02.29 - 2017.11.02.31)

      requesting SSAC to develop a new plan for Board approval setting out studies of the issue of name collision, with many elements detailed.

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

      On 28 February 2018, SSAC published "SSAC Proposal for the Name Collision Analysis Project", which proposed three consecutive studies to address the Board's request.

      In June 2018, after input from the Board, the ICANN org CEO assigned the Office of the Chief Technical Officer (OCTO) to be responsible for completing the NCAP studies since SSAC does not have the administrative infrastructure to undertake and manage such a large project. 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.

      As the NCAP studies encompass all of the elements within SAC045, during ICANN66 in November 2019, SSAC agreed with OCTO that SAC045 could be closed.

      This Board Paper demonstrates ICANN org's completion of work on SAC045's recommendations. As a result, the Board is now directing that the remaining items related to SAC045 being tracked in the ICANN org Action Request Registry may be closed, at the recommendation of the Board Technical Committee (BTC).

      2. What is the proposal being considered?

      The Board is considering a recommendation from the BTC that the ICANN Board direct that the remaining items related to SAC045 being tracked in the ICANN org Action Request Registry may be closed.

      3. Which stakeholders or others were consulted?

      The SSAC agreed that ICANN org has fulfilled its role in implementing the Recommendations of this Advisory.

      4. What concerns or issues were raised by the community?

      None.

      5. What significant materials did the Board review?

      In determining that the remaining items related to SAC045 being tracked in the ICANN org Action Request Registry may be closed, the Board considered the recommendation of the BTC and the rationale from ICANN org demonstrating that work on these remaining items is now complete.

      6. Are there positive or negative community impacts?

      This Board resolution confirms that the Advisory's recommendations were completed by ICANN org and does not assess the impacts of the implementation of the recommendations.

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

      No fiscal impacts or ramifications on ICANN, the community, or the public are expected as a result of closing these remaining SAC045 items.

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

      No security, stability, or resiliency issues relating to the DNS are expected as a result of closing these remaining SAC045 items.

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

      Yes. Confirming the completion of the implementation of an Advisory provides an accountability mechanism for ICANN's work, which is in the public interest and within ICANN's mission.

      10. 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 action does not require public comment.

    5. SAC062: Advisory Concerning the Mitigation of Name Collision

      Whereas, on 7 November 2013, the Security and Stability Advisory Committee (SSAC) published SAC062: SSAC Advisory Concerning the Mitigation of Name Collision Risk.

      Whereas, on 21 November 2013, the ICANN Board accepted this advice and directed ICANN org to implement SAC062 per ICANN org's recommendation.

      Whereas, ICANN org attempted to shepherd the Special-Use Domain Name delegation issues through an IETF process for updating RFC 6761, as well as related discussions within the Domain Name System Operations (DNSOP) Working Group, and discussions ended without any related decisions due to a lack of interest from these groups and the wider Internet community.

      Whereas, on 20 July 2014, the ICANN Board New gTLD Program Committee (NGCP) adopted the Name Collision Occurrence Management Framework which considered the questions, as instructed, from Recommendations 2 and 3.

      Resolved (2021.05.12.08), the Board finds that ICANN org has implemented all of SAC062's Recommendations, and considers SAC062 to be completed.

      Rationale for Resolutions 2021.05.12.08

      1. Why is the Board addressing the issue?

      ICANN org received SAC062: Concerning the Mitigation of Name Collision Risk on 7 November 2013. On 21 November 2013 the Board passed a resolution that "directs ICANN's President and CEO to have the advice provided in SAC062 evaluated." On 8 June 2017, ICANN org submitted the requested feasibility analysis, and on 24 June 2017, the ICANN Board accepted this advice and directed ICANN org to implement per the ICANN org's recommendation.

      This Board Paper demonstrates ICANN org's completion of work on SAC062's recommendations. As a result, the Board is now directing that the remaining items related to SAC062 being tracked in the ICANN org Action Request Registry may be closed, at the recommendation of the Board Technical Committee (BTC).

      2. What is the proposal being considered?

      The Board is considering a recommendation from the BTC that the ICANN Board direct that the remaining items related to SAC062 being tracked in the ICANN org Action Request Registry may be closed.

      3. Which stakeholders or others were consulted?

      The SSAC agreed that ICANN org has fulfilled its role in implementing the Recommendations of this Advisory.

      4. What concerns or issues were raised by the community?

      None.

      5. What significant materials did the Board review?

      In determining that the remaining items related to SAC062 being tracked in the ICANN org Action Request Registry may be closed, the Board considered the recommendation of the BTC and the rationale from ICANN org demonstrating that work on these remaining items is now complete.

      BACKGROUND

      Recommendation 1

      Recommendation 1 on Special-Use Domain Names recommended that ICANN org should work with the wider Internet community, including at least the Internet Architecture Board (IAB) and the Internet Engineering Task Force (IETF), to identify (1) what strings are appropriate to reserve for private namespace use and (2) what type of private namespace use is appropriate (i.e., at the TLD level only or at any additional lower level).

      ICANN org attempted to update RFC 6761 through the IETF process. The Domain Name System Operations (DNSOP) Working Group raised awareness on its work in this area by organizing a webinar entitled, "IETF Overview and Special-Use Domain Names Problem Statement" held on 23 May 2017. Despite these efforts, this subject was unable to gain momentum in the DNSOP Working Group. OCTO's (Office of the Chief Technical Officer, ICANN org) attempts at working with the wider Internet community failed to achieve consensus on how to move forward with updating Request For Comment (RFC) 6761, despite OCTO's direct involvement.

      Recommendation 2 and 3

      Recommendation 2 advises that ICANN org should explicitly consider the following questions regarding trial delegation and clearly articulate what choices have been made and why, as part of its decision as to whether or not to delegate any TLD on a trial basis:

      1. Purpose of the trial: What type of trial is to be conducted? What data are to be collected?
      2. Operation of the trial: Should ICANN org (or a designated agent) operate the trial or should the applicant operate it?
      3. Emergency rollback: What are the emergency rollback decision and execution procedures for any delegation in the root, and have the root zone partners exercised these capabilities?
      4. Termination of the trial: What are the criteria for terminating the trial (both normal and emergency criteria)? What is to be done with the data collected? Who makes the decision on what the next step in the delegation process is?

      Recommendation 3 advises that ICANN org should explicitly consider under what circumstances un-delegation of a TLD is the appropriate mitigation for a security or stability issue. In the case where a TLD has an established namespace, ICANN org should clearly identify why the risk and harm of the TLD remaining in the root zone is greater than the risk and harm of removing a viable and in-use namespace from the DNS. Finally, ICANN org should work in consultation with the community, in particular the root zone management partners, to create additional processes or update existing processes to accommodate the potential need for rapid reversal of the delegation of a TLD.

      Recommendations 2 and 3 were considered by ICANN org while developing the Name Collision Occurrence Management Framework and included in said framework. The ICANN Board New gTLD Program Committee (NGCP) adopted the Name Collision Occurrence Management Framework on 20 July 2014 in order "to continue to manage the occurrence of collisions between new gTLDs and existing private uses of the same strings, and directed the President and Chief Executive Officer (CEO), or his designee(s), to take the necessary actions to implement the Name Collision Occurrence Management Framework."

      6. Are there positive or negative community impacts?

      This Board resolution confirms that the Advisory's recommendations were completed by ICANN org and does not assess the impacts of the implementation of the recommendations.

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

      No fiscal impacts or ramifications on ICANN, the community, or the public are expected as a result of closing these remaining SAC062 items.

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

      No security, stability, or resiliency issues relating to the DNS are expected as a result of closing these remaining SAC062 items.

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

      Yes. Confirming the completion of the implementation of an Advisory provides an accountability mechanism for ICANN's work, which is in the public interest and within ICANN's mission.

      10. 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 action does not require public comment.

    6. SAC065: SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure

      Whereas, on 18 February 2014, SSAC published SAC065: Security and Stability Advisory Committee (SSAC) Advisory on DDoS Attacks Leveraging DNS Infrastructure.

      Whereas, on 24 June 2017, the ICANN Board accepted this advice and directed ICANN org to implement SAC065 per ICANN org's recommendation.

      Whereas, ICANN org supported community efforts with several projects so that on 12 February 2020, SSAC agreed ICANN org had fulfilled the recommendation to the extent feasible.

      Resolved (2021.05.12.09), the Board finds that ICANN org acted upon SAC065's Recommendation 1. The Board considers SAC065 to be completed.

      Rationale for Resolution 2021.05.12.09

      1. Why is the Board addressing the issue?

      On 18 February 2014, ICANN received SAC065: Security and Stability Advisory Committee (SSAC) Advisory on DDoS Attacks Leveraging DNS Infrastructure.

      On 24 June 2017, the Board adopted the advice in SAC065 and directed the CEO to implement the advice as described in the document:

      "SAC065 is an advisory on DDoS attacks leveraging DNS infrastructure and Recommendation 1 indicates that ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing. Upon the creation of such a community effort, ICANN should provide measurement and outreach support with appropriate allocation of staff and funding."

      This Board Paper demonstrates ICANN org's completion of work on SAC065's recommendations. As a result, the Board is now directing that the remaining items related to SAC065 being tracked in the ICANN org Action Request Registry may be closed, at the recommendation of the Board Technical Committee (BTC).

      2. What is the proposal being considered?

      The Board is considering a recommendation from the BTC that the ICANN Board direct that the remaining items related to SAC065 being tracked in the ICANN org Action Request Registry may be closed.

      3. Which stakeholders or others were consulted?

      The SSAC agreed that ICANN org has fulfilled its role in implementing the Recommendations of this Advisory.

      4. What concerns or issues were raised by the community?

      None.

      5. What significant materials did the Board review?

      In determining that the remaining items related to SAC065 being tracked in the ICANN org Action Request Registry may be closed, the Board considered the recommendation of the BTC and the rationale from ICANN org demonstrating that work on these remaining items is now complete.

      BACKGROUND

      Only Recommendation 1 advised actions for ICANN org, while Recommendations 2 through 6 were addressed to other parties in the community (network operators, DNS operators, and manufacturers and/or configurators of customer premise networking equipment):

      Recommendation 1: ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing. This effort should involve measurement efforts and outreach and cooperation in relevant technical fora involving network operators worldwide, but will not have an operational component. ICANN should support this effort with adequate staffing and funding.

      The Recommendation outlined data that ICANN org should collect in order to create reports for all kinds of network server operators and manufacturers to whom Recommendations 2 thru 6 were addressed.

      b. Coordinate with the Internet community to popularize and support recommendations 2-5. This coordination should include exploration of whether operational requirements regarding open resolvers and the prevention of network spoofing can be incorporated into regulatory compliance frameworks and certification regimes.

      Since then, ICANN org has been supportive of community efforts underway to raise visibility of open resolvers, such as https://dnsscan.shadowserver.org and http://openresolverproject.org. In particular, ICANN org has funded the Shadowserver Foundation.

      Regarding explicit efforts to reduce the number of open resolvers, ICANN org has investigated the viability of such a project. The effort is daunting, if not impossible, given the large number of open resolvers (tens of millions) and the difficulty in determining and then reaching operators. As an example of this difficulty, in 2018 the Office of the Chief Technical Officer (OCTO) made a significant effort to reach out to operators of resolvers that were thought to be using only KSK-2010 in order to prepare for the key rollover. ICANN org discovered that contacting individual resolver operators to alert them of possible problems was extremely difficult and largely unsuccessful. Given the large number of open resolvers (tens of millions) and the anticipated effort it would take to get even a significant fraction of operators of those resolvers to enable appropriate resolution service access controls, ICANN org believes further efforts in this area would be extremely resource intensive and unlikely to make a material difference.

      With respect to facilitating an Internet-wide community effort to reduce the number of networks that allow network spoofing, this activity may be viewed as outside of ICANN's limited technical remit. ICANN org notes that the Internet Society continues to make great strides with their Mutually Agreed Norms for Routing Security (MANRS) in encouraging network operators to reduce the impact of network spoofing.

      Based on the work discussed above, on 12 February 2020, SSAC agreed that actions related to SAC065 Recommendation 1 should be considered complete.

      6. Are there positive or negative community impacts?

      This Board resolution confirms that the Advisory's recommendations were completed by ICANN org and does not assess the impacts of the implementation of the recommendations.

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

      No fiscal impacts or ramifications on ICANN, the community, or the public are expected as a result of closing these remaining SAC062 items.

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

      No security, stability, or resiliency issues relating to the DNS are expected as a result of closing these remaining SAC065 items.

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

      Yes. Confirming the completion of the implementation of an Advisory provides an accountability mechanism for ICANN's work, which is in the public interest and within ICANN's mission.

      10. 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 action does not require public comment.

    7. SAC070: Security and Stability Advisory Committee (SSAC) Advisory on the Use of Static TLD / Suffix Lists

      Whereas, on 28 May 2015, SSAC published SAC070: SSAC Advisory on the Use of Static TLD / Suffix Lists.

      Whereas, on 1 June 2016 the ICANN org and SSAC agreed through a Statement of Understanding that Recommendations 1, 2, 4b, and 4c had no actions for the Board.

      Whereas, on 24 June 2017, in Resolution 2017.06.24.19, the ICANN Board accepted this advice and directed the ICANN org to implement per the ICANN org's recommendation.

      Whereas, on 18 May 2020, ICANN org published "The Public Suffix List: A Guide for TLD Administrators" (OCTO-011) which completed Recommendation 3.

      Whereas, on 8 August 2017, the Universal Acceptance Steering Group (UASG) considered the SSAC advice in its document UASG007, and ICANN org notified SSAC of the completion of the actions called for in Recommendation 4a.

      Whereas, on 1 December 2019, the IANA team started hosting an authoritative PSL for all TLDs in the root zone, completing Recommendation 5.

      Whereas, on 8 August 2017, the UASG considered SAC070's Recommendation 6 advice in UASG007, and ICANN org notified SSAC of Recommendation's 6 completion.

      Resolved (2021.05.12.10), the Board finds that the actions called for by the recommendations from SAC070 advising action for ICANN org, specifically Recommendations 3, 4a, 5, and 6, have been completed by ICANN org.

      Rationale for Resolution 2021.05.12.10

      1. Why is the Board addressing the issue?

      On 24 June 2017, the ICANN Board accepted SAC070's advice and directed the ICANN org to implement the advice per the ICANN org's recommendation.

      This advisory concerns the use of static TLD / suffix lists. Software that processes domain names, such web browsers, sometimes needs to know whether a domain name ends in a "public suffix", i.e., a domain typically open for registration, such as .com or .co.uk. "Public suffix lists" (PSLs), most notably the one maintained by Mozilla, attempt to list all such public suffix domains. Software uses this list for various purposes, such as quickly validating a TLD without requiring a DNS query, highlighting the public portion of a domain name in a browser's address bar, or determining if one domain is able to set a cookie for another (which is not allowed if the domains are unrelated, which is the case if they are peers under the same public suffix).

      As of May 2020, all recommendations from SAC070 calling for action by ICANN org had been completed.

      The Board briefings on this matter demonstrates ICANN org's completion of work on SAC062's recommendations. As a result, the Board is now directing that the remaining items related to SAC070 being tracked in the ICANN org Action Request Registry may be closed, at the recommendation of the Board Technical Committee (BTC).

      2. What is the proposal being considered?

      The Board is considering a recommendation from the BTC that the ICANN Board direct that the remaining items related to SAC070 being tracked in the ICANN org Action Request Registry may be closed.

      3. Which stakeholders or others were consulted?

      The SSAC agreed that ICANN org has fulfilled its role in implementing the Recommendations of this Advisory.

      4. What concerns or issues were raised by the community?

      None.

      5. What significant materials did the Board review?

      In determining that the remaining items related to SAC070 being tracked in the ICANN org Action Request Registry may be closed, the Board considered the recommendation of the BTC and the rationale from ICANN org demonstrating that work on these remaining items is now complete.

      BACKGROUND

      Recommendations 1 and 2: No Action Required by ICANN org

      Recommendations 1 and 2 addressed the IETF and the applications community and on 1 June 2016, SSAC approved a statement of understanding acknowledging that no action was required from ICANN org.

      Recommendation 3

      SAC070 Recommendation #3 advised that ICANN org, in concert with the Mozilla Foundation, prepare educational materials on the Mozilla PSL covering the meaning of the resource and the impact of the resource.

      ICANN org hired a contractor to provide the materials and on 18 May 2020, "The Public Suffix List: A Guide for TLD Administrators" (OCTO-011) was published. This document about the Mozilla PSL can be given to TLD registry operators and is designed to close the knowledge gap between registries and popular PSL maintainers.

      Recommendation 4 which has three (3) parts:

      4a advised that ICANN org should request that the UASG encourage the development of software resources enabling or enhancing the effective use of the Mozilla PSL, with attention toward software developers. As the UASG considered the SSAC advice in its document UASG007, ICANN org notified SSAC of this recommendation's closure on 8 August 2017.

      4b advised that application developers should use a canonical file format and modern authentication protocols as specifications to this work. On 30 August 2016, ICANN org received SSAC's approval of understanding acknowledging there is no action for the Board.

      4c advised that application developers should also replace proprietary PSLs with well-known and widely accepted PSL implementations such as the Mozilla PSL and the proposed IANA PSL (part of Recommendation 5). On 30 August 2016, ICANN org received SSAC's approval of understanding acknowledging there is no action for the Board.

      Recommendation 5

      Recommendation 5 advised that IANA should host a Public Suffix List (PSL) containing information about the domains within the registries with which IANA has direct communication. Such a PSL would be authoritative for those domains. Such a list should include, at a minimum, all Top Level Domains (TLDs) in the IANA root zone.

      As of 1 December 2019, the IANA team is now hosting an authoritative PSL for all TLDs in the root zone as stated in recommendation 5 of SAC070. On 12 February 2020, SSAC agreed that SAC070, Recommendation 5 had been completed.

      Recommendation 6

      Recommendation 6 encouraged those parties working on universal acceptance such as the UASG to explicitly include the use of a PSL and actions related to a PSL as part of their work. As the UASG considered the SSAC advice in its document UASG007, ICANN org notified SSAC of this recommendation's closure on 8 August 2017.

      6. Are there positive or negative community impacts?

      This Board resolution confirms that the Advisory's recommendations were completed by ICANN org and does not assess the impacts of the implementation of the recommendations.

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

      No fiscal impacts or ramifications on ICANN, the community, or the public are expected as a result of closing these remaining SAC070 items.

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

      No security, stability, or resiliency issues relating to the DNS are expected as a result of closing these remaining SAC070 items.

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

      Yes. Confirming the completion of the implementation of an Advisory provides an accountability mechanism for ICANN's work, which is in the public interest and within ICANN's mission.

      10. 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 action does not require public comment.

  2. Main Agenda:

    1. FY22-26 Operating and Financial Plan and FY22 Operating Plan and Budget Approval

      Whereas, the draft FY22-26 Operating and Financial Plan and draft FY22 Operating Plan and Budget were posted for public comment in accordance with the Bylaws on 17 December 2020.

      Whereas, the public comments received were considered and revisions were applied as appropriate and feasible to the revised draft FY22-26 Operating and Financial Plan and draft FY22 Operating Plan and Budget.

      Whereas, in addition to the public comment process, ICANN organization actively solicited community feedback and consultation with the ICANN Community by other means, including a remote public session during ICANN 70.

      Whereas, at each of its recent regularly scheduled meetings, the Board Finance Committee (BFC) has discussed, and guided ICANN organization on the development of the Proposed for Board Adoption FY22-26 Operating and Financial Plan and the Proposed for Board Adoption FY22 Operating Plan and Budget.

      Whereas, the BFC reviewed and discussed suggested changes to the FY22-26 Operating and Financial Plan and the FY22 Operating Plan and Budget resulting from public comment and consultations and recommended that the Board approve the Proposed for Board Adoption FY22-26 Operating and Financial Plan and the Proposed for Board Adoption FY22 Operating Plan and Budget.

      Whereas, per section 3.9 of the 2013 Registrar Accreditation Agreements, the Board is to establish the Registrar Accreditation Fees and Variable Accreditation Fees, which must be established to develop the annual budget.

      Whereas, the description of the Registrar fees, including the recommended Registrar Accreditation Fees Variable Accreditation Fees, for FY22 have been included in the FY22 Operating Plan and Budget.

      Resolved (2021.05.12.11), the Board adopts the FY22-26 Operating and Financial Plan, which describes the activities ICANN org will undertake and the resources needed to achieve the ICANN Board adopted ICANN's Strategic Plan for Fiscal Years 2021-2025.

      Resolved (2021.05.12.12), the Board adopts the FY22 Operating and Budget including the FY22 ICANN Caretaker Budget that would be in effect in the event the FY22 ICANN Operating Plan and Budget is not in effect at the beginning of FY22.

      Rationale for Resolutions 2021.05.12.11 – 2021.05.12.12

      In accordance with Article 22, Sections 22.4 (a) and 22.5 (a) of the ICANN Bylaws, the Board is to adopt an annual budget and publish it on the ICANN website. On 17 December 2020, drafts of the ICANN FY22-26 Operating and Financial Plan and draft FY22 Operating Plan and Budget were posted for public comment. The Public Technical Identifiers (PTI) Board approved the PTI FY22 Operating Plan and Budget on 13 January 2021, and the PTI Operating Plan and Budget was received as input into the FY22 IANA Budget.

      The published draft FY22-26 Operating and Financial Plan and draft FY22 Operating Plan and Budget and the FY22 IANA Budget were based on numerous discussions with members of ICANN organization and the ICANN Community, including extensive consultations with ICANN Supporting Organizations, Advisory Committees, and other stakeholder groups throughout the prior several months.

      The comments received from the public comment process resulted in no revisions to the 17 December 2020 draft FY22-26 Operating and Financial Plan and draft FY22 Operating Plan and Budget.

      In addition, the following consultation activities were carried out:

      • 6 October 2020 – Community webinar held on the FY2 Planning Process and Timeline.
      • 12 January 2021 and 13 January – two Community webinars were held to review the Draft FY22-26 Operating and Financial Plan and draft FY22 Operating Plan and Budget published for public comment
      • 9 March 2021- the comments received through the public comment process were discussed by Board members and ICANN organization members during a remote public session on public comments during ICANN 70 Prep week with representatives of the ICANN bodies that submitted them to help ensure the comments were adequately understood and appropriate consideration was given to them.
      • In addition to the public comment process, ICANN actively solicited community feedback and consultation with the ICANN Community by other means, including during sessions with Supporting Organizations and Advisory Committees during ICANN 70.

      All comments received were considered in developing the Proposed for Board Adoption FY22-26 Operating and Financial Plan and the Proposed for Board Adoption FY22 Operating Plan and Budget. Where feasible and appropriate these inputs have been incorporated into the Proposed for Board Adoption FY22-26

      Operating and Financial Plan and the Proposed for Board Adoption FY22 Operating Plan and Budget.

      In addition to the day-to-day operational requirements, the FY22 Operating Plan and Budget allocates amounts to various FY22 budget requests received from community leadership. The FY22 Operating Plan and Budget also discloses financial information on the 2012 New gTLD Program, relative to expenses, funding and net remaining funds. Further, because the Registrar Variable Accreditation Fee is key to the development of the budget, the FY22 Operating Plan and Budget sets out and establishes those fees, which are consistent with recent years, and will be reviewed for approval by the Registrars.

      The FY22-26 Operating and Financial Plan and FY22 Operating Plan and Budget, all will have a positive impact on ICANN in that together they provide a proper framework by which ICANN will be managed and operated, which also provides the basis for the organization to be held accountable in a transparent manner.

      This decision is in the public interest and within ICANN's mission, as it is fully consistent with ICANN's strategic and operational plans, and the results of which in fact allow ICANN to satisfy its mission.

      This decision will have a fiscal impact on ICANN org and the Community as is intended. This should have a positive impact on the security, stability and resiliency of the domain name system (DNS) with respect to any funding that is dedicated to those aspects of the DNS.

      This is an Organizational Administrative Function that has already been subject to public comment as noted above.

    2. Transfer to Reserve Fund and Creation of Supplemental Fund for Implementation of Community Recommendations (SFICR)

      Whereas, the Operating Fund includes the funds used for ICANN's day-to-day operations and must contain enough funds to cover at a minimum ICANN's expected expenditures for three months.

      Whereas, periodically, any funds in the Operating Fund considered to be in excess of its normal level may be transferred to the Reserve Fund to maintain a minimum target level, as determined and approved by the Board.

      Whereas, a Supplemental Fund for Implementation of Community Recommendations (SFICR) will allow ICANN to segregate resources in support of increasing the capacity of the organization to address activities and projects not currently included in the organization's historical expenses or current budget.

      Whereas, the ICANN Investment Policy has been revised to reflect the governance of the SFICR.

      Whereas, periodically, if excess funds exist in the Operating Fund after an allocation to the Reserve Fund has been considered or decided, an allocation to the SFICR will be considered during the annual planning process based on the project needs identified.

      Whereas, ICANN organization has determined that the balance of the Operating Fund as of 30 June 2020, based on the audited Financial Statements, contained excess funds.

      Resolved (2021.05.12.13), the Board approves the transfer of US$10,000,000 from the Operating Fund to the Reserve Fund.

      Resolved (2021.05.12.14), the Board authorizes the creation of the SFICR.

      Resolved (2021.05.12.15), the Board approves the revised ICANN Investment Policy that, as revised, establishes the governance of the SFICR and provides clarity on a few other provisions.

      Rationale for Resolutions 2021.05.12.13 – 2021.05.12.15

      As part of ICANN's Investment Policy, the Operating Fund should be at a level of funds to cover a minimum of three months of ICANN organization's operating expenses, and that any amount determined to be in excess may be transferred to the Reserve Fund to ensure its balance is at or above the minimum target level, as determined and approved by the Board.

      A Supplemental Fund for Implementation of Community Recommendations (SFICR) would establish segregated resources in support of increasing the capacity of the organization to address activities and projects not currently included in the organization's historical expenses or current budget. If the Operating Fund contains net excess after an allocation to the Reserve Fund has been made, an allocation to the SFICR will be determined based on the project needs identified.

      ICANN organization has evaluated the Operating Fund at the end of FY20 on the basis of its audited Financial Statements, and has determined that excess funds of US$10,000,000 should be transferred to the Reserve Fund and an SFICR should be created. The governance of the SCFIR is set forth in the ICANN Investment Policy.

      This action is consistent with ICANN's mission and is in the public interest as it is important to ensure stability of ICANN organization in the way of a robust Reserve Fund in case use of a Reserve Fund becomes necessary. Furthermore, this action is consistent with ICANN's mission and is in the public interest as the SFICR will fund projects, as approved by the Board, when the size, complexity, and length of the projects create a challenge to be solely funded by recurring funding. The SFICR will fund projects based on the public interest of the community that would otherwise go unbudgeted.

      This action will not have a negative financial impact on ICANN, and will not have any negative impact on the security, stability or resiliency of the domain name system.

      This is an Organizational Administrative function that does not require public comment.

    3. SAC063, SAC073 and SAC102 regarding the DNSSEC Key Rollover in the Root Zone

      Whereas, on 7 November 2013, the Security and Stability Advisory Committee (SSAC) published SAC063: SSAC Advisory on DNSSEC Key Rollover in the Root Zone, regarding performing the first root zone key signing key (KSK) rollover.

      Whereas, on 5 October 2015 the SSAC published SAC073: SSAC Comments on Root Zone Key Signing Key Rollover Plan - Design Teams Draft Report.

      Whereas, on 24 June 2017, the ICANN Board accepted the advice of SAC063 and SAC073 based on ICANN org's analysis and directed the org to implement per the org's recommendation.

      Whereas, on 13 May 2018, after the initial KSK Rollover was delayed, in Resolution 2018.05.13.09, the ICANN Board asked SSAC for advice on how to continue forward.

      Whereas, on 20 August 2018, SSAC published SAC102: SSAC Comment on the Updated Plan for Continuing the Root KSK Rollover, advising ICANN org to continue with the rollover.

      Whereas, on 16 September 2018, the ICANN Board accepted this advice and directed ICANN org to proceed with the KSK rollover as described in the "Updated Plan for Continuing the Root KSK Rollover".

      Whereas on 11 October 2018, ICANN org successfully completed the first rollover of the root zone KSK.

      Resolved (2021.05.12.16), the Board finds that ICANN org acted upon all Recommendations from SAC063, SAC073, and SAC102, as is evidenced by the successful first KSK Rollover. The Board considers SAC063, SAC073, and SAC102 to be completed.

      Rationale for Resolutions 2021.05.12.16

      1. Why is the Board addressing the issue?

      On 8 March 2013, ICANN org opened a Public Comment period seeking feedback with respect to the execution of a root zone Key Signing Key (KSK) rollover. On 7 November 2013, SSAC published SAC063, which contains five recommendations for the ICANN org related to rolling the root zone KSK.

      The draft report from the Design Team convened by ICANN org to make recommendations on the first root zone KSK rollover went into Public Comment on 6 August 2015. SSAC commented on this report by publishing SAC073 on 5 October 2015. This document reiterated the recommendations in SAC063 and called for each to be addressed in the final version of the Design Team's report, which was eventually published on 7 March 2016 as the Root Zone KSK Rollover Plan.

      On 27 September 2017, the ICANN org announced it was postponing the root zone KSK rollover and on 17 October 2017 published a paper entitled "Postponing the Root KSK Roll."

      On 13 May 2018, in Resolution 2018.05.13.09, the ICANN Board requested that SSAC provide advice to the Board on the Updated Plan for Continuing the Root KSK Rollover due to the rollover's postponement. SSAC delivered the advice on 21 August 2018 in SAC102 which concluded that "the SSAC has not identified any reason within the SSAC's scope why the rollover should not proceed as currently planned."

      ICANN org carried out the first rollover of the root zone KSK on 11 October 2018. The project is documented in a report written by the Office of the Chief Technology Officer (OCTO) entitled "Review of the 2018 DNSSEC KSK Rollover." By all accounts the first root zone KSK rollover was a success.

      This Board Paper demonstrates ICANN org's completion of work on SAC063, SAC073 and SAC102's recommendations. As a result, the Board is now directing that the remaining items related to these three advisories being tracked in the ICANN org Action Request Registry may be closed, at the recommendation of the Board Technical Committee (BTC).

      2. What is the proposal being considered?

      The Board is considering a recommendation from the BTC that the ICANN Board direct that the remaining items related to SAC063, SAC073, and SAC102 being tracked in the ICANN org Action Request Registry may be closed.

      3. Which stakeholders or others were consulted?

      The SSAC agreed that ICANN org has fulfilled its role in implementing the Recommendations of this Advisory.

      4. What concerns or issues were raised by the community?

      None.

      5. What significant materials did the Board review?

      In determining that the remaining items related to SAC063, SAC073, and SAC102 being tracked in the ICANN org Action Request Registry may be closed, the Board considered the recommendation of the BTC and the rationale from ICANN org demonstrating that work on these remaining items is now complete as evidenced by the successful completion of the KSK Rollover.

      6. Are there positive or negative community impacts?

      This Board resolution confirms that the Advisory's recommendations were completed by ICANN org and does not assess the impacts of the implementation of the recommendations.

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

      No fiscal impacts or ramifications on ICANN, the community, or the public are expected as a result of closing these remaining SAC063, SAC073, and SAC102 items.

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

      No security, stability, or resiliency issues relating to the Domain Name System (DNS) are expected as a result of closing these remaining SAC063, SAC070, and SAC102 items.

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

      Yes. Confirming the completion of the implementation of an Advisory provides an accountability mechanism for ICANN's work, which is in the public interest and within ICANN's mission.

      10. 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 action does not require public comment.

    4. GAC Advice: ICANN70 Communiqué (25 March 2021)

      Whereas, the Governmental Advisory Committee (GAC) met during the ICANN70 Virtual Community Forum and issued advice to the ICANN Board in a communiqué on 25 March 2021 ("ICANN70 Virtual Community Forum Communiqué").

      Whereas, the ICANN Board acknowledged the ICANN70 Virtual Community Forum Communiqué in a letter dated 7 April 2021.

      Whereas, the ICANN70 Virtual Community Forum Communiqué was the subject of an exchange raising Clarifying Questions between the Board and the GAC on 21 April 2021, which helped develop a mutual understanding of the advice issues.

      Whereas, in a 7 May 2021 letter, the GNSO Council provided its feedback to the Board concerning advice in the ICANN70 Virtual Community Forum Communiqué relevant to EPDP Phase 2 Final Report, CCT Review and Subsequent Rounds of New gTLDs, and IGO Identifiers.

      Whereas, the Board developed a scorecard to respond to the GAC's advice in the ICANN70 Virtual Community Forum Communiqué, taking into account the dialogue between the Board and the GAC and the information provided by the GNSO Council.

      Resolved (2021.05.12.17), the Board adopts the scorecard titled "GAC Advice – ICANN70 Virtual Community Forum Communiqué: Actions and Updates (12 May 2021)" in response to items of GAC advice in the ICANN70 Virtual Community Forum Communiqué.

      Rationale for Resolutions 2021.05.12.17

      Article 12, Section 12.2(a)(ix) of the ICANN Bylaws permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." In its ICANN70 Virtual Community Forum Communiqué (25 March 2021), the GAC issued advice to the Board on the EPDP Phase 2 Final Report. The GAC also provided follow-up to previous advice regarding the CCT Review and Subsequent Rounds of New gTLDs as well as IGO Identifiers. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the policies. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. Any GAC advice approved by a full consensus of the GAC (as defined in the Bylaws) may only be rejected by a vote of no less than 60% of the Board, and the GAC and the Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution.

      The Board is taking action today on all items in the ICANN70 Virtual Community Forum Communiqué, including the items related to the EPDP Phase 2 Final Report.

      The Board's actions are described in the scorecard dated 12 May 2021.

      In adopting its response to the GAC advice in the ICANN70 Virtual Community Forum Communiqué, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      The adoption of the GAC advice as provided in the scorecard will have a positive impact on the community because it will assist with resolving the advice from the GAC concerning gTLDs and other matters. There are no foreseen fiscal impacts associated with the adoption of this resolution. Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS. This is an Organizational Administrative function that does not require public comment.

Published on 14 May 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."