Approved Resolutions | Special Meeting of the ICANN Board | 29 July 2024

Rationale for Resolution 2024.07.29.01

Why is the Board addressing the issue?

The Competition, Consumer Trust and Consumer Choice (CCT) Review is one of the four Specific Reviews anchored in Article 4, Section 4.6 of the ICANN Bylaws. Specific Reviews are conducted by community-led review teams, which assess ICANN's performance in fulfilling its commitments. Reviews contribute to ensuring that ICANN serves the public interest, are critical to maintaining an effective multistakeholder model, and help ICANN achieve its mission, as detailed in Article 1 of the Bylaws.

The CCT Review is the first iteration of this effort. It was initiated under the Affirmation of Commitments (AoC), and calls for an assessment of the extent to which the expansion of generic top-level domains (gTLDs) has promoted competition, consumer trust and consumer choice. It also serves to assess the effectiveness of the application and evaluation process during the 2012 round of the New gTLD Program.

What is the proposal being considered?

This proposed action is in furtherance of resolution 2019.03.01.04 to place 17 CCT recommendations in "pending" status.

CCT Recommendations 2, 3, 4, and 5 respectively call for ICANN org to collect data on wholesale pricing for legacy gTLDs, transactional pricing for the gTLD marketplace, retail pricing for the domain marketplace, and secondary market data.

The Board recalls the Registries Stakeholder Group (RySG)'s comment on the CCT Final Report that expressed some concerns, notably that "price information is generally business sensitive", and there is a lack of clarity on who will have access to such data once collected, who will "arbitrate access to the data, and to what extent" ICANN commissioned a report to identify what types of information are probative to assess the competition within the DNS market. The report demonstrates that domain name price, including the different types of pricing data as requested by the CCT, is just one of the elements that may signal competition in the domain name market. While lower prices could be one measure of benefit, offering innovation or a better product (not necessarily at a lower price) is another key element of measuring possible consumer benefit and competitive impact. The report discusses that some innovations within new gTLDs introduced after the 2012 New gTLD round, provide enhanced safeguards to consumers, such as those associated with special use TLDs such as .bank, providing heightened registration requirements within those TLDs. The Board notes that contracts with gTLD Registry Operators and accredited Registrars do not provide ICANN with the ability to collect the requested pricing data. Further, ICANN does not have access to pricing data related to country code top-level domains (ccTLDs), either through ccTLD managers or the registrars through which most of them are offering registrations. ICANN also does not have access to secondary market data on sales of domain names, which are not governed by ICANN agreements, either. Moreover, the Board notes that the Registries Stakeholder Group, RySG, stated that "not only should ICANN not involve itself with pricing studies, using parties' contracts with ICANN as a mechanism to force its production is terribly inappropriate". The Board is mindful that even if ICANN were to have access to such pricing data, the risks of collection and maintenance of such data within ICANN raise questions about the propriety of ICANN becoming a clearinghouse for pricing-related data, and the potential for ICANN to be used as a source for competitors to access sensitive pricing data on their competitors. The Board acknowledges that the CCT Review Team suggests that ICANN could outsource the compilation and storage of pricing related data to a third party, however that still creates a clearinghouse of pricing data under ICANN's control and does not mitigate the Board's concerns.

As a result, the Board rejects CCT Recommendations 2, 3, 4, and 5.

The Board acknowledges that the report provides substantial information on the types of non-pricing data elements that might support an evaluation of competition in the DNS market. The report states that, in forming the list of non-pricing data elements, the author "[has] not determined whether ICANN is able to access the items on the list. To the extent that a given item is not available to ICANN, obviously no analysis based on that item could be conducted." The Board notes that the ICANN org has already started an evaluation of the data points identified to assess if the data is available to ICANN, could be made available through contracts, or might be available through third-party data sources. Through this, ICANN has the opportunity to collect and maintain data that could meet the CCT Review Team's goal "to have access to data for use in evaluating competition within future reviews," beyond pricing.

Which stakeholders or others were consulted?

The Board received community feedback as part of the public comment proceeding on the CCT Final Report.

ICANN commissioned a third party, an economist, to address the ICANN Board's 1 March 2019 request to "identify what types of data would be relevant in examining the potential impacts on competition and, whether that data is available, and how it could be collected [...]" to inform the Board's decision.

What significant materials did the Board review?

