Plan to shift internet's control panel away from US government gets tentative thumbs-up

The plan to shift control of the top level of the internet away from the US government to domain name overseer ICANN has been given a tentative thumbs-up by the internet community.

A public comment period on the proposal for the IANA functions contract closed earlier this week with 159 submissions received. Just under half the comments came from individuals, but governments, the technical community, business groups, and civil society all sent in comments.

The vast majority of the comments were supportive of the plan overall, which will hand control over to a new affiliate of the current contract owner, ICANN, and two new groups set up to ensure that the contract is run effectively. In addition, a process to pull the IANA functions was identified as a last resort.

The proposal was pulled together from three different proposals covering the three main technical jobs that are being considered. Despite most commentators agreeing with the proposal, there were significant concerns over key aspects of the plan.

The same five issues were identified repeatedly from stakeholders as diverse as Google, the Internet Society, US Council for International Business (USCIB), the Internet Architecture Board (IAB), and others:

1. Whether the new affiliate will cover all the functions

The so-called "Post-Transition IANA" (PTI) that will officially take over the IANA functions may not actually be used by two of three functions.

Google wrote: "The three communities associated with the IANA functions submitted separate proposals, and the PTI is not included in the numbers and protocol parameters proposals. Rather, [they] have proposed that they continue to work with ICANN as the IANA Functions Operator (IFO). Given this inconsistency, the ICG should provide additional details to harmonize the three proposals."

The USCIB wrote: "[We ask] the ICG to clarify how the Numbers and Protocols communities will interact with the new PTI entity and with whom the Numbers and Protocols communities will conclude contracts. If the Numbers and Protocols communities want their contractual relations to be with ICANN (and treat the PTI as a subcontract), that should be spelled out."

Even the ICANN Board noted the issue – the result of the group simply squashing three plans together rather than developing a single approach. It wrote: "The names community suggests an operational relationship directly with PTI, while the other two communities propose agreements directly with ICANN. The ICANN Board seeks more clarity on the implications of these arrangements on ICANN and ICANN’s relationship with the operational communities."

One of the groups in question, the IAB, provided its understanding of the situation: "We understand that the existing MoU between the IETF and ICANN will continue without change. That is, the MoU remains the basis for the administration and maintenance of the protocol parameters registries. This means that ICANN will be effectively subcontracting the performance of its obligations to the PTI. We have no objection to this mode of operation because we understand that the obligations themselves will remain with ICANN."

In other words, the new body at the heart of the plan would be effectively moot for one of the three functions.

This creates further problems, as other commentators noted. The rest of the plan is built around the idea of keeping the PTI in check. If two of the three IANA functions go directly to ICANN, that greatly reduces the value and authority of the new committees. The IAB even noted "we have no current intent to place IETF representatives on additional committees whose primary duty is to judge the effectiveness of IANA."

2. Who runs the new affiliate

The PTI will be a wholly owned subsidiary of ICANN, but after some back and forth, the group drawing up the plan decided that there should be a three- or five-person Board, with ICANN's Board allowed to choose three members and approve the other two. It is currently foreseen that someone who works for the PTI will be on the Board and others from the technical community also sit on it.

Several commentators argued that the Board should just be made up of a subset of ICANN Board members and be done with it. "Employees of PTI would not necessarily provide the requisite level of accountability, and the appointment of independent directors creates confusion as to who is ultimately responsible for carrying out the IANA functions," argued ICANN's Business Constituency.

At the same time, however, those same commentators argued that it was essential that the PTI Board focus only on very specific IANA technical issues – something that seems a little unrealistic given the importance of IANA to ICANN more broadly.

3. What is the separation process?

By far the most common concern was over the process for separating IANA from the PTI/ICANN at a later date.

The plan as currently written is vague and overly complex, requiring multiple committees and numerous steps before anything is done. There is a strong view that this whole approach needs some clarity, particularly over what specifically would result in a shift away from the PTI/ICANN. The hope is that if specific criteria are laid out, it would not be necessary to have so many groups and process steps.

Google said: "The CWG should provide more detail on the necessary criteria to invoke separation and put forth clear standards for determining if and when separation is appropriate."

The USCIB said: "We concur with the ICANN Business Constituency (BC) that the ICG proposal should clarify the escalation processes necessary to precipitate separation and adopt a standard for determining when separation may be appropriately considered. The current proposed separation process does not clearly indicate what the Names Community should do through discussions with ICANN or PTI to remedy problems before resorting to the dramatic step of separation."

And again the ICANN Board was also concerned: "In the case the IANA Functions are split, the ICG Proposal lacks detail on the process that each operational community will use to determine the escalation paths leading to separability, ensuring accountability of a successor, and identifying a successor IANA Functions Operator."