One of the biggest controversies surrounding the IANA stewardship transition revolves around the fate of the IANA trademark and domain name (IANA.ORG). Both of these assets are currently owned by ICANN. But the IANA stewardship transition has raised questions about who or what should be their proper home.
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.
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).
In other words, the role of the IANA is to coordinate assignments within names spaces defined by the IETF standards. 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.
 RFC 2434 has been superseded by RFC 5226, but the definition remains the same.
 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.”