Private Ownership of gTLDs and Enforcement of gTLD Policies Kent Crispin, Songbird July 22, 1998 updated Jan 10, 2001 [0] This short document explores private ownership of TLDs and its impact on the regulation of TLDs. I use the word "regulation" in a very generic sense: "regulation" is "enforcing policy". I also deliberately use the more general phrase "regulation of TLDs" instead of the phrase "regulation of TLD registries", because registries are not the only point at which regulation may be applied. In addition, the focus of the paper is on gTLD policy enforcement, and not the general case which might include ccTLDs, or chartered TLDs. Examples of policies to be enforced are "gTLD registries will allow equal access to all qualified registrars"; "gTLDs must allow registrations from all comers on a non-discriminatory, fair basis"; "TLD registries will pay $1.00/year/domain to ICANN to support the root nameservers". If or when "chartered" TLDs are developed, some of the policies in a TLD charter would be regulations. There is wide agreement that ICANN must establish policies that regulate TLDs in at least some ways, though there is wide disagreement about what those policies should be, or how extensive they should be. This paper makes no presumption about the content of those policies, how broad they are, the structure of ICANN, how stakeholders are represented, what makes ICANN "legitimate", or how power is given to ICANN. The paper only addresses the issue of *how* policies can be enforced, not how policies are developed, or what they are. The usual context for considering enforcement of regulations is through government. Governments have infrastructure, money, a monopoly on force, and police powers with which to enforce regulations. ICANN has none of these things. However, for a regulation to have any meaning there must be some policing mechanism -- unenforced policies don't really count. Every substantive policy, therefore, imposes an enforcement cost. I. The need for regulation A basic tenant of this paper is that at least some regulation is needed. An extreme libertarian view is that there is no need for any regulation whatsoever -- that market forces are completely sufficient. However, from a practical standpoint, the White Paper calls for fair access by registrars, and this clearly requires some regulatory function. Moreover, as the examples above indicate, there are other areas where some kind of enforceable policies must be established. Further, there are ongoing concerns about the monopoly power of registries that must be considered, and there needs to be at least a regulatory framework in place to deal with such abuses, should they occur. Another important reason for the need of regulation is the infrastructural nature of the Internet. Government, educational institutions, medical institutions, utilities -- all these are using the Internet more and more every day. The Internet is like the phone service, only potentially even more pervasive. If the Internet is to fulfill its full potential as a fundamental part of the infrastructure of civilization, it must be accountable to society at large. Such infrastructural regulation usually comes through government. Indeed, the ultimate source of regulatory authority always comes from Governments, and their monopoly on force. One approach to TLD regulation, therefore, is to make it a DIRECT Government function, either by centralizing all TLD operations in a single country, or by establishing an international treaty that defines the regulatory framework. ICANN, however, is a private corporation, and uses the power of government INDIRECTLY, through its enforcement of contracts and property rights. II. Regulation in the DNS "State of Nature" [2] The hierarchical structure of DNS, by itself, provides a very simple model for policy control relationships between domains. DNS Servers run on real computer systems, systems that are owned and controlled by particular parties. This model is seductively simple, so much so that many people seem to think that it is all there is to it: Control over a domain means control over the contents of that domains "zone file". That is, the immediate subdomains of a domain exist at the whim of whoever controls that zone file, because subdomains can be added or deleted from the zone file at any time. So, of course, if you control a zone file, you can sell or rent entries in your zone file, and you are free to set contractual relationships with the individuals to whom you sell or rent these entries. These contractual relationships can contain whatever policies that you wish to apply to subdomains of your zone file. In turn, however, if your domain is a subdomain of some higher level domain, your domain name exists in that higher-level zone file at the whim of the owner of that zone. In addition, that owner gets to set policies that *you* must follow. Those policies can contain a requirement that you apply them recursively for all your subdomains. All other things being equal, of course, a recursive policy imposes higher enforcement costs -- frequently much higher enforcement cost. [This additional enforcement cost is a strong natural limitation on the effectiveness of recursive policies.] A highest level zone is called a "root zone", and, in the "State of Nature" model, the owner of a root zone has total freedom to set any policies whatsoever on its subdomains, charge any prices it likes, require any business model it likes -- anything allowed within the bounds of contract law. The simple model of control inherent in DNS grants full power to the owner of the root zone. However, Of course, there is nothing to prevent multiple root zones[3], and, while it would be a pointless philosophical exercise, a case could probably be made that multiple root zones are the "natural" consequence of a system based only on the "State of Nature" model. This follows from the fact that while the owner of a zone is free to eliminate entries in their own zone, they are also free to seek arrangements with other root zones. At the "state of nature" level, enforcement of policies is through the threat of removal of a domain from a zone. However, contracts ("registration agreements") may be involved that define the terms and conditions of membership in a zone, and they can have any conceivable clause that 1) the two parties are willing to agree to, and 2) that fit into the general legal constraints on contracts. However, at the base the question at issue is presence or non presence in a zone file, and therefore these contracts always have as an ultimate sanction removal from the zone. Registration agreements, one might say, modulate the "State of Nature" model, rather than entirely replacing it. Of course, registration agreements draw a legal system into the process, and therefore the notion of jurisdiction. I have fancifully called this the "State of Nature" theory. Its fundamental control mechanism is the ability to add or delete subdomains. In the real world all sorts of other considerations enter in, especial at high levels, but this fundamental control mechanism remains of great importance, and it is one of the fundamental conceptual building blocks of DNS management. Note again that, by itself, it has no jurisdictional limits, though the entanglement in a legal system implied by the use of "registration agreements" will inevitably involve the notion of jurisdiction. III. The Global Root Zone The goal of The Global Root zone (capital R) is a single unified name space for the Internet. To be more explicit, the goal is to be sure that every IP address reachable through the Internet backbone can also be uniquely named. By extension, one of the primary goals of the ICANN exercise is to provide a (capital "R") Root zone. This is an asymptotic goal, at best, and it is not a part of the "State of Nature" model. DNS is a general mechanism, and nowhere is it written in stone that a single connected name space must exist. As noted, the nature of DNS is such that an organization that wishes to set up a competing root zone can do so. Moreover, "little r" local roots, with no pretensions of universality, are commonplace. On the other hand, the existence of a Global Root zone is of fundamental importance. Much of the economic power in the Internet is a function of convenient universal connectivity, and a universal name space is a necessary component of that convenience. The "single unified name space" goal has certain implications for the Root zone. It must be extremely reliable; it must be "trustworthy"; it must abide by widely accepted operational practices; and it must be cost-effective. Any Root zone that substantially fails to meet these goals will be changed, or will be replaced. Thinking this far leads one to a particularly simple-minded theory of Root Zone management: The Root is a zone like any other zone -- the TLD "owners" rent or otherwise acquire an entry in the Root zone, and manage their own zone files autocratically, modulated only by recursive policies established by the Root. These recursive policies, and any other policies, are enforced through Root level "registration agreements" -- contracts between the Root zone operator (ICANN, or an appropriate surrogate) and the owners of the TLD zones. Alternatively, they are managed through the simple threat of removal from the Root. This is a "State of Nature" model for the Root Zone. [4] IV. The Root Zone Social Contract I have characterized the above model as "simple-minded". While many are seduced by the simplicity of the State of Nature model, it is in fact completely inadequate to describe the nature of the Global Root Zone. The Global Root Zone has, in practice, many more unique characteristics than just sitting at the top of the tree. For example: 1) It has a historical fiduciary character. 2) Stability must emanate from the Root. Clearly, if the Root is unstable, then no subdomain can be stable, and thus the requirements for stability are much greater on the Root Zone than on other zones. It must be noted again that this requirement of stability is not a surface requirement, although the rush to commercialize the Internet tends to mask its depth. As time goes on the Internet will be an indispensable part of the infrastructure of the civilized world, and many completely automated functions will operate through it. Now, thousands of hospitals losing access to remote medical knowledge because the ".org" registry didn't meet certain policy constraints would not be a socially acceptable result. Fifteen years in the failure of a national power grid could come from such an event. 3) The Root zone contains the top of the special .arpa zone, and thus is entwined in the technical functioning of lower level protocols in the Internet. 4) Currently the majority of the domains in the Root zone have political significance (the ccTLDs). 5) In addition to the public service role alluded to in bullet 2, above, the Root zone also provides essential service to government and international organizations. 6) IANA has essentially no discretionary authority to remove any of the current TLDs. The ccTLDs are controlled by ISO and political concerns; .com, .org, and .net cannot be removed for practical reasons; .gov and .mil cannot be removed for political reasons; .edu can't be removed for historical reasons; .int can't be removed for political reasons; and the .arpa domain cannot be removed for practical and technical reasons. These characteristics and more create an expectation concerning the nature of the root zone, an expectation I will call the "Root Zone Covenant". [5] It is an implied social contract with all the users of the Internet: The Root Zone Covenant A Root zone operator that takes its task seriously, and likewise wishes to be taken seriously, must assume a responsibility to those end users, even though the end users have no direct contact with the Root zone operator. More succinctly, the Root Zone Operator cannot disenfranchise end-users of the DNS: the Root Zone Operator will not willfully cause users to lose connectivity to the global name space. For our purposes the most profound implication of the Root Zone Covenant is that the Root Zone cannot use the threat of removal of a TLD from the Root Zone as a means of enforcing policy. [6] Besides this argument from social contract, there are other arguments that TLDs cannot be unilaterally removed by ICANN: 1) the practical legal argument -- if ICANN removed .com (for example) from the root it is clear that it would be opening itself to a lush garden of potential legal actions. This would be true for smaller zones, as well -- the legal basis is the same, though the war chest might not be as big. 2) the White Paper Priority argument -- the number one priority of the White Paper is stability. Removing zones as a means of policy enforcement is not conducive to stability; and 3) the alternate root argument -- if ICANN removes the .com zone, NSI could simply start its own root zone and advertise it. This would not be conducive to stability, either. V. Inadequacy of the "State of Nature" Model In the "State of Nature" model, TLDs are, by definition, the only domains over which the Root zone has direct policy control. [7] However, the fundamental "State of Nature" enforcement mechanism (deletion from the zone) is unavailable to ICANN, because of the Root Zone Covenant. The only remaining means of control available in the State of Nature model are "registration agreement" contracts. Compared to the State of Nature model, however, these contracts are missing an important enforcement tool, the threat of removal from the zone. These contracts would need to be drawn in a particular legal jurisdiction. For example, ICANN might require that all TLD "owners" must sign a contract, under US law, with ICANN. This would effectively place all TLD policy under US jurisdiction. Many people would be offended by such a development, and, in fact, it would present a giant political problem. Besides this political problem, regulating TLD registries through such contractual means suffers from another, far more serious problem: it is ineffective. This can be illustrated through an example: Imagine a gTLD ".tld", "owned" by a company in, let's say, Japan. The owner of .tld signs a hypothetical US "Root zone registration agreement", which includes the usual "equal access" clause for registrars. [8] The owner of .tld, let's further imagine, manages to get a trademark for ".tld". Things go on for a couple of years, the .tld registry does a good business, and makes a fair amount of money. Now, suppose the owner decides that it doesn't want to honor the equal access clause. That is, after a couple years operation it decides that it wishes to be its own registrar, and to deny access to other registrars. What does ICANN do? If the company is intransigent a lawsuit is the only option -- a painful, expensive, slow option, but the only one available to ICANN, under the circumstances. Assume that ICANN wins. The company ignores the judgement, and continues registering names. What does ICANN do next? The company has the contact database with the billing information -- ICANN doesn't. The company owns intellectual property rights in the ".tld" name -- ICANN doesn't. The company is located in a jurisdiction foreign to the contract jurisdiction, and is very difficult to pursue legally. By the Root Zone Covenant, ICANN cannot remove the name "tld" from the Root -- to do so might actually open ICANN up to a lawsuit from SLD holders in the .tld domain... I have cast this example as a case concerning registrar-registry policies. But ICANN has little real leverage for *any* kind of enforcement through contracts. For example, a registry could refuse to pay fees to ICANN, or a registry could charge higher prices for "special" names, or it could collude with Domain Name pirates. In all these cases, the only sanction ultimately available to ICANN would be to go to court. International lawsuits are an extremely inefficient and expensive way to enforce policies. [9] We needn't look far to find a real life example of how the problem of unclear title to the TLDs and the associated database can be exploited to considerable advantage: In theory, NSI is simply a contractor, and the upcoming termination of the contract with NSF should be no big deal. In practice, however, it enjoys luxurious negotiating room. Part of that luxury stems from the fact it has physical possession of a live billing database that must continue to operate. All open questions concerning legal ownership of that database add greatly to NSI's negotiating position. [10] Additionally, NSI has made some light-hearted efforts to "brand" .com: e.g. "Network Solutions: the people who brought you .com". Imagine how much stronger NSI's position would be if it had clear intellectual property title to ".com". Then further imagine that NSI was headquartered in Japan; DOC/DOJ would be negotiating with a Japanese company. Then, finally, imagine that, instead of DOC/DOJ, the regulatory authority doing the negotiation was a small non-profit corporation. VI. ICANN Ownership of gTLD names and Databases It should be clear from the above discussion that the key to the problem is private possession of the gTLD name and database. There is an old saying that "possession is nine tenths of the law"; when the law is fragmented and complex, as the case in the international arena, possession is even more important. We need an alternate model of regulation, one that does not involve private possession of these things. In this alternate model, ICANN must have unencumbered control over the gTLD name and database, in permanent trust for DNS stakeholders [11]. That is, instead of "selling" or "renting" space in the Root zone, all the entries in the Root zone BELONG TO THE PUBLIC, through ICANN. ICANN may enter contracts with registry operator companies to run registries for TLDs on ICANN's behalf, but in those contracts ICANN retains control or ownership, as a trustee for the public. Note that the above paragraph speaks only of gTLDs. Essentially all the current TLDs are already under some form of public control: Though hotly contested by some ccTLD registry operators, the ISO3166 TLDs explicitly belong to sovereign entities; .gov, .mil, .edu, .int, and .arpa all belong to the public infrastructure. Most people, I believe, would argue that .com, .net, and .org also belong to the public. Thus, the question of private ownership only comes up with new gTLDs. [12] There are various means by which private ownership of TLD names may be avoided. For example, ownership may be vested in a recognized public body, like a government, or a standards body. (In fact, one of the models for ICANN is as a public standards body). Another mechanism might be for by ICANN to assert ownership of the name, and granting public use in a manner similar to the Gnu Public License. Or rights to a privately owned name might be given to ICANN (though such a gift would have to be examined very carefully for attached strings). It is not necessary that there be a single mechanism: the basic requirement is that ICANN has control over the use of the name as a TLD. There are also various means by which ICANN can maintain possession of the TLD database -- the most obvious being that registry operators would be required by contract to escrow the data in a place where ICANN can always get it. [13] To make this work most efficiently ICANN should have contracts (directly or indirectly) with several registry operators, presumably located around the globe. In the best case each operator should run a registry for several TLDs, registry operations should be standardized, and the various registries should act as backups for each other. It would be straightforward to move a TLD from one registry operator to another -- the transfer of the registry data and the TLD zone file could be done with no interruption in service. Note that such an arrangement gives ICANN a very flexible and well modulated management regime. gTLDs can be moved for load balancing; they can be moved as proactive policy enforcement. International contracts will still be involved. But they are straightforward work-for-hire contracts that are well understood and common in an international context. They are not contracts that try to implement a regulatory role. This is a stark contrast to the "state of nature" example described above. ICANN owns the TLD name, has a current copy of the billing database available [14], and has a set of other contractors already managing TLDs, perhaps with the data in question already on site. If there is a problem with a contractor ICANN simply hands the data to one of the other contractors (the contracts would already be written to cover such cases), does a zone transfer, and changes the pointers in the root zone. Later, if capacity demands warrant it, ICANN will put out a bid for a new registry development contract. [13] These actions are enabled by the establishment of clear title to the TLD name and to the database, before a contractor is ever hired. Without that clear title, ICANN's ability to regulate the TLD space is hamstrung. VII. Conclusion The problem of policy enforcement is real, and it is an extremely important problem for ICANN to solve. For several reasons, regulatory contracts between a TLD-owner and ICANN are not a good way to solve it. Instead, ICANN must assert and maintain public ownership of all TLDs in the Root zone, from the beginning. This ownership would involve a trust relationship with DNS stakeholders. ICANN must never delegate ownership of TLDs; it only delegates operation of registries. Likewise, ICANN must also assert original ownership of the customer databases for the TLDs. ================================================================ Notes: [0] A lot has happened since the first version of this paper, so a revision was necessary. In the first version I used the term "nIANA" where I now use "ICANN", but there have been many substantive changes as well. [1] I am no longer so optimistice about this. I now believe there is a fair probability that the "ICANN experiment" will fail, and that management of the TLD space will become a function of an international treaty organization. Karl Auerbach has made a case that special laws will be necessary for the initial transfer of the database from NSI to ICANN -- the transfer of title to the .com/.org/.net registry database. I don't agree that special legislation would be needed, but such one-time special purpose legislation would not impact the ongoing regulatory model in any case. On the other hand, laws that granted special anti-trust exemptions to ICANN *would* impact the regulatory model, and would have the effect of binding ICANN to the US. [2] "State of Nature" arguments are an old philosophical standard, revived in my memory by Robert Nozick's book "Anarchy, State, and Utopia"... [3] There are, however, technical issues concerning overlapping root zones. [4] I believe that the philosophical background to the "Root Server Confederation" groups is essentially that of "State of Nature TLD Management". [5] I called this the "Root Zone Condition" in a previous version. [6] Jay Fenello has argued that a TLD can be removed from the root zone in exactly the same way that "hotmail.com" could be removed from the .com registry. That is, if NSI didn't pay their dues to ICANN, ICANN would simply remove .com from the root. I contend that this is, to put it mildly, unrealistic. Removal of a large TLD from the root would also risk a "fracture" of the root -- as an obvious case, removal of .com from the Root zone would simply result in another Root that included .com as the new Root -- the customer base of the current .com zone would demand it. A "center of gravity" analogy seems useful -- TLDs have "mass" measured in the number of registrations; the Global Root must be the "gravitational center of mass" of the name space. Kicking out .com would kick out most of the mass; and a new root would accrete around .com. Paul Svenson has also argued that the Root zone is only different in the number of subdomains that it holds. I argue that the Root Zone special in quite a few ways, as indicated in the examples in the main text. Many more examples could be added. [7] It can, of course, impose recursive policies on TLDs. But even non-recursive policies will greatly affect the character of the entire DNS structure under the Root zone. [8] The "equal access clause" refers to a requirement that registries grant fair access to all registrars. [9] Some may argue that international contracts are not so bad as a regulatory mechanism, because businesses do business across international boundaries on a daily basis. But the relationship between ICANN and registries or TLD owners is not a just a business relationship -- one of ICANN's fundamental roles is to be a way for stakeholders to influence TLD policy through non-economic means, and some of that policy may not be in the best business interest of either party. [10] This may sound like I am engaging in "NSI bashing". That is not the case. NSI, as a for-profit company, now public, has an affirmative duty to pursue these negotiations as aggressively as it can, as would any company. [11] While I don't really discuss ICANN's structure here, the phrase "in trust for DNS stakeholders" is a necessary component. Private ownership of the TLDs by ICANN is of course not intended. [12] A further advantage: by eliminating private ownership of TLDs, the Root Zone retains a management mode it has had from the beginning. Given the emphasis on stability in the White Paper and elsewhere, this continuity is highly desirable. [13] Another example: a contractual requirement that updates to the contact data be transmitted to ICANN on a daily basis. Failure to transmit the data would be grounds to give the TLD to another registry. But data escrow should be a requirement for data safety, in any case. As mentioned, an attractive alternative would be that the data be backed up to another registry operator on a daily basis. This would serve two purposes -- redundancy in case of any failure, and as a policy enforcement lever. [14] I note that my position on multiple registry operators is not exactly the PAB/POC/CORE position. Designing an international distributed TLD registry (which is what we are actually discussing) is a non-trivial task, though the CORE work covers most of the bases, complete development of a multiple registry system still needs some work.