But a September 22 letter from Congressmen Grassley, Goodlatte, Issa and Senator Cruz has changed the tune; now it’s more like “send in the clowns.”

This letter asks for yet another GAO report on the transition. Specifically, the Congressmen want to assert that the U.S. government “owns” the root zone file, and thus reframe the transition as a “transfer of U.S. government property to a private entity.” Since such a transfer would require Congressional approval, this is Congress’s new way of attempting to assert its authority over the transition. And it is clear from the letter that by asserting this authority certain representatives want to prevent the transition from happening.

The letter asks three specific questions:

1. Would the termination of the NTIA’s contract with ICANN cause government property, of any kind, to be transferred to ICANN?
2. Is the authoritative root zone file, or other related materials or information, United States government property?
3. If so, does the NTIA have the authority to transfer the root zone file or other related material or information to a non-federal entity?

We here at IGP can save Congress and the GAO a lot of time and trouble. We can answer these questions, and we’ll do it at a fraction of the price (we’ll send a bill later to Senator Cruz’s campaign committee) and much, much faster. The answer to the first two questions is ‘No.’ Once those questions are answered in the negative, the third question becomes irrelevant.

To support our answers, let’s begin by taking up the question: What is the ‘property’ that the transition would transfer? There are only two possible candidates: one is the DNS root zone file (RZF), the other is the physical and software facilities involved in operating or publishing the authoritative root zone.

Is the RZF property? And if it is, can it be considered U.S. government property?

The Congressmen may need some education regarding the RZF and its functionality. The RZF is a text file that contains a list of top level domains and information about the nameservers that support them. You can look at it here. Where does this data come from? It comes from the registries who run top level domains. They all need to get this data in the RZF or their domains don’t work on the Internet. The registries who supply the data that is compiled in the RZF come from all over the world (in other words, they are not all in the U.S.A.). They give it to IANA, which updates the RZF and sends it off to NTIA for approval and to Verisign for publication.

The RZF is not like a copyrighted movie or photograph, to which an owner restricts access so that users can be charged. It is, rather, a pooling of data about private name servers into a publicly accessible resource so that any domain name user in the world can connect to any other domain name user in the world. The whole point of pooling data about registries’ privately run name servers into the RZF is to get it openly and globally shared.

The U.S. government does not own the RZF and nothing in its contractual relations with ICANN or Verisign asserts that it does. By ending the IANA contract, the US government is not transferring “ownership” of the RZF to a private party; it is ending its contractual authority to approve any changes to the RZF before Verisign publishes it. This approval authority, by the way, does not even live in the IANA functions contract. It is part of NTIA’s Cooperative Agreement with Verisign. The amendment asserting U.S. approval authority was inserted into that agreement without Congressional approval, and it is hard to understand why it could not be eliminated without its approval. As a GAO report from 2000 concluded:

The Department undertook its domain name system management responsibilities to carry out the President’s directive to support efforts to privatize the domain name system. Under these circumstances, neither the Department nor any other federal agency is under an explicit statutory obligation to manage the domain name system including control over the authoritative root server

Nothing in the IANA functions contract asserts federal ownership of the RZF. On page 31 of the contract (section F.5) there is a statement that “All deliverables provided under this contract become the property of the U.S. Government.” The deliverables are specifically enumerated in section F.4. They include things like an audit report, a customer service survey, instructional documentation for users, a root zone management dashboard, and similar kinds of reports. The root zone file is not listed as a deliverable. No other part of the IANA Functions Contract can be construed to give the federal government an ownership right to the RZM.

What about the materials and facilities that make up the infrastructure for publishing the RZF? There are 13 root servers that publish the RZF. Most of that infrastructure for publishing the root zone is owned by private organizations both inside and outside the United States. There are three exceptions: root servers are run by NASA, the U.S. Army Research Lab and the Defense Department NIC. But these federally-operator root servers would not be transferred or changed by the IANA transition. They would continue to publish the authoritative RZF as before.

This attempt to find an excuse to block the transition is likely to fail on the merits. But aggressive assertions by rightwing politicians that the U.S. “owns” the DNS, or the entire Internet, are destabilizing and counterproductive. They actually help to further the agenda of the governments who want to undermine the private sector-based Internet governance model on which ICANN is based. Assertions of control by one state cannot help but produce equal and opposite reactions from other sovereigns.

Making a huge tactical error, the CCWG acccpts the proposed meeting date and time, allowing ICANN to lure them into a meeting on its own turf. In its PR announcements, ICANN frames the meeting as a “dialogue” – implying that there are only two actors, ICANN and the CCWG, and the main topic they will discuss is the board’s objections to the CCWG plan and ICANN legal’s counter proposal. Over two days, the CCWG’s agenda is completely dominated by the complaints of board members and ICANN staff about their proposal.

A sample of the transcript provides the flavor of the interactions. Former board member Sebastien Bachollet complained that there is no need for a community power to remove board members because the board can already do that. Current board member George Sadowsky agrees, claiming “It’s absolutely surreal that the removal of the entire board is demanded by the [CCWG]. I wouldn’t spill the board and this…it’s a very destabilizing event.” CCWG Co-chair Thomas Rickert then reminded the board that “the existence of the community power to spill the board is indisputable. It’s been on the table in our first report, we got overwhelming community support for it. It’s a CCWG requirement to have this community power…”  The board members should know this, if they have followed the process at all. Yet here they are trying to reverse it.

Yet another board member, Chris Disspain, tried to turn the tables on the CCWG. “It isn’t enough to simply say, ‘we make up the SO’s and ACs and therefore what we say goes. You’ve got to be accountable. …the question becomes to whom are you accountable?” Nice one, Chris.  You’re not quibbling with specific reforms, you’re suggesting that the whole plan be scrapped and refocused on reforming ICANN’s participants. But it wasn’t the problems and abuses associated with ICANN participants that led to the calls for accountability reforms, and it wasn’t the community that was overseen by the U.S. government: it was you, ICANN.