The Board considered various significant materials and documents. In addition to the study, the Board consulted the review team's final report, and the Staff Report of Public Comment Proceeding on Competition, Consumer Trust, and Consumer Choice Review Team (CCT) Final Report & Recommendations.

Are there positive or negative community impacts?

Taking action on the four CCT pending recommendations contributes to further addressing the outcome of the Specific Review, and enhancing ICANN's accountability.

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

None.

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 in the public interest as it is a fulfillment of ICANN Bylaws, as articulated in Section 4.6. It is also within ICANN's mission and mandate. ICANN reviews are an important and essential part of how ICANN upholds its commitments.

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?

None required.

Rationale for Resolutions 2024.07.29.02 – 2024.07.29.03

In order to facilitate the New gTLD Program: Next Round (Next Round) governance structure outlined above, ICANN org has a need for external resources to be dedicated full-time to how the work gets done, including maintenance of project schedules, budget and human resource tracking, reporting, decision logs, and other areas of implementation management.

Following review and conversations with various firms through a targeted Request for Proposal (RFP) process, the designated provider was selected. The provider was engaged under an initial contract, which was then extended. Based on a positive outcome of the work performed thus far, and to ensure a natural continuation of work carried out, an extension is recommended through [Redacted – Confidential Negotiation Information].

The program implementation manager was engaged by ICANN org in October 2023 and has been supporting the Program with the overall management and oversight of the New gTLD Program. To date, the externally sourced implementation manager has established effective planning and controls for the program and provided the structure needed to drive a successful program.

The gTLD Application Process (GAP) senior project manager was contracted in June 2024 and has been working with the ICANN GAP project lead, the project team and numerous external vendors, providing the structure, tools, and processes to enable the project team to successfully deliver the scope of the project and achieve project objectives. The GAP project is the largest project within the Next Round, responsible for the design, development and implementation of the gTLD application process and system. ICANN is anticipating an extension of the GAP Project Manager contract through [Redacted – Confidential Negotiation Information].

The total value of a contract extension with the selected vendor will be in an amount not exceed [Redacted – Confidential Negotiation Information].

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 utilizes available funding in the most effective and efficient manner so as to be in the best interests of ICANN and the global Internet community.

This decision will have a fiscal impact, but the impact has already been accounted for in the FY25 New gTLD Program budget and will be for the future budgets as well. Further, this decision should not have a negative impact on the security, stability or resiliency of the domain name system, and likely will have a positive impact.

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

Rationale for Resolutions 2024.07.29.04 – 2024.07.29.05

In order to support the New gTLD Program: Next Round (Next Round), ICANN org has a need for a vendor strategist and a vendor sourcing consultant to help define the Next Round vendor risk management and sourcing strategy in line with the New gTLD Program's objectives and needs. This includes the mitigation model for conflict of interest and subjectivities of certain deliverables, segregation of duty requirements, determination of overall number of vendors required to execute the Program with cost effectiveness in mind, and risk mitigation for the unknown volume and duration of work assigned to each vendor.

Following review and conversations with various firms, through a targeted RFP process, the designated provider was selected. The provider has been engaged under a 3-month initial contract. Upon a positive outcome of the initial contract, an extension is recommended in order to continue working with the existing vendor strategist and the vendor sourcing consultant for the following reasons:

• Experience and quality of resources leading organizations through vendor strategy and RFP development.
• Lower cost of resources compared with other vendors.
• Most experienced candidates, with the most applicable skillset, at the lowest cost.
• Internal ICANN staff have limited experience in sourcing contracts of this size with large and experienced firms.
• Expertise in how to set the strategy on utilization of vendors and techniques to structure RFPs in a way to minimize cost and risk.

The vendor strategist will develop the vendor sourcing strategy and pricing model for multiple vendors delivering the gTLD application process capabilities, manage the development of vendor requirements and performance criteria to be included in the Request for Proposals (RFPs), and support ICANN staff in the negotiation of vendor contracts, and establishment of vendor governance and oversight, for the New gTLD Program Next Round.

The vendor sourcing consultant will work closely with the vendor strategist, vendor management team, procurement team, and various subject matter experts to ensure timely and effective development of RFP materials, training and on-boarding of vendors, and engagement with a number of vendors to carry on the application processing of the Next Round.

