Amy, Thank you for laying out the proposed schedule in some detail. I offer below the following comments on some of the issues you have teed up for tomorrow's call, and welcome responses from others. These are listed in the order you listed below. Provider Suspension (Issue 13): Offhand I do not see a problem with section 5.7.1, if we have an adequate labeling protocol in place. Any registrar that receives after the suspension date a registration from the suspended provider could reject it if it is labeled as required. (Of course if it is not labeled as required, this is a different problem (deliberately false Whois data) which this provision can't solve, but could be another grounds for suspension or de-accreditation.) I suppose adequate time would need to be allowed before the suspension becomes effective but I imagine this could be managed. Provider Contact Information (Issue 9): Section 3.12 seems reasonable to me. I guess the only question is whether the officer information (3.12.16)needs to be published, although it certainly should be provided to ICANN. Reveal Requirements (Issue 10): I am not clear on the concern here. This provision was included in the WG report to make clear that providers had flexibility in how they handle disclosure/publication requests and did not have to adopt automated, one size fits all systems. If the provider adopts a policy that those who present sufficiently detailed/credible/urgent disclosure requests will be put in direct touch with customers, even if that means disclosing one means of such contact to the requester, there should be no problem with that so long as the provider's policy is adequately disclosed in accordance with accreditation standards. Code of Conduct (Issue 5): This is a third order issue that I hope will not detain us now, since it deals with a hypothetical future Code of Conduct that would certainly have to go through some kind of extensive drafting and review process. If and when such an effort gets underway then I agree that the definition of consensus would need to be established. Let's not spend time on it now. Domain Name Cancellation (Issue 6): First, the citations to the Agreement seem incorrect, shouldn't it be 3.5.4.1 and 3.5.4.17? Second, I agree that the reference to cancellation of the registered name agreement should probably be dropped from 3.5.4.1, as that action has to be taken by the registrar. {Perhaps the provider should be required to notify the registrar immediately of the breach, simultaneously with supplying it with the "actual" contact information for the customer so that the latter can be published.} Finally, as to 3.5.4.17: as I recall one (or possibly two) WG members felt strongly that customers should be provided the option of cancelling their registrations rather than having their contact points published, and that this should be a required policy for all accredited providers. There was a lot of pushback against such a mandate, with the compromise solution that the provider be allowed, but not required, to adopt such a policy (which of course would have to be adequately disclosed). In practice I agree that such a policy could only be implemented by a provider that is either Affiliated with (i.e., controlled by) a registrar, or at least as the result of some kind of contractual agreement between the registrar and an unaffiliated provider. As I read 3.5.4.17 it simply says that no such policy can trump the applicable UDRP or URS policies as adopted by ICANN. This make sense to me and I don't know of any reason 3.5.4.17 has to be changed in this regard. Looking forward to discussing these further on tomorrow's call. Steve Metalitz On behalf of Coalition for Online Accountability (COA) | www.onlineaccountability.net [image001] Steven J. Metalitz | Partner, through his professional corporation T: +1.202.355.7902 | met@msk.com<mailto:met@msk.com> Mitchell Silberberg & Knupp LLP | www.msk.com<http://www.msk.com/> 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: gdd-gnso-ppsai-impl-bounces@icann.org [mailto:gdd-gnso-ppsai-impl-bounces@icann.org] On Behalf Of Amy Bivins Sent: Tuesday, July 25, 2017 2:44 PM To: gdd-gnso-ppsai-impl@icann.org Subject: [Gdd-gnso-ppsai-impl] Action items (including poll) from today's PP IRT call Dear Colleagues, Thank you for your active participation on today's Privacy/Proxy IRT call. I've attached an updated issues list that includes notes from our discussions today. To summarize for those who could not attend, we discussed the draft PPAA data escrow specification, amendment process, and priorities for upcoming IRT discussions regarding the agreement. To ensure we have a complete record of IRT member views surrounding the data escrow specification, we are re-polling the group. Please complete this poll no later than next Friday, 4 August. We are allowing over a week to complete this poll to ensure that all IRT members have adequate time to consider this issue and provide your input. There is only one substantive question. The results of this poll, coupled with the IRT discussions on the topic to date, will be used to determine the final IRT view on this topic. Thus, it is important that you participate if you want your opinion heard. The poll is available at https://www.surveymonkey.com/r/62XCMSS. As a reminder on the background of this provision, the Final Report does not explicitly mention data escrow, but seems to contemplate that data escrow would be an element of this accreditation program. The 2013 RAA's interim specification on privacy and proxy registration<https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#privacy-proxy>s includes data escrow requirements. IRT members in attendance at the 28 February IRT meeting and discussing the topic on-list confirmed that this program should have data escrow requirements built into it, https://community.icann.org/display/IRT/28+February+2017<https://community.icann.org/display/IRT/28+February+2017> The poll also asks you to identify other sections of the PPAA that you would like to discuss in detail in an upcoming IRT meeting. However, please note that any and all comments related to the PPAA draft are also welcome on the list anytime. Based on the IRT discussion and poll today, we are planning to discuss the following topics in August. Please consult the attached issues list to see specific questions related to this topic: 1 August: Provider Suspension (Issue 13); Contact Information (Issue 9); Reveal Requirements (Issue 10); Code of Conduct (Issue 5); Domain Name Cancellation (Issue 6) 8 August: LEA Framework Specification (Issues 17-19); Data Retention (Issues 4, 23) (This is pending confirmation of PSWG availability to attend this meeting) 15 August: Definitions (Issue 1); Amendment Process (Issues 2, 3, pending updates following 25 July IRT discussion); RAA Synchronization (Issue 21) 22 August: Any issues not reached above, plus additional topics recommended by IRT in poll and on-list 29 August: Data Escrow (Issue 14, pending results of IRT discussions and poll); Labeling (Issue 16) Please send any additional input on the topics discussed this week to the list prior to our next meeting. For next week, please come prepared to discuss the topics identified above under 1 August (and please feel free to share any comments with the group beforehand on-list). Best, Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org>