[Internal-cg] thoughts on where we are with the transition
Milton L Mueller
mueller at syr.edu
Thu Sep 11 13:24:00 UTC 2014
> -----Original Message-----
> However, it is not an IETF goal to change the current operator of the IANA
> functions just because we are doing a transition. The transition is about
> building/strengthening/recognising an oversight mechanism that replaces NTIA.
> Or perhaps even improves over NTIA.
> Does the above match your understanding, Milton? Or do you envision that
> because of the transition, one of the operational communities have to both
> develop the oversight _and_ change the current operator? My position is that
> we need to develop the oversight and an ability to change the current operator
> should that some day be needed, but not that we have to make such a change
In my view, the concept of "oversight mechanism" could legitimately include new institutional arrangements that move the IANA function out of ICANN. However, my main point is not to advocate that position in this context, it is simply to make it clear that the responses to the RFP should be open to such alternatives - we should not foreclose any possible responses.
Thus, when you say "the operator will not change" you are foreclosing options. You can legitimately say, "in Jari Arkko's opinion, the current operator _should_ not change," but people on the ICG should not be telling the rest of the communities what "will not change" or what they cannot propose.
> This discussion also goes to the heart of the scoping document debate. The role
> of ICANN as the current operator IMHO is not something that we need to deal
> with, but we do need an oversight that has teeth - including the ability to
Back in May, the public comment on ICANN's draft process proposal decisively rejected the ICANN scoping document. There is no room for debate about that, all one has to do is read and keep track of the responses. Did you read the responses? The message was loud and clear: nothing should be defined "out of scope" regarding the location of the IANA services, and you cannot separate oversight from deciding who the IANA is or how it is provided.
> consider that question later, should it ever be needed. (And I feel I need to re-
> emphasise that the service we get today is very good, and problems unlikely. But
> I still want oversight with teeth, just in case something goes wrong in 2064.)
As you know the names community has a very different sense of satisfaction with ICANN than the protocols, and the names people do not currently have the ability to alter their provider, unlike the IETF.
I would say that as long as you believe that there should be a contracting authority capable of removing the IANA functions from ICANN to someone else, then we have no serious disagreement. What you may not fully understand is the extent to which giving the names community that capability requires some pretty significant organizational or institutional changes.
More information about the Internal-cg