Second Security, Stability, and Resiliency Review

The Second Security, Stability, and Resiliency Review (SSR 2) was initiated in June 2016. The review team's final report was submitted to the ICANN Board in January 2021. The board took action on the recommendations contained in the SSR 2 final report in July 2021. As of August 2021, the review is in the implementation planning phase.

Background

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;
• preserves the security, stability, and resiliency of the DNS;
• promotes competition, consumer trust, and consumer choice; and
• enables access to registration data.

ICANN is also charged to periodically review and assess its performance through the lens of each of the above commitments.

ICANN's board enshrined these commitments (and the associated reviews) in its Bylaws in Article 1 (Mission, Commitments, and Core Values) and in Article 4 (Accountability and Review). Article 4.6 deals with "Specific Reviews," each of which are tied to one of the commitments in the Affirmation of Commitments.

The Organizational Effectiveness Committee of the board oversees the conduct of specific reviews. The SSR is one such review. The Bylaws mandate that the review team include independent experts in the field of networking security and stability. The Bylaws also call for SSR reviews to begin no later than five years after the completion of the prior review.

Initiation, Delay, and Suspension of Work

The call for volunteer applications was posted in June of 2016. The deadline for applications was extended, in part because the ICANN Board had adopted amendments to the organization's bylaws, some of which affected the selection process for specific reviews such as the SSR. Team selection was delayed until February 2017

The team submitted its Terms of Reference (ToR) on May 11, 2017. In June, the Board responded to the review team, noting that the Terms of Reference "in general must provide a clear articulation of work to be done and a basis for how the success of the project will be measured," and expressing some concerns regarding the clarity of the ToR and work objectives. Work continued within the review team and on the listserv, particularly with regard to formulating and refining the team's work plan. However, no formal response issued regarding the board's concerns.

In October 2017, the SSAC submitted a letter to the ICANN Board, advocating for a pause in SSR2 and arguing that the "current approach, if continued without significant change, will ultimately result in a report that does not have the quality expected by the ICANN Community." In the same month, the Board sent objections regarding the scope of the still-evolving work plan, specifically the work of Subgroup 2 and the proposal to conduct a full review of ICANN's internal operational security. Within the review team, reactions were mixed to both letters. A proposed response regarding a planned Los Angeles on-site for Subgroup 2 On October 10-11 (one week from receipt of the letter addressing scope concerns) was not able to obtain consensus, particularly from SSAC-affiliated members of the review team.

In the following weeks, additional actions occurred that were directly or indirectly related to the SSR2 situation. The board had acknowledged their own failure to set expectations for specific review processes, and set about remedying this failure with a proposed operating standards document for public comment. The chairs of other SOs and ACs also reported concerns regarding the direction of the SSR2 review. As a result, on October 28, 2017, the board sent a letter to the review team instructing them to pause all work until meetings could be held between the chairs of the SOs and ACs and board members at ICANN 60. The letter reads in part:

In light of the importance of this effort, the concerns being expressed, and the resources devoted to date, we believe that it is imperative that the community assure itself that the SSR2 is appropriately composed and structured to achieve its purpose. Accordingly, the Board will be meeting with SO/AC Chairs, the SSR2 Review Team, and the community on this topic throughout ICANN 60, and following the meeting will formally ask the SOs and ACs to consider whether they believe there is a need to adjust the scope, terms of reference, work plan, skill set and/or resources allocated to SSR2. Without prejudging the answer to those questions, the Board considers that the most responsible course is to suspend the review team’s work pending responses from the SOs and ACs.

The SSR2 team met with SOs and ACs over the course of ICANN 60, as well as the board. In the aftermath of the meeting between SSR2 and the board, there was a brief discussion between the board and chairs of the SOs and ACs regarding next steps. The result of those meetings was that the SOs and ACs would "do what needed to be done" to correct the trajectory of the review process. There was acknowledgement that there was no existing process for a situation like this, and apologies to chairs and review team members alike regarding potential board or staff contributions to the impasse. The project remained on hold for the SOs and ACs to establish a plan. Board members variously noted that they did not know, and were never informed, that there was a finalized work plan for the team.

