[Internal-cg] thoughts on where we are with the transition

[Jari Arkko]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140911/c0bfde2f/signature.asc>