en

Board Activities and Meetings

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

Approved Board Resolutions | Special Meeting of the ICANN Board | 24 February 2022

  1. Consent Agenda:
    1. RZERC003: Adding Zone Data Protections to the Root Zone
  2. Main Agenda:
    1. FY23 IANA Operating Plan and Budget
    2. GNSO Supplemental Recommendation on EPDP Phase 1 Recommendation 12
    3. AOB

 

  1. Consent Agenda:

    1. RZERC003: Adding Zone Data Protections to the Root Zone

      Whereas, in February 2021, the Internet Engineering Task Force (IETF) produced RFC 8976 documenting a new technique for verifying the contents of Domain Name System (DNS) zone files: Message Digests for DNS Zones (aka "ZONEMD").

      Whereas, on 12 February 2021, the ICANN Root Zone Evolution Review Committee (RZERC) published RZERC003: Adding Zone Data Protections to the Root Zone containing three recommendations to ICANN in support of implementing the ZONEMD protocol in the DNS root zone.

      Whereas, the Board Technical Committee (BTC) has considered RZERC003 and ICANN org's feasibility assessment of implementation of the recommendations and found that implementing the recommendations would be in alignment with ​ICANN's strategic ​goals and mission to ensure the stable and secure operation of the Internet's unique identifier systems.

      Resolved (2022.02.24.01) the Board accepts Recommendation 1 calling for ICANN org to engage with the Root Zone Maintainer and the Root Server operators to ensure the addition of a ZONEMD resource record to the root zone will not negatively impact the distribution of root zone data within the Root Server System, and directs the ICANN President and CEO, or his designee(s), to implement this recommendation.

      Resolved (2022.02.24.02) the Board accepts Recommendation 2 calling for ICANN org to engage with relevant technical bodies to raise awareness of the plan for the deployment of ZONEMD in the root zone, and directs the ICANN President and CEO, or their designee(s), to implement this recommendation.

      Resolved (2022.02.24.03) the Board accepts Recommendation 4 calling for ICANN org to develop a plan for deploying ZONEMD in the root zone with its contractors and make the plan available to RZERC for review, and directs the ICANN President and CEO, or his designee(s), to implement this recommendation.

      Rationale for Resolution 2022.02.24.01 – 2022.02.24.03

      Why is the Board addressing the issue?

      The Board is taking action on advice from the RZERC. The RZERC reviews proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone. The Board's consideration of this advice forms a part of the Action Request Register (ARR) process designed to manage community requests to the Board and ICANN org in a consistent, efficient, and transparent manner.

      What is the proposal being considered?

      In February 2021, the Internet Engineering Task Force (IETF) produced RFC 8976 documenting a new technique for verifying the contents of DNS zone files, known as Message Digests for DNS Zones, or ZONEMD. The RZERC considered a proposal to implement ZONEMD in the root zone at the request of the Root Zone Maintainer and published RZERC003 on 12 February 2021. RZERC003 contains four recommendations in support of implementing the ZONEMD protocol in the DNS root zone:

      • Recommendation 1: The root zone maintainer and root server operators should verify and confirm that the addition of a ZONEMD resource record will in no way negatively impact the distribution of root zone data within the RSS.

      • Recommendation 2: The DNS and Internet community should be made aware of plans to use ZONEMD in the root zone, and be given an opportunity to offer feedback. This may include technical presentations at meetings hosted by ICANN, the DNS Operations Analysis and Research Center (DNS-OARC), the North American Network Operators' Group (NANOG), the Réseaux IP Européens (RIPE), etc.

      • Recommendation 3: Developers of name server software are encouraged to implement ZONEMD and consider enabling it by default when the software is configured to locally serve root zone data. The Board is not taking action on Recommendation 3 as it is not directed at ICANN.

      • Recommendation 4: Public Technical Identifiers (PTI) and the RZM should jointly develop a plan for deploying ZONEMD in the root zone, and make this plan available for review by RZERC.

      Which stakeholders or others were consulted?

      RZERC003 was created and edited by members of the RZERC. The RZERC is comprised of representatives from:

      • Internet Engineering Task Force (IETF)
      • Address Supporting Organization (ASO)
      • Country Code Names Supporting Organization (ccNSO)
      • ICANN Board
      • Public Technical Identifiers (PTI)
      • Registries Stakeholder Group of the Generic Names Supporting Organization (RySG)
      • Root Server System Advisory Committee (RSSAC)
      • Security and Stability Advisory Committee (SSAC)
      • Verisign as the Root Zone Maintainer

      What concerns or issues were raised by the community?

      No concerns or issues raised.

      Are there positive or negative community impacts?

      Implementation is expected to have positive community impacts by implementing additional security mechanisms for the dissemination of the DNS root zone. No negative impacts have been identified.

      What significant materials did the Board review?

      The Board reviewed RZERC003 produced by the RZERC and RFC 8976 produced by the IETF. In addition, for each recommendation presented in this resolution the Board considered ICANN org's understanding of the recommendation as confirmed by the RZERC and ICANN org's feasibility assessment of implementation.

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

      The cost for ICANN org is anticipated to be low, and includes expenditure associated with project management, administration, and outreach efforts. These costs are incorporated into the Office of the Chief Technology Officer (OCTO) budget as part of normal activities.

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

      ZONEMD is a new technique for verifying the contents of DNS zone files. If deployed in the root zone, ZONEMD is expected to provide additional data integrity protections, particularly for emerging applications such as hyperlocal root zone distribution.

      Is this action within ICANN's Mission? How does it relate to the global public interest?

      This action is within ICANN's mission and serves the global public interest as implementation is expected to provide additional data integrity protections in the root zone.

      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. FY23 IANA Operating Plan and Budget

      Whereas, the draft FY23 IANA Operating Plan and Budget was posted for public comment in accordance with the Bylaws on 15 September 2021.

      Whereas, comments received through the public comment process were reviewed and responded to and provided to the Board Finance Committee (BFC) for review and consideration. In addition, all public comments have been taken into consideration, and where appropriate and feasible, have been incorporated into a final FY23 IANA Operating Plan and Budget.

      Whereas, in accordance with ICANN Bylaws Article 22, Section 22.4(b), ICANN shall require PTI to submit the PTI Budget to ICANN as an input prior to and for the purpose of being included in the proposed Operation Plan and ICANN Budget. The Adopted FY23 PTI Budget is included as input to the IANA Operating Plan and Budget.

      Whereas, per the ICANN Bylaws, the IANA Operating Plan and Budget is to be adopted by the ICANN Board and then posted on the ICANN website.

      Resolved (2022.02.24.04), the Board adopts the FY23 IANA Operating Plan and Budget.

      Rationale for Resolution 2022.02.24.04

      In accordance with Article 22, Section 22.4 of the ICANN Bylaws, the Board is to adopt an annual IANA budget and publish it on the ICANN website. On 15 September 2021, the drafts of the FY23 PTI Operating Plan and Budget and the FY23 IANA Operating Plan and Budget were posted for public comment. The PTI Board approved the FY23 PTI Operating Plan and Budget on 13 December 2021, and the PTI Budget was received as input into the FY23 IANA Operating Plan and Budget.

      The FY23 PTI Operating Plan and Budget and the draft FY23 IANA Operating Plan and Budget are based on numerous discussions with members of ICANN org and the ICANN Community, including extensive consultations with ICANN Supporting Organizations, Advisory Committees, and other stakeholder groups throughout the prior several months. In July 2021, preliminary consultations were conducted with stakeholders on FY23 priorities for Public Technical Identifiers (PTI). These engagements were in the form of discussions with Supporting Organizations and Advisory Committees, as well as the gTLD Registries Stakeholder Group, Regional Internet Registries and IETF leadership. In addition, two Community Webinars were held on 27 July 2021.

      All comments received through the Public Comment proceeding were considered in relation to the FY23 IANA Operating Plan and Budget.  Where feasible and appropriate these inputs have been incorporated into the final FY23 IANA Operating Plan and Budget proposed for adoption.

      Adopting the FY23 IANA Operating Plan and Budget will have a positive impact on ICANN in that it provides a proper framework by which the IANA services will be performed, 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 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. GNSO Supplemental Recommendation on EPDP Phase 1 Recommendation 12

      Whereas, on 20 February 2019, the Expedited Policy Development Process team (EPDP) Phase 1 team published its Final Report1 on the Temporary Specification for gTLD Registration Data.

      Whereas, on 4 March 2019, the GNSO Council approved all 29 of the Final PDP recommendations as documented in the EPDP Working Group's Phase 1 Final Report.

      Whereas, on 29 March 2019, the GNSO Council transmitted its Bylaws-mandated Recommendations Report to the ICANN Board of Directors, recommending that the Board adopt all the Phase 1 policy recommendations.

      Whereas, on 4 March 2019, the Phase 1 Final Report was published for public comment to inform Board action on the report, in accordance with the Bylaws.

      Whereas, on 15 May 2019, the Board adopted the EPDP Phase 1 recommendations with the exception of Recommendation 1, Purpose 2, and Recommendation 12, which the Board did not adopt in full. The Board articulated its reasons for not adopting Recommendation 12, with respect to the option to delete data in the Organization field in its scorecard titled "Scorecard: EPDP Phase 1 Recommendations." 

      Whereas, the ICANN Board chose not to adopt implementation advice 2(b) of Recommendation 12, given that the deletion of the contents in the organization field might result in the loss of identifying information about who the registrant is and might not be consistent with ICANN's mission or in the global public interest.

      Whereas, per Bylaws requirements the GNSO Council reviewed the Board statement and initiated a discussion with the ICANN Board.

      Whereas, on 14 October 2019, the Board suggested to the GNSO Council that including an additional safeguard, similar to the safeguard applied with respect to the administrative contact field, within a supplemental recommendation might be a path forward for Board adoption of Recommendation 12.

      Whereas, on 19 December 2019, the GNSO Council adopted Recommendation 12 by a supermajority, amending the text of Recommendation 12 to state that "prior to eliminating Organization Contact fields, all Registrars MUST ensure that each registration contains Registered Name Holder contact information" (Supplemental Recommendation 12).

      Whereas, the Board considered the Supplemental Recommendation 12 and corresponded with the GNSO Council throughout 2020 and 2021. On 23 October 2021, the Board shared its understanding of the intent and impact of Recommendation 12 once the Registration Data Policy is implemented with the GNSO Council for further clarification.

      Whereas, on 14 December 2021 the Board and GNSO Council discussed the Board's understanding in detail.

      Whereas, on 21 January 2022, the GNSO Council generally confirmed the Board's understanding of the intent and impact of Recommendation 12, once implemented, as outlined in  its 21 January 2022 letter.

      Resolved (2022.02.24.05), the Board adopts the GNSO Council's Supplemental Recommendation on the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP) Phase 1, Recommendation 12, concerning the deletion of data in the Organization field as it addresses the Board's overarching concern of loss of essential data, should there ever be the need to contact the registered name holder and is in the best interests of ICANN and the ICANN community.

      Resolved (2022.02.24.06), the Board directs the ICANN President and CEO, or his designee(s), to include the appropriate guidance as described in the GNSO 21 January 2022 correspondence as part of the implementation of the Registration Data Policy.

      Rationale for Resolutions 2022.02.24.05 – 2022.02.24.06

      Why is the Board addressing the issue?

      On 20 February 2019, the Expedited Policy Development Process team (EPDP) Phase 1 team published its Final Report on the Temporary Specification for gTLD Registration Data. On 4 March 2019, the GNSO Council adopted the Final Report by a supermajority and ICANN org subsequently commenced a public comment period. The Board resolved to adopt the recommendations, with some exceptions, on 15 May 2019. The Board did not adopt Recommendation 12 in full with respect to the recommendation's implementation advice 2(b) which allows the deletion of registration data in the organization field.  Recommendation 12 relates to the publication or deletion of data in the organization field. The ICANN Board chose not to adopt implementation advice 2(b) of Recommendation 12, where contracted parties are given the option to delete data in the Organization field due to the concern that this would result in loss of necessary information if a registrant does not reply to a registrar's inquiry. The Board articulated its reasons for not adopting Recommendation 12, with respect to the option to delete data in the Organization field in the scorecard titled "Scorecard: EPDP Phase 1 Recommendations." Within the scorecard the Board highlighted its concern about losing necessary information if a registrant does not reply to a registrar's inquiry. Subsequently, the Board issued a Board Statement to the chair of the GNSO Council requesting a discussion per the Bylaw requirements (Annex A-1, Section 6.c).

      What is the proposal being considered?

      Under ICANN Bylaws Annex A section 9.d, the Board is taking action at this time to adopt the GNSO Council Supplemental Recommendation on the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP) Phase 1, Recommendation 12, concerning the Organization field.

      Which stakeholders or others were consulted?

      The GNSO Council discussed this topic during its Council meetings on 28 May 2019, 26 June 2019, 18 July 2019, 22 August 2019, 24 October 2019 and 6 November 2019, and with the ICANN Board during its joint sessions at ICANN65 and ICANN66, on 24 June 2019 and 3 November 2019 respectively. The GNSO Council also solicited additional information from the EPDP team to prepare for the upcoming discussion with the ICANN Board. The GNSO Council's initial communication with the EPDP Phase 2 team on this topic occurred on 16 May 2019 to inform the team of the Board's decision to defer the adoption of Recommendation 1, Purpose 2 for further consideration in EPDP Phase 2, and the non-adoption of the aspect of Recommendation 12 that permitted the deletion of registrant organization field data, resulting in a dialogue between the Board and the GNSO Council.

      On 9 June 2019, the EPDP Phase 2 Chair corresponded with the Chair of the GNSO Council identifying additional context for the EPDP Team's rationale for its Recommendation 12; however, there was no agreement at that stage on whether or not the Board's non-adoption should be supported.  On 24 June 2019, the GNSO Council held its working session at ICANN65 in Marrakech, Morocco and discussed Recommendation 12 in response to the GNSO Council's request to the EPDP team for substantive feedback on the Board's decision. The GNSO Council Chair wrote to the EPDP team on 31 October 2019 articulating that the Council was aiming to conclude the GNSO-Board discussion based on input received by the Board. On 3 November 2019, the GNSO Council met with the Board, and EPDP team members during the ICANN66 public meeting to discuss potential next steps forward resulting in the GNSO council resolving supplemental implementation guidance.

      What concerns or issues were raised by the community?

      Following the GNSO Council approval of the Supplemental Recommendation related to Recommendation 12, the Business Constituency (BC) group released a public statement supporting the supplemental guidance provided by the GNSO Council to address a concern similar to the Board's regarding the deletion of data.

      What significant materials did the Board review?

      The Board reviewed the following significant materials:

      • The 15 May 2019 Board statement on adopting 27 out of the 29 recommendations.

      • The GNSO Council's 09 September 2019 letter updating the Board on the EPDP Phase 1 consultation process.

      • The Board's 14 October 2019 letter welcoming the Recommendation 12 rationale that was provided during the Board-GNSO Council ICANN65 meeting.

      • The GNSO Council's 23 December 2019 letter, notifying the Board of its supermajority adoption of the Recommendation 12 supplemental guidance.

      • The Board's 11 December 2020 letter sharing their concern that data be retained someplace, as a safeguard rather than deleted.

      • The GNSO Council's 04 March 2021 letter clarifying the Boards concern that data published in Whois or RDAP is not the data on which the registrar primarily relies to maintain contact with the registrant.

      • The Board's 7 May 2021 letter acknowledging receipt of the GNSO council correspondence  concerning the Council's clarification on the Supplemental Guidance on EPDP Phase 1, Recommendation 12.

      • The Board's 23 October 2021 letter sharing their understanding of the impact and intent of Recommendation 12 once implemented in the Registration Data Policy.

      • The GNSO Council's 21 January 2022 letter confirming with the Boards assumptions on the intent and impact of Recommendation 12 once implemented.

      What factors did the Board find to be significant?

      The Board understands from the GNSO Council letter that "there is a significant legacy of mixed uses and purposes for this field. There is no standardization across the registrar landscape in how this field is processed." Thus, it is the Board's ​​understanding that the intent of EPDP Phase 1 Recommendation 12 is to provide requirements to standardize how the Registrant Organization Field is processed. The Board also acknowledges the GNSO Council statement that "the data published in Whois or RDAP is not the only data stored, nor is it the data on which the registrar primarily relies to maintain contact with the registrant" and understands that for existing registrations, deleted values will continue to be required to be maintained in the registrar record of changes to WHOIS information for the duration of the registrar's sponsorship of the domain name and for an additional 2 years per section 1.1 of the Data Retention Specification in the 2013 RAA. The requirement for new registrations is for Registrars to seek confirmation to publish the value in the Registrant Organization Field. If the Registrant declines publication of the value, the value will remain redacted, but the data will not be deleted.

      Are there positive or negative community impacts?

      Adopting the GNSO Council-adopted Supplemental Recommendation on the EPDP Recommendation 12 regarding the deletion of data will have a positive impact on ICANN and the community as it establishes safeguard mechanisms to prevent the chance of essential registrant data, should there ever be the need to contact the domain owner.

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

      Implementing the EPDP Phase 1 Recommendations is expected to have operational, financial, and/or other impact on registries and registrars who will implement new requirements to standardize how the Registrant Organization Field is processed.

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

      None at this time.

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

      This action is within ICANN's mission and mandate and in the public interest as ICANN's role is to coordinate the development and implementation of policies that are developed through a bottom-up consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet's unique names systems.  

      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 within ICANN's Organizational Administrative Function that does not require public comment, but it should be noted that the Final Report of policy recommendations were the subject of public comment as discussed above.

    3. AOB

Published on 28 February 2022


1 ICANN.org GNSO (20 Feb 2019), Final Report on Temporary Specification for gTLD Registration Data Expedited Policy Development Process, https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf p.15.