Registration Directory Service Review (RDS-WHOIS2) Final Report and Recommendations

Why is the Board addressing the issue?

The Registration Directory Service (RDS) Review is one of the four Specific Reviews anchored in Section 4.6 of the ICANN Bylaws. Specific Reviews are conducted by community-led review teams which assess ICANN's performance in reaching its commitments. Reviews are critical to maintaining an effective multistakeholder model and to helping ICANN achieve its Mission as detailed in Article 1 of the Bylaws. Review mechanisms also contribute to ensuring that ICANN serves the public interest.

The RDS Review is an important component of ICANN's commitment to continuous improvement of key areas. It originates from the Affirmation of Commitments (AoC) and was moved to ICANN Bylaws in 2016. The RDS-WHOIS2 Review is the second iteration of the review; the first review effort concluded in 2012 through the WHOIS Policy Review Team.1

The RDS-WHOIS2 Review Team (RDS-WHOIS2-RT) produced 22 final recommendations for Board consideration and released its Final Report2 on 3 September 2019. The Board notes that recommendations were submitted with full consensus and that a Statement of the Non-Commercial Stakeholder Group Member of the RDS Review Team3, which includes areas of concerns, was attached to the RDS-WHOIS2 Final Report. As required by section 4.6 of ICANN Bylaws, the Final Report was published for public comment to inform Board action on the final recommendations.

Under the Bylaws, the Board is obligated to provide rationale for every recommendation issued by the RDS-WHOIS2 Review Team that that the Board does not approve. For completeness, the Board provides rationale below for its action on each recommendation, whether approved or not approved.

What is the proposal being considered?

Formally convened in June 2017, the RDS-WHOIS2-RT's Final Report is the culmination of over two years of work by 11 review team members, representing over 1,000 hours of meetings and countless more hours of work4, assessing the extent to which prior Directory Service Review recommendations (WHOIS Policy Review Team) have been implemented and whether implementation has resulted in the intended effect. The review team also examined the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promotes consumer trust and safeguards registrant data. Additionally, the RDS-WHOIS2-RT performed an evaluation of ICANN's Contractual Compliance function "with the intent of (a) assessing the effectiveness and transparency of ICANN enforcement of existing policy relating to RDS (WHOIS) through ICANN Contractual Compliance actions, structure and processes, including consistency of enforcement actions and availability of related data, (b) identifying high-priority procedural or data gaps (if any), and (c) recommending specific measurable steps (if any) the team believes are important to fill gaps".

To complete its analysis of law enforcement needs, the RDS-WHOIS2-RT issued a survey5 intended "to collect evidence on whether WHOIS meets the legitimate needs of law enforcement agencies and to assess the impact of changes in the context of current adaptations to data protection laws".

The RDS-WHOIS2-RT was informed by ICANN org briefings and available documentation. Exchanges with the ICANN org took place throughout the review cycle, including the submission of written input6 for consideration.

The Board thanks the RDS-WHOIS2 for its dedication and extensive work throughout the review process. The Board appreciates that the RDS-WHOIS2-RT acknowledged the changing RDS landscape and ongoing initiatives in its Terms of Reference, and notes that given the significant importance of GDPR, the RDS-WHOIS2-RT decided to consider GDPR effects on the RDS to the extent possible.

In assessing the RDS-WHOIS2 Final Report and Recommendations, the Board Caucus Group dedicated to this effort (the RDS Board Caucus Group) reached out to RDS-WHOIS2 Implementation Shepherds to obtain a set of clarifications and confirm understanding of some recommendations. Implementation Shepherds are review team members who volunteered to be a resource for clarifications needed on: recommendations' intent, rationale, facts leading to conclusions, envisioned timeline, and successful measures of implementation7. The RDS Board Caucus Group and ICANN org have engaged with the RDS-WHOIS2 Implementation Shepherds since the review team concluded its work. The purpose of this engagement has been to get clarification regarding the intent of certain recommendations in order to inform the Board's consideration of Final Recommendations. A preliminary assessment, including questions requesting RDS-WHOIS2 Implementation Shepherds' guidance, was shared to frame the discussion.8 Such clarifications provided by the Implementation Shepherds are referenced as appropriate within this rationale section and within the Scorecard.

