<html><body><span style="font-family:Verdana; color:#000; font-size:10pt;"><div><span style="">Thank you all for the opportunity to comment. Like you all, I have read Milton's proposal and read IANA-related comments on other lists. I find Milton's proposal well-thought through and defensible. My comment doesn't go to that proposal directly but rather the many comments directed at reassigning IANA or IANA oversight.</span></div><div style=""><br style=""></div><div style="">it seems to me that the inquiry begins with IANA's customers, the TLDs. (I understand IANA has other roles, assigning port and protocol parameter numbers but I believe most of the discussion has explicitly or implicitly targeted the root-zone management function). I haven't seen any comments to this or other lists by TLD operators complaining about IANA performance, citing examples of undue refusal or delay, or recommending that there were specific improvements to be made. </div><div style=""><br style=""></div><div style="">New models require new performance targets. The first step in a change management process is to understand the gap between where you are and where you want to be. How can a proposed model be evaluated if we do not know the target? Usually change is fomented by complaints or requests from customers. There have not been any on these lists. I understand that some root-zone management requests have been delayed in the past as the USG developed paths to comply with existing US laws, and I understand there is a risk that someday the USG might use it's oversight role to deny an otherwise bona fide request. However, there is no clear definition of that on these lists and no clear indication that an alternative model would better serve its customers.</div><div style=""><br style=""></div><div style="">Does the fact that there are no customer complaints truly indicative of customer satisfaction? I think yes. I was at ICANN years ago when there were multitudes of complaints about poor performance. These problems were addressed in a systemic way and performance (I would say) excelled. The ccTLDs and gTLDs that are IANA's customers are not reticent about voicing issues where they exist. </div><div style=""><br style=""></div><div style="">If it is thought that political reality dictates that it should be attempted to move IANA out from UGS oversight or remove the IANA contract from ICANN, such moves must be made in a way that guarantee the same or better levels of performance. This is based in part on Vint's five "Rs," especially:</div><div style=""><br style=""></div><div style="">Reciprocity: Do no harm, and</div><div style="">Robustness: as found in simplicity.</div><div style=""><br style=""></div><div style="">The IANA function is not purely mechanical, making a move more than trivial. Those handling root zone change requests are guided by RFCs and ICP-1 but there are no bright line rules for administering contentious re-delegation requests or measuring the support of the local Internet community. The current IANA function does a credible job in weighing less than clear policy inputs when recommending actions on requests. That credibility and due diligence has a result: the USG has approved every request, even when potentially against the interest of some USG departments. Removing the IANA function from a nearby policy coordination function where input and information is readily available might cause delays. (It might not but we don't know that.) </div><div style=""><br style=""></div><div style="">While the USG might have veto power (and, in real effect, it might not), it has never exercised it. In creating a new model, we must be certain we are not creating multiple vetoes. There must be some oversight function. It should be simple and limited. </div><div style=""><br style=""></div><div style="">In a complex system, changes can have unanticipated, unintended effects. If change is desired, start with the customers, define the objectives of change, and develop a system that is more assured to meet the goals of the customers than the current system and also meets the political goals. </div><div style=""><br style=""></div><div style="">Kurt</div><div><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left-width: 2px; border-left-style: solid; border-left-color: blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana; text-align: left; ">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [discuss] Roadmap for globalizing IANA<br>
From: Milton L Mueller <<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>><br>
Date: Tue, March 11, 2014 10:23 am<br>
To: Douglas Onyango <<a href="mailto:ondouglas@gmail.com">ondouglas@gmail.com</a>><br>
Cc: "<a href="mailto:discuss@1net.org">discuss@1net.org</a>" <<a href="mailto:discuss@1net.org">discuss@1net.org</a>><br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Douglas Onyango [<a href="mailto:ondouglas@gmail.com">mailto:ondouglas@gmail.com</a>] <br>
<br>
> I think the real issue, as I see it is the appreciation of how intrinsically <br>
> linked the two are - especially in as far as they relate to IG. Just the <br>
> technical operations of the root zone cannot be referred to as IG <br>
> IMHO. This is why, I view your proposal as an attempt to resolve a <br>
> subset of the problem and my response, and proposal, an attempt <br>
> to look at the bigger picture<br>
<br>
Absolutely! We are trying to break down the problem and solve a smaller part of it. We did this after agonizing for years about the overall reform of ICANN. We think that reform of the policy making process - which involves complex issues like the role of governments, whether we need a new international treaty or not, whether ICANN re-incorporates in Geneva or somewhere outside the US - is more difficult and in some ways more important. But in fact, you can't solve those issues properly until the IANA problem is solved first. IANA contract prevents ICANN from moving out of the US. And if ICANN controls IANA without any oversight, or with the wrong kind of political oversight, it may be impossible to reform the ICANN policy process in the future. ICANN could just ignore us and proceed on its way in full control. <br>
<br>
> Working with the "end in mind" habit, do you honestly feel that moving <br>
> the technical IANA function from ICANN will solve the problem? I think <br>
> not entirely: it may take care of some politics by mooting NTIA's <br>
> "Administrator" function and curing the perception that IANA being <br>
> housed within ICANN compromises its integrity, <br>
<br>
Yes, you are right, that is all it does. But I remain convinced that we have to do that first. Then take on the bigger issues in step 2. <br>
<br>
> but if ICANN maintains its relationship with the USG, this could still be construed <br>
> as unilateral control of the root zone, and by extension the internet, by <br>
> controlling the policy function :-).<br>
<br>
To some extent. Your concern is not frivolous. However, as things stand now the only real undesirable control the US can be said to have over policy is its latent authority to yank the IANA contract. The AoC is objectionable on some substantive grounds and because of its unilateralism, but it is pretty weak and in some ways fairly community-driven in its implementation, so I don't think a delay in the reform of the AoC and the policy side is going to let the U.S. exert undue influence over ICANN. <br>
<br>
> Based on my current understanding of the situation, I conditionally <br>
> support this proposal; condition is that this or another attempts to <br>
> resolve the remainder of the problem.<br>
<br>
Thanks! We are working on ideas to solve the remainder. But we calculated that it was too big a ball of gum for the Brazil meeting to chew on.<br>
<br>
_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@1net.org">discuss@1net.org</a><br>
<a href="http://1net-mail.1net.org/mailman/listinfo/discuss">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
</div>
</blockquote></span></body></html>