In December 2017, the SOs and ACs sent a letter to the SSR2 review team. The letter described the chairs' conclusions regarding the work of SSR2 to date, as well as the responses to a questionnaire submitted to SSR2 review team members. The questionnaire received responses from all but two of the SSR2 members. The chairs concluded that the SSR2 team was made up of dedicated volunteers with a true desire to see the work completed. However, they identified issues of trust, bandwidth, potential conflicts of interest, detail and completeness of the team's work plan, and a challenging and overambitious scope. the chairs summarized their next steps:

The SOAC chairs recognizes [sic] a number of concrete actions for us: first, appoint more members to the SSR2 team and discuss with ICANN Staff what the budget and staffing situation looks like. After these actions have taken place, we are to restart the SSR2 review with some initial concrete items on their agenda: agree internally on updated leadership, COI issues and scope; and work with ICANN Staff and SOAC chairs to agree on communication, milestones, and progress reporting/management of the review.

The letter acknowledged the hard work of the team thus far, and noted that the pause represented an opportunity for team members to assess their bandwidth to continue with the project.

Restart

At the beginning February 2018, the NCPH Intersessional meeting took place in Los Angeles. One of the sessions was devoted to SSR2, as well as the planning for and initiation of the Third GNSO Organizational Review. During the plenary session, which was attended by members of the OEC, Susan Kawaguchi from the GNSO Council provided a status update as it related to the GNSO's communication with the other SOs and ACs:

We just finalized a letter to the SO and AC leaders, trying to come to consensus, come to the middle ground to figure out a way to move forward with putting this team back to work un-suspending it and move on, but with the right resources and talent and expertise. So we're taking this very seriously. You know, I'm sort of developing into a process person. If you have a process, it's much easier than designing it on the fly, and unfortunately the board's action has now, you know, everybody sort of had to sit back and go, "Oh, what do we do now?" The GNSO, through Heather, is trying to lead that and has proposed several paths forward. One is the facilitator for the whole team to, review team, to really decide what they need and somebody to work with them. What I don't think they need, and this is a personal opinion, is SO and AC leaders, even Heather as chair as GNSO, saying this is what you need, review team. Having sat - now I'm on my second review team, it's really important to maintain that independence. So that's what the GNSO is leading - is pushing for. We would like to see this, you know, move on. It's important work. And then take the learnings from it and develop a process.

Later that month, the SOAC chairs again communicated with the review team, presenting a status update and findings from additional communications and a survey of team members. As forecast at the Intersessional, the letter noted that survey comments from team members led the SO/AC leadership to conclude that there was "insufficient alignment within the SSR2-RT on many issues ranging from mission/scope to process/leadership." To address this misalignment, the SOAC chairs requested that the OEC provide a neutral facilitator to work with the group to identify common ground and re-orient the goals and expectations of the team. The OEC agreed, and set about working with the SOAC chairs to identify the required skills and experience that the facilitator should have.

After an RFP process, Phil Khoury was engaged as facilitator in June 2018. The review's relaunch was was announced shortly thereafter on June 7, 2018. The culmination of Khoury's involvement came in August 2018, when the review team (with five additional appointed members) met in Washington DC and worked on drafting a new Terms of Reference. The agenda and notes from the DC meeting indicate that this was the facilitated resolution of outstanding issues and concerns that the SOAC Chairs had requested. Records of Khoury's work with the review team are available largely through the SSR2 listserv archive from his appointment in June 2018 to his sharing of his draft report following the DC meeting.

The team presented a new Terms of Reference to the Board in September 2018. The team followed up with a work plan in November 2018. The team subsequently updated the board in February 2019 on its status subsequent to another multi-day, face to face meeting in Los Angeles. The board acknowledged receipt of the ToR, work plan, and update report at the end of February.