Fortunately Jordan Carter was there  to challenge this nonsense:

The ICANN board is the governing body of a corporation with a budget of $100 million plus, 300 staff, control over the root of the Internet …operating the IANA functions.  That is the body that is being held to account by these [CCWG-proposed] powers. Compared with that, the SOs and ACs …have some very narrowly scoped powers by which they hold that governing body with all those resources and power and influence and responsibility to account. so it just isn’t right to say that the SOs and ACs or the community needs to be held to account in a symmetrical fashion.

The mere fact that Disspain would suggest turning the tables in that way tells speaks volumes about the mentality inside ICANN.

The CCWG’s and CWG’s lawyers provided a review of the ICANN board’s counter-proposal that makes the issues very clear. Under ICANN’s so-called “Multistakeholder Enforcement Mechanism” (MEM) the board could always invoke its “fiduciary duty” to overrule community empowerment mechanisms. Then conflict would have to go into arbitration, and in which the standard for overturning the board would shift dramatically in ICANN’s favor.

So the choice being faced in Los Angeles is a stark one: do we want to make ICANN accountable or not? And if not, can we actually have an IANA transition? Will there be any support for it? A growing number of people would prefer the status quo (U.S. oversight) to an ICANN without a membership and the CCWG-proposed community empowerment mechanisms.

We urge the CCWG to stand firm. It must resist the full court press, consider the full gamut of public comments, and continue with improving its membership plan. In its discussions in LA, the ICANN board counter-proposal should not be given privileged status over the comments of the other stakeholders; the CCWG’s task at this point is to modify its proposal as necessary to obtain the broad community consensus required. They are not in a dialogue with ICANN, they are in the end game 0f a vital reform process in global governance that involves the entire global multistakeholder community.

For months the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability), with the help of independent lawyers, considered possible models that would give the community the power to hold the Board and ICANN staff accountable. After months of discussions, hundreds of hours of meetings online and face-to-face, and one round of community comment, the CCWG’s proposal offered a sole membership model to empower the community and enable them to ultimately go to court to challenge the actions or inactions (with many caveats) of the Board and staff under certain circumstances. The conditions to challenge the Board and staff in court are very strict. CCWG-Accountability’s team of independent lawyers, based on the community requests, found ways to provide a balance between community empowerment and the stability of ICANN.

But the Board was having none of it. Again and again they insisted that they agreed with the community on principles, and then suggested an implementation plan that weakens or undermines all those principles. They proposed to eliminate the possibility of going to court from the proposal and replace it with an arbitration mechanism. This they called, quite misleadingly, the Multistakeholder Enforcement Mechanism. In their enforcement plan, which is sketchy and entails only 4 bullet points (as opposed to the CCWG-Accountability’s 100-page proposal), the arbitration panel will be paid by ICANN, which undermines the neutrality of the panel, and the binding arbitration award will be enforceable in California court. Moreover, they don’t want the community to challenge the strategic plan or the budget. Their argument for changing the membership model to “MEM” is: we should not change the governance structure of ICANN drastically and the membership proposal does that. They also repeatedly said the proposal has unintended consequences, which they were unable to elaborate on during the call.

Why does the board’s plan sound like it defeats the whole purpose of the accountability working group? All this time we’ve needed a strong enforcement mechanism – not necessarily to take ICANN to court, but to put them under the “shadow of the law.” The possibility of legal action by members (who have specific rights under California nonprofit law) stops ICANN from easily disregarding the community’s policies. The board proposal would blunt the community’s ability to challenge ICANN’s decisions with layers and layers of process. For example, a court judgement is enforceable on its own, but an arbitration award has to be enforced in a court of law if ICANN does not voluntarily abide by it. An arbitration award can only be challenged based on due process violations and can be petitioned to be vacated, hence prolonging the process. Moreover, an arbitration award cannot be challenged based on the merits of the case, so they are seriously limiting the community’s access to court if we want to challenge ICANN’s actions or inactions.

The way the Board reacted to the accountability proposal exemplifies the very reason why we need a strong accountability mechanism. After months of deliberations, hours of voluntary work, many consultations with the independent lawyers — engaged at great cost to ICANN (and their support for this independent advice was exceptional, and perhaps useless) — the Board suddenly decided to turn the tables. The Board has followed the process from the beginning, but this sudden and intense reaction came in the final stages of proposal development. There can only be one reason for such a reaction to the sole member mode proposal: the legal advice they received from their Jones-Day and in-house lawyers. Are they shielding themselves, or are they rescuing ICANN for our sake because we poor little volunteers don’t understand the consequences of the CCWG proposal?

The legal team working for CCWG-Accountability provided an incisive analysis of the ICANN legal team’s critique of its proposal, summed up in these two bullet points:

• The [Jones-Day] Analysis does not identify any legal flaws or legal “workability” issues with respect to…key elements of the Second Proposal.

• The [Jones-Day] Analysis does not identify any significant issues that the CCWG, its working groups and/or its advisors have not already considered.

Should we really treat ICANN board’s decision seriously and give it a serious consideration? They cannot reject the proposal, but what will happen if ICG sends the proposal to NTIA with a note from ICANN board that it does not accept it? Regardless, we need to wait to see the results of the public comment period.

The dilemma I am referring to is this: does the GAC want to participate in the community empowerment mechanism as an organization, with voting seats, or does it want to have a privileged advisory role like it has today with respect to the ICANN board? Or does it want both?

I’ve been reviewing the transcripts of the ICANN 53 (Buenos Aires) meeting in an attempt to understand how GAC might be approaching this question.

Some people defend making the GAC part of the community empowerment mechanism by invoking the concept of “equal footing”  for stakeholders. While reading the transcript today I was hit over the head with reminders of how wrong this argument is. Here are the simple facts:

1. The GAC does not have equal footing now, it has superior footing.
2. The GAC knows this.
3. The GAC does not want equal footing in the future, it wants to retain its superior footing.
4. Some members want to further strengthen their ‘footing’ to make it even more superior