In relation to the recommendations, the Board noted some broad areas and themes that it took into consideration in determining Board action for each recommendation.

Prioritization of Recommendations

ICANN Bylaws (Section 4.6 (a)(vii)(A)) stipulate that "the review team shall attempt to prioritize each of its recommendations and provide a rationale for such prioritization." In its Final Report, the RDS-WHOIS2 indicated that 11 recommendations are "High Priority", six are "Medium Priority" and five are "Low Priority", stating that "Implementation of all recommendations identified as High Priority should begin as soon as possible once approved by the Board and once all preconditions are met. Recommendations assigned medium or low priority need to be considered with respect to overall ICANN priorities, but should not be deferred indefinitely." The RDS-WHOIS2-RT included its prioritization rationale for each of the 22 recommendations.

The Board notes that currently there are over 300 recommendations resulting from Specific Reviews not including the Third Accountability and Transparency Review Team (ATRT3) and Second Security, and Second Security, Stability, and Resiliency Review Team (SSR2), Organizational Reviews and the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability)'s Work Stream 2 (WS2), that are either pending consideration by the Board, or awaiting implementation following Board action; the 22 recommendations issued by the RDS-WHOIS2-RT are part of this count. Neither the Bylaws nor the Operating Standards provide a clear and consistent methodology or basis for evaluating resource requirements associated with these recommendations, prioritizing recommendations across the universe of review teams and cross-community working groups or for budgeting for prioritized recommendations.

The Board has started a conversation with the community on the topic of prioritization; see Resourcing and Prioritization of Community Recommendations: Draft Proposal for Community Discussion, and the discussion continued at the public session at ICANN66 in November 2019, Enhancing the Effectiveness of Review Recommendations and Their Implementation. Additionally, the ATRT3 determined that the topic of prioritization of recommendations was relevant to its work and important to the ICANN community, thus including its views on this topic for community consideration in its Draft Report. The public comment proceeding closed on 31 January 2020 and the ATRT3 will consider the comments it received as it refines its report in preparation for the issuance of the Final Report in April 2020. In its public comment to the ATRT3, the ICANN Board indicated that it supports the proposal of a "holistic suggestion with respect to prioritization." The Board reiterated "that prioritization of review recommendations cannot take place in isolation and that the prioritization process must fit into ICANN's existing budget and planning mechanisms. Furthermore, all parts of ICANN need to take part in the prioritization – ICANN community, ICANN Board and ICANN org. Prioritization of community-issued recommendations needs to take place within the broader context of all ICANN work and must consider implications on community and ICANN org resources and bandwidth, as well as the availability of resources (including funds) whether required up-front only, or on an ongoing basis."

Considering the ongoing work to prioritize the large number of recommendations, the Board considers that the community prioritization work should be considered as a "precondition" specified by the RDS-WHOIS2-RT in its definition of "High Priority" recommendations. In line with the approach for Competition, Consumer Trust, and Consumer Choice Review Team (CCT-RT) recommendations, the Board believes that implementation work, where no significant incremental costs and resources are needed, should begin as soon as possible. Any recommendations that require significant resources and budget, should be included into operational planning and budgeting processes, allowing for appropriate community consideration and prioritization, as applicable, of planned work.

Recommendations the Board Approves

In total, the Board approves 14 recommendations, as specified in the Scorecard: R1.1, R1.2, R1.3, R3.1, R3.2, R10.2, R11.2, R12.1, R15.1, LE.1, LE.2, CC.1, CC.2, CC.3. Each of these recommendations are consistent with ICANN's Mission, serve the public interest, and are within the Board's remit.

