[ispcp] WG: Suggestions for Compromise re WHOIS RT Final Report -- PROPOSED DRAFT

Sun Oct 14 15:29:29 UTC 2012

FYI

Wolf-Ulrich Knoben

________________________________
Von: Winterfeldt, Brian [mailto:bwinterfeldt at steptoe.com]
Gesendet: Sonntag, 14. Oktober 2012 11:13
An: Stéphane Van Gelder (stephane.vangelder at indom.com)
Cc: Neuman, Jeff (Jeff.Neuman at neustar.us); Knoben, Wolf-Ulrich
Betreff: FW: Suggestions for Compromise re WHOIS RT Final Report -- PROPOSED DRAFT

FYI

Brian J. Winterfeldt
Partner
bwinterfeldt at steptoe.com<mailto:bwinterfeldt at steptoe.com>
Steptoe

From: Winterfeldt, Brian
Sent: Sunday, October 14, 2012 11:08 AM
To: Wendy Seltzer (wendy at seltzer.com)
Subject: Suggestions for Compromise re WHOIS RT Final Report -- PROPOSED DRAFT

Dear Wendy,

Please find below the beginning of a working draft I put together last night to try to suggest were both of our groups can possibly compromise.  Please review with your SG and let me know if you think there is room for negotiation on any of the below points.

Many thanks for your time to try to reach some additional consensus before reporting to the Board.  I appreciate the opportunity to work with you on this.

Best,

Brian

WHOIS RT Final Report

Suggestions for Compromise - Implementation vs. Policy Development

At its Board Meeting on October 18, 2012, the ICANN Board is scheduled to vote as to how to move forward with the 16 recommendations contained in the WHOIS Review Team Final Report.  To date, despite the Board's request for input, the GNSO Council has been unable to provide cohesive advice due to a disparity among constituencies and stakeholder groups as to which recommendations should require a PDP and which may be implemented without a PDP.  In order to ensure that the Council has the opportunity to provide meaningful input to the Board, it appears a compromise would be necessary on this point.  This document sets forth suggestions for compromise from both the NCSG and IPC and/or BC in order to allow the Council to provide guidance to the Board on as many of the RT's recommendations as possible.

Existing Full Consensus that PDP Needed - No Compromise Required:

10a.  The Review Team recommends that ICANN should initiate processes to regulate and oversee privacy and proxy service providers.

10b.  The Review Team considers that one possible approach to achieving this would be to establish, through the appropriate means, an accreditation system for all proxy/privacy service providers. As part of this process, ICANN should consider the merits (if any) of establishing or maintaining a distinction between privacy and proxy services.

10c.  The goal of this process should be to provide clear, consistent and enforceable requirements for the operation of these services consistent with national laws, and to strike an appropriate balance between stakeholders with competing but legitimate interests. At a minimum, this would include privacy, data protection, law enforcement, the industry around law enforcement and the human rights community.

10d.  ICANN could, for example, use a mix of incentives and graduated sanctions to encourage proxy/privacy service providers to become accredited, and to ensure that registrars do not knowingly accept registrations from unaccredited providers.

10e.  ICANN could develop a graduated and enforceable series of penalties for proxy/privacy service providers who violate the requirements, with a clear path to de-accreditation for repeat, serial or otherwise serious breaches.

10f.  In considering the process to regulate and oversee privacy/proxy service providers, consideration should be given to the following objectives: . . .

Suggestions for NCSG To Consider Possibly Compromising on position that No PDP Needed (I am of course not suggesting that you compromise necessarily on all these points - but thought it might be helpful to identify ones to focus your review on from my analysis of the various positions and points at issue):

Please note that these recommendations generally relate to ICANN data/report generation and other administrative functions to be completed by ICANN staff.

1.  It is recommended that WHOIS, in all its aspects, should be a strategic priority for ICANN the organization. It should form the basis of staff incentivization and published organizational objectives.

3.  ICANN should ensure that WHOIS policy issues are accompanied by cross-community outreach, including outreach to the communities outside of ICANN with a specific interest in the issues, and an ongoing program for consumer awareness.

4.  ICANN should act to ensure that its compliance function is managed in accordance with best practice principles . . .

5.  ICANN should ensure that the requirements for accurate WHOIS data are widely and pro-actively communicated, including to current and prospective Registrants, and should use all means available to progress WHOIS accuracy, including any internationalized WHOIS data, as an organizational objective. (note: NCSG position not included on recommendation chart)

