<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Avri,<div><br><div><div>On Mar 16, 2014, at 2:53 PM, Avri Doria <<a href="mailto:avri@acm.org">avri@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br>One of those principles for me would be:<br><br>- Strict functional separation of the policy making and administration<br></blockquote><div><br></div><div>This is not as simple as it might seem. It depends on exactly what you mean by �policy.� I expect your focus, along with many others, is the decisions related to delegation and re-delegation, i.e. which names are added to the root zone who is allowed to operate them. Perhaps �policy� also includes various issues related to public interest, compliance, etc. For all of these, I would agree strongly that we do not want to burden the IANA group or the operation of the IANA function with those sorts of issues.</div><div><br></div><div>On the other hand, here are some other things that have been treated as policy issues in the past that are intimately related to the operation of the IANA function.</div><div><br></div><div><ul class="MailOutline"><li>DNSSEC. Should the root be signed? If so, how? What should the rules be for assuring trust in the process? How often should the root key be changed? Etc.<br><br>Quite obviously we�ve gotten past the first few questions, but there was a lengthy period several years ago where the answers to these questions were stuck in limbo. Even now, there are important questions about the frequency of key rollover, etc. that are not yet reduced to standard practice.<br><br></li><li>IPv6 addresses for root servers. Should IPv6 addresses be included as glue records for the root servers?<br><br>Again, we are now well past this question, but there was a surprisingly long period where several of the root servers were accessible via IPv6 addresses but those addresses were not in the root zone. Worse yet, there was no process in place for figuring out whether it was ok to add them and what the issues might be. (Eventually RSSAC and SSAC did an ad hoc study to provide advice to IANA to get it done. (See SSAC reports SAC 018 and supporting reports SAC 016 and SAC 017.)<br><br></li><li>IDN TLDs. Are IDNs ok as top level domains?<br><br>It took a long time to work through these issues. Along the way, eleven names in various scripts were added to the root zone for testing and evaluation.</li></ul><div><br></div><div>Each of the items in the list above has a required policy development and policy decisions. Equally, each is so intimately tied to the operation of the IANA function that it is impossible and ill-advised to insist there be a complete separate between �policy� and �administration.� Going forward, I think we need to be careful to fit the solution to the problems. The IANA function is critical to the operation of the Internet. As technology changes, the details of its operation must change too. From my perspective, there will be a mix of policy, technical, administrative and resource issues involved in these changes. We need a system that is transparent and accountable. We also need a system that is efficient and effective.</div></div><div><br></div><br><blockquote type="cite">I think that many, myself included, do not see how being part of ICANN<br>and strict functionally separation are possible within ICANN's current<br>configuration.<br></blockquote><div><br></div><div>Can you identify specific instances where the current configuration has failed to operate properly and where the failure is due to lack of strict functional separation? (Also, I think there�s been pretty strong separation in place for a long time, so I�m not sure how much more separation you have in mind.</div><div><br></div><blockquote type="cite">This may also be a big part of the expectations of global stakeholders.<br><br>There is also the issue of ICANN being subject to US law. This remains a problem if ICANN plans to keep the administrative function after transition.<br></blockquote><div><br></div><div>The question has already been asked and I�ll ask again. What is the specific problem about being subject to US law? As a general matter, rule of law is usually considered one of the U.S.�s very strongest qualities.</div><div><br></div><div>Thanks,</div><div><br></div><div>Steve</div><div><br></div></div></div></body></html>