<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 12 (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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Calibri Light";
panose-1:2 15 3 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
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:0cm;
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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{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:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">I’m not really convinced by Milton’s arguments – Chuck is right to throw in the questions and I think it appropriate that they should be considered objectively.<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">I agree that functional separation needs to be defined more clearly – I guess many of us are using it in our own ways.
<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">For me functional separation is to do with keeping a clear division between the different operational units of ICANN and the IANA functions operator – both in the policy-IANA separation (which is required under
the NTIA contract) and the gTLDs/registry contracting role of ICANN and the IANA functions operator.
<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">I’m actually quite happy with looking to include much of the IANA functions operator accountability mechanisms under an enhanced ICANN accountability regime. In my mind this has one crucial element in it – that
the stakeholders are present in ICANN already and accountability is to them. Move it somewhere else and the stakeholders have another organisation to watch.<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">If we need to move the IANA functions operation out of ICANN later, yes, it might be comforting to have an existing model that can just be separated and handed to a new operator. But I guess it would be nearly
just as easy to hive off a functionally independent unit to a new overlord as to move off a subsidiary (with its new management level, which is likely where the problem really is).<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">Cheers<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">Martin<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org]
<b>On Behalf Of </b>Milton L Mueller<br>
<b>Sent:</b> 11 April 2015 16:32<br>
<b>To:</b> Gomes, Chuck; cwg-stewardship@icann.org<br>
<b>Subject:</b> Re: [CWG-Stewardship] Question for Sidley<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><i><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><i><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span lang="EN-US" style="color:#1F497D">--MM<o:p></o:p></span></i></b></p>
</div>
</body>
</html>