The Board approves the recommendations that call for a forward-looking mechanism that monitors legislative and policy developments (R1.1 and R1.2) and notes that the Board has already endorsed this work more broadly through the charter for the legislative and regulatory tracking initiative in January 2019, through the FY20 goals the Board set for ICANN's President and CEO, and the priorities the Board has identified for itself. Proactively monitoring impacts on the RDS from legislative and policy development around the world is an operational task, and therefore an ICANN org responsibility. The RDS-WHOIS2 Implementation Shepherds clarified, and the Board concurs, that ICANN org's existing initiative already addresses these concerns and – through ongoing collaboration between ICANN org departments – the requisite analysis of global policy developments could be provided to the Board Working Group on Internet Governance which is regularly briefed by ICANN org and updates the ICANN Board as needed. In addition, through the revised public reports and briefings, this information can be shared with the full ICANN community. This aligns with a suggestion made by the Registrar Stakeholder Group (RrSG), supported by Non-Commercial Stakeholder Group (NCSG) in the public comment proceeding, that "such updates also be provided to the GNSO Council to enable it to initiate timely policy development processes where necessary". Recognizing that there are ongoing discussions with the community on how to improve the mechanism and process in place, the Board notes that the Governmental Advisory Committee (GAC) made a reference to the GNSO Council letter to ICANN org (date 24 July 2019) that offers feedback on existing efforts. The Board therefore adopts recommendations R1.1, and R1.2, with the clarification that this work is already underway within ICANN org.

Regarding recommendation R1.3, which recommends certain transparency requirements for the Board's working group on RDS activities, the Board notes general support in the public comment proceeding. The Board notes the clarification received from the RDS-WHOIS2 Implementation Shepherds that the recommendation is not determining a specific set of records to be developed, but instead seeks the availability of information to demonstrate that activities are taking place. In light of the RDS-WHOIS2 Implementation Shepherds' clarification, the Board approves R1.3.

On updating publicly available information related to RDS (R3.1), the Board notes that ICANN org has already launched an effort to redraft the content and improve navigation of the Whois portal. It is anticipated that the involvement of user and focus groups suggested by the RDS-WHOIS2-RT could potentially extend the time period for completion by another two to three months. The Board notes broad support in the public comment proceeding for this recommendation. The At Large Advisory Committee (ALAC), for instance, notes that documentation is "important to end users and to registrants". The Board adopts recommendation R3.1.

On the outreach-related recommendation (R3.2), the Board notes concerns expressed in the public comment proceeding. While the RrSG, supported by the NCSG, agrees with recommendation R3.2, the RrSG cautions against costs and increase of the ICANN budget costs. The NCSG questions the need for this outreach and believes the level of priority (high) assigned to this recommendation by the RDS-WHOIS2 is inappropriate "given the lack of readiness of the data", and the uncertain situation "with respect to any replacement for WHOIS or RDAP implementation". To address budgetary concerns expressed in the public comment period, the Board urges ICANN org, when implementing this recommendation, to consider where efficiencies can be gained by pairing engagement efforts related to RDS with education and awareness related to the implementation of the Registration Data Access Protocol (RDAP). The Board adopts recommendation R3.2.

Recommendations R10.2 and R12.1 recommend the deferral of an assessment of the effectiveness of WHOIS1 Policy Review Team recommendations on privacy/proxy as well as International Registration Data to a future RDS Review Team. The Board approves this recommendation insofar as it agrees to recommend to the next RDS Review Team that these items should be part of its work plan. However, the Board does not set the charters for the RDS Review Teams and therefore cannot dictate that either of these items are addressed. The Board cautions that the RDS-WHOIS3-RT might not consider itself bound by such recommendations. The Board notes broad support in the public comment proceeding for Recommendations R10.2 and R12.1, with the exception of the NCSG, which, in the context of 10.2, cautions that many recommendations will no longer be relevant in light of the new system anticipated for development by the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data Policy (EPDP). The NCSG suggests a fresh start might be necessary and is concerned that it would be a "waste of money" to do otherwise. The Board approves recommendations R10.2 and R12.1 with the caveat that the subsequent review team (RDS-WHOIS3-RT) might not consider itself bound by these recommendations.