Mid-2019 Setbacks

At ICANN 64 in Kobe, the review team requested technical writing support from the ICANN board and organization. ICANN org conducted a search for a technical writer to be assigned to the review team. A writer was hired in May 2019; however, after two weeks, the writer was dismissed by ICANN org. The review team expressed displeasure about this development (and others) in a letter to the board, CEO, and SOAC chairs:

Unfortunately, the SSR2 Team has a history of being under-supported and obstructed: our work was initially delayed by a lack of documentation regarding the incomplete implementation of the 2012 SSR1 recommendations; we were “paused” for about a year by the Board without prior communication with the Team; we saw considerable delays when asking questions to staff, and received multiple insufficient responses; and we have had professional writing and research support for only 15 days. In addition, the Board’s subsequent handling of the CCT Review Team recommendations* further confused and deflated the enthusiasm of our Team.

*The board approved action on only six of thirty-seven recommendations, placing seventeen of the recommendations on hold pending further research into feasibility, cost, and other unknowns.

The letter reported that the team's work had been substantially set back by the loss of technical writing support. The letter concluded "In addition to raising serious concerns about the accountability, transparency and independence of community reviews required by the ICANN bylaws, these unilateral and in transparent [sic] actions are extremely demoralizing to many Review Team members."

In October 2019, the review team requested an additional $250,000 to complete the work of the review. The request cited the technical writing issue as well as other delays. The Board approved the additional funding in November 2019.

Draft and Final Report

The team published its draft report for public comment in January 2020. The report contained 31 recommendations, with many recommendations including multiple action items to fully implement each recommendation. The public comment period on the draft report was extended from March 4 to March 20, 2020. The ICANN Board's response to the report was posted on March 20. Several comments were received after the close of the comment period.

A total of eighteen comments were received. The report on public comments identified four common themes among the comments:

1. Prioritization - commenters noted that many recommendations were designated high priority, and recommended increased clarity and justifications for prioritization decisions.
2. Outside of Remit/Scope - commenters noted that some recommendations were beyond the Board's power to enact, or were in their opinion beyond the scope of review.
3. Clarity of Recommendations - a number of commenters asked for additional specifics, background, or expected outcomes of recommendations within the report.
4. DNS Abuse - commenters had opinions and objections regarding the definitions of DNS abuse and related terms, as well as the proposed methods of dealing with abuse. There was again concern that some of the policy proposals were more properly addressed to a GNSO policy development process.

The final report was submitted to the board and published for public comment in January 2021. The report contained twenty-four issue areas, with a number of recommendations within each issue area. The review team noted that some recommendations were removed because of lack of alignment with the Board's five-year strategic plan.

There were nineteen public comments submitted on the report; as with the draft report, the comments were diverse and extensive.

Board Action and Implementation Planning

The board addressed the topic of the final report at its regular meeting on July 22, 2021. In keeping with its updated processes, the board issued a scorecard categorizing the recommendations contained in the report under six headings. The board attached a 53-page rationale for its decisions. The six categories in the scorecard were each tied to either approval, rejection, or the placing of recommendations in pending status:

• Recommendations the Board approves, subject to prioritization, risk assessment and mitigation, costing and implementation considerations; and recommendations that the Board approves with the understanding that they are already fully implemented;
• Recommendations the Board rejects because they cannot be approved in full; Maarten Botterman, in his blog post announcing the Board's action on the final report, explains:

The Board does not have the option to selectively approve or reject parts of a single, indivisible community recommendation; they must act on a recommendation as written and not as interpreted by ICANN org or the Board. The Board notes that part of the community intent in incorporating Specific Reviews into the ICANN Bylaws in 2016 was to require the Board to act on recommendations as written, not as interpreted by ICANN org or Board.

