<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>Hi all</div><div><br></div><div>The discussion about what is in or out of scope is a bit abstract, so I thought I would try and give some short examples that show my concern.&nbsp;</div><div><br></div><div>The five wee wee scenarios below only deal with IANA functions operation.&nbsp;</div><div><br></div><div>Note that the process currently proposed by ICANN gives the Board the role of making sure the final proposal remains within the scope &#8212; and both Scope and Process are open for comment until 8 May.</div><div><br></div><div>These are just some options that come to mind &#8211; I am not trying to argue in favour or against any of these.</div><div><br></div><div>A) Imagine that the transition plan proposes that IANA remain a functionally separate part of ICANN as it is now, with no institutional changes.&nbsp;</div><div>&nbsp;- that&#8217;s in scope</div><div>&nbsp;- it could fly as a proposal</div><div><br></div><div>B) Imagine that the transition plan proposes IANA remains within ICANN, but has an &#8220;IANA Board&#8221; - a committee to which IANA staff report and are accountable to, but that remains within ICANN, uses ICANN corporate services (ICT systems, offices, payroll, etc etc).</div><div>&nbsp;- that&#8217;s in scope</div><div>&nbsp;- it could fly as a proposal</div><div><br></div><div>C) Imagine the plan proposes IANA become a wholly-owned subsidiary company of ICANN, with a Board of Directors appointed by the ICANN NomCom process, but borrowing ICANN corporate services (ICT systems, offices, payroll, etc etc).</div><div>&nbsp;- that's out of scope</div><div>&nbsp;- ICANN&#8217;s board would invalidate it as a possible proposal</div><div><br></div><div>D) Imagine the plan proposes the IANA functions be split, with some operated by ICANN (say the protocol registries, the numbering registry) and some operated by another currently unspecified entity (say the TLD registry).</div><div>&nbsp;- that&#8217;s out of scope</div><div>&nbsp;- ICANN&#8217;s board would invalidate it as a possible proposal</div><div><br></div><div>E) Imagine the plan proposes that IANA be operated by a new entity (e.g. the IGP model), related to its policy authorities (IETF, RIRs, TLDs, ICANN) by strong contracts.</div><div>&nbsp;- that&#8217;s out of scope</div><div>&nbsp;- ICANN&#8217;s board would invalidate it as a proposal</div><div><br></div><div><br></div><div>Now.&nbsp;</div><div><br></div><div>I firmly believe that all of these options should be on the table, and that the benefits and costs of different arrays of the IANA functions, different demands from the IANA customers, different options for protecting the important IANA function, should be on the table.</div><div><br></div><div>And I believe the scope needs to change so that the process we&#8217;re about to undertake &#8211; to develop a transition plan &#8211; keeps ALL options on the table.</div><div><br></div><div>I firmly believe that this community has the wit and the will to move towards a settlement that can work.&nbsp;</div><div><br></div><div>I also firmly believe that ICANN would do itself much credit if it argued the merits of its position in an open process, rather than trying to cut off options it doesn&#8217;t like before the community has a chance to fully work through them.</div><div><br></div><div>Best,</div><div>Jordan</div></body></html>