<div dir="ltr"><div><div><div>All,<br><br></div>Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion.<br><br></div>This is particularly relevant to RFP4 (which requests a &quot;Description        
  of        
  how        
  you        
  have        
  tested        
  or        
  evaluated        
  the        
  workability        
  of any        
  new        
  technical        
  or operational        
  methods proposed        
  in this        
  document and        
  how        
  they        
  compare        
  to        
  established arrangements&quot;) and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses).<br><br></div>Greg<br><br><div><div><div><div><div><div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Steve DelBianco</b> <span dir="ltr">&lt;<a href="mailto:sdelbianco@netchoice.org">sdelbianco@netchoice.org</a>&gt;</span><br>Date: Tue, Nov 25, 2014 at 3:24 PM<br>Subject: Stress Tests for IANA transition proposals<br>To: &quot;<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>&quot; &lt;<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>&gt;<br>Cc: Steve Metalitz &lt;<a href="mailto:met@msk.com">met@msk.com</a>&gt;, Tony Holmes &lt;<a href="mailto:tonyarholmes@btinternet.com">tonyarholmes@btinternet.com</a>&gt;, Phil Corwin &lt;<a href="mailto:psc@vlaw-dc.com">psc@vlaw-dc.com</a>&gt;, Aparna Sridhar &lt;<a href="mailto:aparnasridhar@google.com">aparnasridhar@google.com</a>&gt;, &quot;<a href="mailto:skawaguchi@fb.com">skawaguchi@fb.com</a>&quot; &lt;<a href="mailto:skawaguchi@fb.com">skawaguchi@fb.com</a>&gt;, Jonathan Zuck &lt;<a href="mailto:JZuck@actonline.org">JZuck@actonline.org</a>&gt;, Kristina Rosette &lt;<a href="mailto:krosette@cov.com">krosette@cov.com</a>&gt;, Rick Lane &lt;<a href="mailto:RLane@21cf.com">RLane@21cf.com</a>&gt;, Elisa Cooper &lt;<a href="mailto:Elisa.Cooper@markmonitor.com">Elisa.Cooper@markmonitor.com</a>&gt;<br><br><br>



<div style="word-wrap:break-word;font-size:16px;font-family:Calibri,sans-serif;color:rgb(0,0,0)">
<div style="color:rgb(0,0,0)">
<div>
<div>Greg — as you requested on our call today, here are ’stress tests’ from the BC&#39;s  June comments (<a href="http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhancing-ICANN-Accountability-FINAL.pdf" target="_blank">link</a> to comments).   The stress
 tests in a standalone doc are also available at <a href="http://bizconst.org/StressTests" target="_blank">
http://bizconst.org/StressTests</a>  </div>
</div>
</div>
<span>
<div style="word-wrap:break-word;font-size:16px;font-family:Calibri,sans-serif">
<span>
<div style="word-wrap:break-word;font-size:16px;font-family:Calibri,sans-serif">
<span>
<div style="word-wrap:break-word;font-size:16px;font-family:Calibri,sans-serif">
<div style="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">Some of these stress tests relate to general ICANN accountability concerns.  But several are relevant to the IANA role you are looking at for Naming Functions  (Numbers 3, 5, 7, 8, 9, and 10, in red below): </div>
<div style="color:rgb(0,0,0)"><br>
</div>
<div>
<div title="Page 9" style="color:rgb(0,0,0)">
<div>
<div>
<p><span style="font-size:11pt;font-family:&quot;Calibri&quot;">The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs
 its core functions. Although it can be uncomfortable to </span><span style="font-family:Calibri;font-size:11pt">imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios
 that could arise, such as those described below:</span></p>
</div>
</div>
</div>
<div title="Page 10">
<div>
<div>
<ol>
<li style="color:rgb(0,0,0);font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt">Scenario: ICANN unilaterally cancels the </span>
<span style="font-size:11pt;font-style:italic;color:rgb(0,0,255)">Affirmation of Commitments</span><span style="font-size:11pt">, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations
 of an </span><span style="font-size:11pt;font-style:italic">Affirmation </span>
