245

Review Urgent Request response time requirement: IRT Email on 30 June 2023

20230711

 

The updated policy document has been posted on the wiki for your reference.

https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Resource+Documents?preview=/124847947/244945954/Post%20PC%20-%20OneDoc%20RegDataPolicy%20(30%20June%202023).pdf

 

You’ll note that the only open item now is the [TBD] Effectivity Date in Section 4.

We’ll tackle this next.

 

One thing I can assure you at this time is that we will no longer consider 1-month transition time as an option.

More on this soon.

 

Dennis Chang

 

Dear IRT,

 

Thank you for supporting the Registration Data Policy Implementation. We have successfully worked together as one Implementation Team for over 4 years and resolved all issues to date. We have one requirement remaining to complete the policy: the Urgent Requests response time. 

 

For those of you who attended the ICANN77 session, you will note that there are two strongly-held positions on this topic. Some members of the IRT, particularly the Contracted Parties, believe the response timeline should be two business days in recognition of business realities associated with responding to requests and the potential consequences of unlawfully releasing personal data. Other members of the IRT, including the IPC, BC, ALAC, and GAC representatives, believe the requirement should be 24 hours in recognition of the urgency associated with this narrowly-tailored class of requests, e.g., a life is threatened. 

 

After hearing from many of you via email and in person in Washington, D.C., we are proposing a compromise position between these two timelines. The proposed compromise timeline comes directly from the consensus recommendation from the EPDP Phase 2 Final Report, Recommendation 10.2, which provides a timeline of 1 business day, not to exceed 3 calendar days. (Please see p. 42 of the Final Report.) The EPDP Phase 1 WG did not have time to discuss the timeline requirement and left it to the Implementation Team. The EPDP Phase 2 WG, however, did spend the time to come to this recommendation language. Accordingly, it is an acceptable solution to those participating in EPDP WG and GNSO Council that approved it.  

 

For those of you who participated in the EPDP Phase 2 deliberations, you may remember that no one was particularly happy with this compromise. That working group ultimately agreed, though, that this language struck an appropriate compromise between the business realities of the contracted parties and the occasional urgent needs of the data by those that needs to resolve time critical issues. By including one business day instead of 24 hours, this language recognizes the business realities for some of the smaller business models in the ICANN community. The inclusion of “not to exceed 3 calendar days” recognizes the concern that some national holidays may span multiple days and result in week(s)-long office closures, and urgent requests must be acted on sooner than that.

 

It is particularly important to us that we stay consistent within EPDP Phases. EPDP Phase 2 Implementation MUST be “1 business day, not to exceed 3 calendar days” because that is clearly in the recommendation language. There were no brackets used. In EPDP Phase 1 recommendation the brackets were used to indicate that this is an example only and was not meant to be part of the recommendation language: “[less than X business days].” If X was the variable that was meant to be determined by the Implementation Team, we would have seen, “less than [X] business days” as a clear recommendation language. If the ICANN Board ultimately adopts the SSAD recommendations (either as is or modified), we need to avoid inconsistencies, including situations where a requestor will receive a different response timeline depending on which method they use to reach out to the registrar. The original EPDP was meant to be one policy. It was due to time constraints that the policy scope was separated into two phases. 

 

While the “1 business day, not to exceed 3 calendar days“ requirement may not be exactly what everyone in the Implementation Team wanted, ICANN org, as the entity responsible for implementing Board adopted policy recommendations, plans to proceed with this compromise timeline because we believe this compromise meets the intent of the policy recommendation: recognizing the need for timely responses to a narrowly-tailored class of urgent requests but also considering the business realities associated with responding to such requests and the potential consequences of unlawfully releasing personal data. We plan to move forward with this compromise timeline unless there is an alternative compromise solution from the IRT that can receive the support of everyone in the Implementation Team.  Please review this language and come prepared to discuss at our next meeting on 12 July 2023. It would be helpful for interested groups to talk to each other before 12 July 2023. 

 

Below is the language we plan to incorporate in the final policy document with your support.

 

Policy Language in Section 10.6 is revised: 

 

For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, within no more than one (1) business day 24 hours two (2) business days. Should the one (1) business day include weekends, holidays or other office closures, the response time MUST NOT exceed three (3) calendar days.

 

If responding to an Urgent Request for Lawful Disclosure is complex, or a large number are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) calendar business day from the date of receipt of the Urgent Request for Lawful Disclosure, provided it gives notice to the requestor within the response time period defined in the previous section. 24 hours two (2) business days and explains the need for an extension of time. 

 

 

Please note that this review is being issued as an IRT Task 245 due on 11 July 2023.

If you complete your task earlier and are supportive of this compromised solution, please do reply with your support!