[discuss] [IANAxfer] [ccnso-igrg] Two accountability questions - help pls- Workshop 23 - ICANN accountability

[John Curran]

On Sep 5, 2014, at 9:47 AM, Milton L Mueller <mueller at syr.edu> wrote:

>  
> I actually don't know if moving the IANA outside of ICANN is a good idea or not; there are
> certain stability issues that weigh heavily, but we also have existence proof that such teams
> can be transitioned from their parent organizations successfully.  My main point is that moving
> IANA (or not) doesn't actually have any meaningful impact on the ICANN accountability, which 
> appears (from those on the sidelines such as myself) to be the DNS communities principal 
> source of angst.
>  
> John,
> You pretend to not have an opinion about something but then offer arguments and observations that support only one point of view. I find this less than transparent. Let’s be honest and clear about this: you want the IANA functions to stay in ICANN, and all of your arguments are structured to defend that point of view, and they have been for months.

Wow.  Please reread the paragraph you quote above - I very much feel that moving the IANA
function has some benefits but also some risks.   In the balance, it's a very close call, and I
actually think is a less important question than other accountability aspects of the transition.

> Now let me take up your argument that structural separation “has no meaningful impact on ICANN accountability.”
> For someone whose interventions are usually well supported, it seems an unusually poorly thought out argument.
>  
> The ultimate form of accountability is when the IANA functions can be taken away from the provider. That is, the contract can be awarded to someone else if ICANN performs poorly, takes ultra vires actions, etc. The separability of IANA is meant to foster this kind of a relationship. If ICANN the policy development organ and ICANN the IANA functions operator are indelibly linked together, you cannot change the provider of the IANA services without also destroying the policy development functions. You would have to start all over, create an entirely new ICANN or (what is more likely) limp along with bad performance or abuses and try to flog away at them from the inside of ICANN.  That option is clearly an inferior one. A structurally separated ICANN lends itself to a clear focus on the performance of the  IANA functions in isolation and lends itself to clear, quick and clean rectification of problems.

I agree with you that the IANA functions and the policy development bodies should never be indelibly 
linked together.
 
> Under the NTIA contracting regime we do have such separation, more or less, because in principle NTIA can award the IANA contract to someone else. Thus, the IANA functions provider is separable from ICANN.

Correct.  However, this situation apparently does not provide the level of accountability that some
in the DNS community feel is necessary.  The ability to separate is a very blunt instrument, and any
potential wavering in ICANN's fidelity to the community's intent has not risen to the point of trigging 
such separation.  

So, yes, it's a useful mechanism, but potentially not sufficient on its own.
 
> I hope this makes it clear to you how accountability and structural separation are related. Of course, I don’t expect to change your position on this – as I said, it is evident that you do take sides on this issue and that you oppose structural separation.

Read again - as noted, I believe that IANA must be separable. Whether it is desirable to extract it 
from ICANN at this time is a harder question, one that must balance the operational risks against 
the benefit.   If our only choice for an accountability mechanism is an external and separate IANA 
operator, then sign me up, but I've got an open mind and believe that there may be other mechanisms
worth considering before taking the structural separation approach (particularly if those approaches
provide more usable and not as "blunt" accountability mechanisms.)

Thanks!
/John

Disclaimer: my views alone.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140905/d7ab214e/attachment-0001.html>