thoughts on where we are with the transition
FYI - thoughts from me on the transition. http://www.ietf.org/blog/2014/09/iana-transition-update/ Jari
Jari, With all due respect, when you say "It is not about who performs the IANA function. That is not changing." That decision is up to the process, you are not in a position to say that. Milton L Mueller Laura J and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Jari Arkko Sent: Wednesday, September 10, 2014 9:06 AM To: ICG Subject: [Internal-cg] thoughts on where we are with the transition
FYI - thoughts from me on the transition.
http://www.ietf.org/blog/2014/09/iana-transition-update/
Jari
Milton,
"It is not about who performs the IANA function. That is not changing."
That decision is up to the process, you are not in a position to say that.
I probably have to explain this a bit. Maybe I was not communicating clearly. The full quote was:
It is not about who performs the IANA function. That is not changing. (But of course, the oversight role brings a responsibility to track the performance and make any corrective actions that might be needed.)
What I meant with the part in parenthesis is that the party with oversight (e.g., the IANA customers) have to have the ability to make all corrective actions. Including the ability to move the function out to another party, if things really do not work out. Of course, such a situation is very unlikely IMO, but the power to do that has to be there. (And there’d be a long process of escalation and corrective attempts before we’d get so far.) 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 today. 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 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.) Jari
-----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 today.
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.
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.
Ok. I think I agree with that.
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.
Fair enough. I can see if I can edit my blog to make this clearer.
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.
I do.
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.
Point taken. Thanks for the explanation. Jari
participants (2)
-
Jari Arkko -
Milton L Mueller