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

Tue Sep 9 10:40:48 UTC 2014

On Mon, Sep 8, 2014 at 5:02 PM, Milton L Mueller <mueller at syr.edu> wrote:

>
>
> *From:* Seun Ojedeji [mailto:seun.ojedeji at gmail.com]
> I think you have clearly identified the problem which is ensuring that
> ICANN does not update the IANA record without following clearly defined
> policy process. You are now saying that the ONLY solution to avoid that is
> by taking IANA out?
>
>
>
> Not quite right. ICANN could operate the IANA, as a fully separated
> subsidiary, if it won the contract from a new contracting authority. The
> issue is whether it just “gets” IANA or whether it has to earn it.
>

Okay thanks for clarifying this and i also share the fact that ICANN has to
earn IANA by being accountable to its customers. However you seem to be
indicating that the only way to achieve this is by continuing with the
contracting approach which i don't think should be the case.  There are 2
major ways by which i think ICANN can be reminded of the fact that it
doesn't own the funtions and by so has no absolute control over it.

- Through the various policy processes (which i think you also agreed to in
your mail)
- Through the service providers: The reality is that the functions are
actually in effect because many service providers subscribed to it. If
ICANN so extremely miss-behaves then it definitely won't be the end of the
Internet as i would expect major service providers to be able to find a way
around this. I believe ICANN itself would know that she is not the ultimate
source of names and numbers and will like to keep up with its customers
demands/needs.

>
> This is the aspect I am quite concerned about, considering that IANA
> records contains not only the names but includes numbers and protocol
> parameters. Are you saying that the reason why ICANN has not done something
> contrary on numbers and protocol parameters is because of the contract and
> not because of the policy/agreements?
>
>
>
> Yes. The IETF does have a contract with ICANN that allows it to change its
> registry if the IETF is dissatisfied with ICANN’s performance. The number
> registries may not have such a contract, but do have policy processes
> clearly separated from ICANN.
>

+1

> Names is the only space where policy development and IANA implementation
> would not be separated if ICANN were to inherit the DNS IANA functions
> without an external contracting principal.
>

Hmm....i think i can almost +1'd this but like to get some clarification.
Are you saying that there is already an existing separation between names
policy and IANA names function? If yes then i agree to that. Are you also
saying that the separation was made possible because of the contract? If
Yes, no problem. Would you not also agree then that the current separation
can be maintained even without the contract? I for one, expect that the
separation would still exist and perhaps ways to ensure that should be on
our top agenda.

>
> If it's because of the policy (hoping that's your view) why can't we then
> concentrate on strengthening the policy process for names and how will
> taking IANA out really solve that problem because the policy process is
> still broken and it means IANA is more prone to record update without
> following due process.
>
>
>
> We do need to strengthen the accountability of the ICANN policy process.
> This is in fact the main goal of many of the actors. However, most of them
> feel, even more strongly than I do, that the IANA transition is the only
> real leverage we have to require ICANN to make those changes. Because, as I
> explain in the original post, if ICANN controls both policy and
> implementation (IANA) without oversight, accountability will be much worse
> than it is now.
>

I agree that the 2 should be clearly separated (!structural); while ICANN
is the home of the names PDP, it should have absolutely no control over it
(This is the similar manner existing with the RIR PDP). By this, the
oversight will then be a shared responsibility; oversight from the
community on ICANN's interpretation of policies during implementation and
the other oversight will be that of the external (which could be done by
the consortium of affected communities)

>  There is also one aspect that we need to also remember, which is the
> purpose of ICANN and the essence of removing the contract which is largely
> to indirectly end the contracting regime.
>
> I do not understand this statement.
>
Okay i will further explain, historically and from my discussion with
people who where there when it all started. I have figured that ICANN was
purpose built; which is to ultimately coordinate the internet resources and
the reason why there was need for contract is to allow the then young and
vulnerable ICANN grow to maturity before it is fully allowed to be
independent. So i think going out of this contracting processes should
indeed be the next phase in the growing process of ICANN and it absolutely
may not make any much difference if it leaves one contracting regime to
enter into another.

>  So if you are saying takeout IANA, you need to be clear on whether it's
> the 3 function (which ofcourse may not go well with IETF and NRO). If you
> are taking out the DNS function only, then you will have further fragmented
> IANA and then introduce unnecessary complication and oversight issue on
> wherever body you are taking the function to.
>
> IANA for protocols is already separable; i.e., it is the subject of a
> contract between IETF and ICANN. The DNS root is in my opinion could be
> independently managed from the number and protocol registries without
> causing any serious complications.
>
By DNS root, i presume you refer to the role carried out by Verisign? or is
it the names functions carried out by IANA? If its by Verisign, i may not
necessarily care much about this for now. However i will be concerned that
the IANA functions is getting detached (protocol and numbers are not
detached in terms of the function) by making another independent body
manage the names function. Perhaps ways of making sure that the IANA
functions ONLY gets executed through policies should be explored.

Thanks

Cheers!
-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>seun.ojedeji at fuoye.edu.ng
<seun.ojedeji at fuoye.edu.ng>*

The key to understanding is humility - my view !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140909/0b323fc5/attachment.html>