[IOT] Timing - Repose Issue

[Elizabeth Le]

During the last IOT meeting, a question was raised as to whether demonstrable harm could come from allowing an IRP to only be limited from when a person believes they have been harmed by an act of ICANN that violated ICANN’s mission, as opposed to including both a limitation on when the harm occurred and when the ICANN Board or org took the act from which the alleged harm occurred. This is really not the question we need answered though.  The better question is: What are the benefits that can be gained from removing finality from any act of ICANN that can’t be achieved through having a reasonable timeframe within which someone can challenge and act of ICANN?

We’ve discussed multiple times the benefits that statutes of limitations on claims bring, such as availability of witnesses, freshness of recollections, documents remaining in existence under relevant documentation retention claims are just some of those benefits. Within ICANN, we have been working to promote accountability, addressing issues in a more timely fashion.  Our system of contracts for gTLDs is based upon the unique commercial arrangement that Registry Operators and Registrars agree that the ICANN community can change their contracts at any time through the passage of Consensus Policies, even if not all contracted parties agree to the change. Consistency, predictability and coherency are essential to ICANN’s legitimacy.

To be clear, ICANN org concurs that acts of the ICANN Board or org that are outside of mission are not appropriate and should not stand.  That fundamental notion is not in dispute. That does not, however, mean that the IRP is always the appropriate mechanism to hold ICANN accountable to its mission.  As we’ve noted before, there are other mechanisms – both formal and informal – to bring ICANN into compliance with its mission.  The IOT is not challenged with making the IRP the ultimate accountability measure; the IOT is challenged with developing rules, aligned with principles of international arbitration, that allow the IRP to operate as anticipated under ICANN’s Bylaws.

Prior to 2016, the IRP always included an outside time for filing based on the time of the ICANN act – a time period that was often less than 90 days, as it was based on the publication of ICANN Board minutes evidencing the act.

Here are some thoughts on the stress tests proposed before the last meeting and how they are served – or not – through the inclusion of an outer time-limit to file.

The Edutania Example

In the fifth year of a program run by ICANN (after community consultation), the implementation of the program expands into a new territory.  A company there alleges that it is materially harmed by that implementation, and that the program being implemented is not consistent with ICANN’s mission.  The example as written suggested that the IRP could only be effective if it was allowed to challenge the very introduction of the program (five years prior), as opposed to timing it from the introduction of the program into the new territory where the injury was alleged to occur.

If the program as implemented in the fifth year is determined to be against the Bylaws, how is that not a sufficient outcome for the IRP claimant?  It is the exact same outcome that would be reached for that claimant whether they are challenging a 5-year old program as opposed to a new implementation. The IRP Panel does not have the power to award monetary damages, or to direct a different outcome.  ICANN’s conduct would still be challenged, and the IRP declaration would have the same precedential effect.

The GetBaked Example

With all respect to the creativity of the author of the hypothetical, the hypothetical is taking the purpose and premise of the IRP fully out of scope.  The IRP itself is about achieving consistent and coherent outcomes within ICANN – bringing predictable outcomes to ICANN’s work.  Where the hypothetical suggests years of failure of consistency or coherency in ICANN – and across the entirety of the ICANN system - the IRP is not the place where the wrongs are best righted. Building the IRP procedures on such corner cases is not the way to solve this example.

Let’s assume the IRP goes forward – what’s the outcome? A declaration that the ICANN Board violated the Bylaws in adopting a policy; or a declaration that the ICANN org implemented policy in a manner that violated the Bylaws.  The IRP Panel cannot order a full revocation of the policy, though that might be a choice that the ICANN Board takes in applying the Panel declaration. Neither the ICANN Board nor the IRP Panel can grant the domain name back to the claimant. Getting this hypothetical policy off the books would, of course, be good, but that’s not really the solution, because the policy itself isn’t really the issue.  In that situation, an ultra vires policy is the symptom of a more fully broken system that failed at every step of the way, a system that isn’t capable of being repaired in an IRP. This example isn’t a stress test of the IRP; it’s a stress test of ICANN. The IOT’s mandate is not that broad.

Counter-examples of impact of lack of a time limit on ICANN and the broader ICANN community - We’ve discussed these impacts before.  See attached a note that was circulated in 2017 that discusses issues such as the purposes of the IRP and impact to contracts and the ICANN community where waiting is encouraged.

Looking forward to continuing the discussion on today’s call.

Best regards,
Liz

Elizabeth D. Le
Associate General Counsel, ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
Direct Dial:  +1 310 578 8902




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/iot/attachments/20201201/f3196b05/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Timing-Repose-Email-to-IOT-11-May-2017.pdf
Type: application/pdf
Size: 105348 bytes
Desc: Timing-Repose-Email-to-IOT-11-May-2017.pdf
URL: <http://mm.icann.org/pipermail/iot/attachments/20201201/f3196b05/Timing-Repose-Email-to-IOT-11-May-2017-0001.pdf>