Dear RDS-WHOIS2, ICANN Org has reviewed the 23 recommendations in the draft report and would like to highlight areas that would benefit from clarification, as you work toward finalizing the recommendations. The input you will find below is not intended to discuss the merit of recommendations, but rather identifies elements for your consideration as you process public comment and shape your final recommendations. We note that you have assigned priority levels to each recommendation. In absence of a definition of what these entail, we would recommend factoring the impact of EPDP, GDPR, and need for community input etc. into the establishment of priority levels. In the context of your strategic priority related recommendation 1.1, we would like to call your attention to an initiative ICANN launched in April 2018 – see https://www.icann.org/news/blog/improving-our-planning-and-preparation that seeks to “identify legislative efforts across the globe early-on to raise awareness within ICANN and consider potential impacts, including how these legislative initiatives may have unintended consequences, which may be avoided”. The reports issued to date can be found at: https://www.icann.org/legislative-report. Additional context can be found at: https://www.icann.org/news/announcement-2018-08-30-en. We believe this may be in alignment with the improvements you suggested. On recommendation 3.1 (outreach), a clarification from the review team on whether it has insights into the user requirements for web documentation and what these are would be a great addition to the report to help determine specific needs. A review and feedback of current compliance related webpages would also be useful to evaluate any potential improvements needed. On recommendation 11.1 (common interface), based on the review team’s suggested implementation, it appears that the metrics and SLAs asked for in the recommendation are intended for use by ICANN org as mechanisms to proactively identify compliance issues. ICANN org would like to note that there are multiple reasons queries could return blank fields, or no results. It is not possible programmatically to determine the causes of these results. Additionally, per the Temporary Specification, gTLD registration data results could differ between registry and registrar outputs. Therefore, inconsistencies in registrar and registry gTLD registration data outputs are not necessarily compliance issues. ICANN org would also like to inform the RDS-WHOIS2 review team that the existing WHOIS look-up tool at whois.icann.org will be updated in the coming months with a new tool built on RDAP. It is possible and intended that the new tool would function in such a way that no data would be collected by ICANN org. On law enforcement recommendations (LE.1 – LE.2), indication from the review team on what “regular” refers to would constitute helpful guidance on timing of data gathering efforts. In addition, we would encourage the review team to refine the scope of the surveys to bring additional clarity to their purpose. On safeguarding registrant data (SG.1), we would recommend clarifying how the recommended action would differ from Principle 1(f) of Article 5 of the GDPR, and whether the review team meant to refer to baseline requirements (vs. uniform requirements). ICANN Org notes that section 3.2 of the 2013 RAA currently requires Registrars to notify ICANN within 7 days of any unauthorized access to or disclosure of registrant account information or registration data. With respect to compliance related recommendations, we would remind the review team for 4.1 and 4.2 that actions to mitigate are contracted parties’ prerogative and sanctions are unfeasible based on the current policies/contracts. On CM.1 we also wish to flag that the WHOIS Accuracy Program Specification of the 2013 RAA states that if Registrar does not receive an affirmative response from the Registered Name Holder, the Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. On CM.3, we would also would recommend using the GAC terms of “underserved regions” instead of “global south”, as some stakeholders may view global south as not representative of their region and there are conflicting views on the use of the term Global South outside of ICANN. In addition, we believe clarifications on the following would be helpful to provide further detail and context: · On CM.1, How would the review team expect the determination of the best path forward to be made? · On CM.3, What does “regions” refer to – i.e. registered domain name holder, registrar/record, or reporter? How is it anticipated that the review of registration data for a sample of names will yield insight into awareness of reporting tools in each of the regions? · On CM.5, what would be the envisioned timeline, form (e.g. initiated PDP), and topic a potential PDP would be expected to address? Could the review team clarify what a “risk-based approach” refers to? What new RDS policies is the review team referring to? How would the GNSO be expected to incorporate these requirements for measurement, auditing, tracking, reporting and enforcement in all new RDS policies? Per Section 4.6 <https://www.icann.org/resources/pages/governance/bylaws-en#article4.6> of ICANN Bylaws, the ICANN Board has six months within receipt of the final report to consider the review team’s recommendations. We would suggest factoring this into implementation details you include in your recommendations (see 1.1 – 1.2 – 1.3 – 15.1 – LE.1 – LE.2). We hope you find this feedback helpful and welcome any follow-up questions or comments you may have. We thank you for all of your efforts in finalizing your recommendations and in supplementing them with additional detail. Thank you, Best regards ICANN org