Re: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins)
Amy, Following our F2F discussion on Sunday, many of us have continuing and renewed concerns regarding the LEA spec, in particular the high priority disclosure framework and Section 4.2. After much discussion and many options being put to staff, 4.1.2 has devolved to a “compromise” which is basically the exact same language we started with 6 months ago, with the exception of adding “in accordance with Section 4.2.” As such, we are very concerned that the LEA Spec as written creates a presumption of disclosure and means to bypass due process. Additionally, it is important to remember that this is an accreditation program for ALL Privacy/Proxy Providers around the globe. That means that LEA requests come from LEA in all sorts of countries, and the language in the accreditation agreement need to reflect that. We cannot take an American-centric view. We need to bolster the language in 4.2 to better protect the rights of the Provider and its customers. Therefore, if we are to consider/accept the current proposed high priority language, namely: “Where a disclosure request has been categorized as High Priority, this must be actioned within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” Then the following amendments must be made to Section 4.2 (new language in bold below): 4.2. Disclosure: 4.2.1. Within the applicable timeframe for a request’s Priority Level, Provider will disclose to the LEA Requestor, using a secure mechanism (this must be defined), the Requested Information it holds [associated with] the account. 4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including without limitations any of the following: 4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification; 4.2.2.2. If disclosure would lead to a contravention of applicable law; or 4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer. 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. 4.2.2.5. Where Provider has not been able to verify the identity of the LEA Requestor. (We also need to determine how Providers can best verify the identity of the requestor in a timely fashion. This can at times be very time consuming.) 4.2.2.6. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded. 4.2.3. If disclosure is refused by Provider, Provider must provide written notice (which may be by electronic communication) to the LEA Requestor setting for Provider’s specific reasons for refusing to disclose. Such notice must be provided by Provider to the LEA Requestor prior to any Customer notification by Provider, irrespective of the reason for refusal. 4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2. 4.2.5. For all refusals made in accordance with the policy and requirements herein, Provider must accept and give due consideration to the LEA Requestor’s requests for reconsideration of the refusal to disclose. 4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level. Finally, I believe you were wanting to know if it was acceptable to have Escrow separate from the PPAA. I believe that is the case for the RAA, so I do not see an issue with having it separate from the PPAA. Sara sara bockey sr. policy manager | GoDaddy™ sbockey@godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Amy Bivins <amy.bivins@icann.org> Reply-To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Date: Sunday, March 11, 2018 at 6:24 PM To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Subject: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins) Dear Colleagues, Attached you will find a document that a member of the finance team will be discussing during our session starting in a few minutes. In addition, you’ll be hearing an update about ongoing discussions between registrar and PSWG members of the IRT related to the draft LEA disclosure framework specification. This language was discussed informally among a smaller group this afternoon. Registrar and PSWG members of the IRT appear to be nearing agreement on a proposal for presentation to the IRT that would include a 24-hour time frame for provider responses to high priority LEA requests, with some additional requirements for documentation demonstrating that the request is high priority. The updated draft language for Section 4.1.2 for further discussion (deletions shown as strikeouts, additions in blue) is currently: * “Where a disclosure request has been categorized as High Priority, this must be actioned responded to within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” In addition, staff was asked to provide suggestions for additional details that can be specified about what goes into a High Priority requests. Staff has proposed the following as a starting point. * “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”. (Note: Section 2.1 is the section that lists all the details currently needed for a request.) We will be discussing these during the session and soliciting further feedback on the list afterward. 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>
All - I need some time to review and digest this, but my first reaction is that this is a good attempt to find a working compromise. That said, there is one provision that is mildly problematic: 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. The whole point of the emergency request is that there is not enough time to get any kind of court order. If there was time to get a court order, we would just go get it. This provision would effectively render the high priority disclosure meaningless. Also, I was kind of hoping that rather than just denying requests outright, if the provider finds some problem, there could be a discussion between the provider and the Requestor about what those problems are and whether we can rectify them. I don’t know whether that can be incorporated in the draft but I hope that was an underlying assumption that I just missed in this quick review (while listening to the timeline discussion in San Juan). Finally, I don’t understand the bit about providers giving the LEA Requestor a written response. First, that seems slow in a situation where speed is critical (unless by “in writing” you mean “by email or text”). If you are going to deny the request, it would be good to do so in time to see if we can fix the issue and/or to work other avenues of investigation. Second, as noted above, that sounds like a final decision will be made without any consultation with the Requestor to try and fix the request. Thanks for taking the time to work on this with us and being willing to compromise. Best, Peter Roman Senior Counsel Computer Crime & Intellectual Property Section Criminal Division U.S. Department of Justice 1301 New York Ave.<x-apple-data-detectors://7>, NW Washington, DC 20530 (202) 305-1323 peter.roman@usdoj.gov<mailto:peter.roman@usdoj.gov> On Mar 15, 2018, at 12:30 PM, Sara Bockey <sbockey@godaddy.com<mailto:sbockey@godaddy.com>> wrote: Amy, Following our F2F discussion on Sunday, many of us have continuing and renewed concerns regarding the LEA spec, in particular the high priority disclosure framework and Section 4.2. After much discussion and many options being put to staff, 4.1.2 has devolved to a “compromise” which is basically the exact same language we started with 6 months ago, with the exception of adding “in accordance with Section 4.2.” As such, we are very concerned that the LEA Spec as written creates a presumption of disclosure and means to bypass due process. Additionally, it is important to remember that this is an accreditation program for ALL Privacy/Proxy Providers around the globe. That means that LEA requests come from LEA in all sorts of countries, and the language in the accreditation agreement need to reflect that. We cannot take an American-centric view. We need to bolster the language in 4.2 to better protect the rights of the Provider and its customers. Therefore, if we are to consider/accept the current proposed high priority language, namely: “Where a disclosure request has been categorized as High Priority, this must be actioned within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” Then the following amendments must be made to Section 4.2 (new language in bold below): 4.2. Disclosure: 4.2.1. Within the applicable timeframe for a request’s Priority Level, Provider will disclose to the LEA Requestor, using a secure mechanism (this must be defined), the Requested Information it holds [associated with] the account. 4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including without limitations any of the following: 4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification; 4.2.2.2. If disclosure would lead to a contravention of applicable law; or 4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer. 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. 4.2.2.5. Where Provider has not been able to verify the identity of the LEA Requestor. (We also need to determine how Providers can best verify the identity of the requestor in a timely fashion. This can at times be very time consuming.) 4.2.2.6. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded. 4.2.3. If disclosure is refused by Provider, Provider must provide written notice (which may be by electronic communication) to the LEA Requestor setting for Provider’s specific reasons for refusing to disclose. Such notice must be provided by Provider to the LEA Requestor prior to any Customer notification by Provider, irrespective of the reason for refusal. 4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2. 4.2.5. For all refusals made in accordance with the policy and requirements herein, Provider must accept and give due consideration to the LEA Requestor’s requests for reconsideration of the refusal to disclose. 4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level. Finally, I believe you were wanting to know if it was acceptable to have Escrow separate from the PPAA. I believe that is the case for the RAA, so I do not see an issue with having it separate from the PPAA. Sara sara bockey sr. policy manager | GoDaddy™ sbockey@godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. 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 <amy.bivins@icann.org<mailto:amy.bivins@icann.org>> Reply-To: "gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Date: Sunday, March 11, 2018 at 6:24 PM To: "gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Subject: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins) Dear Colleagues, Attached you will find a document that a member of the finance team will be discussing during our session starting in a few minutes. In addition, you’ll be hearing an update about ongoing discussions between registrar and PSWG members of the IRT related to the draft LEA disclosure framework specification. This language was discussed informally among a smaller group this afternoon. Registrar and PSWG members of the IRT appear to be nearing agreement on a proposal for presentation to the IRT that would include a 24-hour time frame for provider responses to high priority LEA requests, with some additional requirements for documentation demonstrating that the request is high priority. The updated draft language for Section 4.1.2 for further discussion (deletions shown as strikeouts, additions in blue) is currently: * “Where a disclosure request has been categorized as High Priority, this must be actioned responded to within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” In addition, staff was asked to provide suggestions for additional details that can be specified about what goes into a High Priority requests. Staff has proposed the following as a starting point. * “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”. (Note: Section 2.1 is the section that lists all the details currently needed for a request.) We will be discussing these during the session and soliciting further feedback on the list afterward. 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> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
Hi everyone, I suggest a couple of tweaks to the text amendments proposed by Sara, to provide further clarity: 4.2.2.4. Where a court order/warrant/subpoena is legally required and Requestor was unable or unwilling to provide the same; I think 4.2.6. is covered in 4.2.2 (it was certainly intended to achieve this, so maybe these two could be combined with something like: 4.2.2. If disclosure would lead to a contravention of applicable law, or require the Provider to act outside of due legal process within its required jurisdiction, irrespective of Priority Level. I’m not sure about the inclusion of 4.2.2.6. If the intent is to give the ability of the Provider to challenge the veracity of Request when appropriate legal authority (court order etc) has been provided I disagree, as I believe the judicial process should ultimately determine the veracity and legality of the prosecution’s evidential case, and I think it is a dangerous thing to shift the responsibility to the Provider to make such determinations. If the intent is to challenge the accuracy of the request, such as the domain name in question has been incorrectly spelt, or the privacy registration is not held with the Provider, then this should be covered in 4.2.2.1 and 4.2.3. Kind regards, Nick Nick Shorey Phone: +44 (0) 7552 455 988 Email: lists@nickshorey.com Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin Web: www.nickshorey.com
On 15 Mar 2018, at 17:08, Roman, Peter (CRM) <Peter.Roman@usdoj.gov> wrote:
All -
I need some time to review and digest this, but my first reaction is that this is a good attempt to find a working compromise.
That said, there is one provision that is mildly problematic:
4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same.
The whole point of the emergency request is that there is not enough time to get any kind of court order. If there was time to get a court order, we would just go get it. This provision would effectively render the high priority disclosure meaningless.
Also, I was kind of hoping that rather than just denying requests outright, if the provider finds some problem, there could be a discussion between the provider and the Requestor about what those problems are and whether we can rectify them. I don’t know whether that can be incorporated in the draft but I hope that was an underlying assumption that I just missed in this quick review (while listening to the timeline discussion in San Juan).
Finally, I don’t understand the bit about providers giving the LEA Requestor a written response. First, that seems slow in a situation where speed is critical (unless by “in writing” you mean “by email or text”). If you are going to deny the request, it would be good to do so in time to see if we can fix the issue and/or to work other avenues of investigation. Second, as noted above, that sounds like a final decision will be made without any consultation with the Requestor to try and fix the request.
Thanks for taking the time to work on this with us and being willing to compromise.
Best,
Peter Roman
Senior Counsel Computer Crime & Intellectual Property Section Criminal Division U.S. Department of Justice 1301 New York Ave. <x-apple-data-detectors://7>, NW Washington, DC 20530 (202) 305-1323 peter.roman@usdoj.gov <mailto:peter.roman@usdoj.gov>
On Mar 15, 2018, at 12:30 PM, Sara Bockey <sbockey@godaddy.com <mailto:sbockey@godaddy.com>> wrote:
Amy,
Following our F2F discussion on Sunday, many of us have continuing and renewed concerns regarding the LEA spec, in particular the high priority disclosure framework and Section 4.2.
After much discussion and many options being put to staff, 4.1.2 has devolved to a “compromise” which is basically the exact same language we started with 6 months ago, with the exception of adding “in accordance with Section 4.2.” As such, we are very concerned that the LEA Spec as written creates a presumption of disclosure and means to bypass due process. Additionally, it is important to remember that this is an accreditation program for ALL Privacy/Proxy Providers around the globe. That means that LEA requests come from LEA in all sorts of countries, and the language in the accreditation agreement need to reflect that. We cannot take an American-centric view. We need to bolster the language in 4.2 to better protect the rights of the Provider and its customers. Therefore, if we are to consider/accept the current proposed high priority language, namely:
“Where a disclosure request has been categorized as High Priority, this must be actioned within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.”
Then the following amendments must be made to Section 4.2 (new language in bold below):
4.2. Disclosure:
4.2.1. Within the applicable timeframe for a request’s Priority Level, Provider will disclose to the LEA Requestor, using a secure mechanism (this must be defined), the Requested Information it holds [associated with] the account.
4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including without limitations any of the following:
4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification; 4.2.2.2. If disclosure would lead to a contravention of applicable law; or 4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer. 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. 4.2.2.5. Where Provider has not been able to verify the identity of the LEA Requestor. (We also need to determine how Providers can best verify the identity of the requestor in a timely fashion. This can at times be very time consuming.) 4.2.2.6. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded.
4.2.3. If disclosure is refused by Provider, Provider must provide written notice (which may be by electronic communication) to the LEA Requestor setting for Provider’s specific reasons for refusing to disclose. Such notice must be provided by Provider to the LEA Requestor prior to any Customer notification by Provider, irrespective of the reason for refusal.
4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2.
4.2.5. For all refusals made in accordance with the policy and requirements herein, Provider must accept and give due consideration to the LEA Requestor’s requests for reconsideration of the refusal to disclose.
4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level.
Finally, I believe you were wanting to know if it was acceptable to have Escrow separate from the PPAA. I believe that is the case for the RAA, so I do not see an issue with having it separate from the PPAA.
Sara
sara bockey sr. policy manager | GoDaddy™ sbockey@godaddy.com <mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey
This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.
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 <amy.bivins@icann.org <mailto:amy.bivins@icann.org>> Reply-To: "gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>> Date: Sunday, March 11, 2018 at 6:24 PM To: "gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>> Subject: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins)
Dear Colleagues, <>
Attached you will find a document that a member of the finance team will be discussing during our session starting in a few minutes.
In addition, you’ll be hearing an update about ongoing discussions between registrar and PSWG members of the IRT related to the draft LEA disclosure framework specification. This language was discussed informally among a smaller group this afternoon. Registrar and PSWG members of the IRT appear to be nearing agreement on a proposal for presentation to the IRT that would include a 24-hour time frame for provider responses to high priority LEA requests, with some additional requirements for documentation demonstrating that the request is high priority.
The updated draft language for Section 4.1.2 for further discussion (deletions shown as strikeouts, additions in blue) is currently: “Where a disclosure request has been categorized as High Priority, this must beactioned responded to within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.”
In addition, staff was asked to provide suggestions for additional details that can be specified about what goes into a High Priority requests. Staff has proposed the following as a starting point. “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”. (Note: Section 2.1 is the section that lists all the details currently needed for a request.)
We will be discussing these during the session and soliciting further feedback on the list afterward.
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/>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org <mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl <https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org <mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl <https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>
Thanks, everyone, for your continued work on this. Sara and other registrars in the group, what do you think about the issues/edits raised by Peter and Nick? I know it had been an incredibly busy week for those of you at ICANN61. It’s not expected that resolution must be reached on this this week. It’s clear that both sides are willing to continue working toward a compromise and hopefully we can pick this up on the list next week and wrap this up in our next meeting. With respect to the other major topic discussed this week, I’ll get you additional information as soon as I can regarding the fees discussion. Safe travels to everyone who attended ICANN61! Best, Amy Sent from my iPhone On Mar 15, 2018, at 1:36 PM, Nick Shorey <lists@nickshorey.com<mailto:lists@nickshorey.com>> wrote: Hi everyone, I suggest a couple of tweaks to the text amendments proposed by Sara, to provide further clarity: 4.2.2.4. Where a court order/warrant/subpoena is legally required and Requestor was unable or unwilling to provide the same; I think 4.2.6. is covered in 4.2.2 (it was certainly intended to achieve this, so maybe these two could be combined with something like: 4.2.2. If disclosure would lead to a contravention of applicable law, or require the Provider to act outside of due legal process within its required jurisdiction, irrespective of Priority Level. I’m not sure about the inclusion of 4.2.2.6. If the intent is to give the ability of the Provider to challenge the veracity of Request when appropriate legal authority (court order etc) has been provided I disagree, as I believe the judicial process should ultimately determine the veracity and legality of the prosecution’s evidential case, and I think it is a dangerous thing to shift the responsibility to the Provider to make such determinations. If the intent is to challenge the accuracy of the request, such as the domain name in question has been incorrectly spelt, or the privacy registration is not held with the Provider, then this should be covered in 4.2.2.1 and 4.2.3. Kind regards, Nick Nick Shorey Phone: +44 (0) 7552 455 988 Email: lists@nickshorey.com<mailto:lists@nickshorey.com> Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> Web: www.nickshorey.com<http://www.nickshorey.com> On 15 Mar 2018, at 17:08, Roman, Peter (CRM) <Peter.Roman@usdoj.gov<mailto:Peter.Roman@usdoj.gov>> wrote: All - I need some time to review and digest this, but my first reaction is that this is a good attempt to find a working compromise. That said, there is one provision that is mildly problematic: 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. The whole point of the emergency request is that there is not enough time to get any kind of court order. If there was time to get a court order, we would just go get it. This provision would effectively render the high priority disclosure meaningless. Also, I was kind of hoping that rather than just denying requests outright, if the provider finds some problem, there could be a discussion between the provider and the Requestor about what those problems are and whether we can rectify them. I don’t know whether that can be incorporated in the draft but I hope that was an underlying assumption that I just missed in this quick review (while listening to the timeline discussion in San Juan). Finally, I don’t understand the bit about providers giving the LEA Requestor a written response. First, that seems slow in a situation where speed is critical (unless by “in writing” you mean “by email or text”). If you are going to deny the request, it would be good to do so in time to see if we can fix the issue and/or to work other avenues of investigation. Second, as noted above, that sounds like a final decision will be made without any consultation with the Requestor to try and fix the request. Thanks for taking the time to work on this with us and being willing to compromise. Best, Peter Roman Senior Counsel Computer Crime & Intellectual Property Section Criminal Division U.S. Department of Justice 1301 New York Ave.<x-apple-data-detectors://7>, NW Washington, DC 20530 (202) 305-1323 peter.roman@usdoj.gov<mailto:peter.roman@usdoj.gov> On Mar 15, 2018, at 12:30 PM, Sara Bockey <sbockey@godaddy.com<mailto:sbockey@godaddy.com>> wrote: Amy, Following our F2F discussion on Sunday, many of us have continuing and renewed concerns regarding the LEA spec, in particular the high priority disclosure framework and Section 4.2. After much discussion and many options being put to staff, 4.1.2 has devolved to a “compromise” which is basically the exact same language we started with 6 months ago, with the exception of adding “in accordance with Section 4.2.” As such, we are very concerned that the LEA Spec as written creates a presumption of disclosure and means to bypass due process. Additionally, it is important to remember that this is an accreditation program for ALL Privacy/Proxy Providers around the globe. That means that LEA requests come from LEA in all sorts of countries, and the language in the accreditation agreement need to reflect that. We cannot take an American-centric view. We need to bolster the language in 4.2 to better protect the rights of the Provider and its customers. Therefore, if we are to consider/accept the current proposed high priority language, namely: “Where a disclosure request has been categorized as High Priority, this must be actioned within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” Then the following amendments must be made to Section 4.2 (new language in bold below): 4.2. Disclosure: 4.2.1. Within the applicable timeframe for a request’s Priority Level, Provider will disclose to the LEA Requestor, using a secure mechanism (this must be defined), the Requested Information it holds [associated with] the account. 4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including without limitations any of the following: 4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification; 4.2.2.2. If disclosure would lead to a contravention of applicable law; or 4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer. 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. 4.2.2.5. Where Provider has not been able to verify the identity of the LEA Requestor. (We also need to determine how Providers can best verify the identity of the requestor in a timely fashion. This can at times be very time consuming.) 4.2.2.6. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded. 4.2.3. If disclosure is refused by Provider, Provider must provide written notice (which may be by electronic communication) to the LEA Requestor setting for Provider’s specific reasons for refusing to disclose. Such notice must be provided by Provider to the LEA Requestor prior to any Customer notification by Provider, irrespective of the reason for refusal. 4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2. 4.2.5. For all refusals made in accordance with the policy and requirements herein, Provider must accept and give due consideration to the LEA Requestor’s requests for reconsideration of the refusal to disclose. 4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level. Finally, I believe you were wanting to know if it was acceptable to have Escrow separate from the PPAA. I believe that is the case for the RAA, so I do not see an issue with having it separate from the PPAA. Sara sara bockey sr. policy manager | GoDaddy™ sbockey@godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. 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 <amy.bivins@icann.org<mailto:amy.bivins@icann.org>> Reply-To: "gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Date: Sunday, March 11, 2018 at 6:24 PM To: "gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Subject: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins) Dear Colleagues, Attached you will find a document that a member of the finance team will be discussing during our session starting in a few minutes. In addition, you’ll be hearing an update about ongoing discussions between registrar and PSWG members of the IRT related to the draft LEA disclosure framework specification. This language was discussed informally among a smaller group this afternoon. Registrar and PSWG members of the IRT appear to be nearing agreement on a proposal for presentation to the IRT that would include a 24-hour time frame for provider responses to high priority LEA requests, with some additional requirements for documentation demonstrating that the request is high priority. The updated draft language for Section 4.1.2 for further discussion (deletions shown as strikeouts, additions in blue) is currently: * “Where a disclosure request has been categorized as High Priority, this must beactioned responded to within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” In addition, staff was asked to provide suggestions for additional details that can be specified about what goes into a High Priority requests. Staff has proposed the following as a starting point. * “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”. (Note: Section 2.1 is the section that lists all the details currently needed for a request.) We will be discussing these during the session and soliciting further feedback on the list afterward. 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/> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl <signature.asc> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
Hi Amy, After further discussions within our Legal team, we (GoDaddy) have determined that committing to a 24-hour response time for high priority requests is unworkable. Our P/P team does not, nor have they ever, provide a 24/7 service. Additionally, while GoDaddy, the registrar, has received “imminent threat to life” requests, our P/P team has not. Building this capability in our P/P would be a significant undertaking. And if this poses a challenge for a company as large as GoDaddy, it will be significantly more difficult for smaller providers. As Peter has often reminded us, this agreement is between the Provider and ICANN, and LEA is not a party to it. While we understand and respect the needs of LEAs, and GoDaddy has a long-standing track record of cooperating with high-priority investigations, that doesn’t mean we can accept unreasonable contract terms. Accordingly, after much consideration and internal discussions with our P/P and Legal teams, GoDaddy believes one business day is the appropriate response time for High Priority requests. Additionally, our Legal team has determined the following amendments are needed to the Specification. Section 2.1, the following provisions must be added: 2.1.9 A clear statement that the domain name or URL involved is part of an official investigation. 2.1.10 A clear statement that Law Enforcement/Gov’t Agency has attempted to contact the relevant parties and has no other means of identifying them. I would also like clarification to understand where ICANN staff is intending to include this proposed language: “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”. Was staff intending it to be part of 2.1 or appear elsewhere? Regarding Nick’s comment on previously proposed language in 4.2.2.6, which states “Where Provider has found, after investigation, that LEA Requestor’s request is not well founded”, the intent to not to challenge the veracity of the request, but rather a reflection of the language that appears in Section 3.18.2 of the RAA. Regarding Nick’s comments on the proposed language in 4.2.2.4 and 4.2.6, while I appreciate his efforts to combine the two provisions as a compromise, 4.2.6 must stand on its own. I am willing to remove “Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same” as a reason for refusal under 4.2.2, but the proposed 4.2.6 language must remain as is. In light of the above, 4.2.2 and 4.2.6 would read as follows: 4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including without limitations any of the following: 4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification; 4.2.2.2. If disclosure would lead to a contravention of applicable law; or 4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer. 4.2.2.4. Where Provider has not been able to verify the identity of the LEA Requestor, in accordance with 3.2.2. 4.2.2.5. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded. 4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level. Finally, I want to ensure that Staff includes a provision regarding exceptional circumstances, as previously discussed, to address acts of nature, or other circumstances outside of the provider’s control. Perhaps we can address this in Section 4.2.4, for example: 4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2. 4.2.4.1. Exceptional circumstances to include delays caused by acts of nature. Sara sara bockey sr. policy manager | GoDaddy™ sbockey@godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Amy Bivins <amy.bivins@icann.org> Reply-To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Date: Thursday, March 15, 2018 at 12:44 PM To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Subject: Re: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins) Thanks, everyone, for your continued work on this. Sara and other registrars in the group, what do you think about the issues/edits raised by Peter and Nick? I know it had been an incredibly busy week for those of you at ICANN61. It’s not expected that resolution must be reached on this this week. It’s clear that both sides are willing to continue working toward a compromise and hopefully we can pick this up on the list next week and wrap this up in our next meeting. With respect to the other major topic discussed this week, I’ll get you additional information as soon as I can regarding the fees discussion. Safe travels to everyone who attended ICANN61! Best, Amy Sent from my iPhone On Mar 15, 2018, at 1:36 PM, Nick Shorey <lists@nickshorey.com<mailto:lists@nickshorey.com>> wrote: Hi everyone, I suggest a couple of tweaks to the text amendments proposed by Sara, to provide further clarity: 4.2.2.4. Where a court order/warrant/subpoena is legally required and Requestor was unable or unwilling to provide the same; I think 4.2.6. is covered in 4.2.2 (it was certainly intended to achieve this, so maybe these two could be combined with something like: 4.2.2. If disclosure would lead to a contravention of applicable law, or require the Provider to act outside of due legal process within its required jurisdiction, irrespective of Priority Level. I’m not sure about the inclusion of 4.2.2.6. If the intent is to give the ability of the Provider to challenge the veracity of Request when appropriate legal authority (court order etc) has been provided I disagree, as I believe the judicial process should ultimately determine the veracity and legality of the prosecution’s evidential case, and I think it is a dangerous thing to shift the responsibility to the Provider to make such determinations. If the intent is to challenge the accuracy of the request, such as the domain name in question has been incorrectly spelt, or the privacy registration is not held with the Provider, then this should be covered in 4.2.2.1 and 4.2.3. Kind regards, Nick Nick Shorey Phone: +44 (0) 7552 455 988 Email: lists@nickshorey.com<mailto:lists@nickshorey.com> Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin<http://www.linkedin.com/in/nicklinkedin> Web: www.nickshorey.com<http://www.nickshorey.com> On 15 Mar 2018, at 17:08, Roman, Peter (CRM) <Peter.Roman@usdoj.gov<mailto:Peter.Roman@usdoj.gov>> wrote: All - I need some time to review and digest this, but my first reaction is that this is a good attempt to find a working compromise. That said, there is one provision that is mildly problematic: 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. The whole point of the emergency request is that there is not enough time to get any kind of court order. If there was time to get a court order, we would just go get it. This provision would effectively render the high priority disclosure meaningless. Also, I was kind of hoping that rather than just denying requests outright, if the provider finds some problem, there could be a discussion between the provider and the Requestor about what those problems are and whether we can rectify them. I don’t know whether that can be incorporated in the draft but I hope that was an underlying assumption that I just missed in this quick review (while listening to the timeline discussion in San Juan). Finally, I don’t understand the bit about providers giving the LEA Requestor a written response. First, that seems slow in a situation where speed is critical (unless by “in writing” you mean “by email or text”). If you are going to deny the request, it would be good to do so in time to see if we can fix the issue and/or to work other avenues of investigation. Second, as noted above, that sounds like a final decision will be made without any consultation with the Requestor to try and fix the request. Thanks for taking the time to work on this with us and being willing to compromise. Best, Peter Roman Senior Counsel Computer Crime & Intellectual Property Section Criminal Division U.S. Department of Justice 1301 New York Ave.<x-apple-data-detectors://7>, NW Washington, DC 20530 (202) 305-1323 peter.roman@usdoj.gov<mailto:peter.roman@usdoj.gov> On Mar 15, 2018, at 12:30 PM, Sara Bockey <sbockey@godaddy.com<mailto:sbockey@godaddy.com>> wrote: Amy, Following our F2F discussion on Sunday, many of us have continuing and renewed concerns regarding the LEA spec, in particular the high priority disclosure framework and Section 4.2. After much discussion and many options being put to staff, 4.1.2 has devolved to a “compromise” which is basically the exact same language we started with 6 months ago, with the exception of adding “in accordance with Section 4.2.” As such, we are very concerned that the LEA Spec as written creates a presumption of disclosure and means to bypass due process. Additionally, it is important to remember that this is an accreditation program for ALL Privacy/Proxy Providers around the globe. That means that LEA requests come from LEA in all sorts of countries, and the language in the accreditation agreement need to reflect that. We cannot take an American-centric view. We need to bolster the language in 4.2 to better protect the rights of the Provider and its customers. Therefore, if we are to consider/accept the current proposed high priority language, namely: “Where a disclosure request has been categorized as High Priority, this must be actioned within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” Then the following amendments must be made to Section 4.2 (new language in bold below): 4.2. Disclosure: 4.2.1. Within the applicable timeframe for a request’s Priority Level, Provider will disclose to the LEA Requestor, using a secure mechanism (this must be defined), the Requested Information it holds [associated with] the account. 4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including without limitations any of the following: 4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification; 4.2.2.2. If disclosure would lead to a contravention of applicable law; or 4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer. 4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same. 4.2.2.5. Where Provider has not been able to verify the identity of the LEA Requestor. (We also need to determine how Providers can best verify the identity of the requestor in a timely fashion. This can at times be very time consuming.) 4.2.2.6. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded. 4.2.3. If disclosure is refused by Provider, Provider must provide written notice (which may be by electronic communication) to the LEA Requestor setting for Provider’s specific reasons for refusing to disclose. Such notice must be provided by Provider to the LEA Requestor prior to any Customer notification by Provider, irrespective of the reason for refusal. 4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2. 4.2.5. For all refusals made in accordance with the policy and requirements herein, Provider must accept and give due consideration to the LEA Requestor’s requests for reconsideration of the refusal to disclose. 4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level. Finally, I believe you were wanting to know if it was acceptable to have Escrow separate from the PPAA. I believe that is the case for the RAA, so I do not see an issue with having it separate from the PPAA. Sara sara bockey sr. policy manager | GoDaddy™ sbockey@godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. 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 <amy.bivins@icann.org<mailto:amy.bivins@icann.org>> Reply-To: "gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Date: Sunday, March 11, 2018 at 6:24 PM To: "gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Subject: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins) Dear Colleagues, Attached you will find a document that a member of the finance team will be discussing during our session starting in a few minutes. In addition, you’ll be hearing an update about ongoing discussions between registrar and PSWG members of the IRT related to the draft LEA disclosure framework specification. This language was discussed informally among a smaller group this afternoon. Registrar and PSWG members of the IRT appear to be nearing agreement on a proposal for presentation to the IRT that would include a 24-hour time frame for provider responses to high priority LEA requests, with some additional requirements for documentation demonstrating that the request is high priority. The updated draft language for Section 4.1.2 for further discussion (deletions shown as strikeouts, additions in blue) is currently: * “Where a disclosure request has been categorized as High Priority, this must beactioned responded to within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.” In addition, staff was asked to provide suggestions for additional details that can be specified about what goes into a High Priority requests. Staff has proposed the following as a starting point. * “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”. (Note: Section 2.1 is the section that lists all the details currently needed for a request.) We will be discussing these during the session and soliciting further feedback on the list afterward. 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/> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl <signature.asc> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
From an operational perspective, there are many providers that will not be able to comply with the 24-hour deadline. If GoDaddy will struggle, for
Hi there Amy, Endurance supports GoDaddy’s comments above. In order to appropriately reflect the rights and obligations of privacy/proxy providers globally, the contractual language cannot include or imply a presumption of disclosure and must provide adequate refusals in the manner Sara suggests in Sections 4.2.2 and 4.2.6. It would be irresponsible of this IRT to create a program requiring a contracted party to violate local law or ignore due process within its jurisdiction. Endurance supports Sara’s recommended language above. the small provider it’s hard to imagine it’s anything but impossible. And while many providers, including Endurance, endeavor to respond to LEA as quickly as possible in urgent situations within the confines of the law, there will be many such occasions where 24 hours is unworkable. It is irresponsible for this IRT to push for a program that will not be operationally viable or effective, or that will establish contractual requirements where the sole effect is to create lack of compliance for most if not all providers. Endurance agrees that one business day is an appropriate response requirement. Regards, Eric *Eric Rokobauer* Sr. Registrar Compliance Manager | Endurance International Group 10 Corporate Drive, Suite 300, Burlington MA 01803 T - 781.852.3445 <(781)%20852-3445> E - eric.rokobauer@endurance.com On Thu, Mar 22, 2018 at 4:30 PM, Sara Bockey <sbockey@godaddy.com> wrote:
Hi Amy,
After further discussions within our Legal team, we (GoDaddy) have determined that committing to a 24-hour response time for high priority requests is unworkable.
Our P/P team does not, nor have they ever, provide a 24/7 service. Additionally, while GoDaddy, the registrar, has received “imminent threat to life” requests, our P/P team has not. Building this capability in our P/P would be a significant undertaking. And if this poses a challenge for a company as large as GoDaddy, it will be significantly more difficult for smaller providers.
As Peter has often reminded us, this agreement is between the Provider and ICANN, and LEA is not a party to it. While we understand and respect the needs of LEAs, and GoDaddy has a long-standing track record of cooperating with high-priority investigations, that doesn’t mean we can accept unreasonable contract terms. Accordingly, after much consideration and internal discussions with our P/P and Legal teams, GoDaddy believes one business day is the appropriate response time for High Priority requests.
Additionally, our Legal team has determined the following amendments are needed to the Specification.
Section 2.1, the following provisions must be added:
*2.1.9 A clear statement that the domain name or URL involved is part of an official investigation.*
*2.1.10 A clear statement that Law Enforcement/Gov’t Agency has attempted to contact the relevant parties and has no other means of identifying them.*
I would also like clarification to understand where ICANN staff is intending to include this proposed language:
“For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”.
Was staff intending it to be part of 2.1 or appear elsewhere?
Regarding Nick’s comment on previously proposed language in 4.2.2.6, which states “Where Provider has found, after investigation, that LEA Requestor’s request is not well founded”, the intent to not to challenge the veracity of the request, but rather a reflection of the language that appears in Section 3.18.2 of the RAA.
Regarding Nick’s comments on the proposed language in 4.2.2.4 and 4.2.6, while I appreciate his efforts to combine the two provisions as a compromise, 4.2.6 must stand on its own. I am willing to remove “Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same” as a reason for refusal under 4.2.2, but the proposed 4.2.6 language must remain as is.
In light of the above, 4.2.2 and 4.2.6 would read as follows:
4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including *without limitations* any of the following:
4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification;
4.2.2.2. If disclosure would lead to a contravention of applicable law; or
4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer.
*4.2.2.4. Where Provider has not been able to verify the identity of the LEA Requestor, in accordance with 3.2.2.*
*4.2.2.5. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded.*
*4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level.*
Finally, I want to ensure that Staff includes a provision regarding exceptional circumstances, as previously discussed, to address acts of nature, or other circumstances outside of the provider’s control. Perhaps we can address this in Section 4.2.4, for example:
4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2.
*4.2.4.1. Exceptional circumstances to include delays caused by acts of nature.*
Sara
*sara bockey*
*sr. policy manager | **Go**Daddy™*
*sbockey@godaddy.com <sbockey@godaddy.com> 480-366-3616 <(480)%20366-3616>*
*skype: sbockey*
*This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.*
*From: *Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Amy Bivins <amy.bivins@icann.org> *Reply-To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org
*Date: *Thursday, March 15, 2018 at 12:44 PM *To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> *Subject: *Re: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins)
Thanks, everyone, for your continued work on this.
Sara and other registrars in the group, what do you think about the issues/edits raised by Peter and Nick?
I know it had been an incredibly busy week for those of you at ICANN61. It’s not expected that resolution must be reached on this this week. It’s clear that both sides are willing to continue working toward a compromise and hopefully we can pick this up on the list next week and wrap this up in our next meeting.
With respect to the other major topic discussed this week, I’ll get you additional information as soon as I can regarding the fees discussion.
Safe travels to everyone who attended ICANN61!
Best,
Amy
Sent from my iPhone
On Mar 15, 2018, at 1:36 PM, Nick Shorey <lists@nickshorey.com> wrote:
Hi everyone,
I suggest a couple of tweaks to the text amendments proposed by Sara, to provide further clarity:
*4.2.2.4. Where a court order/warrant/subpoena is legally required and Requestor was unable or unwilling to provide the same;*
I think 4.2.6. is covered in 4.2.2 (it was certainly intended to achieve this, so maybe these two could be combined with something like:
*4.2.2. If disclosure would lead to a contravention of applicable law, or require the Provider to act outside of due legal process within its required jurisdiction, irrespective of Priority Level.*
I’m not sure about the inclusion of 4.2.2.6. If the intent is to give the ability of the Provider to challenge the veracity of Request when appropriate legal authority (court order etc) has been provided I disagree, as I believe the judicial process should ultimately determine the veracity and legality of the prosecution’s evidential case, and I think it is a dangerous thing to shift the responsibility to the Provider to make such determinations.
If the intent is to challenge the accuracy of the request, such as the domain name in question has been incorrectly spelt, or the privacy registration is not held with the Provider, then this should be covered in 4.2.2.1 and 4.2.3.
Kind regards,
Nick
Nick Shorey Phone: +44 (0) 7552 455 988 <+44%207552%20455988> Email: lists@nickshorey.com <lists@nickshorey.com> Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin Web: www.nickshorey.com
On 15 Mar 2018, at 17:08, Roman, Peter (CRM) <Peter.Roman@usdoj.gov> wrote:
All -
I need some time to review and digest this, but my first reaction is that this is a good attempt to find a working compromise.
That said, there is one provision that is mildly problematic:
*4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same.*
The whole point of the emergency request is that there is not enough time to get any kind of court order. If there was time to get a court order, we would just go get it. This provision would effectively render the high priority disclosure meaningless.
Also, I was kind of hoping that rather than just denying requests outright, if the provider finds some problem, there could be a discussion between the provider and the Requestor about what those problems are and whether we can rectify them. I don’t know whether that can be incorporated in the draft but I hope that was an underlying assumption that I just missed in this quick review (while listening to the timeline discussion in San Juan).
Finally, I don’t understand the bit about providers giving the LEA Requestor a written response. First, that seems slow in a situation where speed is critical (unless by “in writing” you mean “by email or text”). If you are going to deny the request, it would be good to do so in time to see if we can fix the issue and/or to work other avenues of investigation. Second, as noted above, that sounds like a final decision will be made without any consultation with the Requestor to try and fix the request.
Thanks for taking the time to work on this with us and being willing to compromise.
Best,
Peter Roman
Senior Counsel Computer Crime & Intellectual Property Section
Criminal Division U.S. Department of Justice 1301 New York Ave., NW
Washington, DC 20530 (202) 305-1323
peter.roman@usdoj.gov
On Mar 15, 2018, at 12:30 PM, Sara Bockey <sbockey@godaddy.com> wrote:
Amy,
Following our F2F discussion on Sunday, many of us have continuing and renewed concerns regarding the LEA spec, in particular the high priority disclosure framework and Section 4.2.
After much discussion and many options being put to staff, 4.1.2 has devolved to a “compromise” which is basically the exact same language we started with 6 months ago, with the exception of adding “in accordance with Section 4.2.” As such, we are very concerned that the LEA Spec as written creates a presumption of disclosure and means to bypass due process. Additionally, it is important to remember that this is an accreditation program for ALL Privacy/Proxy Providers around the globe. That means that LEA requests come from LEA in all sorts of countries, and the language in the accreditation agreement need to reflect that. We cannot take an American-centric view. We need to bolster the language in 4.2 to better protect the rights of the Provider and its customers. Therefore, if we are to consider/accept the current proposed high priority language, namely:
“Where a disclosure request has been categorized as High Priority, this must be actioned within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.”
Then the following amendments must be made to Section 4.2 (new language in bold below):
4.2. Disclosure:
4.2.1. Within the applicable timeframe for a request’s Priority Level, Provider will disclose to the LEA Requestor, using a secure mechanism (*this must be defined*), the Requested Information it holds [associated with] the account.
4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including *without limitations* any of the following:
4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification;
4.2.2.2. If disclosure would lead to a contravention of applicable law; or
4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer.
*4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same.*
*4.2.2.5. Where Provider has not been able to verify the identity of the LEA Requestor. (We also need to determine how Providers can best verify the identity of the requestor in a timely fashion. This can at times be very time consuming.)*
*4.2.2.6. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded.*
4.2.3. If disclosure is refused by Provider, Provider must provide written notice (which may be by electronic communication) to the LEA Requestor setting for Provider’s specific reasons for refusing to disclose. Such notice must be provided by Provider to the LEA Requestor prior to any Customer notification by Provider, irrespective of the reason for refusal.
4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2.
4.2.5. For all refusals made in accordance with the policy and requirements herein, Provider must accept and give due consideration to the LEA Requestor’s requests for reconsideration of the refusal to disclose.
*4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level.*
Finally, I believe you were wanting to know if it was acceptable to have Escrow separate from the PPAA. I believe that is the case for the RAA, so I do not see an issue with having it separate from the PPAA.
Sara
*sara bockey*
*sr. policy manager | **Go**Daddy™*
*sbockey@godaddy.com <sbockey@godaddy.com> 480-366-3616 <(480)%20366-3616>*
*skype: sbockey*
*This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.*
*From: *Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Amy Bivins <amy.bivins@icann.org> *Reply-To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org
*Date: *Sunday, March 11, 2018 at 6:24 PM *To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> *Subject: *[Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins)
Dear Colleagues,
Attached you will find a document that a member of the finance team will be discussing during our session starting in a few minutes.
In addition, you’ll be hearing an update about ongoing discussions between registrar and PSWG members of the IRT related to the draft LEA disclosure framework specification. This language was discussed informally among a smaller group this afternoon. Registrar and PSWG members of the IRT appear to be nearing agreement on a proposal for presentation to the IRT that would include a 24-hour time frame for provider responses to high priority LEA requests, with some additional requirements for documentation demonstrating that the request is high priority.
The updated draft language for Section 4.1.2 for further discussion (deletions shown as strikeouts, additions in blue) is currently:
- “Where a disclosure request has been categorized as High Priority, this must beactioned responded to within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.”
In addition, staff was asked to provide suggestions for additional details that can be specified about what goes into a High Priority requests. Staff has proposed the following as a starting point.
- “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”.
(Note: Section 2.1 is the section that lists all the details currently needed for a request.)
We will be discussing these during the session and soliciting further feedback on the list afterward.
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 <(202)%20249-7551>
Fax: +1 (202) 789-0104 <(202)%20789-0104>
Email: amy.bivins@icann.org
www.icann.org
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
<signature.asc>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
We support these additions as well. It is good to know it is not only us smaller providers that feel this request is unworkable. Best, Volker Am 02.04.2018 um 21:45 schrieb Eric Rokobauer:
Hi there Amy,
Endurance supports GoDaddy’s comments above. In order to appropriately reflect the rights and obligations of privacy/proxy providers globally, the contractual language cannot include or imply a presumption of disclosure and must provide adequate refusals in the manner Sara suggests in Sections 4.2.2 and 4.2.6. It would be irresponsible of this IRT to create a program requiring a contracted party to violate local law or ignore due process within its jurisdiction. Endurance supports Sara’s recommended language above.
From an operational perspective, there are many providers that will not be able to comply with the 24-hour deadline. If GoDaddy will struggle, for the small provider it’s hard to imagine it’s anything but impossible. And while many providers, including Endurance, endeavor to respond to LEA as quickly as possible in urgent situations within the confines of the law, there will be many such occasions where 24 hours is unworkable. It is irresponsible for this IRT to push for a program that will not be operationally viable or effective, or that will establish contractual requirements where the sole effect is to create lack of compliance for most if not all providers. Endurance agrees that one business day is an appropriate response requirement.
Regards, Eric
*/Eric Rokobauer/* Sr. Registrar Compliance Manager | Endurance International Group 10 Corporate Drive, Suite 300, Burlington MA 01803 T - 781.852.3445 <tel:%28781%29%20852-3445> E -eric.rokobauer@endurance.com <mailto:eric.rokobauer@endurance.com>
On Thu, Mar 22, 2018 at 4:30 PM, Sara Bockey <sbockey@godaddy.com <mailto:sbockey@godaddy.com>> wrote:
Hi Amy,
After further discussions within our Legal team, we (GoDaddy) have determined that committing to a 24-hour response time for high priority requests is unworkable.
Our P/P team does not, nor have they ever, provide a 24/7 service. Additionally, while GoDaddy, the registrar, has received “imminent threat to life” requests, our P/P team has not. Building this capability in our P/P would be a significant undertaking. And if this poses a challenge for a company as large as GoDaddy, it will be significantly more difficult for smaller providers.
As Peter has often reminded us, this agreement is between the Provider and ICANN, and LEA is not a party to it. While we understand and respect the needs of LEAs, and GoDaddy has a long-standing track record of cooperating with high-priority investigations, that doesn’t mean we can accept unreasonable contract terms. Accordingly, after much consideration and internal discussions with our P/P and Legal teams, GoDaddy believes one business day is the appropriate response time for High Priority requests.
Additionally, our Legal team has determined the following amendments are needed to the Specification.
Section 2.1, the following provisions must be added:
*2.1.9 A clear statement that the domain name or URL involved is part of an official investigation.*
*2.1.10 A clear statement that Law Enforcement/Gov’t Agency has attempted to contact the relevant parties and has no other means of identifying them.*
I would also like clarification to understand where ICANN staff is intending to include this proposed language:
“For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”.
Was staff intending it to be part of 2.1 or appear elsewhere?
Regarding Nick’s comment on previously proposed language in 4.2.2.6, which states “Where Provider has found, after investigation, that LEA Requestor’s request is not well founded”, the intent to not to challenge the veracity of the request, but rather a reflection of the language that appears in Section 3.18.2 of the RAA.
Regarding Nick’s comments on the proposed language in 4.2.2.4 and 4.2.6, while I appreciate his efforts to combine the two provisions as a compromise, 4.2.6 must stand on its own. I am willing to remove “Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same” as a reason for refusal under 4.2.2, but the proposed 4.2.6 language must remain as is.
In light of the above, 4.2.2 and 4.2.6 would read as follows:
4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including *without limitations* any of the following:
4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification;
4.2.2.2. If disclosure would lead to a contravention of applicable law; or
4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer.
*4.2.2.4. Where Provider has not been able to verify the identity of the LEA Requestor, in accordance with 3.2.2.*
*4.2.2.5. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded.*
*4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level.*
Finally, I want to ensure that Staff includes a provision regarding exceptional circumstances, as previously discussed, to address acts of nature, or other circumstances outside of the provider’s control. Perhaps we can address this in Section 4.2.4, for example:
4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2.
*4.2.4.1. Exceptional circumstances to include delays caused by acts of nature.*
Sara
*sara bockey*
*sr. policy manager | **Go**Daddy^™ *
*sbockey@godaddy.com <mailto:sbockey@godaddy.com> 480-366-3616 <tel:%28480%29%20366-3616>*
*skype: sbockey*
//
/This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments./
*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 <amy.bivins@icann.org <mailto:amy.bivins@icann.org>> *Reply-To: *"gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>> *Date: *Thursday, March 15, 2018 at 12:44 PM *To: *"gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>> *Subject: *Re: [Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins)
Thanks, everyone, for your continued work on this.
Sara and other registrars in the group, what do you think about the issues/edits raised by Peter and Nick?
I know it had been an incredibly busy week for those of you at ICANN61. It’s not expected that resolution must be reached on this this week. It’s clear that both sides are willing to continue working toward a compromise and hopefully we can pick this up on the list next week and wrap this up in our next meeting.
With respect to the other major topic discussed this week, I’ll get you additional information as soon as I can regarding the fees discussion.
Safe travels to everyone who attended ICANN61!
Best,
Amy
Sent from my iPhone
On Mar 15, 2018, at 1:36 PM, Nick Shorey <lists@nickshorey.com <mailto:lists@nickshorey.com>> wrote:
Hi everyone,
I suggest a couple of tweaks to the text amendments proposed by Sara, to provide further clarity:
/4.2.2.4. Where a court order/warrant/subpoena is legally required and Requestor was unable or unwilling to provide the same;/
I think 4.2.6. is covered in 4.2.2 (it was certainly intended to achieve this, so maybe these two could be combined with something like:
/4.2.2. If disclosure would lead to a contravention of applicable law, or require the Provider to act outside of due legal process within its required jurisdiction, irrespective of Priority Level./
I’m not sure about the inclusion of 4.2.2.6. If the intent is to give the ability of the Provider to challenge the veracity of Request when appropriate legal authority (court order etc) has been provided I disagree, as I believe the judicial process should ultimately determine the veracity and legality of the prosecution’s evidential case, and I think it is a dangerous thing to shift the responsibility to the Provider to make such determinations.
If the intent is to challenge the accuracy of the request, such as the domain name in question has been incorrectly spelt, or the privacy registration is not held with the Provider, then this should be covered in 4.2.2.1 and 4.2.3.
Kind regards,
Nick
Nick Shorey Phone: +44 (0) 7552 455 988 <tel:+44%207552%20455988> Email: lists@nickshorey.com <mailto:lists@nickshorey.com> Skype: nick.shorey Twitter: @nickshorey LinkedIn: www.linkedin.com/in/nicklinkedin <http://www.linkedin.com/in/nicklinkedin> Web: www.nickshorey.com <http://www.nickshorey.com>
On 15 Mar 2018, at 17:08, Roman, Peter (CRM) <Peter.Roman@usdoj.gov <mailto:Peter.Roman@usdoj.gov>> wrote:
All -
I need some time to review and digest this, but my first reaction is that this is a good attempt to find a working compromise.
That said, there is one provision that is mildly problematic:
*4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same.*
The whole point of the emergency request is that there is not enough time to get any kind of court order. If there was time to get a court order, we would just go get it. This provision would effectively render the high priority disclosure meaningless.
Also, I was kind of hoping that rather than just denying requests outright, if the provider finds some problem, there could be a discussion between the provider and the Requestor about what those problems are and whether we can rectify them. I don’t know whether that can be incorporated in the draft but I hope that was an underlying assumption that I just missed in this quick review (while listening to the timeline discussion in San Juan).
Finally, I don’t understand the bit about providers giving the LEA Requestor a written response. First, that seems slow in a situation where speed is critical (unless by “in writing” you mean “by email or text”). If you are going to deny the request, it would be good to do so in time to see if we can fix the issue and/or to work other avenues of investigation. Second, as noted above, that sounds like a final decision will be made without any consultation with the Requestor to try and fix the request.
Thanks for taking the time to work on this with us and being willing to compromise.
Best,
Peter Roman
Senior Counsel Computer Crime & Intellectual Property Section
Criminal Division U.S. Department of Justice 1301 New York Ave., NW
Washington, DC 20530 (202) 305-1323 <tel:%28202%29%20305-1323>
peter.roman@usdoj.gov <mailto:peter.roman@usdoj.gov>
On Mar 15, 2018, at 12:30 PM, Sara Bockey <sbockey@godaddy.com <mailto:sbockey@godaddy.com>> wrote:
Amy,
Following our F2F discussion on Sunday, many of us have continuing and renewed concerns regarding the LEA spec, in particular the high priority disclosure framework and Section 4.2.
After much discussion and many options being put to staff, 4.1.2 has devolved to a “compromise” which is basically the exact same language we started with 6 months ago, with the exception of adding “in accordance with Section 4.2.” As such, we are very concerned that the LEA Spec as written creates a presumption of disclosure and means to bypass due process. Additionally, it is important to remember that this is an accreditation program for ALL Privacy/Proxy Providers around the globe. That means that LEA requests come from LEA in all sorts of countries, and the language in the accreditation agreement need to reflect that. We cannot take an American-centric view. We need to bolster the language in 4.2 to better protect the rights of the Provider and its customers. Therefore, if we are to consider/accept the current proposed high priority language, namely:
“Where a disclosure request has been categorized as High Priority, this must be actioned within 24 hours, in accordance with Section 4.2. The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.”
Then the following amendments must be made to Section 4.2 (new language in bold below):
4.2. Disclosure:
4.2.1. Within the applicable timeframe for a request’s Priority Level, Provider will disclose to the LEA Requestor, using a secure mechanism (*/this must be defined/*), the Requested Information it holds [associated with] the account.
4.2.2. Disclosure can be reasonably refused by Provider for reasons consistent with the general policy stated herein, including*without limitations*any of the following:
4.2.2.1. The LEA Requestor failed to provide to Provider information to meet the minimum standard for acceptance as outlined in Section 2 of this Specification;
4.2.2.2. If disclosure would lead to a contravention of applicable law; or
4.2.2.3. Where the Customer has provided, or Provider has found, specific information, facts, or circumstances showing that disclosure will endanger the safety of the Customer.
*4.2.2.4. Where Provider has requested a court order/warrant/subpoena and LEA Requestor was unable or unwilling to provide same.*
*4.2.2.5. Where Provider has not been able to verify the identity of the LEA Requestor. (/We also need to determine how Providers can best verify the identity of the requestor in a timely fashion. This can at times be very time consuming/.)*
*4.2.2.6. Where Provider has found, after investigation, that LEA Requestor’s request is not well founded.*
**
4.2.3. If disclosure is refused by Provider, Provider must provide written notice (which may be by electronic communication) to the LEA Requestor setting for Provider’s specific reasons for refusing to disclose. Such notice must be provided by Provider to the LEA Requestor prior to any Customer notification by Provider, irrespective of the reason for refusal.
4.2.4. In exceptional circumstances, if Provider requires additional time to respond to the LEA Requestor, Provider shall inform the LEA Requestor of the cause of the delay and agree with the LEA Requestor on a new date by which it will provide its response under this Section. 4.2.
4.2.5. For all refusals made in accordance with the policy and requirements herein, Provider must accept and give due consideration to the LEA Requestor’s requests for reconsideration of the refusal to disclose.
*4.2.6. Nothing in Section 4.2 above shall be interpreted nor is it intended to imply the Provider shall forego due process within its applicable jurisdiction to satisfy LEA Requestor’s request, regardless of Priority Level.*
Finally, I believe you were wanting to know if it was acceptable to have Escrow separate from the PPAA. I believe that is the case for the RAA, so I do not see an issue with having it separate from the PPAA.
Sara
*sara bockey*
*sr. policy manager | **Go**Daddy^™ *
*sbockey@godaddy.com <mailto:sbockey@godaddy.com> 480-366-3616 <tel:%28480%29%20366-3616>*
*skype: sbockey*
//
/This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments./
*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 <amy.bivins@icann.org <mailto:amy.bivins@icann.org>> *Reply-To:*"gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>> *Date:*Sunday, March 11, 2018 at 6:24 PM *To:*"gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl@icann.org <mailto:gdd-gnso-ppsai-impl@icann.org>> *Subject:*[Gdd-gnso-ppsai-impl] Discussion items for today's PP IRT face-to-face at ICANN61 (starting in 10 mins)
Dear Colleagues,
Attached you will find a document that a member of the finance team will be discussing during our session starting in a few minutes.
In addition, you’ll be hearing an update about ongoing discussions between registrar and PSWG members of the IRT related to the draft LEA disclosure framework specification. This language was discussed informally among a smaller group this afternoon. Registrar and PSWG members of the IRT appear to be nearing agreement on a proposal for presentation to the IRT that would include a 24-hour time frame for provider responses to high priority LEA requests, with some additional requirements for documentation demonstrating that the request is high priority.
The updated draft language for Section 4.1.2 for further discussion (deletions shown as strikeouts, additions in blue) is currently:
* “Where a disclosure request has been categorized as High Priority, this must beactionedresponded towithin 24 hours,in accordance with Section 4.2.The LEA Requester will detail the threat type and justification for a request with a Priority Level of High Priority.”
In addition, staff was asked to provide suggestions for additional details that can be specified about what goes into a High Priority requests. Staff has proposed the following as a starting point.
* “For High Priority requests, in addition to the requirements specified in Section 2.1.*, LEA Requesters should provide specific information demonstrating that the request is necessary due to an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation”.
(Note: Section 2.1 is the section that lists all the details currently needed for a request.)
We will be discussing these during the session and soliciting further feedback on the list afterward.
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 <tel:%28202%29%20249-7551>
Fax: +1 (202) 789-0104 <tel:%28202%29%20789-0104>
Email:amy.bivins@icann.org<mailto:amy.bivins@icann.org>
www.icann.org<http://www.icann.org/>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>
<signature.asc>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org <mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl <https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
participants (6)
-
Amy Bivins -
Eric Rokobauer -
Nick Shorey -
Roman, Peter (CRM) -
Sara Bockey -
Volker Greimann