It’s all written down in black and white, in multiple languages, from the June 21st, June 23rd and especially the June 24th transcripts. The GAC members realize that the privileged status of their advice under the ICANN bylaws gives them an extraordinary amount of influence over ICANN’s policy making process.

Here we see the UK representative to the GAC worrying about whether empowering the community will make GAC lose its superior status.

UK: “we have our first amongst equals status under the current arrangements, and we are grappling with how to ensure that that is retained against proposals which are going to empower other parts of the community in the successive regime.”

Portgual chimed in with an even stronger claim. The power of governments within ICANN to define policy should be unlimited:

PORTUGAL: “our position is that the public-policy issues obviously have to be dealt with by the government. Obviously governments [should] not be limited in [any] respect. So any wording in the proposal or in the text referring to what the governments do or don’t do within a certain boundary, provided that there is a limitation to the role of governments, I think that this would be unacceptable, because you cannot limit the role of governments in these kind of issues. At the same time we need to be first among equals.”

How about America, land of the free?

USA: So I couldn’t agree more with Portugal. We are first among equals. We wish to see that continue.

The quotation above ought to be a very nice antidote to what I call L. Gordon Crovitz disease, the idea that America is exceptional and it’s only other governments, not governments per se, that we need to worry about in the transition. (But Crovitz never let facts get in the way of his arguments.)

Spain made a ringing endorsement of the unequal footing argument:

SPAIN: From our point of view, we have to maintain the status quo of GAC as first among equals within the ICANN ecosystem. This is key.

Indeed, Spain wins my prize for the GAC’s most ardent statist. Their representative worried about the possibility that an empowered community might “defy ICANN board decision that are based on GAC advice.” Something needed to be done about that, Spain suggested:

maybe we can think of reasons or instances in which the community could not exert their powers against government decision — board decisions based on government advice.

Brazil, showing that little has changed there since 2005 (or 1895), had this to say:

And that’s why, therefore, [we] support in the new ICANN accountability framework a more significant involvement of governments that goes beyond the merely advisory role that the GAC holds today.

China sounded a similar theme:

We cannot make the conclusion right now to say the GAC will forever just be advisory body,

Solidarity among the BRICS: here’s RUSSIA:

…we totally agree with Brazil that this level of decision-making and the role of governments cannot be lower than it is today at this level.

Very nice to see the harmonious relationship between the US, Russia, Brazil, China and Europe here. The world’s states are united in their determination to preserve and possibly expand their power at the expense of the Internet community! Out of fairness, let me note that Denmark offered a word of caution:

from a Danish point of view, it’s very important that nobody, no individual, no organization even government can capture the organization in the future. That’s why we think it’s important to keep the rule that the Board only have to take into account the GAC advice when it’s in consensus.”

These sobering facts need to be reflected in our assessment of the CCWG proposal for enhancing ICANN accountability. The CCWG proposal would make the GAC a voting member in the community empowerment mechanism. This concept is usually rationalized in the name of “equal footing” for different stakeholders, but the GAC transcript blows their cover: They are first among equals and they revel in it. Governments would only use participation in the community mechanism to protect that special status and would probably attempt to expand it.

This blog has criticized including Advisory Committees in the community mechanism, but I, at least, am reconsidering> If we give GAC equal status in the community mechanism and TAKE AWAY their special advice status, we are closer to “equal footing” than we are now. Indeed, it may be that the privileged advisory power is more dangerous and distortive of ‘equal footing’ than their participation in the community mechanism would be. While many of us assume that GAC’s “Advisory” status limits its power, in fact when it is used strategically it elevates governments above all other stakeholders in the policy making process. If one reviews the history of the new TLD program, for example, one can see how GAC advice was repeatedly used to provide the “last word” that could delay, hijack and change the policy developed by the GNSO. So maybe we should force the GAC to choose between privileged advice or participation in the community mechanism. Or, maybe we should actually prefer their inclusion in the community mechanism to continued special status of advice.

Two things to avoid like the plague:

• Giving GAC BOTH privileged advisory status AND participation in the community mechanism
• Giving GAC a similar privileged advisory status over the community mechanism (e.g., GAC would not participate directly but would “advise” the empowered community, which would translate into an effective veto, delay or dilution of the community’s powers).

It seems unlikely that the special advisory power would be taken away. So if we don’t oppose their inclusion in the community mechanism, there is a risk that they will get both. Indeed, it seems highly likely to me that many members of GAC will respond to the CCWG dilemma by demanding option 1) or 2).  The Internet community needs to be alert to this threat. Reassuring aphorisms about “equal footing”  can obscure a rather Orwellian reality that all animals are supposed to be equal, but some are more equal than others.

After more than a decade at Syracuse University, the Internet Governance Project is now part of the School of Public Policy at the Georgia Institute of Technology. The move comes as a consequence of the Georgia Tech’s recruitment of Dr. Milton Mueller, who departs from the Syracuse School of Information Studies to join the School of Public Policy at Georgia Tech in Atlanta. Postdoctoral researcher Dr. Brenden Kuerbis, one of IGP’s key contributors, will also be working for Georgia Tech as of mid-August.

IGP will continue to be independently funded and operated center that bridges scholarship and participation in Internet institutions. Yet at Georgia Tech’s School of Public Policy, IGP will be in a much richer environment for public policy-related research and analysis. We will be able to work more closely with one of IGP’s original partners, Dr. Hans Klein, and we will have stronger connections to Tech’s world-renowned computer science researchers, policy researchers in other schools such as Peter Swire, and international relations scholars. Plans are underway for a seminar series and workshops in the fall of 2015 and the spring of 2016. Stay tuned.

