PPIRT colleagues, It's been pointed out to me that section 3.3 of the PPAA does not in fact list all the data elements that would have "ordinarily appeared" in publicly accessible RDDS at the time of adoption of this consensus policy; two such elements (e-mail address and telephone number of the customer) are lacking. In the attached v.2 of my suggested revision of section 3.1.2.1 of specification 4, I have added these two elements. My error, and sorry for any confusion. Steve Metalitz From: Metalitz, Steven Sent: Monday, September 17, 2018 11:04 AM To: gdd-gnso-ppsai-impl@icann.org Subject: RE: PP IRT Action Items This Week --- specification 4 PPIRTers, Two points regarding specification 4, the Intellectual Property Disclosure Framework specification. First, as previously discussed on our calls, attached please find a proposed revision to section 3.1.2.1 of this specification, which spells out what the provider should do if it decides to disclose to the requester. This provision as originally drafted refers to disclosing the information "that would ordinarily appear in the publicly accessible Registration Data Directory Service." Since, post-Temp Spec, there is no longer a uniform set of data that "ordinarily appears" in the RDDS for various registrars and registries, this language needs to be updated. The full set of data that the PDP Working Group proposed, and that the GNSO council and ICANN board approved, should be disclosed in response to a successful IPR request corresponds to the data elements listed in section 3.3 of the PPAA (for ready reference I paste these in the attachment as well). At the time that the PDP WG, Council and Board acted, that list was synonymous with what would "ordinarily appear" in RDDS (Whois) for particular non-P/P registrations. Since that is no longer the case, it is important to spell out what the requester can expect to receive as part of a disclosure under this specification, in order to maintain the substance of the approved consensus policy. Second, regarding Amy's question (3) below about the dispute resolution provisions of this specification, while I agree that the title of section 4 of specification 4 can go away, it may be possible to drop the section altogether, or at least to condense it substantially. The background here is a bit complicated. During the negotiation in 2015 of the Illustrative Disclosure Framework (the basis for specification 4 of the PPAA now before us), a lot of effort was spent on developing a dispute resolution mechanism. I believe we ultimately could not reach agreement on such a mechanism, and instead decided to leave this to "other available remedies at law" (as section 4 of specification 4 now begins). We also agreed that for a defined category of disputes (those arising from wrongful disclosure or misuse of disclosed information), requesters would submit to the jurisdiction of specified courts. The second prong of this conclusion is now reflected in the specification as one of the representations requesters must make in order to have their request for disclosure considered (see, sections 2.1.6.3, 2.2.7.4, 2.3.6.3 of the specification). It may be that the only thing we need to say here is in the first sentence of section 4, that nothing precludes the pursuit of available remedies at law when disputes arise. That would certainly include the pursuit of data subject rights under the GDPR to the extent those are applicable. I'd like to study this issue a little further and aim to provide a more definitive proposal by the Friday deadline Amy has set, but wanted to share my preliminary thinking on it. Steve Metalitz From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org<mailto:gdd-gnso-ppsai-impl-bounces@icann.org>> On Behalf Of Amy Bivins Sent: Monday, September 17, 2018 9:40 AM To: gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org> Subject: [Gdd-gnso-ppsai-impl] PP IRT Action Items This Week Dear Colleagues, ICANN org is continuing to review your feedback on the PPAA draft, and I hope to have an update this week as to your specific feedback on the data processing provisions. In the interim, please provide any feedback you have on the following no later than your end of day on Friday, 21 Sept: (1) In Specification 3, do you have any issue with incorporating a definition of action/actioned? We have attempted to clarify the term in Section 3.2.3 (p. 52) to state "action, in accordance with Sections 4.1 and 4.2..." but we believe this could be made more clear by explicitly defining this term. For example, we could add a definition that states that action means "to disclose the Requested Information, to refuse in writing to disclose the Requested Information, and/or to inform the LEA Requester that more time is required to respond to the request." (2) Should we add a new explicit basis for a Provider to reasonably refuse to disclose Requested Information in Specification 3, Section 4.1, where the Provider has a basis for reasonably believing that such Disclosure would violate relevant data protection law? (3) In Specification 4 (p. 62)-should this section title be updated since it doesn't specifically address how to resolve disputes? In addition, does the IRT wish to review the meaning and intent of this section in light of data subject rights in the GDPR, and its relevance to resolving disputes concerning data protection matters? 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>