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

Caitlin Tubergen caitlin.tubergen at icann.org
Wed Dec 6 19:28:44 UTC 2017


Hi Theo,

Thank you for the question.

Attached, please find the updated draft PPAA, which includes Peter’s comments.  

I will be sending additional materials to the IRT (link to recording, issues list, etc.) shortly.

Kind regards,

Caitlin

 

On 12/6/17, 4:12 AM, "gtheo" <gtheo at xs4all.nl> wrote:

    Hi Caitlin,
    
    Are Peters comments going to be added to the draft so we can discuss 
    them?
    
    Thanks,
    
    Theo
    
    
    
    Caitlin Tubergen schreef op 2017-12-05 04:07 PM:
    > 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
    > _______________________________________________
    > Gdd-gnso-ppsai-impl mailing list
    > Gdd-gnso-ppsai-impl at icann.org
    > https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
    

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PPAA_redline_6Dec.pdf
Type: application/pdf
Size: 838371 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20171206/238b0a9a/PPAA_redline_6Dec-0001.pdf>
-------------- 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/20171206/238b0a9a/smime-0001.p7s>


More information about the Gdd-gnso-ppsai-impl mailing list