Contenido disponible solo en los siguientes idiomas

  • English

Approved Resolutions | Regular Meeting of the ICANN Board | 30 April 2023

1. Consent Agenda

a. Appointment of Independent Audit Firm for FY23

Whereas, the Board Audit Committee has discussed a recommendation from ICANN org to engage [Redacted – Confidential Negotiation Information] to carry out the independent audit for the fiscal year ending 30 June 2023 and has recommended that the Board authorize the Interim President and CEO, or her designee(s), to take all steps necessary to carry out the engagement.

Resolved (2023.04.30.01), the Board authorizes the Interim President and CEO, or her designee(s), to take all steps necessary to engage Moss Adams and Moss Adams member firms as the audit firm(s) for the financial statements for the fiscal year ending 30 June 2023.

Resolved (2023.04.30.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 Interim President and CEO, or her designee(s), determines that the confidential information may be released.

Rationale for Resolutions 2023.04.30.01 – 2023.04.30.02

The audit firm [Redacted – Confidential Negotiation Information]. Based on the report from the organization and the Audit Committee's evaluation [Redacted – Confidential Negotiation Information], the Committee has recommended that the Board authorize the Interim President and CEO, or her designee(s), to take all steps necessary to engage [Redacted – Confidential Negotiation Information] as ICANN's independent audit firm(s) for fiscal year 2023 for any annual independent audit requirements in any jurisdiction.

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

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

This is an Organizational Administrative Function not requiring public comment.

b. Recommendation on Board Committee Appointment

Whereas, the Board Governance Committee has recommended that the Board appoint Nicolas Caballero to the Board Technical Committee (BTC) and the Chair of the BTC agrees with the recommendation.

Resolved (2023.04.30.03), the Board appoints Nicolas Caballero to the Board Technical Committee.

Rationale for Resolution 2023.04.30.03

Article 7, Section 7.2 and Article 14 of the ICANN Bylaws call for the Board to appoint, among other things, membership of each Board Committee. Nicolas "Nico" Caballero joined the Board in March 2023 as the non-voting Governmental Advisory Committee Liaison to the Board. Upon joining the Board, Nico expressed interest in serving on the Board Technical Committee (BTC). His experience as outlined in his biography shows that he will bring valuable skills to the BTC.

The appointment of the Board Committee membership is consistent with ICANN's Mission and is in the public interest as it is important to ensure that the Board and its Committees have the properly skilled expertise to carry forth ICANN's Mission, Commitments and Core Values. This decision will have no direct fiscal impact on the organization and no impact on the security, stability, or resiliency of the domain name system.

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

2. Main Agenda

a. Amendments to Registrar Accreditation Agreement & Registry Agreement for RDAP

Whereas, the ICANN Board accepted the advice from SAC051 on 28 October 2011 and directed ICANN organization to produce, in consultation with the community, a roadmap for the coordination of the technical and policy discussions necessary to evaluate and adopt a replacement for the WHOIS protocol.

Whereas, the Base gTLD Registry Agreement (RA) and 2013 Registrar Accreditation Agreement (RAA) both provide that, until ICANN requires a different protocol, the contracted party will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service providing free public query-based access in the required format. The RA and RAA further provide that ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the contracted party will implement such alternative specification as soon as reasonably practicable.

Whereas, ICANN org and members of the gTLD Registries Stakeholder Group (RySG) and the Registrar Stakeholder Group (RrSG), collectively the Contracted Party House Negotiating Team (CPH-NT), worked together to draft proposed Global Amendments to the RA and RAA to specify the operational requirements for providing Registration Data Directory Services (RDDS) via the Registration Data Access Protocol (RDAP).

Whereas, the proposed Global Amendments include reporting requirements for registries that include changes to address the advice from the ICANN Security and Stability Advisory Committee in SAC097 related to inconsistent reporting of RDDS queries.

Whereas, the proposed Global Amendments include a change to the language of Specification 4, Section 3.1 of the RA that will enable ICANN org to use the existing Bulk Registration Data Access (BRDA) for research purposes.

Whereas, the proposed Global Amendments were posted for the contracted parties' approval and received Registry Operator Approval, Registrar Approval, and Brand Registry Operator Approval, as defined in each of the RA, RAA, and Specification 13 of the RA.

Whereas, the Board determined that no further revisions to the proposed Global Amendments are necessary after taking the public comments and voting results into account.

Resolved (2023.04.30.04), the Board approves the proposed Global Amendments to the Base gTLD Registry Agreement, the 2013 Registrar Accreditation Agreement, and Specification 13 to the Base gTLD Registry Agreement.

Resolved (2023.04.30.05), the Board directs the ICANN Interim President and CEO, or her designee(s), to take the actions necessary to finalize and effect the Global Amendments.

Rationale for Resolutions 2023.04.30.04 – 2023.04.30.05

Why is the Board addressing the issue now?

In 2010, the ICANN community held discussions about the need for the technical evolution of the WHOIS system, citing that the WHOIS protocol did not meet the community's needs. On 19 September 2011, the Security and Stability Advisory Committee (SSAC) issued SAC051 advising the ICANN community to evaluate and adopt a replacement for the WHOIS protocol. The SSAC made the recommendation based on the shortcomings found with the WHOIS protocol such as the lack of (1) support for internationalization, (2) secure access to data, (3) differentiated access, and (4) standardized query, response, and error responses.

In 2011, the ICANN Board passed a resolution directing staff to produce, in consultation with the community, a roadmap for the coordination of the technical and policy discussions necessary to implement the recommendations outlined in SAC051. Subsequently, RDAP was developed by the technical community through the Internet Engineering Task Force (IETF) as described in STD95.  In 2017, ICANN launched the voluntary RDAP pilot program at the request of the gTLD Registries Stakeholder Group and with the support of the Registrar Stakeholder Group.

On 17 May 2018, the ICANN Board passed a resolution adopting a Temporary Specification for gTLD Registration Data requiring (1) registry operators and registrars to operate a RDAP service, (2) ICANN org and the community to define the appropriate RDAP profile(s), and (3) registry operators and registrars to implement the service no later than 135 days after being requested by ICANN. Both the 2013 RAA and the RA include an obligation to implement the new RDDS protocol within 135 days of ICANN's request once the IETF produces a standard; and for registries, the implementation of the standard must be considered commercially reasonable in the context of the overall operation of the registry.

In February 2019, pursuant to requirements in the RA, RAA, and the Temporary Specification for gTLD Registration Data, ICANN org triggered the obligations for all registries and registrars to implement RDAP by 26 August 2019. Subsequently in October 2019, ICANN org initiated negotiations with the RySG and RrSG to develop amendments to the RA and the RAA to specify the operating requirements for RDAP and to define the plan to sunset obligations to provide RDDS via the WHOIS protocol.

In July 2022, ICANN and the CPH-NT reached agreement on the proposed amendments and the amendments were posted for public comment from 6 September through 16 November 2022. As set out in the Public Comment Summary Report, ICANN org and the CPH-NT confirmed that the proposed amendments met the stated objective of creating clear contractual obligations for registry operators and registrars to provide RDDS via RDAP and phasing out certain obligations to provide RDDS via the WHOIS protocol.

On 4 January 2023, ICANN org notified applicable registries, applicable brand registries, and applicable registrars of their eligibility to vote on the proposed Global Amendments to the RA, Specification 13 of the RA, and RAA. The 60-day voting period opened at 17:00 UTC on 19 January 2023 and closed at 23:59 UTC on 20 March 2023. Table 1 below provides an overview of the required thresholds to be considered approved by Applicable Registry Operators, Applicable Brand Registry Operators, and Applicable Registrars, respectively. All calculations of the vote were conducted pursuant to Section 7.6(j)(ii) of the RA, Section 9 of Specification 13 to the RA, and Section 1.18.1 of the RAA.

Table 1: Global Amendment Vote Thresholds and Tabulations

  Required Threshold Final Vote Tabulations
Applicable Registry Operator - Fee Threshold $25,668,185.81 $28,559,070.20
Applicable Brand Registry Operator - Fee Threshold $6,639,529.04 $6,827,060.77
Applicable Registry Operator - Majority Threshold 581 856
Applicable Brand Registry Operator - Majority Threshold 202 272
Applicable Registrar Approval - Threshold 90% 91.74%

What is the proposal being considered?

The contractual amendments negotiated between ICANN org and the CPH-NT include:

  • A requirement to comply with the RDAP profile.
  • Updated definitions for RDDS-related terms; this includes updating Specification 13 for .BRAND Registry Operators.
  • Reporting requirements for registries that include changes to address the advice from the SSAC in SAC097 related to inconsistent reporting of RDDS queries.
  • Service Level Requirements for RDAP availability, round-trip time, and update time.
  • The sunset of the requirements to provide RDDS via the WHOIS protocol over a period of 18 months from the amendment effective date.
  • The requirement for registrars to provide RDAP for all gTLD Domains Under Management, eliminating the option for registrars supporting registries that provide complete contact information in their RDDS to relay the registration data from the registry.
  • A change to the language of Specification 4, Section 3.1 of the RA that will permit ICANN org to use the existing Bulk Registration Data Access (BRDA) for research purposes. This amendment will enable ICANN to use BRDA data to conduct important research for projects such as the Domain Abuse Activity Reporting System (DAAR). DAAR is a system for studying and reporting on domain name registration and security threats. The overarching purpose of DAAR is to develop a robust, reliable, and reproducible methodology for analyzing security threat activity, which the ICANN community may use to make informed policy decisions.
  • Updates to Uniform Resource Locator (URL) web addresses in the RA and miscellaneous changes (e.g., URLs updated to "https" from "http") to address outdated links.

Which stakeholders or others were consulted?

ICANN org conducted a Public Comment proceeding on the proposed Global Amendments from 06 September 2022 through 16 November 2022. The Global Amendments received Registry Operator Approval, Brand Registry Operator Approval, and Registrar Approval in accordance with Section 7.6(j)(ii) of the RA, Section 9 of Specification 13 to the RA, and Section 1.18.1 of the RAA.

What concerns or issues were raised by the community?

ICANN org received five (5) comments from five (5) organizations. Comments noted in the Public Comment Summary Report provided general support for the proposed amendments with three (3) organizations offering feedback for ICANN org to consider before additional steps were taken. Two organizations, the SSAC and the Business Constituency, raised the concern that the sunsetting of web-based WHOIS may have a negative impact for end users as the deployment of RDAP lookup services may vary by registry and the loss of human-readable output to queries via web-based WHOIS may be lost in the transition.

However, tools such as https://lookup.icann.org from ICANN org provides a domain name registration data lookup tool, freely available to the general public. This tool uses the RDAP protocol to perform domain registration data queries and provides results in a human-friendly output and similar tools are also readily available. The advantages of the RDAP protocol and the provisions contained in the proposed Global Amendment, such as adherence to certain output requirements (i.e., the RDAP Profile), allow for tools such as these mentioned to exist.

Following a review of the public comments by ICANN org and the CPH-NT, the comments confirmed that the proposed amendments met the stated objective of creating clear contractual obligations for registry operators and registrars to provide RDDS via RDAP and phasing out certain obligations to provide RDDS via the WHOIS protocol. ICANN org and the CPH NT also determined that based on the comment from the SSAC, a modification to the proposed RA Specification 3 was appropriate and was made before the amendments were posted for the contracted parties' approval.

What significant materials did the Board review?

As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:

What factors has the Board found to be significant?

The Board carefully considered the public comments received for the proposed Global Amendments, along with the summary and analysis of those comments. The Board also considered the terms agreed upon by the CPH-NT as part of the negotiations with ICANN org. The Board appreciates the general support from the ICANN community for the new contractual obligations for RDAP negotiated between ICANN and the CPH-NT and for the steps taken to enable the use of BRDA for research purposes, e.g., to combat DNS abuse.

The Board also acknowledges the concern expressed by some community members regarding the sunset of the WHOIS protocol and that the proposed RAA amendment removes the "interactive web page" currently offered by registrars. However, the Board notes that users will have suitable, if not improved, tools to conduct queries for domain name registration data based on the current implementation of RDAP by all registries and registrars, the lookup tool from ICANN and other similar offerings, and furthered by the requirements set forth in the proposed Global Amendments. This is because Domain Name Registration Data is decentralized, meaning it is held at each of the relevant ICANN Accredited registrars and gTLD registry operators. After the transition to RDAP, the individual, interactive web-pages offered by each registrar and registry for WHOIS queries are no longer necessary because the RDAP protocol allows for user-friendly lookup queries from a centralized client such as the ICANN lookup tool (https://lookup.icann.org). Thus, finding sources to look up registration data should not be a challenge as searching for "domain registration lookup" in most search engines today will offer free tools, frequently with the ICANN org tool as the first result. Guiding users to centralized tools where the only required knowledge is the domain name they seek registration date for (as opposed to the user needing to know which registrar was used to register the name, as is the case with the WHOIS protocol) is a better solution than explaining the number of steps required to find the correct sponsoring registrar and its interactive web page for querying domain name registration data.

The Board further recognizes the input from the SSAC regarding SAC097 and that the originally proposed language in Specification 13 of the amendment to the RA may still report per-TLD statistics inaccurately for TLDs under shared registry systems. While ICANN and the CPH-NT were satisfied that the originally proposed language was a significant improvement over the existing language of the RA, additional language has been added to the RA amendment to further clarify (see below in blue). Once implemented this will provide additional accuracy for reporting for TLDs in this scenario.

For gTLDs that are part of a single-instance Shared Registry System: (1) the fields whois43-queries, web-whois-queries, searchable-whois-queries and rdap-queries in the Registry Functions Activity Report should match the sum of queries reported for the gTLDs in the single-instance Shared Registry System; (2) in case of queries related to the fields in (1) above for which the Registry Operator cannot determine the TLD to count the query to (e.g., a registrar lookup query for a registrar operating in more than one TLD sharing the same RDAP base URL), registries have the flexibility to choose how to allocate those queries across the gTLDs utilizing the single-instance Shared Registry System; and (3) the Registry Functions Activity Report may include the total contact or host transactions for all the gTLDs in the system.

The Board is confident the contractual language added by ICANN org and the CPH-NT following the Public Comment period adequately clarifies what is required and, once implemented, will provide additional accuracy for reporting for TLDs under share registry systems.

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

There is no significant fiscal impact expected from the approved amendments to the RA, Specification 13, or the RAA. In February 2019, pursuant to requirements in the RA, RAA, and the Temporary Specification for gTLD Registration Data, ICANN org triggered the obligations for all registries and registrars to implement RDAP by 26 August 2019 and no additional cost considerations or impacts to registries and registrars should be incurred.

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

The approved amendments to the RA, Specification 13, and RAA are not expected to create any security, stability, or resiliency issues related to the DNS.

b. ICANN FY24-28 Operating and Financial Plan, ICANN FY24 Operating Plan and Budget

Whereas, the draft ICANN FY24-28 Operating and Financial Plan and draft ICANN FY24 Operating Plan and Budget were posted for public comment in accordance with the Bylaws on 14 December 2022.

Whereas, the public comments received were considered and revisions were applied as appropriate and feasible to the Proposed for Adoption ICANN FY24-28 Operating and Financial Plan and Proposed for Adoption ICANN FY24 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 public session during ICANN 76.

Whereas, the Board Finance Committee (BFC) has discussed and oversaw ICANN organization's development of the Proposed for Adoption ICANN FY24-28 Operating and Financial Plan and the Proposed for Adoption ICANN FY24 Operating Plan and Budget.

Whereas, the BFC reviewed and discussed suggested changes to the ICANN FY24-28 Operating and Financial Plan and the ICANN FY24 Operating Plan and Budget resulting from public comment and consultations, as well as those resulting from recent Board decisions, and recommended that the Board approve the Proposed for Adoption ICANN FY24-28 Operating and Financial Plan and the Proposed for Adoption ICANN FY24 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 FY24 are included in the Proposed for Adoption ICANN FY24 Operating Plan and Budget.

Resolved (2023.04.30.06), the Board adopts the ICANN FY24-28 Operating and Financial Plan, which describes the activities ICANN will undertake and the resources needed to achieve the Board-adopted ICANN Strategic Plan for Fiscal Years 2021-2025.

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

Rationale for Resolutions 2023.04.30.06 – 2023.04.30.07

On 14 December 2022, a draft of the ICANN FY24-28 Operating and Financial Plan and draft ICANN FY24 Operating Plan and Budget were posted for public comment. The published draft ICANN FY24-28 Operating and Financial Plan and draft ICANN FY24 Operating Plan and 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.

Public comments received were considered, as well as recent decisions by the ICANN Board, and revisions were applied as appropriate and feasible to the Proposed for Adoption ICANN FY24-28 Operating and Financial Plan and Proposed for Adoption ICANN FY24 Operating Plan and Budget.

In addition, the following consultation activities were carried out:

  • 8 September 2022 – Community webinar held at ICANN 75 Prep Week on the Planning and Finance Update
  • 15 December 2022 – Community webinars were held to review the draft ICANN FY24-28 Operating and Financial Plan and draft ICANN FY24 Operating Plan and Budget published for public comment
  • 28 February 2023 – the summary of comments received through the public comment process were shared in a public session during the ICANN 76 Prep week, including with representatives of the ICANN bodies that submitted the public comments, to help ensure the comments were adequately understood and appropriate consideration was given to them.
  • In addition to the public comment process, from December 2022 – February 2023 ICANN actively solicited community feedback and consulted with the ICANN community by other means, including attendance and presentations for At-Large Operations, Finance, and Budget Working Group, Generic Names Supporting Organization Standing Committee on ICANN Budget and Operations Plan, and Country Code Names Supporting Organisation Strategic and Operational Planning Standing Committee.

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

There were no changes to the Operating Plans, Funding or Expenses for the Proposed for Adoption ICANN FY24-28 Operating and Financial Plan and the Proposed for Adoption ICANN FY24 Operating Plan and Budget as a result of public comment. The only changes made to the Proposed for Adoption Plans were the result of Board passing resolutions for the New gTLD Program Next Round and Registration for Data Request implementations after the Draft Plans were posted for public comment. The remainder of the changes were in narrative and presentation only.

In addition to the day-to-day operational requirements, the ICANN FY24 Operating Plan and Budget allocates amounts to various FY24 budget requests received from community leadership. The ICANN FY24 Operating Plan and Budget also discloses financial information on the 2012 Round of the New gTLD Program, relative to expenses, funding and net remaining funds. Further, because the Registrar Fees are key to the development of the Budget, the ICANN FY24 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 ICANN FY24-28 Operating and Financial Plan and the ICANN FY24 Operating Plan and Budget 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 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.

c. Policy Recommendations concerning Curative Rights Protections for International Governmental Organizations (IGOs)

Whereas, on 5 June 2014, the Generic Names Supporting Organization (GNSO) Council resolved1 to initiate a Policy Development Process (PDP) to evaluate whether ICANN's second-level dispute resolution mechanisms, the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension System (URS), should be amended to enable their access and use by International Governmental Organizations (IGOs) and International Non-Governmental Organizations (INGOs), or if a separate, narrowly-tailored procedure modeled on these curative rights protection measures should be developed to apply only to protected IGO and INGO identifiers.

Whereas, on 17 July 2018, the GNSO IGO-INGO Access to Curative Rights Protection Mechanisms Policy Development Process (PDP) Working Group completed its work and submitted its Final Report2 to the GNSO Council.

Whereas, on 18 April 2019, the GNSO Council approved3 the first four recommendations from the PDP Working Group. With respect to Recommendation #5, the GNSO Council directed the Review of All Rights Protection Mechanisms (RPMs) PDP Working Group to consider, as part of its Phase 2 work, whether an appropriate policy solution can be developed that is generally consistent with the four recommendations that the GNSO Council approved and in line with specific considerations laid out by the GNSO Council, including recognizing the possibility that an IGO may have jurisdictional immunity in some circumstances and preserving a registrant's right to a judicial review of a UDRP or URS panel decision.

Whereas, on 19 August 2021, in view of its decision to review the scope of Phase 2 of the RPMs PDP, the GNSO Council took the procedural step4 of initiating an Expedited Policy Development Process (EPDP) on Specific Curative Rights Protections for IGOs, to continue the work originally launched as a separate IGO Work Track within the RPMs PDP and with the same scope of work.5

Whereas, on 4 April 2022, the EPDP on Specific Curative Rights Protections for IGOs completed its work and submitted its Final Report6 to the GNSO Council.

Whereas, on 15 June 2022, the GNSO Council unanimously approved7 all five Full Consensus recommendations from the EPDP on Specific Curative Rights Protections for IGOs and transmitted its Recommendations Report8 to the Board on 21 July 2022.

Whereas, the IGO-INGO Access to Curative Rights Protection Mechanisms PDP and the EPDP on Specific Curative Rights Protections for IGOs have followed all the necessary steps and processes required by the ICANN Bylaws, the GNSO PDP Manual and the GNSO Working Group Guidelines, including the publication of Initial Reports9 for Public Comments and consideration of the public comments received.

Whereas, on 11 July 2019 and 28 November 2022, respectively, the Final Reports of the IGO-INGO Access to Curative Rights Protection Mechanisms PDP and the EPDP on Specific Curative Rights Protections for IGOs were published for Public Comment10 to inform Board action on the reports, in accordance with the Bylaws.

Whereas, on 11 July 2019, the ICANN Board notified11 the Governmental Advisory Committee (GAC) of the GNSO Council's approval of four of the five recommendations from the IGO-INGO Access to Curative Rights Protection Mechanisms PDP, in accordance with the Bylaws, and on 20 August 2019, the GAC advised the Board to abstain from taking a decision to allow the parties sufficient time to explore possible ways forward.12

Whereas, on 14 October 2019, the Board informed the GAC that the Board had formed a new Caucus Group on the topic, and it did not intend to act at the time on the four PDP recommendations until the Caucus Group has reviewed and formulated suggestions for possible paths forward13.

Whereas, on 1 December 2022, the Board notified14 the GAC of the GNSO Council's approval of all five recommendations from the EPDP on Specific Curative Rights Protections for IGOs.

Whereas, on 20 March 2023, in its Cancun Communiqué,15 the GAC advised the Board, to proceed with the approval of the recommendations of the EPDP on Specific Curative Rights Protections for IGOs for implementation.

Whereas, following review of the matter by the Board's Caucus Group, the Board has considered the recommendations that the GNSO Council approved from the two policy development processes as well as the Public Comments submitted.

Resolved (2023.04.30.08) the Board thanks the members of the IGO-INGO Access to Curative Rights Protection Mechanisms PDP Working Group and the members of the EPDP team on Specific Curative Rights Protections for IGOs for their dedication and work on these longstanding policy issues.

Resolved (2023.04.30.09), the ICANN Board adopts the four recommendations that the GNSO Council approved from the IGO-INGO Access to Curative Rights Protection Mechanisms PDP and the five recommendations that the GNSO Council approved from the EPDP on Specific Curative Rights Protections for IGOs.

Resolved (2023.04.30.10), the ICANN Board directs the ICANN Interim President and CEO, or her designee(s), to proceed with the implementation of these recommendations as soon as feasible. The Board further directs the ICANN Interim President and CEO, or her designee(s), to develop and submit to the Board an implementation plan, including estimates on staffing, resources and timelines, to inform the Board as to how the implementation of these recommendations fit into ICANN org's operational planning and prioritization of its ongoing work to implement other community-developed recommendations that the Board has adopted.

Rationale for Resolutions 2023.04.30.08 – 2023.04.30.10

Why is the Board addressing the issue?

The appropriate nature and scope of policy protections for the names and acronyms associated with International Governmental Organizations (IGOs) has been a longstanding issue in the community. In April 2014, following an initial GNSO PDP on Protection of IGO and INGO Identifiers in All gTLDs conducted between October 2012 and November 2013, the Board voted to adopt several GNSO PDP recommendations concerning top and second level protections for the full names of IGOs on a list prepared by the GAC. Those recommendations are now the subject of an ICANN Consensus Policy (effective 1 August 2018).16

The GNSO PDP had also recommended that the GNSO Council consider policy work to explore possible amendments to the UDRP and URS, to enable their use by protected IGOs and INGOs. The GNSO Council initiated the IGO-INGO Access to Curative Rights Protection Mechanisms PDP to consider the issue in June 2014. In July 2019, the GNSO Council approved four of the five recommendations from the GNSO IGO-INGO Access to Curative Rights Protection Mechanisms PDP and directed that additional policy work be conducted on the subject of the fifth recommendation that it decided not to approve. This resulted in the GNSO Council's chartering of the EPDP on Specific Curative Rights Protections for IGOs in August 2021.

Throughout the various policy processes, the GAC had provided Consensus Advice to the Board on the overall topic of IGO protections, including, specifically, on the question of second-level curative rights protections in the Los Angeles (October 2014), Hyderabad (November 2016) and Johannesburg (June 2017) Communiqués. In its most recent Cancun Communiqué (March 2023), the GAC advised the Board to proceed to adopt the EPDP recommendations and noted that this advice superseded those from the previous Communiques insofar as the EPDP recommendations propose "targeted amendments to the UDRP Rules to accommodate IGOs in addressing the abuse of IGO identifiers in the DNS".

Under Section 11.3(i)(x) of the ICANN Bylaws, the GNSO Council's Supermajority support for the four PDP recommendations and its unanimous approval of the five subsequent EPDP recommendations obligates the Board to adopt the recommendations unless, by a vote of more than two-thirds, the Board determines that the policy is not in the best interests of the ICANN community or ICANN.

What is the proposal being considered?

The four recommendations that the GNSO Council approved from the 2019 PDP included specific recommendations not to create a new and separate dispute resolution mechanism for IGOs and INGOs. For INGOs (but not IGOs), there was an additional recommendation not to amend the UDRP or URS. The remainder of the recommendations focused on the provision of Policy Guidance on the UDRP and URS by ICANN org to IGOs, registrants and the GAC, noting the procedural options available to IGOs that do not hold trademarks in their acronyms.

The five recommendations that the GNSO Council approved from the 2022 EPDP achieved Full Consensus across the EPDP team, which included participants from the GAC and several IGOs. The recommendations include the addition of a definition of "IGO Complainant" and a voluntary arbitration component to both the UDRP and URS Rules, without affecting the respondent-registrant's ability to file judicial proceedings against an IGO at any time during a UDRP or URS proceeding. The recommendations also address the question of what the applicable law in an arbitration proceeding should be, and the EPDP team provided high-level implementation guidance regarding the selection of arbitration provider(s) and the applicable arbitration rules.

As required by Article 3, Section 6.a.iii of the ICANN Bylaws, the GNSO Council-approved recommendations from both the PDP and EPDP were posted for Public Comment to inform Board action on the final recommendations. In considering the recommendations, the Board also reviewed the Public Comments and received briefings from ICANN org as well as a briefing from the GNSO Council on the EPDP outcomes.

Which stakeholders or others were consulted?

In accordance with the requirements of the GNSO PDP Manual, the Working Group for the IGO-INGO Access to Curative Rights Protection Mechanisms PDP solicited early input from the Supporting Organizations and Advisory Committees as well as the GNSO's Stakeholder Groups and Constituencies. It also engaged an external legal expert, Professor Edward Swaine of the George Washington University Law School in the United States, to provide advice on the topic of IGO jurisdictional immunity.

Concerns expressed by several GNSO Council members representing different sectors of the community regarding the one recommendation from the IGO-INGO Access to Curative Rights Protection Mechanisms PDP that the GNSO Council did not approve meant that the scope of work for the EPDP on Specific Curative Rights Protections for IGOs was the subject of extensive deliberations within the GNSO Council. The Council also consulted with the GAC and IGO representatives in drawing up the final charter for the work.

As mandated by the GNSO's PDP Manual, the PDP Working Group and the EPDP team both published their Initial Reports for Public Comments. There were 46 comments submitted to the Initial Report from the PDP Working Group on IGO-INGO Access to Curative Rights Protection Mechanisms, 21 of which were from IGOs, with five from different ICANN community structures. The EPDP team on Specific Curative Rights for IGOs received 33 comments, including six from IGOs and six from various ICANN community groups. Both the PDP Working Group and EPDP team considered all the input received in finalizing their recommendations, in some cases amending their preliminary proposals due to the Public Comments received.

As required by the ICANN Bylaws, additional Public Comment proceedings for both Final Reports were conducted, to allow the public to comment on the proposed recommendations prior to Board action. In addition, as also required by the Bylaws, the Board notified the GAC of the recommendations that the GNSO Council had transmitted to the Board, to allow the GAC to provide timely advice on any public policy concerns that it may have with the recommendations.

What concerns or issues were raised by the community?

The community provided feedback through Public Comments on the Initial and Final Reports from both the PDP Working Group and the EPDP team. ICANN org provided the Board with a summary report of all the Public Comments received to both sets of final recommendations.

In general, the community was divided in its support for the recommendations from the IGO-INGO Access to Curative Rights Protection Mechanisms PDP, with IGOs considering that the recommendations did not go far enough to protect IGO identifiers against abuse at the second level of the domain name system, while commentators representing registrants welcomed the PDP Working Group's recommendation not to create a new and separate dispute resolution procedure for IGOs and INGOs as well as its decision not to amend the UDRP and URS. For the subsequent EPDP recommendations, which will, if implemented, result in modifications to the UDRP and URS Rules, commentators representing registrants focused on the risk that registrant rights could be adversely affected or reduced if the recommendations were implemented in a way as to restrict a registrant's ability to file judicial proceedings against an IGO or to effectively compel a registrant to agree to arbitration. Those commentators representing the domain investor community were largely against the recommendations, while the IGO community and those ICANN community groups that submitted input were generally supportive.

What significant materials did the Board review?

The Board reviewed the following materials:

What factors did the Board find to be significant?

The Board appreciates the extensive work from across the community, including the GAC and IGOs, that resulted in the two sets of GNSO policy recommendations that are the subject of this vote, as well as the input provided throughout the policy process from numerous stakeholders, including individuals and governments. The Board notes that the community's policy work on the topic of curative rights protections for IGOs has spanned over ten years, culminating in the recent EPDP in which the GAC and IGO representatives participated, and which saw Full Consensus amongst all the members of the EPDP team on the final outcomes.

Are there positive or negative community impacts?

Adopting the final recommendations will have a positive impact on ICANN in that it will demonstrate that ICANN will have addressed complex issues and public policy concerns that have been the subject of longstanding and extensive community work. Board adoption of the recommendations will mean that IGOs that meet the criteria in the updated UDRP and URS Rules will be able to use these second-level dispute resolution mechanisms to address abusive registrations and use of domain names relating to their missions.

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

Implementing the two sets of recommendations is expected to have financial and resourcing impacts on ICANN org. Modifying the UDRP and URS Rules will impact the various dispute resolution service providers as well as ICANN-accredited gTLD registrars who will have to implement the new requirements and update their processes. To ensure successful implementation, it will be necessary to seek the cooperation and guidance of ICANN's current dispute resolution service providers.

In addition, as implementing the earlier PDP recommendations will require drafting of Policy Guidance to numerous parties and implementing the subsequent EPDP recommendations will require drafting of new provisions and the selection of appropriate arbitration rules and providers, it may be necessary to engage the services of external vendors and legal experts. Using third-party services will likely facilitate more efficient and timelier implementation of the relevant recommendations, but will result in increased costs to ICANN org.

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

None.

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 set forth in the ICANN Bylaws. The multistakeholder policy development process of bottom-up, consensus policies and guidelines help advance the stable and secure operation of the Internet's unique identifier 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?

As required by the ICANN Bylaws and the GNSO's policy procedures, the recommendations were published for Public Comment as discussed above.

d. Further Consideration of the Issues Regarding the .GCC Application

Whereas, GCCIX, W.L.L. (the applicant for .GCC) initiated an Independent Review Process (.GCC IRP) challenging the ICANN Board's acceptance of Governmental Advisory Committee (GAC) consensus advice that the .GCC application should not proceed (GAC Advice).

Whereas, in light of certain findings in prior IRP final declarations, the Board resolved to "authoriz[e] the President and CEO, or his designee(s), to seek a stay of the .GCC IRP and open an informal dialogue with the GAC regarding the rationale for the GAC consensus advice on the .GCC application."

Whereas, ICANN organization sought but was not granted a stay of the .GCC IRP; and ICANN org asked the GAC Chair to open the "informal dialogue."

Whereas, the GAC Chair responded to ICANN org, indicating that the GAC had reviewed "GAC discussions from 2013" and that the rationale for the GAC Advice was as follows (and as expressed in the GAC Early Warning): (i) "The applied-for string (GCC) is an exact match of the known acronym for an Intergovernmental Organization (IGO), the Gulf Cooperation Council and as such, warrants special protection to its name and acronym."; and (ii) "The application clearly targeted the GCC community without any support from the GCC, its six members or its community."

Whereas, following a recommendation from the Board Accountability Mechanisms Committee (BAMC) in May 2022, the Board, in a resolution: (a) "ask[ed] the BAMC to review, consider, and evaluate the underlying basis for the GAC consensus advice that the .GCC application should not proceed, the Board's acceptance of that advice, and relevant related materials; and (b) ask[ed] the BAMC to provide the Board with recommendations regarding next steps."

Whereas, in furtherance of the Board's resolution, the BAMC reviewed and considered the GAC Advice, the .GCC application, and relevant related materials as set forth in the Rationale and the Reference Materials, and carefully considered and discussed what is in the public interest.

Whereas, the BAMC has recommended that the analysis of the GAC Advice and other issues relating to the .GCC application be conducted now, rather than waiting for the completion of the .GCC IRP, in light of certain findings in prior IRP declarations and for the sake of efficiency.

Whereas, the BAMC has further recommended that the Board reaffirm its acceptance of the GAC Advice and its decision to not proceed with the .GCC application based on the second issue identified in the GAC's rationale for the GAC Advice, based on information contained in other materials relevant to the .GCC application as set forth in the Rationale and the Reference Materials, and based on consideration of whether proceeding with the .GCC application is in the public interest.

Resolved (2023.04.30.11), the Board: (a) has analyzed the GAC Advice and other issues relating to the .GCC application, as well as the BAMC's recommendation; (b) reaffirms its acceptance of the GAC Advice and its decision to not proceed with the .GCC application based on the second issue identified in the GAC's rationale for the GAC Advice, based on the Board's evaluation of other materials relevant to the .GCC application, which are set forth in the Rationale and the Reference Materials, and based on the Board's determination that proceeding with the .GCC application is not in the public interest; and (c) directs the Interim President and CEO, or her designee(s), to continue to not proceed with the .GCC application.

Rationale for Resolution 2023.04.30.11

After careful review of the underlying facts, prior applicable Independent Review Process (IRP) final declarations and the importance of respecting ICANN's accountability mechanisms, information from the Governmental Advisory Committee (GAC), the public interest, materials relevant to the .GCC application, and the Board Accountability Mechanisms Committee's (BAMC) recommendations, the Board decided to conduct an independent analysis of the GAC consensus advice that the .GCC application should not proceed (GAC Advice) and other issues relating to the .GCC application now, rather than waiting for the completion of the GCCIX, W.L.L. v. ICANN IRP (.GCC IRP). After having conducted said analysis, the Board has reaffirmed its acceptance of the GAC Advice and its decision to not proceed with the .GCC application based on the concern raised in the GAC's rationale for the GAC Advice regarding lack of support and involvement from the relevant community, based on the Board's evaluation of the GAC Advice and other inputs and materials relevant to the .GCC application as set forth in this Rationale and the Reference Materials, and based on the Board's determination that proceeding with the .GCC application is not in the public interest. Accordingly, the Board has directed ICANN org's Interim President and CEO, or her designee(s), to continue to not proceed with the .GCC application.

Background Information

Additional background information regarding GCCIX, W.L.L.'s .GCC application, the objections to the .GCC application, the GAC Advice, the prior applicable IRP final declarations, and the current .GCC IRP initiated by GCCIX, W.L.L. (Claimant or GCCIX) can be found in the supporting Board materials for this Resolution and for Board Resolutions 2021.09.12.08 and 2022.06.12.18, and is incorporated herein by reference.

In furtherance of the Board's September 2021 Resolution "authoriz[ing] the President and CEO, or his designee(s), to seek a stay of the .GCC IRP and open an informal dialogue with the GAC regarding the rationale for the GAC consensus advice on the .GCC application," ICANN org sought a stay of the .GCC IRP and engaged in an informal dialogue with the GAC regarding the GAC Advice. ICANN org sent a letter to the GAC Chair on 9 November 2021 to open the informal dialogue, seek input from the GAC regarding how it would like to engage with ICANN org in this dialogue, and asking whether the GAC would like to receive any additional information from ICANN org on the topic. As an initial response, the GAC requested that ICANN org provide some factual background to the GAC on the matter, which ICANN org did on 14 December 2021. The GAC discussed the matter on 14 December 2021 and on 20 January 2022.

On 25 January 2022, the GAC Chair sent a letter to ICANN org indicating that the GAC had reviewed "GAC discussions from 2013 held in closed sessions at ICANN46 in Beijing on the .GCC application, which helped inform the language included in the Beijing Communiqué consensus advice text." In the letter, while acknowledging that the GAC did not provide a written rationale in the Beijing Communiqué for its advice relating to .GCC (properly noting that such a written rationale was not required to be included with the advice in 2013), the GAC Chair explained that: in November 2012, "the governments of Bahrain, Oman, Qatar and UAE issued a GAC Early Warning to the Applicant expressing serious concerns against the application"; in February 2013, "the GAC received requests from several GAC members (Bahrain, Oman, Qatar and UAE) as well as the Gulf Cooperation Council (GCC) to include '.GCC' in a GAC Objection Advice that the application should not proceed for the reasons highlighted in the GAC Early Warning"; and "that the GAC, during ICANN46 Beijing (April 2013) deliberated and reached consensus on 'GAC Objection Advice' […] for the reasons expressed by the concerned GAC members" as follows (and as expressed in the GAC Early Warning): (i) "The applied-for string (GCC) is an exact match of the known acronym for an Intergovernmental Organization (IGO), the Gulf Cooperation Council and as such, warrants special protection to its name and acronym."; and (ii) "The application clearly targeted the GCC community without any support from the GCC, its six members or its community."

Following a recommendation from the BAMC in May 2022, the Board passed a resolution: (a) "ask[ing] the BAMC to review, consider, and evaluate the underlying basis for the GAC consensus advice that the .GCC application should not proceed, the Board's acceptance of that advice, and relevant related materials; and (b) ask[ing] the BAMC to provide the Board with recommendations regarding next steps." In furtherance of the Board's resolution, the BAMC provided GCCIX with an opportunity to submit a response to the GAC's January 2022 communication (which the GCCIX submitted on 7 September 2022). As noted in further detail below, the BAMC proceeded to review, consider and evaluate the GAC Advice, the Board's acceptance of the GAC Advice, other inputs and materials relevant to the .GCC application, as well as what is in the public interest.

Discussion of the BAMC's Consideration and Recommendation

Pursuant to the Board's directive, the BAMC reviewed, considered and discussed the .GCC application, the GAC Advice, other relevant materials, and the public interest in order to be able to provide an informed recommendation to the Board. With regard to the .GCC application, of particular interest to both the BAMC and the Board were the statements in the application that:

  • ".GCC is an open Top Level Domain (TLD) created specifically to enhance and develop the provision of Internet services for users in the Gulf and Middle East region."
  • "We are committed to providing exemplary functional utility as well as an opportunity for Internet users with a connection to the Gulf and Middle East to secure a domain name in a new, innovative and competitive TLD."
  • ".GCC will create a region-specific new TLD that allows previously excluded and disadvantaged users to take a stake in a meaningful cultural and economic tool that is specifically designed to respond to their linguistic, cultural and specific business needs."
  • "GCC refers generally, but not exclusively, to the Cooperation Council for the Arab States of the Gulf.  Formed in May 1981 as a regional organization, it consists of six Gulf countries including Bahrain, Kuwait, Oman, Qatar, Saudi Arabia and United Arab Emirates. Its main objectives are to enhance coordination, integration and inter-connection between its members in different spheres. This application is not connected with or sponsored by the Council. .GCC does not purport to represent the Council."
  • ".GCC represents a strong competitive alternative to existing regional ccTLDs by providing instant registration and delegation under the most liberal framework permitted by law, within a TLD which has local significance."
  • ".GCC will be a valuable digital asset dedicated [to] residents living and working in the region."
  • .GCC is "[a] unique and meaningful three letter string."

The BAMC also considered the public comments regarding the .GCC application, as did the Board. While some of the comments were in support of a .GCC gTLD generally, the vast majority of comments were opposed to GCCIX's application for .GCC. For instance, the United Arab Emirates (UAE) stated that the application "is targeting the GCC community which basically covers the 6 member states of the GCC," but that the applicant "did not consult the targeted community in regards to launch of the proposed TLD, its strategy and policies." Likewise, a representative of Saudi Arabia stated that "[s]ince the applicant is not endorsed by the GCC or a majority of its members we strongly request ICANN not to accept this application." And several other commenters stated that the application is "sensitive" because "[t]he applicant (GCCIX WLL) is clearly not known as GCC and is not endorsed by the GCC (Gulf Cooperation Council)."

In addition, the BAMC and the Board considered the GAC Early Warning stating that the governments of Bahrain, Oman, Qatar and United Arab Emirates, and the GCC, expressed "serious concerns" with Claimant's .GCC application. Of particular import were the statements that the .GCC application "[lacks] . . . community involvement and support" and that "the applicant did not consult the targeted community in regards to launch of the proposed TLD, its strategy and policies. The applicant did not obtain any endorsement from the GCC Secretariat General or any of its organizations, or any governmental or nongovernmental organization within the GCC member states."

The BAMC, and the Board, also reviewed the ICANN Independent Objector's (IO) comments regarding the .GCC application. In particular, the IO stated his "opinion that the applied for gTLD string explicitly targets the community of the Arab States of the Gulf, even if the applicant indicates that the application does not intend to represent the international organization itself." "[T]hat [since] five of the six governments as well as the international organization directly targeted by the gTLD expressed their disagreement with the application, it must be considered that there is an obvious and substantial opposition from a significant portion of the community." The IO also noted that use of a .GCC gTLD without the endorsement of the GCC or its member states could lead to confusion and "adverse effects on the mission pursued by the [GCC]" and "could interfere with the legitimate interests of the community of the [GCC], especially since the gTLD is not expected to be managed on behalf of the organization and its interests."

Ultimately, the IO chose not to file an objection to the .GCC application because "the Gulf Cooperation Council is an established institution representing and associated with a significant part of the targeted community. The Gulf Cooperation Council is already fully aware of the controversial issues and is better placed than the IO to file an objection, if it deems appropriate[,]" which the GCC did when it initiated a Legal Rights Objection (LRO) proceeding against GCCIX's .GCC application. Although the LRO filings of GCCIX and the GCC17 focused mainly on intellectual property rights, which are beyond the scope of the BAMC's and the Board's consideration, the filings provided some helpful insights. For instance, the GCC's LRO brief set forth the founding and history of the GCC as well as the GCC's view that use of .GCC by GCCIX could cause confusion and the impression that the GCC has endorsed the operation of the .GCC gTLD and/or the content on domains using the .GCC gTLD. In its LRO filing, GCCIX argued that it "does not expect confusion."

In addition, the BAMC and the Board further considered the GAC Advice contained in the April 2013 Beijing Communiqué as well as the GAC's 25 January 2022 letter, which delineated the GAC's rationale for that advice. Of particular importance was the portion of the GAC's rationale that the .GCC "application clearly targeted the GCC community without any support from the GCC, its six members or its community," which is a view expressed in public comments on the .GCC application, in the GAC Early Warning on the .GCC application, and in the IO's comments on the .GCC application. Moreover, this view does not appear to have been meaningfully addressed by GCCIX in any of its communications to ICANN. For example, the BAMC and the Board considered several communications from GCCIX about its application, including: (i) GCCIX's 15 April 2013 letter to ICANN in response to the GAC Advice in the Beijing Communiqué; (ii) GCCIX's further response to the Beijing Communiqué, submitted on or around 10 May 2013; (iii) GCCIX's Reconsideration Request 13-17; and (iv) GCCIX's 7 September 2022 letter to ICANN regarding the GAC's 25 January 2022 letter. Despite these various communications that have spanned the past several years, as well as GCCIX's IRP filings, there has been no substantive response from GCCIX to the particular claim that the .GCC application is (and the selection of "GCC" for its applied-for string seems) aimed at attracting and engaging with members of the community represented by the GCC and its member states without the support of that community, the GCC, or the GCC member states, which represent approximately 60 million people in the Gulf and Middle East region.

The BAMC and the Board also considered materials relating to previous IRPs and to the current .GCC IRP. In particular, the IRP panels' findings in the .AFRICA and .AMAZON IRPs and their recommendations regarding the steps ICANN should have taken regarding GAC consensus advice that, when presented, did not include a written rationale, and regarding the independent analysis ICANN should have done in evaluating such advice. The BAMC and the Board also considered the actions ICANN took after the Final Declarations were issued in the .AFRICA and .AMAZON IRPs and evaluated the claims asserted by GCCIX in its Amended IRP Request. Specifically, GCCIX claims that: (i) ICANN should have sought from the GAC a rationale for the GAC Advice; (ii) that ICANN should have done an independent evaluation of that rationale; (iii) that ICANN should have provided GCCIX with treatment equal to that provided to similarly situated applicants, such as those for .AFRICA and .AMAZON; and (iv) that ICANN should provide a rationale for any action it takes on account of the GAC Advice regarding the .GCC application.

After extensive analysis and discussion, and after considering several options regarding the .GCC application, the BAMC has recommended that the independent analysis of the GAC Advice and other issues relating to the .GCC application be conducted now, rather than waiting for the completion of the .GCC IRP. Notwithstanding the fact that ICANN's acceptance of the GAC Advice in 2013 was consistent with the terms of Guidebook, two subsequent IRP panels have held that the Board should have conducted a further evaluation of the issues raised in the respective GAC Communiqués. In light of those findings, conducting such a further evaluation now in the .GCC matter is the prudent course of action, demonstrates the seriousness with which the Board considers ICANN's Accountability Mechanisms, and should allow the current IRP to proceed more efficiently. This is also in keeping with ICANN's Core Value to "remain accountable to the Internet community through mechanisms defined in [the] Bylaws that enhance ICANN's effectiveness."

The BAMC has further recommended that the Board reaffirm its acceptance of the GAC Advice and its decision to not proceed with the .GCC application based the second issue identified in the GAC's rationale for the GAC Advice (regarding lack of support and involvement from the relevant community), based on information contained in other inputs and materials relevant to the .GCC application as set forth in this Rationale and the Reference Materials, and based on consideration of whether proceeding with the .GCC application is in the public interest.

Consistent with certain of the concerns raised in the GAC Early Warning, in the GAC's rationale for the GAC Advice, in the IO's comments, as well as by members of the community, the BAMC and the Board note that GCCIX's .GCC application appears to be directly aimed at attracting and engaging with members of the community represented by the GCC and its member states without the support of that community, the GCC, or the GCC's member states. And, in fact, it is not a mere lack of support, the GCC and its member states have repeatedly objected to GCCIX's .GCC application. Moreover, the BAMC noted its concern that GCCIX's selection of the term "GCC" for its applied-for string seems intentional in order to attract (and/or will have the effect of attracting) the relevant community as a result of the association of the Gulf Cooperation Council with the "GCC" acronym and the reputation and goodwill that the GCC and its member states have developed through their representation of over 60 million people in the Gulf and Middle East region over the last forty years, despite the fact that the application is not sponsored or endorsed by the GCC or its member states. Indeed, the .GCC application explicitly states that its intention is to target Internet "users in the Gulf and Middle East." In addition, the BAMC and the Board agree with the IO's comment that this dichotomy between appearances and actual support could lead to confusion as to what entity or group is behind the .GCC gTLD and its content, and it could interfere with the legitimate interests, mission, and community outreach of the GCC and its member states because they do not endorse the .GCC gTLD and will have no role in evaluating or moderating its operation or content. While official "support" is not necessarily required by the Guidebook because "GCC" is not a geographic name, as defined in the Guidebook, the lack of support from the relevant community, the GCC, and the GCC member states (Bahrain, Kuwait, Oman, Qatar, Saudi Arabia, and the United Arab Emirates) was relevant to both the BAMC's and the Board's analysis of whether this .GCC application is in the public interest.

The BAMC and the Board are committed to ICANN's Mission and Core Values as set forth in the Bylaws, including ensuring that this decision is in the public interest. The community most likely impacted by the proposed .GCC gTLD has voiced their concerns through the public comments received regarding the .GCC application, the GAC Early Warning and the GAC Advice regarding the .GCC application, correspondence, and the LRO materials, which "reflect [both] the interests of [the] affected parties and the roles of bodies internal to ICANN." In addition, the IO's comments as well as the GCC's own comments specifically note that use of .GCC by GCCIX could cause confusion and the false impression that the GCC has endorsed the operation of the .GCC gTLD and/or the content on domains using the .GCC gTLD. Potentially causing confusion for Internet users both within the relevant community as well as more broadly is not in the global public interest. Even more so when it appears that GCCIX intentionally chose the "GCC" string in an effort to benefit from the reputation and goodwill that the GCC and its member states have developed through their representation of over 60 million people in the Gulf and Middle East region over the last forty years. Similarly, ICANN's decisions should be guided by the Core Value of "recognizing that governments and public authorities are responsible for public policy and duly taking into account the public policy advice of governments and public authorities." Here, the GAC, through its GAC Advice and subsequent rationale supporting that advice, set forth its public policy position, and the Board is obligated under the Bylaws to consider the GAC's input as part of the Board's independent evaluation of the .GCC application, the GAC Advice, and other relevant materials. For all of these reasons, the BAMC and the Board are of the view that proceeding with GCCIX's .GCC application is not in the public interest.

The BAMC's recommendations are consistent with the approach ICANN has taken regarding other gTLD applications that were lacking support in the communities targeted by the applications, such as .ISLAM, .HALAL and .PERSIANGULF. And these recommendations are generally consistent with the findings and recommendations in the .AFRICA and .AMAZON IRP Final Declarations as well as the actions taken by ICANN in addressing those IRP Final Declarations.

The BAMC also made clear that its recommendation to reaffirm acceptance of the GAC Advice is not based on the GAC's reference to intergovernmental organization (IGO) acronyms at the top-level. While the BAMC respects the GAC's view, the BAMC did not want or intend to recommend that the Board set any type of precedent regarding the level or source of IGO name and acronym protections in gTLDs, which has been and continues to be the subject of community-driven policy work.

Board Decision

The Board agrees with the BAMC's recommendations and reaffirms the Board's acceptance of the GAC Advice and its decision to not proceed with the .GCC application based on the concern raised in the GAC's rationale for the GAC Advice regarding lack of support and involvement from the relevant community, based on the Board's evaluation of the GAC Advice and other inputs and materials relevant to the .GCC application, which are set forth in this Rationale and the Reference Materials, and based on the Board's determination that proceeding with the .GCC application is not in the public interest. The Board also agrees that it is important to do this analysis now, rather than waiting for the .GCC IRP to be completed, because taking these steps is appropriate in light of certain findings in prior IRP final declarations and in light of ICANN's actions in response to those prior IRP declarations, and will benefit the community, including GCCIX, the GCC and the people it represents. This analysis, Resolution, and Rationale provides the parties and the .GCC IRP Panel with a complete picture of the BAMC and Board evaluation of the GAC Advice and the .GCC application, and these steps are generally consistent with the Board's actions in response to the .AFRICA and .AMAZON IRP Final Declarations and address several of the claims raised in the current .GCC IRP. Moreover, taking this action now is consistent with the purposes of the IRP, as set forth in ICANN's Bylaws, in that this action may narrow and focus the claims in the .GCC IRP, should avoid having multiple IRPs regarding the same application, and should lead to the just resolution of the claims in the .GCC IRP in the most efficient manner possible. In furtherance of the aim of limiting the issues in dispute in the .GCC IRP, the Board acknowledges, as did the GAC, that there was no written rationale for the GAC Advice in the Beijing Communiqué in 2013 and that the NGPC did not provide a written rationale when it accepted the GAC Advice beyond reliance on Section 3.1 of the Applicant Guidebook. The GAC has now detailed its rationale for the 2013 GAC Advice in its January 2022 letter and, in this Resolution and Rationale, the Board has described the independent analysis that the BAMC and the Board have conducted regarding the GAC Advice and the .GCC application.

The Board, in exercising its independent judgment, thinks that not proceeding with GCCIX's .GCC application is the right thing to do and is in the public interest. This view is based upon the Board's review, analysis, and discussion of the BAMC's analysis and recommendations, and the Board's independent analysis of the GAC Advice, the .GCC application and other materials relevant to the .GCC application, and what is in the public interest, while taking into consideration the Mission and Core Values set forth in ICANN's Bylaws.

Based on the Board's review and analysis of GCCIX's .GCC application, public comments regarding the .GCC application, the GAC Early Warning regarding the .GCC application, the IO's comments on the .GCC application, the available LRO filings, the GAC Advice in the Beijing Communiqué, the GAC's 25 January 2022 letter to ICANN regarding the Beijing Communiqué, and various communications from GCCIX to ICANN (including GCCIX's 15 April 2013 letter to ICANN in response to the GAC Advice; GCCIX's further response to the Beijing Communiqué, submitted on or around 10 May 2013; GCCIX's Reconsideration Request 13-17; and GCCIX's 7 September 2022 letter to ICANN regarding the GAC's 25 January 2022 letter), GCCIX's .GCC application appears to be directly aimed at attracting and engaging with members of the community represented by the GCC and the GCC member states (as stated in GCCIX's .GCC application) without the support of that community, the GCC, or the GCC's member states. And it is noteworthy that it is not a mere lack of support; the GCC and its member states have repeatedly objected to GCCIX's .GCC application. While official "support" is not necessarily required by the Guidebook because "GCC" is not a geographic name as defined in the Guidebook, the lack of support from the relevant community, the GCC, and the GCC member states is relevant to the Board's analysis of whether or not ICANN should proceed with this .GCC application.

Based on consideration of these materials, it also appears that GCCIX's selection of the "GCC" string is intended to attract, and/or will have the effect of attracting, the relevant community as a result of the association that the Gulf Cooperation Council and its member states have with the "GCC" acronym and the region within which the GCC operates. Further, GCCIX's selection of .GCC also appears to capitalize on the reputation and goodwill that the GCC and its member states have developed through their representation of over 60 million people in the Gulf and Middle East region over the last 40 years, even though the application is not sponsored or endorsed by the GCC or its member states.

Based on its analysis of these materials, the Board believes that this dichotomy between appearances and actual support could lead to confusion and could create the false impression that the GCC and its member states have endorsed the operation of the .GCC gTLD and/or the content of domains using the .GCC gTLD, which the GCC and its member states have not done. In addition, this confusion could interfere with the legitimate interests, mission, and community outreach of the GCC and its member states since they do not endorse or support, and in fact have objected to, this .GCC application and will have no role in evaluating or moderating its operation or content, as mentioned in the IO's comments on the .GCC application.

The Board takes this action based not only on its due diligence and care in reviewing the relevant materials, but also on its adherence to ICANN's Mission, Commitments, and Core Values set forth in the Bylaws, including ensuring that this decision is in the public interest and that it respects the concerns raised by the community likely impacted by the proposed .GCC gTLD.  The Board is of the view that proceeding with GCCIX's .GCC application is not in the public interest.

This action is consistent with the approach ICANN has taken with regard to other gTLD applications that were lacking support in the communities specifically targeted by the applications, such as .ISLAM, .HALAL and .PERSIANGULF. Further, this action is generally consistent with certain findings and recommendations in the .AFRICA and .AMAZON IRP Final Declarations as well as the actions taken by ICANN in addressing those IRP Final Declarations. Moreover, this action addresses several of GCCIX's claims in the current .GCC IRP, including its claims that ICANN should have sought from the GAC a written rationale for the GAC Advice, should have done an independent evaluation of that rationale, should have provided GCCIX with treatment equal to that provided to similarly situated applicants (such as .AFRICA and .AMAZON), and should provide a rationale for any action it takes on account of the GAC Advice regarding the .GCC application.

To be clear, however, the Board is not basing its decision to reaffirm acceptance of the GAC Advice on the GAC's reference to IGO acronyms at the top-level. While the Board respects the GAC's view, the Board does not want or intend to set any type of precedent regarding the level or source of IGO name and acronym protections in gTLDs, which has been and continues to be the subject of community-driven policy work.

Taking the decision to continue to not proceed with GCCIX's .GCC application, after reviewing and considering the aims of the application, the materials relevant to the application, and the objections of those most likely to be impacted by a .GCC gTLD, is in the public interest and reflects the Board's adherence to ICANN's Mission, Commitments, and Core Values as set forth in the Bylaws.

More specifically with regard to ICANN's Core Values as set forth in the Bylaws, this decision takes into consideration the broad, informed participation of the Internet community and those members most affected, it respects ICANN's Accountability Mechanisms, and it recognizes the concerns expressed by the countries and entities representing the majority of the affected community (noted in the Bylaws applicable to the .GCC IRP, https://www.icann.org/resources/pages/bylaws-2012-02-25-en; and similarly reflected in the current Bylaws, https://www.icann.org/resources/pages/governance/bylaws-en):

  • Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making.
  • Acting with a speed that is responsive to the needs of the Internet while, as part of the decision-making process, obtaining informed input from those entities most affected.
  • Remaining accountable to the Internet community through mechanisms that enhance ICANN's effectiveness.
  • While remaining rooted in the private sector, recognizing that governments and public authorities are responsible for public policy and duly taking into account governments' or public authorities' recommendations.

While the Board strives to follow all the Core Values in making its decisions, it is also the Board's duty to exercise its independent judgment to determine if certain Core Values are particularly relevant to a given situation. And, in fact, the Bylaws anticipate and acknowledge that ICANN may not be able to comply with all the Core Values in every decision made and allows for the Board to exercise its judgment in the best interests of the Internet community: "…because [the Core Values] are statements of principle rather than practice, situations will inevitably arise in which perfect fidelity to all eleven core values simultaneously is not possible. Any ICANN body making a recommendation or decision shall exercise its judgment to determine which core values are most relevant and how they apply to the specific circumstances of the case at hand, and to determine, if necessary, an appropriate and defensible balance among competing values." (Bylaws, https://www.icann.org/resources/pages/bylaws-2012-02-25-en.)

Taking this decision is within ICANN's Mission as the ultimate result of ICANN's consideration of this matter is a key aspect of coordinating the allocation and assignment of names in the root zone of the domain name system (DNS). Further, the Board's decision is in the public interest, taking into consideration and balancing the goals of resolving outstanding new gTLD disputes, respecting ICANN's accountability mechanisms and advisory committees, recognizing the input received from the Internet community, and abiding by the policies and procedures set forth in the Guidebook, which were developed through a bottom-up consensus-based multistakeholder process over numerous years of community efforts and input, and is consistent with ICANN's Core Values.

Taking this decision is not expected to have any immediate direct financial impact on the ICANN organization and will not have any direct impact on the security, stability or resiliency of the domain name system.

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

e. Further Consideration of the Afilias Domains No. 3 Ltd. v. ICANN (.WEB) Independent Review Process Final Declaration

Whereas, on 16 January 2022, the Board considered the Final Declaration in the Afilias Domains No. 3 Ltd. (Altanovo)18 v. ICANN Independent Review Process regarding .WEB (.WEB IRP) and, in part, resolved that further consideration was needed regarding the IRP Panel's non-binding recommendation.

Whereas, pursuant to its 16 January 2022 resolution, the Board asked the Board Accountability Mechanisms Committee (BAMC) to review, consider, and evaluate the IRP Panel's Final Declaration and recommendation, and to provide the Board with its findings to consider and act upon before the organization takes any further action toward contracting for or delegation of .WEB.

Whereas, the BAMC complied with the Board's request and recommended next steps related to the .WEB applications.

Whereas, on 10 March 2022, the Board considered the BAMC's recommendation, as well as the relevant related materials, and resolved to: (a) ask the BAMC to review, consider and evaluate the claims relating to the Domain Acquisition Agreement (DAA) between Nu Dotco LLC (NDC) and Verisign, Inc. and the claims relating to Altanovo's conduct during the Auction Blackout Period; (b) ask the BAMC to provide the Board with its findings and recommendations as to whether the alleged actions of NDC and/or Altanovo warrant disqualification or other consequences, if any, related to any relevant .WEB application; and (c) direct ICANN organization to continue refraining from contracting for or delegation of .WEB until ICANN has made its determination regarding the .WEB application(s).

Whereas, in furtherance of that resolution, the BAMC requested that Altanovo, NDC and Verisign provide comprehensive written summaries of their claims and the materials supporting their claims, which they did in July and August 2022.

Whereas, after the BAMC reviewed and considered the parties' July/August 2022 submissions and supporting materials, as well as relevant related materials, and discussed the matter extensively, the BAMC recommended that the Board: (a) determine that NDC did not violate the Guidebook or the Auction Rules, either through entering into the DAA or through its participation in the .WEB auction; (b) direct the Interim President and CEO, or her designee(s), to continue processing NDC's .WEB application; and (c) in light of the above, conclude that is not necessary to make a final determination at this time as to whether Altanovo violated the "Blackout Period" of the .WEB auction.

Whereas, noting the questions raised regarding certain conduct by both both NDC and Altanovo, the BAMC further recommended that the Board direct the Interim President and CEO, or her designee(s), to carefully consider the issues raised by the parties and the Panel in the .WEB IRP with regard to agreements similar to the DAA and communications prior to an ICANN auction when developing the Guidebook and auction rules for the next round of the New gTLD Program in order to provide greater clarity to applicants regarding the transparency and notification requirements throughout the application and auction processes.

Resolved (2023.04.30.12), the Board hereby: (a) determines that NDC did not violate the Guidebook or the Auction Rules, either through entering into the DAA or through its participation in the .WEB auction; (b) directs the Interim President and CEO, or her designee(s), to continue processing NDC's .WEB application; and (c) in light of the above, concludes that is not necessary to make a final determination at this time as to whether Altanovo violated the "Blackout Period" of the .WEB auction.

Resolved (2023.04.30.13), the Board hereby notes the questions raised regarding certain conduct by both NDC and Altanovo and directs the Interim President and CEO, or her designee(s), to carefully consider the issues raised by the parties and the Panel in the .WEB IRP with regard to agreements similar to the DAA and communications prior to an ICANN auction when developing the Guidebook and auction rules for the next round of the New gTLD Program in order to provide greater clarity to applicants regarding the transparency and notification requirements throughout the application and auction processes.

Resolved (2023.04.30.14), specific items within this resolution shall remain confidential pursuant to Article 3, section 3.5(b) of the ICANN Bylaws unless and until the Interim President and CEO, or her designee(s), determines that the confidential information may be released.

Rationale for Resolutions 2023.04.30.12 – 2023.04.30.14

After careful review of the underlying facts, the submissions and supporting materials provided by Altanovo Domains Limited (Altanovo),19 Nu Dotco LLC (NDC) and Verisign, Inc. in July and August 2022, including, but not limited to, the Domain Acquisition Agreement (DAA) between NDC and Verisign and affiliated documents, NDC's .WEB application, relevant provisions of the Guidebook, Auction Rules and Bidder Agreement, and various other materials, as well as the Board Accountability Mechanisms Committee's (BAMC) analysis and recommendations, the Board has determined that NDC did not violate the Guidebook or the Auction Rules, either through entering into the DAA or through its participation in the .WEB auction. In addition, and in light of the above determination, the Board has also concluded that it is not necessary to make a final determination at this time as to whether Altanovo violated the "Blackout Period" of the .WEB auction.

The Board, however, does note the claims asserted regarding NDC's non-disclosure of its arrangement with Verisign and regarding Altanovo's communications prior to the ICANN auction and, thus, has directed ICANN organization to carefully consider such issues when developing the Guidebook and the auction rules for the next round of the New gTLD Program. It would be beneficial to both the applicants and the application process as a whole to provide greater clarity in the next iteration of the Guidebook and auction rules regarding the transparency and notification requirements throughout the application and auction processes, in particular with regard to proposed registry agreement assignments and/or arrangements similar to the DAA as well as communications during the Blackout Period.

Background Information

Additional background information regarding the .WEB applications and the .WEB auction, the Independent Review Process initiated by Altanovo (.WEB IRP), and the IRP Panel's Final Declaration can be found in the Resolution, Rationale and supporting Board materials for Board Resolutions 2022.01.16.12 - 2022.01.16.15 and 2022.03.10.06, and is incorporated herein by reference.

The .WEB Auction and the DAA:

Seven applicants submitted applications for the right to operate .WEB, including Altanovo and NDC. The members of the .WEB contention set did not privately resolve contention; accordingly, the applicants went to an ICANN auction of last resort. An auction was held on 27-28 July 2016, which concluded with NDC prevailing with a bid of US$135 million. Shortly thereafter, Verisign publicly disclosed (through both a press release and a filing with the Securities and Exchange Commission) that, pursuant to an agreement it had entered with NDC, Verisign provided the funds for NDC's auction bid in exchange for, among other things, NDC's future assignment of the .WEB registry agreement to Verisign, subject to ICANN's consent.

The commitment Verisign referenced arose out of an agreement between NDC and Verisign known as the Domain Acquisition Agreement (DAA). The DAA "[Redacted-Confidential Information]" subject to ICANN's consent to an assignment request regarding the Registry Agreement.

Under the terms of the DAA, NDC agreed that it "[Redacted-Confidential Information]," that it "[Redacted-Confidential Information]" and that it will not "[Redacted-Confidential Information]."

NDC and Verisign agreed that "[Redacted-Confidential Information]."

Upon learning of an agreement between Verisign and NDC, Altanovo sent ICANN a letter asking ICANN to disqualify NDC's .WEB application and its bid for .WEB, and award .WEB to Altanovo as the next highest bidder. ICANN undertook an initial investigation, which was followed by a competition investigation by the United States Department of Justice Antitrust Division (DOJ). The DOJ process took approximately a year and a half. In early 2018, the DOJ closed its investigation and took no action. Thereafter, ICANN proceeded to the contracting phase with NDC for .WEB.

IRP Panel Final Declaration:

Altanovo initiated the .WEB IRP in November 2018, alleging that NDC had violated the Guidebook and/or Auction Rules as a result of its arrangement with Verisign, and that ICANN had violated the Bylaws by failing to disqualify NDC. NDC and Verisign asked to participate as amici curiae in the IRP, which the Panel granted. The merits hearing took place on 3-11 August 2020, and the IRP Panel issued its Final Declaration on 20 May 2021, which the Panel later corrected for certain typographical errors, effective 15 July 2021. Altanovo then filed a further challenge to the Final Declaration, which the Panel denied in its entirety in December 2021, at which time the Final Declaration was deemed "final."

In its Final Declaration, the Panel accepted Altanovo's claim that ICANN violated provisions in its Articles of Incorporation (Articles) and Bylaws by proceeding toward entering a Registry Agreement with NDC without having reached a determination about whether the DAA or NDC's conduct warranted rejection of NDC's application for .WEB. The Panel also found that ICANN violated its Bylaws' obligation to operate in an open and transparent manner and consistent with procedures to ensure fairness by not advising Altanovo of the ICANN Board's choice in November 2016 to defer consideration of the .WEB matter while an Accountability Mechanism regarding .WEB was pending.

The Panel, however, denied Altanovo's requested relief that the Panel issue a binding declaration that ICANN must disqualify NDC's bid for .WEB, that the Panel specify a winning bid price, and that the Panel order ICANN to proceed with contracting for .WEB with Altanovo. The Panel found that the questions raised by Altanovo were "serious and deserving of [ICANN's] consideration," but the Panel expressed no view as to the proper resolution of those questions. Instead, the Panel found that the resolution of those questions is a matter within the discretion of ICANN. The Panel noted that: "it is for [ICANN], that has the requisite knowledge, expertise, and experience, to pronounce in the first instance on the propriety of the DAA under the New gTLD Program Rules, and on the question of whether NDC's application should be rejected and its bids at the auction disqualified by reason of its alleged violations of the Guidebook and Auction Rules."

The Panel also stated that it "accepts the submission that ICANN does not have the power, authority, or expertise to act as a competition regulator by challenging or policing anticompetitive transactions or conduct." The Panel further noted that "[c]ompelling evidence to that effect" was presented by several of the ICANN witnesses at the final hearing, and "it is consistent with a public statement once endorsed by [Altanovo], in which it was asserted [that] '[…] Neither ICANN nor the GNSO have the authority or expertise to act as anti-trust regulators.'"

Board Resolutions and BAMC Review:

Once the Final Declaration became "final," after resolution of Afilias' separate request for "interpretation and correction" (which the Panel determined was "frivolous") on 21 December 2021, the Board considered the Final Declaration at its 16 January 2022 meeting. The Board acknowledged the Panel's findings, directed payment to Altanovo of the amount set forth by the Panel, and determined that further consideration of the Panel's recommendation was needed. Accordingly, the Board asked the BAMC to "review, consider, and evaluate the IRP Panel's Final Declaration and recommendation, and to provide the Board with its findings to consider and act upon before the organization takes any further action toward contracting for or delegation of .WEB."

After conducting its initial review of the IRP Panel's Final Declaration and recommendation, and related materials, the BAMC recommended that the Board: (a) ask the BAMC to review, consider and evaluate the claims relating to the DAA, and the claims relating to Altanovo's conduct during the Auction Blackout Period; (b) ask the BAMC to provide the Board with its findings and recommendations as to whether the alleged actions of NDC and/or Altanovo warrant disqualification or other consequences, if any, related to any relevant .WEB application; and (c) direct ICANN organization to continue refraining from contracting for or delegation of .WEB until the Board has made its determination regarding the .WEB application(s).

As set forth in Board Resolution 2022.03.10.06, the Board agreed with the BAMC's recommendation and noted that, "in light of certain of the Panel's determinations, it is appropriate and prudent for ICANN to undertake an analysis of the allegations regarding the DAA as well as the allegations regarding the Auction Blackout Period in order to determine if any consequences are warranted with respect to any of the .WEB applications" before proceeding further.

In furtherance of the Board's Resolution, the BAMC requested that the interested parties (Altanovo, NDC and Verisign) "provide a comprehensive written summary of their claims and the materials supporting their claims." On 29 July 2022, Altanovo and NDC/Verisign provided their initial submissions. Altanovo also submitted two supporting declarations with its submission. On 29 August 2022, Altanovo submitted its reply submission, and NDC/Verisign submitted their reply submission along with two supporting declarations.

The BAMC reviewed and considered the submissions and supporting materials including, but not limited to, the DAA and affiliated documents, NDC's .WEB application, relevant provisions of the Guidebook, Auction Rules and Bidder Agreement, and various other materials. The BAMC carefully considered the parties' positions and supporting materials, and the BAMC extensively discussed the matter and options regarding next steps relating to the .WEB gTLD during at least four separate meetings.

Summary of the Parties' Positions

The following is a summary of the parties' positions but does not capture the entirety of their positions, which are set forth in their submissions to the BAMC and are available on ICANN's .WEB IRP webpage.

Altanovo's Position Regarding the .WEB Auction and the DAA:

Altanovo contends that the gTLD application process is designed to promote fairness, transparency and non-discrimination and that it requires key parts of each application to be posted for a public comment period, which guarantees that other applicants and the Internet community at large know what entity is applying for a gTLD and the purpose for which it is sought and have an opportunity to comment on the application. Altanovo claims that transparency is required so that all applicants know who they are competing against. Altanovo argues that the DAA "decimate[s] [the] fundamental principles underlying the New gTLD Program" and that, according to Altanovo, "the DAA was specifically designed to evade and subvert the most basic purposes that the Program was meant to serve." Further, Altanovo argues that, by submitting an application to ICANN through the New gTLD Program, the applicant enters into a contract with ICANN; and that ICANN enters into these contracts and promulgates the rules in the Guidebook to carry out its Mission on behalf of the Internet community as a whole.

Altanovo argues that the Guidebook prohibits the sale, assignment, or transfer of "any of applicant's rights or obligations in connection with the application," referencing Paragraph 10 of Module 6 of the Applicant Guidebook, which states:

Applicant understands and agrees that it will acquire rights in connection with a gTLD only in the event that it enters into a registry agreement with ICANN, and that applicant's rights in connection with such gTLD will be limited to those expressly stated in the registry agreement. In the event ICANN agrees to recommend the approval of the application for applicant's proposed gTLD, applicant agrees to enter into the registry agreement with ICANN in the form published in connection with the application materials. (Note: ICANN reserves the right to make reasonable updates and changes to this proposed draft agreement during the course of the application process, including as the possible result of new policies that might be adopted during the course of the application process). Applicant may not resell, assign, or transfer any of applicant's rights or obligations in connection with the application.

Altanovo argues that this provision is not merely limited to the total sale or transfer of an application but, rather, prohibits the transfer of individual rights or obligations in an application. And, according to Altanovo, the DAA constituted a resale, assignment and/or transfer of several of NDC's individual rights and/or obligations relating to its .WEB application.

Specifically, Altanovo asserts that NDC transferred to Verisign the right and obligation to negotiate and enter into a Registry Agreement with ICANN and to operate .WEB because the terms of the DAA require that NDC "[Redacted-Confidential Information]" and to "[Redacted-Confidential Information]" before executing the Registry Agreement with ICANN. According to Altanovo, the "most basic right under a gTLD application is . . . the applicant's opportunity to operate the applied-for registry," but the DAA operates as [Redacted-Confidential Information], citing to the portion of the DAA that indicates that, [Redacted-Confidential Information].

Altanovo argues that NDC also transferred to Verisign its right to participate in the .WEB auction on its own behalf by agreeing that it would do so only upon "[Redacted-Confidential Information]." Altanovo also argues that NDC transferred this right by agreeing to participate in the auction "[Redacted-Confidential Information]" and "[Redacted-Confidential Information]." According to Altanovo, each and every bid at the .WEB auction was made "[Redacted-Confidential Information]" and from Verisign's headquarters.

Altanovo disagrees with NDC/Verisign's contention that the DAA comprises a "future" assignment of rights because Verisign exercised its then-existing rights to "[Redacted-Confidential Information]," and to "[Redacted-Confidential Information]." Verisign, according to Altanovo, also controlled NDC's bids at the ICANN Auction.

Altanovo also contends that "virtually all" of the information in NDC's application became untrue, inaccurate, and incomplete when NDC entered into the DAA and "deprived" the Internet community of the ability to submit public comments on Verisign's involvement in .WEB. For instance, in Section 18 (Mission/Purpose) of the application, NDC stated that "[p]rospective users benefit from the long-term commitment of a proven executive team that has a track-record of building and successfully marketing affinity TLD's," and that NDC plans to implement "a very similar strategy for .WEB to the one that it used for .CO." But, according to Altanovo, that was no longer accurate once the DAA was signed because, under the DAA, there was no circumstance where NDC could operate .WEB. Thus, the mission and purpose, including the "long-term commitment of a proven executive team," became an "outright lie," according to Altanovo. Altanovo asserts that this information was published for the members of the Internet community so that they can understand who is applying for a given gTLD, regardless of whether Section 18 is part of ICANN's evaluation. Altanovo contends that this is the reason that Paragraph 1 of the Applicant Guidebook requires applicants to notify ICANN of "any change in circumstances that would render any information in the application false or misleading."

Position of NDC and Verisign Regarding the .WEB Auction and the DAA:

NDC and Verisign claim that Altanovo has lodged a series of attacks designed to disqualify NDC from the .WEB contention set since even before the .WEB auction, and the IRP was yet another such attack. NDC and Verisign also note that Altanovo sought to exclude NDC and Verisign from participating in the IRP while simultaneously asking the IRP Panel to disqualify NDC and its .WEB application. NDC and Verisign contend that Altanovo's proposed relief and proposed reading of the Guidebook are "draconian" and "would create uncertain and destabilizing precedent far beyond this matter." For instance, they assert that ICANN is bound by the Bylaws to act in a non-discriminatory manner, and that awarding Altanovo the relief it seeks would amount to singling out NDC and Verisign because ICANN has approved hundreds of assignments of Registry Agreements, some similar to the assignment envisioned by the DAA, including assignments that change the mission and purpose of the original application. They further claim that numerous applicants have entered into agreements with third parties and that ICANN has never disqualified an applicant on that basis.

NDC and Verisign argue that Paragraph 10 of Guidebook Module 6 does not apply to the DAA because the paragraph only prohibits the sale of a total application itself; it does not address agreements, such as the DAA, "to support an application, finance a resolution of a contention set, or assign a registry agreement post-delegation (upon consent of ICANN)." NDC and Verisign argue that the DAA did not transfer NDC's rights or obligations under the application to Verisign. The DAA contemplates only "a possible, contingent, future assignment of the registry agreement following (i) resolution of the contention set, (ii) execution of a registry agreement, and (iii) ICANN's consent to the assignment." Moreover, the DAA confirmed that NDC did not need Verisign's consent to "[Redacted-Confidential Information]."

According to NDC and Verisign, the DAA fails to meet the legal elements for an assignment, which requires "(1) a specific intention to make (2) a present transfer of ownership of the application, and (3) the transferor have no remaining interest in the application." Instead, the Confirmation of Understanding (a subsequent agreement dated 26 July 2016 between NDC and Verisign relating to the DAA) states that the parties "[Redacted-Confidential Information]"; and that NDC does not need Verisign's consent to "[Redacted-Confidential Information]." NDC and Verisign argue that the only transfer contemplated by the DAA was a future, conditional assignment of a Registry Agreement.

NDC and Verisign also rely upon the Auction Rules, which they contend implicitly authorize agreements such as the DAA. The Auction Rules state that pre-auction agreements regarding post-auction ownership transfer arrangements cannot be discussed during the Blackout Period, impliedly permitting such arrangements to be discussed at other times. Finally, NDC and Verisign argue that when drafting the Applicant Guidebook, ICANN "rejected" a proposal to limit agreements for post-delegation assignments of Registry Agreements, which further confirms that the Guidebook was not intended to limit these assignments.

NDC and Verisign argue that NDC made the bids for itself as the applicant, and that the DAA provisions to which Altanovo cites [Redacted-Confidential Information]. For instance, [Redacted-Confidential Information]. Further, NDC and Verisign claim that not only do the Auction Rules not govern the extent to which an applicant may obtain third-party financing for an auction, but Altanovo even admitted that it received a loan for its participation in the .WEB auction, much like other participants in both private auctions and other ICANN auctions.

NDC and Verisign further contend that NDC is still the applicant for .WEB, and that NDC may become the registry operator because Verisign's rights under the DAA are subject to numerous contingencies. For instance, Verisign could terminate the DAA "[Redacted-Confidential Information]," which would allow NDC to operate .WEB. NDC also could breach the DAA and keep the .WEB registry for itself (even if that action would carry its own consequences). Additionally, if ICANN did not consent to the assignment, NDC and Verisign could modify the DAA such that NDC would remain the registry operator.

NDC and Verisign further contend that new gTLDs have been transferred "hundreds of times post-delegation," and that "ICANN has never objected or refused to consent to an assignment on the grounds that: (i) the pre-delegation agreement provided for a post-delegation assignment of the registry agreement, and/or (ii) there was a lack of pre-delegation public scrutiny of the registry operator because the assignment was effected after the application evaluation period had closed."

NDC and Verisign argue that ICANN has never applied the Guidebook in the manner proposed by Altanovo, and that new gTLDs have been transferred numerous times after execution of a Registry Agreement. NDC and Verisign refer to Christine Willett's testimony at the IRP hearing that "'applicants all the time were assigning rights and designating third parties to operate on their behalf,' with respect to 'all sorts of aspects of their application and future gTLD operations,' including assigning new gTLDs immediately upon execution of the registry agreement."

NDC and Verisign argue that the DAA did not render any statements in the application false or misleading. NDC and Verisign contend that ICANN is generally unconcerned with third-party agreements like the DAA and only is concerned with the ownership, management, and contact personnel for the applicant. The representations regarding NDC's ownership, management, and contact personnel remain accurate.

Additionally, NDC and Verisign argue that there were no changes to Section 18 (Mission/Purpose) of the application about which NDC was required to notify ICANN. The DAA did not alter the mission or purpose as stated in NDC's application, where NDC described "its general strategy at the time [in 2012] as to how .WEB might be successfully and productively introduced and used to benefit consumers." That general strategy was not "intended to be a definitive statement of NDC's plans for .WEB," and, according to NDC and Verisign, they were not "required to be" definitive statements under the Guidebook. NDC and Verisign further contend that any purported inaccuracy in Section 18 is immaterial because Module 2 of the Guidebook states that the information provided in response to Question 18 "is not used as part of the evaluation or scoring of the application."

Allegations regarding the .WEB Auction Blackout Period:

Clause 68 of the Auction Rules and Sections 2.6 and 2.10 of the Bidder Agreement prohibit members of a contention set from, among other things, "cooperating or collaborating with respect to, discussing with each other, or disclosing to each other in any manner the substance of their own, or each other's, or any other competing applicants' bids or bidding strategies, or discussing or negotiating settlement agreements" during the period from the deposit deadline for the auction until full payment has been received from the auction winner. This is referred to as the "Blackout Period." According to NDC and Verisign, an agreement had been reached to resolve .WEB through a "private auction" by all members of the contention set except NDC, which refused to participate in a private auction. The proposed private auction would have been structured so that the proceeds of the winning bid would be distributed to the losing bidders. On 7 June 2016, a representative of Altanovo asked NDC to reconsider entering into a private auction and offered to guarantee that NDC would receive at least $16 million if NDC participated in a private auction and lost. NDC declined. Altanovo offered to increase the guaranteed payment to $17.02 million. NDC declined again.

On 20 July 2016, the deposit deadline for the .WEB action passed, and the Blackout Period began. On 22 July 2016, Altanovo sent a text message to NDC stating:

If ICANN delays the auction next week would you again consider a private auction? Y-N

NDC did not respond to the text message. NDC and Verisign contend that Altanovo's communication violated the Blackout Period.

NDC and Verisign argue that Altanovo's 22 July 2016 message asking if NDC would consider a private auction in the event that the .WEB auction were to be postponed amounted to seeking a "settlement of" the .WEB contention set in breach of paragraph 68 of the Auction Rules and Section 2.6 of the Bidder Agreement. They argue that the text message "unambiguously referred back to Altanovo's prior attempts days earlier to induce NDC to agree to a private auction for .WEB by guaranteeing NDC over $17 million to go to such an auction and lose." NDC and Verisign further argue that Altanovo's text message also intended to probe NDC's strategies for the upcoming auction, which NDC and Verisign contend the Bidder Agreement prohibits.

Altanovo argues that the first two texts NDC and Verisign identified occurred six weeks prior to the Blackout Period, and that while the 22 July 2016 text occurred during the Blackout Period, it did not violate any rules. According to Altanovo, the Blackout Period is "designed to prevent bid rigging by prohibiting bidders from coordinating in advance of the auction." According to Altanovo, its text message did not seek to coordinate or otherwise rig auction bids and did not violate the terms or spirit of the Blackout Period; and the text did not relate to bids, bidding strategies, settlement agreements or post-Auction ownership transfer agreements.

Parties' Request for Remedies:

The parties' submissions propose radically different remedies in the event the Board were to find a violation of the Guidebook or Auction Rules, notwithstanding the fact that the IRP Panel found that the Guidebook and Auction Rules provide ICANN with considerable discretion to address and to remedy breaches of their terms.

Altanovo contends that, if a violation is found, the Articles and Bylaws require the Board to exercise its discretion to disqualify NDC's application/bids and deem NDC ineligible to enter into a Registry Agreement for .WEB, based on Guidebook Module 6 (which provides that ICANN may reject an application if an applicant makes a "material misstatement or misrepresentation" in the application or omits any "material information" from the application). Altanovo further argues that its bid (which was the second highest bid) should be declared the winning bid because certain provisions of the Auction Rules indicate that a bidder may be subject to various penalties, including forfeiture of its application, and that ICANN may make a determination that a winning applicant is "ineligible" to enter into a Registry Agreement.

NDC's and Verisign's overarching theme is that granting Altanovo the relief it seeks would amount to treating NDC and Verisign differently from all other similarly situated new gTLD applicants that have assigned their Registry Agreements to third parties, or otherwise entered into financing agreements related to their applications. NDC and Verisign further argue that Altanovo's argument implies that the Board has no discretion but to award Altanovo its "draconian" relief, thereby resulting in Altanovo obtaining the right to operate .WEB for "far less than its market value." NDC and Verisign, however, assert that Altanovo's argument is contrary to the Guidebook and the IRP Panel's Final Declaration, which held that ICANN has "the requisite knowledge, expertise, and experience to pronounce . . . on the question of whether NDC's application should be rejected and its bid at the auction disqualified."

NDC and Verisign also argue that, even if the DAA violated Paragraph 10 of the Guidebook, forfeiture is not the appropriate remedy and is inconsistent with how ICANN has interpreted Paragraph 10 in the past. Moreover, the fundamental purpose of Paragraph 10 is to ensure that the applicant continues to have responsibility for the application, and the DAA did not interfere with that fundamental purpose, according to NDC and Verisign. As to the alleged violation of NDC's disclosure obligations, again NDC and Verisign argue that the remedy cannot be forfeiture, in part because there is no evidence that the result of the .WEB auction would have been different had the arrangement been disclosed. And conceding to Altanovo's demand "would be singling out NDC for disqualification based on the same conduct by other applicants for which ICANN took no action." Finally, NDC and Verisign argue that the alleged violations of the Auction Rules or the Bidder Agreement cannot support forfeiture because they relate only to the mechanics of the ICANN Auction, and the DAA did not interfere with those mechanics.

Discussion of the BAMC's Consideration and Recommendation

Pursuant to the Board's directive in Resolution 2022.03.10.06, the BAMC, and then the Board, considered various materials relevant to this matter including, but not limited to, the IRP Panel's Final Declaration and the submissions and supporting materials submitted to the BAMC in July and August 2022 by Altanovo, NDC and Verisign.

After careful review of and discussion regarding the Guidebook and Auction Rules, the BAMC, and the Board, found that there is no Guidebook or Auction Rules provision that directly addresses arrangements such as the DAA, despite the parties' respective contentions. The BAMC believes, and the Board agrees, that the DAA falls into a gray area that the Guidebook and Auction Rules do not specifically address. Thus, while both sides make plausible arguments, none of those arguments exactly fits the DAA and the parties' conduct under the current Guidebook and Auction Rules.

More specifically, the BAMC and the Board found that the DAA does not violate Paragraph 10 of the Guidebook, including the last sentence, which states that "Applicant may not resell, assign, or transfer any of applicant's rights or obligations in connection with the Application." NDC remains the applicant of its .WEB application because NDC did not sell or transfer the application. While NDC has agreed that the DAA grants Verisign various rights with respect to how NDC proceeds, including with respect to [Redacted-Confidential Information], NDC did not resell, assign, or transfer its rights or obligations with regard to the .WEB application itself, and retained the right to communicate with ICANN and to provide information "[Redacted-Confidential Information]." In the event NDC negotiates with and enters into a Registry Agreement with ICANN for .WEB, NDC would become the Registry Operator for .WEB. Only after NDC secures a Registry Agreement (if it does) can NDC then submit a request to ICANN to have the agreement assigned to Verisign.

Accordingly, the BAMC and the Board agree with NDC and Verisign that no assignment of NDC's application has occurred and the information provided in NDC's application has not been rendered false. Instead, the DAA contemplates a possible future assignment of the Registry Agreement that NDC might enter into with ICANN, not an assignment of NDC's .WEB application. NDC remains the applicant and, if NDC enters into a Registry Agreement with ICANN, NDC will become the Registry Operator for .WEB. Whether or not NDC then attempts to assign the Registry Agreement to Verisign is, at this point, an event that has not occurred and conceivably may not occur depending on the circumstances at the time. And if NDC subsequently decides to request such an assignment, there are processes in place to review such a request, including the need for ICANN's approval of that request. Such an assignment does not equate to a "circumvention" of the application process but, rather, is a necessary component for servicing Registry Operators and allowing the continued operation of gTLDs.

The BAMC also noted, as does the Board, that Registry Agreements for new gTLDs have been assigned dozens of times, if not more, following contracting and/or delegation of the gTLD and that, generally, there have been no formal objections regarding possible pre-contracting agreements that provided for a post-delegation transfer subject to ICANN approval.20 Although ICANN does not know the circumstances or details of other potential pre-contracting agreements that may have been in place, the BAMC and the Board note that there are examples where assignment requests were submitted shortly after (even as short as one week after) contracting, including for gTLDs that had been the subject of auctions.

Furthermore, if such pre-contracting agreements occurred between private companies, ICANN might not have any direct knowledge of the extent of those agreements because private companies do not have a public disclosure requirement and the Guidebook does not contain a disclosure requirement for such agreements. The primary reason that ICANN and Altanovo became aware of the DAA was due to the fact that Verisign is a public company that was required to make a public disclosure. Verisign should not be treated differently because it is a public company that has a disclosure requirement as compared to private companies that do not have a public disclosure requirement. That being said, the BAMC thinks it is important for applicants and the application process as a whole that ICANN provide greater clarity to applicants regarding the transparency requirements and the notification requirements applicable throughout the various stages of the application process and the ICANN auction process. The Board agrees and has directed ICANN org to consider these issues when developing the Guidebook and auction rules for the next round of the New gTLD Program.

In terms of any Guidebook requirement to update an application for a gTLD, the BAMC and the Board found that NDC did not violate that requirement by entering into the DAA. First and foremost, NDC is still the applicant; that has not changed. And, if NDC enters into a Registry Agreement with ICANN, NDC will become the Registry Operator for .WEB. Second, NDC and Verisign are correct that ICANN does not use the mission and purpose information (set forth in Section 18 of the application) as part of the evaluation or scoring of an application. In this regard, NDC and Verisign also noted that numerous other applicants have changed the mission and purpose for their gTLDs over the course of time without revising those applications and without ICANN taking any punitive action in such circumstances. Moreover, as noted above, it is not uncommon for a Registry Agreement to be assigned to a different Registry Operator, which may have a different mission or purpose for the gTLD. Such an assignment does not equate to a "circumvention" of the application process but, rather, is a necessary component for servicing Registry Operators and allowing the continued operation of gTLDs.

In terms of the Auction Rules and the Bidder Agreement, the BAMC and the Board found that NDC did not violate those provisions because NDC always remained the bidder, the bids that it submitted were legitimate, and NDC was in fact able to fulfill its bid when it became the prevailing party at the auction. The Auction Rules and Bidder Agreement primarily relate to the mechanics of the auction, not the qualifications of an applicant, and the BAMC found that the language in these documents to which Altanovo points was not intended to disqualify an otherwise qualified applicant in these circumstances, a conclusion with which the Board agrees.

With regard to Altanovo's claims regarding ICANN's Core Value relating to competition, the BAMC and the Board note that the Panel understood and explicitly accepted that ICANN "does not have the power, authority, or expertise to act as a competition regulator by challenging or policing anticompetitive transactions or conduct." The Panel further noted that this "is consistent with a public statement once endorsed by [Altanovo], in which it was asserted [that] '[…] Neither ICANN nor the GNSO have the authority or expertise to act as anti-trust regulators.'" The BAMC and the Board note that ICANN's Commitment and Core Value are directed at "enabl[ing[ competition and open entry in Internet-related markets" and "[i]ntroducing and promoting competition in the registration of domain names where practicable and beneficial to the public interest as identified through the bottom-up, multistakeholder policy development process." This sets the table for innovation and ensuring a stable, secure and interoperable Internet. This does not equate to being a competition "regulator," as explicitly stated in the Bylaws ("For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority.").

Based on the BAMC's extensive review and discussion of the allegations relating to the DAA, the BAMC has recommended that the Board determine that NDC did not violate the Guidebook or the Auction Rules, either through entering into the DAA or through its participation in the .WEB auction, and that the Board direct the Interim President and CEO, or her designee(s), to continue processing NDC's .WEB application.

The BAMC then discussed the allegations regarding Altanovo's conduct during the "Blackout Period" of the .WEB auction but, ultimately, concluded and recommended that the Board need not make a final determination at this time as to whether Altanovo violated the Auction Rules. The Board agrees, but notes that auction participants have sufficient time in advance of an ICANN auction to discuss potential private resolution and, thus, should respect the no-communication rule during the designated Blackout Period.

Finally, there was considerable discussion within the BAMC regarding the fact that, in the next round of the New gTLD Program, ICANN org should consider whether to provide more guidance, in the Applicant Guidebook or otherwise, regarding agreements similar to the DAA, including whether those agreements should be disclosed and, if so, when, as well as what communications are and are not permissible leading up to an ICANN auction. The BAMC believes, and the Board agrees, that it is important for both the applicants and the application process as a whole that ICANN provide greater clarity in the next iteration of the Guidebook and auction rules regarding the transparency and notification requirements applicable throughout the various stages of the application and auction processes. Accordingly, the BAMC has recommended that the Board direct ICANN org to carefully consider such issues when developing the Guidebook and auction rules for the next round of the New gTLD Program.

Board Decision:

The BAMC requested, received, and considered the parties' submissions, and it devoted considerable portions of four separate meetings to this matter before issuing its recommendation. The auction for .WEB generated more money than any other ICANN auction but, regrettably, the ensuing disputes have also generated millions of dollars in legal fees by each of the relevant parties and delayed the delegation of .WEB for more than six years. The BAMC's work and recommendations on this matter were critical to the Board's evaluation of this matter.

The Board thanks Altanovo, NDC and Verisign for their participation in this process. It has been somewhat unique in ICANN's history for ICANN to request submissions from the interested parties, and Altanovo, NDC and Verisign participated fully and in good faith. The Board respects the differences of opinion and has worked diligently to address the issues that the Panel recommended the Board address.

In consideration of the underlying facts, the submissions and supporting materials provided by the parties in July and August 2022 including, but not limited to, the DAA and affiliated documents, NDC's .WEB application, relevant provisions of the Guidebook, Auction Rules and Bidder Agreement, and various other materials, as well as the BAMC's analysis and recommendations, the Board has determined that NDC did not violate the Guidebook or the Auction Rules, either through entering into the DAA or through its participation in the .WEB auction.

No assignment of NDC's application has occurred and the information provided in NDC's application has not been rendered false. Rather, the DAA contemplates a possible future assignment of the Registry Agreement that NDC might enter into with ICANN, not an assignment of NDC's .WEB application. NDC remains the applicant and, in the event NDC enters into a Registry Agreement with ICANN, NDC will become the Registry Operator of .WEB. Whether or not NDC requests and is able to assign that agreement to Verisign is, at this point, an event that has not yet occurred. If NDC subsequently decides to request such an assignment, there are processes in place to review such a request, including the need for ICANN's approval of that request. Assignment of a Registry Agreement is not uncommon and it does not equate to a "circumvention" of the application process but, rather, is a necessary component for servicing Registry Operators and allowing the continued operation of gTLDs.

The Board further finds that NDC did not violate any Guidebook provision by not updating its application as a result of entering into the DAA. The Board notes that numerous other applicants have changed the mission and purpose for their requested gTLDs over the course of time without revising those applications; in addition to the numerous occasions in which the mission and purpose for a gTLD has changed as a result of assignment of the Registry Agreement to a new Registry Operator. The Board further finds that NDC did not violate the Auction Rules or Bidder Agreement in that NDC always remained the bidder, the bids that it submitted were legitimate, and NDC was in fact able to fulfill its bid when it became the prevailing party at the auction, and as set forth above.

With regard to the Blackout Period claims, while the Board notes the issue raised regarding Altanovo's conduct during the Blackout Period, the Board has concluded that, in light of the Board's decision to continue processing NDC's .WEB application, it is not necessary to make a final determination at this time as to whether Altanovo violated the Blackout Period of the .WEB auction.

Finally, the Board acknowledges and agrees with the BAMC's recommendation regarding the importance of greater clarity regarding the transparency and notification requirements in the application and auction processes. The Board recognizes that numerous new gTLD Registry Agreements have been assigned and the Applicant Guidebook applicable to the 2012 round of the New gTLD Program does not address the myriad of circumstances under which such assignments might occur, and when such agreements may be entered into. In this respect, the Board has determined that it is prudent to take that into consideration when developing the guidelines, rules and procedures for the next round of the New gTLD Program. Thus, the Board is directing ICANN org to carefully consider the issues raised by the parties and the Panel in the .WEB IRP with regard to agreements similar to the DAA and communications prior to an ICANN auction when developing the Guidebook and auction rules for the next round of the New gTLD Program in order to provide greater clarity to applicants regarding the transparency and notification requirements throughout the application and auction processes.

This action is within ICANN's Mission and is in the public interest as it is important to ensure that, in carrying out its Mission, ICANN is accountable to the community for operating within the Articles, Bylaws, and other established procedures. This accountability includes having a process in place by which a person or entity materially and adversely affected by a Board or organization action or inaction may challenge that action or inaction.

Taking this decision is not expected to have any immediate direct financial impact on ICANN. Further, this action should not have any direct 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. Executive Session

a. Confidential Matter

The Board entered into a confidential discussion and took action that shall remain confidential pursuant to Article 3, section 3.5.b of the ICANN Bylaws unless and until it is decided that the information be publicly released.

Published on 2 May 2023

Footnotes

[1] https://gnso.icann.org/en/council/resolutions#20140605-2.

[2] https://gnso.icann.org/en/issues/igo-ingo-crp-access-final-17jul18-en.pdf.

[3] https://gnso.icann.org/en/council/resolutions#201905.

[4] https://gnso.icann.org/en/council/resolutions/2020-current#20210819-2.

[5] https://gnso.icann.org/en/issues/specific-crp-igo-epdp-charter-16aug21-en.pdf.

[6] https://gnso.icann.org/en/issues/epdp-specific-crp-igo-final-report-02apr22-en.pdf.

[7] https://gnso.icann.org/en/council/resolutions/2020-current#202206.

[8] https://gnso.icann.org/sites/default/files/policy/2022/draft/draft-epdp-specific-curative-rights-protections-for-igos-report-11jul22-en.pdf.

[9] https://gnso.icann.org/en/issues/igo-ingo-crp-access-initial-19jan17-en.pdf and https://gnso.icann.org/en/issues/specific-crp-igo-epdp-initial-report-preliminary-recommendations-14sep21-en.pdf.

[10] https://www.icann.org/public-comments/igo-ingo-crp-recommendations-2019-07-11-en and https://www.icann.org/en/public-comment/proceeding/final-report-from-the-epdp-on-specific-curative-rights-protections-for-igos-28-11-2022.

[11] https://www.icann.org/en/system/files/correspondence/chalaby-to-ismail-11jul19-en.pdf.

[12] See https://www.icann.org/en/system/files/correspondence/ismail-to-chalaby-20aug19-en.pdf.

[13] See https://www.icann.org/en/system/files/correspondence/chalaby-to-ismail-14oct19-en.pdf.

[14] See https://www.icann.org/en/system/files/correspondence/sinha-to-ismail-01dec22-en.pdf.

[15] See https://gac.icann.org/advice/communiques/ICANN76%20Cancun%20Communique.pdf.

[16] The full text of the Policy can be found at https://www.icann.org/resources/pages/igo-ingo-protection-policy-2020-02-18-en.

[17] The LRO filings the BAMC had access to are those attached to GCCIX's Amended IRP Request of 19 May 2022.

[18] Afilias Domains No. 3 Ltd. is now known as Altanovo Domains Limited and will be referred to herein as "Altanovo."

[19] Afilias Domains No. 3 Ltd. is now known as Altanovo Domains Limited and will be referred to herein as "Altanovo."

[20] For instance, in 2012, Demand Media publicly announced an agreement regarding 107 of Donuts' gTLD applications before any Registry Agreements were executed, stating that "it ha[d] entered into a strategic arrangement with Donuts Inc. […], through which it may acquire rights in certain gTLDs after they have been awarded to Donuts by ICANN. These rights are shared equally with Donuts and are associated with 107 gTLDs for which Donuts is the applicant." Ultimately, approximately 24 new gTLDs that Donuts applied for were subsequently transferred via Registry Agreement assignment to Demand Media.