The total value of the [Redacted – Confidential Negotiation Information] contract extension with the selected vendor will be in an amount not exceed [Redacted – Confidential Negotiation Information].

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 utilizes available funding in the most effective and efficient manner so as to be in the best interests of ICANN and the global Internet community.

This decision will have a fiscal impact, but the impact has already been accounted for in the FY25 New gTLD Program budget and will be for the future budgets as well. Further, this decision should not have a negative impact on the security, stability or resiliency of the domain name system, and likely will have a positive impact.

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

Rationale for Resolution 2024.07.29.06

Why is the Board addressing the issue now?

In resolution 2022.09.22.08, the Board approved a four-step process to implement the recommendation contained in SAC113.

The four proposed steps were:

1. Conduct a Public Comment proceeding on the proposed approach in steps 2, 3 and 4;
2. Instruct IANA to choose the string using the criteria described in SAC113;
3. Conduct a Public Comment proceeding on the proposed string chosen by IANA in step 2; and
4. Pass a Board resolution to reserve the proposed string.

ICANN org completed the Public Comment of the first step and published a report on its outcome. The Board then instructed ICANN org to choose a string using the criteria described in SAC113. IANA chose the string .INTERNAL. ICANN org then completed a second Public Comment on the chosen string and published a report on its outcome.

What is the proposal being considered?

The Board is considering whether to reserve .INTERNAL from insertion in the DNS root zone permanently. Applicants of the next and subsequent gTLD application rounds will not be able to apply for the .INTERNAL top-level domain.

Which stakeholders or others were consulted?

SAC113 discusses many of the efforts, both ongoing and abandoned, in the Internet Engineering Task Force (IETF) to try and resolve this issue. Since the publication of SAC113 the ICANN Board and the Internet Architecture Board (IAB) have exchanged correspondence about SAC113, briefly summarized below.

In the first correspondence from the ICANN Board to the IETF/IAB Chairs, the Board asked for clarification on what the definition of a 'technical use' was for domain names. Since the Memorandum of Understanding (MoU) between ICANN and the IETF considers 'assignments of domain names for technical uses' something the ICANN Board cannot delegate, assign, or instruct IANA to reserve unilaterally.

In its response, the IAB/IETF states:

We understand SAC113 to be a proposal for the ICANN [B]oard to allocate an ICANN Reserved Name, and we believe that it being reserved by ICANN would necessarily require that the chosen string also be removed from consideration for any technical use specified by the IETF. In keeping with our commitment to a single, global namespace (RFC 2826), such a reservation would ensure that the IETF would not consider any special-use name with the same string. Procedurally, if the ICANN board chooses to reserve a string following the advice of SAC113, we would expect the string to be reserved within the IANA-managed reserved domain registry rather than the special-use domain names registry.

The IAB/IETF did not voice any objection to the ICANN Board permanently reserving a top-level string.

During the first Public Comment Proceeding on the Proposed Procedure for Selecting a Top-Level Domain String for Private Use, ICANN received comments from the following groups.

• Business Constituency (BC)
• Governmental Advisory Committee (GAC)
• Intellectual Property Constituency (IPC)
• Network Information Centre for United Kingdom of Great Britain and Northern Ireland (UKGBNI)
• Registries Stakeholder Group (RySG)
• Security and Stability Advisory Committee (SSAC)

Two individuals also provided feedback in their individual capacities.

During the second Public Comment Proceeding ICANN received comments from the following groups.

• At-Large Advisory Committee (ALAC)
• Amazon.com, Inc.
• Business Constituency (BC)
• Google
• I Love Domains - United States o' America (ILDUSA)
• The IO Foundation (IO)
• Registries Stakeholder Group (RySG)
• Security and Stability Advisory Committee (SSAC)

24 individuals also provided feedback in their individual capacities.

What concerns or issues were raised by the community?

Community members have noted that, even if a top-level string is reserved for technical use, there is no way to compel equipment vendors, protocol designers, and others to use it. It is also not possible to determine the extent to which the chosen string will be used. It is therefore conceivable that implementing SAC113 could ultimately have no material effect on the DNS.

It is also likely not possible to choose a single string that will enjoy universal agreement as being the most appropriate string for this purpose. Different stakeholders and individuals may have different ideas of what the best string is for this purpose, and it will not be possible to identify a single string that will be acceptable to all stakeholders. This consequence is, however, distinct from the ability to choose a string that adheres to the criteria set forth in SAC113.

