ABSTRACT
INTRODUCTION
I. THE DOMAIN NAME SYSTEM A. Domain Names and Their Uses B. The Source and Import of Control of the Legacy Root
II. THE DNS: A CONTRACTUAL HISTORY A. Before ICANN B. Contractual Basis of ICANN's Authority (October 1998-present)
III. DOC'S RELATIONSHIP WITH ICANN IS ILLEGAL A. ICANN Is Engaged in Policymaking B. DoC's Relationship with ICANN C. APA Issues D. Constitutional Issues E. Due Process Issues F. Structural Failures/Self-Dealing
IV. REFORMING THE U.S. DNS POLICY A. The Policy Problem B. ICANN Sets a Terrible Precedent C. A Better DNS Policy is Within Our Grasp
CONCLUSION
FOOTNOTES
The Internet relies on an underlying centralized hierarchy built into the domain name system (DNS) to control the routing for the vast majority of Internet traffic. At its heart is a single data file, known as the "root." Control of the root provides singular power in cyberspace.
This Article first describes how the United States government found itself in control of the root. It then describes how, in an attempt[*pg 18] to meet concerns that the United States could so dominate an Internet chokepoint, the U.S. Department of Commerce (DoC) summoned into being the Internet Corporation for Assigned Names and Numbers (ICANN), a formally private nonprofit California corporation. DoC then signed contracts with ICANN in order to clothe it with most of the U.S. government's power over the DNS, and convinced other parties to recognize ICANN's authority. ICANN then took regulatory actions that the U.S. Department of Commerce was unable or unwilling to make itself, including the imposition on all registrants of Internet addresses of an idiosyncratic set of arbitration rules and procedures that benefit third-party trademark holders.
Professor Froomkin then argues that the use of ICANN to regulate in the stead of an executive agency violates fundamental values and policies designed to ensure democratic control over the use of government power, and sets a precedent that risks being expanded into other regulatory activities. He argues that DoC's use of ICANN to make rules either violates the APA's requirement for notice and comment in rulemaking and judicial review, or it violates the Constitution's nondelegation doctrine. Professor Froomkin reviews possible alternatives to ICANN, and ultimately proposes a decentralized structure in which the namespace of the DNS is spread out over a transnational group of "policy partners" with DoC.
[*pg 20]
The availability of judicial review is the necessary condition, psychologically if not logically, of a system of administrative power which purports to be legitimate, or legally valid.
LOUIS L. JAFFE{1}
Despite being famously decentralized and un-hierarchical,{3} the Internet relies on an underlying centralized hierarchy built into the domain name system (DNS). Domain names (such as "www.law.miami.edu") are the unique identifiers that people depend on to route e-mail, find web pages, and connect to other Internet resources.{4} The need to enforce uniqueness, that is, to prevent two people from attempting to use the exact same domain name, creates a need for some sort of body to monitor or allocate naming. However, [*pg 21] control over the DNS confers substantial power over the Internet. Whoever controls the DNS decides what new families of "top-level" domain names can exist (e.g., new suffixes like .xxx or .union) and how names and essential routing numbers will be assigned to websites and other Internet resources.{5} The power to create is also the power to destroy, and the power to destroy carries in its train the power to attach conditions to the use of a domain name.{6} Currently, this power is used to require domain name registrants to publish their addresses and telephone numbers on a worldwide readable list and to agree that any trademark holder in the world aggrieved by their registration can demand arbitration regarding ownership of the name under an eccentric set of rules and standards. In theory, the power conferred by control of the DNS could be used to enforce many kinds of regulation of the Internet; it could, for example, be used to impose content controls on the World Wide Web (WWW), although there are no signs that anyone intends this at present.
Without meaning to at first, the United States government found itself controlling this unique Internet chokepoint.{7} When the Internet was small, the DNS was run by a combination of volunteers, the Na- [*pg 22] tional Science Foundation (NSF), and U.S. government civilian and military contractors and grant recipients.{8} As the paymaster for these contractors, the U.S. government became the de facto ruler of the DNS, although it barely exercised -- and for a long time may not in any real sense have been aware of -- its power. The Internet's exponential growth placed strains on the somewhat ad hoc system for managing the DNS, and what had been primarily technical issues became political, legal, and economic problems that attracted high-level official attention.{9} In particular, as attractive domain names in .com began to become scarce,{10} disputes over attractive names became increasingly common,{11} and pressure mounted for the creation of new "top-level" domain suffixes such as .shop or .web. Although technically trivial to implement,{12} the proposals ran into intense counter- [*pg 23] pressure from intellectual property rights holders who already faced mounting problems with cybersquatters -- speculators who registered domain names corresponding to trademarks and held them for profit.{13} Meanwhile, foreign governments, notably the European Union, began to express understandable concern about the United States' control of a critical element of a global communication and commercial resource on which they foresaw their economies and societies becoming ever-more dependent.{14}
[*pg 24]
As the DNS issue, and especially the relationship between domain names and trademarks, grew in importance, the conflicting pressures on the federal government for action grew as well. In June 1998, DoC and an interagency task force headed by Presidential Senior Adviser Ira Magaziner responded with the Statement of Policy on the Privatization of Internet Domain Name System, known as the DNS White Paper.{15} Abandoning earlier hopes of issuing a substantive rule, which requires statutory authorization and is subject to judicial review, the policy statement instead set out goals that the administration thought could be achieved without rulemaking. Embracing the rhetoric of privatization, the DNS White Paper called for the creation of a private nonprofit corporation to take over the DNS and institute various reforms.{16} Shortly thereafter, an international group incorporated ICANN as a private nonprofit California corporation, and, after some negotiation, DoC lent ICANN much of its authority over management of the DNS.
In its first two years of life, ICANN has made a number of decisions with potentially long-term effects. Of necessity, much of ICANN's energy has been devoted to the process of setting up its own, somewhat ornate, internal structures{17} and procedures. The formal structures in place at this writing give overwhelming weight to corporate voices, tempered only by the power of the board to reject their suggestions. The board remains composed of the nine original unelected directors, supplemented by nine selected by so-called constituency groups, who in turn are selected by ICANN. Internet users and individual domain name registrants remain unrepresented at the board level, although ICANN is in the process of organizing a limited representation for the public.{18}
Almost as soon as it was in place, the ICANN board undertook major decisions, beginning with the agenda set out in the White Paper. ICANN pushed Network Solutions, Inc. (NSI), the monopoly registry and dominant registrar, to allow more competition among [*pg 25] registrars.{19} ICANN also instituted mandatory arbitration of trademark claims. ICANN's "Uniform Dispute Resolution Policy" (UDRP) requires every registrant in ..com, .org, or .net to agree to arbitration before ICANN-selected arbitration providers if any trademark owners anywhere in the world feel aggrieved by their registration of a term similar to that trademark.{20}
As a result of this policy, registrants are now subject to an idiosyncratic set of arbitration rules and procedures that benefit third-party trademark holders at the expense of registrants and do not necessarily conform to U.S. trademark law.{21} ICANN also chose to keep in place and step up enforcement of some policies that it inherited, notably NSI's anti-privacy rule requiring that every registrant of a domain name agree to have his name, address, e-mail, and telephone number placed in a database readable by any Internet user in the world.{22}
Since ostensibly handing the policy baton to ICANN, DoC has treated these key decisions regarding the DNS as if they were either matters of policy outside the rulemaking strictures of the Administrative Procedure Act, as if they were matters of contract, or as if ICANN were an arms-length private body exercising autonomous choices that could take effect spontaneously, without DoC's participation or responsibility.{23} DoC has, thus, made, or acquiesced in ICANN's making, some of the most important decisions relating to the near-term future of the Internet via research contracts rather than agency adjudication or rulemaking, thus evading notice, comment, due process, and judicial review. Government outsourcing and privatization often is premised on the theory that private enterprise can [*pg 26] provide some goods and services more efficiently than the public sector.{24} DoC's reliance on ICANN is different from the classic model of privatization, because rather than privatizing a revenue-generating function, the government is "privatizing" a policy-generating function. Furthermore, the "privatization" is subject to sufficient strings to make ICANN's actions fairly chargeable to the government. Although the ICANN-DoC contracts speak of cooperation and research, some of the most significant outputs from ICANN are government regulation in all but name. It is time to call them what they are.
However one chooses to characterize the U.S. government's interest in the root file or the DNS as a whole, there is little debate that (1) DoC derives at least part of whatever authority it has from its ability to instruct a U.S. government contractor, NSI, regarding the content of the root file,{25} and (2) whatever authority ICANN holds at present emanates from, and remains subject to, DoC's ultimate authority.{26} The U.S. government's continuing control of the DNS has legal consequences that have not been well understood by participants in what have come to be called the "DNS wars,"{27} and were ignored in a recent General Accounting Office (GAO) study that examined DoC's role in ICANN's creation.{28} Chief among these legal [*pg 27] consequences is that to the extent that DoC relies on ICANN to regulate in its stead -- and this reliance appears to be quite substantial -- DoC's relationship with ICANN violates fundamental U.S. policies that are designed to ensure democratic control over the use of government power. DoC's relationship with ICANN is, therefore, illegal.
Depending on the precise nature of the DoC-ICANN relationship, not all of which is public, DoC's use of ICANN to run the DNS violates the APA and/or the U.S. Constitution. On the one hand, DoC may retain substantial control, either directly or by review, over ICANN's policy decisions. In that case, DoC's use of ICANN to make rules violates the APA. On the other hand, if DoC has ceded temporary policy control to ICANN, that violates the Constitution's nondelegation doctrine.
There is substantial evidence, discussed below, that DoC has directly instructed ICANN on policy matters. Furthermore, as ICANN is utterly dependent on DoC for ICANN's continuing authority, funding, and, indeed, its reason for being, it would be reasonable to conclude that the corporation is currently so captive that all of ICANN's decisions can fairly be charged to the government. If so, the DNS has not, in fact, been privatized at all, even temporarily. At least in cases where ICANN does what DoC tells it to do, and arguably in all cases, DoC's use of a private corporation to implement policy decisions represents an end run around the APA and the Constitution. To the extent that DoC launders its policy choices through a cat's paw, the public's right to notice and meaningful comment; to accountable decisionmaking; to due process; and to protection against arbitrary and capricious policy choices, self-dealing, or ex parte proceedings are all attenuated or eliminated; so, too, is the prospect of any meaningful judicial review. The result is precisely the type of illegitimate agency decisionmaking that modern administrative law claims to be most anxious to prevent.{29}
If, on the other hand, ICANN is making its policy decisions independently of DoC, as ICANN's partisans tend to argue, then even a partial transfer of DoC's policymaking authority over the DNS violates an even more fundamental public policy against the arbitrary [*pg 28] exercise of public power, the constitutional doctrine prohibiting the delegation of public power to private groups.{30} Most famously expounded in two pre-New Deal cases, Carter v. Carter Coal Co.{31} and A.L.A. Schechter Poultry Corp. v. United States,{32} the private nondelegation doctrine focuses on the dangers of arbitrariness, lack of due process, and self-dealing when private parties are given the use of public power without the shackles of administrative procedure.{33} The doctrine stems from a long tradition of seeking to ensure that public power is exercised in a manner that makes it both formally and, insofar as possible, actually accountable to elected officials, and through them -- we hope -- to the electorate. This concern for proper sources and exercise of public authority promotes both the rule of law and accountability.{34}
The ICANN issue is unique in a number of ways. Modern federal cases implicating the nondelegation doctrine are quite rare; the Supreme Court does not seem to have considered the issue in the context of a delegation to a private group since the New Deal, and the lower court cases are few and often very technical. In any event, nondelegation cases usually involve a contested statute.{35} The issue then is whether Congress's attempt to vest power in an agency or a private body is constitutional. In the case of ICANN, there is no statute. Congress at no time determined that the DNS should be privatized, or, indeed, legislated anything about national DNS policy. Instead, DoC itself chose to delegate the DNS functions to ICANN, relying on its general authority to enter into contracts. ICANN is also a very unusual corporation. There are many government contractors, both profit-making and nonprofit. But it is unusual for a nonprofit corpo- [*pg 29] ration to be created for the express purpose of taking over a government regulatory function.
There is a danger, however, that ICANN may not be unique for long. One administration spokesperson has already suggested that ICANN should be a model for regulation of other Internet-related issues such as accreditation standards for distance learning and e-commerce over business-to-business "closed" networks.{36} The specter of a series of ICANN clones in the United States or in cyberspace should give one pause, because ICANN is a very bad model, one that undermines the procedural values that motivate both the APA and the Due Process Clause of the Constitution.{37}
DoC's reliance on ICANN has (1) reduced public participation in decisionmaking over public issues, (2) vested key decisionmaking power in an essentially unaccountable private body that many feel has already abused its authority in at least small ways and is indisputably capable of abusing it in big ways, and (3) nearly (but, as argued below, not quite) eliminated the possibilities for judicial review of critical decisions regarding the DNS. So far, ICANN appears to be accountable to no one except DoC itself, a department with a strong vested interest in declaring its DNS "privatization" policy to be a success.
Democratic theory suggests that the absence of accountability tends to breed arbitrariness and self-dealing.{38} In addition to avoiding governmental accountability mechanisms, ICANN lacks much of the accountability normally found in corporations and in nonprofits. Or- [*pg 30] dinary corporations have shareholders and competitors. ICANN does not because it is nonprofit and has a unique relationship with the Department of Commerce. Many nonprofit organizations have members who can challenge corporate misbehavior. ICANN has taken steps to ensure that its "members" are denied such legal redress under California law.{39} All but the wealthiest nonprofits are constrained by needing to raise funds; ICANN faced such constraints in its early days, but it has now leveraged its control over the legacy root into promises of contributions from the registrars that have agreed to accept ICANN's authority over them in exchange for the ability to sell registrations in .com, .org and .net, and from NSI, the dominant registrar and monopoly .com/.org/.net registry,{40} which agreed to pay $2.25 million to ICANN this year as part of agreements hammered out with DoC and ICANN.{41} The result is a body that, to date, has been subject to minimal accountability. Only DoC (and, in one special set of cases, NSI or registrars{42}) currently has the power to hold ICANN account- [*pg 31] able. NSI currently has no incentive to use its limited power, and DoC has nothing to complain of so long as ICANN is executing the instructions set out in the White Paper. The accountability gap will get worse if DoC gives full control of the DNS to ICANN.{43} But it should be [*pg 32] noted that opinions may differ as to whether DoC could legally give away its interest in DNS to ICANN without an act of Congress. It is likewise unclear what precisely "giving away control" would consist of beyond DoC's interest in its contracts with the maintainer of the root, since the most important part of anyone's "control" over the root is publishing data that other parties, many of whom are independent of the government, choose to rely on.{44}
Part I of this Article describes the domain name system and its central role in the smooth functioning of the Internet as we know it today. The DNS is a hierarchical system in an otherwise relatively decentralized Internet. Section A explains what a domain name is, what domain names do, and how domain names are assigned and acquired. Section B explains the technical source of control over the DNS and why this control over the DNS system is so important.
Part II of the Article lays out the convoluted legal and contractual history of the DNS in order to establish the foundation for the legal argument in the third part. Part II thus describes the growing formalization of DNS regulation and the increasingly conscious intervention of the U.S. government in DNS policymaking. What began as small operation, below the policy radar, affecting only a small number of computers, grew in importance as the Internet grew and as the number of attractive names remaining to be registered in .com shrank. Existing arrangements came under increasing strain as conflicts over names, especially between trademark holders and registrants, grew. Where there had been uncertainty for many years as to precisely where authority over the root might reside, by 1998 the U.S. government had defeated an attempt to redirect the root and amended its contract with NSI to make the government's supremacy clear. Power, however, brought responsibility and increased controversy. The debate over the addition of new top-level domains to the root brought matters to a head and triggered active intervention by DoC and an interagency group headed by Presidential Senior Adviser [*pg 33] Ira Magaziner. Their policy review culminated in the White Paper, which called for an entity like ICANN to take over the management of the DNS.
Part III of this Article offers a legal analysis concentrating on the federal government's role in DNS policymaking. How ICANN perceives itself is of only minor relevance to the legality of DoC's reliance on it. The central questions concern: (1) the nature of ICANN's actions and (2) the nature of DoC's response to ICANN's actions. ICANN does something that is either is "standard setting" or is something more, such as "policymaking" or "rulemaking." Determining whether ICANN does "policy" requires a fairly detailed excursion into ICANN's and the DNS's history and contributes mightily to the length of this Article. But this is a critical issue, because if ICANN is engaged in mere standard setting, then there is no APA or constitutional issue; however, if ICANN is doing something more than mere standard setting, then the nature of DoC's response to ICANN's actions is legally significant.
If ICANN is engaged in policymaking, and if DoC is reviewing these decisions and retaining the authority to countermand them, then DoC's adoption of or approval of ICANN's regulatory and policy decisions are subject to the APA. One could argue as to whether DoC's approval is an informal adjudication under the APA,{45} or whether due to its overwhelming influence over ICANN and due to its adopting ICANN's rules, DoC is engaged in rulemaking without proper notice and comment. In either case, however, the APA has been violated.
If, on the other hand, ICANN is engaged in policymaking and DoC does not retain the power to countermand ICANN's decisions, then DoC has delegated rulemaking and policymaking power to ICANN. This probably violates the APA, since it was done without proper rulemaking; regardless of the applicability of the APA, it violates the Due Process Clause and the nondelegation doctrine of the U.S. Constitution, as well as basic public policy norms designed to hold agencies and officials accountable for their use of public power. Since ICANN's board and staff operate largely in secret, it is difficult for outsiders to know how much influence DoC has over ICANN's [*pg 34] decisionmaking. As a result, the statutory and constitutional arguments in this Article are presented in the alternative. The two arguments are very closely related, however, in that both rely on legal doctrines designed to promote accountability and prevent the arbitrary exercise of government power.
My analysis is substantially different from both DoC's and ICANN's accounts of their roles and their relationship. DoC's account of its relationship with ICANN relies on what I shall call the private party story and the standard-setting story. The private party story relies on ICANN's status as a California nonprofit corporation. Government agencies have to observe due process, and many rules about openness, even-handedness, and especially advance notice, not least of which are the procedures set out in the Administrative Procedure Act. If they fail to observe these requirements, they are subject to judicial review. Because ICANN is (formally) a private corporation, it does not face similar obligations. It is beyond argument that private parties are almost never subject to the APA.{46}
In fact, as detailed below, ICANN's relationship to DoC is nothing like the arms-length relationship suggested by the private party story. Although ICANN is private, it is no ordinary corporation, and its relationship with DoC is highly unusual. ICANN is totally beholden to DoC for its creation, its initial policies, and especially DoC's loan of control over the root. This control over the root is the sole basis of ICANN's relevance, power, and financing, and DoC can take it away on 120 days' notice, a right that persists even after the recent renewal of ICANN's contract.{47} More than anything, ICANN [*pg 35] seeks to achieve permanent and, perhaps, irrevocable control of the root when the current memorandum of understanding (MoU) expires. DoC has some control over ICANN through the stick of the MoU, but the real control comes from the carrot. ICANN's ability to retain or expand its control over the root is entirely at DoC's discretion.
The standard-setting story focuses on what ICANN does. In this story, ICANN does only "technical coordination" relating to the DNS. ICANN does not do "policy"; if there was any policy to be done (DoC is a little vague on this), it was done in the White Paper -- a statement of policy. And ICANN most certainly does not do "regulation" or "governance." ICANN is at most implementing the key pieces of the White Paper policy: privatization, Internet stability, increasing competition, bottom-up coordination. To the extent that ICANN might be making decisions that have impacts on third parties, this is merely setting standards, not making policy, and it is well settled that the government can rely on private groups to set standards.{48}
There is no question that contractors can administer a federally owned resource, such as the snack bar in a federal building. Moreover, the United States has created a number of federal government corporations, mostly to undertake commercial activities; some are private, a few have mixed ownership, but all have federal charters and direct congressional authorization.{49} While the federal use of state- [*pg 36] chartered corporations to undertake federal tasks is rare, and usually criticized,{50} if it were true that ICANN was limited to "technical coordination," that would rebut the claim of an unconstitutional delegation of power. In fact, as detailed below, the standard-setting story ignores reality. While some of what ICANN does can fairly be characterized as standard setting, key decisions would certainly have been rulemaking if done directly by DoC and remain regulatory even when conducted by its proxy.{51}
Having said what this Article is about, a few words about what it is not about may also be in order. Opinions differ -- radically -- as to the wisdom of ICANN's early decisions, decisions with important worldwide consequences.{52} Opinions also differ as the adequacy of ICANN's decisionmaking procedures. And many legitimate questions have been raised about ICANN's ability or willingness to follow its own rules.{53} Whether ICANN is good or bad for the Internet and whether the U.S. government should have such a potentially dominant role over a critical Internet resource are also important questions. This Article is not, however, primarily concerned with any of these questions. Nor is it an analysis of the legality of actions taken by ICANN's officers, directors, or employees. In particular, this Article does not discuss whether ICANN's actions comply with the requirements of California law regarding nonprofit corporations. Despite their importance, all of these issues will appear only tangentially insofar as they are relevant to the central, if perhaps parochial, question: whether a U.S. administrative agency is, or should be, allowed to call into being a private corporation and then lend it sufficient control over a government resource so that the corporation can use that con- [*pg 37] trol effectively to make policy decisions that the agency cannot -- or dares not -- make itself.
Although focused on DoC's actions, this Article has implications for ICANN. If the government's actions in relation to ICANN are illegal or unconstitutional, then several -- but perhaps not all -- of ICANN's policy decisions are either void or voidable, and DoC might reasonably be enjoined from further collaboration with ICANN in other than carefully delineated areas. Some of these implications for ICANN, and for the Internet, are canvassed in Part IV.
The Internet works the way it does because it is able to route information quickly from one machine to another. IP numbers provide the identifying information that allows an e-mail to find its destination or allows a request for a web page to reach the right computer across the Internet. Until recently,{58} web page accesses, unlike e-mail, always could be achieved with an IP number. Thus, for example, was equivalent to . However, e-mail to froomkin@129.171.187.10 will not inevitably reach me -- or anyone else. (On most systems, however, e-mail to froomkin@[129.171.187.10] will reach me. But it is not inevitable or easy to type.) Because IP numbers are hard for people to remember, the designers of the Internet introduced easier alphanumeric domain names as mnemonics. When a user types an alphanumeric Uniform Resource Locator (URL) into a web browser, the host computer must "resolve" the domain name -- that is, translate it into an IP number.{59} Both domain names and IP numbers are ordinarily unique (subject to minor exceptions if resources are interchangeable). Using domain names also increases portability -- since numbers can be arbitrarily assigned to names, the names can stay constant even when the resources to which they refer change. The system by which these unique domain names and IP numbers are allocated and domain names resolved to IP numbers is a critical function on the Internet. Each of the thirteen legacy root name servers handles millions of [*pg 39] DNS queries a day,{60} and uncounted millions more are handled downstream by ISPs and others who cache the most frequently requested domain names to IP mappings.
Currently, the large majority of domain names for Internet resources intended to be used by the public have a relationship to two organized hierarchies. (Internet-based resources for private use, such as intranets, can be organized differently.) The first, very visible hierarchy relates to naming conventions for domain names and constrains how domain names are allocated. The second, and largely invisible, hierarchy determines the ways in which domain names are resolved into the IP numbers that actually make Internet communication possible. The two hierarchies are closely related but not identical.
Domain naming conventions treat a domain name as having three parts: in the address www.miami.edu for example, "edu," the rightmost part, is the "top-level domain" or "TLD," while "miami" is the second-level domain (SLD), and any other parts are lumped together as third-or-higher-level domains. Domain names are just conventions, and a core part of the current dispute over them arises from the conflict over whether new TLDs should be added to the so-called "legacy root" -- the most widely used, and thus most authoritative, list of which TLDs will actually map to IP numbers. It should be noted that in addition to the "legacy root" TLDs discussed in this Article, there are a large number of "alternate" TLDs that are not acknowledged by the majority of domain name servers.{61} There is no technical bar to their existence, and anyone who knows how to tell his software to use an alternate domain name server can access both the "legacy root" and whatever alternate TLDs are supported by that name server. Thus, for example, choosing to get domain name services from 205.189.73.102 and 24.226.37.241 makes it possible to resolve where a legacy DNS would only return an error message.
The legacy root is currently made up of 244 two-letter country code TLDs (ccTLDs), seven three-letter generic TLDs (gTLDs), and [*pg 40] one four-letter TLD (.arpa).{62} The 244 ccTLDs are almost all derived from the International Organization for Standardization's ISO Standard 3166.{63} Not every ccTLD is necessarily controlled by the government that has sovereignty over the territory associated with that country code, however. This is likely to be an area of increasing controversy, as (some) governments argue that the ccTLD associated with "their" two-letter ISO 3166 country code is somehow an appurtenance of sovereignty.{64} The ccTLDs sometimes have rules that make registration difficult or even next to impossible; as a result, the gTLDs, and especially .com, have the lion's share of the registrations. Three gTLDs are open to anyone who can afford to pay for a registration: .com, .org, and .net. Other gTLDs impose additional criteria for registration: .mil (U.S. military),{65} ..gov (U.S. government),{66} ..int (international organizations), .edu (institutions of higher education, mostly U.S.-based), and .arpa.{67} Domains registered in ccTLDs and gTLDs are equally accessible from any computer on the Internet.
[*pg 41]
2. The Registration Hierarchy. The registration side of the current DNS architecture is arranged hierarchically to ensure that each domain name is unique. At least prior to the recent introduction of a "shared registry" system,{68} which seems to have introduced some at least transitory uncertainty about whether the master list of second-level domain names is authoritative, a master file of the registrations in each TLD was held by a single registry.{69} In theory, and ignoring software glitches, having a single registry ensures that once a name is allocated to one person, it cannot simultaneously be assigned to a different person. End-users seeking to obtain a unique domain name must obtain one from a registrar.{70} A registrar can be the registry or it can be a separate entity that has an agreement with the registry for the TLD in which the domain name will appear. Before issuing a registration, the registrar queries the registry's database to make certain the name is available. If it is, it marks it as taken, and (currently) associates various contact details provided by the registrant with the record.{71}
While one can imagine other possible system architectures, the current domain name system requires that each domain name be "unique" in the sense that it be managed by a single registrant rather than in the sense that it be associated with a single IP number. The registrant may associate the domain name with varying IP numbers if that will produce a desired result. For example, a busy website might have several servers, each with its own IP number, that take turns serving requests directed to a single domain name.{72} In a different [*pg 42] Internet, many computers controlled by different people might answer to . In that world, users who entered that URL, or clicked on a link to it, would either be playing a roulette game with unpredictable results, or they would have to pass through some sort of gateway or query system so their requests could be routed to the right place. (One can spin more complex stories involving intelligent agents and artificial intelligences that seek to predict user preferences, but this only changes the odds in the roulette game.) Such a system would probably be time-consuming and frustrating, especially as the number of users sharing popular names grew. In any case, it would not be compatible with today's e-mail and other non-interactive communications mechanisms.{73}
3. The Domain Name Resolution Hierarchy. The name resolution side of the domain name system is an interdependent, distributed, hierarchical database.{74} At the top of the hierarchy lies a single data file that contains the list of the machines that have the master lists of registrations in each TLD. This is the "root zone," or "root," also sometimes known as the "legacy root." Although there is no technical obstacle to anyone maintaining a TLD that is not listed in the legacy root, these "alternate" TLDs can only be resolved by users whose machines, or Internet service providers (ISPs) as the case may be, use a domain name server that includes this additional data or knows where to find it. A combination of consensus, lack of knowledge, and inertia among the people running the machines that administer domain name lookups means that domain names in TLDs outside the legacy root, e.g., http://lightning.faq, cannot be accessed by the large majority of people who use the Internet, unless they do some tinkering with obscure parts of their browser settings.{75}
[*pg 43]
Domain names are resolved by sending queries to a set of databases linked hierarchically. The query starts at the bottom, at the name server selected by the user or her ISP. A name server is a network service that enables clients to name resources or objects and share this information with other objects in the network.{76} If the data is not in the name server, the query works its way up the chain until it can be resolved. At the top of the chain is the root zone file maintained in parallel on thirteen different computers.{77} These thirteen machines, currently identified by letters from A-M, contain a copy of the list of the TLD servers that have the full databases of registered names and their associated IP numbers. (To confuse matters, some of these machines have both a copy of the root zone file and second-level domain registration data for one or more TLDs.) Each TLD has a registry that has the authoritative master copy of the second-level domain names registered for that TLD, and the root zone file tells domain name resolving programs where to find them.
Thus, any discussion of the U.S. government's, or anybody else's, authority and control over the DNS occurs in the shadow of the peculiar fact that "control" does not work in a way familiar to lawyers. The United States does not "own" the entire DNS, although it has contracts with key players and owns a minority of the root servers. Most domain resolution functions take place on privately owned machines that may get their DNS data from other private machines, or from foreign machines, or from U.S. government contractors. The U.S. government's interest in the DNS indeed can be characterized in different ways. It could be argued that the U.S. government's control is ephemeral, since the only reason the root file matters is that the root server operators choose to get their base DNS data from it and that almost all other Internet users choose to get their root data from the thirteen legacy root servers.
Alternately, it could be argued that the U.S. government "owns" the root file that sits at the top of the DNS hierarchy, since the file is managed by NSI, under U.S. government contract. Indeed, in 1998, DoC amended its contract with NSI to make explicit DoC's power to decide what gets listed in the root file.{82} Yet, although DoC clearly controls the content of the file, the government's power over the root seems to sound more in contract than in property. Indeed, it is difficult to say that the U.S. government's interest is a traditional chattel [*pg 45] property right, since NSI owns the machine on which the root file resides. Nor is it easy to characterize DoC's interest as an intellectual property right. Although the root shares with domain names the property that it is a pointer to something,{83} it is just a small file of data. The root file lacks sufficient originality to be copyrightable, nor is it the sort of collection likely to be entitled to a compilation copyright. Furthermore, if the root file belongs to the government, and it is continually published, then under the 1976 Copyright Act, it is a "work" not subject to copyright.{84}
Whatever control DoC enjoys over the content of the root file remains meaningful only so long as other participants in the DNS -- and especially the twelve other root servers{85} at the next level of the hierarchy -- continue to rely on a U.S. government-controlled root server as their source of the master DNS root file. As long as the United States retains its control of the root file, however, the danger that the twelve root server operators will choose to get their data from elsewhere seems very remote for four reasons: First, of the twelve root servers that draw data directly from the "A" root server at the top of the DNS hierarchy, seven currently are owned by the U.S. government or operated by its contractors. Only three of the servers are located outside the United States.{86} Any move by the non- [*pg 46] U.S. or even non-U.S. government root servers to choose a new source for the master file would be certain to split the root, because the U.S. servers would not follow suit. Second, the old Internet hands who manage key parts of the infrastructure such as the root servers have a very great aversion to anything that looks as if it might split the root.{87} Third, the ur-lord of the DNS, the late Jon Postel, apparently tried to redirect the root from the "A" server and was intimidated into withdrawing the attempt.{88} If Postel could not do it, it is unlikely that others could today. And, fourth, ICANN is currently seeking to move the root file to its own server and to negotiate direct agreements with the other root server operators, which could make the whole issue moot by reducing their independence from ICANN.{89} If DoC were to choose not to renew its contracts with ICANN at some point in the future, then DoC or its designee as ICANN's successor presumably would become the beneficiary of any agreements ICANN had concluded with the root server operators.{90} Ironically, in this scenario, the "privatization" of the DNS proposed in the White Paper could lead ultimately lead to tighter U.S. government control over the DNS.
Control of the root potentially confers substantial economic and political power. The root determines which TLDs are visible to the vast majority of Internet users. The most naked exercise of this power involves deciding what data is contained in the single data file that comprises the root. Given current Internet architecture and customs, [*pg 47] the data in that file determines which gTLDs the vast majority of Internet users can access.{91}
People who register Internet domain names do so in hopes that anyone in the worldwide network will be able to reach them. It may be that they wish their websites to be visible around the world, or it may be that they want to get e-mail, or to engage in two-way chat. Whatever the application, a domain name that cannot be resolved into an IP number{92} by the vast majority of users is of very limited value on the Internet. Similarly, registrars selling domain name registrations understand that only domain names that "work" in the sense of being part of the global network carry much value. The ability to list a registration in a registry that is part of the "legacy" root is thus of paramount importance to a registrar. Similarly, every registry knows that its database of domain name to IP mappings is of limited value if no one can find it. Registries thus need to be listed in the root or they (and all the domains they list) become effectively invisible. As only being listed in the legacy root currently provides visibility for a TLD and the domains listed in it, control of the root creates powerful leverage.
The power to add TLDs to the legacy root has implications for intellectual property rights, consumer choice, competition, the ease of political discourse, and e-commerce generally. It even has implications for nation-building and international law. The root authority can add the top-level domain of any nation or pretender to nationhood; it can create gTLDs such as .shop or .biz in minutes, and within a day or so the results of these decisions automatically echo around the world. For example, when Palestinians wanted to have .ps created as a country code, they first persuaded the keepers of the ISO country code list to add .ps. Since the current policy for determining which "countries" should be listed in the root relies on this list, once the Internet Assigned Numbers Authority (IANA){93} determined that the ISO 3166-1 list had been amended to include .ps as a code for "Palestine," it certified that .ps should be added to the root and announced that it was accepting an application from a Palestinian academic to run the new [*pg 48] .ps domain.{94} At some subsequent point, the Department of Commerce must have approved the change in writing, since its agreement with NSI requires written confirmation for all changes to the root.{95} Although at this writing .ps does not appear to be accepting applications for second-level domain names, the ccTLD is listed in the root.{96}
The power to create is also, at least temporarily, the power to destroy. Because the servers in the DNS chain regularly refresh their cached data from the servers above them in the chain, the root server's decision to remove a nation's TLD from the web could make it effectively inaccessible to everyone who did not have alternate means of turning a domain name into an IP number. Delisting would severely limit the victim's Internet communications -- at least until the managers of other DNS servers in the world manually reinserted the deleted data in their copies of the root. Thus, control over the DNS confers substantial economic and political power. Since both civilian and military infrastructures in many nations are becoming increasingly dependent on the existence of the Internet, the ability to [*pg 49] disrupt an enemy's communications might be a strategic asset in wartime.{97}
However, even if it could be effective, this ploy would work at most once, because, were the U.S. to use the root for strategic advantage, all root servers located abroad would undoubtedly stop mirroring the data served from the U.S. immediately, even if it split the root.
A more subtle, but already commonplace, use of the root authority involves putting contractual conditions on access to the root. ICANN has imposed a number of conditions on registrars and commercial gTLD (but not ccTLD) registries on a take-it-or-be-delisted basis. For example, ICANN not only forbids anonymous registrations; it also forbids the Internet equivalent of an unlisted telephone number. Under ICANN's contractually imposed regulations, which continue the practices it inherited from NSI, every registrant of a domain name in a gTLD must consent to worldwide publication of her name, telephone number and address.{98} Unlike NSI, however, ICANN provides for rigorous enforcement of this rule, since under ICANN's mandatory arbitration policy, the Uniform Domain Name Dispute Resolution Policy, a domain name registration in "bad faith" is a key ground for transferring a domain from a registrant to a trademark holder,{99} and failing to provide accurate contact details is evidence of bad faith.{100} The addition of the UDRP is a radical change: under ICANN, every registrant in a gTLD must agree to a third-party beneficiary arbitration clause. Anyone anywhere who [*pg 50] believes that the registration or use of the domain name infringes a trademark or service mark can invoke this clause to force arbitration before one of a list of ICANN-approved arbitration service providers paid for and selected by the complainant.{101}
One aspect of the legal history and pre-history of ICANN deserves special mention before embarking on a detailed contractual history. Like the story of Sherlock Holmes's dog that did not bark in the night, the ICANN story contains a telling absence. The ICANN story lacks a statute. At no time has Congress ever authorized ICANN or the "privatization" of the DNS. DoC has relied on its general statutory authority to manage and to seek to "privatize" the DNS.{103} As a result, the critical legal documents are all contracts, [*pg 51] memoranda of understanding, or other bilateral agreements either between DoC and contractors, or among government contractors.
Compared to an ordinary legislative history, the contractual history described below is complex, sometimes confusing, rich in acronyms, and at times perhaps a little boring. Yet the legal underpinnings of the current DNS cannot be understood without a slog through it. The contractual history makes clear that the origins of the DNS and its management were informal, and only a small part of larger projects. When the Internet was small, the issues that now loom large were of little importance and attracted almost no attention. As the Internet, and especially its perceived commercial importance, grew, so too did the conflict over the rules to be applied to the DNS. Whatever doubt there may have been about the U.S. government's authority seems to have been resolved by mid-1997, when NSF decisively exercised its authority.{104} Policy control then passed to an interagency working group headed by Ira Magaziner, and to the Department of Commerce, which issued a critical policy document, the DNS "White Paper."{105} Although as a mere policy statement the White Paper did not have the force of law, major parts of its policies were quickly implemented, notably the creation of ICANN and the institution of a new domain name dispute policy that sought to meet the concerns of trademark holders.
The idea of giving internetworked computers easily remembered names dates back at least to 1971.{106} Peggy Karp, one of the early authors and editors of the Internet standards,{107} and the author of the [*pg 52] first request for comments (RFC) on host names, prepared the first hosts.txt file (the predecessor of the modern "root" file) and turned it over to the Stanford Research Institute (SRI) in early 1972. For the next fourteen years, the hosts.txt file was maintained by the SRI Network Information Center (NIC), then the Defense Data Network (DDN) NIC, and then the Defense Information Systems Agency (DISA) NIC.{108} Internet pioneer Paul Mockapetris wrote the specification for the original implementation of the DNS we have today,{109} but the transition to it took several years. Meanwhile, maintenance and administration of the system remained the responsibility of the SRI NIC for DISA.{110} During this period, the SRI NIC not only hosted the root file, but also served as the domain name registrar and registry for most gTLDs.
While the SRI NIC provided the machines and mechanics, starting about 1977,{111} the day-to-day responsibility for coordinating changes in standards and policy fell to a UCLA graduate student, Jon Postel, who was funded by a U.S. Department of Defense grant.{112} Postel, who had started coordinating other Internet protocols as early as 1972,{113} took on the task of assigning IP numbers, and (at some [*pg 53] point) protocol values for domain names. Thus, Postel, working through the evolving consensus procedures for setting Internet standards, decided which gTLDs and ccTLDs would be created and personally selected the people who would be empowered to register names in ccTLDs. When, after receiving his Ph.D., Dr. Postel moved to the University of Southern California's Information Sciences Institute, he took these functions with him.{114}
In October 1983, Postel and his colleague, Joyce Reynolds, authored RFC 920, "an official policy statement" of the Internet Architecture Board (a private Internet standards body){115} and the Defense Advanced Research Projects Agency (DARPA).{116} This official policy of the government and the Internet standards body defined most of the TLDs in use to this day.{117}
In 1985, DISA formally gave the responsibility for managing the expansion of the namespace to the Information Sciences Institute (ISI) at USC.{118} As early as 1974, ISI had begun to manage some other RFC administrative activities. At some later point, perhaps December 1988,{119} ISI reorganized. ISI, led by Postel, began operating the DNS and other RFC operational activities under the rubric of the Internet Assigned Numbers Authority,{120} pursuant to authority delegated from the U.S. Department of Defense.{121}
[*pg 54]
In 1986, DISA began allowing some offshore DARPA research centers to perform some DNS registration functions, the first of which was University College, London, for a UK domain. Later, it allowed a research facility in Amsterdam to manage some IP address blocs under the rubric RIPE. The government contracts for these activities remained with ISI, of which IANA was an unincorporated administrative unit. IANA's funding came from Department of Defense grants to USC.{122} Although for a time IANA claimed to have a charter from the Internet Society (ISOC) and the Federal Networking Council, it was at all relevant times a government contractor.{123}
Between 1972 and 1994, Dr. Postel and (starting in the late 1980s) IANA{124} documented their procedures in a set of requests for comments, which were adopted by the Internet Engineering Task Force (IETF).{125} The IETF is an independent, unincorporated, international standards body of continually floating membership. Although RFCs are nonbinding, they are widely recognized as the critical Internet standards documents and often have enormous influence.{126} Thus, for example, in RFC 349, Postel, still a graduate student, wrote presciently, "I propose that there be a czar (me?) who hands [*pg 55] out official socket numbers for use by standard protocols. This czar should also keep track of and publish a list of those socket numbers where host specific services can be obtained. I further suggest that the initial allocation be as follows . . . ."{127} By the time of his death in 1998, by all accounts Jon Postel and his colleague Joyce Reynolds were not only socket czars, but Internet names and numbers czars.
In 1990, DISA recompeted the NIC contract, which was won by Government Systems Inc. (GSI),{128} who then subcontracted the entire operation to Network Solutions, Inc. NSI started operating the NIC early in 1992. By then, DISA had concluded that the continued growth of the Internet and the introduction of new programs such as the National Research and Educational Network (NREN) meant that the funding and management of the non-military part of the Internet's administration belonged outside the Department of Defense.{129} NSF had already begun funding cooperative private-sector Internet research and development in 1986 and continued to do so on an increasingly large scale until 1995.{130} Unlike the Department of Defense, NSF provided grants to the private sector and entered into "cooperative agreements" to undertake the needed work with the "technology transfer" expectation that anything developed could eventually be undertaken and owned entirely by the grantee.{131}
In 1994, Dr. Postel authored RFC 1591, Domain Name System Structure and Delegation,{132} in which he described his policies and procedures for assigning domain names. Several issues which are fraught [*pg 56] with controversy today took only a paragraph or two to explain in 1994. Thus, for example, RFC 1591 described relatively lightweight procedures for creating new top-level domains -- an issue that has more recently consumed years of debate without the creation of any new gTLDs. Since establishing the basic system of gTLDs and ccTLDs, Postel and IANA had created a small number of additional ccTLDs and a few limited-use gTLDs, but no gTLDs for general use. By 1994, the demand for names in the gTLD space was still very small; the explosion in demand did not begin until at least two years later.{133} RFC 1591 also described how one qualified to manage a ccTLD. It set up a rule of first-come, first-served so long as one had decent Internet connectivity, acted fairly, and was accepted by the user community. Cases in which a ccTLD manager lost the confidence of his users were to be resolved by negotiation among the squabbling parties.{134} As for what is a country name, and who has the right to a domain name that resembles a trademark, RFC 1591 said only this:
1) Names and Trademarks
In case of a dispute between domain name registrants as to the rights to a particular name, the registration authority shall have no role or responsibility other than to provide the contact information to both parties.
The registration of a domain name does not have any Trademark status. It is up to the requestor to be sure he is not violating anyone else's Trademark.{135}
If nothing else, it seems safe to say that by 1994 the authority for DNS policy was somewhat muddled. The entry of a new player would confuse matters further.
2. The NSF-NSI Cooperative Agreement (1993-95). In 1993, about a year before Jon Postel issued RFC 1591, the National Science Foundation replaced the Department of Defense as the funding source for the NIC.{139} It engaged Network Solutions, Inc. to take over the domain name registration services for the non-military Internet, a function that NSF estimated would require it to spend around $1 million per year.{140} NSI thus ran the computers that held the root zone, was responsible for the mechanics of inserting new TLDs into the root (although not for deciding which, if any, should be included), and also took on the function of day-to-day assignment of second-level domain names in .com, .org and .net on a first-come, first-served basis. The NSF-NSI "Cooperative Agreement"{141} gave NSI a monopoly over .com registrations that it would ultimately build into a multi-billion dollar business; the monopoly originally was scheduled to expire in September 1998.{142}
The agreement gave NSI operational control of the DNS but, as in the predecessor agreement between DISA and GSI, required NSI to follow the policy directions of IANA. Article 3 of that agreement required NSI to "provide registration services in accordance with the provisions of RFC 1174."{143} In turn, RFC 1174 stated that IANA had "discretionary authority to delegate [responsibility] with respect to [*pg 58] numeric network and autonomous system identifiers."{144} RFC 1591 soon amplified RFC 1174, although since it was only an "informational" RFC, it arguably was not binding on NSI. RFC 1591 describes IANA as "the overall authority for the IP Addresses, the Domain Names, and many other parameters, used in the Internet."{145} Since the paymaster for IANA remained the U.S. Department of Defense, the effect of this provision was to ensure that policy control of the root remained in the hands of people closely tied to the U.S. government, and especially the military, even while daily functions such as second-level domain name registration services were moving into NSF's, and through them NSI's, hands.
The profit potential of the domain name registration business soon grew. In September 1995, NSF agreed to amend the Cooperative Agreement to allow NSI to charge user fees of $50 per year for domain names.{146} IANA, still working under Department of Defense contracts, remained in charge of fundamental policymaking, but NSI's control over the mechanics of registration allowed it to, and perhaps even operationally required it to, make decisions that had policy im- [*pg 59] plications. The most controversial of these was undoubtedly NSI's frequently amended "dispute policy." Although the details varied from version to version, in essence the policy provided that any person proffering a trademark on a word identical to another person's domain name registration could have the registration put "on hold" -- frozen so that it would no longer resolve to an IP number and was, thus, of no practical use.{147} The dispute policy greatly benefited NSI, as it nearly eliminated its exposure to lawsuits by trademark owners, who tended to be better financed and better represented than non-trademark-owning registrants.
3. The TM Community Awakens. NSI had reason to fear lawsuits. The Internet's explosive growth fueled a land-rush mentality for domain names, especially in the .com domain. In response to the growing demand for new gTLDs, Dr. Postel had endorsed creating a large number of new gTLDs as early as November 1995.{148} Postel's own plan involved creating 150 new TLDs in the first year alone.{149} But already the trademark problem threatened to dominate any debate over the creation of new TLDs, and Postel's plan, like his earlier proposal{150} to de-link IANA from the U.S. government and [*pg 60] find other backing such as the Internet Society, failed to garner sufficient support.{151}
In compliance with NSF's directive to encourage use of the Internet, and in keeping with the growing .com mentality of wanting to do everything immediately, NSI allowed registrants a long grace period; even after NSI started charging $100 for two-year domain name registrations, NSI waited thirty days before sending a bill, and then gave additional time to pay, creating a long float.{152} As there was no limit to the number of names a person could register, name speculators quickly understood that they could register names and attempt to seek buyers for them without risking any capital.{153} While some speculators sought common words with multiple possible uses, a few others -- who became known as cybersquatters -- registered thousands of names that corresponded to the trademarks of companies that had not yet found the Internet and then sought to resell (or, some would say, ransom) the name to those companies. Since the Lanham Act requires commercial use before a court will find trademark infringement, it seemed more than arguable that mere registration, without use, was legal, and that the brokers/cybersquatters had found a costless way to profit.{154}
Much of early cybersquatting law was defined by one of the most active cybersquatters, Dennis Toeppen. By 1996, in Intermatic Inc. v. Toeppen,{155} the first court had held that registering domain names in order to offer them for sale to a firm of that same name constituted an actionable commercial use of that name under the Federal Trademark Dilution Act.{156} The Ninth Circuit later essentially adopted this reasoning in the landmark 1998 case of Panavision International v. [*pg 61] Toeppen.{157} The specter of illegality, however, did not stop the cybersquatters, as they could still exploit the settlement value of cases: they put no money down, or just the cost of a registration, which was $100 or less, and could negotiate for sums up to the filing costs, attorney's fees, and value of management time, which usually added up to at least a few thousand dollars.{158}
4. PGP Media Lawsuit (1997). By 1997, it was evident that domain names would be valuable, and that NSI had a valuable franchise. Other firms sought to become registries and to establish parallel top-level domains. Some set up alternate roots,{159} while others sought to force their way into the legacy root. One of the most persistent was PGP Media (later, Name.Space), a firm that in March 1997 wrote to NSI requesting that NSI add to the root zone file some 530 gTLDs that PGP Media alleged it had claimed. NSI argued that it lacked the authority to add entries to the root zone and referred Name.Space's request to IANA. PGP Media responded by filing a complaint alleging antitrust violations against NSI, with IANA named as a nonparty co-conspirator. As the Second Circuit summarized it:
NSI then wrote to Dr. Jon Postel at IANA on March 27, 1997, informing him of this lawsuit and seeking to confirm NSI's understanding that it could make changes to the root zone file only at the direction of IANA. IANA responded on April 4, 1997 by denying that IANA had any authority over NSI's operations, and stating that IANA also had no authority to establish any new gTLDs in the absence of an Internet community consensus. Therefore, NSI wrote to NSF on June 10, 1997 describing the events that had transpired to date, and requesting authority to begin accepting applications for new gTLDs pursuant to a registration procedure.{160}
NSF officially rejected NSI's proposal on June 25, 1997, and explicitly requested that NSI add no new TLDs to the root zone file pending the conclusion of an internal review of DNS policy, an order it confirmed the next month. Name.Space responded by amending its complaint to include NSF, although that part of the case became moot after ICANN was formed.{161} Although Name.Space ultimately lost on all counts,{162} the maneuvering did have important consequences. IANA disclaimed authority over NSI and asserted only an equivocal authority over the root, the ability to act on the basis of consensus. In contrast, NSF demonstrated control over NSI and thus, in effect, over the root zone file.
5. The Road to the White Paper (1997-98). As the Internet grew, and as commercial considerations began to loom larger, the U.S. government's control of the root began to be a magnet for controversy. Foreign governments began to question why the United States should control a critical component of a global network, and firms all over the world began to complain about the uneasy overlap between domain names and trademarks.{163} In July 1997, in response to these growing domestic and international concerns regarding the future of the DNS, President Clinton directed the Secretary of Commerce to privatize the DNS.{164} On July 2, 1997, the Department [*pg 63] of Commerce issued a request for comments on DNS administration, on behalf of an interagency working group headed by Ira Magaziner.{165} Magaziner's reputation had suffered from his responsibility for the debacle of President Clinton's national health care initiative, and commentators speculated that he saw his role in Internet policymaking as a chance to do some repair work.{166} Magaziner was also influential in crafting the administration's policy statement on e-commerce.{167}
Agencies commonly issue requests for comments as a first step towards figuring out whether (and how) to regulate. While not all such requests result in a notice of proposed rulemaking (NPRM), an NPRM is a routine next step. An NPRM is a formal notice, published in the Federal Register, in which an agency sets out a proposed rule. In informal rulemaking under the APA, an NPRM is subject to public comment, after which the agency can either abandon the rule, substantially revise it and issue a fresh NPRM, or issue it, perhaps with minor changes.
On January 30, 1998, Magaziner and DoC published their proposal for the reform of DNS administration.{168} This document became [*pg 64] known as the Green Paper,{169} but in bureaucratic form it was just an ordinary NPRM proposing an informal rule.
Just before Magaziner published the Green Paper on the World Wide Web,{170} an incident occurred that demonstrated the fragility of the existing, somewhat informal, understandings about DNS authority and control. On January 28, 1998, Jon Postel -- who may have been aware of the likely content of the Green Paper{171} -- sent an e-mail requesting that the root servers not controlled by NSI or the U.S. government start pointing to his server "B" rather than server "A" for the authoritative data on the root.{172} Postel's "B" server continued to mirror the data in "A," so in the short term this shift would have changed nothing; in the longer term it would have enabled him to control the root and thus single-handedly create new TLDs. Most of the other root servers complied.{173} To his detractors, Postel was attempting a power grab, a single-handed hijack of the Internet, or even threatening to split the root, creating the dreaded possibility of inconsistent databases.{174} (Recall that inconsistent data is bad because it means that which IP resolves when one types in a domain name might depend on which database -- effectively which Internet -- one might be connected to.) When Ira Magaziner heard of what Postel would later diplomatically call a "test," Magaziner instructed Postel to return to the status quo. Postel did so, and the "test" was over.{175} Magaziner [*pg 65] was later quoted as saying that he told Postel that redirection could result in criminal charges,{176} although it is unclear what statute would apply.
The Green Paper mapped out an ambitious course of action for U.S. domain name policy, the details of which can be elided since the rulemaking was abandoned in the face of the opposition it engendered. The Green Paper remains noteworthy, however, for its account of why DoC felt it had the power to make rules about the DNS at all, given the absence of direct congressional authorization. The Green Paper listed five sources of DoC's statutory authority for this proposed rulemaking:{177} (1) the general mission statement of DoC for the promotion of U.S. commerce;{178} (2) DoC's National Telecommunications and Information Administration's (NTIA) power to coordinate telecommunications activities and assist in the formation of policies;{179} (3) NTIA's authority to "develop and set forth telecommunications policies";{180} (4) NTIA's power to conduct studies and make rec- [*pg 66] ommendations;{181} and (5) NTIA's authority to "issue such regulations as may be necessary to carry out" its functions.{182} Finding rulemaking authority in any of the above for giving ICANN even temporary control of the DNS in these statutes would be, to put it gently, a stretch. NTIA has the authority to conduct studies, to coordinate and formulate policy, and to make recommendations. It does not have independent rulemaking authority, and the congressional grant of power to act as a think tank cannot be leveraged into rulemaking power via DoC's general authority to make regulations "as may be necessary to carry out the functions assigned under this chapter"{183} when none of those functions involved regulating rather than studying or recommending.
As it happened, however, the question of DoC's or NTIA's rulemaking authority became moot, since the Green Paper foundered on politics. The Green Paper encountered substantial opposition,{184} and it became clear that DNS regulation was too controversial for consensus, or even a politically satisfying compromise. DoC and Ira Magaziner's interagency group abandoned their effort to issue a final rule, and instead, in June 1998, they issued a nonbinding statement of policy that became known as the DNS White Paper.{185} Whether or not DoC had the authority to issue a rule ceding even temporary control of the DNS, it never purported to do so. Unlike substantive rules, statements of policy are not subject to notice and comment under the APA,{186} because they are not a final decision as to citizen's rights or [*pg 67] duties. A statement of policy is intended to guide officials and inform the public,{187} but officials remain required to exercise their discretion when applying the policy, and citizens remain free to challenge each decision on a case-by-case basis.
Like the Green Paper before it, the White Paper framed the basic "Principles for a New System" as "stability, competition, private bottom-up coordination, and representation":{188}
1. Stability. . . . During the transition and thereafter, the stability of the Internet should be the first priority of any DNS management system. . . .
2. Competition. . . . Where possible, market mechanisms that support competition and consumer choice should drive the management of the Internet because they will lower costs, promote innovation, encourage diversity, and enhance user choice and satisfaction.
3. Private Sector, Bottom-Up Coordination. . . . A private coordinating process is likely to be more flexible than government and to move rapidly enough to meet the changing needs of the Internet and of Internet users. The private process should, as far as possible, reflect the bottom-up governance that has characterized development of the Internet to date.
4. Representation. . . . Management structures should reflect the functional and geographic diversity of the Internet and its users. Mechanisms should be established to ensure international participation in decision making.{189}
a new, not-for-profit corporation formed by private sector Internet stakeholders to administer policy for the Internet name and address system. Under such agreement(s) or understanding(s), the new corporation would undertake various responsibilities for the administration of the domain name system now performed by or on behalf of the U.S. Government or by third parties under arrangements or agreements with the U.S. Government.{191}
The statement of policy went on to describe in a fairly detailed way what this new hoped-for corporation should look like, and how it should work. "NewCo" (as it came to be known) "should be headquartered in the United States, and incorporated in the U.S. as a not-for-profit corporation. It should, however, have a board of directors from around the world."{193} It should take over the existing IANA staff, and it should have the authority to "[s]et policy for and direct allocation of IP number blocks to regional Internet number registries" and "[o]versee operation of the authoritative Internet root server system"{194} plus "[o]versee policy for determining the circumstances under which new TLDs are added to the root system" while coordinating "the assignment of other Internet technical parameters as needed."{195}
The White Paper also prescribed a structure for NewCo's board of directors, which it said "should be balanced to equitably represent the interests of IP number registries, domain name registries, domain name registrars, the technical community, Internet service providers (ISPs), and Internet users (commercial, not-for-profit, and individuals) from around the world."{196} NewCo would start with an interim [*pg 69] board that would serve for a fixed period until the board of directors was elected, but interim board members would "not themselves serve . . . for a fixed period thereafter."{197} Government officials would be forbidden to serve on the board. The interim board would "develop policies for the addition of TLDs, and establish the qualifications for domain name registries and domain name registrars within the system."{198}
The White Paper further detailed the internal functioning of NewCo, stating it should be
governed on the basis of a sound and transparent decision-making process, which protects against capture by a self-interested faction . .. . . The new corporation could rely on separate, diverse, and robust name and number councils responsible for developing, reviewing, and recommending for the board's approval policy related to matters within each council's competence. Such councils, if developed, should also abide by rules and decision-making processes that are sound, transparent, protect against capture by a self-interested party and provide an open process for the presentation of petitions for consideration.{199}
In order to achieve these ends, the statement of policy committed the U.S. to a "[r]amp down" of its existing agreements with NSI that would require it to take actions to promote competition{204} -- although in practice the "ramp down" probably meant extending existing agreements rather than simply allowing them to end, as NSF earlier suggested.{205} Further, DoC pledged to require NSI to "recognize the role of the new corporation to establish and implement DNS policy and to establish terms (including licensing terms) applicable to new and existing gTLDs and registries under which registries, registrars and gTLDs are permitted to operate."{206} In other words, NewCo would become NSI's regulator in all but name.
Once ICANN was formed, it owed its purpose, power, and relevance to the Department of Commerce. Without Jon Postel, no one would ever have paid any attention to anything ICANN said, had not DoC designated ICANN as NewCo. ICANN derives its power from [*pg 71] contracts with DoC and acts as DoC's agent for DNS matters. DoC could, if it wished, terminate its relationship with ICANN and choose another body to perform all of ICANN's functions. Thus, whatever the legal formalities, DoC is the "but for" cause of ICANN's relevance, indeed its very existence, and the fundamental source of ICANN's powers. Nevertheless, subsection 1 below argues that because the formation was kept at arms' length, ICANN's creation did not violate the Government Corporation Control Act, the statute designed to prevent agencies from creating private corporations to do their will. Similarly, because DoC's relationship with ICANN is contractual, it probably complies with the letter of the Federal Advisory Committee Act.
Whatever the intentions may have been in early 1998, by early 1999 ICANN had adopted a Byzantine structure that privileged some interests, primarily corporate and commercial. The structure disadvantaged end-users and the firms that had expended resources to set up alternate registries.{207} Would-be registrars, on the other hand, benefited, as ICANN recognized them as one of the seven "stakeholder" interest groups entitled to preferential recognition in the ICANN structure.{208} One of the many oddities of the ICANN gerrymander of the Domain Name Supporting Organization (DNSO) is that future registrars were allowed to enter the registrars' constituency and vote before they were accredited by ICANN, but future registries were not. The first board members, selected for their lack of experience with the DNS wars, nevertheless proceeded to make fundamental decisions that affected the legal rights of all registrants in the three open gTLDs, and perhaps all Internet users. They also sought to impose fees on various participants in the DNS hierarchy and gutted the influence that non-corporate domain name registrants might have over the composition of subsequent boards.
[*pg 72]
The road to these results was anything but direct. It was the result of a tripartite struggle between NSI, ICANN and DoC. From its inception, ICANN embarked on a series of moves designed to raise revenue and to solidify its authority. Its first order of business was to become recognized as NewCo, its next to take over IANA's role in DNS administration. Last but not least, ICANN needed to get NSI to recognize its authority. Only when DoC had pressured a very reluctant NSI to recognize ICANN's authority -- at the price of extending NSI's monopoly over the .com registry business for years to come{209} -- was ICANN able to ensure that the policies it had adopted, such as the UDRP's mandatory arbitration rules, would affect every registrant in the commercial gTLDs. Indeed, each major step required intervention from DoC.
1. ICANN Formed (October 1998). After the publication of the White Paper, Postel and his lawyer, Jones Day partner Joe Sims, incorporated ICANN and set out to write bylaws that would be close enough to DoC's requirements for ICANN to be accepted as NewCo while preserving substantial freedom of action for the ICANN board.{210} The ICANN drafting and board recruitment efforts operated behind closed doors, but it benefitted from the imprimatur and prestige of Jon Postel.{211} Postel was intended to be the chief technical officer of ICANN,{212} and the interim board was designed to be composed of worthies who would be recognized as neutrals and would lend their prestige and neutrality to legitimate his decisions.{213}[*pg 73] (Recall that Postel's previous attempt to add TLDs to the root had been shelved due to protests, leading to questions about who had the authority to make DNS policy.{214}) An important part of the interim board members' function as neutrals would be to agree on how their successors should be selected. The decision to choose neutrals meant that the board members had to be chosen for their lack of involvement in the DNS wars, and this, in turn, meant that the first set of board members had little direct technical expertise relating to the DNS, although some had extensive technical background in other technologies.{215} The exemplar of both of these characteristics was the person ICANN would elect to head its board: Esther Dyson. Already well-known as a magazine publisher, venture capitalist, and Internet guru, Dyson was a highly respected name in most of the Internet community. She did not, however, have much experience in DNS matters.{216} Lack of experience, however, seemed a minor issue since Postel would be the CTO, and he was acknowledged to be a trusted, if not revered, figure by almost everyone interested in DNS policy. But Jon Postel died suddenly on October 16, 1998, just as plans to form ICANN were near completion.{217} With Postel's death, ICANN [*pg 74] lost the figure on which its legitimacy and trust had been based before it was even officially incorporated.
Following the lead of the White Paper, which called for NewCo to have "the functional and geographic diversity of the Internet and its users,"{218} ICANN adopted a frankly corporatist structure. This structure, however, was unduly complex -- as a glance at the simplified (!) diagram in Figure 1 (pp. 185-86) demonstrates; programmers may recognize the symptoms of a code base run wild. Moreover, not only was ICANN frankly corporatist,{219} but some "stakeholders" were far more equal than others. The Domain Name Supporting Organization and its parent body, the Names Council, appeared to be the places where issues such as new gTLDs and anti-cybersquatting policies would be thrashed out. ICANN declared that the DNSO would have seven "constituencies,"{220} each of which would elect three delegates to the Names Council, which, in turn, would ultimately elect three ICANN board members who would sit with the initial, self-selected board.{221} As the DNSO constituencies often overlapped, a single firm could simultaneously be a member of up to four constituencies.{222} In [*pg 75] contrast, none of the DNSO constituencies offered voting membership to individual domain name registrants, not to mention ordinary Internet users. Furthermore, ICANN decided that the public's role, the number of directors the public could elect, and the public's influence over directors that it might elect, should be reduced well below the level contemplated in the White Paper.
a. ICANN and the GCCA. Despite the tradition of openness that dominates most Internet standards processes,{223} ICANN was founded in secret. The secrecy led to enormous ill-will and suspicion in the Internet community and to at least two formal inquiries, one by a House Committee and one by the General Accounting Office.{224} The inquiries were motivated, in part, by an understandable suspicion that administration officials might have done more than simply call for NewCo to be created. Any participation by the federal government in ICANN's formation beyond general cheerleading would probably have violated the Government Corporation Control Act (GCCA). However, most of the board members appear to have been recruited either by European Union officials or by Joe Sims, Postel's lawyer and later ICANN's.{225} Although ICANN organizers [*pg 76] briefed U.S. government officials from time to time, and Magaziner himself had a hand in recruiting Esther Dyson, these officials's participation probably did not violate the GCCA.{226} It may be an indictment of the GCCA, but by simply describing what needed to be done rather than doing it itself, the government remained sufficiently at arms' length to satisfy the formal requirements of the law. Only Magaziner's recruitment of Dyson crossed this line, and that alone was probably not enough to taint the entire enterprise.
DoC is not the first agency to seek to use the corporate form or to create a private corporation to achieve desired ends.{227} The Government Corporation Control Act{228} is Congress's most comprehensive modern attempt to define when and how federal officials may create and use private corporations for public purposes. Congress enacted the GCCA in response to a plethora of federally owned and mixed-ownership federal government corporations{229} and attendant inconsistent accounting standards and a general lack of federal control and accountability.{230} Section 9102 of the GCCA prohibits the creation or acquisition of corporations by the executive branch "to act as an agency" without specific legal authorization.{231}
In one of the few cases interpreting section 9102 of the GCCA or discussing when a federal agency may shepherd a state corporation [*pg 77] into being, the Supreme Court in Lebron v. National Railroad Passenger Corp. observed that the GCCA
was evidently intended to restrict the creation of all Government-controlled policy-implementing corporations, and not just some of them. And the companion provision that swept away many of the extant corporations said that no wholly owned government corporation created under state law could continue "as an agency or instrumentality of the United States," § 304(b), 59 Stat. 602. Once again, that was evidently meant to eliminate policy-implementing government ownership of all state corporations, and not just some of them.{232}
The only other reported case to discuss section 9102, Varicon International v. Office of Personnel Management,{233} involves facts that more closely resemble ICANN. The Office of Personnel Management (OPM) decided to privatize the office that conducts background investigations of executive branch applicants and employees for security clearance purposes. It produced a privatization plan that called for an employee-owned company to be created with which OPM would contract to perform the background investigations previously performed by the Investigations Service. As part of the privatization plan, the new company offered employment to all OPM personnel displaced by the privatization plan. OPM then awarded a sole-source contract for information services to this employee-owned company. Plaintiffs, who had previously contracted with OPM for similar work, sought to enjoin operation of the contract.{234}
In the course of denying the application for an injunction on several grounds, the district court noted a number of facts about the U.S. Investigation Services (USIS) that persuaded it to distinguish Lebron: (1) no USIS employees were employed by the government; (2) the government had no control over the USIS board of directors, management, or employees, except as provided for in the contract; (3) the government did not and would not own any USIS stock; (4) the gov- [*pg 78] ernment appointed none of USIS's directors; and (5) the government had no obligation to pay USIS except as provided under the contract in payment for service performed under the contract.{235} The district court therefore concluded that USIS was "a private corporation which was awarded a government contract, and not a corporation which is acting as a federal agency."{236} All these factors, except perhaps the second, apply to ICANN as well. The second factor is debatable, since DoC control over the root gives it extraordinary leverage over ICANN. However, even if we assume OPM was the only possible buyer of USIS's services (an issue the court did not address), there are still differences between the USIS/OPM relationship and the ICANN/DoC relationships: USIS was a contractor performing a service for money; ICANN is not paid by DoC but rather gets income from third parties over whom DoC gave ICANN power.{237} Most of ICANN's contracts are research agreements rather than ordinary procurement agreements, and the "procurement" is for zero dollars. Finally, there is no way that USIS's services to OPM could be described as regulatory.
The nature of ICANN's services to DoC is particularly important, as can be seen from an analogous distinction involving Defense Department Federally Funded Research Development Centers (FFRDCs). The Acting Comptroller General opined in 1992 that agencies could establish FFRDCs in universities and other nonprofits pursuant to existing statutory authority without violating section 9102.{238} Even FFRDCs that received all of their funding from the government did not, therefore, become "a corporation established or acquired to act as an agency."{239} The Comptroller General noted, however, that "agencies are prohibited from awarding FFRDC contracts to perform work of a policy, decisionmaking or managerial nature which is the direct responsibility of agency officials."{240}
On the other hand, even when a corporation provides no policymaking services, an agency may still lack the authority to create it. The General Counsel of the GAO opined in 1998 that the Federal Communications Commission exceeded its authority under 47 U.S.C. [*pg 79] § 254(h) when the FCC directed the incorporation of two Delaware corporations. Section 254(h) authorized the FCC to provide service support benefits to certain schools, libraries, and rural health care providers, but did not specify how the FCC should do this.{241} The FCC appointed the National Exchange Carrier Association (NECA) to administer its programs, then directed it to create "an independently functioning not-for-profit subsidiary" to temporarily administer some programs.{242} The FCC also directed NECA to create "two unaffiliated, not-for-profit corporations to be designated the Schools and Libraries Corporation and the Rural Health Care Corporation. . . . NECA was directed to incorporate the corporations under the laws of Delaware and to take such steps as are necessary . . . to make the corporations independent."{243} These new entities would take up some of the support functions. The certificate of incorporation for the new entities