Changes

==Background==

==Background==

The [[Affirmation of Commitments]], an agreement between ICANN and the [[United States Department of Commerce]], establishes ICANN's obligations to perform its duties with specific commitments in mind. All of the commitments bear on public and consumer trust of the organization. ICANN is to perform its functions in a manner that:

The [[Affirmation of Commitments]], an agreement between ICANN and the [[United States Department of Commerce]], established ICANN's obligations to perform its duties with specific commitments in mind. All of the commitments bear on public and consumer trust of the organization. ICANN is to perform its functions in a manner that:

*ensures accountability and transparency of decision-making;

*ensures accountability and transparency of decision-making;

*preserves the security, stability, and resiliency of the DNS;

*preserves the security, stability, and resiliency of the DNS;

|-

|-

| Rejected b/c the Board cannot approve the recommendation in full

| Rejected b/c the Board cannot approve the recommendation in full

| 8.1: ICANN Org should commission a negotiating team that includes abuse and security experts to represent the interests of noncontracted parties during renegotiation of agreements with contracted parties

| 8.1: ICANN Org should commission a negotiating team that includes abuse and security experts to represent the interests of noncontracted parties during the renegotiation of agreements with contracted parties

| That's not how ICANN's contracts work. Although the community has expressed concerns regarding how agreements are negotiated & renegotiated, ICANN org represents the global public interest in its contract negotiations, and not a particular group of stakeholders. Also impossible under the current [[Registry Agreement]] and [[Registrar Accreditation Agreement]]<br />

| That's not how ICANN's contracts work. Although the community has expressed concerns regarding how agreements are negotiated & renegotiated, ICANN org represents the global public interest in its contract negotiations, and not a particular group of stakeholders. Also impossible under the current [[Registry Agreement]] and [[Registrar Accreditation Agreement]]<br />

| Rejected

| Rejected

| Rejected b/c the Board cannot approve the recommendation in full

| Rejected b/c the Board cannot approve the recommendation in full

| 17.2: ICANN Community should develop a clear policy for avoiding and handling new gTLD-related name collisions, and implement this policy before the next round of applications

| 17.2: ICANN Community should develop a clear policy for avoiding and handling new gTLD-related name collisions, and implement this policy before the next round of applications

| Both the [[Policy Development Process for New gTLD Subsequent Procedures|GNSO]] and the [[Name Collision Analysis Project|SSAC]] are in the process of studying name collisions and policy development for the next round of applications. The board is not a policy-making body, and has faith in these community efforts<br />