On the recommendation to ensure that the common interface displays all applicable output (R11.2), the Board notes that RDAP was designed with the anticipation of the future need to update or address any future policy or contractual changes. From a feasibility standpoint, the Board notes that there may be a need to program the RDAP lookup tool to note differences between registrar and registry data for a domain name. The Board observes support in the public comment proceeding for this recommendation. For instance, the ALAC notes that "although GDPR has reduced the amount of information publicly available, […] maintaining full functionality is required" and "the portal must provide all available information in a clear and usable fashion". The Board approves this recommendation R11.2.

Recommendation R15.1 makes recommendations on the methodology and tracking of implementation of the RDS WHOIS2 recommendations. The Board notes that while project management methodologies and best practices and reporting mechanisms can be implemented in short order, the effectiveness of ICANN org's implementation will likely be assessed based on how these methodologies, best practices and reporting mechanisms lead to what the community would consider to be a successful implementation. As a result, time may be required to observe the effectiveness of implementation of the recommended methodologies. Additionally, the Board acknowledges that work is currently underway in the ATRT3 sphere on streamlining of reviews and prioritization of community-issued recommendations. The outcome of these efforts will inform how this recommendation will be implemented. The Board notes that while no objections were raised in the public comment proceeding, the Registries Stakeholder Group (RySG) cautions against reporting burdens on contracted parties. The Board approves R15.1 recognizing that the potential recommendations on streamlining of reviews and prioritization arising from ATRT3 may have an impact on this recommendation.

With respect to data gathering initiatives pertaining to law enforcement (LE.1 and LE.2), the Board notes that it is unlikely these recommendations are completed in time to inform the EPDP's work. The Board instead directs ICANN org to define a timeline to consult with the GNSO Council on the type of survey data needed (including approach, deadline, and meaning of "other users") as well as targeted audiences, and when such survey efforts should be completed to inform future policy work. The Board observes support in the public comment proceeding – for instance, the ALAC supports surveys and information gathering and views the review team's findings with regards to law enforcement as "very important". The GAC confirms its support for the use of surveys and information gathering including surveying non-law enforcement cyber security practitioners to help mitigate all forms of crime and of cybersecurity threats to the DNS. The Board also notes that comments revealed a number of concerns and objections, such as from the NCSG, the RySG, and the RrSG, including concerns on survey bias, alignment with contracts, the uncertainties of law enforcement needs in light of the GDPR, and others. Even with the concerns raised, and while this work cannot be completed in time to benefit EPDP Phase 2, the Board approves these recommendations as they are aligned with and could be integrated with those efforts to support informed policy making work across the ICANN community.

Recommendation SG.1 recommends that the Board require ICANN's contracts to include uniform and strong requirements for the protection of registrant data (SG.1). The Board notes there are provisions already in the Registrar Accreditation Agreement (RAA) regarding notification to ICANN on certain security breaches, and that the Registry Agreement (RA) does not currently require registry operators to inform ICANN in the event of security breaches. As contemplated by the RDS-WHOIS2 RT, these contracts would have to be amended. However, the Board cannot unilaterally impose new obligations on contracted parties through acceptance of a recommendation from the RDS-WHOIS2 RT. The RA and RAA can only be modified either via a policy development process (PDP) or as a result of contract negotiations. In either case, the Board does not have the ability to ensure a particular outcome.

The Board notes the RDS-WHOIS2 Implementation Shepherds' clarification that the RDS-WHOIS2-RT expects the Board to take appropriate action either via a PDP or through directing contract negotiations, including their input that they do not expect that specific contract negotiations be initiated in response to an individual recommendation; rather the contract negotiation approach could be pursued the next time contracts are negotiated.

