<html xmlns:v="urn:schemas-microsoft-com:vml" 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 Light";
panose-1:2 15 3 2 2 2 4 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
h5
{mso-style-priority:9;
mso-style-link:"Heading 5 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:10.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma",sans-serif;}
span.Heading5Char
{mso-style-name:"Heading 5 Char";
mso-style-priority:9;
mso-style-link:"Heading 5";
font-family:"Calibri Light",sans-serif;
color:#2E74B5;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma",sans-serif;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><b><i><span style="color:#1F497D">[Chuck Gomes] I haven’t overlooked any of the possible advantages of the legal separation model but instead am also considering possible disadvantages of it in addition to the advantages. One advantage
is that it would involve a simpler transition with lest risk of destabilizing current services. <o:p></o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><span style="color:#1F497D">MM: But it doesn’t really simplify. We’ve been through this time and again. The internal model is like a shell game in which the magician appears to make complexity disappear by hiding it under a shell - a bunch
of unspecified internal bylaw and structural changes in ICANN, ranging from the minor to the huge (e.g., a membership structure). I am pointing out that the problem is under the shell, it has not gone away.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">MM: As for destabilizing current services, this is completely unconvincing. Making the existing IANA staff an affiliate doesn’t destabilize anything. You have the same people doing the same things.
<o:p></o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">Another is that would likely be less complex. A third is that it could probably be implemented in a more timely manner, assuming of course as you point out below that the internal accountability mechanisms
can be implemented in a timely manner including bylaws changes, an assumption I know is a big one.</span></i></b><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">MM: Again, how do you simplify and speed up implementation by deferring the problem to a complete overhaul of ICANN’s policy making apparatus, board structure, membership mechanisms, appeals mechanisms, and bylaws?
This argument just doesn’t hold water, I wonder why people keep making it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">[Chuck Gomes] It is not impossible that the functional separation model could work out well if the accountability mechanisms are well designed and implemented. <o:p></o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><span style="color:#1F497D">MM: It is impossible, because there is no clear target to the reform. If IANA is not legally separate then all the accountability mechanisms associated with it are part of ICANN’s overall accountability reforms.
General ICANN accountability mechanisms of the sort the CCWG is working on are designed to make ICANN’s policy making process more responsive to the community. As you yourself once remarked to me,, “spilling the board” doesn’t improve IANA performance one
bit, but it does upset and destabilize all of ICANN’s activities, of which IANA is a small part. Unless there is legal separation and a distinct PTI governance structure, none of your accountability mechanisms will be targeted specifically at the management
or stewardship of the IANA functions. If you create IANA-specific governance structures with an internal model, then you have the same complexity, don’t you? But you don’t have the same effectiveness because the governance of IANA is not clearly separation
from the governance of ICANN as a whole. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">MM: Further, a semantic issue. Let’s stop using this term “functional separation.” Or if you do use it, give us a clear definition as to how it is different from the status quo. There is no accurate and viable
definition of it that you or anyone else has offered, other than that IANA remains a division of ICANN, managed by ICANN’s board, and subject to ICANN’s general accountability measures. “Functional separation,” so-called, is just an internal option. There
is no separation there. <o:p></o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">If it did, there would be little if any sacrifice. Of course we don’t know at this point in time. That is one reason why it might make sense to give it a shot.
<o:p></o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><span style="color:#1F497D">MM: This is what I think is so completely misguided about your idea. We only have one shot at this. The politics are fraught both at the international and a the domestic level. People are investing an exhausting
amount of time in this. Whatever happens in the first round will be what happens, period. I think you know this. If you want to argue for an internal option, argue for it directly. Don’t pretend that it is a step towards another option. It won’t be.
<o:p></o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">--MM<o:p></o:p></span></i></b></p>
</div>
</body>
</html>