| Both the [[Policy Development Process for New gTLD Subsequent Procedures|GNSO]] and the [[Name Collision#NCAP|SSAC]] are in the process of studying name collisions and policy development for the next round of applications. The board is not a policy-making body, and has faith in these community efforts<br />

| Rejected

| Rejected

|-

|-

| Rejected

| Rejected

|-

|-

| Pending, likely to be approved after receipt of additional information<br />

| Approved<br />

| 5.4: ICANN org should reach out to the community and beyond with clear reports demonstrating what ICANN org is doing and achieving in the security space.

| 5.4: ICANN org should reach out to the community and beyond with clear reports demonstrating what ICANN org is doing and achieving in the security space.

| Too many unanswered questions and details regarding this recommendation make it impossible to approve as written.<br />

| Too many unanswered questions and details regarding this recommendation make it impossible to approve as written.<br />

| ICANN org to coordinate with SSR2 Implementation Shepherds to determine the feasibility of implementing this recommendation, based on a stronger understanding of its intent and goals<br />

| directed ICANN President and CEO to discuss with any firm producing an audit for ICANN to implement appropriate additional disclosures within the publicly available reports.<ref>[https://www.icann.org/en/system/files/files/ssr2-scorecard-01may22-en.pdf Scorecard: SSR2 Pending Recommendations - Board Action 1 May 2022]</ref><br />

|-

|-

| Pending, likely to be approved after receipt of additional information<br />

| Rejected<br />

| 19.1 - 19.2: ICANN org should complete the development of a suite for DNS resolver behavior testing, and ensure that that capability to conduct functional testing of different configurations and software versions is implemented and maintained

| 19.1 - 19.2: ICANN org should complete the development of a suite for DNS resolver behavior testing, and ensure that that capability to conduct functional testing of different configurations and software versions is implemented and maintained

| The final report mentions three testing suites: a "DNS testbed," a "regression test suite," and a "suite for DNS resolver testing." Any of these may be feasible, but we need clarity as to which is being recommended. The board notes also that an always-on testbed of any type would need to be properly budgeted and resourced<br />

| The final report mentions three testing suites: a "DNS testbed," a "regression test suite," and a "suite for DNS resolver testing." Any of these may be feasible, but we need clarity as to which is being recommended. The board notes also that an always-on testbed of any type would need to be properly budgeted and resourced<br />

| ICANN org to coordinate with SSR2 Implementation Shepherds to determine what is intended by this recommendation and collaborate on feasibility.<br />

| to maintain the existing ICANN testbed in perpetuity for public use, to broaden ICANN's testbed, to implement functional testing of different configurations and software versions go beyond ICANN's remit<ref>[https://www.icann.org/en/system/files/files/ssr2-scorecard-01may22-en.pdf Scorecard: SSR2 Pending Recommendations - Board Action 1 May 2022]</ref><br />

|-

|-

| Pending, likely to be approved after receipt of additional information

| Pending, likely to be approved after receipt of additional information

* ''Several recommendations repeat, duplicate or significantly overlap with existing ICANN org operations, or recommendations issued by other Specific Review teams.'' The board cited the public comments of [[RySG]], [[RrSG]], [[Public Interest Registry]], and others who commented on specific recommendations that were repetitive or duplicative.

* ''Several recommendations repeat, duplicate or significantly overlap with existing ICANN org operations, or recommendations issued by other Specific Review teams.'' The board cited the public comments of [[RySG]], [[RrSG]], [[Public Interest Registry]], and others who commented on specific recommendations that were repetitive or duplicative.

* ''Some recommendations contemplate that the ICANN Board or ICANN org should unilaterally develop policy outside of the GNSO Council’s Policy Development Process.'' This was also noted during the public comment period by RySG, RrSG, and PIR, along with prominent contracted parties [[Tucows]] and [[Namecheap]].

* ''Some recommendations contemplate that the ICANN Board or ICANN org should unilaterally develop policy outside of the GNSO Council’s Policy Development Process.'' This was also noted during the public comment period by RySG, RrSG, and PIR, along with prominent contracted parties [[Tucows]] and [[Namecheap]].

* ''Some recommendations do not clearly address a fact-based problem, or articulate what cost/benefit would be derived or how the desired outcome envisioned by the Review Team would add value and improve security, stability, and resiliency.'' Echoing a common tension between technical attitudes toward security, stability, and resiliency on the one hand, and socially-oriented, policy advocacy stances on the other, the board reiterated its own comments to the previous output of the SSR2 team. Citing both the [[Operating Standards for Specific Reviews]] and the conversations held in the development of the [[Resourcing and Prioritization of Community Recommendations]] draft proposal for community discussion, the board repeated the importance of well-crafted, fact-based recommendations that could articulate specific benefits to the stability, security, and resiliency of the DNS.<ref name="rationale" />

* ''Some recommendations do not clearly address a fact-based problem, or articulate what cost/benefit would be derived or how the desired outcome envisioned by the Review Team would add value and improve security, stability, and resiliency.'' Echoing a common tension between technical attitudes toward security, stability, and resiliency on the one hand, and socially-oriented, policy advocacy stances on the other, the board reiterated its own comments to the previous output of the SSR2 team. Citing both the [[Operating Standards for Specific Reviews]] and the conversations held in the development of the [[Prioritization Framework]] for community discussion, the board repeated the importance of well-crafted, fact-based recommendations that could articulate specific benefits to the stability, security, and resiliency of the DNS.<ref name="rationale" />

 

 

 

 

 

 

[[ICANN Organization]] has made progress on recommendations about reviewing implementation, compliance with security standards for external service providers, publishing contingency and continuity plans, updating information on DNS security threats, and developing a Time-Based One-Time Password and new RZMS security measures for authentication and authorization of requested changes, such as Multi-Factor Authentication (MFA) and encrypted email (Rec 21.1). Specifically, ICANN Org is creating a new webpage for information transparency (ITI) featuring statistics and metrics that reflect the operational status of services (root zone, gTLD, IANA registries; Rec 22.1). ICANN org is engaging subject matter experts to review SSR1 implementation and execute a new plan of action (Rec 1.1) and will include a compliance clause with security standards in its one-year-based contracts with external service-provider parties (Rec 5.3). There is now a project team to publish a summary of the Contingency and Continuity Plan and the DR plan (Rec 7.5). The [[DNS Security Threat Mitigation Program]] page and the ICANN Acronyms and Terms page now link to key terms, and the webpage will include comprehensive information on abuse-related obligations within the RAA and RA by Q4 2023 (Rec 10.1). The work on five recommendations has not started yet, two of which depend on other recommendations' completion. Recs 5.1 and 5.2 will be complete when ICANN org migrates to the [[NIST#Cybersecurity Framework|NIST Cybersecurity Framework]].<ref>[https://www.icann.org/en/system/files/files/specific-reviews-q1-2023-report-31mar23-en.pdf Q1 2023 Specific Reviews Report, ICANN Files]</ref>

==References==

==References==

[[Category:Specific Reviews]]

[[Category:Specific Reviews]]