<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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: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;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@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"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Seun Ojedeji [mailto:seun.ojedeji@gmail.com]
<br>
</span>I think you have clearly identified the problem which is ensuring that ICANN does not update the IANA record without following clearly defined policy process. You are now saying that the ONLY solution to avoid that is by taking IANA out?
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Not quite right. ICANN could operate the IANA, as a fully separated subsidiary, if it won the contract from a new contracting authority. The issue is whether
 it just “gets” IANA or whether it has to earn it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal">This is the aspect I am quite concerned about, considering that IANA records contains not only the names but includes numbers and protocol parameters. Are you saying that the reason why ICANN has not done something contrary on numbers and
 protocol parameters is because of the contract and not because of the policy/agreements?
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yes. The IETF does have a contract with ICANN that allows it to change its registry if the IETF is dissatisfied with ICANN’s performance. The number registries
 may not have such a contract, but do have policy processes clearly separated from ICANN. Names is the only space where policy development and IANA implementation would not be separated if ICANN were to inherit the DNS IANA functions without an external contracting
 principal. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal">If it's because of the policy (hoping that's your view) why can't we then concentrate on strengthening the policy process for names and how will taking IANA out really solve that problem because the policy process is still broken and it
 means IANA is more prone to record update without following due process.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">We do need to strengthen the accountability of the ICANN policy process. This is in fact the main goal of many of the actors. However, most of them feel, even
 more strongly than I do, that the IANA transition is the only real leverage we have to require ICANN to make those changes. Because, as I explain in the original post, if ICANN controls both policy and implementation (IANA) without oversight, accountability
 will be much worse than it is now. I think it is a foregone conclusion – at the US government, the Congress, among business interests, among civil society – that IANA cannot be transferred to ICANN the corporation unless new, binding accountability mechanisms
 are created for both the IANA and the ICANN policy process.<o:p></o:p></span></p>
<p>There is also one aspect that we need to also remember, which is the purpose of ICANN and the essence of removing the contract which is largely to indirectly end the contracting regime.
<span style="color:#1F497D"><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I do not understand this statement.<o:p></o:p></span></p>
<p><span style="color:#1F497D">S</span>o if you are saying takeout IANA, you need to be clear on whether it's the 3 function (which ofcourse may not go well with IETF and NRO). If you are taking out the DNS function only, then you will have further fragmented
 IANA and then introduce unnecessary complication and oversight issue on wherever body you are taking the function to.<span style="color:#1F497D"><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">IANA for protocols is already separable; i.e., it is the subject of a contract between IETF and ICANN. The DNS root is in my opinion could be independently managed from the number
 and protocol registries without causing any serious complications. <o:p></o:p></span></p>
</div>
</div>
</body>
</html>