<span style="font-size:11pt">review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the
</span><span style="font-size:11pt;font-style:italic">Affirmation of Commitments</span><span style="font-size:11pt">. If the
</span><span style="font-size:11pt;font-style:italic">Affirmation </span><span style="font-size:11pt">is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with
 a new mechanism, which may or may not include parties external to ICANN. </span>
</p>
</li><li style="color:rgb(0,0,0);font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt">Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN
 opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current
 corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not.
</span></p>
</li><li style="font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt"><font color="#ff0000">Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement
 in the event ICANN could not maintain the necessary qualified technical resources.
</font></span></p>
</li><li style="color:rgb(0,0,0);font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt">Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants,
 registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its
 fees and spending are subject to external accountability. </span></p>
</li><li style="font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt"><font color="#ff0000">Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management
 did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon
 until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability
 mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation.
</font></span></p>
</li><li style="color:rgb(0,0,0);font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt">Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle
 47: “</span><span style="font-size:11pt;font-style:italic">consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection</span><span style="font-size:11pt">.”</span><span style="font-size:7pt;vertical-align:5pt">13
</span><span style="font-size:11pt">But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in </span><span style="font-size:11pt">Singapore
 during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how
 ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus.</span></p>
</li></ol>
</div>
</div>
</div>
<div title="Page 11">
<div>
<div>
<ol start="7">
<li style="font-size:11pt;font-family:Calibri">
<p><font color="#ff0000"><span style="font-size:11pt">Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g.,
</span><span style="font-size:11pt;font-weight:700">.</span><span style="font-size:11pt">corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking
 Twitter. This scenario envisions censorship moving from the edge </span><span style="font-size:11pt;font-style:italic">to the core of the internet
</span><span style="font-size:11pt">– the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS.
</span></font></p>
</li><li style="font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt"><font color="#ff0000">Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction
 from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone?
</font></span></p>
</li><li style="font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt"><font color="#ff0000">Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following
 after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court
 injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction?
</font></span></p>
</li><li style="font-size:11pt;font-family:Calibri">
<p><span style="font-size:11pt"><font color="#ff0000">Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned.
 Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone? </font></span></p>
</li></ol>
</div>
</div>
</div>
</div>
<div>
<div><br>
</div>
</div>
</div>
</span></div>
</span></div>
</span>
</div>

</div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(23,54,93)">Gregory S. Shatan </span></b><b><span style="font-size:8pt;font-family:Symbol;color:rgb(23,54,93)">ï</span></b><b><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(23,54,93)"> </span></b><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(192,80,77)">Abelman Frayne &amp; Schwab</span></b><span style="font-size:12pt;font-family:&quot;Times New Roman&quot;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(23,54,93)">666 Third Avenue </span></b><b><span style="font-size:8pt;font-family:Symbol;color:rgb(23,54,93)">ï</span></b><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(23,54,93)"> New York, NY 10017-5621</span></b><span style="font-size:12pt;font-family:&quot;Times New Roman&quot;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Direct</span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">  </span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+12128859253" style="color:rgb(17,85,204)">212-885-9253</a> <b>| </b></span><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Main</span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy"> </span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+12129499022" style="color:rgb(17,85,204)">212-949-9022</a></span><span style="font-size:12pt;font-family:&quot;Times New Roman&quot;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Fax</span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">  </span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+12129499190" style="color:rgb(17,85,204)">212-949-9190</a> <b>|</b> </span><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Cell </span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+19178166428" style="color:rgb(17,85,204)">917-816-6428</a></span><span style="font-size:12pt;font-family:&quot;Times New Roman&quot;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><i><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy"><a href="mailto:gsshatan@lawabel.com" style="color:rgb(17,85,204)" target="_blank">gsshatan@lawabel.com</a><u></u><u></u></span></i></b></p><p style="margin:0in 0in 0.0001pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><font>ICANN-related: <a href="mailto:gregshatanipc@gmail.com" target="_blank">gregshatanipc@gmail.com</a> </font></b></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><i><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy"><a href="http://www.lawabel.com/" style="color:rgb(17,85,204)" target="_blank">www.lawabel.com</a></span></i></b></p></div></div></div></div>
</div></div></div></div></div></div></div>