The most interesting part of the announcement, however, was not the extension itself but the way the NTIA has finally started to come to grips with the role of Verisign and changes in the root zone management process. Along with the extension announcement, NTIA published a proposal “Root Zone Administrator Proposal Related to the IANA Functions Stewardship Transition.” As we noted in a blog post back in March 2014, it is really the Verisign Cooperative Agreement, not the IANA functions contract, that gives the US government authority over all root zone file changes. It is Verisign, not ICANN, that has operational control of the root zone, so if the Cooperative Agreement with Verisign doesn’t go away, neither does U.S. control of the DNS root.

The procedures for modifying the root zone are one of the most vitally important aspects of the transition from an operational and security standpoint. The Cross-Community Working Group (CWG) on the domain names part of the IANA stewardship transition took a stab at defining the basic outlines of the changes. Its so-called “Drafting Team F” report called for the elimination of an authorization role altogether and a formal study be undertaken post transition to investigate whether there is a need to increase the robustness of the operational arrangements for making changes to the Root Zone.

It is good that the NTIA has finally started providing more detail about what kind of changes are in store for us regarding Verisign’s role. It is not unreasonable for it to have waited to see what kind of a transition proposal was taking shape before starting to figure out how to modify the Cooperative Agreement. At the same time, the announcement raises eyebrows. As has happened so often in ICANN-related matters, some of the most important issues end up being negotiated quietly and secretly rather than developed through an open multi-stakeholder process. This announcement is another example of that. The proposal was prepared by ICANN and Verisign at NTIA’s request. The request was never made public and no one involved in the CWG (other than Verisign, of course) knew this was happening.

The actual proposal is not inconsistent with the DT-F proposal. The operational detail largely covers “the parallel operation period,” i.e., the overlap between the old system and the new, which DT-F identified as an issue. In the proposal, the legally separated Post-Transition IANA (PTI) will take on an authentication role. It will be conducting the validation of Root Zone Change Requests (“RZCRs”) by top level domain operators, presumably according to set validation rules (did it come from an authenticated source, does it comply with data formats, etc.).

That’s probably a very good idea. But the acceptance and implementation of this proposal depends on the mutual agreement of NTIA, ICANN and Verisign alone, so it doesn’t matter what you or I think. Indeed, the proposal says that

“It should be noted that nothing in this proposal is intended to preclude alternative RZA transition mechanisms being jointly proposed by ICANN, Verisign, and/or NTIA. In the event an alternative RZA mechanism is identified in advance of the IANA stewardship transition, it can replace the mechanism proposed in this document by mutual agreement of all parties.”

So it is NTIA, ICANN and Verisign that matter in this negotiation, not the rest of us.

Even though this proposal adds some information to what was a total vacuum before, there are still a lot of unanswered questions. An important detail left hanging is the nature of the contract between ICANN and Verisign. The proposal states:

“It is anticipated that performance of the RZM function would be conducted by Verisign under a new RZM agreement with ICANN once the RZM function obligations under the Cooperative Agreement are completed…”

Is ICANN the principal of this contract? If so, could it choose to make someone other than Verisign the RZM manager? If it can not choose another operator, what kind of an agreement, and with whom, prevents it from doing so? Does Verisign get paid for doing this? Answers to these questions are a vital aspect of the transition, but the involved global multi-stakeholder community seems to have no role in answering them.

The announcement also suggests that NTIA and Verisign will continue to have a Cooperative Agreement post-transition:

“The Cooperative Agreement between NTIA and Verisign will continue. Once the parallel testing for root zone management has proven capable of performance in the absence of the RZA / NTIA role and the IANA Stewardship transition implemented, NTIA and Verisign will amend the Cooperative Agreement as appropriate.”

The CA will be amended? Not ended? What exactly does that mean? Perhaps the perceived need for a continued Cooperative Agreement comes from the problem of liability for root zone changes. Verisign is effectively immunized from antitrust liability for root zone changes under the current arrangement, where the U.S. government acts as a shield against a private actor being in control of an essential facility. If the U.S. goes away entirely, that immunity might be lost. That may or may not be why the NTIA says the Cooperative Agreement “will continue”  – but we don’t know, and neither NTIA nor ICANN nor Verisign is enlightening us.

To conclude, the NTIA-ICANN-Verisign triumvirate seems inconsistent with the overall ethos of open, bottom up development of a transition plan. There are reasons why this is a sticky issue, of course. Still, the U.S. government and ICANN have to be very careful about how they handle this. If the “global multi-stakeholder community” invoked by the original transition announcement goes through an arduous process to replace the IANA functions contract only to learn that Verisign and NTIA still have a compact that gives the U.S. control of root zone changes, their credibility – and the credibility of the entire process model used to develop the transition – will be shot, and the ‘transition’ will have done more damage than good to globalizing Internet governance.

After much deliberation, the CCWG settled on a sole, incorporated “member” representing the various stakeholder bodies as the legal means by which community powers would be enforceable on ICANN. The community powers are what will, in the absence of the NTIA’s ability to yank the IANA contract, hold ICANN accountable to the global stakeholder community. The community’s powers will include:

• Power to reconsider or reject the operating plan and budget
• Power to reconsider or reject changes to ICANN “standard” Bylaws
• Power to approve changes to “Fundamental” Bylaws (including bylaws pertaining to enforcing IANA function reviews outcomes)
• Power to appoint and remove individual ICANN directors
• Power to recall the entire ICANN Board.

This “member” could take action upon a vote facilitated by a proposed Community Mechanism. Of course, the devil is in the details of who is included in a Community Mechanism and how it would operate. The CCWG’s initial proposal gave 5 votes each to the GNSO, ccNSO, ASO, GAC and ALAC, and 2 votes each to the RSSAC and SSAC.  We previously argued that such an allocation was unwise and unfair, because it inappropriately allocated votes to advisory committees – including committees appointed by the ICANN board. Nonetheless, the CCWG states that:

This proposed voting weight is unchanged from the proposal made in our first Public Comment Report, and attracted the most support from CCWG-Accountability participants during the last meetings finalizing this Report. (51)