7.  ICANN shall produce and publish an accuracy report focused on measured reduction in WHOIS registrations that fall into the accuracy groups Substantial Failure and Full Failure, on an annual basis.

9a.  The ICANN Board should ensure that the Compliance Team develop, in consultation with relevant contracted parties, metrics to track the impact of the annual WHOIS Data Reminder Policy (WDRP) notices to registrants. Such metrics should be used to develop and publish performance targets, to improve data accuracy over time.

11.  It is recommended that the Internic Service is overhauled to provide enhanced usability for consumers, including the display of full registrant data for all gTLD domain names (whether those gTLDs operate thin or thick WHOIS services) in order to create a one stop shop, from a trusted provider, for consumers and other users of WHOIS services.

12.  ICANN should task a working group within six months of publication of this report, to determine appropriate internationalized domain name registration data requirements and evaluate available solutions (including solutions being implemented by ccTLDs). At a minimum, the data requirements should apply to all new gTLDs, and the working group should consider ways to encourage consistency of approach across the gTLD and (on a voluntary basis) ccTLD space. The working group should report within a year of being tasked.

16.  ICANN should provide at least annual written status reports on its progress towards implementing the recommendations of this WHOIS Review Team. The first of these reports should be published one year, at the latest, after ICANN publishes the implementation plan mentioned in recommendation 15, above. Each of these reports should contain all relevant information, including all underlying facts, figures and analyses.

Suggestions for IPC and/or BC Compromise that a PDP Can or Should be Conducted:

6.  ICANN should take appropriate measures to reduce the number of WHOIS registrations that fall into the accuracy groups Substantial Failure and Full Failure (as defined by the NORC Data Accuracy Study, 2009/10) by 50% within 12 months and by 50% again over the following 12 months.

9b.  If this [development of certain metrics] is unfeasible with the current system, the Board should ensure that an alternative, effective policy is developed (in accordance with ICANN's existing processes) and implemented in consultation with registrars that achieves the objective of improving data quality, in a measurable way.

13.  The final data model, including (any) requirements for the translation or transliteration of the registration data, should be incorporated in the relevant Registrar and Registry agreements within 6 months of adoption of the working group's recommendations by the ICANN Board. If these recommendations are not finalized in time for the next revision of such agreements, explicit placeholders for this purpose should be put in place in the agreements for the new gTLD program at this time, and in the existing agreements when they come up for renewal.

Further Analysis Necessary - No Clear Majority Position and/or Clarifications Needed from One or More Constituencies or Stakeholder Groups:

2.  The ICANN Board should oversee the creation of a single WHOIS policy document, and reference it in subsequent versions of agreements with Contracted Parties.

8.  ICANN should ensure that there is a clear, unambiguous and enforceable chain of contractual agreements with registries, registrars, and registrants to require the provision and maintenance of accurate WHOIS data. As part of these agreements, ICANN should ensure that clear, enforceable and graduated sanctions apply to registries, registrars and registrants that do not comply with its WHOIS policies. These sanctions should include de-registration and/or de-accreditation as appropriate in cases of serious or serial non-compliance.

14.  In addition, metrics should be developed to maintain and measure the accuracy of the internationalized registration data and corresponding data in ASCII, with clearly defined compliance methods and targets, as per the details in Recommendations 5-9 in this document.

15.  ICANN should provide a detailed and comprehensive plan within 3 months after the submission of the Final WHOIS Review Team report that outlines how ICANN will move forward in implementing these recommendations.

Brian J. Winterfeldt
Partner
bwinterfeldt at steptoe.com<mailto:bwinterfeldt at steptoe.com>
Steptoe

+1 202 429 6260 direct
+1 202 903 4422 mobile
+1 202 429 3902 fax

Steptoe & Johnson LLP - DC
1330 Connecticut Avenue, NW
Washington, DC 20036
www.steptoe.com<http://www.steptoe.com/>

+1 212.506.3935 direct
+1 212.506.3950 fax

Steptoe & Johnson LLP - New York
1114 Avenue of the Americas
New York, NY 10036

This message and any attached documents contain information from the law firm Steptoe & Johnson LLP that may be confidential and/or privileged. If you are not the intended recipient, please do not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20121014/85796722/attachment.html>