[Gdd-gnso-ppsai-impl] FW: [Ext] RE: Agenda + Updated Draft PPAA with IRT comments

Tue Dec 5 15:07:01 UTC 2017

From: "Roman, Peter (CRM)" <Peter.Roman at usdoj.gov>
Date: Tuesday, December 5, 2017 at 5:40 AM
To: Caitlin Tubergen <caitlin.tubergen at icann.org>, "gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org>
Subject: [Ext] RE: Agenda + Updated Draft PPAA with IRT comments 

Good morning all –

I have a few additional comments on the draft:

Overall – this agreement seems to misunderstand the point of having a high priority request mechanism.  High priority requests are usually emergencies where victims are moments away from danger.  Not requiring immediate responses to these requests renders them moot.  A request that is answered within 24 hours, but 20 hours after the victim is dead, does not respect the importance of the request or the imminence of the danger. 

3.12.2 - If the abuse contact point is not monitored 24/7, how are providers going to respond to high priority requests in time?

SPECIFICATION 5: LAW ENFORCEMENT AUTHORITY DISCLOSURE FRAMEWORK SPECIFICATION

3.1 – This is the same issue as for 3.12.2 in the main bod of the agreement, if the point of contact is not required to be available 24/7, it defeats the purpose of the high priority requests.

3.2.1 – This part of the receipt process combined with 4.1 creates a two day window before providers have to even address whether a request is high priority, again defeating the purpose of having a high priority request.

4.1.1 – By waiting to respond until after the Receipt Process is complete, which can take up to two days under 3.2.1, the agreement renders the high priority request provisions moot.

4.1.2 – Responding to high priority requests within 24 hours is not sufficient.  A request that is answered within 24 hours, but 20 hours after the victim is dead, does not respect the importance of the request or the imminence of the danger.  High priority requests need to be responded to more or less immediately.

4.3.2 – The Provider should be required to disclose changes to the timeframe for notification of the Customer to LEA Requestors with current requests (i.e., “should” should be “must”).  If the Customer is a target, notifying the Customer without alerting LEA can lead to the Customer destroying evidence, fleeing, or even threatening or killing informants who led law enforcement to the Customer’s account in the first place. 

5.1 – I do not understand the purpose of this provision.  LEA is not a party to this agreement and the agreement has no ability to bind LEA actions if the Provider fails to respond to a request. 

6.2 – I do not understand the purpose of this provision either.  LEA is not a party to this agreement and the agreement has no ability to bind LEA use of the evidence provided by the Provider.

Peter Roman

Senior Counsel

Computer Crime & Intellectual Property Section

Criminal Division

Department of Justice

1301 New York Ave., NW
Washington, DC 20530
(202) 305-1323

peter.roman at usdoj.gov

From: Caitlin Tubergen [mailto:caitlin.tubergen at icann.org] 
Sent: Monday, December 4, 2017 11:36 PM
To: gdd-gnso-ppsai-impl at icann.org
Cc: Roman, Peter (CRM) <Peter.Roman at CRM.USDOJ.GOV>
Subject: Agenda + Updated Draft PPAA with IRT comments 

Greetings, Colleagues.

Thank you for all of your input on the draft Privacy and Proxy Service Provider Accreditation Agreement (“PPAA”). 

Attached, you will find an updated PPAA, which incorporates the comments received.  I am also working on updating the issues list and will be distributing the list some time tomorrow.

For tomorrow’s call, we can begin by discussing some of the high-level issues some of the IRT members have raised.  Specifically:

The concern that the text of the PPAA does not match the WG’s recommendations
The idea of having two PPAAs: one for affiliated providers and one for unaffiliated providers
The IRT’s preferred path forward for dealing with the comments received

Additionally, I’d like to note two things. First, further to Darcy’s message today, the GNSO Council recently voted to move the Transfer Policy (IRTP-C) issue for discussion within the PPSAI IRT.  I believe the Council directed this issue to be discussed during the public comment period.  Darcy, please feel free to add additional context either on the list or on tomorrow’s call.

Lastly, there have been several mentions of GDPR as a potential issue/barrier to the PPSAI implementation.  I would like to note that ICANN has engaged legal experts to analyze the impact the European Union General Data Protection Regulation (“GDPR”) will have on various data processing activities under ICANN policies and contracts. Such policies and contracts require or permit various entities that participate in the gTLD domain name system, including registries and registrars, to collect, create, retain, escrow, and publish a variety of personal data elements related to registry/registrar operations, domain name registrations, and registrants.

The legal review and analysis is being conducted in iterative phases, and ICANN gathered questions from community discussions and submissions to submit to the legal experts for possible discussion in Part 2 of the analysis. One of the questions included the following: “ICANN org is working with the community to develop implementation details for consensus policy recommendations governing the accreditation of privacy and proxy providers. How should GDPR requirements be factored into developing the accreditation process?”  We will certainly keep you apprised of any feedback we receive. 

See you on our call tomorrow.

Kind regards,

Caitlin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20171205/27faa866/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20171205/27faa866/smime-0001.p7s>