However, several alternative configurations have now been floated, as shown in Figure 1 below and described in the report:

One is that there should be a distinction in voting authority between SOs and ACs, with SOs having greater voting influence (e.g. 5 votes for SOs, 2 votes for ACs). [Alternative 2 below]

Another view is that there should be five votes allocated to each of the SOs and ACs. [Alternative 1 below]

A third view is that there should be four votes each for ASO, ccNSO, and GNSO, and two votes for ALAC. The GAC, the SSAC and the RSSAC would participate fully in discussions in the ICANN Community Forum (introduced in Section 6.3) but would not vote in the Community Mechanism. [Alternative 3 below]

It’s useful to compare these alternatives to the way the ICANN board is selected. This comparison is important for two reasons: one is that the ICANN board will continue to be ultimately responsible for the policies adopted as well as many other corporate governance decisions. Second, early on a CCWG legal scoping identified that “ICANN’s existing organizational framework represents a balancing of interests, and these mechanisms should not upset that balance.”

As Figure 2 below shows, half of ICANN’s sixteen-member board is directly placed by four sending bodies, along with ICANN’s CEO. Each of the SOs elect 2 members (for a total of 6 or 75%), and since 2010 the At-large Community elects one (or 12.5%). The other eight board members are indirectly selected by ICANN’s Nominating Committee, which was created by the 2002 “Committee on Evolution and Reform” (CER). Within the Nomcom selection structure, the ALAC has 33% of the vote by virtue of being the only body represented in Nomcom along regional lines.

If you put these two board selection mechanisms (Nomcom and direct election) together into a weighted average, the Advisory Committees select 3.64 board members out of the total of 16, or 23%, just less than a quarter of the total. The SOs account for the remaining 77%. Even if the denominator is decreased to 15 (accounting for ICANN’s CEO on the board), the weighted average only increases to 24%, still less than a quarter of the total.

Compare that to Alternative 1, which gives the ACs 57% of the voting power or even Alternative 2, which gives ACs almost half of the voting power. If it wasn’t clear before it should be now: the CCWG’s currently proposed vote allocation would be a substantial departure from the current distribution of votes and board members. It would constitute a dramatic shift of power in ICANN, enough to change the way it functions entirely.

The CCWG has tried to rationalize its vote allocation proposal by claiming that regional representation brings greater diversity of views:

The logic for 5 multiple “votes” per participant in the community mechanism among the five SOs and ACs allocated this number is to allow for greater diversity of views, including the ability to represent all the ICANN regions in each participating group.

This is a misleading argument. Even if one accepts the dubious premise that selecting one representative per world region improves “diversity” (as if everyone in a multi-billion person population had the same views), a shift to regional representation does not have to alter the balance of voting power. The CCWG could have proposed to alter the overall number of votes in a way that allowed the SO/AC proportions to remain the same. For example, it could give the SOs 10 votes (2 from each region). Or it could decouple votes from representation, and allow ALAC 5 participants but only 2 votes.

Building accountability structures according to regional lines only makes sense for bodies organized along regional or territorial lines, like ALAC and GAC.  That is why these bodies continue to push for 5 votes per body.

To conclude, Alternative 1, which gives 5 votes to all the ACs and SOs, would be a radical revision of ICANN’s makeup and should be eliminated from consideration immediately. Alternative 2, which allocates votes to all Advisory Committees, has serious problems which we noted before, including the obvious conflict of interest involved in relying on board-appointed people to keep the board accountable. Only Alternative 3 most closely reflects today’s distribution of power and should be the path forward.

In each operational community developing a transition proposal, the IANA trademark and domain were either major sources of controversy (protocols and names) or centerpieces of the actual proposal (numbers). The task of coordinating the different approaches to those assets has been the most significant compatibility problem – perhaps the only real compatibility problem – faced by the IANA Stewardship Coordination Group so far.

Why does this matter? There are people who say it doesn’t, but they are wrong. As we will explain, the fate of those assets is fundamental to the proper execution of the transition, and if it is not handled right, the whole transition could founder.

Historical background

ICANN was given the trademark and domain by the University of Southern California’s Information Sciences Institute when it was first created. According to ICANN’s first proposal to the Commerce Department, in negotiating the transfer of the trademark for IANA from USC to ICANN:

ICANN and USC-ISI concluded that this optional acquisition was appropriate because, although transfer of title to the intellectual property is not necessary to secure ICANN’s right to use the intellectual property to perform the IANA function, it is more appropriate that ICANN, as the new contractor, take responsibility for any effort or costs associated with maintenance or enforcement of the intellectual property.

At the time, ICANN was perceived as the home for the IANA and the direct successor of Jon Postel’s ISI. Postel himself was slated to be the CTO of ICANN before he died, and he conceived of ICANN as an umbrella organization that would be the institutional meeting point of the names, numbers and protocol communities.

ICANN has changed, and so has the whole environment around IANA since then. By internalizing the domain name policy making function, ICANN has become dominated by domain name policy and money. The concept of IANA as a severable, contractual relationship, first introduced by a suspicious IETF in 2000, did not exist in 1998 – or insofar as it did, the principal in the contract was the US government, not three operational communities.

The contracted model

Today, the IETF views the IANA functions as a vital but essentially clerical task that they outsource to ICANN. Although the choice as to who is the IANA functions provider was pretty much made for them by the US Government, the regional numbers registries also aspire to have, like the IETF, a severable contractual relationship with ICANN to provide IANA functions. Both communities insist on the right to change their IANA functions provider if it doesn’t perform to their specifications.

Thus for the numbers and protocol communities, it’s clear that the IANA functions provider (which happens to be ICANN now and is likely to be PTI in the future) should not own the trademark or the IANA.ORG domain name. Ownership of these assets by a specific contractor erects a major barrier to their ability to change providers at will. Aside from the higher switching costs, it is simply bad business practice to let IPR that is core to any entity’s mission reside in the hands of a mere contractor. For example, if Citibank chooses to outsource some of its banking functions to a third party, its managers would not dream of giving the contractor ownership of the Citibank trademark or the citi.com domain name.

