[Gdd-gnso-ppsai-impl] Discussion document for Tuesday's PP IRT meeting
Theo Geurts
gtheo at xs4all.nl
Sat Mar 24 08:37:44 UTC 2018
Hi Amy,
Yes, I agree with Sara.
Regarding the call without adobe connect, I leave that up to you but
keep in mind you will be going in blind.
Theo
On 23-3-2018 15:37, Amy Bivins wrote:
>
> Thank you, Sara.
>
> I’ve created a new markup of the spec showing the most recent comments
> and proposed edits from Sara Bockey and Nick Shorey (attached). We
> will go through this on Tuesday to determine whether there is
> consensus on any of these edits. If other registrars agree with Sara’s
> position on the 24 hour/1 business day issue, we will flag this as an
> area of disagreement among IRT members and specifically request public
> comments on this.
>
> I’m not sure yet whether we will have Adobe Connect capability
> restored in time for our meeting. If not, we will do the best we can
> with a phone bridge.
>
> Thanks, and have a great weekend.
>
> Amy
>
> *From:* Gdd-gnso-ppsai-impl
> [mailto:gdd-gnso-ppsai-impl-bounces at icann.org] *On Behalf Of *Sara Bockey
> *Sent:* Thursday, March 22, 2018 4:30 PM
> *To:* gdd-gnso-ppsai-impl at icann.org
> *Subject:* Re: [Gdd-gnso-ppsai-impl] Discussion items for today's PP
> IRT face-to-face at ICANN61 (starting in 10 mins)
>
> 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 at godaddy.com <mailto:sbockey at 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 at icann.org
> <mailto:gdd-gnso-ppsai-impl-bounces at icann.org>> on behalf of Amy
> Bivins <amy.bivins at icann.org <mailto:amy.bivins at icann.org>>
> *Reply-To: *"gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>" <gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>>
> *Date: *Thursday, March 15, 2018 at 12:44 PM
> *To: *"gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>" <gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at 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 at nickshorey.com
> <mailto:lists at 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 at nickshorey.com <mailto:lists at 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 at usdoj.gov <mailto:Peter.Roman at 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 at usdoj.gov <mailto:peter.roman at usdoj.gov>
>
>
> On Mar 15, 2018, at 12:30 PM, Sara Bockey <sbockey at godaddy.com
> <mailto:sbockey at 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 at godaddy.com <mailto:sbockey at 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 at icann.org
> <mailto:gdd-gnso-ppsai-impl-bounces at icann.org>> on behalf
> of Amy Bivins <amy.bivins at icann.org
> <mailto:amy.bivins at icann.org>>
> *Reply-To:*"gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>"
> <gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>>
> *Date:*Sunday, March 11, 2018 at 6:24 PM
> *To:*"gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>"
> <gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at 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
>
> Fax: +1 (202) 789-0104
>
> Email:amy.bivins at icann.org<mailto:amy.bivins at icann.org>
>
> www.icann.org<http://www.icann.org/>
>
> _______________________________________________
> Gdd-gnso-ppsai-impl mailing list
> Gdd-gnso-ppsai-impl at icann.org<mailto:Gdd-gnso-ppsai-impl at icann.org>
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
> _______________________________________________
> Gdd-gnso-ppsai-impl mailing list
> Gdd-gnso-ppsai-impl at icann.org<mailto:Gdd-gnso-ppsai-impl at icann.org>
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
> <signature.asc>
>
> _______________________________________________
> Gdd-gnso-ppsai-impl mailing list
> Gdd-gnso-ppsai-impl at icann.org<mailto:Gdd-gnso-ppsai-impl at icann.org>
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
>
>
> _______________________________________________
> Gdd-gnso-ppsai-impl mailing list
> Gdd-gnso-ppsai-impl at icann.org
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20180324/783fc4b7/attachment-0001.html>
More information about the Gdd-gnso-ppsai-impl
mailing list