<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=us-ascii">
<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;
margin-bottom:.0001pt;
font-size:12.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;}
span.EmailStyle17
{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"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I actually don't know if moving the IANA outside of ICANN is a good idea or not; there are<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">certain stability issues that weigh heavily, but we also have existence proof that such teams<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">can be transitioned from their parent organizations successfully. My main point is that moving<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">IANA (or not) doesn't actually have any meaningful impact on the ICANN accountability, which <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">appears (from those on the sidelines such as myself) to be the DNS communities principal <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">source of angst.<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">John,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">You pretend to not have an opinion about something but then offer arguments and observations that support only one point of view. I find this less than transparent.
Let’s be honest and clear about this: you want the IANA functions to stay in ICANN, and all of your arguments are structured to defend that point of view, and they have been for months.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Now let me take up your argument that structural separation “has no meaningful impact on ICANN accountability.”
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For someone whose interventions are usually well supported, it seems an unusually poorly thought out argument.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The ultimate form of accountability is when the IANA functions can be taken away from the provider. That is, the contract can be awarded to someone else if
ICANN performs poorly, takes ultra vires actions, etc. The separability of IANA is meant to foster this kind of a relationship. If ICANN the policy development organ and ICANN the IANA functions operator are indelibly linked together, you cannot change the
provider of the IANA services without also destroying the policy development functions. You would have to start all over, create an entirely new ICANN or (what is more likely) limp along with bad performance or abuses and try to flog away at them from the
inside of ICANN. That option is clearly an inferior one. A structurally separated ICANN lends itself to a clear focus on the performance of the IANA functions in isolation and lends itself to clear, quick and clean rectification of problems.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Under the NTIA contracting regime we do have such separation, more or less, because in principle NTIA can award the IANA contract to someone else. Thus, the
IANA functions provider is separable from ICANN.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The other way in which separation affects accountablity is by making the relationship between finalized policy and implementation more visible, more easily
regulated, more transparent. The process of moving from ICANN policy to IANA implementation has to move across clear organizational boundaries, and that means it can be observed and organized for oversight better. This also has the very important effect of
preventing the policy developer from implementing a policy that has not really been finalized. Imagine what would happen, e.g., if ICANN could just put something in the root, or remove it, without going through a consensus policy process. It would have arbitrary
power over the global DNS. Structural separation of the policy development process from implementation prevents this from happening; ergo, it is more accountable.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I hope this makes it clear to you how accountability and structural separation are related. Of course, I don’t expect to change your position on this – as I
said, it is evident that you do take sides on this issue and that you oppose structural separation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Milton L Mueller<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Syracuse University School of Information Studies<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="http://faculty.ischool.syr.edu/mueller/"><span style="color:#0563C1">http://faculty.ischool.syr.edu/mueller/</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Internet Governance Project<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="http://internetgovernance.org"><span style="color:#0563C1">http://internetgovernance.org</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>