That is why the numbers community proposed, as part of its transition plan, to divest ICANN of the IANA trademark and domain name.

With regards to the IANA trademark and the IANA.ORG domain, it is the expectation of the Internet Number Community that both are associated with the IANA Numbering Services and not with a particular IANA Numbering Services Operator. … It is the preference of the Internet Number Community that the IANA trademark and the IANA.ORG domain name be transferred to an entity independent of the IANA Numbering Services Operator, in order to ensure that these assets are used in a non-discriminatory manner for the benefit of the entire community. From the Internet Number Community’s perspective, the IETF Trust would be an acceptable candidate for this role.”

For a variety of reasons, none of which were very intelligent, the IETF’s IANAPLAN Working Group stopped short of asking for the transfer of the assets away from ICANN. Instead, it merely called upon ICANN to acknowledge that the protocol parameter registries are in the public domain and to acknowledge that, if IETF chooses to change IANA functions provider, it will work with the new provider to minimize any disruption caused by its ownership of the domain or trademark. In fact, the status of the IANA-related intellectual property was a divisive and controversial issue during the IANAPLAN deliberations, as many participants pushed for divestiture. But the division was healed retroactively when the numbers community released its plan. Asked by the ICG to clarify whether its proposal was consistent with that of the numbers community, the IANAPLAN WG indicated that it had no objection to such a divestiture, nor to the IETF Trust serving as the repository for the assets. In effect, the proposal of the numbers community had validated the views of the dissenters in the IANAPLAN WG, and everyone was more or less on the same page.

Names and the IANA-centric model

What about names, then? With its recently-approved CWG proposal, the domain name community is also striving towards a more arms-length, contractual relationship between ICANN and its IANA department. They have chosen to make the provider of the names-related IANA functions into a separate legal entity that has a contract with ICANN, even though this entity, the Post-Transition IANA (PTI), is a controlled affiliate of ICANN. Severability of this contract is possible here too, at least in theory, because the CWG proposed to institute a periodic review of the IANA functions. One possible outcome of the reviews is a decision to change the IANA functions provider for names.

But the CWG proposal has an odd wrinkle in it. It contains a very drafty term sheet that could be the precursor to the ICANN-PTI Contract. That term sheet contains the following language:

ICANN will grant PTI an exclusive, royalty-free, fully-paid, worldwide license to use the IANA trademark and all related trademarks in connection with PTI’s activities under the ICANN-PTI Contract.

So in effect the proposed term sheet not only assumes that ownership of the IANA trademark remains with ICANN, it also proposes to grant to PTI an exclusive license to use it. That suggestion is totally incompatible with the proposal of the numbers community. Moreover, it was never discussed or approved by the CWG-names as a whole. Faced with protests from the numbers community, indications of discomfort from the protocols community and opposition within the names CWG, the chairs of the CWG-names have distanced themselves from the trademark language, stating:

…the TM related language in the Final Proposal is preceded by other text and contained in square brackets such that the Final Proposal effectively does not make a specific proposal with regard to the trademark.

But the author of the disputed term sheet – Greg Shatan, a trademark attorney and chair of the Intellectual Property Constituency in the GNSO – continued to argue for his position. He also targeted for criticism the idea that the IETF Trust would be an appropriate home for the trademarks and domain. The next section outlines the arguments for and against ICANN controlling the trademarks.

The Case for PTI or ICANN controlling the Trademarks

In a message sent to the CWG list, Shatan laid out his argument for why he wants ICANN or PTI to hold the trademark. “The owner of a trademark should be the ultimate source of the goods and services offered under that trademark. In the most straightforward case, the trademark owner offers those goods and services themselves or through a subsidiary. The trademark owner can license the mark to third parties to offer goods and services under the mark; but, consistent with their status as the ultimate source, the trademark owner is required by law to exercise continuing quality controls over the goods and services offered by the licensee and the use of the trademark by the licensee. A trademark owner cannot merely “hold the asset” as the numbers team proposed. Ownership of a trademark fundamentally involves being the “source or origin” of the goods and services and fulfilling the “quality control” oversight role, among other things.” Shatan goes on to say

I don’t see how the IETF Trust makes legal sense as the owner of the IANA Trademarks. The IETF Trust is not and does not intend to be the ultimate source and origin of IANA services. Unlike copyrights and patents, trademarks can’t be owned by administrators; they need to be owned by the source of the services. Further, the IETF Trust is clearly not granting ICANN the right to provide the IANA Services, so it is even more inappropriate for the IETF Trust to be the owner of the mark associated with those services.

Shatan’s view is thus based on a straightforward application of basic concepts in trademark law. (The problem is that he doesn’t quite understand what IANA actually is, confusing the IANA functions operator with the IANA itself; more about that below). Shatan also issued some rather interesting critiques of the IETF Trust as the proper home for the trademarks.

In a trademark license, the IETF Trust, as licensor, would have the power to terminate the license according to its terms (e.g., for material breach of the agreement, misuse of the trademark, etc.) or to decide not to renew the license, in which case ICANN would no longer have the right to use the IANA trademark in the provision of services. It would be inappropriate for the IETF Trust to have this power, without accountability to and oversight by the names and numbers communities. A mechanism would need to [be] built for that.

So he is not only suggesting that IETF should not hold the assets; he is suggesting that if they did, the IETF Trust would need to be subject to “accountability and oversight” from the names and numbers communities.

The case against ICANN or PTI holding the trademarks

The fundamental flaw in Shatan’s argument is that he is confusing the entity that is contracted to maintain the IANA registries with the “source and origin” of the IANA function. This is an easy mistake for a trademark lawyer not familiar with the internet standards environment to make, but it is still a mistake. The debate over the IANA trademarks must be grounded in an understanding of what the IANA functions are and where they come from. The acronym IANA has been referenced in IETF standards documents thousands of times, including this 1994 RFC describing the IANA. The references begin many years before ICANN existed. The best formal definition of the IANA functions comes from a 1998 RFC (2434):

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned … To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).[1]

