Em 13 de jul. de 2023, à(s) 11:21, Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Dear IRT,
Thank you for supporting the IRT call yesterday. You should have received Andrea’s email notification for recording by now. I encourage all to listen and support the final push to resolve the one last outstanding policy requirement: Urgent Request.
Keep in mind it’s Urgent Request vs IRT. IRT is One Team.
We spent most of the call discussing Urgent Request, but it was apparent to me that the IRT needs more time to consider. Some new voices and new ideas came in too. Let’s allocate another two additional weeks for work this out. We can still make our August publication.
Please continue the discussion on the urgent request on the list and provide your inputs including the proposed policy language.
In addition, we will send out a doodle for interested parties to continue a discussion during a dedicated meeting. Interested IRT members can reply to that message. We will arrange a meeting room for these members.
Thus far, there has not been a proposed urgent response solution that is agreeable to the full IRT, and these discussions cannot continue indefinitely. This is why the EPDP Phase 1 team asked us – the implementation team - to make the decision. We therefore encourage you to work together to agree on a solution that everyone can live with – both the urgent requestors and responders. We already heard Request for Reconsideration mentioned and if it must come to that we’ll follow that defined process. However, what I heard from the call is the willingness to reach a compromised solution to avoid such disruption and delay in our implementation.
The option before an RfR is made is to recycle this point thru the policy process. Which would be the likely outcome of an RfR anyways, so if it comes to that, it’s better to avoid it by letting the GNSO reprocess this issue. But it’s curious to have to reach a compromise yet again since one was already reached in policy development, but it seems people that agreed then, are unwilling to move forward with they previously accepted as a compromise.
Please use the next two weeks to reach an agreement. If IRT members are unable to come to an agreement that everyone can live with, ICANN will need to keep the Phase 2 language of “1 business day, not to exceed 3 calendar days” as we believe this is the only solution that demonstrated community support by receiving consensus at GNSO.
Nice, now we will have a precedent to fast-track GNSO-approved policies without Board approval. One other option would be for ICANN to waive 90% of all fees it charges from registrars and registries, so contracted parties can hire around the clock lawyers to decide disclosure requests.
Per Marc A’s suggestion, we may add the additional Phase 2 percentages language to account for concerns with abusive and voluminous requests marked as urgent. percentiles to achieve consistency (see. p. 42 of the EPDP Phase 2 Final Report). We’d like to hear from you on this too.
We have reviewed the latest proposal from the RrSG, submitted by Roger on 10 July 2023, and do not believe it would adequately address the concerns raised during public comment from non-contracted party constituencies. Specifically, it reverts the requirement back to the same (two business days), as the addition of "generally means within 24 hours" would not be relevant for contractual enforcement purposes. By reverting to this standard, the same issues remain (e.g. business days vary by jurisdiction and may result in extensive response time where long business shutdowns may occur, both of which are challenging for enforcement purposes). Thanks to Laureen for pointing this out during the IRT call.
This keeps on giving the US-UK centrism to ICANN. Perhaps letting ICANN handle only US-UK contracted parties and forming a different one would solve that too. Rubens