The transition is intended to ensure that the oversight & accountability of the IANA function is free from the US governmental authority, and resides in a multi-stakeholder environment, which is a good thing because the bottom-up multi-stakeholder approach to internet governance and policy has proven to be a great success within ICANN. The transition will help internationalize ICANN in that it will do away with the negative perceptions that ICANN is but an agency of the US government, and will promote the openness of the internet. Importantly, the ICANN community should guard against using the transition process as an opportunity to explore new, unwarranted and radical IANA accountability & operations models. The transition should debate should focus on replacing NTIA as a matter or priority, especially considering the inherent timelines. It should not seek to review the overall current ICANN role in the IANA contract, but should seek to maintain and review it at a later time when we don't have time pressures. Also, IANA customers are well defined: TLD operators, RIRs, etc. The transition should really prioritize what IANA customers want, and not what secondary IANA service beneficiaries (who have no direct relationship with IANA) want. Also, the transition should not make a mistake of treating TLD operators the same, and especially should not compromise the autonomy of ccTLDs from ICANN.
To ensure privatization on DNS and no one country having undue advantage over others
It is what the NTIA wishes provided the conditions of transition are met.
the worldwide current is asking for that, all of effective actions need to be accompanied by democratization idea
To remove the control of one government over the entire internet.
This is a tricky question that is not easy to answer on a yes or no basis. The status quo is that NTIA is an external overseer, and has performed that role well. Based on this, there is no justification why this model (of having an external overseer) should be changed. In fact, the NTIA IANA transition announcement last year showed that the NTIA is confident that an external overseer is an effective model, hence the NTIA is looking for a multi-stakeholder, non-governmental body to play that role. We are therefore comfortable with retaining an external overseer who will play the current NTIA role (including setting performance targets for ICANN) and even have power, at the remotest of possibilities, to take away the IANA function from ICANN. Judging by the NTIA requirement, if a possibility of doing away with an external oversight were to be explored, one is tempted to explore the possibility of having the IANA oversight function allocated to the IANA customers. Who better provides IANA oversight and assess the efficacy of IANA’s performance than the IANA customers themselves? If such an approach is agreeable, ICANN can then set up an equally and geographically representative panel of IANA customers to play the oversight function. Of course, the success of such a panel (call it an “IANA Review Panel”) would depend on the accountability measures compelling the ICANN Board to accept the decisions of the Panel. In addition, the ICANN Board can set an appeals panel (call it an “IANA Appeals Panel”) from outside the ICANN community to which parties aggrieved by IANA and the IANA Review Panel’s decisions may appeal. The appeals’ panel decisions would become final and binding. This approach could allow ICANN to establish the IANA function as a separate subsidiary with a separate budget, but such structural separation is not a must.
ICANN must get the consensus of members on major issues or major decisions
From the time where you want to lock any operation without opening, it's a bad thing
There is a critical need of separation of policy making and policy implementation (operations)
Yes, definitely. In terms of operational performance, IANA customers should have an imposing say because they are the customers. It will not make sense to have a non-TLD operator having an equal say to IANA customers when it does not have a (direct and clear) customer relationship to IANA. At a secondary level on matters of non-operational policy relating to IANA (e.g. addition of new gTLDs), the broader internet community may enjoy equal voice with IANA customers.
Registries need to protect their interests and thereby protect their constituencies
Registries are more linked to IANA as far as day to day registry operations are concerned. Again, registries are entrusted by their communities. However, since registries are not the only customers of IANA other parties should be given weight (RIR, IETF).
Functional separation means having the IANA function remaining within ICANN but as a separate function carried out by an IANA division. Such functional separation, at least for the medium term (e.g. 5 years), is feasible, provided that sufficient and robust accountability measures are implemented for the ICANN Board. The work of the CWG-Accountability will have to inform us how ICANN accountability should be enhanced. Nevertheless, nothing in the current scheme of things seems to suggest that functional separation is not feasible. Of course, if ICANN itself becomes the IANA overseer (see reponse to Question 2 above), it could make more sense to explore structural separation where IANA is a subsidiary of ICANN. For accountability purposes, functional separation must be such that the IANA division of ICANN does not do anything else other than the IANA function, and has a clearly separated budget. ICANN will have a lot to prove that it does not unduly interfere with the IANA division, and one hopes that enhanced accountability measures will suffice to achieve this objective. Also, having an IANA Review Panel and IANA Appeals Panel (see response to Question 2) will give confidence that ICANN will not unduly influence the IANA operator.
It is deemed that ICANN is a neutral entity
I think this internal separation has to be clear through well established procedures
What is needed here is a separate Board of approval of IANA activities (and not ICANN Board)
As stated above, the separation is adequate because there has been no evidence of it being compromised, but enhanced accountability measures should be introduced to ensure that the separation is even more effective. Also, structural separation as outlined in reponse to Question 2 above is also a feasible alternative.
In this regards, Should ICANN not have a contract for its functions?
Need more clarification in the separation of their respective actions and activities
Internal separation is in place only that final approval of IANA activities is coming from USG and not a multistakeholder entity.
The push to separate IANA from ICANN appears somewhat overplayed if it means removing the IANA function totally from ICANN: ICANN has performed the IANA function well so far, and there does not seem to be any pressing reason why so much importance should be attached to such separability. Also, we would need to have a clear process outlining how such separability of IANA from ICANN, if it were to occur, should occur, of course, as a matter of last resort. The argument to have it easy to separate IANA from ICANN (again, assuming such separability means having ICANN no longer performing the IANA function), therefore, ranks the least, but outlining the basis on which such separability could occur – as a matter of a remote, last resort post the NTIA oversight role – is important and should be informed by the measures inherent in the current NTIA-ICANN contract on IANA. As stated in 2 above, if any more separation is required than the present one (which is functional separation), structurally separating the IANA division of ICANN from ICANN seems the best because it will keep the IANA function within ICANN but as a separate subsidiary of ICANN. What undoes the drive to separate IANA completely from ICANN as part of the current IANA transition is that it is not clear if there is another multi-stakeholder, non-governmental, non-private sector player that can adequately play the IANA role with independence and un-bias that ICANN has shown so far. Quality of IANA services, maintaining the autonomy of ccTLDs from ICANN in their dealing with IANA (something that is happening effectively currently), separation of IANA function from the ICANN policy making roles, and ICANN accountability improvements are more important, at least at this stage, than trying to separate IANA completely from ICANN. Again, if we have sufficient accountability measures for ICANN, the separability of IANA from ICANN should be the least concern & should be used as an option of last resort.
Strong important. ICANN policy making and IANA the technical implementation arm.
a lot of importance for separability
We do not have any problem with the current setup apart from the approval process.
This will be very good for accountability, and supports the argument to have IANA as a separate function of ICANN with a separate budget – something that is very attainable. This should remain as a condition for allocating the IANA function to ICANN. Such separate cost requirement will also be feasible should ICANN decide to have a separate IANA subsidiary (i.e. structural separation).
Whoever would be responsible would want to know the cost of operations as a possible determining factor.
Like with any business model, the economic costs and benefits of the existence and operations should be spelt out in a transparent manner so that stakeholders are able to assess the merits and disadvantages of each entity.
That way it will complication of a solution. Lets not re-invent the wheel.
It would help in understanding actual IANA operational costs to separate the address and protocol costs from the naming costs. The IANA function, as a whole, requires ICANN to table separate report on IANA costs. It seems reasonable to expect that such a report will be detailed enough to clarify and distinguish all the costs of each IANA function across different IANA customers.
Transparency in cosst allocation is the only way to assess usefulness of any function.
actions transparency is mandatory regardless of the level
Another complication of a solution.
The danger with a separate IANA operator outside ICANN is that such an operator would face additional, unnecessary political hurdles that ICANN, as a policy body, has already managed to address. For example: • Should such a separate operator be a US entity or a non-US entity? • How comfortable would the US government be with handing over the IANA function to a non-US entity? • How would such an entity be constituted? • Who will have a final say on its composition? • Should it be composed of the defined IANA customers only or should other parties be included? If they are included, on what basis? • Would governments and ICANN itself be allowed to be part of the separate operator? The point is that there are too many difficult-to-answer questions against having a new separate IANA operator. Maintaining the status quo (i.e. keeping IANA as an ICANN function), and then focusing on enhanced accountability measures for ICANN in the short term, seems more feasible to focus on right now.
Given the way policies are determined at ICANN - consensus based and ground up, the new operator will have no choice but to accept it and this must be made clear in the contract of any new operator who will have studied the contract prior to accepting the role.
A clear separation of duties can be determined internally (within ICANN). Let us avoid a totally new ghost.
However, the NTIA already has a clear view about its preferred model. There does not seem to be any reason to believe that NTIA wants to separate IANA from ICANN or wants any overseer other than a multi-stakeholder, non-governmental body. There are clear indications that NTIA will accept nothing less than what it has already stipulated.
It is possible there are other options
The current transition models should be fully explored. The concept of a Board of Trustee is a very powerful one which merit further evaluation especially if they are to patrol the conditions of transition which the NTIA has set out.
Why not, we could foresee other acceptable schemes
We believe in re-adjusting the current setup rather than building afresh.