Hello team,
Thank you for a
thoughtful and productive call today. I want to take a moment to
recap my input and address some of what we discussed.
1. Urgent requests
are already being handled.
We should understand what
problems or gaps exist in the current process to ensure
that these are addressed by our implementation of this Policy
recommendation. Can someone on the requestor side
provide more information on that?
Agreed. We definitely need to understand the problems and gaps. Let's start with some data on the actual Urgent Requests. And let's have data from both the Requestors and the Registrars.
2. We must consider
the practical aspects of the implementation.
There is a requirement
in the Registration Data Policy that the Registrar and Registry
Operator must publish the mechanism and process for submitting
Disclosure Requests. If Urgent requests are to be properly
triaged they would need to go through a separate path, and
that separate path must not be public or it will be misused.
Strongly agree. If there is wording in existing contracts or policies that suggests these points of contact must be publicly available, they should be removed or amended.
Perhaps we should
consider having ICANN maintain two lists: one of authenticated
LEA requestors (with jurisdiction), and one of registrar contact
points (with jurisdiction); in Urgent cases the authenticated
LEA person would be able to access the registrar's emergency
disclosure point of contact.
Yes, this is the right idea, but more is required. Is knowing the jurisdictions of both the requesting LEA and the registrar enough? Probably not. The registrar also needs to know that the requesting LEA can be trusted to adhere to the rules of use and protection of the data. For example, if the request comes from the FBI or one of the LEAs the FBI will vouch for and is presented to a U.S. registrar, we expect the registrar will respond affirmatively and quickly. On the other hand, if the request comes from a U.S. LEA that the FBI does not vouch for, the registrar will likely refuse, engage the FBI or initiate some sort of dialog before deciding whether or not to respond affirmatively.
For requests from approved LEAs to registrars in compatible jurisdictions, it should be possible to process the request with (a) minimum labor, (b) minimum delay, and (c) minimum risk. What's required is an automated, protected pathway for requests to come from approved LEAs to registrars. There are several choices on how to design and implement this, all of which will work, some with an ICANN operated system as part of the path, e.g. the way RDRS is in the path between requestors and registrars today for regular requests, and some without an ICANN operated system in the path. (ICANN can still be part of the vetting process but it need not -- and to be clear about my own view, should not -- be in the operational pathway.)
3. Scope of the IRT
Isabelle raised a
reasonable question of scope; we've been asked to work on the
timeline, and the method for submitting requests is a separate
thing although (as we agreed on the call) they are related. We
all share the goal of implementing the EPDP Phase 1 Rec 18 in a
functional and useful manner, so to ignore the request
submission process would not achieve this goal. As long as we do
work on a timeline I don't think we are prevented from working
on other related topics.
We can't reasonably work on the timeline until we (a) know what the actual need is and (b) know what's achievable. We're lacking data on the actual need. It was a first class mistake to initiate the original work on this without this, and it's a continuing mistake to proceed as if we can set the timeline without this information. All we have at present is the position of the registrars regarding what they say they're willing to do. That's only part of the overall picture and not sufficient to proceed.
With respect to what's achievable, a fully automated process with pre-approved requestors should permit a request and response within a small number of seconds, i.e. at Internet speeds.
I'll also note that an LEA might need to make repeated queries in the course of handling a single incident, and that the subsequent requests might depend on the data they receive from prior requests.
Also missing from our discussion is the legal status of an Urgent Request. Is it equivalent to, and hence subject to the same rules as, a declaration of Exigent Circumstances? If so, then those rules and the corresponding practices provide helpful guidance in formulating the process for handling Urgent Requests. Alternatively, if Urgent Requests are viewed as qualitatively distinct from declarations of Existent Circumstances, then legal advice relevant to Urgent Requests needs to be developed.
Thanks,
Steve Crocker