• Recommendations the Board rejects; Although ten recommendations were rejected, those recommendations were clustered around three top-level recommendations: the creation of a CSO position with ICANN org; the creation of a temporary specification requiring all contracted parties to keep domains with reported DNS abuse activity below a certain percentage threshold; and an Expedited Policy Development Process to define and implement an anti-abuse policy.
• Recommendations the Board determines to be pending, likely to be approved once further information is gathered to enable approval;
• Recommendations that the Board determines to be pending, holding to seek clarity or further information; and
• Recommendations the Board determines to be pending, likely to be rejected unless additional information shows implementation is feasible.

Scorecard Summary Table

Category	Recommendation(s)	Board Response	Next Steps
Approved/Already Implemented	1.1: Review implementation of SSR1 recommendations and develop plan to complete implementation.	Approved	ICANN org to review SSR2 findings regarding unimplemented recommendations
Approved/Already Implemented	4.1: Continue centralizing risk management functions; adopt a security risk management framework.	Already fully implemented	No action required
Approved/Already Implemented	5.1 - 5.2: Adopt an Information Security Management System (ISMS) and submit to regular audits.	Will be fully implemented upon completion of transition to NIST Cybersecurity Framework	No additional action required
Approved/Already Implemented	9.1: Direct the contract compliance team to monitor and strictly enforce compliance of contracted parties to current and future security and risk management requirements.	Already fully implemented	No action required
Approved/Already Implemented	10.1: Create a webpage that: defines ICANN's current operational consensus on what constitutes "DNS Abuse;" provides links to excerpts of registry agreements and other contracts that reference DNS Abuse; and distinguishes and defines similar terminology such as "malicious conduct" or "security threats." Update annually and archive past versions.	To the extent that the recommendation is intended to enhance transparency, accountability, and clarity of ICANN org’s work on Domain Name System (DNS) security threat mitigation through its existing contractual and compliance mechanisms, and thereby facilitate ongoing community discussions around definitions of DNS security threats, the Board approves this recommendation	Review implementation priority, cost, and other considerations, including whether ICANN's Information Transparency Initiative should incorporate some or all of this recommendation
Approved/Already Implemented	16.1: Create consistent cross-references across the ICANN.org website to allow easy access to all actions taken in the realm of data privacy and data stewardship, particularly as applied to WHOIS/RDS policy	Like recommendation 10.1, this may overlap with the Information Transparency Initiative	Review implementation priority, cost, and other considerations
Approved/Already Implemented	21.1, 22.1 - 22.2, and 23.1 - 23.2: Accelerate implementation of new Root Zone Management System security measures (particularly encrypted email and multi-factor authentication); create a list of services for which ICANN is responsible and publish operational statistics and metrics on those services on an open data platform; request community feedback on those measurements and metrics on an annual basis; improve PTI operating procedures regarding DNSKEY transitions and update the DNSSEC Practice Statement to allow for transitions between different types of digital signature algorithms	Actions are already being taken on specific elements of these recommendations	Review implementation priority, cost, and other considerations
Approved/Already Implemented	24.2: Make the Common Transition Process Manual easier to find by providing links on the EBERO website	Like recommendations 10.1 and 16.1, elements of this recommendation may be best handled by ICANN org within the Information Transparency Initiative	Review implementation priority, cost, and other considerations
Rejected b/c the Board cannot approve the recommendation in full	4.2: ICANN Org should adopt and implement ISO 31000 "Risk Management" framework and validate its implementation with appropriate, publicly available, independent audits	Board approves of ICANN Org's current risk management program and does not see a benefit to switching to the ISO standard. ICANN org is encouraged to continue identifying and adapting industry best practices to serve the organization's mission	Rejected (agree in principle)
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	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	Rejected
Rejected b/c the Board cannot approve the recommendation in full	9.4: ICANN Org should task the compliance team with publishing regular reports that enumerate tools that they are missing that would help them enforce the SSR-related elements of ICANN's agreements, including measures that would require changes to the agreements	Agree in principle that the contractual compliance team should seek and improve tools to do its job; cannot approve the modification of contracts willy-nilly (again, this is impossible under the provisions of the RA and RAA)	Rejected (agree in principle)
Rejected b/c the Board cannot approve the recommendation in full	10.2 - 10.3: Establish a cross community working group to establish a process for reviewing and evolving the definitions of prohibited DNS Abuse; utilize the developed consensus definitions consistently throughout the organization and in communications regarding abuse [see also recommendation 10.1, above]	The board/org cannot unilaterally convene a CCWG; the board is aware of and will continue to engage with the conversations about DNS abuse as a term of art and what types of abuse are within ICANN's remit to act upon; agree in principle with consensus definitions, but the recommendation (10.3) is dependent upon 10.2, which cannot be approved	Rejected (agree in principle)
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	Both the GNSO and the 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	Rejected
Rejected	2.1 - 2.4: Create a CSO position within ICANN org	The CEO of ICANN is responsible for the structure of his team - not the board's place to intervene. The board is satisfied that security policy has sufficient oversight and attention at the C-Suite level and in coordination with the Board's risk committee	Rejected
Rejected	14.1, 14.3 - 14.5, 15.1 - 15.2: Create a Temporary Specification to require contracted parties to keep abuse below a certain threshold; provide incentives for limiting abuse; once the temporary specification is in place, establish an expedited policy development process to create an anti-abuse policy, utilizing the definitions & parameters determined by recommendation 10.2	Board can only create Temporary Specification in "emergency" situations - no such indication of an emergency here. EPDPs can only be initiated by the GNSO Council.	Rejected
Approved	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.	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.
Rejected	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	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
Pending, likely to be approved after receipt of additional information	20.2: ICANN org should create a group of stakeholders involving relevant personnel (from ICANN org or the community) to periodically run table-top exercises that follow the Root KSK rollover process.	This seems feasible and desirable, but more information is needed regarding what the exercise is designed to target	ICANN org to coordinate with SSR2 Implementation Shepherds to determine the purpose and desired outcomes of this recommendation
Pending - on hold to seek clarity or further information	3.1 - 3.3: Proposed roles and responsibilities for the CSO (recommendation 2)	Board is rejecting the creation of a CSO position	ICANN org to coordinate with Implementation Shepherds to see if these roles and responsibilities can be coordinated by other elements of ICANN's risk management staff
Pending - on hold to seek clarity or further information	4.3: Create a risk manager position reporting to the CSO (recommendation 2) with specific duties and responsibilities	Board is rejecting the creation of a CSO position. Also, the CEO is responsible for the structure and job positions within ICANN org	Coordinate with Implementation Shepherds to clarify elements of the recommendation that are unclear, and de-couple the recommendation from dependency upon the CSO role
Pending - on hold to seek clarity or further information	5.3: ICANN org should require vendors and contractors to comply with security principles, and document its due diligence regarding screening of security standards	Engineering & IT team already requires this; unclear whether the recommendation seeks to expand this sort of screening & evaluation to all vendors	Clarify with Implementation Shepherds
Pending - on hold to seek clarity or further information	7.1 - 7.3, 7.5: Establish business continuity and disaster recovery plans based on ISO 22301; enlist RSSAC and RSOs to ensure that PTI's continuity plans and ICANN's continuity plans include all relevant systems, include root zone management, and are in line with ISO 27031; publish a summary of these continuity plans and conduct periodic audits of compliance with the plans	Recommendation 7.4 recommends that ICANN have a non-U.S., non-North American colocation site for failovers. This recommendation is being placed in the "pending, likely to be rejected" category. SSR2's guidelines for successful implementation of recommendation 7's parts includes the creation of the colocated site. The board is concerned that successful implementation of the other parts of recommendation 7 will be impossible without approval of 7.4	Clarify with Implementation Shepherds whether implementation of these constituent parts can be deemed effective without implementation of 7.4
Pending - on hold to seek clarity or further information	9.3: Audit "compliance activities" at least annually and publish results, policy outcomes, and implementation plans	Unclear what is supposed to be audited	Clarify with Implementation Shepherds
Pending - on hold to seek clarity or further information	11.1: ensure that the Central Zone Data Service is accessible in a timely matter without unnecessary hurdles	Unclear how this recommendation is different than the current efforts to implement SAC0097, which has a similar recommendation	Clarify with Implementation Shepherds
Pending - on hold to seek clarity or further information	12.1 - 12.4, 13.1 - 13.2: Assemble an advisory team to overhaul DNS Abuse Reporting processes and data collection; make the data available to academia & researchers; publish reports on statistical "worst abusers" and actions taken against abuse; and create a central clearinghouse for abuse complaints, designed to pass claims to relevant parties. Mandatory participation by gTLDs, voluntary participation by ccTLDs	Sounds great - community is already very active on the topic of DNS Abuse. Also, some aspects of these proposals would need to be more fully understood before proposing an implementation plan	ICANN org to evaluate how this group of recommendations, along with other recommendations pertaining to the security of the DNS, should be considered in a coordinated way, including through ICANN org's DNS Security Threat Mitigation program
Pending - on hold to seek clarity or further information	14.2: Provide lists of domains that have been identified as abusive to the relevant contracted parties	Open questions regarding how to best implement this	As above, ICANN org to evaluate how this recommendation fits into a coordinated plan, including its inclusion in ICANN org's DNS Security Threat Mitigation program
Pending - on hold to seek clarity or further information	17.1: Create a framework to characterize the nature and frequency of name collisions and resulting concerns; include metrics and measurements regarding prevention mechanisms; ensure data privacy protections	This recommendation has dependencies on the outcome of SSAC's Name Collision Analysis Project - board previously recommended considering passing this recommendation through	Board still recommends that SSR2 pass this recommendation onto the NCAP
Pending - on hold to seek clarity or further information	18.1 - 18.3: Generate periodic "executive summaries" of peer-reviewed publications, conference proceedings, and other research findings that are germane to ICANN's work and mission; highlight findings or recommendations for process improvement in security protocols, contract provisions, and other areas related to SSR; recommend additional studies and define how ICANN could provide datasets for such studies (i.e. through the Central Zone Data Service)	"[T]he Board notes that many academic papers published do not reach the level of notice that would impact the work of ICANN and a significant investment of time, money, and effort would be required to sort through these materials. In this manner, Recommendations 18.1 - 18.3 imply unbounded work."	Evaluate tracking efforts currently underway and assess community appetite for this recommendation
Pending - on hold to seek clarity or further information	20.1: Establish a formal procedure for key rollovers, informed by community input, and updated at least as often as the rollovers	Likely massively expensive, and it's unclear what benefits would accrue. Alternatives exist to the proposed scheme that might fulfill the same objectives	Clarify with Implementation Shepherds, and if appropriate, gather community input regarding the proper way forward
Pending - on hold to seek clarity or further information	24.1: Coordinate end-to-end testing of the full EBERO process at predetermined intervals	Live test? What data sets?	Clarify with Implementation Shepherds
Pending, likely to be rejected unless additional information shows implementation to be feasible	6.1: Promote the voluntary adoption of SSR best practices; failing widespread adoption, enforce via contract, MoU, or other agreements	The specifics of "best practices" are unclear; ICANN cannot unilaterally change its contracts with contracted parties; threshold for shifting to contractual enforcement is unclear; etc.	Clarify with Implementation Shepherds
Pending, likely to be rejected unless additional information shows implementation to be feasible	6.2: Implement coordinated vulnerability disclosure reporting; disclosures should be passed on to affected parties; ICANN to regularly report on vulnerabilities, including anonymized metrics and ensuring data protection and privacy	Three recommendations in one; some of this is already done, but creating an omnibus system as well as reporting/pass through to affected parties, is likely impossible	Clarify with Implementation Shepherds
Pending, likely to be rejected unless additional information shows implementation to be feasible	7.4: Establish a third colocated site for disaster recovery outside of the U.S. & North America, or create such a site with a view toward replacing either the Los Angeles or Culpeper site	IANA Naming Function contract makes this impossible; no explanation of benefit; Board requested an explanation of the team's cost/benefit analysis in comments to the draft report	Engage with Implementation Shepherds
Pending, likely to be rejected unless additional information shows implementation to be feasible	9.2: Proactively monitor and enforce registry/registrar contractual obligations to improve accuracy of registration data; establish routine audits of such data, focusing on contracted parties that have received over 50 complaints per year	ICANN org does not have the power to implement this recommendation under current agreements	Clarify with Implementation Shepherds what authority they expect the contract compliance staff to rely upon to implement this recommendation
Pending, likely to be rejected unless additional information shows implementation to be feasible	16.2: Create specialized groups within the contract compliance team that understand privacy requirements and principles, and that can facilitate law enforcement needs under the RDS framework as adopted and amended by the community	The contract compliance team possesses that expertise now, as well as having the Chief Data Protection Officer as a resource; it is unclear what "law enforcement needs" are contemplated; ICANN Org does not have the authority to facilitate whatever those needs are	Clarify with Implementation Shepherds
Pending, likely to be rejected unless additional information shows implementation to be feasible	16.3: Conduct periodic audits of registrars' adherence to their posted privacy policies; ensure that procedures are in place to address breaches	As noted in comment to SSR2's draft report, ICANN org's RAA does not require a privacy policy. You can't audit something that isn't required	Clarify with Implementation Shepherds