ICANN org initiated the first public comment proceeding on the proposed process and published a report on the public comment proceeding.

In response to the report of the first public comment proceeding the SSAC provided additional input via a correspondence, SSAC2023-05: SSAC Response to Public Comment Summary Report on Proposed Procedure for Selecting a Private Use TLD in which the SSAC commented:

The SSAC certainly acknowledges that much expertise exists within ICANN org to implement policy decisions. However, implementation plans, e.g., the work products of Implementation Review Teams, are routinely published for public comment before actual implementation. Therefore, it is disappointing that [the summary] response effectively dismisses the request to provide a more detailed selection process (implementation plan) and make that available for Public Comment before that process is undertaken.

ICANN org sent a response to SSAC2023-05 describing the procedure and noting that the Board still had to make a decision on whether or not to proceed with instructing IANA to select a string for reservation.

The Board then proceeded with instructing ICANN org to proceed with choosing a string for reservation with Board resolution 2023.09.10.09. IANA then proposed .INTERNAL and initiated a second public comment proceeding. Two themes were identified in the comments received that did not agree with the proposal.

The first was that .INTERNAL was too long. Six respondents to the Public Comment believed the selected string to be too long.

Additionally, one respondent believed that the string was not meaningful enough. This respondent viewed the analysis as insufficient to demonstrate the meaningfulness of the string, and concluded the assessment may need to be performed again.

What significant materials did the Board review?

The Board has reviewed SAC113, an Options Paper developed by ICANN org staff, correspondence between ICANN and the IAB, the MoU between ICANN and the IETF, the Public Comment Summary Report of the Proposed Procedure for Selecting a Top-Level Domain String for Private Use Public Comment, SSAC2023-05, ICANN org's response to SSAC2023-05, and the summary report on the second Public Comment Proceeding.

What factors did the Board find to be significant?

The Board recognizes that the problem highlighted in SAC113 is a legitimate and significant one that could, if not addressed, materially affect the DNS. Reserving .INTERNAL will not only close out SAC113, but also resolve a longstanding issue. Network administrators unable to use a name in the global DNS for their private, or internal, uses can now safely use .INTERNAL.

Are there positive or negative community impacts?

A positive impact from this Board resolution is to complete the process to provide a designated namespace for the private use of vendors and other users of the DNS. A negative impact is that there will be one fewer meaningful names available for delegation in the root zone.

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

No additional fiscal impact is anticipated as a result of reserving .INTERNAL for private use.

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

The SSAC has identified many security, stability, and resiliency issues associated with the uncoordinated use of private-use names in SAC113. It is impossible to determine the extent to which reserving a string for private use will alleviate these issues. However, it will not introduce any new security, stability or resiliency issues. It will also not increase the severity of any known and existing security, stability, or resiliency issues.

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

Reserving a string from delegation permanently is in the public interest for the reasons outlined in this resolution and rationale. It is also within the scope of ICANN's mission as described in the Bylaws. Specifically, Section 1.1 (a) (i) which states: "[ICANN] Coordinates the allocation and assignment of names in the root zone of the Domain Name System [..]".

In its letter to the Board, the IAB/IETF agreed that this reservation was within the scope of ICANN based on ICANN's MoU with the IETF.

During the first public comment proceeding there were no comments received stating that this reservation was not in the public interest or that it was not within ICANN's mission.

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?

Reserving a string from delegation permanently is neither a defined policy process with ICANN's supporting organizations nor an ICANN administrative function. The Public Comment proceedings outlined in the four-step implementation plan are not required by the ICANN Bylaws, but are part of the proposed process for implementing SAC113. The purpose of this specific Board action is to finalize this process by reserving .INTERNAL permanently, thereby preventing applicants of the next and subsequent gTLD application rounds from applying for it.

Rationale for Resolutions 2024.07.29.07 – 2024.07.29.08

Article 12, Section 12.2(a)(ix) of the ICANN Bylaws permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." In its ICANN80 Kigali Communiqué (17 June 2024), the GAC issued advice to the Board regarding the Applicant Support Program (ASP) and Auctions: Mechanisms of Last Resort/Private Resolution of Contention Sets in New gTLDs. The GAC also provided a follow-up to previous advice regarding the Applicant Support Program and Urgent Requests for Disclosure of Registration Data. Article 12, Section 12.2(a)(x) of the ICANN Bylaws states that the