In assessing input received in the public comment proceeding, the ICANN Board notes that the RySG believes the recommendation bleeds into compliance with data protection laws and should be handled between ICANN org and the contracted parties directly. The RrSG, with support from NCSG, has no issue with these requirements "with the assumption that any update of contracts will not be extended to anything outside of them" and adds that "such requirements should be general, not specific and merely reference best practice legal regulations such as the GDPR". In contrast, the Business Constituency (BC) feels that data breach reporting is "critical for the protection of registrant data", and recommends it to be a requirement; a sentiment echoed by the Intellectual Property Constituency (IPC) which considers tracking minimal data on data breaches to be a "simple but necessary step" in further protecting registrant data. Others raise issues.

The Board acknowledges that working toward the inclusion of such provisions could be appropriate, but also cautions that the scope of notifications needs to be tethered to ICANN's Mission and contractual role, such as related to circumstances that threaten to undermine the stability, security, and resiliency of the Internet's DNS. The Board therefore approves recommendation SG.1, and directs this item to be included in the next round of contractual negotiations with the Contracted Parties, insofar as it relates to ICANN receiving notification of data breaches in circumstances that threaten to undermine the stability, security, and resiliency of the Internet's DNS. The Board cannot require or guarantee any negotiation outcomes.

On the RDS-WHOIS2-RT's recommendation CC.2 that ICANN initiate action intended to ensure that all gTLD domain name registration directory entries contain at least one full set of either registrant or admin contact details, the Board notes that the EPDP recommendation 29 provides that, before deleting any administrative contact details, the registrar must ensure that it has contact details for the Registered Name Holder. However, the contact details required to be collected and displayed for the Registered Name Holder under the EPDP's Phase 1 recommendations are not identical to those required in the 2013 Registrar Accreditation Agreement (RAA). The Board also notes a divergence of opinion in the public comment proceeding: the RrSG, supported by NCSG, does not support this recommendation and considers it as "very problematic". Furthermore, the RySG believes CC.2 has "significant overlaps with community-developed policies that are in place or in the process of being implemented". The BC discusses competing requirements for longstanding registrations. The Board notes clarification received from the RDS-WHOIS2 Implementation Shepherds that the RDS-WHOIS 2 recommendation CC.2 is aligned with and addressed as part of the implementation of the EPDP phase 1 recommendations. In light of this clarification, and as this is already proceeding to implementation within the EPDP work, the Board approves recommendation CC.2.

The Board approves recommendation CC.3 which calls for adequate resources for ICANN Contractual Compliance and notes that this is already part of ICANN org's existing budgeting and planning process. No concerns are recorded in the public comment proceeding. For instance, the IPC notes that it "remains critical for the Compliance team to be adequately staffed and resourced to fulfill its important function in furtherance of ICANN's mission" and the BC notes that "with the recent changes and staff departures on the Compliance team, this recommendation is more critical".

Recommendations the Board is Placing in "Pending" Status

The Board places four recommendations (R4.1, R4.2, R5.1, R10.1) in a pending status in light of dependencies enumerated below. The Board commits to resolve the pending status and take appropriate action on these four recommendations once all dependencies pertaining to ongoing community work and activities allow for an assessment of feasibility and compatibility. The Board expects to monitor progress on these recommendations through progress updates to be delivered by ICANN org on a regular basis.

For Recommendations R4.1, R4.2, R5.1 and R10.1, these recommendations each have dependencies and overlap with the EPDP Phase 2, priority 2 topics. Taking action on these in advance of Board action on the recommendations that will come out of the EPDP risks duplication and overlap. As a result, the Board places all four of these recommendations into pending status until after Board action on the EPDP Phase 2, priority 2 topics. The Board acknowledges that ICANN org provided information on the considerations for each of these four recommendations that are captured in the Scorecard, however the Board is not in a position to consider the substance of these recommendations at this time.

