Hi all, To Steve's last point -- the legal status of  "Urgent Requests" is indeed missing from the conversation. The situations that would qualify as "Urgent" under the proposed process make them directly analogous to an exigent request under most laws. Thanks, *Sarah Wyld, CIPP/E* Pronouns: she/they Head, Policy & Privacy Tucows #MakingTheInternetBetter swyld@tucows.com /Responses to this email are processed according to the Tucows Privacy Policy <https://www.tucows.com/privacy>/ On 2025-05-27 12:11 p.m., Steve Crocker via IRT.RegDataPolicy wrote:

Sarah,

Thanks very much for your summary.  I agree with the general direction but I think it needs to be strengthened.  See comments below.

Steve

On Wed, May 21, 2025 at 3:30 PM Sarah Wyld via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:

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

Sent by a Verified

sender

_______________________________________________ IRT.RegDataPolicy mailing list --irt.regdatapolicy@icann.org To unsubscribe send an email toirt.regdatapolicy-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.