- RDS-WHOIS2-RT - lists.icann.org

Relevant Research Links Edits
by Jackie Treiber Dec. 19, 2018

Dec. 19, 2018

?Hi everyone, The Relevant Research Links sections for Privacy/Proxy and Common Interface are in need of your attention. You can find them now in Appendix I. You should have access to this document via the Index sent out during out F2F meeting last week. Thanks, Jackie

1 0

Plenary Call #44 | 17 December 2018 | 15:00 UTC | Slides - Agenda
by Jean-Baptiste Deroulez Dec. 17, 2018

Dec. 17, 2018

Dear review team members, In preparation for your plenary call #44<https://community.icann.org/x/OwvVBQ>, scheduled for today, Monday, 17 December at 15:00-16:30 UTC, please find the slides attached and the below meeting agenda: 1. Welcome, roll-call, SoI 2. Recommendations updates review: * Recommendation 5.1 * Recommendation CM.3 * Recommendation 10.1, 10.2 4. A.O.B. As always, let us know if you have any questions or concerns. Kind regards, Jean-Baptiste

1 0

RDS-WHOIS2 Ftof 4: Action items
by Jean-Baptiste Deroulez Dec. 17, 2018

Dec. 17, 2018

Dear review team members, Per Alan’s request, please find below the identified action items. I have also attached the recommendations (draft report version). Level of priorities Action item: Define priority level for each recommendation with some quick description. E.g. High, to be implemented by… Action item: Include brief statement that refers to timing envisioned for recommendations while highlighting some of the dependencies. Agreement to consider the six-month Bylaw window in assessments. Report Action item: ALL - Reference to “The Board should negotiate …” has been used in a few places throughout the report. The RT will update this wording throughout the report consistently. Executive Summary Action item: Add section of the problems of the policy development process regarding a single RDS (WHOIS) in the Executive Summary. (based on WHOIS1 Rec #2: Single WHOIS Policy action item) Action item: RT needs to evaluate recommendation numbering, potential explanation in ES. Action item: History of WHOIS on ICANN’s website. Erika to provide Jackie with the right content/references link so introduction section can be properly updated. Background Section Action item: Alan and Jackie review and modify the WHOIS Background section (in reference to the last bullet on slide # 40 of Day # 3 of F2F meeting) WHOIS1 Rec #1: Strategic Priority (Cathrin) Decision Reached: Do a rewording/reaffirmation of strategic priority, in the implementation note: reference to stakeholders is there. Work should be interactive and Board should not act unilaterally. Action item: Since the former Board WG was dissolved, the recommendation should be reformatted to say any WG that is focusing on RDS issues should be made public and not make specific reference to a particular WG. Action item: Comments from NCSG on R1.1, R1.2 and R3.1 need to be updated to Neutral, instead of Disagreement in the public comment summary. Action item: As per Dmitry’s note, Cathrin to report for this recommendation that “legislative efforts are not enough”. WHOIS1 Rec #2: Single WHOIS Policy (Carlton) Action item: Jackie to work with Alan to mention the problems of the policy development process regarding a single RDS (WHOIS), to be placed in the Executive Summary. WHOIS1 Rec #3: Outreach (Alan) Action item: DNRC comment on section: Alan to update language. R3.1: Action item: ICANN org to change public comment of NCSG to “Neutral” if comment not already marked as such. Action item: Alan to clarify what specific improvements we are looking for. R3.2: Action item: NCSG comment: Alan to work with Jackie on rewording of the recommendations to clearly articulate the need for outreach before and after RDS changes are finalized. Action item: Add implementation note, that the RT does not have any input on ICANN budget. WHOIS1 Rec #4: Compliance (Susan) Action item: * Susan to clarify that ICANN will not go on fact-finding missions, but use the information they currently have on hand (input received). * Susan to clarify that Compliance enforces Registrars to enforce data accuracy for registrants. R4.1 Action item: Volker to provide language to update recommendation 4.1 based on RrSG and NCSG comments. Action item: Susan to delete the portion of the recommendation that refers to sanctions and make a reference to it in the report text. R4.2 Action item: Volker and Alan work on rewording R4.2 and add some metrics in for measurability and success of implementation. WHOIS1 Recs #5-9: Data Accuracy (Lili/Cathrin) R5.1: Action item: Lili & Cathrin to rewrite recommendation. It is conceivable that the recommendation could be removed or replaced with a different one. Consider changing the recommendation to say “ARS” (or some sort of accuracy-reporting system) must continue, even post-GDPR because the then-users of the data will want accuracy of data available to them. (There must be some level of contactability/accuracy of the data and we must consider the resources of Compliance) Action item: Lili and Cathrin to add a bookmark “if indeed it is conceivable that the outcome of ePDP is that the work that Compliance does today becomes more complex than it currently is, compliance must be properly resourced to do its job.” Wording to be discussed. Action item: ICANN org to double-check the recommendation numbering to ensure comment was in response to recommendation 5-9 and adjust as needed. Action item: (RrSG comment) Cathrin to review this section of the report and consider rewording as needed. Cathrin to provide Jackie with the correct references. Cathrin to insert the references in the PC document as well. WHOIS1 Rec #10: Privacy/Proxy Services (Volker) R10.1 Action item: Recommendation stands but Volker needs to make sure wording is clear. WHOIS1 Rec #11: Common Interface (Susan/Volker) Action item: Susan/Volker to clarify that this recommendation was not specifically aimed at compliance. WHOIS1 Rec #12: Internationalized Domain Names (Dmitry/All) Action item: RT to review this section and recommendation and decide if changes are needed. RT needs to evaluate recommendation numbering, potential explanation in ES. WHOIS1 Rec #15-16: Plan & Annual Reports (Lili/Stephanie) R15.1 Action item: Stephanie to work with Jackie to modify the recommendation language. (Immediate suggestion to mention language “impact evaluation:”) * Add a comment that ICANN needs to focus more on ensuring the intent of the recommendation is implemented. * Add something focusing “Consider to what extent implementation is meeting the intent, and was effective” Objective 3: Law Enforcement Needs (Cathrin) LE.1 Action item: MSSI to estimate number of hours spent on the LE survey in response to NCSG request for estimated cost associated with conducting the survey. Action item: In response to the PC, Cathrin to work with Jackie to add clarifying text/update rationale to reflect difference between use of surveys and studies. Action item: Cathrin to bring this recommendation to GAC’s attention, Alan to EPDP’s Action item: Clarify what “regular” means and include rationale: 1) ex-ante impact assessment 2) evaluate new policies once there are in place. LE.2 Action item: In response to NCSG comment, Cathrin to add a clause “factoring costs/benefits analysis”. Also, reword the recommendation to define what “extend” means. New suggested text: The ICANN Board should consider to conducting comparable surveys and/or studies(as described in LE.1) to other RDS (WHOIS) users working with law enforcement on a regular basis. Objective 4: Consumer Trust (Alan/Erika) Action item: Alan and Erika to update section. Objective 5: Safeguarding Registrant Data (Alan) Action item: Alan to update recommendation: Agreement to add: “ICANN Board should consider whether and to what extent notifications of breaches should be publicly disclosed.” Action item: Alan to clarify recommendation in light of section 3.2 of the 2013 RAA Objective 6: ICANN Contractual Compliance Actions, Structure and Processes (Susan, Cathrin, Alan) Action items: CM1: Alan to reword CM.1 so that it does not say “the Board should negotiate …”. The goal is to ensure the recommendation is not dictating a PDP but suggesting a change somehow. CM2: * Alan and Volker to add more details to CM.2 to clarify the registrant fields being addressed in the recommendation. Additionally, the whole recommendation should be reworded to better convey intent. * Update as of 11 December 2018: Based on the updated recommendation and rationale language Volker provided on 11 December (Day # 2), Susan is to take the pen and update the relevant sections of the report accordingly. * Jackie to add in introduction, to the extent that their deliberations so far impact areas in our review. CM3: * Recommendation to be deleted. Add this as a more targeted outreach in the relevant recommendation. * Cathrin to Change Global South reference to underserved regions. * Cathrin to clarify Board options in a footnote. CM4: * Alan to write to ICANN org Compliance and negotiate language to be added to relevant page(s). If successful, recommendation will be deleted. Objective 7: ICANN Bylaws (Carlton/Alan) BY.1 Action item: Carlton to amend the recommendation to incorporate the words “safeguarding the registrant data” and provide clarification that the suggestion is meant to postpone the topic to future reviews. Kind regards, Jean-Baptiste

2 1

Proposed R5.1 replacement plus one on Compliance resourcing
by Alan Greenberg Dec. 16, 2018

Dec. 16, 2018

This is a proposal for a replacement for R5.1 in the draft report. To recap, R5.1 asked for an investigation of anomalous ARS compliance actions. Based on the discussion that Susan and I had with ICANN Contractual Compliance, we still do not FULLY understand the issues but we are sufficiently comfortable that we do not believe there is any merit in keeping the recommendation as written. We had two discussions, one on Monday morning (before Stephanie had arrived) and a second one on Tuesday afternoon. The conclusions for both were roughly comparable. My summaries were: "Okay. So a recommendation saying we must have some level of contactability/accuracy monitoring, [give us a] high level of confidence in the data. And the issue that we have to put on hold somewhere further is resourcing of Compliance if necessary." (Page 95 of https://community.icann.org/download/attachments/90773039/rds-plenary-43-f2…) "At this stage the recommendation is being withdrawn. The replacement recommendation will reiterate the need for continuing diligence regarding accuracy and we will be recommending that the ARS or something comparable be continued." (2:23 of https://participate.icann.org/p3nv3p6irnk) I also note that during the discussion, the issue of contactability vs accuracy was brought up with some RT members feeling that the former was a better measure and perhaps easier to achieve (not all RT members agreed). I propose: 1. We adjust the report section to reflect the overall results of the ARS results to date, removing undue reference to the "anomalous" results we flagged in the draft report but keeping the clear statement that there were still significant accuracy issues being detected. If it does not already reflect it, it should make it clear that the ARS was suspended due to the Temp Spec. and its continued use is contingent of appropriate EPDP actions to sanction such processing. 2. Recommendation: R5.1 The Accuracy Reporting System, which was instituted to address concerns regarding RDS (WHOIS) contact data accuracy has demonstrated that there is still an accuracy concern and therefore such monitoring must continue. ICANN Org should continue to monitor accuracy and/or contactability through either the ARS or a comparable tool/methodology. This recommendation is in line with the conclusion drawn to both discussions and there was no objections raised at the time. I further note that we had planned to return and include a recommendation on Contractual Compliance resourcing. If we wish to do this, here is a proposed recommendation CM.3 The ICANN Board should take steps to ensure that ICANN Contractual Compliance is adequately resourced factoring in any increase in workload due to additional work required due to compliance with GDPR or other legislation/regulation. Both will be discussed on the RT meeting tomorrow Alan

1 0

Jackie's Edits in Google Docs
by Jackie Treiber Dec. 12, 2018

Dec. 12, 2018

Hi everyone, Somehow in the process of importing my edited version of the draft to Google Docs, most of my edits were lost. I will be re-adding these edits manually over the next few days. I just wanted to ensure that you all knew this. Many thanks, Jackie

1 0

Rec SG.1
by Alan Greenberg Dec. 12, 2018

Dec. 12, 2018

Rec SG.1 New sentence added at the end: The ICANN Board should require that the ICANN Organization, in consultation with data security and privacy expert(s), ensure that all contracts with contracted parties (to include Privacy/Proxy services when such contracts exist) include uniform and strong requirements for the protection of registrant data and for ICANN to be notified in the event of any data breach. The data security expert(s) should also consider and advise on what level or magnitude of breach warrants such notification. In carrying out this review, the data security and privacy expert(s) should consider to what extent GDPR regulations, which many but not all ICANN contracted parties are subject to, could or should be used as a basis for ICANN requirements. The ICANN Board must either negotiate appropriate contractual changes or initiate a GNSO PDP to consider effecting such changes. The ICAN Board should consider whether and to what extent notifications of breaches that it receives should be publicly disclosed.

1 0

R3.2 Edits
by Jackie Treiber Dec. 12, 2018

Dec. 12, 2018

Added text is bolded R3.2: With community input, the ICANN Board should instruct the ICANN Organization to identify which groups of those that routinely engage with ICANN should be targeted effectively through RDS (WHOIS) outreach. In light of GDPR-driven changes, ICANN should consider the needs for education within and outside of ICANN communities. An RDS (WHOIS) outreach plan should then be developed, executed, and documented. There should be an ongoing commitment to ensure that as RDS (WHOIS) policy and processes change, the wider community is made aware of such changes. WHOIS inaccuracy reporting was identified as an issue requiring additional education and outreach and may require a particular focus. The need for and details of the outreach may vary depending on the ultimate General Data Protection Regulation (GDPR) implementation and cannot be detailed at this point.

1 0

15.1 Edits
by Jackie Treiber Dec. 12, 2018

Dec. 12, 2018

15.1: (Edit was to the Implementation section, bolded) The ICANN Board should ensure that implementation of RDS-WHOIS2 Review Team recommendations is based on best practice project management methodology, ensuring that plans and implementation reports clearly address progress, and applicable metrics and tracking tools are used for effectiveness and impact evaluation. *Implementation Note should mention The ICANN Board should take the lead in developing the structure and metrics for the plan and implementation reports. An overview of the recommendations generated by this Review Team will be the foundation for that design. The envisioned implementation timeline should be within 6 months. The organization should consider an impact evaluation to measure to what extent implementation is meeting the recommendation's intent and was effective.

1 0

LE.1 Edits
by Jackie Treiber Dec. 12, 2018

Dec. 12, 2018

LE.1 (Rec stays same with footnote clarification of difference between studies and surveys) The ICANN Board should resolve that regular data gathering through surveys and studies are to be conducted by ICANN to inform a future assessment of the effectiveness of RDS (WHOIS) in meeting the needs of law enforcement, as well as future policy development (including the current Temporary Specification for gTLD Registration Data Expedited Policy Development Process and related efforts).1 1While surveys as used here refers to questionnaires distributed to a group of respondents to gather their input, studies by contrast, would rely on a detailed analysis and investigation, and not simply be based on user input. Public Comment response pending...

1 0

5.1 Edits
by Jackie Treiber Dec. 12, 2018

Dec. 12, 2018

Recommendation 5.1 Re-write: The ICANN Board should direct the ICANN Organization to take every reasonable measure to ensure "that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay" (GDPR, art. 5(1)(d), and to take the necessary steps to identify inaccuracies, both for standard registrations and those that are made through P/P services. For example, it could look for potentially-anomalous ARS results1 to determine the underlying cause and take appropriate action to reduce anomalies. If the ARS program were to be discontinued, measures to the same effect should be implemented for the subsequent program for data quality assurance. 1(e.g., 40% of ARS-generated tickets closed with no action because the RDS (WHOIS) record changed between the time the ARS report was generated and the time the registration was reviewed by ICANN Contractual Compliance) Rationale: According to the GDPR, Article 5, paragraph 1, litera D, "Accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay ('accuracy'). The focus should be not only the contactability, but also the reliability (corresponding to the Registrant). It's highly recommended to have a measurement on the improvement on an annual basis.

1 0