Recommendation the Board is Passing through to a Designated Community Group for Consideration

The Board passes recommendation (CC.4) to the GNSO Council. This recommendation calls for the GNSO to adopt a risk-based approach to incorporating requirements for measurement, auditing, tracking, reporting and enforcement in all new RDS policies. In passing this recommendation through, the Board is neither accepting nor rejecting the recommendation. The Board is careful to respect the remit and roles of the different parts of the ICANN community and is not directing Board or ICANN org action that would usurp another group's remit. The recommendation calls for work or outcomes that are outside of the Board's remit to direct, and is contingent on community work. The Board is not in a position to direct that the community group come to any particular outcome, nor is the Board initiating any policy development work. The Board notes absence of concern in the public comment proceeding with the exception of the RySG, which finds overlap with community-developed policies that are in place or in the process of being implemented. The Board also recalls a clarification received from RDS-WHOIS2 Implementation Shepherds that this recommendation could be directed to the GNSO. Accordingly, the Board passes recommendation CC.4 through to the GNSO Council for consideration.

Recommendation the Board is Approving in Part and Passing through in Part to a Designated Community Group for Consideration

Recommendation CC.1 calls for the Board to initiate action related to treatment of gTLD domain names suspended due to RDS contact data known to be incorrect. This recommendation requires either a policy to be developed or an amendment to the RA and RAA. As discussed above, in either case, the Board is not able to guarantee an outcome from either process. In the event the GNSO Council wishes to initiate a policy development process in order to address the RDS-WHOIS2 recommendation, the Board passes this Recommendation CC.1 to them for that purpose. While the Board has the ability under the Bylaws to initiate policy work within the GNSO, the Board confirms that in acting on the CCT-RT recommendations, the Board passed through recommendations that require policy development to the GNSO Council in recognition of the policy role of the GNSO and the community's prerogative to initiate policy development processes. There is no reason to deviate from that precedent here. The Board is also approving this recommendation in part, for ICANN org to include in the next round of contractual negotiations for the RA and RAA. The RDS-WHOIS2 Implementation Shepherds confirmed that action on this recommendation could include Board initiation of a policy development process or contract negotiations, and as the Board has previously recognized the community role in initiation of policy development based upon Specific Review team recommendations, the Board once again confirms this role.

Recommendations the Board Rejects

