245 Review Urgent Request response time requirement: IRT Email on 30 June 2023<https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Reso...> 20230711 The updated policy document has been posted on the wiki for your reference. https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Reso... 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. Thanks, Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, June 30, 2023 at 2:46 PM To: "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Subject: [IRT.RegDataPolicy] IRT Task 245: Urgent Request response time requirement due 20230711 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<https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase...>, 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! -- Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet

Em 30 de jun. de 2023, à(s) 18:45, Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:

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 <https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase...>, 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.

Dennis, This brings a lot of US-UK centrism to an ICANN policy. Between the tradition of moving holidays to Mondays and week-long holidays that exist in some countries, there are middle grounds that would be disfavored by such policy, like holidays in Tuesdays (for instance) in the LAC region that ends up being a 4 calendar days holiday, automatically bringing a contracted party from such region out of compliance. Lack of cultural sensitivity, like what I’m seeing here, is not something I would usually expect from ICANN Org. I sometimes saw that from the community, and in most cases Org was useful in educating them. Not this time, it seems.

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.

That is too much reading coffee leaves instead of what is actually written. If you want to back these assertions up, it would help bringing specific transcripts from the EPDP Phase 1 that would in effect list this is a “random” example. Otherwise, I see this as moot. Also, whenever we mention something from an approved GNSO policy to ICANN Org we always get in response something like “not approved by the Board, end of discussion, period”. Why would this time be any different regarding EPDP Phase 2 ? Is ICANN Org willing to set precedent to allow for fast tracking of approved GNSO policies before Board approval ? I would want to use that here and there. Rubens