<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:12.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:12.0pt;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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
<b>and</b> 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?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">The Edutania Example</span></b><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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
<i>exact same</i> 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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">The GetBaked Example<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif">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.</span><span style="font-family:"Arial",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif">Counter-examples of impact of lack of a time limit on ICANN and the broader ICANN community -
</span></b><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Looking forward to continuing the discussion on today’s call.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Best regards,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">Liz</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:6.0pt"><u><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:black">                               
<o:p></o:p></span></u></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">Elizabeth D. Le<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black">Associate General Counsel, ICANN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black">12025 Waterfront Drive, Suite 300<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black">Los Angeles, CA 90094<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black">Direct Dial:  +1 310 578 8902<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></b></p>
</div>
</body>
</html>