As if on cue, a statement has emerged from the I* organizations concerning the IANA functions transition. [1, 2, 3, 4] Unfortunately, the statement outlines a plan to simply give ICANN the IANA functions; it considers accountability an afterthought. The statement, circulated in the last few days on IETF and RIR lists, is described as

something that some leaders of technical Internet organisations have agreed is a reasonable starting point for discussing how the role of the USG can be transitioned to the Internet community.

Note that it is only the leaders, not the organizations themselves, that concocted this plan. Indeed, they have only started circulating the ideas among their member organizations yesterday, after publishing the statement. In their approach,

The roles of all Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, ccNSO, ccTLD ROs, and gNSO) stay unchanged. These bodies continue to hold policy authority for the protocol parameter, number, and name spaces, including responsibility to ensure the faithful registry implementation according to those policies.

Regarding the performance of the IANA function,

The IETF, IAB, and RIRs…are committed to the role of ICANN as the IANA protocol parameter and IP address registry operator. The accountability mechanisms for ICANN’s administration of these core internet functions will provide escalation routes that assure the names, numbers, and protocol communities that if IANA’s performance is lacking, those communities can pursue defined processes for improving performance, including pre-agreed independent third party arbitration processes.

The approach correctly identifies a need for accountability, but totally misses the mark suggesting that it can be accomplished with new processes. This is because it completely overlooks a major difference between the names, numbers and protocol governance structures. The policy making authorities for IP numbers and protocol parameters (the RIRs and IETF, respectively) are structurally separated from the IANA functions operator (ICANN).  This is not the case with the names policy authority. The Generic Names Supporting Organization (GNSO) is a wholly-owned and operated part of ICANN. Because it is a part of ICANN, the ICANN board and staff play a huge role in the policy process. Indeed, it would not be an exaggeration to say that the GNSO merely makes policy suggestions to the ICANN board, which the board modifies and renegotiates as it pleases. Often the ICANN board and staff make major changes in policy while claiming that it is only “implementing” GNSO policy.  It is this structural deficiency which is corrupting bottom-up, multistakeholder DNS policy making. And because of it, as Councillor Maria Farrell put it at the Singapore ICANN meeting yesterday, the GNSO is “dying the death of a thousand cuts.”

The I*  ICANN_blueprintapproach tellingly mirrors the blueprint being foisted upon stakeholders by Fadi Chehadé which eliminates all structural separation in the domain name space. The blueprint claims to retain functional separation between the activities. But as we’ve noted, once the USG contract ends, what ensures that functional separation continues to exist? Answer: nothing. Under Fadi and the I*’s approach, ICANN management would be fully in charge of both policy making and root zone implementation and maintenance. No external authority or contract would be in place to keep them in check.

How to remedy this? The solution is plain to see – structural separation of domain name policy making and root zone implementation. We have been hammering home the idea since the release of our proposal March 3. Structural separation should be a key principle of the transition. One way to bring it about would be to structurally separate IANA functions from ICANN, as suggested in IGP’s proposal. Another alternative might be to structurally separate the GNSO from ICANN. In other words, leave the IANA functions with ICANN, but pull out the GNSO and make it a separate organization with its own management and board. That may sound radical, but it was actually the original plan of Jon Postel and the early ICANN years. Indeed, one of the proponents of the I* statement, ARIN Director John Curran, was a strong advocate of this “separate DNSO” model, for reasons that parallel our advocacy of structural separation.

Rumor has it the Commerce Dept has spoken with Chehadé, letting him know any proposal that is not developed by the stakeholders will be unacceptable. It’s time to put Chehadé and the I*’s flawed attempts to drive the process to rest.

 

6 thoughts on “Fadi’s railroad: Are the I* organizations getting on board?

  1. Brenden – Interesting posting. For clarity, the fact that ICANN had an original model with independent supporting organizations with primary policy development duties does not necessarily mean that such a model is desirable today. ICANN’s evolution over more than a decade must also be taken into consideration, as well as the key requirements for any transition, “stability” in particular.

    The NTIA IANA Function contract has indirectly served a “safety net” should ICANN take a serious fall, but ICANN is far more mature than when that originally was put in place, and it is not apparent what additional mechanisms (if any) are necessary before the net is removed.

    Given the risk involved with any structural changes, it will take a very carefully thought out plan to credibly propose that the better solution is to crack ICANN open and begin rearranging pieces, particularly when contrasted with the option of adding additional mechanisms for accountability to the existing system.

    The ARIN community has not considered this matter yet, so the above should be considered solely my observations of the situation.

    Thanks!
    /John

    John Curran
    President and CEO
    ARIN

    1. Thanks, John.
      Actually both options involve structural changes and risks. Let’s not forget that the IANA functions are _already_ ‘cracked open’ and you are proposing to merge them together. That is to say, the Verisign part would have to be moved into ICANN/IANA if the I* suggestions are followed. You are proposing to move root zone maintenance into ICANN, we are proposing to move the IANA functions into the root zone maintainer. Both options involved structural changes. Presumably you are talking about technical risks, but IMHO the economic and political risks of an out of control ICANN with control of both policy and operations for DNS far exceed the identifiable and surmountable operational risks of moving IANA out of ICANN.

  2. Brenden,

    I agree with what John said. In an Internet Draft that documents the IAB’s IANA evolution program thinking on this we put stability as one of the principles. But the separability of roles you (Brenden) stated as a principle, we included as well.

    See http://tools.ietf.org/html/draft-iab-iana-framework (currently) section 3. That framework also identifies separate roles for what we call ‘evaluation coordination’ and ‘publication/maintenance’. In other words those may be separable functions (e.g. Coordinating the evaluation of a rede legation request, and getting the result publish in a Registry and the DNS).

    Also allow me to refer to mailFrom the IAB chair which documents some principles around a transition of the protocol parameter registries.

    Observations on personal title,
    —Olaf Kolkman

    1. Thanks Olaf,
      In addition to stability, separation of roles, and accountability and transparency, the IAB draft also mentions the ability “to delegate any of the roles for registries or parts thereof” – all good principles. However, there is a need to be more specific. What is being pushed by ICANN is to bring the IANA role within the same organization with some form of functional separation. Only by structurally separating (i.e., placing them in different organizations) can we achieve external accountability of the policy and IANA roles for names. In our proposal, ICANN would be held accountable _for_ policy making _to_ the DNSA. The DNSA would be held accountable _for_ implementation _to_ ICANN.

      BK

Comments are closed.