In other words, the role of the IANA is to coordinate assignments within names spaces defined by the IETF standards.[2] Thus the ‘source and origin’ of the IANA functions is the IETF standards.

As noted above, to the numbers and protocols communities, the IANA Functions operator (IFO) is merely a contractor, someone to do the clerical and administrative work of coordinating registry values based on the decisions made by independent policy making bodies (the IETF, ICANN, and the five RIRs). The contractor should not be the owner of the mark, because the contractor is not the real source or origin of IANA functions. It is the agent, not the principal. Put differently, ICANN is not “the IANA,” it just happens to be the IANA functions provider for all three communities at the moment.

Tying the trademark to one IANA functions operator – and one that is located in only one of the three operational communities – would create all kinds of coordination problems. Consider the scenario in which one of the three operational communities (let’s say, the IETF) decides to stop using ICANN or PTI for the IANA functions and chooses some other provider. Under Shatan’s scenario, the IETF would have to find another domain for its protocol registries (which could have bad operational consequences) and would also have to stop calling its new provider “the IANA” or even an “IANA functions provider” unless it got permission to use the term and domain from ICANN. But it would seem odd to need the permission of a service provider one just abandoned for bad performance or some other reason. Suppose two of the three operational communities abandon ICANN’s PTI. Then two of the three communities would not be able to use the IANA domain and trademark. This could threaten the coordination of the central registries that keep the Internet globally compatible.

Clearly, this scenario makes no sense. Any new IANA functions operator selected by the names, numbers or protocols communities are still providing IANA functions; the source and origin of the registries has not changed; the source or origin of the policy decisions about what values go into the registry has not changed. The affected community should not have to rebrand its entire system and move it to a new domain simply because they switched IFOs. The simple fact is that all three operational communities have built into their proposals the principle of separability. If we want the IANA functions provider to be subject to the discipline of potential competition – which is the most effective form of accountability – we cannot give a single IFO control of the IANA trademarks.

Where to go now

Clearly, we need to find a “home” for the IANA trademarks and domains that allows the term to continue to be used by the IETF itself (which invented the term and has it deeply embedded in its standards documents and processes), and by any or all IANA functions operator(s) that have been legitimately designated by the relevant operational communities.

Is the IETF Trust the right home? It is certainly a more appropriate one than ICANN. The IETF, not the names-centric ICANN, is the true source and origin of all IANA functions, and it would be truly odd for the IETF to have to obtain permission from anyone else to use the mark or the domain. If people are really concerned that the IETF Trust could arbitrarily terminate licenses to use the trademark or domain, it doesn’t seem that difficult to write into the terms and conditions governing the transfer of the trademark some commitments that the IETF Trust will license the mark to whoever a community deems to be their preferred IFO.

[1] RFC 2434 has been superseded by RFC 5226, but the definition remains the same.

[2] RFC 5226 uses the following definitions: “In this document, we call the set of possible values for such a field a “namespace”; its actual value may be a text string, a number, or another kind of value. The binding or association of a specific value with a particular purpose within a namespace is called an assigned number (or assigned value, or sometimes a “code point”, “protocol constant”, or “protocol parameter”). Each assignment of a value in a namespace is called a registration.”

The plans and proposals are now specific enough for us to get a glimpse of the future in store for us. We can see the light at the end of the tunnel. People are getting excited.

This was the environment when Assistant Secretary of Commerce Lawrence Strickling took to the stage in a packed room on Sunday evening (June 21). Strickling was the opening speaker on a panel discussion of “IANA Stewardship Transition & Evolution of ICANN Accountability” put together by ICANN’s staff.

And in so many ways, this panel was a complete downer. Despite repeated protestations from both the U.S. Commerce Department and ICANN’s staff that the whole thing is in the hands of “the community,” both the Commerce Department and ICANN are still trying to subtly steer the enhanced accountability process –  in the wrong direction.

Let’s start with Strickling’s speech. Coming on the heels of a widely read blog post posing some pointed “questions” (actually, indirect advice), Strickling seemed to be intent on undermining key reforms proposed by the accountability process. The most shocking of these comments concerned the Independent Review Process (IRP). Nearly everyone involved in ICANN recognizes that ICANN needs an “independent judiciary” – a neutral and binding dispute resolution process that can tell ICANN that it has broken its own rules or strayed too far from its narrow mission. Yet here was the U.S. Asst Secretary of Commerce warning us about the alleged dangers of independent review; how can we allow a panel of 5 judges to overturn a “multistakeholder consensus,” he asked? Strickling also repeatedly referred to ICANN’s “elected” board and asked why the community did not trust them once they got on the board. Strickling did not seem to realize that most of the board is not elected but selected by a small multistakeholder Committee which operates in secret. Strickling seemed to be implying that the community does not need to be empowered to impose any binding limts on the board through membership or other means.

Whether intended or not, the underlying message seemed to be “don’t rock the boat,” and “trust ICANN.” It’s almost as if Strickling was turning the clock back to 2009 or thereabouts, as if the revolution in accountability expectations that has gained momentum since then had never taken place.

That was bad enough. But the rest of the panel was worse, worse in a most peculiar way. Instead of allowing the people in the community who are working on the reforms to engage with Strickling on the questions he was asking, the panel contained the three co-chairs of the 2002 “Committee on Evolution and Reform” (CER). A more disturbing historical reference could not have been made.