The Board rejects recommendation R11.1 as the interface tool referenced in the recommendation is no longer in use, and the RDS-WHOIS Implementation Shepherds have clarified the same. In July 2019, ICANN org launched a Registration Data Access Protocol (RDAP) lookup service. This new lookup service standardized data access and query response formats and allows the results from data searches to be directly returned from the server to the end-user, without passing through ICANN org servers. As such, ICANN org does not collect or log any information relating to what data is being returned from search queries since ICANN does not touch the data. The current web client cannot support the metrics defined in the recommendation. While there is expression of support in the public comment proceeding for R11.1 (for instance: the GAC "supports the gathering of data recommended by the RDS-WHOIS Review Team), the NCSG is of the opinion that "this recommendation may be redundant after the SSAD is developed". The RySG is "unclear on if or how the SLAs mentioned in R11.1 for the common RDS lookup interface would overlap with the SLAs registries and registrars must meet in responding to RDAP queries" and calls for consideration to be "given to this question before ICANN Org determines which metrics to measure around the interface".

In light of the above considerations, the Board is in a position where it cannot approve this recommendation as the interface tool referenced in the recommendation is no longer applicable, and the system in use cannot be modified to support this recommendation. This decision is in alignment with clarification received from RDS-WHOIS2 Implementation Shepherds in the 29 January 2020 discussion with the RDS Board Caucus Group that the recommendation does not apply to the current version of the portal.

The Board is also rejecting Recommendation BY.1, regarding proposed changes to the scope of the RDS Review mandate as set out in the Bylaws. The Board notes that language in the recommendation could serve to significantly broaden the scope of work for future RDS teams, as well as require specific review team expertise in identifying the "applicable" regulations and laws and then interpreting how current practice addresses those regulations and laws. Keeping up-to-date cross-jurisdictional surveys of data protection and data transfer laws can be quite expensive, and such an effort is quite broad when considering the currently-defined role of the RDS Review in the Bylaws. To that end, the reference to the OECD guidelines that is currently in the Bylaws provides an objective referential starting point, i.e. standards, as opposed to the less defined general scope of a legal database that is called for within the recommendation. The likely expansion of the RDS Review scope as a result of this recommendation also appears to be out of sync with the ongoing community conversations on review streamlining. Because of the overbreadth and impractical nature of what this recommendation suggests, the Board rejects, as approving such a recommendation does not appear to be in the best interests of ICANN. The Board notes that if this or a future Accountability and Transparency Review Team recommends changes to the scope of the RDS Review (as is within the ATRT mandate), the Board will consider such recommendations at the appropriate time.

Which stakeholders or others were consulted?

As required by ICANN Bylaws, the RDS-WHOIS2-RT sought community input on its Draft Report, including 23 draft recommendations, through a public comment period in September 2018. A total of 7 (seven) community submissions were posted to the forum. Additionally, the RDS-WHOIS2-RT conducted engagement sessions, as documented on its wiki space9. The RDS-WHOIS2-RT summarized its approach to how public comments and inputs received were considered in Appendix H of its Final Report.

ICANN Bylaws call for the Final Report to be posted for public comment to inform Board action on the RDS-WHOIS2 Final Recommendations. The public comment proceeding opened on 8 October 2019, closed on 23 December 2019, and yielded a total of nine comments, which were considered during the Board's assessment of Final Recommendations.

The Board also, through the RDS Board Caucus Group, consulted with the RDS-WHOIS2 Implementation Shepherds to gain clarification on some recommendations to help inform the Board action. Information on those interactions is available here.

What concerns or issues were raised by the community?

The summary of community input received on the RDS-WHOIS2-RT Final Report public comment proceeding highlighted that the community was of divergent opinion on the report. While the ALAC, IPC, BC, GAC and two individuals have no concerns on any of the recommendations, the RrSG, RySG and NCSG raise some issues on some recommendations. Concerns include, but are not limited to, overlap with ongoing community initiatives, impact of ongoing community work on feasibility and/or raison d'être of recommendation, compatibility with model or requirements resulting from community work, appropriate allocation of resources, potential interfering with community prerogatives or policy processes, and overall feasibility.

There is general recognition in the public comment proceeding on the Final Report that the RDS-WHOIS2 was faced with challenges given the ongoing changes to the RDS landscape. Concerns and objections specific to recommendations are included above.

Are there positive or negative community impacts?

Taking action on these recommendations will contribute to ensuring ICANN meets its commitments relative to the RDS and enhances security, stability and resiliency of the DNS. Potential actions resulting from these recommendations could affect community bandwidth and resources, in addition to other ongoing work.

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

The implementation of the RDS-WHOIS2 recommendations that the Board has accepted pursuant to the Scorecard will have budgetary impact on the organization. It is expected that any recommendations that require incremental resources should be included into operational planning and budgeting processes, allowing for appropriate community consideration and prioritization, as applicable, of planned work.

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

This Board action is not expected to have a direct effect on security, stability or resiliency issues relating to the DNS, though the outcomes may have an impact in the future.

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

This action is within ICANN's Mission and mandate and in the public interest as it is a fulfillment of an ICANN Bylaw, as articulated in Section 4.6. ICANN's reviews are an important and essential part of how ICANN upholds its commitments. The scope of this review is inherently tied to ICANN's commitment to improve accuracy and access to generic top-level domain registration data, as well as consider safeguards for protecting such data.

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?

Public comments were received prior to Board consideration.