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, 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