The CER “reform” process, initiated in November 2001 at the nadir of ICANN’s existence, was an accountability disaster. Many of the accountability and structural problems we have today are a direct consequence of its work. It was the CER which led to the adoption of new bylaws that allowed the Board to ignore the consensus of its supporting organizations and make domain name policies by a vote of the Board. The new bylaws, three academic critics wrote, “represent an intentional departure from the consensus decision-making model, and a move towards centralized, top-down policy-making.” The CER “reform” process also abolished democratic elections of board members and put in its place the absurdly expensive, entirely ICANN-controlled At Large Advisory Committee. ALAC was supposed to provide a vehicle for representing all the world’s individual Internet users yet has never managed to grow beyond the size of a single stakeholder group in the GNSO. It was the CER that replaced board elections with board selections by a Nomcom. It was the CER which created the bylaw change that endowed GAC advice with the magical power to override the GNSO policy development process, inadvertently creating a parallel, competing policy development process. Finally, the CER was initiated and run by ICANN itself, not in a bottom up fashion by the community. Another academic wrote that “ICANN 2.0 looks like a deal between (some) industries and (some) governments which sidelines the global Internet users.”

At the same time as official ICANN declares the process as “on the verge of accomplishing something truly remarkable”  its clear that the accountability reforms are beginning to make the ICANN staff/board uncomfortable. Unlike the 2002 CER, they are not in control of the process. More puzzling, however, is the obvious tendency of the NTIA to side with ICANN in its attempt to short-circuit reforms to avoid real accountability. The tendency of regulators to identify with and become solicitous of the industy they regulate is well known. We greatly appreciate Assistant Secretary Strickling’s leadership in promoting multi-stakeholder governance, but we think that after more than fifteen years of routinely interacting with each other, ICANN and NTIA may have become a little too close. It’s time for Strickling to stop kibitzing and start acting like the neutral arbiter the U.S. government claims to be.

Those of you who thought that “membership” meant that ordinary people, individuals, would be empowered by this process, think again. The idea of individual membership, Internet democracy, is so…..fifteen years ago.

No, the CCWG membership proposal makes ICANN’s own bylaw-created supporting organizations and advisory committees its members. And it contains a potentially radical rebalancing of voting power within ICANN. It assigns an equal number of votes (5) to GNSO (the domain name policy making organ), ccNSO (the country code registry supporting organization), ASO (the numbers or IP address supporting organization), ALAC (the 15-person Advisory Committee for the “at large”) and the Governmental Advisory Committee (GAC). It also gives 2 votes to two other Advisory Committees, the Security and Stability Advisory Committee (SSAC) and the Root Server System Advisory Committee (RSSAC).

This proposed allocation of voting power is unfair and in some ways actually works against aligning accountability with the stakeholders. The proposed allocation of voting power does not seem to have been designed to optimize or maximize accountability of ICANN to Internet users and suppliers. It was designed to share control among the specialized little groups who make up the CCWG. Like the winners of World War 1 carving up the remains of various empires, the CCWG seems to be carving up control of ICANN among its chartering organizations.

When it comes to membership, it seems incongruous to this veteran of ICANN’s policy making process to consider Advisory Committees members of the same status as Supporting Organizations. With the separation of IANA and ICANN proposed by the CWG-Stewardship, ICANN is now more focused, as it should be, on policy development for domain names. This means that the two names-oriented Supporting Organizations, the ccNSO and the GNSO, are the key arenas for policy development in the new ICANN environment. Thus, they are the stakeholders with the greatest interest in ensuring that the ICANN board is held accountable for the policies it passes and implements.

ICANN’s role as the ratifier of global policies for numbers also justifies a membership status for the ASO, as the ASO represents an extensive global community for policy development organized around Regional Internet Registries. A membership proposal that assigns an equal number of votes to ccNSO, GNSO and ASO makes sense.

It is the ACs that don’t really make sense in this scheme. Providing two votes to a highly technical advisory committee (SSAC), which does not make policy and whose members are already well-represented in GNSO and ccNSO, is bad enough. But the more serious problem is that SSAC membership is appointed by the ICANN board! Does it make sense to expect a board-appointed committee to keep the board accountable? This seems obviously wrong.The same, it seems, is true of the RSSAC. Let’s get back to the original idea behind SSAC and RSSAC: they are sources of expert advice for the board and the policy development entities. They are not policy development entities that compete with the GNSO. It makes no sense to treat them as “members” to whom the board is accountable.

GAC and ALAC are also outliers in this proposal, though for different reasons. One could make some case for considering ALAC a member, because it does select board members under the current regime. But to weight ALAC the same as the entire GNSO or ccNSO seems ridiculous. The ALAC consists of 15 people. Although they are elected by somewhat larger regional organizations, in terms of membership and participation the entire At Large is about the size of a single Stakeholder Group in the GNSO. For example, both the Noncommercial Stakeholders Group and the Commercial Stakeholders Group have more, or, to be charitable, comparable number of members to all the Regional At Large organizations combined. In fact, there is significant overlap in membership between ALAC’s At Large Structures, their individual members, and NCSG and CSG. Giving it the same weight as the GNSO, which consists of 4 distinct stakeholder groupings and 7 constituencies, or ccNSO, which represents over 100 national and territorial registries, seems woefully unbalanced. If it is to be considered a member at all it should be only two votes as proposed for the RSSAC.

It seems especially incongruous to have the Governmental Advisory Committee become a member entity equivalent to a Supporting Organization. The GAC does not select board members and is barred from doing so by the current bylaws. The GAC is not supposed to be a policy development entity, but a provider of advice to the board on the policies developed by the bottom up process. The legal status of a collection of national governments and intergovernmental organizations forming an unincorporated association under the umbrella of ICANN seems extremely odd, and will probably prove to be unacceptable to the GAC itself.

In short, the proposed membership allocation does not make sense and needs to be rethought.

To casual observers this may all seem like inside baseball. And in fact, that is exactly what it is. This is how insiders take control, by doing obscure work in an obscure corner, silently taking care of their own.  The general public needs to re-examine the work of the CCWG on membership with this question in mind: does this proposal make ICANN more accountable to the broad community that ICANN  is supposed to serve, or does it make it more controlled by the small group of people who are drafting the proposal?