December 2018 - RDS-WHOIS2-RT

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

CM.2 Rec
by Alan Greenberg Dec. 12, 2018

Dec. 12, 2018

Volker's re-write of CM.2 The ICANN Board should initiate action intended to ensure that for all gTLD domain name registrations at least one full set of contact details as required for new registrations under 2013 RAA (or any subsequent version thereof) or applicable policies must be collected or be present for either registrant or admin contact. My revision (with Volker's agreement) The ICANN Board should 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 comparable to those required for new registrations under 2013 RAA (or any subsequent version thereof) or applicable policies. Alan

1 0

The ICANN Board should negotiate contractual terms or initiate a GNSO PDP to require that
by Alan Greenberg Dec. 12, 2018

Dec. 12, 2018

I suggest that we use Volker's wording from CM.2 and in all recommendations, replace The ICANN Board should negotiate contractual terms or initiate a GNSO PDP to require that ... with The ICANN Board should initiate action intended to ensure that ... We will add a general comment that typically the actions that the Board could take are to initiate ICANN Org negotiations with contracted parties, or to initiate or request the initiation of a PDP to effect the change through policy. But the RDS-WHOIS2-RT gives the Board full discretion to investigate other mechanisms if appropriate. Alan

1 0

Caught on a call so will be a little late
by Chris Disspain Dec. 11, 2018

Dec. 11, 2018

Cheers, Chris

1 0

ICANN org input
by Jean-Baptiste Deroulez Dec. 11, 2018

Dec. 11, 2018

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

1 0

Grand Sablon
by Erika Mann Dec. 11, 2018

Dec. 11, 2018

Really great location, traditional modern Belgian restaurant, they take no reservations but you will not have to wait very long and you can have a drink outside and they will call you in once the table is ready ... https://www.tripadvisor.com/Restaurant_Review-g188644-d740584-Reviews-Au_Vi…

1 0

CM.2 - Alternative Language suggestion
by Volker Greimann Dec. 11, 2018

Dec. 11, 2018

The ICANN Board should initiate action intended to ensure that for all gTLD domain name registrations at least one full set of contact details as required for new registrations under 2013 RAA (or any subsequent version thereof) or applicable policies must be collected or be present for either registrant or admin contact. Reason: In the light of the possibility that some contact fields may be eliminated or significantly reduced in scope, a concrete risk exists with regard to domain name registrations that do not meet the requirements of the 2013 RAA (“grandfathered domain names”) no longer having one complete set of contact details associated with the registrant or his representative (registrant or admin). In such cases, action should be undertaken to ensure that the registrant or his representative remain contactable. Timeline: four calendar years or next renewal date, whichever is longer. -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

1 0