advice of the Governmental Advisory Committee on public policy matters shall be duly taken into account, both in the formulation and adoption of policies. In the event that the Board determines to take an action that is not consistent with Governmental Advisory Committee advice, it shall so inform the Governmental Advisory Committee and state the reasons why it decided not to follow that advice. Any Governmental Advisory Committee advice approved by a full Governmental Advisory Committee consensus, understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection ("GAC Consensus Advice"), may only be rejected by a vote of no less than 60% of the Board, and the Governmental Advisory Committee and the Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. The Governmental Advisory Committee will state whether any advice it gives to the Board is GAC Consensus Advice.

The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of policies. At this time, the Board's current thinking and approach to implementing SubPro recommendations related Topic 17 and GNSO Guidance Process Recommendations concerning the Applicant Support Program is inconsistent or could be viewed as inconsistent with item 1.a.i and 1.a.ii of the GAC's advice in the ICANN80 Kigali Communiqué. Regarding item 1.a.i, the Board notes concerns that changes to the processing and evaluation of ASP applications at this stage may reduce the time supported applicants will have to access resources, would not solve the challenge of how to decide which applicants receive support over others, and may delay the opening of the New gTLD Program: Next Round. Regarding item 1.a.ii, the Board notes concerns that implementing this advice may substantially increase the risk of conflict of interest and legal challenges over the evaluation and related decision-making of ASP applications. Furthermore, the Board notes that ICANN org is conducting a Request-for-Proposal (RFP) process to contract an independent Standing Application Review Panel (SARP) and that changes to this established plan and approach may delay the launch of the ASP. The Board is taking action today on the GAC Consensus Advice to the ICANN Board in the ICANN80 Kigali Communiqué, including the items related to the ASP and Auctions: Mechanisms of Last Resort/Private Resolution of Contention Sets in New gTLDs as described in the scorecard dated 29 July 2024. This decision is in the public interest and within ICANN's mission, as it is fully consistent with ICANN's Bylaws for considering and acting on advice issued by the GAC.

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

• ICANN80 Kigali Communiqué (17 June 2024): https://gac.icann.org/advice/communiques/ICANN80%20GAC%20Communique-zh.pdf
• GAC Response to ICANN80 Kigali GAC Communiqué and Initial Feedback for Consideration (08 July 2024): https://gac.icann.org/contentMigrated/gac-response-to-icann80-kigali-gac-communique-and-initial-feedback-for-consideration
• The GNSO Council's review of the advice in the ICANN80 Kigali Communiqué as presented in the 12 July 2024 letter to the Board: https://gnso.icann.org/sites/default/files/policy/2024/correspondence/dibiase-to-sinha-12jul24-en.pdf

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

Rationale for Resolution 2024.07.29.09

The Fundamental Bylaws amendment process initiated today is not a decision on the Bylaws language. It is instead the clearance for posting for public comment the proposed amendments to Article 4, Section 4.2(d) (Reconsideration) and 4.3(c) (Independent Review) that will specifically exclude the ICANN Accountability Mechanisms from being available for challenges to decisions to approve or not approve an application to the ICANN Grant Program.

The Cross-Community Working Group on New gTLD Auction Proceeds '(CCWG-AP) Final Report included Recommendation 7, which states in relevant part "Existing ICANN accountability mechanisms such as IRP or other appeal mechanisms cannot be used to challenge a decision from the Independent Project Applications Evaluation Panel to approve or not approve an application. Applicants not selected should receive further details about where information can be found about the next round of applications as well as any educational materials that may be available to assist applicants. The CCWG recognizes that there will need to be an amendment to the Fundamental Bylaws to eliminate the opportunity to use the Request for Reconsideration and Independent Review Panel to challenge grant decisions." Though the Board previously accepted Recommendation 7 on 12 June 2022, on 23 October 2023, the Board revisited that action because of implementation challenges that arose during the design of the ICANN Grant Program. The Board explained:

In order to account for the design work that has progressed since the Board's June 2022 action which defines different stages of assessment of individual applications, from admissibility to eligibility to substantive evaluation by an Independent Application Assessment Panel, the Board expects the limitation to restrict access to ICANN's accountability mechanisms for all decisions on those individual applications, not limited only to those made by the Independent Application Assessment Panel (as stated within the CCWG-AP recommendation). Anything short of this comprehensive view makes it possible that some applicants could have access to ICANN's accountability mechanisms for decisions on their individual applications as long as that action wasn't taken by the Independent Application Assessment Panel. If allowed, this uneven access to the accountability mechanisms still risks the use of auction proceeds to defend against accountability challenges on individual application decisions in a manner the CCWG-AP wished to protect against.