Board Rationale

The Board Rationale document is notable for its length - typically, even in complex situations, the rationale is not so long as to require an attachment to the recorded minutes. The board cited Article 4.6 as the basis for the comprehensive and lengthy rationale document:

The categorization approach allows for additional community consultation and information gathering where necessary, such as where recommendations are not clear or present inconsistencies with advice or other community work and public input. Further, the approach ensures Board accountability to the Bylaws-mandated deadline to take action on the recommendations within six months of receipt of a final report. The Bylaws require that for every Specific Review recommendation that the Board does not accept, the Board must provide a rationale supporting its action.

The board noted several themes among the recommendations, which in some cases made a particular recommendation impossible to approve as an a priori matter:

• SSR2 recommendations are considerable in number, complex, and have interdependencies with other significant areas of work underway. The board noted in its scorecard when such other areas of work were implicated by (or addressed the same subject matter as) a given recommendation.
• Some recommendations contain components that the Board cannot approve, along with components that are feasible, and in some cases already being done. Per Maarten Botterman's comment, above, the board rejected these recommendations, even in situations where they agreed in principle with the spirit of the recommendation.
• Some recommendations are polarizing, with public comments reflecting different, often opposing views. The board implied, as well, that some recommendations were inconsistent with advice from within the community.
• 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 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.

Implementation Planning Phase

An ICANN Board Caucus has met with the SSR2 implementation shepherds twice as of December 2021. A key focus of the meetings to date is to resolve the "pending" recommendations where additional information from the review team was required.

At its September meeting, Danko Jevtovic reiterated the Board's commitment to grow its understanding of the review team's recommendations as well as inform and educate the implementation shepherds regarding what is possible. The September meeting specifically addressed two categories of recommendations:

• Audits, either under ISO 31000 or otherwise, regarding ICANN's security and risk management practices; and
• Recommendations that were contradictory to the ICANN Bylaws (Board implementing policy, additional contractual compliance activity or contract amendments).

In both cases, the conversation tended toward an autopsy of the review team's process and rationales.

In December 2021, ICANN org submitted its first series of clarifying questions to the implementation shepherds listserv. The questions dealt with the recommendations in the "Pending - Likely to be Approved" category, and sought clarification based on the scorecard assessments and board rationales for those recommendations. ICANN org hoped to receive answers to these questions by January 14, 2022