Yes, we support the transition of the NTIA’s stewardship role over the IANA Functions. The transition of NTIA stewardship is an important step in the evolution and maturation of the multi-stakeholder model. Notwithstanding, we think it is imperative that the transition be done right. This includes development of a sound transition plan that meets the needs of the customers of the IANA function; addressing contingencies, concerns, and potential issues related to the transition through stress testing; and ensuring that the requisite “Workstream 1” accountability mechanisms identified by the CCWG Accountability are in place prior to the transition.
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.
The entire process in our opinions seems rushed....Are the requisite frameworks/resources in place to ensure a smooth transition..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.
Not at this time, the process has not taken into account full consultation and consideration of the transition to the internet community.
Besides the opportunity of converting this into a multistakeholder process, I think our community is having enough time to work out a consensed proposal, so we all are going to look bad if we fail to do the transition
In my view, both ICANN and the multistakeholder model are mature enough to step in and take the responsibility and the service ( role ) delivered by NTIA.
The multistakeholder community has grown engough in maturity to supervise indirectly the overall NTIA functions, in place of one governement in particular
The current control of USG bears risks to the long term coherence of the Internet - and wastes a lot of resources as it is discussed over and over again. Operationally the NTIA oversight is not harmful, and there are certainly possible scenarios that are worse.
I think, it is time that the NTIA hand over its stewardship to other hands
IANA stewardship should be neutral to any government.
IANA should be independent of any government.
Would relieve the pressure form certain countries looking for multilateral solutions and nothing a transition now would be seen as a failure of the multistakeholder model
It is important that IANA will be a neutral organization
It is all natural that all the functions of Domains and numbers should be under the multistakeholder hat.
stewardship of tha global DNS should be the responsibility of the multi stakeholder community
It is natural development of global internet
It's working, more or less.
I do not see the need for a rush
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.
For control and transparancy mechanisms, urgent for the community
That is precisely the reasons we had when we decided to work and to build ICANN as the trustable structure to coordinate the process related to build policy and to operate IANA fuctions. We believe that is time now to move forward and to liberate the NTIA of this responsabilities.
This transition was part of the plan since the beginning, and the unique role of the USG has lasted for far too long, generating a perception of asymmetry in comparison to all other governments. The Internet community should be able to handle this task.
We are generally comfortable with ICANN continuing to serve as both a convener for the policy making processes for the GNSO and CCNSO and as the IANA operator. We note the key distinction that ICANN is not in its own right the policymaker for ccTLD and gTLDs, but rather facilitates policy development through the applicable multi-stakeholder process. The acceptability of ICANN continuing both of these roles is not condition-free. It depends upon continued insulation of the IANA functions from the ICANN policy process and development and implementation of a sound transition proposal by the CWG IANA and an accountability framework by the CCWG-Accountability. These outputs must meet the needs of the customers of the IANA functions in terms of operational performance and transparency and provide for overall organizational accountability, respectively. We believe that some external oversight over the performance of the IANA functions is still desirable, but that this oversight could take a variety of forms. We strongly support the formation of a Customer Standing Committee to regularly review the performance of the IANA Functions against established service levels and the continuation of existing reporting and transparency requirements to facilitate third party monitoring of this nature.
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
I could say yes in a first moment, but I would rather be able to work some form of external oversight.
Mature management requires acceptance of external oversight; this is very important function which supports growth and development.
sutrctural or operational separation is necessary to insure that policy making is not influenced by execution contingency. Furthermore, policy making as well as operations (execution) has to be oversighted
We could live with it, altough we'd prefer to have some oversight. This oversight could be part of the ICANN arena but would have to be outside of the control of the ICANN board.
for a ccTLD ICANN is not the police making organisation, therefore I think the operational part of IANA is well located within ICANN, but there should be an external oversight body or organisation
Yes, if both policy-making and IANA operation have enough accountability to the community and the community has enough power to redress the unfavorable activities of ICANN.
As long as there is a multistakeholder oversight and a possibility of later separability
Only if ICANN accountability is improved = there is no need for oversight. Yes there is already a separation between policy making part for TLDs and IANA operations but can be improved too. e.g. IANA can be operated as a sister or a subsidiary company of ICANN but some process separation should be in place.
We didn't experience any problem with ICANN and IANA until now.
As long as ICANN is in both roles under the oversight of the multistakeholder community as is what the CCWG currently strives for
I am sure that ICANN is able to manage the accountability with the communities' support
This is a multistakeholder environment, and will have the oversight built in to it.
ICANN should outsource the IANA operation so that there can be a choice of operators that can meet the SLA.
ICANN is desperately lacking transparency and accountability.
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)
Is important built a survillance institution outside to make transparent all the processes between the parts
Yes we are. We need to continue working into the ICANN structure to have and to maintain the independence and accountability of IANA functions as well the policy development processes.
There should be sufficient internal checks and balances and accountability mechanisms for these two tasks to be performed well. If ICANN ever becomes dysfunctional enough that the IANA function does not work, by then the policy function will also probably be broken.
One criterion described by the NTIA was that the proposal must meet the needs of the customers of the IANA functions, which for the naming functions refers to ccTLD and gTLD registry operators. Registries’ businesses are uniquely dependent on the continued operational performance of the IANA naming functions. As such, we believe that any proposal must be deemed acceptable by ccTLD and gTLD registry operators.
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
I understand we have created commisions that intent to represent our interests. While more people is involved, it is more difficult to reach consensus.
The registries are key clients of IANA and focus mainly on technical aspects including service level. The scope of transition proposal is much wider.
Regsitries are not the primary customers of all IANA functions. They are essential customers of the naming function. They have to be listened carefully, and yet they are not the most important stakeholders as stakeholders has to be taken on equal footing.
I don't agree that registries are more important. They are only more complicated.
the IANA part is very important for all ccTLD´s and therefore there voice should be heart
Yes, especially for the technical aspects of the IANA functions.
But only in relation to the technical performance
But the end of the day it is negotiation and coming to a mutually acceptable agreement with other customers of IANA.
Registries should verify the acceptability of the transition proposal.
There is a direct dependency with regard to the IANA services. So proposals should only be acceptable and presented to the NTIA if these proposals have the support of the registries. This is however already part of the NTIA criteria, so should not be an issue.
We are the organizations that needs the IANA's services
CC and g-Tlds should have more saying about oversight and control over IANA. But the decision should be clear multistakeholder - all have same saying.
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).
Is necessary to evolve the world trends. IANA has concluded their period satisfactoryly, but is necessary create an external entity to make the process transparent
No further comments...
We believe that functional separation should, at minimum, encompass the following: ● Providing a stable, transparent, and predictable revenue stream for IANA operations that would continue regardless of decisions made as a part of ICANN’s budgeting process (e.g. by apportioning a set percentage of the fees that ICANN receives from registry operators or from the other streams to IANA operations); ● Operating IANA in accordance with processes, service levels, and reporting requirements, and transparency procedures, etc. that are known to its customers and not subject to unilateral change by ICANN; ● Insulating IANA operations from the ICANN policy process by ensuring that groups or interests cannot use IANA to advance a policy goal; and ● Designating distinct ICANN staff to manage IANA operations and the ICANN policy processes.
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
Limited conflict of interest and confidentiality between the IANA operations and overall ICANN (being more industry based)
IANA performs technical duties, based on policies and procedures that must be approved by the respective community (names, numbers or protocols). ICANN must follow and respect these policies.
- Presence of SLA's: - Mechanisms to redress
We have dedicated resources, managemt system, metrics, procedures and processes exclusively assigned to IANA.
internal separation between ICANN and IANA in the context where ICANN is the IANA operator
Mainly dedicated staff, up to management level. Fine grained, auditable reporting on actions. Clearly defined processes. However, care should be taken that rules are not overly restrictive, and do not prevent IANA knowledge and experience to reach the other ICANN staff.
that different people do the day-to-day job and the police making body for IANA is not ICANN or the ICANN board
(This question can't be answerd by "Yes" or "No") To separate the framework of policy-making and that of operation.
Means that IANA have separate personel like own legal advice, own technicians, own leadership team and their own budget.
As stated in the previous question, IANA can be operated as a sister or a subsidiary company of ICANN but some process separation should be in place.
We'd like IANA to be a part of ICANN.
It seems logical that the IANA services are run by a separate part of ICANN as it is currently organised. We do not see any need for further separation.
better to have IANA operator as entity separate from ICANN
Internal separation is fine, but then ICANN/IANA still needs some form of oversight
More transparency and openness to the rest of the internet environment
Separate functions must be performed by separate entities as one can not divide responsibilities.
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)
This means that we need to make the processes transparent, ICANN is related to IANA, even we make transparent the situation that image for the community is not good. We must divide the structure, policies and rules, that will make possibily more credibility
Just for very exceptional and critical circumstances
We believe that IANA operations are generally well separated from interference by the ICANN policy process, but that separation could be further improved. Examples of how separation could be improved include providing transparency into the budget of the IANA department versus that of ICANN as a whole and by providing a stable and segmented revenue stream for IANA operations.
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?
As I said, I agree with this, but it would not harm to have an external oversight sometime in the future.
From my perspective, the mentioned separtion works, however we have never tested any bad scenarious ( bad things never happened, at least for the last 2 and half years; from the moment I joined the ccTLD), however I would liek point out that it doeas not mean that the model with separation requirement is not needed.
I do not know enough about it to give an informed answer.
No better functional separation is needed
But the transition is an opportunity for improving those current arrangements.
IANA is quite independent from ICANN under current arrangements.
works fine now, so why change anything
I think that is important to let the relevant communities the opportunity to make the right decisions
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.
I believe that there is room for a more explicit organizational separation, and that it is desirable, but I do not think the current structures deserves a "No" answer.
We feel that separability of the IANA functions from ICANN should be possible in limited circumstances, such as operational incompetence, and provided that a clear and transparent escalation process is followed and fails to address the issue under consideration. We believe that a decision to appoint a new operator for the IANA naming functions would have to be approved by registry operators as the primary customers of that function.
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.
Not the top priority. I appreciate more the quality of service, efficiency, security and stability, etc.
Quite importnat, as it is a part of management system; the most of the listed aspects are related to services and overall performance. This is different agenda. .
I would give a great importance to the "ability" to seprate IANA from ICANN. Because if this ability would not exist, it would be a stepback from the current situation were the US governement theoretically can remove the IANA function from ICANN.
Medium to low. The most important part is the actual service, and that should receive all the support and resources required to perform next to perfection. Accountability and auditability would be closely related to that. Easy separability is only useful in case of ICANN's failure, and as a menace.
(This question can't be answerd by "Yes" or "No") Security and stability of the DNS and its operational arrangement are the most important regardless of where IANA function resides.
Security and stability are the most important
We don't think that they should be separated.
Very limited to none. Oversight over the IANA function should be arranged by changes to ICANN's accountability. If the community obtains through the CCWG process the necessary mechanisms that will give them oversight over the board there will no longer be any necessity for a separability mechanism as the community that than oversees ICANN is exactly the same community that would decide on separation.
It is not the top priority, but it is important. There should be a mechanism to continue IANA function in case ICANN fails for any reason
security and stability, ease of separating the IANA function from ICANN, quality of services, accountability mechanisms. All of this should be the first thing in consideration to make the transition
One depends on the other
I do not understand the yes/no option. To me a possible separation of IANA from ICANN is very important
a lot of importance for separability
We do not have any problem with the current setup apart from the approval process.
Is necessary the transition process should ensure the the security of each cctld, for that reason the time need should be considered one of the major factors to risk analysis
high logical importance
There are too much more important topics to be defined rather than this one that seems to be as a very extreme possibility
Yes :-) If sufficiently strong accountability mechanisms are put in place, I would rank "ease of separation" 3rd or 4th. Separation is the "nuclear option", so it should be doable, but we should not spend most of our efforts in making it easy to do. Instead, we should work on the safeguards for this options never (i.e. VERY unlikely) to be necessary to be exercised.
Yes, we believe that it would be valuable to provide these costs as well as a breakout across the three categories of functions.
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.
In the context of an eventual separation, yes, in order to select another operator and no over pay him.
Yes, it would help us in understandnig the value and the cost figures; the performance indicators and targets ( service levels); the excellence of service and security and stability; and the overall risk of operations including financial risk, if it comes.
In any case, it is important. Even in the case there would be no posibility for separation.
Not sure if I understood the question correctly. As long as IANA is part of ICANN (functionally separated or not), ICANN should provide the funds via its budget. If IANA is completely outside ICANN, ICANN should not be required to contribute - in that case the IANA customers should be able to provide the funds, possibly by reducing ICANN contributions.
If IANA's budget is defined by the community, the result of the financial audit is the most important information for the community.
If IANA functions will be separated from ICANN then IANA auditor (oversight body) should care about the cost.
I could not answer this question as it is not clear what 'overhead costs' in this specific question means. In my perspective it should be clear what the costs of the IANA services are.
If the community choose to run IANA with another operator, the community have to suply funds to that operator.
Yes it is important, having in mind self-growth of ICANN functions
That way it will complication of a solution. Lets not re-invent the wheel.
Because ICANN has the economic support of the Community and IANA has benefited as related part
I see no sense on this
A good way to keep ICANN honest on a routine basis.
Yes, we believe that it would be valuable to provide these costs as well as a breakout across the three categories of functions.
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.
I think that would be something that could create more discussion and differences among actors, and would not be helpful.
Based on the details I have, I would not support the importance of the mentioned separation
accountability, transparency, but also the need to always improve.
because there is a need for a clear cost calculation for the founding and what part is for ccTLD´s (and also gTLD´s)
Registries should pay for the name functions. RIRs should pay address and protocol functions.
Not sure, but it seems unneccesary to split up too much. And the two has been handled as one. Very hard to find funding for protocol?
It seems that address and protocol function costs are not that much of an issue
actions transparency is mandatory regardless of the level
Another complication of a solution.
To the extent possible contingencies associated with the ability to move the IANA functions should be considered and addressed within the stress tests for the IANA transition.
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.
Yes unforeseen impacting circumstances could arise
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.
ICANN should not have unilateral decision in future new gTLD rounds
If everything is taken into account before writing contracts, and there is a defining body for the unforeseen, all should work well.
I see some risk of delay when making the decision and deployment of the new project. I belive that ICANN policy is/ will be subject of the internet community consensus and will work for public good.
There would be impacts, but I don't see how they would be unforseen. Any operator should have to implement the policy. inside or outside Icann, and if ICANN still have this policy role, ICANN would have the ability to demand the implementation in any circumstance to the IANA operator.
ICANN would provide input to IANA, just like the IETF or NROs. Generally speaking it should not be IANA's role to comment on that input. This said, technical comments from the IANA operator should be valuable input during any policy process.
(Cannot fully understand the question.)
But this can be dealt with.IANA should only be separated from ICANN in extreme misconduct.
We do not consider another operator for the IANA functions.
invalid question/answer combination
As soon as you select a new operator it is needed that the roles and authorities of all involved becomes crisp clear, defined and well documented, which it clearly currently is not. (the same question however currently applies to the rol of the RZM.)
This is a decision that must be taken by gNSO and ccNSO communitues
There has to be clear roles if separeted.
There will be service agreement which specify the process for notifying the operator of additional TLDs and the cost thereof
10-100-1000 what's the difference?
A clear separation of duties can be determined internally (within ICANN). Let us avoid a totally new ghost.
there will be few. OK ICANN runs new gTLD process. Operator accepts only the results and not part of it
Yes, in the sense that anything can happen, but a key point in selecting and sticking with a IANA operator should be its commitment to obeying the policies agreed by the community in the ICANN context, without second guessing them.
We believe that the CWG should give serious consideration to recommendations that simplify or streamline the proposals currently under discussion. We believe that the interests and needs of ccTLD and gTLD registries are insufficiently represented in the proposals to date as the direct customers of the IANA naming function and we would welcome proposals that empower these communities in IANA’s oversight.
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.
More subsidiary approach decentralising the administration of ICANN
I do not think of any.
Anything that leads to a solution preserving stability, security,and resiliency and is simple.
The proposal should be build on the existing assests; on what we already gathered. It's a lot. The differences have to be understood and negoatiated. First of all the objective of low risk should be applied. The IANA in this proposal should be housed by ICANN and separated accordingly ( an independent department). ICANN accountability should be analysed and possible extenstion to be discussed and implemented to meet the new management model.
I have no idea.
As stated before we see enhancing ICANN's accountability as the solution for the IANA oversight transition and even think that it would be good to merge the CWG and CCWG and stop working on the separability driven CWG solutions (including the new proposal by Avri Doria c.s.).
There must be, but I cannot submit one ;)
Contracts with each ccTLD
Why not, we could foresee other acceptable schemes
We believe in re-adjusting the current setup rather than building afresh.
there is one: the simple one. limit the IANA operator functionality and selection to the technical community.
Or rather, maybe. Should there appear another proposal that is simpler, with fewer committees and structures, and still able to do the job, it should be considered.