[discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body

[Milton L Mueller]

Steve
Based on what you write below, I still see a clear distinction between the policy decisions, and their later implementation by the IANA. Of course the policy and the implementation are interdependent. But none of your examples undercut the argument for structural separation.

IPv6 addresses: RSSAC and SSAC are obviously on the ICANN, policy side of the equation. If they recommend adding v6 addresses to the glue records, IANA implements.

IDNs: Obviously, like any new TLD addition whether to authorize them or not was a policy decision, albeit dependent on prior standardization work by the IETF and tests.

DNSSEC: You ask "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?"   - These all seem to be policy decisions to me.

I would note that separating IANA implementation from policy seems a lot less intricate and complicated to me than the separation of registry and registrar functions, which was done 15 years ago with huge economic and technical consequences.

When you talk about "complete separation of policy and administration" I wonder whether you have an unrealistic notion of separation in mind, which is not what anyone advocates. It doesn't mean a lack of communication, for example. It is more like a clear division of labor or function. Sure, there are bound to be some grey areas, but that shouldn't be used to rationalize complete integration of the two.

Also, you ask for example of where the current configuration has failed to operate properly. But this misses the point: under the current configuration, you are _contractually obligated_ to run the IANA functions in a way that meets standards. Once that USG contract goes away, what is the guarantee that this will continue to happen?


From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of Steve Crocker
Sent: Sunday, March 16, 2014 4:29 PM
To: Avri Doria
Cc: discuss at 1net.org List
Subject: Re: [discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body

Avri,

On Mar 16, 2014, at 2:53 PM, Avri Doria <avri at acm.org<mailto:avri at acm.org>> wrote:


Hi,

One of those principles for me would be:

- Strict functional separation of the policy making and administration

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.

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.


  *   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.

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.
  *   IPv6 addresses for root servers.  Should IPv6 addresses be included as glue records for the root servers?

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.)
  *   IDN TLDs.  Are IDNs ok as top level domains?

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.

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.



I think that many, myself included, do not see how being part of ICANN
and strict functionally separation are possible within ICANN's current
configuration.

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.

This may also be a big part of the expectations of global stakeholders.

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.

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.

Thanks,

Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140316/00a847c1/attachment.html>