The Board, considering alternative means to achieve the CCWG-AP's stated goal, asked ICANN org to produce a more general Bylaws amendment that would provide a process through which the ICANN community could signal its intent to limit the use of ICANN's Accountability Mechanisms. A draft Bylaws amendment to Article 4, Section 4.1, drafted to support this more general approach was posted for Public Comment in April 2024. The comments received in that forum confirmed the ICANN community was not satisfied with and did not support the general process approach.

The ICANN Board also, in March 2024, sent a letter to the Chartering Organizations to the CCWG-AP explaining that an update to the CCWG-AP's Recommendation 7 to remove the words "from the Independent Project Applications Evaluation Panel" would cure much of the Board's concerns in supporting full implementation of the CCWG-AP's Recommendation 7. That letter confirmed that there are two dependencies to the Board approving the distribution of any grants within the ICANN Grant Program: (1) updating Recommendation 7 and (2) amending the Bylaws to confirm the restriction access to ICANN's Accountability Mechanisms. To date, ICANN has heard back from all Chartering Organizations, with all but one stating either support or non-objection to proceeding with the updated text. The seventh Chartering Organization noted a need for further clarification of how the Board would resolve the issue of the disfavored Bylaws proposal as posted for comment in April.

Today's action makes clear that the Board has heard the community's dissatisfaction with the proposal posted for public comment in April 2024. Multiple commenters to the April Public Comment forum suggested that the preferred path would be for ICANN to pursue a Fundamental Bylaws amendment that specifically excluded decisions on individual applications from the reach of each of ICANN's Accountability Mechanisms. That is exactly the option that the Board is moving forward today. As both the Reconsideration and Independent Review processes already enumerate excluded topics for claims or disputes, the proposed amendment set forth today adds to each of those exclusions, relying on language as likely to be approved within an updated Recommendation 7 ("cannot be used to challenge a decision to approve or not approve an application").

This is a further procedural step necessary to meet the community's conversation on the Fundamental Bylaws amendment process. The Board is not taking any substantive action today on the ICANN Grant Program, as such a decision on updating Recommendation 7 still requires further input from the ICANN community.

The ICANN Board looks forward to the community discussion over these proposed changes.

Today's action is directly related to how the ICANN community may hold ICANN accountable to its mission and work. It is in the public interest, and is aligned with ICANN's Bylaws, to seek public comment on changes to ICANN's Bylaws and the ICANN Accountability Mechanisms defined therein.

Initiating the Fundamental Bylaws Amendment process is not anticipated to result in any impact to the security, stability or resiliency of the Internet's DNS. Nor is this action anticipated to result in any budgetary or financial implications.

This is an Organizational Administrative Function decision requiring public comment.

Rationale for Resolutions 2024.07.29.10 – 2024.07.29.11

When the Interim President and CEO was engaged, both in her role as Special Advisor to the President and SVP Global Stakeholder Engagement, and again as Interim President and CEO, she was offered a base salary, plus an at-risk component of her compensation package. Consistent with all personnel with the ICANN organization, the Interim President and CEO is to be evaluated against specific goals, which the Interim President and CEO established in coordination with the Compensation Committee, which were previously approved by the Board.

The Interim President and CEO provided to the Compensation Committee her assessment of the progress toward her FY24 goals. The Compensation Committee discussed and agreed that the Interim President and CEO should be awarded her at-risk compensation for the second half of FY24 and recommended that the Board approve such payment to the Interim President and CEO. The Board agrees with the Compensation Committee's recommendation.

Taking this decision is in furtherance of ICANN's Mission and is in the public interest in that it helps ensure that Interim President and CEO is sufficiently compensated in line with her performance in furtherance of the Mission, and which reflects that her goals are consistent with ICANN's Strategic and Operating plans.

While the decision to pay the Interim President and CEO her at-risk compensation for the second half of FY24 will have a fiscal impact on ICANN, it is an impact that was contemplated in the FY24 budget. This decision will not have an impact on the security, stability or resiliency of the domain name system.

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