Thank you for this proposed timeline.

This timeline is based on Urgent Requests arriving from authenticated authorized requestors from law enforcement agencies and other non-gun carrying public safety institutions like CISA and CERTS.

Because an Urgent Request can only arrive from a person or agency that has already been approved to make Urgent Requests, the timeline can and should be simplified.

There should be a protected electronic channel for submitting urgent requests. The response should be immediate, i.e. within a few seconds, also via the protected electronic channel.

There is no need for a review of whether the request is legitimate. That determination was made when the requestor was authorized to make Urgent Requests. (If an unauthorized person or agency feels the need to make an Urgent Request, they need to find someone who is authorized and seek their assistance. If an unauthorized person or agency wishes to become authorized, they should go through the authorization process. The authorization process is not part of this working group's scope but it obviously must exist.)

The response to an Urgent Request should be fully automated and hence seconds.

Implementation of a fully automated receipt and response cycle may take some time. During a transition period, an automated front-end should receive the request and indicate the expected response time.

Complete records of requests and responses should be maintained for review by authorized supervisory personnel. Post-event analysis can focus on whether the process worked properly, whether the data provided satisfied the requestor's need, and whether the request was necessary to resolve the Urgent matter.

The language in the proposed timeline about the maximum number of days(!!) to respond is intended to protect the registrars from a compliance action by ICANN. Their concern is understandable but the approach is wrong. If a response was not provided immediately, something was broken. That proper response is to ask what went wrong and make a determination what remedial action, if any, should be taken to prevent a similar problem in the future.

I will also transpose these comments into the document.

Thanks,

Steve Crocker

On Wed, Apr 16, 2025 at 7:57 PM Isabelle Colas-Adeshina via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:

Dear IRT,

In preparation for our discussion on Wednesday 23 April, please see IRT task 257 which includes a proposed timeline based on recent discussions between the GAC, GNSO Council and ICANN Board. Please use comment mode to add your input /feedback and questions. If identified, the IRT is also welcome to provide alternative proposals for consideration on list. I will use the comments both in the document and on list to help facilitate the discussion next week. As a reminder the proposed language is with the assumption that urgent requests being received are bona fide and have been authenticated.

257

Review Urgent Request Timeline Proposal

20250423

Please let me know if you have any questions. I look forward to seeing you all soon.

Kind Regards

--

Isabelle Colas-Adeshina

Sr. Manager, Policy Research & Stakeholder Programs

Internet Corporation for Assigned Names and Numbers (ICANN)

Los Angeles, CA

www.icann.org

Mobile: +1 310 266 7469

_______________________________________________
IRT.RegDataPolicy mailing list -- irt.regdatapolicy@icann.org
To unsubscribe send an email to irt.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.