Hi Milton, On Thu, Feb 19, 2015 at 05:04:33AM +0000, Milton L Mueller wrote:
To me, "narrow" is code for "let's pretend that NTIA oversight with contracting authority wasn't an critical and essential aspect of the status quo." In other words, this approach seems like a way of pretending that we don't need significant new accountability mechanisms to deal with the post-NTIA world.
Well, sure, if you redefine it that way then it's obviously a bad idea. Just to be explicit, however, I am not advocating that pretending. I do wonder how live an option it ever was that NTIA would remove ICANN from the IANA operator role, but I think that is the sort of counterfactual question that is interesting to philosophers but not a very useful guide to action. You touch on the point I was trying to make, however:
worst. And the latter simply shifts the problem to bylaw changes and accountability changes within ICANN.
Yes. And what I was suggesting was that there is an entirely other group that is supposedly responsible to deliver such mechanisms. Therefore, we need not repeat that work, and instead need only to specify the necessary and sufficient conditions for what "adequate accountability" is. Then we (or anyone else) have a simple matter to determine whether CCWG-accountability's "track 1" delivers what is necessary and sufficient. But we at least will have a proposal ready against which others could work. And it prevents us from having to make decisions about (e.g.) structural separation vs. external contracting co. when another group is supposed to be doing that work too.
This is a false hope. Either the community has separability or it doesn't. It is a binary possibility in the end.
I'm not entirely sure I agree that this is as clear dichotomy as you say. What I understand we're (supposed to be) worried about is the IANA function. That's quite limited. AFAIK nobody has ever suggested that IANA has well and truly screwed up. AFAIK, there have been complaints that IANA moved too slowly in the past, but that has mostly been remedied in recent years. There remain some concerns about redelegations (particularly of ccTLDs), but nobody seems to suggest that IANA is not following the policy they have; instead, the objection is to the policy as such. I _think_, however, that what you're arguing is that things are different between the names community and the policy-generation organization for names, and the other communties and the policy-generation organization for those topics. The IETF is outside ICANN, and the problem you're concerned about is that the IANA staff ultimately report to the organization that also generates the names policy for IANA publication. Is that right? If so, perhaps the way forward is to turn things on their head. (This is not a well-developed idea, please note, but just a suggestion that occurs to me and that might be worth batting about.) In the IETF and RIR cases, what we have (roughly) is an expectation that the output of the policy organization (whatever it is) will be faithfully implemented by IANA, and we have a mechanism to do something about it if that does not happen. Perhaps because IANA is inside ICANN, the right thing to do here is to put a firewall around IANA, and state what it shall do _unless_ other conditions come to bear, and specify what those conditions are. This gets us out of the bind of deciding what kind of separation would be possible and so on, and gives us a nice place to state the necessary and sufficient conditions for acceptable IANA behaviour. We then do have a problem of what to do in case IANA goes completely rogue and violates these requirements, but apart from either "fire rogue employee" or "root server operators refuse to load the IANA zone" it's hard to see how to handle that. I'm aware that some people want desperately to completely specify how to handle that case, but it leads us into attempting to tell all network operators which root nameservers they use -- a power that we do not have. I think this is _sort_ of like the current "internal" proposal, but it changes the dynamic because we only have to specify a bounded set of contingencies, and clearly leaves the rest of the accountability stuff for the CCWG-accountability. I may have misunderstood the current proposal, though, so I anxiously await correction. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com