[AUTHOR] 1

TABLE OF CONTENTS TABLE OF CONTENTS

FOREWORD ...... 4

1
INTRODUCTION ...... 6

1.1
Objectives ...... 6

1.2
Scope ...... 8

1.3
Method ...... 11

1.4
Summary of Findings ...... 14

2
INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) ...... 17

2.1
The Arpanet ...... 17
2.1.1
Host Addresses ...... 22
2.1.2
Multiplexing Numbers ...... 23
2.1.3
Host Names ...... 25
2.1.4
Declarative Specifications ...... 27

2.2
The Internet ...... 28
2.2.1
Internet Protocol (IP) Address ...... 29
2.2.2
Transmission Control Protocol (TCP) Ports ...... 31
2.2.3
Network Numbers ...... 33
2.2.4
Autonomous System Numbers (ASNs) ...... 33
2.2.5
Host Names ...... 35
2.2.6
Domain Name System (DNS) ...... 36
2.2.7
Protocol Parameters ...... 38

3
OPERATIONAL ORGANIZATIONS (1969-2017) ...... 39

3.1
Network Working Group (NWG) (1969-c.1980) ...... 39

3.2
Bolt Beranek and Newman Inc. (BBN) (1969-92) ...... 43

3.3
Stanford Research Institute Network Information Center (SRI and DDN NIC) (1969-91) ..... 45

3.4
Root Server Operators ...... 48

3.5
University of Southern California Information Sciences Institute (USC-ISI) (1976-98) ...... 50

3.6
Network Solutions, Inc. (NSI) and Verisign (1991-2017) ...... 53

3.7
ICANN IANA Department (1999-2017) and Public Technical Identifiers (PTI) (2016-17) ..... 55

The Creation and Administration of Unique Identifiers, 1967-2017 2

TABLE OF CONTENTS 3.8
Regional Internet Registries (RIRs) ...... 59

4
PRE-ICANN POLICY ADVISORY AND COORDINATION ORGANIZATIONS (1975-99) ...... 60

4.1
Arpanet Sponsors Group (1975-83) ...... 60

4.2
Internet Configuration Control Board (ICCB) (1979-84) ...... 61

4.3
Internet Advisory Board (IAB), Internet Activities Board (IAB), Internet Architecture Board (IAB) (1984-2017) ...... 62

4.4
Internet Engineering Task Force (IETF) (1986-2017), Internet Engineering Steering Group (IESG) (1989-2017) ...... 66

5
POLICY SETTING ORGANIZATIONS (1968-2017) ...... 68

5.1
The Defense Advanced Research Projects Agency (DARPA) (1968-98) ...... 69

5.2
Defense Communications Agency (DCA) and Defense Data Network Program Management Office (DDN PMO) (1975-92) ...... 74

5.3
National Science Foundation (1982-98) ...... 76

5.4
Federal Research Internet Coordinating Committee (FRICC) (1987-90), Federal Networking Council (FNC) (1990-97) ...... 81

5.5
U.S. Department of Commerce (DoC) (1997-2016) ...... 83

5.6
Regional Internet Registries (RIRs) (1992-2017) ...... 87

5.7
IANA Functions and the Internet Corporation for Assigned Names and Numbers (ICANN) (1998-2017) ...... 89
5.7.1
IANA Functions Stewardship Transition Agreements ...... 90
5.7.1.1 DOC-ICANN Memorandum of Understanding (MOU), Joint Project Agreement (JPA), and Affirmation of Commitments (AOC) ...... 90
5.7.1.2 USC-ICANN Transition Agreement ...... 93
5.7.1.3 NTIA-NIST-ICANN Cooperative Research and Development Agreement (CRADA) ...... 93
5.7.1.4 DOC-ICANN InterNIC® Agreement ...... 94
5.7.1.5 DOC-ICANN IANA Functions Contracts ...... 94
5.7.2
IANA Functions Stewardship Transition (IANA Stewardship Transition) Process and Implementation Agreements ...... 96

6
ACKNOWLEDGMENTS ...... 100

7
SOURCES ...... 101

The Creation and Administration of Unique Identifiers, 1967-2017 3

FOREWORD FOREWORD

Vinton G. Cerf Stephen D. Crocker VP, Google CEO, Shinkuro, Inc. Former Chairman, ICANN Former Chairman, ICANN

As the Arpanet and Internet evolved, the role and importance of unique identifiers increased markedly. At first, the creation and administration of the necessary identifiers was a small matter and handled as an implicit task within the contracts for the overall network development. Over time, the creation and administration of unique identifiers evolved into a visible and important activity on its own.

The Arpanet project was started in 1968 by the U.S. Advanced Research Projects Agency (ARPA), now called the Defense Advanced Research Projects Agency (DARPA). It aimed at applying packet switching to computer communication. It developed a layered protocol architecture for host-to-host communication, which included a variety of identifiers necessary for referencing hosts on the network and labeling key parameters of the protocols used to support networked applications.

With support from ARPA and experience gained from the Arpanet project, the Internet’s design began in 1973 to be a highly distributed, scalable, and adaptable network of networks. It inherited many of the concepts and institutions emerging from the development of the Arpanet, including the need for identifiers of various kinds. It was concluded that memorable names for the hosts on each network and numeric addresses and identifiers would be needed for uniquely distinguishing the hosts and networks that make up the Internet. The many communication protocols required to implement applications or supporting infrastructure of the Internet also had configuration parameters that needed unique identifiers for reference.

In recognition of the emergent central role of identifiers, the Internet Corporation for Assigned Names and Numbers (ICANN) and Google commissioned this report to document the design, evolution, and management of the Internet’s unique identifiers. It draws upon considerable input from the Internet community as well as in-depth research by the report’s authors, Bradley Fidler and Russ Mundy.

The report offers the first comprehensive documentation and analysis of the evolution and use of unique identifiers in the Internet and how different entities developed, deployed, used, and, above all, managed Internet identifiers. The authors chose a disciplined approach to their work, relying on primary source documentation ranging from the Request for Comment documentation series as well as detailed U.S. Government records from the National Archives and Records Administration (NARA), the Computer History Museum, interviews with primary actors in the development of the Arpanet and Internet, among other sources.

The Creation and Administration of Unique Identifiers, 1967-2017 4

A key observation in this report is that the evolution of the unique identifiers involved the FOREWORD interplay among four distinguishable processes: (1) the technical design of the unique identifiers; (2) the operational administration of the identifiers; (3) the development of the conceptual framework for thinking about policy issues related to the identifiers; (4) formal policy-setting processes and organizations. These four activities are intertwined, but each has its own history, as detailed in Sections 2 through 5.

As the authors point out,

“The interactions between these four sets of entities have changed over time – something that is easiest to illustrate with examples. In some instances, decisions made in one or more organizations have determined the design of a unique identifier. At other times, it is the design and functioning of unique identifiers that imparts requirements upon organizations for how they must be administered. At certain points in Internet history, policy setting organizations have set policy in a top-down manner, while at others, operational organizations developed practices and implemented policy that traveled ‘up’ to the top-level organizations.”

The story of the Internet is notable for the global collaboration it spawned and for the cooperative roles played by government agencies and the private sector in its evolution. Responsibility for the oversight of the Internet project moved among different agencies in the U.S. and elsewhere over time, and new organizations were created as necessary.

As the authors have shown, there is an unbroken chain in oversight authority from the project’s origins in ARPA to the present mix of government and private sector entities that bear different but coordinated responsibilities for the unique identifier space, which is vital to the functioning of the Internet.

The authors have done remarkable work in collecting and presenting the important and lengthy story of the Internet’s structure and organization. It has been our pleasure to support their work, which is a significant contribution to documenting the Internet’s history and evolution.

The Creation and Administration of Unique Identifiers, 1967-2017 5

INTRODUCTION 1
INTRODUCTION

1.1
OBJECTIVES This report documents the forms of authority that have governed the creation and technical administration of unique identifiers for the Arpanet and Internet. To accomplish this, it documents the forms of authority that have governed: i) how the Arpanet and Internet community created unique identifiers in protocol specifications; ii) how they built the social and technical systems needed to administer these identifiers; and iii) the forms of authority through which these systems for technical administration have operated.

Furthermore, this report traces the evolution of the unique identifier administration from its origins in research funded by the united states department of defense, through increasingly civilian and, ultimately, non-governmental and community-driven organizations. This transition was remarkable, both in terms of the transition to community governance, and the backdrop of rapid, and at times, exponential growth of the internet. In explaining the evolution of unique identifiers, this report begins with the arpanet, a computer network that went online in 1969 and, in the late 1970s, began serving as the first internet backbone. Internet Protocol (IP) addresses, domain names, and port numbers are examples of identifiers, which require uniqueness within certain contexts in order for the Internet to function. An important property of Internet protocols is that they promote “interoperability” between systems and software. For instance, programs created by widely differing parties for what may be different purposes still communicate with each other, because they each comply with a suite of universal Internet protocols, and do not need additional prior arrangements for compatibility.

These protocols rely on identifiers, which are important because they provide the unique names, numbers, and protocol parameters that make it possible to identify and communicate with specific entities on the Internet. Names typically refer to the name resources of the Domain Name System (DNS), which are an exception among unique identifiers, because they often carry human-readable semantic value. Numbers normally denote identifiers, such as addresses and port numbers that are machine-readable and are needed for connections between multiple endpoints. Protocol parameters refer to the other managed unique identifiers used by the numerous standardized communication protocols on the Internet, such as the identification of DNS resource record types and the definition of Assigned IP numbers.1

1 On the Arpanet, the values, which were later called parameters, existed in protocol specifications and were managed by the protocol specification itself. They were sometimes called “declarative specifications.” The current use of the term “parameter” – denoting a set of data structures and formats managed by a certain kind of organizational infrastructure – is subsequent to the creation of the Internet. All of this is addressed below.

The Creation and Administration of Unique Identifiers, 1967-2017 6

Different names, numbers, and parameters can possess either global or local uniqueness. Globally INTRODUCTION unique identifiers are the names, numbers, or parameters that are delegated to only one party and must be unique, although it is possible to associate them with multiple endpoints. For example, an IP address used on the global Internet is typically assigned only once at any given time.2 Locally unique identifiers are only unique under the rubric of this global threshold, such as the addresses on a Local Area Network, or the sequence numbers used in a connection between two Transmission Control Protocol (TCP) end point implementations.

Generally, unique identifiers require a certain amount of administration. This administration can be described as forms of assignment and reservation. Assignment is typically the mapping of a specific identifier to a device, human, or organization. For example, a domain name is usually assigned to an organization or an individual. In this case, a block of IP addresses are assigned to an organization, while an individual IP address is assigned to a device interface. Reservation is when an identifier or set of identifiers is allocated for use by a protocol; for example, when certain port numbers are reserved for convenient use by applications.

Both assignment and reservation are multi-step processes that have both technical and social components. For example, software may automatically assign an IP address to a device interface. First, though, it must be assigned to an Internet Service Provider (ISP) by a Regional Internet Registry (RIR), which manages and controls allocated blocks of IP addresses through its relationship with the Internet Assigned Numbers Authority (IANA) function.3

These names, numbers, and parameters are administered because each requires some form of uniqueness. The varying technical characteristics of each identifier – its type, form of uniqueness, and form of assignment or reservation – influences the kind of human-directed administration that is required to ensure their proper operation. This report explains the evolution of this administration and its legal and organizational basis. It provides a framework that identifies the sources of authority behind all identifiers, and its analysis is focused on globally assigned identifiers, such as IP addresses and domain names.

2 For exceptions to this rule see Jon Postel, “INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION,” Request For Comments (University of Southern California Information Sciences Institute and the Defense Advanced Research Projects Agency, September 1981), https://www.rfc-editor.org/info/rfc791. Anycast (RFC 1546) permits the use of multiple endpoints for a single address. 3 The Internet Engineering Task Force reverses the use of “assignment” and “allocation.” See Y. Rekhter and T. Li, “An Architecture for IP Address Allocation with CIDR,” Request For Comments, 1993, https://www.rfc-editor.org/info/rfc1518. There are instances in which IP address assignment occurs under different circumstances, such as an IPv6 PI (Provider-Independent) address. The most general statement of this rule is that an IP address must first be assigned to a single entity by an appropriate authority.

The Creation and Administration of Unique Identifiers, 1967-2017 7

INTRODUCTION 1.2
SCOPE This report traces the administration of the Internet's unique identifiers back to the U.S. Department of Defense Advanced Research Projects Agency’s computer network of the late 1960s. This network, quickly called the Arpanet, was a product of the Advanced Research Projects Agency (ARPA), which is known today as the Defense Advanced Research Projects Agency (DARPA).4 (This report refers to DARPA in general, and ARPA when describing events specific to its original name.) As intermittent Internet experiments gave way to a set of permanent Internet connections between 1976-795, the Arpanet served as the first Internet backbone – and continued as the principal backbone until the U.S. National Science Foundation (NSF) created the NSFNET in 1986.6 The Arpanet was retired in 1990.

The traditions and organizations that evolved to assign names, numbers, and parameters on the Arpanet served as the framework for their assignment on the Internet. In 1988, the Internet Activities Board (IAB) and DARPA first identified the Internet Assigned Numbers Authority (IANA) in the Request for Comments (RFC) document 1083.7 Earlier that year, the term “Internet Assigned Numbers Coordinator” appeared as contact information in two RFCs, identifying Joyce Reynolds at the University of Southern California Information Sciences Institute (USC-ISI) in that role.8

RFC 1083 was the first in a longstanding series (the most recent dating to 2000) of “IAB Official Protocol Standards,” which documented “the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).” Less than two years later, a subsequent Request For Comments (1174), written by Vint Cerf for the Internet Activities Board, declared that “Throughout its entire history, the Internet system

4 Arthur L. Norberg, Judy E. O’Neill, and Kerry J. Freedman, Transforming Computer Technology: Information Processing for the Pentagon, 1962-1986 (Baltimore: Johns Hopkins University Press, 1996). The Advanced Research Projects Agency (ARPA) was renamed the Defense Advanced Research Projects Agency (DARPA) in 1972, reverted to the Advanced Research Projects Agency (ARPA) in 1993, and altered again to the Defense Advanced Research Projects Agency (DARPA) in 1996. This report will refer to the agency by its name at the time in question. (“ARPA Becomes DARPA,” n.d.) 5 Peter T. Kirstein, “University College London ARPANET Project Annual Report, 1 January 1977 - 31 December 1977” (University College London, April 1978), http://www.dtic.mil/docs/citations/ADA135020. 6 D. L. Mills and H. Braun, The NSFNET Backbone Network, SIGCOMM ’87 (ACM, 1988), https://doi.org/10.1145/55482.55502. 7 Internet Activities Board and Defense Advanced Research Projects Agency, “IAB Official Protocol Standards,” Request For Comments, December 1988, https://tools.ietf.org/html/rfc1083. 8 M. A. Sirbu, “Content-Type Header Field for Internet Messages,” 1988, https://www.rfc- editor.org/rfc/pdfrfc/rfc1049.txt.pdf; Stuart Levy and T. Jacobson, “Telnet X. 3 PAD Option,” 1988, https://www.rfc-editor.org/rfc/pdfrfc/rfc1053.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 8

INTRODUCTION has employed a central Internet Assigned Numbers Authority (IANA) for the allocation and assignment of various numeric identifiers needed for the operation of the Internet.”9 Subsequently, the definition of the Internet Assigned Numbers Authority was expanded to include the administration of the DNS, which is also addressed in this report.10

By 1990, the Internet community began incorporating global stakeholders into the administration and governance of the Internet – for example, by paving the way for Regional Internet Registries and removing the distinction between networks with and without official government status.11 This report details the development of the IANA functions in the national context of the United States. In documenting the relationships of authority within the U.S., this report is not claiming U.S. ownership. Instead, it is documenting the path – within the United States – that transitioned the IANA function, undertaken under U.S. Government funded research contracts, into a global activity administered by a multistakeholder organization. This path constituted the beginning of the IANA function’s transition towards global governance. Its findings do not relate to the cultural, political, or economic influence that political or economic entities have over the Internet in general.

Following the first section, this report is organized into four main sections. Section 2 documents the origins of the identifiers themselves, while Sections 3 through 5 document the organizations that work together to administer them. These sections also document, as much as possible, the source of those organizations’ authorities.

Section 2: Unique identifiers (1969-2017) documents the structure and function of key unique identifiers from the Arpanet and the Internet, and identifies the organizations and groups responsible for their creation. It also identifies the authority under which these organizations and groups operate.

Section 3: Operational organizations (1969-2017) analyzes sources of authority, such as the original contract awards to organizations defining their participation in the direct operational administration of unique identifiers. These organizations may also perform additional functions.

9 V. G. Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status,” Request For Comments, 1990, https://www.rfc-editor.org/info/rfc1174. 10 Jonathan Postel and Joe Bannister, “Tera-Node Network Technology (TASK 4) Network Infrastructure Activities (NIA) Final Report,” March 15, 2000, http://www.osti.gov/servlets/purl/802104- AO0fQ0/native/. 11 Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.”

The Creation and Administration of Unique Identifiers, 1967-2017 9

Section 4: Pre-ICANN policy advisory and coordination organizations INTRODUCTION (1975-99) analyzes organizations that prior to the creation of ICANN did not participate in the direct operational administration of unique identifiers or function as the final source of policy authority over identifiers. Instead, these organizations worked with both operational and policy-setting bodies to help develop and implement standards and policy. Several organizations in this category continued to operate after ICANN’s creation, which meant a change in their status. Their post-ICANN roles in the Internet community are documented in Section 5.

Section 5: Policy setting organizations (1968-2017) analyzes the operation and the basis of authority for organizations defined by their position as the highest level of authority in which Arpanet or Internet-specific policy was or is formulated. In some cases, such as with DARPA, the organization is the final authority; in other cases, such as with ICANN, the policy-setting function operates through a bottom-up multistakeholder framework. In other words, the sources of authority for policy-setting organizations change over time, and these changes are explained by this section.

The interactions between these four sets of entities have changed over time – something that is easier to illustrate with examples. In some instances, decisions made in one or more organizations have determined the design of a unique identifier. At other times, it is the design and functioning of unique identifiers that imparts requirements upon organizations for how they must be administered. At certain points in Internet history, policy setting organizations have set policy through a top-down approach, while at other times, operational organizations developed practices and implemented policy through a bottom-up approach.

Each of these sections has its own chronology, which collectively span c. 1967-2017. While each section’s history is unique, it also, when necessary, refers to the broader historical context of other sections, such as major events and organizations. This method was chosen over describing the fifty-year history of unique identifiers in a single chronology, because a single chronology would require weaving together the history of a number of entities and events, which could confuse readers.

It is important to note the difference between the practical or de facto relationships between these organizations and unique identifiers, on the one hand, and legal and programmatic authority, on the other. Prior to ICANN’s creation in 1998, which introduced a formalized bottom-up, multistakeholder process, the organic and pragmatic approaches to solving problems still relied on formal relationships of authority, such as the legal rights and responsibilities of the NSF and DARPA. This report focuses on the formal systems of authority.

The Creation and Administration of Unique Identifiers, 1967-2017 10

It is also important to distinguish between the global Internet which is the focus of this report, INTRODUCTION and any internet. This report relies on a canonical definition of the Internet provided by the Federal Networking Council in 1995:12

The "Internet" refers to the global information system that

(I) is logically linked together by a globally unique address space based on the Internet Protocol (IP) or its subsequent extensions/follow-ons; (II) is able to support communications using the Transmission Control Protocol/Internet Protocol (TCP/IP) suite or its subsequent extensions/follow-ons, and/or other IP- compatible protocols; and (III) provides, uses or makes accessible, either publicly or privately, high level services layered on the communications and related infrastructure described herein."

This definition refers to “the global” system, which requires further explanation. Due to the open nature of Internet protocols and standards, it is possible for anyone to establish an internet, or even an alternative name system, using the Internet protocols. However, this report describes the creation and administration of assigned names, numbers, and parameters for the global Internet, which is defined by its interoperability.

There are many dimensions to the broader history of computer networking: networks that rose to prominence and disappeared, or networks that never progressed beyond plans or testbeds. There are also the many social forces that intersect with unique identifiers, such as their cultural meanings or their social impacts. This report, however, focuses only on the technical administration of unique identifiers on the global, interoperable Internet. This narrow scope makes it possible to draw meaningful conclusions about a fifty-year period. In keeping with this focus, we refer to the Internet (with a capital i) as a proper noun to denote the global and interoperable internetwork of computer networks that use the Internet Protocol. Conversely, an internet (with a lower-case i) is a common noun that denotes any internetworked group of computer networks that use the TCP/IP protocol suite.

1.3
METHOD In sum, the scope of this report is the formal relationships of authority that have governed the technical administration of unique identifiers since their inception. As such, it does not address broader interpretive questions that surround the Internet or its administration. Its method reflects this narrow scope.

12 Federal Networking Council, “Definition of ‘Internet’” (Federal Network Council, October 24, 1995), https://web.archive.org/web/20130303021314/nitrd.gov/fnc/Internet_res.aspx.

The Creation and Administration of Unique Identifiers, 1967-2017 11

Empirically, this report is based as much as possible on primary sources: historical artifacts INTRODUCTION generated at the time of the events under study. These sources include government contracts, technical reports, and protocol specifications. For example, contemporaneous conference proceedings are a useful primary source, in that they are typically short on hindsight, detailed technically, and straightforward in noting their institutional sponsors and priorities.

Individual primary sources are not always sufficient to reveal the meaning of an event, as individuals that generate these sources will often have competing but equally accurate perceptions of the same event and often have a strategic interest in portraying things in a certain way. Nonetheless, when multiple primary sources are combined, it is possible to determine basic social facts.13

When necessary, the report draws on peer-reviewed secondary sources such as commentary and analysis of primary source evidence vetted by academic peer review – when their conclusions represent a historical consensus, are uncontroversial, and not central to this report’s major claims.

Much of the source material referenced in this report is used to document formal relationships of authority between organizations and between organizations and people. This report utilizes the following kinds of primary source evidence to document these relationships:

I.
Legal rights and responsibilities of U.S. Federal entities. In this report these are typically documented in Department of Defense directives, and U.S. law such as The Code of Laws of the United States, and also includes U.S. Executive orders. Together, these document the authority by which policy-setting organizations such as DARPA, the National Science Foundation, and the Department of Commerce operate.

II.
Contracts and orders between policy-setting organizations and the operational organizations to which they would delegate responsibility. Contracts would typically include statements of work, the summary of agreed-upon responsibilities taken on by the operational organizations. Contracts often specify additional rights of the policy-setting organization, such as regarding the goods and services generated in the course of fulfilling the contract, but not specified in it. DARPA has always used external agencies to administer contracts, and as such, many of its contracts are through those agencies. This category includes the variously-titled updates, modifications, and extensions to contracts. Contracts and orders presuppose the existence of appropriate legal rights and responsibilities (note [I] immediately above), which this report nonetheless verifies.

13 Martha C. Howell and Walter Prevenier, From Reliable Sources: An Introduction to Historical Methods (Ithaca, NY: Cornell University Press, 2001).

The Creation and Administration of Unique Identifiers, 1967-2017 12

III.
In the case of DARPA specifically, it relies on ARPA orders for all of its contracting, INTRODUCTION which direct a specific contracting agency to contract with the organization that will execute DARPA’s delegated responsibilities.

IV.
Contract proposals are generated by organizations to describe how they propose to carry out work for policy-setting organizations. Proposal statements of work are often identical to subsequent contracts or present the same work in longer form. Sometimes a contract will incorporate the full proposal into the contract as the definition of work to be carried out under the contract.

V.
Reports (e.g., progress, technical, quarterly, annual, project summary) generated for policy-setting organizations by the organizations to which they delegated authority. These reports are useful because they illustrate specific activities such as software development and services such as management that were carried out in pursuit of goals made explicit in contracts. In this sense, they help us reconstruct the shared understanding of delegated responsibility under which contracts were issued. Reports indicate the existence of contracts and, in the case of DARPA, orders.

VI.
Request for Comments (RFC) documents began in 1969 and remain in use. Today, RFCs are best known as the mechanism through which the Internet Engineering Task Force (IETF) develops and publishes Internet standards. Throughout its history, however, the RFC series has also been used to i) publicize directives by policy-setting organizations, ii) to publish agreements reached between policy-setting organizations and the advisory/coordination organizations, iii) to publish policy decisions of groups and individuals exercising delegated authority, and iv) to distribute identifier specification, management information and policy.

VII.
Conference papers and other technical publications can be used to identify dates, responsibilities, and the specific contract under which responsibilities were executed.

The archival record remains incomplete and is scattered across multiple sites. Nonetheless, this report provides samples of contracts from all kinds of relationships in each distinct period.

This report draws occasionally on oral history interviews, conducted either by historians or peers of the interviewee. Interviewee statements in an oral history interview are important because they reflect the impressions and recollections of the interviewee, sometimes separated from events under consideration by decades. This report’s use of oral history interviews reflects this understanding. It relies on them to connect and contextualize larger claims derived from, where possible, multiple primary sources.

The Creation and Administration of Unique Identifiers, 1967-2017 13

Terminology used in this report refers to concepts and organizations as they were described INTRODUCTION in the period being referenced. As such, it uses “IANA” when referencing historically specific uses of the Internet Assigned Numbers Authority; in contrast, as a general technical and administrative category that existed prior to IANA, this report refers to the administration of assigned names, numbers, and parameters.

As noted above, today’s Defense Advanced Research Projects Agency (DARPA) is referred to as ARPA during the periods when it was called the Advanced Research Projects Agency. The term “governance” is not employed in periods before it was in use by the communities in question.

This report also refers to the Arpanet community and Internet community. We define these communities as the individuals, groups, and organizations that contributed to the development of the Arpanet and Internet, respectively. When describing actions taken by a subset of either community, or by a particular organization, this report uses the more specific definition.

1.4
SUMMARY OF FINDINGS This report concerns the authorities (people, organizations, and institutions) and relations of authority (laws, contracts, and other relationships) that have underpinned the administration of unique identifiers on the Arpanet and Internet. Its findings are as follows:

I.
The history of unique identifiers for the Arpanet and Internet is a testimony to the centrality of identifiers to the success of both of these systems. This centrality is not simply the challenges inherent in specifying unique identifiers, but that effectively specified and administered identifiers have always been necessary for the Arpanet and Internet to function at all. The continuous operation of the Arpanet, its emergent role as the first backbone for the Internet, and the continuous operation of the Internet have relied on the continuous administration of unique identifiers.

II.
This continual operation of the Arpanet and Internet occurred on a foundation of policy-setting organizations that, between 1967 and 2017, exhibited two distinct kinds of authority. During this period, policy-setting authority over the administration of unique identifiers moved from the Department of Defense, to other parts of the U.S. Federal Government, and then the private sector. Federal authority, both civilian and defense, derives from U.S. law, which gains legitimacy from the governed. The shift in policy-setting authority to the private sector reflected a more fundamental change, in that it shifted the constituency. The Internet Corporation for Assigned Names and Numbers (ICANN) emerged in 1998 as a policy-setting entity, with that authority initially delegated by the U.S. Federal Government. Today, authority rests with the Internet community, exercised through ICANN and other organizations, such as the Regional Internet Registries, within the governance ecosystem.

The Creation and Administration of Unique Identifiers, 1967-2017 14

III.
This report refers to two forms of policy authority: 1) the authority to set policy, INTRODUCTION that is, to tell another entity what they can and cannot do, and how they can do it, and 2) the authority to define a policy realm for an entity, that is, to grant an entity the authority to operate in a given scope. In different times and places, different institutions held various combinations of these two kinds of policy authority.

IV.
The Internet’s IANA functions have operated under different policy-setting organizations, and with different combinations of these types of authority, from its origins to the present day. Key to the successful operation of the IANA functions was the transitions between different sources of authority: shifts within the U.S Federal Government, and ultimately to the Internet community.

V.
Prior to the creation of ICANN, these policy-setting organizations delegated authority to two main categories of organization. These organizations include the pre-ICANN policy advisory and coordination organizations, in order to facilitate the development and implementation of policy, as well as operational organizations, for the direct administration of unique identifiers. While the U.S. Federal Government, at times, provided great latitude to these organizations to which it delegated authority, it nonetheless did so through delegation and not relinquishment. During this period, pragmatic and organic methods of policy deliberation and implementation occurred against a backdrop of government authority.

VI.
From ICANN’s inception until the completion of the IANA stewardship transition, the U.S. Government had the policy authority to oversee how ICANN performed the IANA functions, including the ability to direct how ICANN could or could not do that work.

VII.
Changes in the identity or responsibilities of the policy-setting authority have not always meant a parallel change in operational or policy advisory and coordination organizations. New policy-setting organizations would inherit responsibilities and specific contracting mechanisms from their predecessors. When operational or policy advisory and coordination organizations did change, it could often occur during the tenure of a single policy-setting organization. Put another way, the overall organizational system of technical administration enabled changes in one ‘layer’ without disturbing operations in another.

VIII.
Especially in the early history of Arpanet and the Internet , the formal source(s) of policy-setting authority sometimes differed from commonly identified and de facto sources of legitimacy, in other words, the perceived ‘real’ sources of authority in the Internet community. Nonetheless, these sources of legitimacy would consist of individuals or groups that were delegated responsibilities from formal, policy-setting authorities.

The Creation and Administration of Unique Identifiers, 1967-2017 15

IX.
Outside of the legal authority and issued contracts of policy-setting organizations, INTRODUCTION some relationships have, and continue to exhibit degrees of “constructive ambiguity.”14 This concept is used by the Internet community in a largely informal manner, referring to formal agreements and informal relationships alike. It describes strategically ambiguous language used by parties to maintain consensus, despite potential disagreement over the issues covered by the ambiguity. This report does not attempt to identify instances of constructive ambiguity. Instead, in cases of ambiguity, it documents the certainty that does exist.

14 See for example: Bertrand de La Chapelle, “Multistakeholder Governance: Principles and Challenges of an Innovative Political Paradigm,” MIND Multistakeholder Internet Dialogue, no. 2 (September 2011): 14–25, http://en.collaboratory.de/w/Discussion_Paper_Series. For a similar concept used in the social sciences, see Susan Leigh Star, “This Is Not a Boundary Object: Reflections on the Origin of a Concept,” Science, Technology & Human Values 35, no. 5 (2010): 601–17, https://doi.org/10.1177/0162243910377624.

The Creation and Administration of Unique Identifiers, 1967-2017 16

INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) 2
INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017)

This section explains the origins and creation of unique identifiers for the Arpanet and the Internet. By origins, this report identifies the technical need and institutional context in which ARPA initiated funding for this research. By creation, this report describes the design of key identifiers for the Arpanet and Internet. Protocol development was covered, but not specified, by earlier contracts; it emerged as a specific technical need of both the Arpanet and Internet. The Arpanet and Internet subsections are historical explanations, with subheadings to indicate key unique identifiers addressed at each point in the chronology.

This section neither provides a full history of the Arpanet and Internet, nor does it provide a comprehensive picture of the development of all unique identifiers. Instead, in presenting a historical overview, this section calls attention to key moments and illustrates overarching trends. By examining the origins of important identifiers, it illustrates the context in which unique identifiers, in general, were constructed. The organizations that, in turn, administered these unique identifiers are addressed in subsequent sections.

2.1
THE ARPANET Many unique identifiers particular to the Arpanet were phased out of use when the Arpanet was decommissioned between 1989-90; however, there are two reasons why they are relevant to this study. First, many of the design decisions made during the creation of Arpanet’s unique identifiers influenced the subsequent design of unique identifiers for the Internet. Second, the organizations that evolved to administer unique identifiers for the Arpanet either influenced or became the organizations that administered them for the Internet.

While ARPA’s experiments with networking date back to 1963,15 there was no need to actively administer unique identifiers at a significant scale until 1969. The first networking experiment that is tied to the development of the Arpanet was funded by ARPA and carried out between 1966-67. This experiment connected a computer at the Systems Development Corporation and another at the Massachusetts Institute of Technology (MIT) Lincoln Laboratory. It originated from a 1965 proposal by Thomas Marill to DARPA, and was managed by Lawrence (Larry) Roberts, then at Lincoln Laboratory. Marill and Roberts understood the experiment as a feasibility study concerning the technologies needed for resource sharing.16

15 D. Hemmendinger, “Messaging in the Early SDC Time-Sharing System,” IEEE Annals of the History of Computing 36, no. 1 (January 2014): 52–57, https://doi.org/10.1109/MAHC.2013.44. 16 D. Hemmendinger, “Two Early Interactive Computer Network Experiments,” IEEE Annals of the History of Computing PP, no. 99 (2015): 1–1, https://doi.org/10.1109/MAHC.2015.44.

The Creation and Administration of Unique Identifiers, 1967-2017 17

Roberts and Marill published the first preliminary designs of what would become known as INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) the Arpanet in the Proceedings of the Joint Fall Computer Conference in 1966, prior to the completion of their two-node experiment.17 Based on the accumulated ARPA experiences in computer networking to date, they argued for “a cooperative network of time-shared computers,” and “envision[ed] the possibility of the various time-shared computers communicating directly with one another, as well as with their users, to cooperate on the solution of problems.”18 Such a network would be possible by agreeing on a common “message protocol” that could be implemented on heterogeneous machines.19 In this early work, Marill and Roberts were only specifying broad principles and use cases, and not the specific architecture of identifiers.

Roberts began employment at ARPA’s Information Processing Techniques Office (IPTO) in late 1966, was hired specifically to pursue research in computer networking, and remained there until 1973.20 In preparation to pursue a large computer network project, he set to work soliciting input from the IPTO contractor community.21 At the 1967 Association for Computing Machinery’s (ACM) Symposium on Operating System Principles in Gatlinburg, Tennessee, Roberts presented a more detailed paper on the Arpanet’s design, with information dated from June of that year, and incorporating feedback from the IPTO community.22

17 Thomas Marill and Lawrence G. Roberts, Toward a Cooperative Network of Time-Shared Computers, AFIPS ’66 (Fall) (ACM, 1966), https://doi.org/10.1145/1464291.1464336. 18 Ibid., 426. 19 Ibid., 428. 20 R. W. (Robert William) Taylor, Oral history interview with R. W. Taylor, interview by William Aspray, February 28, 1989, Charles Babbage Institute, http://conservancy.umn.edu/handle/11299/107666. 21 Frank Heart et al., “ARPANET Completion Report” (Bolt Beranek and Newman Inc., 1978), Section I, http://walden-family.com/bbn/arpanet-completion-report.pdf. The idea of separating the packet- switching functions into what became the Interface Message Processor (IMP) is credited here to Wes Clark. 22 Lawrence G. Roberts, “Multiple Computer Networks and Intercomputer Communication,” Proceedings of the First ACM Symposium on Operating System Principles, 1967, 3.1–3.6, https://doi.org/10.1145/800001.811680. The 1967 Gatlinburg conference at which Roberts presented his paper on the design of the Arpanet was also attended by representatives from the National Physical Laboratory (NPL) of the United Kingdom. They presented their own plans for a resource sharing computer network, which, like the Arpanet, was a packet-switching network that operated with packet switching nodes (called “interface computers”), with brief references to network addresses. Davies’ plans suffered from a lack of funds, and only began to come online in January 1972, limited to a single node for the duration of the experiment. Roger Scantlebury attended the Gatlinburg meeting on behalf of NPL and convinced Roberts to use higher speed lines than had been planned. M. Campbell-Kelly, “Data Communications at the National Physical Laboratory (1965-1975),” Annals of the History of Computing 9, no. 3 (July 1987): 221–47, https://doi.org/10.1109/MAHC.1987.10023; D. W. Davies et al., A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals, SOSP ’67 (ACM, 1967), https://doi.org/10.1145/800001.811669.

The Creation and Administration of Unique Identifiers, 1967-2017 18

Roberts’ 1967 paper, similar in many ways to the design of the team from the United Kingdom’s INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) National Physical Laboratory, separated the network, which would be responsible for delivering messages from the attached computers. Doing so provided an initial glimpse at how the first framework for the administration of unique identifiers would be structured on the Arpanet.

Roberts outlined how a dedicated computer and an Interface Message Processor (IMP) would handle communication between machines, a device known today as a packet switch. These would be linked together as a network that would provide transparent connectivity between computers. The reason for this design decision was that “a unified, straightforward design of the network can be made and implemented without undue consideration” of attached heterogeneous computers’ idiosyncrasies, and as such, “the entire planning job is substantially simplified.”23 The IMPs would not only be responsible for error checking, retransmission, and verification, but also for routing between each other. At this early stage, Roberts understood that the standard “communication protocol” would specify the “origin” and “destination” of each message that was provided from a computer to an IMP for delivery across the network. Put another way, messages would specify the addresses.24

In his 1967 paper, Roberts noted that the communication protocol for the attached computers “is currently being developed,” and that the principal investigators of the future Arpanet nodes “have agreed to accept a single network protocol so that they may all participate in an experimental network (Roberts 1967, 3).”25 IPTO would delegate authority to two main groups, with very different structures. One, which later called themselves the Network Working Group (NWG), was a mostly self-organizing group that would be responsible for creating the communication protocols for the attached computers, and was largely composed of graduate students from the sites at which ARPA would fund Arpanet nodes. The NWG inherited its name from the first meetings of principal investigators,26 and is detailed below. The other group was whichever contractor selected to build the network itself.

23 Roberts, “Multiple Computer Networks and Intercomputer Communication,” 3. 24 Ibid. 25 Roberts’ design was further hammered out at a meeting from 9-10 October 1967, in the Pentagon, which was attended by “interested ARPA contractors.” There he noted that the network’s communication circuits “should be procured under the auspices of the [Government Services Administration],” and that sites with attached computers should screen access to the network on the grounds that it is “for the exclusive use of ARPA-related activities. ”E. B. Shapiro, “A Study of Computer Network Design Parameters” (Menlo Park, California: Stanford Research Institute, December 1968), Defense Technical Information Center, http://www.dtic.mil/docs/citations/AD0784954. 26 Elmer B. Shapiro, “Untitled Report of ARPA Contractor Meeting Held at the University of Santa Barbara, California, on 22-23 August 1968” (Stanford Research Institute, August 26, 1968).

The Creation and Administration of Unique Identifiers, 1967-2017 19

For this, in the same month, ARPA published the request for quotations (RFQ), “Specifications INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) of Interface Message Processors for the ARPA Computer Network.”27 It sought bids from private sector contractors to build the network.

ARPA’s RFQs further specified the institutional and technical separation first identified by Roberts in 1967.28 Technically, the RFQs set forth the basic specifications of the Arpanet, including, for example, a network that was functionally separate from its attached computers, a description of the IMPs, including their function as packet switches and their distributed and adaptive routing algorithm, the interface between IMPs and attached computers, suggested packet format, error control mechanisms, and resource sharing and network experiment use scenarios.

ARPA also specified the functions of the major non-network contractor organizations that would participate in the management and operation of the network, each of which is documented in this report. The Stanford Research Institute’s (now SRI International) “network library of documentation information” became the Network Information Center (NIC). The University of California Los Angeles’ (UCLA) “[n]etwork studies” became the Network Measurement Center. The network contractor’s “[a]dditional facilities [that] should be provided as required for operation, debugging, and maintenance” of the network, which were later awarded to Bolt Beranek and Newman Inc. (BBN), and executed in part with their Network Control Center.

BBN, of Cambridge Massachusetts, submitted the winning proposal, which laid out in full technical detail their plans for the Arpanet. Crucially, they argued that the distinction between the network and its attached computers ought to be maximized: “we have reached the conclusion that the [Interface Message Processors] and their operation should be initially implemented with the maximum logical separation from Hosts [attached computers] and Host programmers that can possibly be obtained.”29 Not only would this make the technical challenges of the network easier, but it would also provide clear lines of responsibility.

ARPA awarded its Arpanet contract to BBN in December 1968, with work to commence in January 1969.30 In January 1969, BBN released Report 1763, which contained an abridged version of the core technical components of their 1968 proposal; this document,

27 Defense Supply Service, “Specifications of Interface Message Processors for the ARPA Computer Network,” July 29, 1968. 28 Ibid. 29 Bolt Beranek and Newman Inc., “Proposal: Interface Message Processor for the ARPA Computer Network” (Cambridge MA: Bolt Beranek and Newman Inc., September 6, 1968), II–4. 30 Bolt Beranek and Newman Inc., “Program Plan for Interface Message Processors for the ARPA Computer Network” (Cambridge MA, January 1969).

The Creation and Administration of Unique Identifiers, 1967-2017 20

officially under an ARPA contract, served as the first technical specification of the Arpanet INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) network.31 While ARPA’s request for quotations for the Arpanet specified the overall architecture of the network, it was BBN’s proposal and subsequent Report 1763 that contained the first specification of the Arpanet’s unique identifiers. BBN published a more comprehensive and revised version on 1 May 1969 as Report 1822.32 BBN released multiple updates to their 1822 Report, which became known as the 1822 protocol or interface specification.

The Arpanet network, sometimes referred to as the subnetwork or subnet, was BBN’s responsibility, which neither included the host software used to promote interoperability nor the host-specific hardware needed to connect to an IMP. IMPs could receive data from origin hosts and deliver it to destination hosts, but this functionality did not provide a standard way for data to be sent between specific processes or applications on each host. What is more, the network protocols did not provide software that applications could use to communicate over the network. This task would be carried out by the Network Working Group (NWG), a team of mostly graduate students from Arpanet sites, detailed below. NWG members were funded out of ARPA contracts that specified development work on the host protocols for the network.

ARPA specified the division of labor between network and host protocols in the RFQ, namely, that BBN would build the network and an organization of ARPA-funded researchers at the network’s nodes would build the “host software.” In the proposal it accepted from BBN, ARPA approved a specific implementation of the general kind of network it required. The first meeting of representatives of the first four host sites was organized by Elmer Shapiro, who in 1968 provided Roberts an ARPA-funded report on the design parameters of the communication protocols that would be used by the attached computers.33 Representatives adopted the name of the earlier group of principal investigators, and continued meeting intermittently as the NWG.34 The NWG pursued technical directions they thought best for the design of the Arpanet’s host software.

Consistent with ARPA practices, IPTO created a research atmosphere that provided high degrees of autonomy. Indeed, in the ARPA request for quotations, Roberts included both specific design parameters for the Arpanet subnet, and left open-ended the research to be conducted by the community.

31 Bolt Beranek and Newman Inc., “Initial Design for Interface Message Processors for the ARPA Computer Network,” BBN Technical Report (Bolt Beranek and Newman Inc., January 1969). 32 Bolt Beranek and Newman Inc., “Interface Message Processor: Specifications for the Interconnection of a Host and an IMP” (Cambridge MA, May 1969). 33 Shapiro, “A Study of Computer Network Design Parameters.” 34 Shapiro, “Untitled Report of ARPA Contractor Meeting Held at the University of Santa Barbara, California, on 22-23 August 1968.”

The Creation and Administration of Unique Identifiers, 1967-2017 21

ARPA specified a specific form of technology, for instance, the Arpanet subnet, and ensured INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) that it would be open-ended and responsive to the initially unpredictable ways that the network would be used. The autonomy exercised by the NWG was entirely consistent with its role as a group of graduate students who were conducting research under ARPA contracts. All Requests for Comments (RFCs) created by the NWG were published openly among the group, with copies forwarded to Larry Roberts at ARPA.35

BBN’s proposal and Report 1763 contained the first specification of some of the numbers used as Arpanet unique identifiers. As unique identifiers, these numbers were used in addressing: to specify the address of a host computer, as well as further numbers used for multiplexing that allowed multiple simultaneous connections to and from a single address.

2.1.1
HOST ADDRESSES Initially, BBN specified a five-bit “host address” in Report 1763. This format was based on the original design assumption that each IMP would serve a single host – as such, there was no reason to differentiate between the IMP and the host in the address space. Five bits also limited the Arpanet to 32 hosts, well within the planned size of the first contract.

Early on, in response to orders to expand the number of IMPs and hosts beyond the original expectations, BBN expanded the host address itself, and also created a separate IMP address.36 This address was used by the sending host when passing information to its local IMP. The IMP would convert this message into its own format, and forward it to successive IMPs in the network, each using the host address as the final destination. BBN provided this and other information to host sites upon request, services which were covered under “site support” in BBN’s first program plan.37

35 S. D. Crocker, “Documentation Conventions” (RFC Editor, April 1969), https://www.rfc- editor.org/info/rfc0003. 36 Bolt Beranek and Newman Inc., “Initial Design for Interface Message Processors for the ARPA Computer Network,” 12. Based on the IMP code, by December 1971 the host address was six bits, and by September 1973, it was six bits for each IMP, two bits to identify one of up to four hosts connected to each IMP, and one (non- contiguous) bit to identify a fake host. By 1977, the host address number was expanded to 7 bits. D. Walden, “The Arpanet IMP Program: Retrospective and Resurrection,” IEEE Annals of the History of Computing 36, no. 2 (April 2014): 28–39, https://doi.org/10.1109/MAHC.2014.30. 37 Bolt Beranek and Newman Inc., “Program Plan for Interface Message Processors for the ARPA Computer Network.”

The Creation and Administration of Unique Identifiers, 1967-2017 22

INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) 2.1.2
MULTIPLEXING NUMBERS BBN’s specification for host addresses provided a foundation for further protocol development by the NWG. The NWG’s host software included the Host-Host protocol, a general set of rules governing how the host computers would communicate over the Arpanet. The Host-Host Protocol referred, initially, to the protocol specification, with its various machine-specific implementations called the Network Control Program (NCP).38

When implemented, the Host-Host Protocol / NCP would handle basic network functions for the users and their software. For example, one of the major challenges that the Host-Host Protocol needed to address was the ability of host computers to support communication between local and remote processes, such as applications, which were then called “interprocess communication.” While a host address would allow a NCP to send data to a specific host, this address was not enough to send data to a specific process on that machine. Rather than have each program provide this function itself, the NCP would perform this work on behalf of the other software on each host.

The first members of the NWG were graduate students, as well as a few undergraduate students and staff members, at the Arpanet’s first four nodes, with their work funded by ARPA research contracts. The NWG was led by Steve Crocker of University of California Los Angeles (UCLA). Not all meetings and correspondence were documented, and there was no formal membership process.39 NWG contributions can be assessed from RFC authorship, as well as the distribution list included in early RFCs, although neither should be considered exhaustive as RFCs were further distributed and discussed at each site. The NWG’s discussions concerning the design of the Host-Host Protocol began in the summer of 1968.40 Between April and May of 1969, the group published more of what would become the first Host-Host Protocol specification.41 Gerard Deloche, a UCLA graduate student published an early specification of the Host-Host Protocol in August 1969 (Deloche 1969c), based on its implementation on the UCLA host computer.42

38 Eventually, the NCP came to refer to both, sometimes referred to as the Network Control Protocol. 39 The Earliest members of the 1968-69 period included Steve Carr, Vint Cerf, Gerard Deloche, Bill Duval, Steve Crocker, Charles Irby, Jon Postel, Jeff Rulifson, and Ron Stoughton, and it expanded considerably in 1969 and the early 1970s. Distribution lists only included each institution’s point of contact, so they are necessarily incomplete. 40 Stephen Crocker, “Host Software,” Request For Comments (Los Angeles, California: University of California, Los Angeles, 1969), https://www.rfc-editor.org/info/rfc1. 41 Ibid.; B. Duvall, “Host Software,” Request For Comments (Stanford Research Institute, 1969), https://www.rfc-editor.org/info/rfc2; G. Deloche, “Host Software,” 1969, https://www.rfc- editor.org/info/rfc9. 42 G. Deloche, “Implementation of the Host - Host Software Procedures in GORDO,” 1969, https://www.rfc-editor.org/info/rfc11.

The Creation and Administration of Unique Identifiers, 1967-2017 23

This first draft of the Host-Host Protocol relied on “links” to manage interprocess INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) communication. Links were specified by BBN in their Arpanet proposal, and initially in Report 176343 and were part of what would become known as the “Host-IMP Interface,” the protocol specifying the rules of communication between an IMP and its local hosts and which would provide flow control.

In the earliest Host-Host Protocol drafts, the NWG planned to use links in order to manage multiplexing. Links provided the first instance of a discussion over identifier administration; specifically, over global identifier reservation.44

BBN used links as a method for controlling the flow, which meant keeping one message in flight per link. The link numbers available to UCLA in sending to SRI were the same as, and represented a distinct space from, the links available for sending to the node at University of California Santa Barbara (UCSB). The NWG made the first link reservation in April 1969.45

A NWG meeting at the University of Utah on 8 December 1969 led to the decision by the group to use “sockets” as the mechanism to connect processes on different host computers.46 Links would be used by sockets for connections, but the link identifier itself would not be used by the Host-Host Protocol to specify a connection endpoint. In contrast to links, sockets were associated with a host, not a host-host pair, and thus a UCLA-SRI connection and a UCLA- UCSB connection would have to use different sockets on the UCLA end. Sockets were specified in the subsequent draft of the Host-Host Protocol specification,47 and further refined in 1971 by work at Lincoln Laboratory.48 The Host-Host Protocol was formalized, for a time, in January 1972.49 Subsequent to this new draft of the Host-Host Protocol, the NWG decided that sockets would be negotiated automatically between hosts with the Initial Connection Protocol (ICP).50

43 Bolt Beranek and Newman Inc., “Proposal: Interface Message Processor for the ARPA Computer Network”; Bolt Beranek and Newman Inc., “Initial Design for Interface Message Processors for the ARPA Computer Network.” 44 On the Arpanet, “global” refers to “system-wide.” The following discussion may have been the result of a misunderstanding by the NWG as to the ability of host software to actively reserve links. 45 Duvall, “Host Software.” 46 S. D. Crocker, “Network Meeting Epilogue, Etc,” Request For Comments (Los Angeles, California: University of California Los Angeles, 1970), https://www.rfc-editor.org/info/rfc37. 47 S. D. Crocker, “New Host-Host Protocol,” Request For Comments (Los Angeles, California: University of California Los Angeles, 1970), https://www.rfc-editor.org/info/rfc33. 48 J. M. Winett, “Definition of a Socket,” Request For Comments, 1971, https://www.rfc- editor.org/info/rfc147. 49 A. McKenzie and S. Crocker, “Host/Host Protocol for the ARPA Network,” Request For Comments (RFC Editor, April 2012), https://www.rfc-editor.org/info/rfc6529. 50 A. M. McKenzie, “Initial Connection Protocol,” Request For Comments (Cambridge MA: Bolt Beranek and Newman Inc., 1971), https://www.rfc-editor.org/info/rfc93.

The Creation and Administration of Unique Identifiers, 1967-2017 24

By November 1974, BBN deprecated the Link Number and replaced it with the Message INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) Identification field, also known as the Message ID. This change also meant extending the field to 12 bits.51

2.1.3
HOST NAMES By early 1971, staff at the Arpanet nodes were debugging their existing NCP implementations.52 Many sites also had an early version of an application called Telnet, which enabled users at one Arpanet site to establish interactive, command-line connections with remote hosts, as if a local terminal connected them. Telnet is the earliest documented case of the use of host names mapped to addresses.

The exact moment and inspiration for adding names to Telnet does not appear in the documentary record. The early Telnet specification required host numbers to establish connections, and local implementations generated their own naming solutions. An early Telnet implementation, published in August 1971 by James White at the UCSB node, also utilized numeric addresses, listing the host names in the specification alongside with the host addresses.53 In September 1971, at MITRE Corporation, Peggy Karp noted how “in each Telnet implementation, a list of host nmeumonics [sic] is provided for the user to indicate the serving host desired. Currently, each site employs their own special list.”54

51 Jon Postel, “Protocol Information,” Request For Comments (Stanford Research Institute Augmentation Research Center, 1974), https://www.rfc-editor.org/info/rfc661. The name “link” now referred to the higher order eight bits of the Message ID field, as per Jon Postel, “RFC790: Assigned Numbers” (University of Southern California Information Sciences Institute, September 1981). Some documentation notes that for regular (type 0) messages, the Message ID was still referred to as the Link Field. Elizabeth J. Feinler, DDN Protocol Handbook: DARPA Internet Protocols, vol. 2 (DDN Network Information Center, SRI International, 1985).
52 E. Harslem, J. Heafner, and E. Meyer, “Request for Comments on Socket Name Structure,” Request For Comments (RAND Corporation, Massachusetts Institute of Technology, April 1971), https://www.rfc-editor.org/info/rfc0129. 53 J. White, “A User TELNET Description of an Initial Implementation,” Request For Comments (University of California Santa Barbara, 1971), https://www.rfc-editor.org/info/rfc206. 54 P. M. Karp, “Standardization of Host Mnemonics,” Request For Comments (MITRE, 1971), https://www.rfc-editor.org/info/rfc226. This was further evidenced in late October 1971, when Abhay Bhushan at MIT published a booklet of scenarios for using the Arpanet, meant to help acclimatize new users. Its example uses of Telnet showed connections initiated with (MIT’s local) host names. A. Bhushan, “Scenarios for Using ARPANET Computers,” Request For Comments (Massachusetts Institute of Technology, 1971), https://www.rfc- editor.org/info/rfc254.

The Creation and Administration of Unique Identifiers, 1967-2017 25

Other NWG discussions of host names indicated that each site, owing to its own technologies INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) and practices, had their own abbreviations for each site.55 Presumably, these local versions were incorporated into local Telnet implementations; Karp requested that the community come to an agreement on a standard set of host names.

Names were not specified in ARPA’s RFQ but the RFQ did specify the capacity for interactive access. In 1971, however, the NWG developed the first global naming convention in the history of the Internet. This work was not done in accordance with an explicit ARPA directive to develop names, but rather it was part of the contracted duties at Arpanet host sites to develop the Host-Host Protocol and its implementations. As outlined in the ARPA Computer Network RFQs and manifested in the hands-off approach it took to managing the NWG, ARPA did not intend the development of host protocols to be a top-down affair.

In early October 1971, Richard Watson of the Stanford Research Institute proposed that its NIC be responsible for both maintaining the new hostname standard, which was still under deliberation, and assigning these standardized host names to new Arpanet sites. After significant discussion, a consensus emerged that each node would announce its name to the NIC through its technical liaison, and that the NIC would collect, update, and distribute these entries in a host’s list. The NIC published its first list in December.56 In December 1973, L. Peter Deutsch at the Xerox Palo Alto Research Center (Xerox PARC) proposed that the NIC also offer the standardized host names in a standardized, machine-readable list,57 which was made available in March 1974.58 The contents of the file were expanded, for example, to include information about the services provided at each host. This machine-readable list remained the mechanism for hostname administration and distribution on the Arpanet and the early Internet until it was replaced in the mid-1980s by the DNS. The impact of DNS on the Arpanet is addressed below.

55 R. T. Braden, “Host Mnemonics Proposed in RFC 226 (NIC 7625),” Request For Comments (University of Southern California Information Sciences Institute, 1971), https://www.rfc- editor.org/info/rfc239. 56 R. W. Watson, “NIC View of Standard Host Names,” Request For Comments (Stanford Research Institute, 1971), https://www.rfc-editor.org/info/rfc237; R. W. Watson, “What We Hope Is an Official List of Host Names,” Request For Comments (Stanford Research Institute, 1971), https://www.rfc- editor.org/info/rfc289. 57 L. P. Deutsch, “Host Names on-Line,” Request For Comments (Xerox Palo Alto Research Center, 1973), https://www.rfc-editor.org/info/rfc606. 58 M. D. Kudlick and E. J. Feinler, “ASCII Text File of Hostnames,” Request For Comments (Stanford Research Institute, 1974), https://www.rfc-editor.org/info/rfc627.

The Creation and Administration of Unique Identifiers, 1967-2017 26

INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) 2.1.4
DECLARATIVE SPECIFICATIONS On the Arpanet, the values, which were later called parameters, existed in protocol specifications and were managed by the protocol specification itself. The current use of the term “parameter” is subsequent to the creation of the Internet. The 1972 Host-Host Protocol specification used “declarative specifications” to refer to “message format, link assignment, control messages, control commands, opcode assignment, and control command summary,” which is similar to the modern use of “parameter.” As such, the declarative specifications used refer to what could anachronistically be called protocol parameters.

In contrast to the later administration of protocol parameters for the Internet, the ARPA community responsible for administering the unique identifiers on the Arpanet did not identify “parameters” as a specific administrative category. Documentation such as RFCs, however, did show their frequent use of the term “parameter” as a reference or value in protocol design. It was understood, especially as the Arpanet grew, that some form of stewardship was required for administering standardized parameters. The earliest form of parameter management existed in the protocol specifications published in RFCs, and, in the case of the Host-IMP protocol, BBN reports. These RFCs documented parameters on a case by case basis. It was around this practice that the Arpanet, and later the Internet, community gradually developed the administration of protocol parameters.

In November 1974 and June 1975, Jon Postel, then at the Stanford Research Institute’s Augmentation Research Center (SRI ARC), published two RFCs entitled “Protocol Information.”59 Both documents categorized protocols into IMP-IMP, IMP-Host, Host-Host, Host-Frontend, Process-Process, Programs, and National Software Works–an experimental distributed computing platform under development by ARPA. For each protocol, information was structured under the following categories: contact, documents, people, schedule, comments, and recent developments. Postel noted that “for protocols which are official standards the designation ‘[Official]’ will be appended to the name.” Both documents contained Arpanet and Internet protocols, and the latter document also contained assigned link and socket numbers. This system remained in place through the creation of the Internet, eventually emerging as the protocol parameters function. Described later in this section, protocol parameters consume the majority of the labor required to perform the IANA functions.

59 Postel, “Protocol Information”; J. Postel, “Protocol Informations,” 1975, https://www.rfc- editor.org/info/rfc694.

The Creation and Administration of Unique Identifiers, 1967-2017 27

INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) 2.2
THE INTERNET By early 1973, ARPA began funding research on the protocols meant to interconnect computer networks, with contracts to, among others, Stanford University60 and the University College London (UCL) in the United Kingdom.61 ARPA’s interest coincided with the founding of an organization to study internetworking, the International Network Working Group (INWG). INWG was an international forum for computer scientists created to address the challenges of interconnecting heterogeneous computer networks.62 Cerf served as INWG’s first chair and worked closely with, and was supported programmatically by, Robert Kahn, then a program manager at ARPA IPTO. Cerf and Kahn authored the earliest extant documentation of what would eventually become known as the Transmission Control Protocol/Internet Protocol (TCP/IP), following a June 1973 INWG meeting. The document, A Partial Specification of an International Transmission Protocol (Cerf 1973),63 reflected Cerf’s position on the best way to solve the technical challenges addressed by the group. INWG was fertile ground for wide-ranging discussions and debates about internetwork64 protocols and architectures.65

60 Lawrence G. Roberts, “MEMORANDUM FOR THE DIRECTOR, PROGRAM MANAGEMENT. Subject: Initiation of a New Contract with Stanford University for Research in Intelligent Systems and Network Protocol Development,” Records Group 330 January 31, 1973, College Park, National Archives and Records Administration, Maryland, https://www.archives.gov/college-park. 61 Office of Naval Research Contract Administration, “N00014-73-C-0522, University College London,” Records Group 330 July 1, 1973, College Park, National Archives and Records Administration, Maryland, https://www.archives.gov/college-park. 62 Alexander McKenzie, “International Packet Network Working Group (INWG),” Alex McKenzie Collection of Computer Networking Development Records 1972, University of Minnesota, Charles Babbage Institute, Minneapolis and Saint Paul, Minnesota, https://archives.lib.umn.edu/repositories/3/resources/242. 63 Vinton Cerf, “A Partial Specification of an International Transmission Protocol” (Stanford, California: Stanford University, 1973). 64 The earliest documentation does not refer to (the or a) internet, but instead refers to inter-connection of networks and inter-networking. To avoid anachronism, this report will use contemporaneous terminology. Internetworking appears in a 1973 RFC, and “Internet” in 1974. J. Postel, “Assigned Link Numbers,” Request For Comments (MITRE, 1973), https://www.rfc-editor.org/info/rfc604; V. Cerf, Y. Dalal, and C. Sunshine, “Specification of Internet Transmission Control Program,” Request For Comments (Stanford University, December 1974), https://www.rfc-editor.org/info/rfc0675. 65 The individuals, groups, and contributions of INWG’s history are too numerous to mention; rather than highlight only some, INWG records can be accessed at the Charles Babbage Institute. McKenzie, “International Packet Network Working Group (INWG).”

The Creation and Administration of Unique Identifiers, 1967-2017 28

INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) 2.2.1
INTERNET PROTOCOL (IP) ADDRESS The unique identifiers specified in Cerf’s Partial Specification differed from others in what would become version four of TCP and IP which DARPA standardized between the late 1970s and early 1980s. At this stage in the design of Internet protocols, which were termed the “International Transmission Protocol,” they provided end-to-end reliable transmission, relying on gateways to link networks, and encapsulate packets in local formats. Understood simply, the International Transmission Protocol performed the functions that would later be carried out by both TCP and IP. The Partial Specification also provided the first definition of unique identifiers for what would become TCP/IP:

We take the position that only sufficient addressing need[s] be provided to get a message to a particular TCP. The address field must be broken into a subfield for network, and one for TCP identifier.66

As such, this partial International Transmission Protocol specification identified a numerical address that would contain components that would identify both the network and device interface on that network. How network addresses were administered is addressed below.

In late 1973, Cerf and Kahn, then at IPTO, submitted their now-seminal paper, “A Protocol for Packet Network Intercommunication,” which the IEEE Transactions on Communications published in 1974.67 Like the partial specification that preceded it, Cerf and Kahn’s solution to the problem of heterogeneous networks lay in a standardized host protocol. This host protocol would be implemented on all the hosts connected to the participating networks. In their words, “A uniform Internetwork TCP address space, understood by each GATEWAY and TCP, is essential to routing and delivery of Internetwork packets.”68

By mid-1976, DARPA was no longer funding internet research from multiple IPTO programs, but instead through a single Internet program, with Vint Cerf as the program manager.69 In the following year, Cerf oversaw a major change in the design of TCP. Rather than have TCP responsible for the error-free transport and addressing of Internetwork packets, as well as other

66 Cerf, “A Partial Specification of an International Transmission Protocol,” 21–22. 67 Vinton Cerf and Robert Kahn, “A Protocol for Packet Network Intercommunication,” IEEE Transactions on Communications, 1974. 68 Ibid. 69 Robert E. Kahn, Oral history interview with Robert E. Kahn, interview by Judy O’Neill, April 24, 1990, http://conservancy.umn.edu/handle/11299/107387. The first published reference to the Internet Program appeared in 1978. Vinton G. Cerf and P. T. Kirstein, “Issues in Packet-Network Interconnection,” Proceedings of the IEEE 66, no. 11 (November 1978): 1404, https://doi.org/10.1109/PROC.1978.11147.

The Creation and Administration of Unique Identifiers, 1967-2017 29

functions not discussed here, DARPA researchers “split” the protocol.70 TCP would now INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) provide a reliable delivery, among other things, and a new protocol, the Internet Protocol (IP), would provide a uniform addressing system and basic packet delivery, again, among other things for the Internet. Cerf approved the change in a January 1978 meeting of DARPA Internet Program researchers.71 He published the new header formats for both TCP and IP in February,72 and Postel published the first draft of Internet Protocol specification (version 2) later that month.73

The Information Sciences Institute published the fourth version of IP in multiple versions starting in June 1978 and culminating in a final standard in September 1981.74 As is documented below, Jon Postel managed the publication and standardization process, working under DARPA contracts at USC-ISI. The first standardized iteration of IP version 4, typically referred to as IPv4 today, published in January 1980, specified a 32-bit, four octet address format used for the source and destination of each packet, in which the first octet indicated the network and the remaining three octets indicated the device interface.75 As this only permitted 256 networks, the subsequent revised version 4 Internet Protocol introduced three address formats, with a fourth reserved for later use, which were known as address classes A, B, and C. These classes extended the maximum number of networks by allowing a small number of very large networks, a large number of smaller networks, and an even larger number of very small networks: As distinguished by the first two bits of the address, Class A addresses used 8 bits for the network number and 24 bits for the device interface, Class B addresses used 16 and 16, and Class C addresses used 24 and 8. Subsequently Class D was created for multicast, and Class E created and reserved for later use.76

70 There were multiple reasons for this change, proposed largely by members of the DARPA Internet Program, as well as by commentary from researchers in the broader U.S, computer networking community. 71 Jonathan B. Postel, “1.4.2 Meeting Notes - 1 February 1978,” Internet Experiment Note (University of Southern California Information Sciences Institute, February 3, 1978), https://www.rfc-editor.org/ien/. 72 Vint Cerf, “2.3.2.1 A Proposed New Internet Header Format,” Internet Experiment Note (ARPA, February 14, 1978), https://rfc-editor.org/ien/; Vint Cerf, “2.4.2.1 A Proposal For TCP Version 3.1 Header Format,” Internet Experiment Note (ARPA, February 14, 1978), https://rfc-editor.org/ien/. 73 Jonathan B. Postel, “DRAFT INTERNETWORK PROTOCOL SPECIFICATION,” Internet Experiment Note (University of Southern California Information Sciences Institute, February 1978), https://rfc-editor.org/ien/. 74 Postel, “INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION.” 75 Defense Advanced Research Projects Agency, “DOD STANDARD INTERNET PROTOCOL,” Request For Comments, January 1980, https://www.rfc-editor.org/info/rfc760. 76 Postel, “INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION.”

The Creation and Administration of Unique Identifiers, 1967-2017 30

Prior to IPv6, the last major change in IPl addressing and routing occurred in the early 1990s. INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) The IETF standardized Classless Inter-Domain Routing (CIDR),77 a process that began in 1992.78 In this proposal, the IANA, through at the time the NIC, would allocate large79 address blocks to “network service providers,” rather than assigning different sized blocks to organizations directly. Next, these network service providers would, in turn assign portions of their assignment to organizations, based on these organizations’ immediate needs. These re-assigned blocks of IP addresses could, in turn, be further delegated in smaller blocks to yet additional organizations. These delegations occur within what are today called “CIDR blocks” (Classless Inter-Domain Routing)
addresses that share an initial prefix of bits, when represented in binary form. This way, small groups of addresses can be “aggregated” in single routing entries. CIDR was announced in a series of 1993 RFCs,80 and standardized with respect to modifications to Internet routing through the IETF.

2.2.2
TRANSMISSION CONTROL PROTOCOL (TCP) PORTS An IP address specifies the interface that an end device uses to send and receive packets through the Internet. By itself, this address does not allow two devices to multiplex their communications, that is, to have more than one set of its processes communicating with one set of processes on the other end device. Cerf and Kahn’s 1974 paper introduced ports as the mechanism through which implementations of the TCP would identify and differentiate multiple connections between each other, and by which TCPs would link a connection to a process on its system.81 Ports are similar in function to Arpanet sockets, documented above. After the DARPA Internet Program split IP from TCP, they left ports with TCP. Internet project researchers continued to develop TCP from January 1978 until DARPA standardized it in September 1981.82

77 Rekhter and Li, “An Architecture for IP Address Allocation with CIDR”; V. Fuller et al., “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy,” Request For Comments, 1993, https://www.rfc-editor.org/info/rfc1519. 78 Vince Fuller et al., “Supernetting: An Address Assignment and Aggregation Strategy,” 1992, https://www.rfc-editor.org/info/rfc1338. 79 In this early articulation, IP addresses would be distributed in high numbers of the smallest (Class C) blocks, however the proposal also called for the class itself to eventually be deprecated. 80 Robert Hinden, Internet Engineering Steering Group, and Others, “Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR),” 1993, https://www.rfc-editor.org/rfc/ pdfrfc/rfc1517.txt.pdf; Rekhter and Li, “An Architecture for IP Address Allocation with CIDR”; Fuller et al., “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy.” 81 Cerf and Kahn, “A Protocol for Packet Network Intercommunication.” 82 Gerald Dinneen, “Host-to-Host Protocols for Data Communications Networks” (Washington, D.C.: Under Secretary of Defense for Research and Engineering, December 23, 1978); Gerald Dinneen, “Host-to- Host Data Communications Protocols” (Washington, D.C.: Assistant Secretary of Defense, Communications, Command, Control, and Intelligence, April 3, 1980).

The Creation and Administration of Unique Identifiers, 1967-2017 31

This final iteration of TCP version 4 specified ports as 16-bit numerical identifiers.83 INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017)

While port numbers did not require global uniqueness, their identifiers could not be duplicated during communication between two devices, as each would be used to link a connection to a local process. As the mechanism that carries out these extremely local and rapid assignments is specified in the TCP protocol, the mechanism of these assignments is provided as a standard by the organization(s) that administers the TCP standard and its parameters. Developers, in turn, chose to implement these standards for the sake of interoperability and other benefits. The organizations and the methods of administration have shifted since TCP was developed and are documented below.

In specifying ports, Cerf and Kahn faced the same challenge confronted on the Arpanet and the development of sockets, and they used the same solution. The challenge in both cases was that processes, meaning applications on one system would need to have a way of knowing which port they would find the process with which they wanted to communicate. Cerf and Kahn rejected the possibility of integrating with the protocol a centralized system of assigning port numbers to specific processes, for this approach would “violate the premise that interprocess communication should not require centralized control.” Instead, “Provision should be made for a destination process to specify that it is willing to LISTEN to a specific port or ‘any’ port,” much like the use of sockets on the Arpanet.84 TCP implementations could then “listen” at specific port numbers for incoming connections meant for specific local processes. The combination of a port number and an IP address formed a socket. In this way, the original TCP specification created the requirement for the administration of common port numbers.

In Postel’s role at USC/ISI, he began including standard port numbers in his regular “Assigned Numbers” RFCs that he published from 197685 until 1994,86 and publishing with Joyce Reynolds beginning in 1983. In 2002, the Assigned Numbers RFCs were replaced with an online database.87 As is noted below, Postel began working in this capacity for

83 Jon Postel, “TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION,” Request For Comments (University of Southern California Information Sciences Institute and the Defense Advanced Research Projects Agency, September 1981), https://www.rfc-editor.org/info/rfc793. 84 See for example Jonathan B. Postel, “Proposed Standard Socket Numbers,” Request For Comments (University of California Los Angeles, May 30, 1972), https://www.rfc-editor.org/info/rfc349. 85 J. Postel, “Assigned Network Numbers,” Request For Comments (University of Southern California Information Sciences Institute, 1976), https://www.rfc-editor.org/info/rfc717. 86 J. Reynolds and J. Postel, “RFC1700: Assigned Numbers,” Request For Comments (University of Southern California Information Sciences Institute, 1994), https://www.rfc-editor.org/info/rfc1700. 87 J. Reynolds, “Assigned Numbers: RFC 1700 Is Replaced by an On-Line Database,” Request For Comments (University of Southern California Information Sciences Institute, 2001), https://www.rfc- editor.org/info/rfc3232.

The Creation and Administration of Unique Identifiers, 1967-2017 32

the Arpanet project in 1972.88 In 1976, Cerf formalized Postel’s role as an administrator INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) of unique identifiers for the Internet.89

2.2.3
NETWORK NUMBERS The IP specification not only created the IP address, but it also created the network number as a component of that address. Network numbers permit internetwork routing by identifying Internet networks in a single number space. The network number originated with the 1974 specification, in which it is the first 8 bits of the address.90 The standardized IP specification of 1981 provided classful addressing, that used fixed-size blocks of network numbers, which was later superseded by CIDR, as noted above.91

DARPA’s standardization of the network number as part of the IP address meant that network numbers would require administration, the responsibilities for which are documented below. Postel published the first list of assigned network numbers in 1974, just four in all.92 Network numbers remained the single unique identifier for internetwork routing until the introduction of Autonomous Systems (ASes) in 1982. After their introduction both network numbers and Autonomous System Numbers (ASNs) were used for internetwork routing and, thus, they needed to be administered. The need for this administration was an important factor in the transition to the era of the RIRs.93

2.2.4
AUTONOMOUS SYSTEM NUMBERS (ASNs) ASes originated as a result of a transformation in the Internet’s routing architecture, which was planned by DARPA since the late 1970s. This change, which culminated with the creation of ASes, saw an early framing in a proposal by David Clark and Danny Cohen in June 1978.94 Cerf systematized the thinking in his “Catenet Model for Internetworking” in July 1978.95

88 Postel, “Proposed Standard Socket Numbers.” 89 Jonathan B. Postel, “TCP Meeting Notes 14 & 15 July 1977,” Internet Experiment Note (University of Southern California Information Sciences Institute, August 5, 1977), 18, https://rfc-editor.org/ien/. 90 Cerf and Kahn, “A Protocol for Packet Network Intercommunication.” 91 Postel, “INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION,” 7. 92 Postel, “Assigned Network Numbers.” 93 E. Gerich, “Guidelines for Management of IP Address Space,” Request For Comments, 1993, https://www.rfc-editor.org/info/rfc1466; K. Hubbard et al., “Internet Registry IP Allocation Guidelines,” Request For Comments, 1996, https://www.rfc-editor.org/info/rfc2050. 94 David D. Clark and Danny Cohen, “A Proposal for Addressing and Routing in the Internet,” Internet Experiment Note (Massachusetts Institute of Technology, USC/Information Sciences Institute, June 1978), https://rfc-editor.org/ien. 95 Vint Cerf, “The Catenet Model for Internetworking,” Internet Experiment Note (Defense Advanced Research Projects Agency Information Processing Techniques Office: ARPA, July 1978), https://rfc- editor.org/ien.

The Creation and Administration of Unique Identifiers, 1967-2017 33

In 1982 at BBN, Eric Rosen, Robert Hinden, and Alan Sheltzer began introducing gateway INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) protocols in a series of RFCs.96

ASes provided several closely linked benefits. First, the introduction of the Exterior Gateway Protocol (EGP) was partly intended to introduce an “open,” that is, non-proprietary, gateway protocol. Until that time, connected networks utilized BBN’s own Gateway-to-Gateway Protocol (GGP) for their gateways. Note, at the time, routers were still called their original name, “gateway.”97 DARPA pursued the Exterior Gateway Protocol (EGP) because it introduced a distinction between interior gateway protocols (IGPs) and EGPs. The Exterior Gateway Protocol would govern routing with other ASes and would be a standard that any company could deploy in gateways,now, routers.

With a standard external protocol in place, interior protocols, on the other hand, would govern routing within each system, and permit flexibility for the organizations to run their own ASes as they choose. One consequence was that firms beyond BBN would be able to build gateways and have more flexibility in their choice of routing protocols. Another consequence was that the configuration (or misconfiguration) of interior protocols within an AS would not directly impact routing between ASes in the Internet at large. Finally, ASes made Internet routing more scalable.

Today, the Border Gateway Protocol (BGP) enables network operators to greatly simplify the application of policy to Internet routing, i.e., the selection of paths packets are forwarded through, by aggregating multiple disjointed IP prefixes into single ASes. Using CIDR, ASes announce their own prefixes and exchange reachability information with other ASes on this basis. The consequence is that routers can calculate routes based on these aggregations, rather than the impractical task of calculating reachability based on individual networks. Here, ASNs are used to identify the authority that announces a network within its responsibility. This system is designed to operate without reference to international boundaries; autonomous systems would be run by any organization, and its underlying addressing framework (IP) was, furthermore, also independent of national boundaries.

Just as each network required a number to participate in the Internet, so too would ASes. Between 1982 and the creation of the NSFNET backbone in 1986, the Arpanet served as the Internet’s backbone AS.98

96 E. C. Rosen, “Exterior Gateway Protocol (EGP)” (Bolt Beranek and Newman Inc., October 1982), https://www.rfc-editor.org/info/rfc0827; R. M. Hinden and A. Sheltzer, “DARPA Internet Gateway” (RFC Editor, September 1982), https://www.rfc-editor.org/info/rfc0823. 97 Virginia Strazisar and Radia Perlman, “Gateway Routing: An Implementation Specification,” Internet Experiment Note (IEN, April 11, 1978). 98 Rosen, “Exterior Gateway Protocol (EGP)”; J. K. Reynolds and J. Postel, “Internet Numbers,” 1987, https://www.rfc-editor.org/rfc/pdfrfc/rfc997.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 34

By January 1983, the administration of ASNs was underway by Postel at USC-ISI, with INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) numbers 2 through 65,534 available for assignment. The numbers 0, 1, and 65,535 were reserved.99 The Internet Engineering Task Force (IETF) introduced 32-bit ASNs in 2007 in order to deal with the exhaustion of the 16-bit ASN space, numbered 65536-4294967295, with a total ASN range of 0-4294967295.100

The organizational relationships that govern the allocation of ASN blocks is the same as that which governs IP addresses.101 The IANA, NRO, and RIRs work together to coordinate the distribution of ASN blocks. ASNs are assigned in blocks of 1024 numbers, and since 2010, out of the undifferentiated 32-bit number space.102

2.2.5
HOST NAMES The administration of names on the Internet primarily concerns host names. Traditionally, a “host” is a connected device that runs, at a minimum, the Internet Protocol (IP). Since the early Arpanet days, the Arpanet and Internet communities have assigned human-readable names to host computers. This permits users to connect to a host,, through Telnet or a web browser by specifying its name. As both the Arpanet and Internet locate and route data based on numbers, in other words IP addresses, names must always be mapped to a number. These mappings, in turn, must be available to hosts that wish to ‘look up’ a host address by name, and the mappings must also be able to be updated by responsible parties. What is more, names must be structured so that in addition to being human readable, they are also readable by machines.

The Internet’s naming system can be understood in two broad phases. The first was adapted from the Arpanet and relied on a static host names file. The second, the DNS, was developed by DARPA-funded researchers beginning in the late 1970s and remains in use today.

The hostnames system first used for the Internet was the same system that was, by then, in use on the Arpanet, which was detailed above. By the late 1970s, that system was straining under the increasing size of the Arpanet and the nascent Internet that was growing around it.

99 J. Postel and J. Vernon, “RFC820: Assigned Numbers,” Request For Comments, 1982, https://www.rfc-editor.org/info/rfc820. 100 Quaizar Vohra and Enke Chen, “BGP Support for Four-Octet AS Number Space,” Request For Comments, 2007, https://www.rfc-editor.org/rfc/pdfrfc/rfc4893.txt.pdf. 101 Internet Corporation for Assigned Names and Numbers. 2010. “Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries | (Ratified by Executive Committee, on behalf of the ICANN Board in September 2010).” https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en. 102 Internet Assigned Numbers Authority. “Autonomous System (AS) Numbers.” https://www.iana.org/assignments/as-numbers/as-numbers.xhtml.

The Creation and Administration of Unique Identifiers, 1967-2017 35

The host names system underwent a significant update in 1982, to accommodate the soon-to-be INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) deployed domain names.103 Nonetheless, host names remained accessible only from a file that was periodically downloaded from the SRI NIC hostname server. On 27 May 1983, for example, the host file was 645 lines long, and just over 43 kilobytes in size.104 In a gradual process that began in the mid-1980s, the hostname system was replaced with the DNS. During this process both naming systems were maintained.

2.2.6
DOMAIN NAME SYSTEM (DNS) The design of what became the Domain Name System differed in a crucial way from the design of most other name and number identifiers. In the design of IP addresses and their Network Numbers, ASNs, and the Arpanet host file, there was no explicit inclusion of instructions for how these identifiers would be administered. Administrative structure beyond the contracted work at SRI NIC was in general not a priority in ARPA’s design considerations in the 1960s and 1970s. The DNS, to which we now turn, differed in that its architecture was based around an explicit recognition that it would require a distributed administration at scale.

A research effort to replace the Internet host table began in the late 1970s, initiated by DARPA and managed by Jon Postel at USC-ISI. Discussion of how to create a new system for mapping names to IP addresses began in earnest in 1979, with proposals and commentary solicited from multiple DARPA contractors: Stanford University,105 the Stanford Research Institute,106 USC-ISI,107 COMSAT Laboratories,108 MIT,109 and Bolt Beranek and Newman.110 The discussion evolved into the identification of two interlinked requirements: i) provide a scalable and distributed database of host names, and ii) define the domain in the domain name to represent a meaningful region of the Internet.

103 E. J. Feinler et al., “DoD Internet Host Table Specification,” Request For Comments, 1982, https://www.rfc-editor.org/info/rfc810; K. Harrenstien, V. White, and E. J. Feinler, “Hostnames Server,” Request For Comments, 1982, https://www.rfc-editor.org/info/rfc811. 104 Takashi Takizawa, Hosts.txt (Github), accessed September 22, 2018, https://github.com/ttkzw/hosts.txt. 105 M. R. Crispin, “Universal Host Table,” Request For Comments, 1979, https://www.rfc- editor.org/info/rfc752. 106 J. R. Pickens, E. J. Feinler, and J. E. Mathis, “NIC Name Server - a Datagram-Based Information Utility,” Request For Comments, 1979, https://www.rfc-editor.org/info/rfc756. 107 Z. Su and J. Postel, “The Domain Naming Convention for Internet User Applications,” Request For Comments, 1982, https://www.rfc-editor.org/info/rfc819. 108 D. L. Mills, “Internet Name Domains,” Request For Comments, 1981, https://www.rfc- editor.org/info/rfc799. 109 David D. Clark, “Name, Addresses, Ports, and Routes,” Request For Comments (Massachusetts Institute of Technology, 1982), https://www.rfc-editor.org/rfc/pdfrfc/rfc814.txt.pdf. 110 D. P. Deutsch, “Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPANET Message Systems,” Request For Comments, 1979, https://www.rfc-editor.org/info/rfc757.

The Creation and Administration of Unique Identifiers, 1967-2017 36

In August 1982, under contract from DARPA, Zaw-Sing Su of SRI and Jon Postel announced INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) an “Internet naming convention,” the outline of how this new name system would structure its domains.111 This “hierarchical naming convention” provided an outline of a naming authority that would work with a name service. Just as ASes structured networks into administrative regions, the name space too would be structured, although along different administrative boundaries.

Postel and Su’s August 1982 scheme defined the top of the authority structure of domains, what would become known as the Root Zone (or simply “root”), which would delegate authority–and with these, the identities of specific name servers–to subordinate domains. For example, the Root Zone could identify an “arpa” domain, which would in turn have authority to provide names “usc” in that space. Labels in each domain would be unique in that domain and in its ‘parent’ domains, but not across the entire namespace. This system can be understood as sequences of “labels,” separated by dots (“.”), with each label representing a potentially independently administered zone–and certain requirements of uniqueness–within the domain name hierarchy. In October of that year, Su provided a further elaboration of how the name service would function on a technical basis, and how domains would be represented, as what we now routinely call host names: thus the “arpa” domain could denote the name “usc” as “usc.arpa”.112

Su described the purpose in his follow-on to the August 1982 domain authority document, noted above, as “to focus discussion on the subject… it is hoped that a general consensus will emerge leading eventually to the adoption of standards.”113 By November 1983, that consensus was reached, as Postel published “The Domain Names Plan and Schedule:”

Domain style names are being introduced in the Internet to allow a controlled delegation of the authority and responsibility for adding hosts to the system. […] The subdivision will be based on administrative authority or organization boundaries (not necessarily network boundaries). Certain requirements will be placed on organizations wishing to be ‘top level’ domains. […] This plan will be implemented in the ARPA community.114

Postel’s schedule called for a gradual roll-out of the DNS from March through May of 1984.

111 Su and Postel, “The Domain Naming Convention for Internet User Applications.” 112 Z. Su, “Distributed System for Internet Name Service,” Request For Comments, 1982, https://www.rfc-editor.org/info/rfc830. 113 Ibid. 114 J. Postel, “Domain Names Plan and Schedule,” Request For Comments, 1983, https://www.rfc- editor.org/info/rfc881.

The Creation and Administration of Unique Identifiers, 1967-2017 37

At USC-ISI, Paul Mockapetris contributed to the wide-ranging discussions around which INSTANTIATING THE UNIQUE IDENTIFIERS (1969-2017) Su and Postel wrote their first, partial specification. Mockapetris also produced the first generation of authoritative DNS specifications, which were dramatically more complex than the earlier draft. Indeed, the gap between initial concepts and specification was much wider than was typical of the period, and amounted to a reinvention.115 Organizationally, he maintained the structured domain space hierarchy as proposed by Postel and Su noting that the “tree structure is intended to parallel the administrative organization and delegation of authority.” The hierarchy established for the DNS, then, would map to real-world organizations within a real-world hierarchy.

Alongside Mockapetris’ specifications, Postel and Reynolds published a set of requirements for any organization to run a domain.116 The initial schedule had the DNS becoming available for general use in late 1984.117

2.2.7
PROTOCOL PARAMETERS The IANA functions encompass a number of activities with the most visible and widely discussed being the root zone updates.118 Protocol parameters have represented a wide range of content and structure since RFCs were first published. At their core, parameters provide the details that are necessary for Internet protocols to facilitate interoperation between devices. For example, as packets are sent through the Internet, they normally encapsulate data required by multiple protocols, each of which contains multiple fields. The acceptable values for those fields are provided in the protocol registries. In addition to specific acceptable values for specific protocols and fields, there are also registries that provide information that is used throughout the Internet. For example, there are registries that document the allocation of IPv4 and IPv6 address space.

Although RFC 349 is sometimes referred to as the first indication of the parameters function, it is more accurate to view this RFC as the first document to acknowledge the requirement for the central assignment and management of the protocol parameters activity.

115 P. V. Mockapetris, “Domain Names: Concepts and Facilities,” Request For Comments, 1983, https://www.rfc-editor.org/info/rfc882; P. V. Mockapetris, “Domain Names: Implementation Specification,” Request For Comments, 1983, https://www.rfc-editor.org/info/rfc883. 116 Jon Postel and Joyce K. Reynolds, “Domain Requirements,” Request For Comments, 1984, https://www.rfc-editor.org/rfc/pdfrfc/rfc920.txt.pdf. 117 The history of the Domain Name System is also documented in the National Research Council Computer Science Task Board's Signposts in Cyberspace (2005), which also provides a snapshot of its operation in 2005. 118 Reports on the performance of the various IANA functions are available at https://www.iana.org/performance.

The Creation and Administration of Unique Identifiers, 1967-2017 38

Between 1969 when RFCs were first published and 1972 when RFC 349 was published, many OPERATIONAL ORGANIZATIONS (1969-2017) RFCs contained information that would later be considered parameters. As subsequent agreements and contracts were put in place for what are now considered IANA functions, the administration of protocol parameters has always been identified as a required activity.

3
OPERATIONAL ORGANIZATIONS (1969-2017)

Operational organizations are defined by their role in directly administering unique identifiers. They also perform other functions such as participating in policy development with policy- setting organizations. This section documents the relationships of authority that provided the foundation of this direct administration. It proceeds chronologically, although given the organic creation and operation of these organizations, the chronology is not neat, rather it has some overlap of authority and responsibility.

In some cases, these organizations were delegated authority by different organizations over time. For example, BBN and its Network Control Center were contracted first by ARPA, and beginning in 1975, by the Defense Communications Agency (DCA).119 The objective of this section is to document the operational activities of the responsible organizations. The subsections that follow will document the duties of each responsible organization, as well as the contract or other vehicle through which those responsibilities were assigned and maintained.

3.1
NETWORK WORKING GROUP (NWG) (1969-C.1980) The background of the Network Working Group (NWG), as well as its role in specifying Arpanet unique identifiers, is documented in Section 2. In this role, the Group exercised a major influence over the development of the Arpanet—and, through its design influence, the evolution of host protocols and architecture of the Internet as well. This subsection instead addresses the specific role of the NWG in directly administering unique identifiers.

ARPA/IPTO periodically updated its contracts with its contractors, adding to existing Statements of Work the development of host software (such as at the University of California Santa Barbara,120 the third Arpanet node). This work also began to appear in the quarterly quarterly reports submitted by Principal Investigators, such as Leonard Kleinrock at UCLA,121 to ARPA IPTO reporting on the accomplishments of their teams.

119 The Defense Communications Agency (DCA) was reorganized, and renamed the Defense Information Systems Agency (DISA). This report refers to the agency by its name during the period under discussion, which is typically DCA. 120 Lawrence G. Roberts, “Memorandum for the Director, Program Management: Request for Amendment to AO 865 - University of California, Santa Barbara,” Records Group 330 February 10, 1970, College Park, National Archives and Records Administration, Maryland, https://www.archives.gov/college-park. 121 Leonard Kleinrock et al., “Computer Network Research: Advanced Research Projects Agency Semiannual Technical Report” (University of California Los Angeles, June 30, 1971).

The Creation and Administration of Unique Identifiers, 1967-2017 39

While the NWG was indeed mentioned in contracts and reports,122 the formal direction from OPERATIONAL ORGANIZATIONS (1969-2017) ARPA IPTO was by function: the development and operation of host software. The NWG was a strategy for forming a community and organizing work. It was also the creation of the (largely) graduate students of which it consisted. For this reason, ARPA IPTO did not formally define membership in the NWG, instead it provided funds and direction to its institutional contractors to develop and find uses for host software. Indeed, the members of the NWG who made ongoing contributions to the specification, implementation, and administration of unique identifiers—as indicated, for example, in RFC and conference publication authorship and citation—were students or employees (or both) of ARPA IPTO contractors. Early documentation created by the Group noted that “[m]embership is not closed.”123 This is evidenced, for example, in the authorship and institutional affiliation of the first 200 RFCs spanning April 1969 to August 1971.124

Before the Arpanet subnet became operational in late 1969, the Request for Comments (RFC) series of publications, distributed between representatives at Arpanet sites, served as the repository of prospective unique identifier reservations. While not yet in use for the Arpanet (as it was not yet online), certain link numbers, for example, were reserved for use by the Network Control Program.125 In 1971, during a meeting at the University of Illinois (under ARPA contract126), the NWG agreed on a link reservation for use with network measurements,127 and Crocker announced link number assignments through Alex McKenzie at BBN.128 Later that year in August, Postel announced his intention to “collect information on the use of socket numbers for ‘standard’ service programs,” requesting that the community submit information by phone or mail.129 The next year in March 1972, Postel began publishing

122 Ibid., 9. 123 Crocker, “Documentation Conventions.” 124 J. B. North, “ARPA Network Mailing Lists,” 1971, https://www.rfc-editor.org/info/rfc155. 125 Duvall, “Host Software”; V. Cerf, “IMP-IMP and HOST-HOST Control Links,” Request For Comments (University of California Los Angeles, 1969), https://www.rfc-editor.org/info/rfc18. 126 Lawrence G. Roberts, “Incremental Funding for the University of Illinois Center for Advanced Computation (ARPA Order 1899),” Records Group 330 May 8, 1972, College Park, National Archives and Records Administration, Maryland, https://archives.gov/college-park. 127 J. B. Postel and S. D. Crocker, “Link 191,” 1971, https://www.rfc-editor.org/rfc/pdfrfc/rfc104.txt.pdf. 128 A. M. McKenzie, “Link Number Assignments,” Request For Comments, 1971, https://www.rfc- editor.org/info/rfc179. 129 J. Postel, “Sockets in Use,” 1971, https://www.rfc-editor.org/rfc/pdfrfc/rfc204.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 40

the assigned link numbers,130 and continued to collect socket numbers—now suggesting that OPERATIONAL ORGANIZATIONS (1969-2017) the SRI Network Information Center (NIC) help publish the list.131 The work of the NWG was specified in pre-existing ARPA contracts,132 and included in progress reports to ARPA.133

By early 1972, Postel was responsible for most work in tracking and publishing number assignments for links and sockets. In May, Postel proposed that his role be formalized within the Arpanet community:

I propose that there be a czar (me ?) who hands 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.134

Postel did indeed assume that responsibility, publishing “socket number lists” in December 1972 and April 1973 while at UCLA, and the latter with Nancy Neigus of DARPA contractor Bolt Beranek and Newman Inc.135 He published “assigned link numbers” in December 1973, after arriving at the MITRE Corporation, also a DARPA contractor,136 where he worked on a DARPA Network Control Protocol implementation.137 Postel continued in these duties at Keydata Corporation,138 also under a DARPA contract.139 He moved to the Stanford Research

130 J. Postel, “Official Host-Host Protocol Modification: Assigned Link Numbers,” Request For Comments, 1972, https://www.rfc-editor.org/info/rfc317. 131 V. Cerf and J. Postel, “Well Known Socket Numbers,” 1972, https://www.rfc- editor.org/rfc/pdfrfc/rfc322.txt.pdf 132 Thomas E. Cheatham Jr et al., “Proposal to the Advanced Research Projects Agency for a Continuation of Air Force Contract F19628-68-C-0379 Supporting Networking and Graphics Research,” Records Group 330 November 1970, College Park, National Archives and Records Administration, Maryland, https://archives.gov/college-park. 133 Kleinrock et al., “Computer Network Research: Advanced Research Projects Agency Semiannual Technical Report.” 134 Postel, “Proposed Standard Socket Numbers.” 135 Postel, “Assigned Link Numbers”; N. Neigus and J. Postel, “Socket Number List,” 1973, https://www.rfc-editor.org/rfc/pdfrfc/rfc503.txt.pdf. 136 Lawrence G. Roberts, “Request for Amendment to ARPA Order 2344 - Mitre,” Records Group 330 July 1, 1973, College Park, National Archives and Records Administration, Maryland, https://www.archives.gov/college-park. 137 Postel, “Assigned Link Numbers”; Jon Postel, “JBP Jon Postel CV,” Jon Postel Collection n.d., University of Southern California, University of Southern California University Archives, Los Angeles CA, https://libraries.usc.edu/locations/special-collections-department/university-archives. 138 Postel’s duties at Keydata involved work on the ARPA Network Control Program. “JBP Jon Postel CV. 139 Lawrence G. Roberts, “Request for a New ARPA Order, Proposal from Keydata Corporation, 13 Nov 72,” Records Group 330 December 8, 1972, College Park, National Archives and Records Administration, Maryland, https://www.archives.gov/college-park.

The Creation and Administration of Unique Identifiers, 1967-2017 41

Institute (SRI) in 1974, where he worked under a DCA contract to develop a reference OPERATIONAL ORGANIZATIONS (1969-2017) implementation of the Transmission Control Protocol (TCP) for the AUTODIN II network,140 from within the ARPA-funded Augmentation Research Center (ARC).141 While there, he published assigned numbers and, what are now called, parameters for the developing DARPA protocol suites for both the Arpanet and Internet,142 as well as the first publication of network number assignments for the experimental Internet.143 Postel moved to USC-ISI in early 1976,144 where he remained for the rest of his career. After his arrival, Postel worked on USC-ISI’s DARPA contracts,145 and his role in administering Arpanet and Internet unique identifiers grew alongside the Internet.

In November 1977, Postel began publishing a general “assigned numbers” RFC series,146 which included assignments for link numbers, socket numbers, network numbers, and Internet message versions, formats, and types or parameters for the new TCP. In other words, this was a centralization of the variety of assignments that he had previously managed, as the need arose, since at least 1972.

Name management, in the form of the “hosts file,” was covered at the SRI Network Information Center, which is detailed below; and Postel’s new “assigned number” series covered all numerical assignments required by the host protocols and software. These RFCs continued through 1994, published with Joyce Reynolds, Postel’s colleague at USC-ISI; beginning that year, the “Assigned Numbers” RFCs were replaced with an online database.147 Also at USC-ISI and working under DARPA contracts, Bob Braden, whose role is also addressed below, also contributed to the RFC series and its role in the standards process.148 During this time the

140 Jonathan B. Postel, Larry L. Garlick, and Raphael Rom, “Transmission Control Protocol Specification” (Menlo Park, California: Stanford Research Institute Augmentation Research Center, July 15, 1976). 141 Spencer Floyd, “Attention: Mr. Roger Lemke/PMRD Reference: SRI Proposal ISU 74-84 (ARPA Order No. 2542),” SRI ARC/NIC Records December 10, 1974, Computer History Museum, Computer History Museum Collections, Menlo Park, CA, http://www.computerhistory.org/collections/catalog/102706170. 142 Postel, “Protocol Information,” 1974; Postel, “Protocol Informations,” 1975 143 Postel, “Assigned Network Numbers.” This RFC appeared after Postel’s personal CV indicates that he had left MITRE for SRI; this is assumed to be a normal publication delay. “JBP Jon Postel CV.” 144 J. Postel, “Extensible Field Addressing” (USC Information Sciences Institute, 1977), https://www.rfc- editor.org/rfc/pdfrfc/rfc730.txt.pdf 145 Danny Cohen, “Internetting or Beyond NCP,” Internet Experiment Note, 1977, 12, https://www.rfc- editor.org/ien/. 146 Postel and Vernon, “RFC820: Assigned Numbers.” 147 Reynolds, “Assigned Numbers: RFC 1700 Is Replaced by an On-Line Database”; Reynolds and Postel, “RFC1700: Assigned Numbers.” 148 RFC Editor, “30 Years of RFCs,” 1999, https://www.rfc-editor.org/rfc/pdfrfc/rfc2555.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 42

scope of the unique identifiers managed by Postel and Reynolds shifted, in terms of the OPERATIONAL ORGANIZATIONS (1969-2017) names, numbers, and parameters that it covered. These changes are addressed below.

3.2
BOLT BERANEK AND NEWMAN INC. (BBN) (1969-92) Much like the early work of Postel, Crocker, and Cerf at UCLA, BBN’s role in the administration of unique identifiers began as the responsible execution of general duties specified in contracts. In the case of BBN, their execution of delegated responsibilities was documented in the quarterly reports submitted to DARPA.149

As was often the case with the Arpanet and early Internet, some of BBN’s responsibilities evolved organically. This is visible, for example, in the case of networking monitoring and software updates. In BBN’s bid for the ARPA contract, they noted that updates and maintenance of the packet switch software would be done in person at each site, and that “in later versions of the system, more elegant debugging facilities will be provided as they prove useful.”150 In their included program schedule, which was republished in January 1969 as Report 1765,151 they indicated that they would provide “IMP network test and support.” This was included, albeit in a slightly different form, in the subsequent republication of the plan.

In BBN’s proposal, they further noted that “the RFQ was not specific as to what tasks, specifically, might be performed during the three months after installation of the four-node net” and prior to the end of the contract.152 The first contract included the installation and demonstration of a four-node network, and the design of a 19-node network.153 Nonetheless, by the end of the first contract, BBN had begun to create network management techniques and technologies. Their on-site maintenance from the early months evolved from a teletype that printed IMP reports,154 to, in mid-1971, a dedicated host computer that collected and organized

149 BBN’s contracts were not available at the time of this report’s publication. However, their quarterly and final technical reports serve as direct evidence of their responsibilities. 150 Bolt Beranek and Newman Inc., “Proposal: Interface Message Processor for the ARPA Computer Network.” 151 Bolt Beranek and Newman Inc., “Program Plan for Interface Message Processors for the ARPA Computer Network.” 152 Bolt Beranek and Newman Inc., “Proposal: Interface Message Processor for the ARPA Computer Network,” IV 13–15. 153 Defense Supply Service, “Specifications of Interface Message Processors for the ARPA Computer Network,” 37. 154 Alexander McKenzie et al., “The Network Control Center for the ARPA Network,” Proceedings of the First International Conference on Computer Communication, 1972, 185–91.

The Creation and Administration of Unique Identifiers, 1967-2017 43

status reports from the network,155 which underwent significant upgrades for the life of OPERATIONAL ORGANIZATIONS (1969-2017) the Arpanet.156 All of this work was documented in technical reports submitted by BBN to DARPA.157

In the late 1970s158 and early 1980s,159 BBN also administered early Internet monitoring and control centers for DARPA, specifically, for monitoring early gateways as that technology was in development. Although likely dedicated only to monitoring, BBN also ran the NSF’s Network Service Center for the National Science Foundation Network (NSFNET) for several years beginning in the mid-1980s,160 which is documented below.

In addition to their initial specification of unique identifiers, BBN also updated them. In the first quarterly report submitted by BBN following the Arpanet contract, for example, BBN staff noted their changes to the host address, as well as modifications to the link numbers.161 Through the work of Alexander McKenzie in particular, BBN contributed to and published specifications–including what would be later known as protocol parameters–for the Mail Box Protocol,162 File Transfer Protocol (FTP),163 and Telnet.164

155 Alexander McKenzie, “The ARPA Network Control Center,” Fourth Data Communications Symposium, Quebec City, Canada, October 1975, 5–1 – 5–6. 156 Susan L. Bernstein and James G. Herman, “NU: A Network Monitoring, Control, and Management System,” ICC’83- Integrating Communication for World Progress, 1983, 478–83. 157 For example, Bolt Beranek and Newman Inc., “Interface Message Processors for the ARPA Computer Network: Quarterly Technical Report No. 7 1 July 1974 to 30 September 1974” (Bolt Beranek and Newman Inc., October 1974). 158 Bolt Beranek and Newman, Inc., “Combined Quarterly Technical Report No. 18” (Bolt Beranek and Newman Inc., August 1980); David Flood Page, “The CMCC Terminal Process,” Internet Experiment Note (Bolt Beranek and Newman Inc., February 1, 1980), https://rfc-editor.org/ien. 159 J. F. Haverty, “Combined Quarterly Technical Report Number 24. SATNET Development and Operation, Pluribus Satellite IMP Development, Remote Site Maintenance, Internet Operations and Maintenance, Mobile Access Terminal Network, TCP for the HP3000, TCP for VAX-UNIX” (Bolt Beranek and Newman Inc., February 1982), http://www.dtic.mil/dtic/tr/fulltext/u2/a112575.pdf. 160 National Science Foundation, “NSF9224--Network Information Services Manager(s) for NSFNET and NREN” (National Science Foundation, March 19, 1992), https://www.nsf.gov/pubs/stis1992/nsf9224/nsf9224.txt. 161 Bolt Beranek and Newman Inc., “Interface Message Processors for the ARPA Computer Network Quarterly Technical Report No. 1: 2 January 1969 to 31 March 1969” (Bolt Beranek and Newman Inc., April 1969). 162 A. K. Bhushan et al., “Revision of the Mail Box Protocol,” 1971, https://www.rfc- editor.org/rfc/pdfrfc/rfc278.txt.pdf. 163 A. M. McKenzie, “File Transfer Protocol-Meeting Announcement and a New Proposed Document,” 1973, https://www.rfc-editor.org/rfc/pdfrfc/rfc454.txt.pdf. 164 A. M. McKenzie, “Telnet Protocol Specifications,” 1973, https://www.rfc- editor.org/rfc/pdfrfc/rfc495.txt.pdf; A. M. McKenzie, “Modifications to the TELNET Specification,” 1973, https://www.rfc-editor.org/rfc/pdfrfc/rfc562.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 44

BBN also assigned Arpanet network addresses as additional hosts, which were added to the OPERATIONAL ORGANIZATIONS (1969-2017) network. As noted in Section 2, a “network address” was also referred to as a “host address” as it was updated to support multiple hosts per IMP, and a larger number of total hosts. BBN assigned these numerical identifiers sequentially when they organized installation of IMPs and hosts. They published regular network address RFC listings in the early 1970s,165 and included network addresses in Appendix A of its 1822 Report until sometime prior to 1976, before this task was taken over by the SRI Network Information Center, which is documented below.166 This work was not specified in the original ARPA RFQ. Nonetheless, as is detailed below, DARPA was entitled to the product of work, which was unspecified but was required to execute the general responsibilities outlined in its contracts.

3.3
STANFORD RESEARCH INSTITUTE NETWORK INFORMATION CENTER (SRI AND DDN NIC) (1969-91) While early contributions to the Arpanet from the Stanford Research Institute (SRI) were, in the first months, sometimes associated with only SRI or its Augmentation Research Center (ARC), it organized its unique identifier administration through the Network Information Center (NIC).167 ARPA included the existence of a NIC-like service at SRI in its original Arpanet RFQ, referring to a “network library of documentation information”168 that would take advantage of its “oNLine System” (NLS) at the Augmentation Research Center (SRI ARC), a project also funded by ARPA.169

The Stanford Research Institute Network Information Center’s (SRI NIC’s) administration of unique identifiers began with the first standardization of host names on the Arpanet, described in Section 2. It then took on the role of administering the host name system for the Arpanet and early Internet. The SRI NIC also played a major role in administering the early DNS for the Internet, which included the Arpanet until its decommissioning in 1990.170 In 1987, SRI NIC

165 E. Westheimer, “Site Status,” Request For Comments (Bolt Beranek and Newman Inc., 1971), https://www.rfc-editor.org/info/rfc235; E. Westheimer, “Network Host Status,” 1972, https://www.rfc- editor.org/rfc/pdfrfc/rfc376.txt.pdf; A. M. McKenzie, “Address Tables,” 1971, https://www.rfc- editor.org/rfc/pdfrfc/rfc208.txt.pdf. 166 The listing of host addresses in Appendix A of 1822 is mentioned in early-1970s RFCs; it does not exist in a 1976 version of 1822. McKenzie, “Address Tables.” 167 Lawrence G Roberts, Advanced Research Projects Agency, “Stanford Research Institute Contract, ARPA Order 967” July 31, 1970, Records Group 330, National Archives and Records Administration, College Park, Maryland, https://www.archives.gov/college-park. 168 Defense Supply Service, “Specifications of Interface Message Processors for the ARPA Computer Network.” 169 Lawrence G Roberts, Advanced Research Projects Agency, “Stanford Research Institute Contract, ARPA Order 967.” 170 The Stanford Research Institute’s role in administering unique identifiers on the Defense Data Network (DDN) is not addressed in this report, as the DDN did not interoperate fully with the global Internet.

The Creation and Administration of Unique Identifiers, 1967-2017 45

began administering, on behalf of the IANA functions at USC-ISI, a set of unique numeric OPERATIONAL ORGANIZATIONS (1969-2017) identifiers (detailed below), which it continued until 1991.

In early October 1971, Richard Watson of the Stanford Research Institute proposed that its NIC be responsible for both maintaining the new hostname standard, which was still under deliberation, and assigning these standardized host names to new Arpanet sites. After a significant discussion, a consensus emerged that each node would announce its name to the NIC through its network liaison, and that the NIC would collect, update, and distribute these entries in a hosts list; it published its first list in December 1971.171

In December 1973, L. Peter Deutsch at the Xerox Palo Alto Research Center (Xerox PARC) proposed that the NIC also offer the standardized host names in a standardized, machine- readable list.172 The NIC made the machine-readable list available in March 1974.173 The contents of the “host.txt” file were expanded, for example, to include information about the services provided at each host. It remained the mechanism for host name administration and distribution on the Arpanet and the early Internet until it was replaced in the mid-1980s by the DNS. The file was expanded with regard to the information it contained and use of that system continued as the mechanism for host name distribution on the Arpanet and the early Internet until the development and implementation of the DNS in the 1980s.

The specification of the DNS unique identifiers is documented in Section 2. In March 1984, a policy set by the U.S. Defense Communication Agency (DCA) and announced by the NIC required all Internet hosts to operate on the .arpa domain, and in October of that year the first generation of top-level domains were announced by DARPA and the IAB.174 While the old hosts file system was still in place for host name resolution, the adoption of the .arpa domain by all hosts, and the corresponding modification of the hosts file to reflect this, was a major step in the preparation for the shift to DNS. In November 1988, the DCA required that all Internet hosts now be registered under a domain other than .arpa,175 signaling that the

171 Watson, “NIC View of Standard Host Names”; Watson, “What We Hope Is an Official List of Host Names.” 172 Deutsch, “Host Names on-Line.” 173 Kudlick and Feinler, “ASCII Text File of Hostnames.” 174 SRI Network Information Center and Defense Communications Agency Defense Data Network Program Management Office, “Domain Names Transition,” Defense Data Network Management Bulletin, March 16, 1984, https://www.rfc-editor.org/rfc/museum/ddn-news/; Postel, “Domain Names Plan and Schedule”; Postel and Reynolds, “Domain Requirements.” 175 DDN Network Information Center and Defense Communications Agency Defense Data Network Defense Communications System, “Phase II of the MILNET Domain Name Implementation,” Defense Data Network Management Bulletin, November 2, 1988, https://www.rfc-editor.org/rfc/museum/ddn- news/.

The Creation and Administration of Unique Identifiers, 1967-2017 46

DNS was in place.176 Thus, between 1984 and 1988 the DNS was put in place, administered OPERATIONAL ORGANIZATIONS (1969-2017) from the NIC on behalf of the DCA, and with input from DARPA.

What is more, in 1984 the SRI NIC was renamed the Defense Data Network Network Information Center (DDN NIC), referring to its role as the NIC for the new, military portion of the Internet, the Defense Data Network, run by the DCA. Nonetheless, DDN NIC would continue to serve the civilian portion of the Internet until 1991.

In late 1984, the only top-level domains available for the DNS, excluding the temporary .arpa, were .gov, .edu, .com, .mil, .org, and .net. Initially, the NIC acted as registrar for the DNS root zone on behalf of DARPA and the DCA’s Defense Data Network. That is, the NIC performed administration of the top-level DNS zone content using procedures established by DARPA and DCA. This administration was done on behalf of DARPA and DCA in that both funded different parts of NIC operations. The NIC also administered the DNS root name servers and the root server zone files.177 DARPA was the administrative authority of all but .mil, which was administered by the DCA’s Defense Data Network Program Management Office.178

In 1984-85, USC-ISI ran two root servers with Mockapetris’ JEEVES name server software; as JEEVES matured, the DDN NIC hosted another root server in 1985. Root server operations were established by volunteering organizations authorized by Postel,179 which is detailed in Section 3.4 below.

176 .arpa was always intended as a temporary domain to facilitate the transition between the hosts file and the Domain Name System (DNS). It was subsequently renamed as Address and Routing Parameter Area and is used by Internet infrastructure. Ed G. Huston, “Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain (‘arpa’),” 2001, https://www.rfc- editor.org/info/rfc3172. 177 “As registrar of top-level and second-level domains, as well as administrator of the root domain name servers on behalf of DARPA and DDN, the NIC is responsible for maintaining the root server zone files and their binary equivalents.” M. K. Stahl, “Domain Administrators Guide,” 1987, https://www.rfc- editor.org/rfc/pdfrfc/rfc1032.txt.pdf. 178 Postel and Reynolds, “Domain Requirements.” 179 RSSAC, “RSSAC023: History of the Root Server System” (Root Server System Advisory Committee and Internet Corporation for Assigned Names and Numbers, November 4, 2016), https://www.icann.org/en/system/files/files/rssac-023-04nov16-en.pdf. In the same year, the U.S. Army Ballistic Range Laboratory ran its own root server with BIND, for dedicated DDN/MILNET use.

The Creation and Administration of Unique Identifiers, 1967-2017 47

In November 1987, the DDN NIC at SRI assumed responsibility for the assignment of IP OPERATIONAL ORGANIZATIONS (1969-2017) addresses and Autonomous System Numbers (ASNs),180 a responsibility that was transferred directly from the University of Southern California Information Sciences Institute (USC-ISI).181 USC-ISI remained involved in numbers assignment and continued to administer the IANA functions; its role is documented later in Section 3.

In 1990, while continuing this responsibility, the DDN NIC was identified as the “Internet Registry” by the Internet Activities Board (IAB), as part of a broader set of recommendations to the Federal Networking Council (FNC).182 The role of the Internet Registry thus meant the administration of the Domain Name System, as well as the “Internet Numbers,” the Internet Protocol (IP) addresses and ASNs.

In 1991, the NSF completed the transition from the SRI’s DDN NIC to Network Solutions, Inc., a subcontractor of Government Systems Inc. (GSI).183 In 1991, NSF created the InterNIC to administer the civilian Internet. As part of the InterNIC establishment, Network Solutions Inc was awarded the registry services contract for the InterNIC. Section 5 documents these top-level policy changes, and the responsibilities of other operational organizations are documented in this section, below.

3.4
ROOT SERVER OPERATORS Root server operators comprise another operational community. In 2016, the ICANN Root Server System Advisory Committee (RSSAC) in collaboration with the Root Server Operators (RSOs) published RSSAC023, “History of the Root Server System,” to provide the community with a reference on the history and evolution of the root server system.184 It serves as a consensus statement on the topic and is the source of this section.

As noted above, USC-ISI operated the first two root servers. By 1985, they were joined by SRI International and the U.S. Army Ballistics Research Laboratory (BRL), each operating its own server.

180 S. Romano and M. K. Stahl, “Internet Numbers” (Stanford Research Institute, 1987), https://www.rfc-editor.org/info/rfc1020; Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status”; A. Cooper and J. Postel, “The US Domain,” 1993, https://www.rfc-editor.org/rfc/pdfrfc/rfc1386.txt.pdf 181 According to RFC 1174, this was a delegation of IANA.Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.” 182 Ibid. 183 J. Robert Beyster, Michael A. Daniels, and Vinton G. Cerf, Names, Numbers, and Network Solutions: The Monetization of the Internet (CreateSpace Independent Publishing Platform, 2013), https://www.amazon.com/gp/product/1482077353/. 184 RSSAC, “RSSAC023: History of the Root Server System.”

The Creation and Administration of Unique Identifiers, 1967-2017 48

This marked the beginning of the expansion of the root server community. By 1987, there OPERATIONAL ORGANIZATIONS (1969-2017) were six root servers, all located in the United States. In 1989, the Internet community began discussions on locating root servers outside of North America; NORDUnet, a consortium of Northern European research networks, began operating their root server in 1991.185

In 1995, IANA and the then existing RSOs agreed to rename the root servers to the single letter format familiar today, renaming servers A through I. In 1997, moving the root servers to a single domain permitted the use of DNS label compression, thereby allowing J, K, L, and M roots to be added. Both the single letter hostnames and the shared domain name were a workaround for a protocol-based limit on the size of DNS responses which had constrained the number of root servers. The RSSAC authors compiled the criteria used by Postel for establishing new root servers:

Need: The need for root server service. At the time, Europe had one operator. As the Internet developed in Europe, another root server would be useful. There were also no root servers in Asia, so a root server was needed there. The primary tool that Postel used to determine the need was Larry Landweber’s International Connectivity Map.186

Connectivity: The potential operator must have good connectivity both to the internal infrastructure (internal connectivity), and to the world (external connectivity).

Community consensus: The potential operator should demonstrate the widest possible support from the community being served.

Commitment to send and respond to traffic without filtering. The operator must be able to answer every DNS query and send responses back unfiltered.187

In 1997, K-Root moved to the United Kingdom to be managed by London LINX, and M-Root moved to Japan to be managed by the Widely Integrated Distributed Environment (WIDE) at Keio University. J-Root remained with VeriSign, having acquired NSI in 2000, and L-Root was transferred to and managed by ICANN in 1999.

The Root Server Operator community first met at IETF 43, in December 1998, agreeing to a basic set of principles:

• Operate reliably, for the common good of the Internet. • Recognize IANA as the source of the root data.

185 By 1990, seven root servers were operational, now including Rensselaer Polytechnic Institute (RPI, a part of New York State Education and Research Network, or NYSERNET), and the University of Maryland, which could service NSFNET, ARPANET, MILNET, and SURANET. 186 Landweber’s International Connectivity Map is documented in RSSAC, “RSSAC023: History of the Root Server System.” 187 Ibid.

The Creation and Administration of Unique Identifiers, 1967-2017 49

• Invest sufficiently to ensure responsible operation. OPERATIONAL ORGANIZATIONS (1969-2017) • Facilitate the transition, when needed and with proper notice. • Recognize the other root server operators.188

The RSO community continues to meet at IETF and ICANN meetings.

3.5
UNIVERSITY OF SOUTHERN CALIFORNIA INFORMATION SCIENCES INSTITUTE (USC-ISI) (1976-98) Keith Uncapher founded the Information Science Institute (USC-ISI) in 1972 within the USC School of Engineering, and USC-ISI joined the Arpanet as its own node later in the same year.189 Postel arrived at USC-ISI from the Stanford Research Institute in March 1976190 and published his first RFC from USC-ISI in May 1977.191 As noted above, Cerf made Postel’s function official during an Internet Program meeting later in 1977.192 While Postel’s role, which was soon known as the IANA functions, was central to the operation of the Internet (and Arpanet), his responsibilities were always delegated by one or more policy-setting organizations, which are documented below.

At USC-ISI, Postel continued to publish the Assigned Numbers RFC, which reflected up-to-date information (see “Assigned Numbers” RFCs). In his role he also published official protocol standards,193 a task he began with colleagues at UCLA.194 Often with Joyce Reynolds, he also published official protocol information with details such as its official specification and dependencies,195 which grew to include an explanation of the standards process; he began this work in 1974 at the Stanford Research Institute.196 These publications were made available in different ways depending on the period, ranging from the early, physical distribution of RFCs to the electronic distribution of the 1970s and thereafter.

188 Ibid. 189 J. B. North, “Official Site Idents for Organizations in the ARPA Network,” 1972, https://www.rfc- editor.org/info/rfc384. 190 Postel, “JBP Jon Postel CV.” 191 Postel, “Extensible Field Addressing. RFC 690 which, unlike his preceding or subsequent RFCs identify him with USC-ISI, may be in error. 192 Postel, “TCP Meeting Notes 14 & 15 July 1977.” 193 J. Postel, “RFC739 Assigned Numbers,” Request For Comments, 1977, https://www.rfc- editor.org/info/rfc739. 194 S. D. Crocker et al., “Official Protocol Proffering,” 1970, https://www.rfc-editor.org/info/rfc54. 195 J. Postel and J. K. Reynolds, “RFC880: Official Protocols,” 1983, https://www.rfc- editor.org/info/rfc880. 196 Postel, “Protocol Information.”

The Creation and Administration of Unique Identifiers, 1967-2017 50

At USC-ISI, Postel and, from 1983, Joyce Reynolds were also the main points of contact OPERATIONAL ORGANIZATIONS (1969-2017) through which others could provide updated protocol information or inquire about assigned numbers or standards. From Postel’s 1977 arrival at USC-ISI until 1981, the published197 assigned numbers included the link and socket numbers first published from UCLA, as well as the network numbers published once before from MITRE. In 1977, USC-ISI saw the first publication of assigned numbers from the DARPA Internet Program. This combination–of Arpanet links and sockets with additional Internet network and protocol numbers–continued until 1981.

Between 1983-84 the scope of USC-ISI’s assigned numbers expanded significantly,198 now including parameters by name, in addition to numbers. These included Arpanet logical addresses, IEEE 802 numbers, Address Resolution Protocol (ARP) parameters, Telnet options, protocol and service names.199 Some of these parameters reflected new technologies for an expanding Internet. Autonomous Systems (ASes) had been conceived since the late 1970s by DARPA200 and were announced in 1982.201 ARP was important for the interconnection of Ethernet Local Area Networks (LANs) with IP networks. The documentation of parameters performed by Postel and Reynolds also included recording the parameters of long-standing protocols that were now being offered in this systematized form, such as options for the Telnet protocol, as well as name resources, such as machine, system, and protocol and service names. Alongside this expansion of the IANA function was a clarification, from 1982, that number allocation is “subject to the agreement between DARPA/IPTO and DDN/PMO about number allocation,”202 an arrangement documented in Section 5.

Name identifiers were also administered in part through USC-ISI. The DNS was developed at USC-ISI, not only the formal specification, but also in terms of the underlying research program that decided on the overall architecture of the system (see Section 2).

197 This report uses assigned number publications in RFCs as a proxy for the numbers administered by the IANA Function.
198 Joyce Reynolds and Jon Postel, “RFC870: Assigned Numbers,” 1983, https://www.rfc- editor.org/info/rfc870; J. K. Reynolds and J. Postel, “RFC900: Assigned Numbers,” 1984, https://www.rfc-editor.org/rfc/pdfrfc/rfc900.txt.pdf. 199 Reynolds and Postel, “RFC900: Assigned Numbers.” 200 Cerf, “The Catenet Model for Internetworking.” 201 Rosen, “Exterior Gateway Protocol (EGP).” 202 J. Postel and J. Vernon, “RFC820: Assigned Numbers,” Request For Comments, 1982, https://www.rfc-editor.org/info/rfc820.

The Creation and Administration of Unique Identifiers, 1967-2017 51

The CLASS parameter of the DNS was added to the Assigned Numbers list in 1985.203 USC-ISI OPERATIONAL ORGANIZATIONS (1969-2017) also implemented the first two test root servers in 1985, and with some root server shuffling throughout the years, ran L-Root and M-Root in 1997.204

In May 1987, as a result of Defense Department policy, the administration of network numbers and ASNs moved from USC-ISI to the SRI NIC. This change also marked the beginning of the current form of protocol parameters. However, between 1987 and 1994, the scope of the assigned numbers administered by the IANA functions more than doubled in the total number of entries and included parameters from the IP, TCP, Internet Control Message Protocol (ICMP), Simple Mail Transfer Protocol (SMTP), and Multipurpose Internet Mail Extension (MIME). What is more, the final Assigned Numbers publication from USC-ISI205 included lists of the individuals responsible for the administration of each number or parameter. In 1994, the Assigned Number publications were replaced by the iana.org web page.206 In early 1999, the iana.org website provided a list referred to varyingly as “protocol numbers and assignment” and “unique parameters and protocol values.”207

The introduction of parameters to the Assigned Numbers lists reflects a move within the IANA functions. Since the first RFC, published by Stephen Crocker at UCLA in 1969, protocol standards have included their parameters. Beginning in 1974 from the Stanford Research Institute, Postel began publishing summaries of all the official protocols, with information on their official specification as well as the key people involved. Postel appeared to have prepared for this a year earlier, when he requested that all protocol drafts be submitted to the Stanford Research Institute’s Network Information Center.208 Publications followed in 1975,209 a range of individual standard protocols, such as IP and TCP, between 1979-81, especially, and more protocol summaries between

203 Reynolds and Postel, “RFC900: Assigned Numbers.” USC-ISI also began to publish machine and system names from the host file in 1984. (Reynolds and Postel 1984/RFC 900). 204 RSSAC, “RSSAC023: History of the Root Server System.” 205 RSSAC, “RSSAC023: History of the Root Server System.” 206 Ibid, 207 Internet Assigned Numbers Authority, “Wayback Machine Archive: ‘IANA Matrix for Protocol Parameter Assignment,/Registration Procedures’” iana Internet Assigned Numbers Authority, February 18, 1999, https://web.archive.org/web/20050219042820/http://www.iana.org:80/numbers.html. 208 Postel, “Assigned Link Numbers.” 209 Postel, “Protocol Informations.”

The Creation and Administration of Unique Identifiers, 1967-2017 52

1983-87.210 From 1983, Joyce Reynolds, also at USC-ISI, co-authored these publications. OPERATIONAL ORGANIZATIONS (1969-2017)

USC-ISI ceased protocol summary publications in 1987, the year that specific protocol parameters, and the responsible individuals, increasingly appeared in the Assigned Numbers publication. In other words, protocol parameters were always a part of identifier administration since the first years of the Arpanet, and in the 1980s they were systematized alongside numbers as a function of what was by 1988 called the Internet Assigned Numbers Authority (IANA).

3.6
NETWORK SOLUTIONS, INC. (NSI) AND VERISIGN (1991-2017) Network Solutions, Inc. (NSI) operated the registration services function of InterNIC from October 1991, when it won a competition with SRI for this IANA function, until September 1998, when most, but not all, of its functions were transferred to the Internet Corporation for Assigned Names and Numbers (ICANN).211 Originally, NSI operated name and number assignments as a subcontractor of Government Systems, Inc (GSI) for the Defense Data Network; in 1992 it won the name and number component of a larger set of contracts from the NSF that also included directory and database services and information services for the civilian Internet. NSI’s contract saw it providing domain name registration, domain name server registration, network number assignment, and ASNs assignment.212 It could also create and delegate registries for specified domains.

The NSF specified that NSI would provide its services “in accordance with the provisions of RFC 1174,” including specifically:

[T]he Internet system has employed a central Internal [sic] Assigned Numbers Authority (IANA) for the allocation and assignment of various numeric identifiers needed for the operation of the Internet. The IANA function is currently performed by the University of Southern California's Information Sciences Institute. The IANA has the discretionary

210 J. Postel, “RFC840: Official Protocols,” Request For Comments, n.d., https://www.rfc- editor.org/info/rfc840; Postel and Reynolds, “RFC880: Official Protocols”; J. K. Reynolds and J. Postel, “RFC901: Official ARPA-Internet Protocols,” Request For Comments, 1986, https://www.rfc- editor.org/info/rfc901; J. K. Reynolds and J. Postel, “RFC944: Official ARPA-Internet Protocols,” Request For Comments, 1986, https://www.rfc-editor.org/info/rfc944; Joyce K. Reynolds and J. Postel, “RFC1011: Official Internet Protocols,” 1987, https://www.rfc-editor.org/info/rfc1011 211 Services provided to civilian Internet referred to as the “Internet Registration Service.” S. Williamson, “Transition and Modernization of the Internet Registration Service,” Transition Metal Chemistry, 1993, https://www.rfc-editor.org/info/rfc1400. 212 National Science Foundation and Network Solutions Inc., “Network Information Services Manager(s) for NSFNET and the NREN: INTERNIC Registration Services,” January 1, 1993, https://archive.icann.org/en/nsi/coopagmt-01jan93.htm.

The Creation and Administration of Unique Identifiers, 1967-2017 53

authority to delegate portions of this responsibility and, with respect to numeric OPERATIONAL ORGANIZATIONS (1969-2017) network and autonomous system identifiers, has lodged this responsibility with an Internet Registry (IR).213

By including RFC 1174214 in the NSI contract, the NSF was acting on two recommendations by the Internet Activities Board (IAB) to the Federal Networking Council (FNC), as documented in Section 4. First, an Internet registry should continue to provide centralized administration of IP addresses and ASNs, and that the registry would in the future accomplish this by delegating assignments to other organizations, which would soon be known as Regional Internet Registries, or RIRs. Second, IP addresses, ASNs, domain names, and other identifiers should be registered without reference to their “connected” status, meaning their relationship to a U.S. Government entity).215 This was significant, as it both prepared InterNIC and the Internet community for the development of RIRs, and because it directed InterNIC to provide name and number identifier services without regard to registering entities’ relationships with the U.S. Government.

The relationship between InterNIC and IANA was further explained by Postel in 1994:

The Internet Assigned Numbers Authority (IANA) is the overall authority for the IP Addresses, the Domain Names, and many other parameters, used in the Internet. The day-to-day responsibility for the assignment of IP Addresses, Autonomous System Numbers, and most top and second level Domain Names are handled by the Internet Registry (IR) and regional registries.216

Thus, while InterNIC provided the same services that from 1987-91 were provided to the civilian Internet by the SRI NIC, the IANA functions at USC-ISI would exercise oversight over InterNIC, as the latest Internet Registry. The contract also noted that “NSF will contact and negotiate with Federal agencies and other national and International members of the Internet community to further the efforts of this project.”217

Network Solutions, Inc. entered into a cooperative agreement218 with the NSF in 1992 to provide the registration services formerly conducted by the SRI NIC. VeriSign219 acquired

213 Ibid. 214 Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.” 215 Vinton Cerf, “Internet Activities Board,” 1160, 1990, https://www.rfc-editor.org/info/rfc1160. 216 J. Postel, “Domain Name System Structure and Delegation,” Request For Comments, 1994, https://www.rfc-editor.org/info/rfc1591. 217National Science Foundation and Network Solutions Inc., “Network Information Services Manager(s) for NSFNET and the NREN: INTERNIC Registration Services.” 218 Cooperative Agreement NCR 92-18742 219 Verisign was capitalized as VeriSign during its acquisition of NSI. After divesting from its certificate business, a trademark sale returned its name to Verisign.

The Creation and Administration of Unique Identifiers, 1967-2017 54

Network Solutions, Inc. in 2000, assuming its responsibilities and its relationship with OPERATIONAL ORGANIZATIONS (1969-2017) the U.S. Department of Commerce (DOC), which is documented in Section 5 below. NSI began its work for DCA and NSF as an independent company; in 1995 it was acquired by the Science Applications International Corp (SAIC), and in 2000 it was acquired by VeriSign.220 As part of the creation of ICANN, in October 1998 the DOC modified the Cooperative Agreement, “under which NSI agreed to implement a shared registration system in which competitive registrars would enter registrations into the .com, .net, and .org registry on an equitable basis.”221

3.7
ICANN IANA DEPARTMENT (1999-2017) AND PUBLIC TECHNICAL IDENTIFIERS (PTI) (2016-17) ICANN was created, in large part, to perform the IANA functions for the Internet, with the IANA functions core to the organization. To accomplish this task, its creation included the creation of a number of Supporting Organizations and Advisory Committees.222 The IANA department of ICANN was put in place to ensure that specific staff were tasked with performing the IANA functions.

The U.S. DOC, documented in Section 5 below, heavily influenced the transition of operational responsibility for the administration of the IANA functions to ICANN. The USC/ICANN Transition Agreement defined the details of the transition.223 This USC/ICANN agreement provided the details and responsibilities of each party for performing the IANA functions and for the transfer from USC to ICANN in 1999.

In addition to the USC/ICANN agreement, ICANN established a Memorandum of Understanding (MOU) with the Address Supporting Organization (ASO) in 1999.224 Formally, the ASO is the supporting organization in the ICANN structure that provides the formal representation for the RIRs and the group that advises the ICANN Board

220 Beyster, Daniels, and Cerf, Names, Numbers, and Network Solutions: The Monetization of the Internet. 221 United States Department of Commerce, “Amendment 19 to Cooperative Agreement # NCR 92- 18742 Between NSI and U.S. Government,” November 10, 1999, https://archive.icann.org/en/nsi/coopagmt-amend19-04nov99.htm. 222 See “Community,” Internet Corporation for Assigned Names and Numbers, accessed September 27, 2018, https://www.icann.org/community. 223 University of Southern California and Internet Corporation for Assigned Names and Numbers, “USC/ICANN Transition Agreement,” December 1999, https://www.icann.org/resources/unthemed- pages/usc-icann-transition-2012-02-25-en. 224 The Address Supporting Organization (ASO ICANN), “ASO Memorandum of Understanding,” 1999, https://aso.icann.org/documents/historical-documents/memorandum-of-understanding-1999/.

The Creation and Administration of Unique Identifiers, 1967-2017 55

with respect to policy issues relating to the operation, assignment, and management OPERATIONAL ORGANIZATIONS (1969-2017) of Internet addresses. By the terms of a MOU between the ASO and Number Resource Organization (NRO),225 the NRO acts as the ASO, while the ASO Address Council, which is responsible for undertaking the specified role in global address policy definition, is made up of the NRO Number Council.226

In March 2000, the IETF/IAB and ICANN signed a MOU concerning the technical work of the IANA requirement from the IETF/IAB perspective.227 Under this agreement, the organizations have a Service Level Agreement (SLA) that is negotiated annually to incorporate any necessary modifications to responsibilities.

In addition to agreements with various community actors, such as USC and the IETF, in February 2000 ICANN signed a no-cost contract with the National Telecommunications and Information Administration (NTIA) for the performance of the IANA functions, called the “Contract Between ICANN and the United States Government for Performance of the IANA functions.”228 The contract included the USC/ICANN Transition Agreement and the ICANN quotation.229 There were several subsequent contracts awarded to ICANN by NTIA, including the final contract that was in effect from October 2012 until September 30, 2016 when the IANA stewardship transition was completed.

The general requirements for the functions of the IANA department were described in the various contracts and agreements identified in this section. When the NTIA requested development of a plan for the transition of IANA stewardship functions,230

225 Established in 2003, the Number Resource Organization (NRO) is the coordinating body for Regional Internet Registries. 226 Number Resource Organization et al., “ASO Memorandum of Understanding,” ICANN Address Supporting Organization, October 21, 2004, https://aso.icann.org/about-the-aso/aso-memorandum-of- understanding/. 227 Internet Engineering Task Force and Internet Corporation for Assigned Names and Numbers, “IETF- ICANN Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority,” March 1, 2000, https://www.ntia.doc.gov/files/ntia/publications/ianacontract_081406.pdf. 228 Department of Commerce and Internet Corporation for Assigned Names and Numbers, “Contract Between ICANN and the United States Government for Performance of the IANA Function,” August 2006, https://www.ntia.doc.gov/files/ntia/publications/ianacontract_081406.pdf. 229 Internet Corporation for Assigned Names and Numbers, “Response to Request for Quotation Number 40SBNT067020,” February 2000, https://archive.icann.org/en/general/iana-proposal-02feb00.htm. 230 Office of Public Affairs, “NTIA Announces Intent to Transition Key Internet Domain Name Functions,” National Telecommunications and Information Administration Newsroom, March 14, 2014, https://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name- functions.

The Creation and Administration of Unique Identifiers, 1967-2017 56

ICANN established the IANA Stewardship Transition Coordination Group (ICG) to coordinate OPERATIONAL ORGANIZATIONS (1969-2017) the preparation of the response to NTIA. The ICG requested that the names, numbers, and protocol parameters communities each prepare a response through their respective community processes. After receipt of each response, the ICG analysed each to ensure that they were complete as well as to ensure that each proposal met the NTIA established requirements.

Additionally, the ICG analyzed the responses collectively to ensure that the plans developed by the respective communities did not contain inconsistent or conflicting solutions. Although the ICG was responsible to see that inconsistencies and conflicts between proposals were resolved, each respective community followed their own processes to achieve the resolution. There were a small number of inconsistencies which were resolved and are summarized in the ICG combined proposal.231 The topic of the ICG is returned to in Section 5 below.

From an organizational and operational perspective, the most significant change originated with the names community response that recommended the creation of a separate legal entity (post-transition IANA, or PTI) as an affiliate of ICANN to perform the IANA functions under contract to ICANN. In addition to the establishment of PTI, the names community proposal also contained the requirement to establish oversight activities called the IANA Function Review, the Customer Standing Committee, and the Root Zone Evolution Review Committee (RZERC).232

Since neither the numbers nor the protocol parameters communities had identified the need for a separate legal entity or oversight activities, each of these communities used their respective processes to review these organizational structures and found them to be acceptable. As a result of this process, the ICG combined proposal included the recommendation that such a separate legal entity should be established.

231 IANA Stewardship Transition Coordination Group (ICG), “Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions from the U.S. Commerce Department’s National Telecommunications and Information Administration (NTIA) to the Global Multistakeholder Community,” March 2016, https://www.icann.org/en/system/files/files/iana-stewardship-transition- proposal-10mar16-en.pdf. 232 See IANA Transition Coordination Group, “IANA Stewardship Transition Proposal: Call for Public Comment,” n.d., https://www.ianacg.org/icg-files/documents/XPL- ICAN_1510_ICG_Report_Visual_Summary_09.pdf. for an overview of the ICG combined proposal.

The Creation and Administration of Unique Identifiers, 1967-2017 57

As a result of the combined ICG proposal, ICANN created Public Technical Identifiers (PTI) OPERATIONAL ORGANIZATIONS (1969-2017) in August 2016.233 As per the IANA stewardship transition, PTI began performing the IANA functions as governed by its contracts, subcontracts, and other agreements.234

The contractual relationships between ICANN and PTI, and the communities served by the IANA functions, are defined by three agreements.235 The IANA Naming Function Agreement, between ICANN and PTI, defines the performance of the naming function.236 The updated annual Service Level Agreement (SLA) with the IETF defines the performance of the protocol parameters function.237 Finally, the SLA with the numbering community setting out its oversight role for the performance of the numbering function.238 ICANN’s relationship with PTI is set forth in ICANN’s Bylaws in Articles 16-19.239

233 “ICANN Announces Incorporation of Public Technical Identifiers (PTI),” Internet Corporation for Assigned Names and Numbers, August 11, 2016, https://www.icann.org/news/announcement-2-2016-08- 11-en. 234 “Agreements.” n.d. Public Technical Identifiers. Accessed September 1, 2019. https://pti.icann.org/agreements. 235 Furthermore, ICANN subcontracts the IETF and numbering agreement to PTI, as well as certain of ICANN’s responsibilities under the RZMA with Verisign. The Customer Standing Committee, set out in ICANN’s Bylaws also plays a role. 236 Internet Corporation for Assigned Names and Numbers, and Public Technical Identifiers. 2016. “IANA Naming Function Agreement.” https://www.icann.org/en/system/files/files/proposed-iana-naming- function-agreement-10aug16-en.pdf. 237 Internet Corporation for Assigned Names and Numbers, and Internet Engineering Task Force. 2016. “ICANN-IETF MoU Supplemental Agreement.” https://www.icann.org/iana_imp_docs/59-2016-icann- ietf-mou-supplemental-agreement-v-1-0. 238 Internet Corporation for Assigned Names and Numbers, AFRINIC Ltd, APNIC Pty Ltd, for the Asia Pacific Network Information Centre, American Registry for Internet Numbers, Ltd, Latin American and Caribbean Internet Addresses Registry, and Réseaux IP Européens Network Coordination Centre. 2016. “Service Level Agreement for the IANA Numbering Services.” https://www.nro.net/wp- content/uploads/SLA-Executed-ICANN-RIRS.pdf. 239 “Bylaws for Internet Corporation for Assigned Names and Numbers.” 2018. Internet Corporation for Assigned Names and Numbers. June 18, 2018. https://www.icann.org/resources/pages/governance/bylaws-en/.

The Creation and Administration of Unique Identifiers, 1967-2017 58

OPERATIONAL ORGANIZATIONS (1969-2017) 3.8
REGIONAL INTERNET REGISTRIES (RIRs) Although each of the RIRs came into operation through different processes, RFC 1174 is generally recognized as providing the basic architecture for the RIRs.240 In the context of this section, each of the RIRs follow the principles contained in RFC 1174. In addition, each RIR defines the set of policies for the allocation of the resources in the region. Although each RIR separately develops and implements their own policies, the NRO is the entity used by the RIRs when there is a need to coordinate their individually developed policies. Although the NRO does not have an operational role, the coordination function it provides facilitates policies between the RIRs that promote operational stability.

As distinguished from globally coordinated policies in which the RIRs agree to coordinate their individual policies without ICANN involvement, global policy is developed and coordinated through the Address Supporting Organization (ASO) Address Council (AC).241 The Board can reject a global policy and return it to the RIRs orNRO for further consideration but cannot change it other than to ratify recommendations from the RIRs, which are coordinated by the NRO. The policy-setting functions of RIRs are discussed in Section 5.6.

240 Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.” 241 Number Resource Organization, Internet Corporation for Assigned Names and Numbers, Asia-Pacific Network Coordination Centre, American Registry for Internet Numbers, Latin American and Caribbean Internet Addresses Registry, and Réseaux IP Européens Network Coordination Centre. “ASO Memorandum of Understanding.” ICANN Address Supporting Organization, October 21, 2004. https://aso.icann.org/about-the-aso/aso-memorandum-of-understanding/

The Creation and Administration of Unique Identifiers, 1967-2017 59

PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) 4
PRE-ICANN POLICY ADVISORY AND COORDINATION ORGANIZATIONS (1975-99)

Beginning with DARPA’s creation of the Internet Configuration Control Board (ICCB) in 1979, the creation and administration of unique identifiers has been managed by a succession of boards, task forces, working groups, and steering groups. These range from task forces with no formal membership, to chartered organizations. Prior to ICANN, these groups operated technologies, developed standards, and proposed policies for the legally authorized organizations and their coordinating groups. Subsequent to ICANN's creation they operated in an Internet community organized through ICANN’s multistakeholder model. The relationships between these groups shifted considerably between 1979 and the present, with responsibilities and relationships undergoing frequent change. As such, this section provides a description of their structures, functions, and interrelationships, prior to the creation of ICANN. Subsequently, their changes post-ICANN are addressed.

Prior to the creation of ICANN, policy advisory and coordination organizations neither participated in the direct operational administration of unique identifiers, nor did they function as the final source of policy authority. Instead, they worked with both operational and policy- setting bodies to help develop standards and policy. Of these organizations, the Internet Architecture Board (IAB) (formerly the Internet Advisory Board and Internet Activities Board), the Internet Engineering Task Force (IETF), and its associated Internet Engineering Steering Group (IESG) continued to operate during and after ICANN’s creation. Their post- ICANN responsibilities are documented in Section 5, below.

4.1
ARPANET SPONSORS GROUP (1975-83) The Defense Communications Agency (DCA) created the Arpanet Sponsors Group in 1975, the same year it took over the day-to-day operations and financing for the Arpanet. It performed the latter by billing its institutional users. The group met twice a year, with its first meeting in October 1975. The group was “a forum for the exchange of ideas and information on the operation of the Arpanet,” in which the DCA would announce policy; and sponsors could “make recommendations to DCA on network operational activities and services.”242 The DCA described the group as responsible for ensuring that it would “be flexible and responsive to the requirements of the user community.” By user community, this referred not just to individual users, but the U.S. federal departments, agencies, and contractors that represented all users in the group. Membership ranged from thirteen organizations in 1978 to eleven in 1980.243

242 Defense Communications Agency, “ARPANET Information Brochure” (Washington, DC, August 1976), 11, Defense Technical Information Center, http://www.dtic.mil/dtic/tr/fulltext/u2/a482154.pdf. 243 These figures are published in the ARPANET Information Brochures, published by the SRI Network Information Center. Due to availability, years 1976, 1978, 1979, 1980, and 1985 were consulted.

The Creation and Administration of Unique Identifiers, 1967-2017 60

In 1983, the non-civilian nodes moved from the Arpanet to the Defense Data Network (DDN), PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) and Arpanet management was reconfigured in a new arrangement between DCA’s Defense Data Network Program Management Office (DDN PMO) and DARPA. By 1985, official policy stated that “the DDN PMO operates and manages the Arpanet, including the node software and hardware, while DARPA pays the backbone operating costs, sets policy for the ARPANET, and approves access for DARPA-sponsored subscribers.”244 The relationship between DARPA and the DCA was further specified: “The DDN PMO… manages the Arpanet on behalf of DARPA,” including “configuration management and control.” During this time, registration of Arpanet host addresses was administered by the IANA functions under contract to DARPA on behalf of the DCA.245

4.2
INTERNET CONFIGURATION CONTROL BOARD (ICCB) (1979-84) In 1979, Vint Cerf, then Program Manager of DARPA’s Internet Program, created the Internet Configuration Control Board (ICCB) at Robert Kahn’s urging as an “informal committee to guide the technical evolution of the protocol suite”246 and to “help manage the DARPA Internet Program.”247 The ICCB was central to leading the development of core Internet technologies, and, by 1984, interfaced with the IANA functions through Postel’s role as Deputy Internet Architect of the ICCB.248

Chaired first by David Clark of MIT, with Jon Postel as his deputy, the ICCB included twelve member “implementers” from the Internet community.249 The ICCB’s responsibilities included both short- and long-term matters. In the short term, it involved “[k]eeping the Internet operating as an on-going resource, i.e., dealing with problems that arise due to the growth in the size of the system and the level of use of the system. Sometimes this suggests research on new procedures and algorithms, or suggests changes to the existing protocols and procedures.” In the longer term, the ICCB considered “communication problems related to the Internet more abstractly,” it “[suggested] to DARPA possible research topics and experiments,” and could “act as a sounding board for ideas suggested by others.”250

244 Defense Communications Agency, “ARPANET Information Brochure.” 245 Ibid., 17–19. 246 Cerf, “Internet Activities Board.” 247 J. K. Reynolds and J. Postel, “ARPA Internet Protocol Policy” (RFC Editor, July 1984), https://www.rfc-editor.org/info/rfc0902. 248 Ibid. 249 Robert Kahn, Oral History of Kahn, Bob (Robert), interview by Vinton Cerf, (September 30, 2006), http://www.computerhistory.org/collections/catalog/102657973. 250 Reynolds and Postel, “ARPA Internet Protocol Policy.”

The Creation and Administration of Unique Identifiers, 1967-2017 61

In 1984, Jon Postel and Joyce Reynolds of USC-ISI noted that “DARPA has delegated some PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) aspects of the management of the Internet Program and operation of the ARPA-Internet for the DARPA research community to the ICCB.”251 While the ICCB was formally separate from the IANA functions, Postel’s dual role illustrates the close-knit nature of the DARPA networking community at the time.

4.3
INTERNET ADVISORY BOARD (IAB), INTERNET ACTIVITIES BOARD (IAB), INTERNET ARCHITECTURE BOARD (IAB) (1984-2017) DARPA Program Manager Barry Leiner created the Internet Advisory Board (IAB) in 1984 as an evolution of the Internet Configuration Control Board (ICCB). By that time, the number of participants and complexity of the work was straining the organizational capacities of the ICCB. The IAB performed the same functions, but its work was now structured around task forces, the chairs of which comprised the IAB membership. In 1986, the Internet Advisory Board was reconfigured as the Internet Activities Board, which was reformed significantly in 1989. In 1992, it became the Internet Architecture Board (IAB), the title it retains today and which signaled another organizational change. These changes reflected the substantial reorganizations of the relationships between the board and its task forces, as well as shifts in the boards’ responsibilities, as discussed below.

The original purpose of the Internet Advisory Board (IAB) was to assist DARPA in further developing the Internet: to “generate and develop new ideas, to monitor the technical work of the Internet program, and to recommend additional research activity.”252 While similar in general function to the ICCB, the Internet Advisory Board was structured around task forces. The first ten task forces consisted of Gateway Algorithms, New End-to-End Service, Applications Architecture and Requirements, Privacy, Security, Interoperability, Robustness and Survivability, Autonomous Systems, Tactical Internetting, and Testing and Evaluation.253

The organizational structure of the IAB consisted of the chairman of each task force, DARPA’s Internet Program program manager, the IAB chairman, who served as the chief Internet

251 Ibid. 252 Defense Communications Agency, “ARPANET Information Brochure.” In a 2006 interview, Robert Kahn noted that the new DARPA Program Manager for the Internet Program, Barry Leiner, made this decision, based in part on the increasing complexity of the tasks and the growing size of the audience. Kahn, Oral History of Kahn, Bob (Robert). 253 Robert Braden, “The End-to-End Research Group – Internet Philosophers and ‘Physicists,’” March 1998, http://www.ietf.org/proceedings/98mar/slides/plenary-braden/.

The Creation and Administration of Unique Identifiers, 1967-2017 62

architect, the deputy chairman, and the secretary.254 This group, as documented in 1985, PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) “guides and reviews the work of the task forces, and ensures proper cross communication among them. The IAB may, from time to time, create new, or disband existing, task forces.”255 The Internet Advisory Board, then, advised DARPA and other U.S. Federal activities, and directed the work of its task forces.

In 1986, the Internet Advisory Board was renamed and reorganized as the Internet Activities Board. While it retained its task force and general organizational structure, its task forces were changed, with the Gateway Algorithms Task Force replaced with the Internet Engineering Task Force (IETF, see below) and the Internet Architecture Task Force (INARC).256 INARC met once during 1986, and concluded its activities with a workshop in 1989.257

The most significant changes to the Internet Activities Board came in July of 1989, however, when some of its key functions were moved to steering groups. Until then, the IAB was structured around multiple task forces. Now, the task forces were combined to leave only two: the IETF, and the newly formed Internet Research Task Force (IRTF). The IRTF focused on long-term exploratory research and did not engage in direct standards work. For this reason it is not further addressed in this report.258

254 Defense Communications Agency, “ARPANET Information Brochure.” 255 Ibid, II–51. 256 INARC is referred to in documentation as both “Internet Architecture” and the “Internet Architecture Task Force.” It had the structure of a task force. 257 Allison Mankin and Phillip Gross, “Proceedings of the July 27-29, 1987 Internet Engineering Task Force,” July 1987; Philip Gross and Gregory M. Vaudreuil, “Proceedings of the Sixteenth Internet Engineering Task Force Florida State University February 6-9, 1990” (Corporation for National Research Initiatives, 1990). Its proposed charter would have seen it “explore and extend the architectures and engineering models for internet systems” by considering large-scale and long-term design issues alongside prototyping efforts both in its own group and through collaboration with other task forces. Phillip Gross, “Proceedings of the 16-17 January 1986 DARPA Gateway Algorithms and Data Structures Task Force / FIRST IETF” (The MITRE Corporation, 1986); Philip Gross and Allison Mankin, “Proceedings of the Ninth Internet Engineering Task Force March 1-3, 1988 in San Diego” (McLean, Virginia: The MITRE Corporation, March 1988). 258 In 1990, the IRTF was described as "generally more concerned with understanding than with products or standard protocols, although specific experimental protocols may have to be developed, implemented and tested in order to gain understanding" (Cerf 1990 / RFC 1120). Put more directly by the 1996 official IRTF Research Group Guidelines and Procedures, "[t]he IRTF does not set standards" (Weinrib 1996 / RFC 2014).

The Creation and Administration of Unique Identifiers, 1967-2017 63

The IAB would not interact with the remaining task forces directly, as it had in the past, but PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) instead would interface through a steering group for each: the Internet Engineering Steering Group (IESG) communicated with the Internet Engineering Task Force, and the Internet Research Steering Group (IRSG) communicated with the Internet Research Task Force (IRTF). These steering groups performed functions previously incorporated within the IAB itself. With respect to the IETF and IESG’s domain of Internet standards:

Overall guidance of the IETF is provided by the IETF Steering Group (IESG). The IESG is composed of the area directors and the Chair of the IETF. The IESG has the general responsibility for making the Internet operate smoothly by identifying and resolving the short and mid term issues and problems. Each area director has primary responsibility for one area of IETF activity.259

Each of these Task Forces is led by a chairman and guided by a Steering Group which reports to the IAB through its chairman. Each task force is organized by the chairman, as required, to carry out its charter. For the most part, a collection of Working Groups carries out the work program of each Task Force.260

As such, while the overall structure and functions of the Internet Activities Board and its task forces remained the same, this change further formalized the coordination between the two.

The IAB engaged with the unique identifier administration in two ways. First, it oversaw the technical development and standardization of protocols that specified the structure of unique identifiers and protocol parameters, and as such their requirements for administration.261 The IAB set direction and approved standards through their role in appointing and ratifying chairs of the task forces (1984-89), and then the task forces through the steering groups (1989-92).262 Prior to 1992, given how IETF task forces chairs populated much of the IAB membership, the IAB was deeply intertwined with the IETF. Second, the IAB periodically worked in cooperation with federal agencies to formulate general policy for unique identifier administration.

259 Philip Gross and Gregory M. Vaudreuil, “Proceedings of the Fifteenth Internet Engineering Task Force University of Hawaii October 31 - November 3, 1989” (Corporation for National Research Initiatives, 1989), 7. 260 Cerf, “Internet Activities Board.” 261 Internet Activities Board, “Minutes of the March 21, 1988 Internet Activities Board Teleconference,” March 21, 1998, https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988-03-21/; Internet Activities Board, “Minutes of the July 12-13, 1988 Internet Activities Board Meeting Sante Fe, New Mexico,” July 12, 1988, https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988- 07-12/. 262 IAB approved standards until 1992 when the POISED working group, led by Steve Crocker, restructured the relationship and responsibility for standards decisions, delegating direct standards- making to IESG and its IETF. This is addressed below.

The Creation and Administration of Unique Identifiers, 1967-2017 64

For example, policy for the requirements for Internet domains, as well as the DNS PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) implementation schedule and policies, were announced by DARPA and the IAB.263 The IAB also published the agreement with the NSF that ensured interoperability between the DARPA-sponsored Internet and the new NSFNET,264 and the IAB was briefed by the NSF on the plans for its development.265

In June 1992, the Internet Activities Board was renamed and reorganized as the Internet Architecture Board, which accompanied two major changes that took place over the span of the next six months. First, the organizations, whose relationships with each other also changed, as documented below, were organized under the auspices of the newly chartered, not-for-profit Internet Society (ISOC).266 This made ISOC the legal home for the IETF. 267

Second, the Internet community overhauled the standards process itself, which resulted in a different relationship between ISOC, the IESG, the IETF, and the IAB. In response to controversy at the first meeting of the Internet Architecture Board and Internet Society, in June 1992, the IETF formed the Process for Organization of Internet Standards (POISED) Working Group, led by Steve Crocker.268 This working group would address concerns surrounding the procedures for making appointments, for resolving disagreements between the IAB, IESG, and IETF, as well as methods for assuring that standardization procedures were being followed. The POISED recommendations were adopted by all parties in January 1993 and a new charter would follow,269 and was implemented formally as a new standards process in March 1994.270

263 Postel and Reynolds, “Domain Requirements”; Jon Postel, “Domain Name System Implementation Schedule-Revised,” 1984, https://www.rfc-editor.org/info/rfc921; Stahl, “Domain Administrators Guide.” 264 Network Technical Advisory Group, “Requirements for Internet Gateways - Draft” (National Science Foundation, 1986), https://www.rfc-editor.org/rfc/pdfrfc/rfc985.txt.pdf; Robert T. Braden and Jon Postel, “Requirements for Internet Gateways,” 1987, https://www.rfc-editor.org/info/rfc1009. 265 Ann Westine and Karen Roubicek, “January 1998 Internet Monthly Reports” (NSFNET Information Service, January 1998). 266 S. Crocker, “The Process for Organization of Internet Standards Working Group (POISED),” 1994, https://www.rfc-editor.org/rfc/pdfrfc/rfc1640.txt.pdf. 267 ISOC’s articles of incorporation lay out its own structure, but its relationship to the IAB and other organizations was documented by the Internet community. See “Governance & Policies,” Internet Society, accessed September 18, 2018, https://www.internetsociety.org/about-internet-society/governance- policies/. 268 Stephen Crocker, “The Process for Organization of Internet Standards Working Group [POISED],” Request For Comments, January 1993, https://www.rfc-editor.org/info/rfc1396; Crocker, “The Process for Organization of Internet Standards Working Group (POISED).” 269 Crocker, “The Process for Organization of Internet Standards Working Group [POISED].” 270 Scott Bradner, “The Internet Standards Process--Revision 2,” 1996, https://www.rfc- editor.org/info/rfc1602.

The Creation and Administration of Unique Identifiers, 1967-2017 65

With respect to the Internet Architecture Board specifically, it now served as a “technical PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) advisory group of the Internet Society.” The 1992 reorganization retained a relationship between the IETFand its steering group. However, the IAB’s role in the standards process shifted to providing the appeal process for IESG decisions, and approving the IETF’s nominations for appointment to the IESG.271 Authority to approve standards moved to the IESG from the IAB. The IETF published the details of the standardization processes in RFCs; how the standards process applies to specific identifiers and classes of identifiers is documented in Section 2.

4.4
INTERNET ENGINEERING TASK FORCE (IETF) (1986-2017), INTERNET ENGINEERING STEERING GROUP (IESG) (1989-2017) The IETF was created in 1986, replacing the Internet Activity Board’s Gateway Algorithms and Data Structures (GADS) Task Force. Its original proposed charter reflected how it would work under the Internet Activities Board:

The mission of this task force is to identify and resolve engineering issues in the near- term planning and operation of the DoD Internet. [...] The products of this task force are expected to be in the form of technical memoranda and other documents useful to the operational agencies and their contractors.272

At the time, the Internet Activities Board worked very closely with U.S. Federal agencies and departments, and new standards would be implemented by a small number of contracted researchers, such as university faculty and graduate students. The IAB was assigned technical problems and, after research and testing, proposed solutions. Standards were approved by the IAB in conjunction with federal bodies.

The IETF’s internal structure evolved over the subsequent years: beginning with organizing work into areas of concern,273 then introducing working groups in 1987,274 which in 1989 were organized into technical areas.275 At each of these stages, the areas or groups were coordinated by a director who was also a member of the Internet Engineering Steering Group (IESG).

271 Ibid. 272 Gross, “Proceedings of the 16-17 January 1986 DARPA Gateway Algorithms and Data Structures Task Force / FIRST IETF.” 273 Ibid.; Phillip Gross, “Proceedings of the 15-17 October 1986 Joint Meeting of the Internet Engineering and Internet Architecture Task Forces” (McLean, Virginia: MITRE Corporation, October 1986). 274 Gary Malkin, “The Tao of IETF-A Guide for New Attendees of the Internet Engineering Task Force,” 1993, https://www.rfc-editor.org/rfc/pdfrfc/rfc1391.txt.pdf. 275 Gross and Vaudreuil, “Proceedings of the Fifteenth Internet Engineering Task Force University of Hawaii October 31 - November 3, 1989.”

The Creation and Administration of Unique Identifiers, 1967-2017 66

Crucially, the IETF has never had a formal membership other than its directors. Instead, PRE-ICANNPOLICY ADVISORY AND COORDINATIONORGANIZATIONS (1975-99) the IETF is described as a “collection of happenings” and anyone may contribute to one of its working groups.276

The organizational structure of the Internet community’s boards, task forces, and steering groups changed significantly between DARPA’s creation of the ICCB in 1979, and its reconfigurations in 1992. From 1992 until the creation of ICANN in 1998, the IAB/IETF/ IESG structure remained in place. Throughout this entire period from 1979-98, there were no significant changes in the relationship within the Internet community between the federal policy-setting bodies, on the one hand, and the boards, task forces, and steering groups, on the other. The statutory authority to administer the unique identifiers remained with the U.S. Federal Government, for which it solicited advice and delegated authority to the rest of the Internet community. The U.S. Federal Government’s authority did not prevent, in the mid-1990s, controversy over the future of unique identifier administration—as well as controversy over who should control it.277

276 Paul Hoffman and Susan Harris, “The Tao of IETF-A Novice’s Guide to the Internet Engineering Task Force,” 2006, https://www.rfc-editor.org/info/rfc3160. 277 The largest controversy surrounded the newly formed International Ad Hoc Committee (IAHC), and its Generic Top Level Domain Memorandum of Understanding (gTLD-MOU). The IAHC’s original website and the gTLD-MOU are available at International Ad Hoc Committee, “The Generic Top Level Domain Memorandum of Understanding,” The Internet Archive, December 11, 1997, https://web.archive.org/web/19971211190034/http://www.gtld-mou.org/.

The Creation and Administration of Unique Identifiers, 1967-2017 67

POLICY SETTING ORGANIZATIONS (1968-2017) 5
POLICY SETTING ORGANIZATIONS (1968-2017)

Policy setting organizations are defined in this report by their role as the highest authority within the Internet or Arpanet community at which policy is formulated. This policy-setting authority takes two forms: 1) the authority to set policy, that is, to tell another entity what they can and cannot do, and how they can do it, and 2) the authority to define a policy realm for an entity, that is, to grant an entity the authority to operate in a given area. In different times and places, different institutions held various combinations of these two kinds of policy authority. Prior to the changes put in motion with the creation of the Internet Corporation for Assigned Names and Numbers (ICANN), policy setting authority was exercised by organizations within the U.S. Federal Government. While these organizations frequently gathered input from the broader community, their authority was still derived from their status as parts of the U.S. Federal Government.

Most of the organizations discussed in this report have a level of formality that is in some sense ‘legal;’ here we use this term specifically with respect to organizations with legal authorization to administer unique identifiers. ICANN, on the other hand, drew on a new kind of authority to administer unique identifiers. Created in 1998, ICANN derives its policy-setting authority from its “multistakeholder model,” although the origins of this model can be traced back to the Réseaux IP Européens (RIPE) and Asia Pacific Network Information Centre (APNIC). ICANN describes this “decentralized governance model,” which is discussed further below, as one that,

places individuals, industry, non-commercial interests and government on an equal level. Unlike more traditional, top-down governance models, where governments make policy decisions, the multistakeholder approach used by ICANN allows for community-based consensus-driven policy-making.278

Within the space of legally recognized and community organizations there are horizontal or peer relationships, and there are also hierarchical relationships, or relations of authority. This section documents i) the sources of these organizations’ authority and legitimacy, ii) the relationships between these organizations, and iii) the mechanisms by which the organizations delegate responsibility to the “responsible organizations” documented in Section 3. The relationships between the three categories of organization documented in this report were sometimes first codified in contracts or other legal instruments, but most often they first evolved organically over time.

278 See, for example “A Beginner’s Guide to Participating in ICANN” (Internet Corporation for Assigned , November 2013), https://www.icann.org/resources/pages/beginners-guides-2012-03-06-en.

The Creation and Administration of Unique Identifiers, 1967-2017 68

Central to this evolution are the relationships between different types of organization POLICY SETTING ORGANIZATIONS (1968-2017) and different forms of interface between them: for example, between ARPA and the Networking Working Group, and between the National Science Foundation and the Internet Architecture Board. Another form of relationship that evolved was between Internet community organizations and volunteer organizations or individuals responsible for local implementation or policy, such as with the management of Country Code Top-Level Domains (ccTLDs).

Related to the policy-setting authority is the ability to fund the administration of unique identifiers. In the case of funding, we are careful to distinguish between this, and this top-level, policy setting authority. Frequently, a funding mechanism such as a contract is a useful proxy for the delegation of responsibility, or of other coordination of work. However, due to the complexity of the relationships between the organizations that administer unique identifiers, funding is not synonymous with authority. Authority and coordination can exist without a funding mechanism, and a funding mechanism can exist without authority; for example, ICANN was given authority, but no funding from the U.S. Federal Government.

Until the 1990s–that is, in the early history of the Internet and throughout the entire history of the Arpanet–the organizations that set policy for the unique identifier administration were largely exercising statutory authority. While these organizations certainly received the support of their communities, the mechanism by which they derived their authority was granted through law. What is more, this legal authority was American, because it was U.S. Government organizations that led the Arpanet and the early Internet research and development ecosystem. This section documents how the Internet community transformed the legal and American character of unique identifier administration into a global and multistakeholder model–beginning with their creation of the ICANN in 1998 and entering its current phase with the IANA stewardship transition in 2016.

5.1
THE DEFENSE ADVANCED RESEARCH PROJECTS AGENCY (DARPA) (1968-98) DARPA’s role in the creation of both the Arpanet and the Internet is well known.279 This subsection documents the sources of its legal authority over the administration of unique identifiers on the Arpanet and Internet.

279 In addition to a number of academic texts on the history of the Internet, the Internet Society provides a survey of key individuals, organizations, ideas, and dates. Janet Abbate, Inventing the Internet (MIT Press, 1999), http://books.google.com/books?id=E2BdY6WQo4AC; Matthew Lyon and Katie Hafner, Where Wizards Stay Up Late: The Origins Of The Internet (Simon and Schuster, 1999); M. Mitchell Waldrop, The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal, 1ST edition (New York: Viking Adult, 2001); Barry M. Leiner et al., “Brief History of the Internet” (Internet Society, 1997), https://www.internetsociety.org/resources/doc/2017/brief-history-internet/.

The Creation and Administration of Unique Identifiers, 1967-2017 69

The Eisenhower administration created the Advanced Research Projects Agency (ARPA) POLICY SETTING ORGANIZATIONS (1968-2017) in 1958, as part of a larger reorganization of the U.S. Department of Defense. Specifically, the U.S. Government created ARPA through the U.S. Department of Defense Reorganization Act of 1958, itself an update to the National Security Act of 1947. The Reorganization Act itself authorized the U.S. Department of Defense, specifically, the U.S. Secretary of Defense and subordinates, such as agency directors, to engage in a wide range of research:

The Secretary of Defense or his designee, subject to the approval of the President, is authorized to engage in basic and applied research projects essential to the responsibilities of the Department of Defense in the field of basic and applied research and development which pertain to weapons systems and other military requirements.280

As such it authorized all research projects related to military requirements. In order to carry out this work, the U.S. Defense Department was also authorized to perform such research

by contract with private business entities, educational or research institutions, or other agencies of the Government, through one or more of the military departments, or by utilizing employees and consultants of the Department of Defense.281

Thus, the U.S. Defense Department was authorized to contract with a wide range of organizations in carrying out its research mission.282 Finally, the Reorganization Act also signaled the development of an “advanced projects” function, linked to federal efforts to rationalize research and development of space technologies283 and for military requirements in general. Here, the subordinates of the U.S. Secretary of Defense were specifically authorized to “engage in such advanced projects essential to the U.S. Defense Department's responsibilities in the field of basic and applied research and development,” again pertaining to both weapon systems and military requirements in general.284

280 Sec “Department of Defense Reorganization Act of 1958,” Pub. L. No. 85-599, 514 (1958)9.2. 281 Sec ibid.9.2. 282 The Department of Defense’s authority to utilize contracts, internally and externally, was created in its modern form in the National Security Act Amendments of 1949 and specified in Directive 7410.4. This Act also created the Industrial Fund, which was the strictly financial (rather than contractual) mechanism by which Defense Department entities paid for goods and services. “National Security Act Amendments of 1949,” Pub. L. No. 216, U.S.C. (1949), https://catalog.archives.gov/id/299860; Jan Michele Hinton, “A Study of the Communications Services Industrial Fund” (Monterey, California. Naval Postgraduate School, 1985), http://calhoun.nps.edu/handle/10945/21562. 283 Richard Barber, “The Advanced Research Projects Agency, 1958-1974” (Washington, D.C.: Richard J. Barber Associates, Inc., December 1975), http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA154363. 284 Sec Department of Defense Reorganization Act of 19587.

The Creation and Administration of Unique Identifiers, 1967-2017 70

Texts pertaining to ARPA from the Reorganization Act were applied in slightly modified POLICY SETTING ORGANIZATIONS (1968-2017) form to create the first U.S. Department of Defense Directive, hereafter referred to as the DoD Directive or as Issuances number 5105.15.285 U.S. DoD Directives are U.S. Department of Defense documents that create or describe organizations, programs, or general policy within the U.S. Department of Defense as it fulfills its duties. As such, U.S. DoD Directive 5105.15 is sometimes referred to as DARPA’s ‘charter.’ It stated that “The Agency shall be responsible for the direction or performance of such advanced projects in the field of research and development as the Secretary of Defense shall, from time to time, designate by individual project or category.”286

Projects designated by “category” would come to include the Command and Control Research (CCR) portfolio assigned to ARPA by the White House in 1962, for which ARPA created IPTO to execute. DARPA’s ‘charter’ included language similar to the Reorganization Act in its authority to contract with a wide range of organizations. It also further authorized the agency to “acquire or construct such research, development, and test facilities and equipment” in carrying out its mission.287

The U.S. Department of Defense replaced this original charter with DoD Directive 5105.41 in 1972, which brought significant changes to ARPA and its mission.288 In addition to altering its name to DARPA, as noted in Section 1 above, it stated the agency’s responsibilities in a broader form: “DARPA has the responsibility to provide for the conduct of basic and applied research and development for such advanced projects as may be designated by the Secretary of Defense.”289 This expanded considerably DARPA’s authorization.

What is more, with respect to the “designation” of DARPA research programs by the U.S. Secretary of Defense, DARPA was also authorized to recommend “the assignment of research projects” to itself through the Director of Defense Research & Engineering (DDR&E), thereby giving it a formal mechanism to effectively assign itself research. The 1972 directive retained DARPA’s original 1958 authorizations to contract with a wide range of entities, including individuals, private firms, and U.S. military departments, as well as to “acquire or construct… research, development, and test facilities and equipment” required to carry out its programs.290

285 Department of Defense, “Department of Defense Directive 5105.15 1958” (Department of Defense, February 7, 1958). 286 Ibid. 287 Ibid, 2. 288 Department of Defense, “Department of Defense Directive 5105.41 1972,” March 23, 1972. 289 Ibid, 1. 290 Ibid, 2–3.

The Creation and Administration of Unique Identifiers, 1967-2017 71

This 1972 expansion of DARPA’s authorization is relevant in terms of the growing significance POLICY SETTING ORGANIZATIONS (1968-2017) of the Arpanet. Until then, the network was broadly understood as purely experimental, as a testbed for the demonstration of packet switching and resource sharing. The original request for quotations (RFQ) solicited bids for a four-node network that would, if successful, be expanded to an experiment of 19 nodes.291 While the Arpanet surpassed 19 nodes in 1971,292 it continued to develop as an experiment as its success created new avenues for research. In 1972, DARPA was provided a formal channel through which to recommend its own research projects,293 which codified an arrangement that dated from the 1960s.294 During the period in which DARPA was involved in unique identifier administration, the DoD issued subsequent directives in 1978, 1986, 1989, and 1995,295 which by 1995 saw an overall expanded set of responsibilities and more latitude in the means by which it delegated authority and in its ability to determine research priorities.

Through the 1950s and the 1960s, the U.S. Department of Defense typically negotiated, for each contract, rights to use the product of its research programs, including “the right to distribute the information resulting from these federally funded projects to the general public.”296 It is in this context that DARPA made much of its networking research publicly available, effectively or formally placing them in the public domain.297

291 Defense Supply Service, “Specifications of Interface Message Processors for the ARPA Computer Network.” 292 V. Cerf and B. Kahn, “Selected ARPANET Maps,” Computer Communications Review (CCR) 20 (1990): 81–110. 293 Department of Defense, “Department of Defense Directive 5105.41 1972.” 294 Barber, “The Advanced Research Projects Agency, 1958-1974.” 295 Department of Defense, “Department of Defense Directive 5105.41 1972”; Department of Defense, “Department of Defense Directive 5105.15 1978,” 1978; Department of Defense, “Department of Defense Directive 5105.15 1989,” 1989; Department of Defense, “Department of Defense Directive 5105.15 1995,” 1995. 296 Danielle Conway-Jones, “Research and Development Deliverables under Government Contracts, Grants, Cooperative Agreements and CRADAs: University Roles, Government Responsibilities and Contractor Rights,” Computer Law Review & Technology Journal 9 (2004): 181, http://heinonline.org/HOL/Page?handle=hein.journals/comlrtj9&id=183. 297 David C. Mowery and Timothy Simcoe, “Is the Internet a US Invention?—an Economic and Technological History of Computer Networking,” Research Policy 31, no. 8–9 (December 2002): 1369–87, https://doi.org/10.1016/S0048-7333(02)00069-0; David C. Mowery and Bhaven N. Sampat, “The Bayh- Dole Act of 1980 and University-Industry Technology Transfer: A Model for Other OECD Governments?,” in Essays in Honor of Edwin Mansfield, ed. Albert N. Link and F. M. Scherer (Springer US, 2005), 233–45, http://link.springer.com/chapter/10.1007/0-387-25022-0_18.

The Creation and Administration of Unique Identifiers, 1967-2017 72

These rights were identified by the U.S. Government Accountability Office’s General Counsel POLICY SETTING ORGANIZATIONS (1968-2017) in its finding that the IANA stewardship transition, which is addressed below, did not violate U.S. law.298

Until 1974, Section 9-203(b) of the Armed Services Procurement Regulations (ASPR) under the Armed Services Procurement Act governed DARPA’s legal rights to the software and data derived from its research funding. Beginning in 1974, these rights were governed by the U.S. Office of Federal Procurement Policy (OFPP) Act (41 U.S.C. 1707).299 The Armed Services Procurement Regulations governed by this act stated that the U.S. Government has broad rights to retain, use, and release data created in the course of its contracts.300 These rights typically took the form of “unlimited rights in data,” and were included on a per-contract basis. This meant that the U.S. Federal Government had the right to release data, such as unique identifier assignments, insofar as that data was necessary to interface items and processes with other items or processes. The extent of this disclosure, based on government preference, was (as noted) unlimited. The U.S. Federal Government also enjoyed the right to “deferred ordering,” which granted it the rights to data and software that was not specified in the original contracts, but subsequently became necessary to fulfill those contracts.301

298 Office, U. S. Government Accountability, “Department of Commerce--Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions.” 299 “Office of Federal Procurement Policy Act,” 41 U.S.C. § 1707 (1974). 300 “The United States may release or disclose technical data to persons outside the Government, or permit the use of technical data by such persons, if—(i) such release, disclosure, or use—(I) is necessary for emergency repair and overhaul; (II) is a release, disclosure, or use of technical data pertaining to an interface between an item or process and other items or processes necessary for the segregation of an item or process from, or the reintegration of that item or process (or a physically or functionally equivalent item or process) with, other items or processes; or (III) is a release or disclosure of technical data (other than detailed manufacturing or process data) to, or use of such data by, a foreign government that is in the interest of the United States and is required for evaluational or informational purposes; (ii) such release, disclosure, or use is made subject to a prohibition that the person to whom the data is released or disclosed may not further release, disclose, or use such data; and (iii) the contractor or subcontractor asserting the restriction is notified of such release, disclosure, or use.” 301 Deferred ordering “refers to delaying the ordering of technical data or computer software generated in the performance of the contract until such time as a need can be established and the requirements can be specifically identified for delivery under the contract. In many instances it is difficult to determine during solicitation and negotiation stages exactly what data or software is needed. The information available at these stages may suggest the need for some data or software but further information may be needed to identify the specific data or software items In such situations and also when it is desired to delay the ordering of technical data or computer software until such time as the production design becomes firm the Deferred Ordering clause is appropriate.” One reason given for this regulation was that it was required to facilitate interface between parts of the technical system (e.g. the Arpanet and Internet) under construction. Today, this statute is Section 227.7102-2 of the Defense Federal Acquisition Supplement.

The Creation and Administration of Unique Identifiers, 1967-2017 73

POLICY SETTING ORGANIZATIONS (1968-2017) 5.2
DEFENSE COMMUNICATIONS AGENCY (DCA) AND DEFENSE DATA NETWORK PROGRAM MANAGEMENT OFFICE (DDN PMO) (1975-92) Like DARPA, the National Security Act of 1947 and its update in the Defense Reorganization Act of 1958 created the authority that would underpin what would become the Defense Information Systems Agency (DISA) in 1960. The Secretary of Defense authorized the creation of the DCA with the U.S. Department of Defense Directive 5105.19, which was updated multiple times between 1960 and 2006.302

The DCA’s purpose was to centralize the common-user, meaning U.S. Defense Department- wide communication within the U.S. Department of Defense. DCA also played a role in the administration of unique identifiers on the Arpanet and the Internet. In July 1975, DCA took over ARPA contracts for the operational, meaning non-research, tasks of the Arpanet. In April 1982, the U.S. Secretary of Defense authorized the creation of the Defense Data Network, which led to the formation of the DCA Defense Data Network Program Management Office (DDN PMO). After its creation, the DDN PMO, as well as committees formed to advise it, worked with DARPA and the IANA function at the Information Sciences Institute (USC/ISI) to set policy for the administration of unique identifiers.

The 1978 version of U.S. DoD Directive 5105.19 renewed DCA’s original 1960 authority to manage common-user communications for the U.S. Department of Defense.303 It also continued DCA’s authorization to “[p]rocure leased communication circuits, services, facilities, and equipment for the DoD [Department of Defense], where authorized, and for other Government agencies as directed by the Secretary of Defense.”304 As a U.S. Defense agency, DCA’s authority to issue contracts, internally and externally to the U.S. Defense Department, was first created in the National Security Act Amendment of 1949.305 This contracting authority made use of the Industrial Fund–specifically, the Communication Services Industrial Fund (CSIF), as the financial mechanism through which the DCA procured, and charged for, goods and services.306

302 Department of Defense, “DoD Directive 5105.19: Defense Communications Agency,” 1961. During the period discussed in this study, directive 5105.19 was subsequently issued in 1974, 1978, 1988, and 1991. 303 The original DCA authorization was for the Defense Communications System (DCS) and the National Military Command System (which was variously named over the years). The DCS was a categorical description of all common-user networks. 304 Department of Defense, “Department of Defense Directive 5105.15 1978.” 305 National Security Act Amendments of 1949. It was further specified in Defense Directive 7410.4 (1982). 306 Defense Communications Agency, “ARPANET Information Brochure”; Hinton, “A Study of the Communications Services Industrial Fund.”

The Creation and Administration of Unique Identifiers, 1967-2017 74

The U.S. Secretary of Defense transferred the Arpanet operations and maintenance contracts POLICY SETTING ORGANIZATIONS (1968-2017) to the DCA effective July 1, 1975.307 DARPA and the DCA outlined the transfer in a MOU that called for DCA management until 1978, or until other networks could take its place. The MOU, also, designated a six-month period during which time DARPA would assist the DCA with management of the Arpanet. The DCAs Arpanet responsibilities fell into two categories: contracting Arpanet operations, including the administration of unique identifiers, and coordinating policy decisions through the Arpanet Sponsors Group.308 During this time, DCA shared with DARPA authority over the Arpanet. It does not appear that significant network policy authority over unique identifier administration was, in practice, transferred from DARPA to DCA. Nonetheless, the relationship between DARPA and the DCA in the administration of the Arpanet appears as follows.

Policy authority over Internet unique identifiers was also shared between DARPA and the DCA, but in different ways that varied across time. The history is made more complex by the fact that Arpanet and Internet unique identifiers were managed by the same people and organizations, from the origins of DARPA’s internetworking research until the decommissioning of the Arpanet in 1990.309

DCA assumed responsibility for Arpanet operations and maintenance contracts in 1975. These included Bolt Beranek and Newman Inc.’s Network Control Center (BBN NCC) and the Stanford Research Institute’s Network Information Center (SRI NIC).310 Contracts to the University of Southern California Information Sciences Institute (USC ISI), however, remained with DARPA , which were exercised through a contracting agency. The IANA functions, which arrived at USC-ISI with Jon Postel in 1976, was embedded in a broader internetworking research program funded by DARPA. Meanwhile, higher level policy authority was divided between DARPA and DCA.

307 GIRDVAINIS@BBN-TENEX, “Arpanet Management Transition,” September 26, 1975; Alexander McKenzie and David Walden, “The ARPANET, the Defense Data Network, and the Internet,” in Encyclopedia of Telecommunications, vol. 1 (Marcel Dekker, Inc., 1997), 341–76. 308 McKenzie and Walden, “The ARPANET, the Defense Data Network, and the Internet.” 309 After the Arpanet’s decommissioning, the similar MILNET unique identifiers continued to be managed by the IANA functions. 310 Defense Communications Agency, “Contract DCA200-84-C-0024” (SRI International, February 6, 1984).

The Creation and Administration of Unique Identifiers, 1967-2017 75

POLICY SETTING ORGANIZATIONS (1968-2017) 5.3
NATIONAL SCIENCE FOUNDATION (1982-98) Like DARPA and DCA, the National Science Foundation (NSF) possessed statutory authority to build and maintain network infrastructure. The U.S. Federal Government created the NSF in 1950, with the passage of the National Science Foundation Act, and the NSF’s statutory authority is now governed by Chapter 16 of Title 42 of the U.S. Code.311 As stated in the NSF Act, the NSF was created with the mission to, among other things, "foster the interchange of scientific information among scientists in the United States and foreign countries" and better distribute scientific expertise and resources across the United States.312 The NSF was also granted the “general authority” to undertake a range of activities so as to fulfill its mission, such as the ability to contract with organizations and individuals in the U.S. and abroad, to purchase, lease, etc. property, and to publish and arrange for the publication of scientific and technical information.313 The NSF was also authorized to partner with the U.S. Department of Defense for research. Since its establishment in law in 1950, the U.S. Congress has continually modified the laws governing NSF operation and authority.

The NSF’s first engagement with the Arpanet-Internet community was with the development of CSNET, the Computer Science Network. Initiated in 1980 with the first services appearing online in 1981, CSNET was funded by NSF contract314 and provided access to computer networking services to researchers outside of Arpanet and the nascent Internet community. The CSNET did not refer to a single network but to a linked collection of services and connections: links over Telenet, a private-sector X.25-based network provider, Phonenet, an electronic mail relay network, and direct connections with the Arpanet.315 Thus, in addition to utilizing the Internet community’s protocols, CSNET also interoperated with the X.25 transport protocol in order to also send data over Telenet.

The NSF provided funding for five years of CSNET service–not only funding for Telenet and other commercial services, but software development for information resources—after which it became self-sustaining through fees. The NSF’s direct involvement ceased after 1986.316

311 “National Science Foundation Act,” Title 42 § 16 (1950), https://www.loc.gov/law/help/us-code.php. 312 “A Brief History,” The National Science Foundation, July 15, 1994, https://www.nsf.gov/about/history/nsf50/nsf8816.jsp. 313 National Science Foundation Act. 314 Lawrence Landweber and Marvin Solomon, “Technical Support of Csnet and Service Host Functions in Support of Csnet” (National Science Foundation Division of Computing and Communication Foundations, January 16, 1981), https://www.nsf.gov/awardsearch/showAward?AWD_ID=8109318. 315 Peter J. Denning, Anthony Hearn, and C. William Kern, History and Overview of CSNET, vol. 13 (ACM, 1983), http://dl.acm.org/citation.cfm?id=1035267. 316 Landweber and Solomon, “Technical Support of Csnet and Service Host Functions in Support of Csnet.”

The Creation and Administration of Unique Identifiers, 1967-2017 76

CSNET merged with Bitnet–a cooperative network of US universities317–and was shut down POLICY SETTING ORGANIZATIONS (1968-2017) in 1991.318 During its operation, neither the NSF nor CSNET management was involved in the administration of unique identifiers. While CSNET did utilize unique identifiers in its operation, those identifiers were simply assigned to the appropriate components of the CSNET project.319 CSNET also utilized protocol specifications developed by the Internet community, although CSNET-funded developers also created their own software to interface different networks and services.320 The NSF’s funding of the NSFNET did, however, eventually lead NSF to become involved in unique identifier administration, although not until the passage of the High Performance Computing Act (HPCA) of 1991.321 For convenience, we will first provide a summary of the NSFNET’s operation.

The NSFNET’s first (56kbit/s) backbone was operational in 1986, with the backbone run by NSF-funded supercomputer centers, to which the network was connected. In June 1987, the NSF released a solicitation to enter into a cooperative agreement with an organization to provide an expanded (1.5 Mb/s, or T-1) backbone. In October 1988 the NSF announced Merit, IBM, and MCI as the recipients, and that November the NSF initiated with Merit a five-year cooperative agreement.

The new backbone and its additional backbone nodes were online in July 1988.322 In 1989, the NSF increased the monetary value of the cooperative agreement in order to provide more capacity to the NSFNET, the use of which was skyrocketing. Merit proposed adding faster (45 Mb/s T3) speeds to certain links, and NSF revised the cooperative agreement accordingly.323 Now administered by the Advanced Network & Services, Inc. (ANS) consortium of Merit, IBM, and MCI, the NSF approved the addition of Network Access Points (NAPs) to enable the connection of private backbone infrastructure.324

317 James Gillies and Robert Cailliau, How the Web Was Born: The Story Ofthe World Wide Web (Oxford: Oxford University Press, 2000). 318 D. A. Grier and M. Campbell, “A Social History of Bitnet and Listserv, 1985-1991,” IEEE Annals of the History of Computing 22, no. 2 (April 2000): 32–41, https://doi.org/10.1109/85.841135. 319 Postel and Vernon, “RFC820: Assigned Numbers,” 1982. 320 Postel and Reynolds, “RFC880: Official Protocols”; Reynolds and Postel, “RFC870: Assigned Numbers.” 321 Gore and Albert, “High-Performance Computing Act of 1991,” Pub. L. No. 272 (1991), https://www.congress.gov/bill/102nd-congress/senate-bill/272. 322 Office of the Inspector General, “Review of NSFNET” (National Science Foundation, April 23, 1993), https://www.nsf.gov/pubs/stis1993/oig9301/oig9301.txt. 323 Ibid. 324 Ibid.

The Creation and Administration of Unique Identifiers, 1967-2017 77

The NSF decommissioned its public backbone in 1995 and former users of the NSFNET relied POLICY SETTING ORGANIZATIONS (1968-2017) on commercial Internet Service Providers (ISPs) and intermediate level networks interconnected by way of NSF-sponsored NAPs, Internet Exchange Points (IXPs) or direct network peering connections.325

The NSF contributed to the Internet community since its funding of CSNET. In 1985, NSF reached a further agreement with DARPA to use DARPA-developed internetworking protocols on the NSFNET. This agreement was reached through the NSF’s Network Program Advisory Group (NPAG), which was formerly called the NPA Committee, or NPAC. The NSF used this body to deliberate technology policy.326 The NSF announced this agreement in RFC 985,327 which was a statement of the NSFNET’s requirements for Internet gateways. Furthermore, from 1986, the NSF specified to contractors that the NSFNET would interoperate with the DARPA Internet. In the NSFNET’s specification of the T-1 upgrade, for example, NSF specified that the contractor would “[p]rovide and install network services, initially DOD standard IP per RFC 791, including Internet Control Message Protocol (ICMP) per RFC 792, and appropriate reachability and routing functions compatible with interoperation with the DARPA Internet.”328

NSF also specified that the contractor would “[w]ork with representatives of other agencies in providing connections for NSFNET with “peer” networks such as the NASA Science Internet, the Department of Energy Energy Sciences Network (ESNET), and the ARPANET.”329 In other words, the organization that would build and manage the NSFNET would not only use DARPA protocols, but ensure interoperability with the Internet community. This meant integrating with the system of unique identifier administration that was, at the time, organized by DARPA and DCA. At the time, DARPA and DCA were the sources of legal authority under which the Internet community organized its work, and the Internet Activities Board (see below) was organized to support decision-making at DARPA.

325 Karen D. Frazer, “NSFNET: A Partnership for High-Speed Networking Final Report 1987-1995” (MERIT, 1995), https://web.archive.org/web/20150210181738/http://www.merit.edu/about/history/pdf/NSFNET_final. pdf. The NSFNET top-level network existed in the 5 May 1986 host table at SRI’s DDN NIC, but not the February 5 table of the same year (suggesting the period in which it. Takizawa, Hosts.txt. 326 David Farber, “Network Program Advisory Group,” ConneXions 1, no. 8 (December 1987): 13. 327 Network Technical Advisory Group, “Requirements for Internet Gateways - Draft.” 328 “Project Solicitation for Management and Operation of the NSFNET Backbone Network” (National Science Foundation, 1987). 329 Ibid.; J. Y. Yu and H. W. Braun, “Routing between the NSFNET and the DDN,” 1989, https://www.rfc-editor.org/rfc/pdfrfc/rfc1133.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 78

This change of authority for oversight of the federal networking was mandated by the High POLICY SETTING ORGANIZATIONS (1968-2017) Performance Computing Act (HPCA) of 1991, which created the National Research and Education Network (NREN), a term for all the federally-funded networks running Internet protocols (NREN’s origins date to planning in the late 1980s).330 The HPCA also centered authority for administration of the civilian Internet under the NSF, instructing it to “serve as the primary source of information on access to and use of the Network” and to "upgrade the [NSFNET], assist regional networks to upgrade their capabilities, and provide other federal departments and agencies the opportunity to connect to the [NSFNET]." The NSF understood this to mean that it was now necessary for NSF to assume responsibility for provision of its own registration services for the user community.”331 DARPA, meanwhile, was tasked with further protocol development.332 The NREN and the NSF’s responsibilities were further authorized in the U.S. President’s fiscal 1992 budget and authorized with the December 1991 passage of the U.S. federal budget.333

These changes between 1990 and late 1991 resulted in the move, documented in Section 3, of SRI’s DDN NIC functions to Network Solutions, Inc. (NSI). However, despite the appearance of a new contractor, this shift had the effect of formalizing the organizational configuration of unique identifier administration. The Federal Research Internet Coordinating Committee (FRICC) organized the transition, as documented below:

As a result of a recompetition for services, GSI has replaced SRI as the contractor to DCA for provision of registration services and network and host machine address assignment. Accordingly, the DCA agrees to provide address registration services for

330 George E. Brown, Management of NSFNET. Hearing before the Subcommittee on Science of the Committee on Science, Space, and Technology, U.S. House of Representatives, One Hundred Second Congress, Second Session (Washington DC: Congress of the U.S., 1992), https://eric.ed.gov/?id=ED350986. 331 Office of the Inspector General, “Review of NSFNET.” 332 Gore and Albert, High-Performance Computing Act of 1991. 333 In 1992, the U.S. Federal Government clarified the NSF’s authority with respect to its operation of the National Science Foundation Network (NSFNET) backbone. The Scientific and Advanced-Technology Act of 1992 authorized “the NSF to foster and support access by the research and education communities to computer networks which may be used substantially for additional purposes if this will tend to increase the networks' overall capabilities to support research and education in science and engineering. The gradual commercialization and eventual privatization of the Internet backbone, however, did not directly impact the administration of unique identifiers. Barbara Mikulski, “Scientific and Advanced-Technology Act of 1992,” Pub. L. No. 1146 (1992), https://www.congress.gov/bill/102nd-congress/senate-bill/1146. See also Arthur Oldehoeft, “NISTIR 4734, Security Policy for Use of National Research Educational Network | CSRC” (National Institute of Standards and Technology, February 1992), https://csrc.nist.gov/publications/detail/nistir/4734/archive/1992-02-01.

The Creation and Administration of Unique Identifiers, 1967-2017 79

POLICY SETTING ORGANIZATIONS (1968-2017) the NSF community of users on an interim basis while the NSF implements its own solicitation for long term registration and information services. This will insure continuity of this critical operation for the entire Internet community.334

In 1992, the Scientific and Advanced-Technology Act expanded NSF authority along different lines, granting NSFNET the right to carry certain commercial traffic.335

The National Science Foundation contract with Network Solutions, Inc. provides more insight into the relationship between the IANA at USC-ISI, and the unique identifier administration for the civilian Internet.336 The contract specified that NSI would provide its services “in accordance with the provisions of RFC 1174,”337 which included specifically:

[T]he Internet system has employed a central Internal [sic] Assigned Numbers Authority (IANA) for the allocation and assignment of various numeric identifiers needed for the operation of the Internet. The IANA function is currently performed by the University of Southern California's Information Sciences Institute. The IANA has the discretionary authority to delegate portions of this responsibility and, with respect to numeric network and autonomous system identifiers, has lodged this responsibility with an Internet Registry (IR).338

The NSF’s contract with NSI is significant in its specific reference to RFC 1174, which contained two IAB “Recommended Policy” statements. Previously, groups like the IAB would have their recommendations implemented through a DARPA or DCA contract. In this case, published policy recommendations from the Internet Activities Board were included in contracts for the administration of unique identifiers.

334 William Decker, “Internet Related Registration Services” (National Science Foundation Division Of Computer and Network Systems, February 1, 1992), https://nsf.gov/awardsearch/showAward?AWD_ID=9201059&HistoricalAwards=false. 335 Mikulski, Scientific and Advanced-Technology Act of 1992. 336 GSI subcontracted Network Solutions Inc. for identifier administration as part of its contract with DCA for the Defense Data Network. For the civilian Internet, however, NSF contracted NSI directly. 337 National Science Foundation, “NSF9224--Network Information Services Manager(s) for NSFNET and NREN.” 338 Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.”

The Creation and Administration of Unique Identifiers, 1967-2017 80

POLICY SETTING ORGANIZATIONS (1968-2017) 5.4
FEDERAL RESEARCH INTERNET COORDINATING COMMITTEE (FRICC) (1987-90), FEDERAL NETWORKING COUNCIL (FNC) (1990-97) One year into the NSF’s operation of the NSFNET, several U.S. Federal agencies formed the Federal Research Internet Coordinating Committee, or FRICC, under the Federal Coordinating Committee for Science, Engineering, and Technology (FCCSET).339 Its initial member agencies were DARPA, NSF, NASA, the U.S. Department of Energy (DOE), and the U.S. Department of Health and Human Services (DHHS) (Wolff 1988); by 1992 the FRICC had sixteen federal members, as well as an advisory committee consisting of the IAB, national research labs, higher education, and the private sector.340

The purpose of the FRICC was to coordinate both planning and implementation of the federal agencies’ networks, and thus the civilian Internet. The FCCSET was a logical home for this committee as its function was to “consider problems and developments in the fields of science, engineering, and technology and related activities affecting more than one federal agency, and shall recommend policies and other measures” for member agencies to implement.341FRICC permitted coordinated decision-making between federal agencies.

FCCSET was first created in 1976 alongside the executive-level U.S. Office of Science and Technology Policy (OSTP), was chaired by the OSTP director, and was the logical home for U.S. federal policy-making authority with respect to Internet identifiers.342 FCCSET did not possess budgetary or other policy authority over its member agencies, but instead acted as a forum for coordination. In this capacity, FCCSET was used to set policy for the civilian components of the Internet. The more ad hoc nature of the FRICC was replaced in 1990 by the Federal Networking Council, or FNC, which performed the same functions but in a more structured manner, with a larger number of member agencies and work structured into working groups.343 The creation of this working group structure was also under the FCCSET’s authority.

339 Phillip G. Gross and Gregory M. Vaudreuil, “Proceedings of the Seventeenth Internet Engineering Task Force” (Corporation for National Research Initiatives, May 1990). 340 Arthur E. Oldehoeft, “Foundations of a Security Policy for Use of the National Research and Educational Network” (Gaithersburg, MD: National Institute of Standards and Technology, 1992). 341 “Establishment, Membership, and Functions of Council,” Pub. L. No. 104-127, § 6651, 42 U.S. Code (1976), https://www.law.cornell.edu/uscode/text/42/6651. 342 Olin Teague, “An Act to Establish a Science and Technology Policy for the United States, to Provide for Scientific and Technological Advice and Assistance to the President, to Provide a Comprehensive Survey of Ways and Means for Improving the Federal Effort in Scientific Research and Information Handling, and in the Use Thereof, to Amend the National Science Foundation Act of 1950, and for Other Purposes,” Pub. L. No. 10230 (1976), https://www.congress.gov/bill/94th-congress/house-bill/10230. Executive Order 12039 refined FCCSET by tasting it with advising and assisting OSTP. 343 Gross and Vaudreuil, “Proceedings of the Seventeenth Internet Engineering Task Force.”

The Creation and Administration of Unique Identifiers, 1967-2017 81

Its 1990 role in the coordination of policy-setting for the Internet was summarized by Cerf POLICY SETTING ORGANIZATIONS (1968-2017) as follows:

The FNC is the Federal Government's body for coordinating the agencies that support the Internet. It provides liaison to the Office of Science and Technology Policy (headed by the President's Science Advisor) which is responsible for setting science and technology policy affecting the Internet. It endorses and employs the existing planning and operational activities of the community-based bodies that have grown up to manage the Internet in the United States.344

Further coordination was managed between the FNC and its international counterparts in the Coordinating Committee for Intercontinental Research Networks (CCIRN).345

The coordination function of the U.S. Federal Networking Council (FNC) was utilized to address multiple issues concerning IP address space, such as in the creation of RIRs346 and the decision to deploy Classless Inter-Domain Routing (CIDR).347 In both cases, the FNC would support recommendations from the Internet community, which would in turn be implemented by its member organizations. The FNC’s coordinating function was also apparent in decisions surrounding the DNS, such as when the FNC set policy for U.S. Government domain names.348

In 1994, the Internet Architecture Board (IAB) worked under the “auspices” of the FNC,349 and thus under the auspices of the consensus of its member agencies. Put another way, the members of FNC agreed to coordinate policies so to the extent that IAB enjoyed the support of FNC, IAB's policy would have the force of U.S. Government authority. Above specific

344 Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.” 345 “Federal Networking Council Charter,” September 20, 1995, https://www.nitrd.gov/fnc/FNC_Charter.pdf. 346 Gerich, “Guidelines for Management of IP Address Space.” 347 Mark Knopper and S. Richardson, “Aggregation Support in the Nsfnet Policy-Based Routing Database,” 1993, https://www.rfc-editor.org/rfc/pdfrfc/rfc1482.txt.pdf. 348 Federal Networking Council, “U.S. Government Internet Domain Names,” 1995, https://www.rfc- editor.org/rfc/pdfrfc/rfc1811.txt.pdf. 349 C. Huitema, “Charter of the Internet Architecture Board (IAB),” 1994, https://www.rfc- editor.org/rfc/pdfrfc/rfc1601.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 82

policy issues, the FRICC and FNC were responsible for developing broader policy. For POLICY SETTING ORGANIZATIONS (1968-2017) example, by 1989 the chairman of the FCCSET Subcommittee on Networking requested that FRICC develop a “coordinated, multi-agency implementation plan for the National Research Network.”350

In 1997, the chartering organization for the FNC remained within the U.S. executive branch but was then transferred to the recently formed National Science and Technology Council (NSTC), which was created by Executive order in 1993. Specifically, the FNC operated under the Committee on Computing, Information and Communications (CCIC). The FNC was de-chartered on 1 October 1997, with some of its functions by then carried out by newer sub-organizations of the same Committee on Computing, Information, and Communications (of the NSTC).

5.5
U.S. DEPARTMENT OF COMMERCE (DOC) (1997-2016) President Clinton's 1 July 1997 Memorandum on Electronic Commerce Executive Order directed the U.S. Secretary of Commerce to "support efforts to make the governance of the domain name system private and competitive and to create a contractually based self-regulatory regime" for its administration.351 The order implemented “A Framework For Global Electronic Commerce,” developed by Ira Magaziner at President Clinton’s request, which stated that the administration “has formed an interagency working group under the leadership of the Department of Commerce” to review proposals for a new system of DNS administration, and will consider “in light of public input, (1) what contribution government might make, if any, to the development of a global competitive, market-based system to register Internet domain names, and (2) how best to foster bottom-up governance of the Internet.”352

350 J. B. Hoy et al., “Computer Security: Virus Highlights Need for Improved Internet Management” (General Accounting Office, Information Management and Technology Division, June 1989), http://www.dtic.mil/docs/citations/ADA344751. 351 William J. Clinton, “Memorandum on Electronic Commerce,” Weekly Compilation of Presidential Documents Volume 33 Issue 27 (Monday, July 7, 1997) July 1, 1997, U.S. Government Publishing Office, https://www.gpo.gov/fdsys/pkg/WCPD-1997-07-07/html/WCPD-1997-07-07-Pg1006-2.htm. 352 Ibid.

The Creation and Administration of Unique Identifiers, 1967-2017 83

In subsequent government documents and actions, identified below, this plan was further POLICY SETTING ORGANIZATIONS (1968-2017) elaborated to include unique identifiers in general.353 The Executive order identified a preexisting “Interagency Working Group” that would now evaluate proposals from the private sector, and report back to both the President and Vice President. The content of the feedback it received,354 and the 1998 “Statement of Policy on the Management of Internet Names and Addresses” subsequently published by NTIA, both dealt with unique identifiers as the IANA functions, and not only DNS.355

The National Telecommunications and Information Administration published its “Request for Comments in the Matter of Registration and Administration of Internet Domain Names,” shortly after the Clinton Executive Order. The document elaborated the U.S. Federal Government’s strategy with respect to the future policy-making authority and management of unique identifiers:

The United States Government played a central role in the initial development, deployment, and operation of domain name registration systems, and through the NSF agreement as well as Defense Advanced Research Projects Agency (DARPA) agreement(s) continues to play a role.356

It also put 28 questions for Public Comment, on matters of organizational framework, the creation of new gTLDs, policies for registries, and trademark issues. In framing these questions, the NTIA noted that the private sector should develop global, evolutionary, stable, open, and consensus-based governance mechanisms. What is more:

Competition in and expansion of the domain name registration system should be encouraged. Conflicting domains, systems, and registries should not be permitted to jeopardize the interoperation of the Internet, however. The addressing scheme should not prevent any user from connecting to any other site.357

353 This is also in keeping with standard interpretation of Executive Orders. See Erica Newland, “Executive Orders in Court,” The Yale Law Journal 124, no. 6 (April 2015): 1836–2201, https://www.yalelawjournal.org/note/executive-orders-in-court. 354 Early draft proposals on this topic of transitioning unique identifier administration, for example, focused on the Domain Name System but also included the broader IANA functions.See Jon Postel, “New Registries and the Delegation of International Top Level Domains” (University of Southern California Information Sciences Institute, 1996), https://tools.ietf.org/html/draft-postel-iana-itld-admin-01. 355 Subsequent publications also referred to the IANA functions as “key Internet domain name functions.” Office of Public Affairs, “NTIA Announces Intent to Transition Key Internet Domain Name Functions.” 356 National Telecommunications and Information Administration, “Request for Comments on the Registration and Administration of Internet Domain Names,” July 2, 1997, https://www.ntia.doc.gov/federal-register-notice/1997/request-comments-registration-and-administration- internet-domain-names. 357 Ibid.

The Creation and Administration of Unique Identifiers, 1967-2017 84

Following public discussion, on 30 January 1998, the NTIA created what is now known POLICY SETTING ORGANIZATIONS (1968-2017) as the Green Paper.358 It was published in the U.S. Federal Registry on 20 February 1998, and received over 650 comments by the time the comment period ended on 23 March 1998.359 The green paper noted that the Internet is an “outgrowth” of U.S. Government research and development “carried out under agreements with the Defense Advanced Research Projects Agency (DARPA), the National Science Foundation (NSF) and other U.S. research agencies.”

It identifies IP address assignment, domain registration, the DNS root, and protocol assignment as all being carried out by entities under either DARPA or the NSF–and as the functions that would eventually be completely transitioned out of the government and to a new organization.

This new organization would “manage the coordinated functions” of the Internet. Set to evolve over time, its initial “authority” would be clustered in four areas:

1.
to set policy for and direct the allocation of number blocks to regional number registries for the assignment of Internet addresses; 2.
to oversee the operation of an authoritative root server system; 3.
to oversee policy for determining, based on objective criteria clearly established in the new organization's charter, the circumstances under which new top-level domains are added to the root system; 4.
to coordinate the development of other technical protocol parameters as needed to maintain universal connectivity on the Internet.360

Four months later, on 10 June 1998, the NTIA released a statement of policy, published in the U.S. Federal Register, entitled “Management of Internet Names and Addresses.”361 Known as the “White Paper,” it reflected four months of feedback from the Internet community, as well as business and community groups, recognized in the document as “private sector Internet stakeholders.”362

358 National Telecommunications and Information Administration, “Statement of Policy on the Management of Internet Names and Addresses,” Federal Register Notices (Washington, DC: National Telecommunications and Information Administration, June 5, 1998), https://www.ntia.doc.gov/federal- register-notice/1998/statement-policy-management-internet-names-and-addresses. 359 Department of Commerce, “Registration and Administration of Internet Domain Names -- Summary of Comments,” August 18, 1997, https://www.ntia.doc.gov/other-publication/1997/registration-and- administration-internet-domain-names-summary-comments-docket. 360 National Telecommunications and Information Administration, “Statement of Policy on the Management of Internet Names and Addresses.” 361 National Telecommunications and Information Administration, “Management of Internet Names and Addresses,” June 10, 1998, https://www.icann.org/resources/unthemed-pages/white-paper-2012-02-25-en. 362 It also drew on Federal Statutes 15 (Commerce and Trade) and 47 (Telecommunications) of the United States Code.

The Creation and Administration of Unique Identifiers, 1967-2017 85

The White Paper provided a guiding framework within which a new corporation would be POLICY SETTING ORGANIZATIONS (1968-2017) created, and to which responsibility over unique identifier administration would eventually be transitioned. NTIA requested a workable proposal from the Internet community by 30 September 1998, when NSF’s agreement with NSI would expire. After multiple proposals and extensive negotiation, the U.S. Department of Commerce created a MOU with the ICANN on 25 November 1998, in which the United States agreed with ICANN to collaborate to design, develop, and test the mechanisms, methods, and procedures that should be in place and the steps necessary to transition management responsibility for Internet domain name system (DNS) functions now performed by, or on behalf of, the United States Government to the private sector.363

The NTIA officially designated ICANN as the not-for-profit NewCo within the cooperative agreement on 26 February 1999.364

As noted above, the White House Executive Order occurred prior to the dissolution of the Federal Networking Council. At the time, DARPA continued to fund the IANA functions at USC-ISI, and the NSF funded the IANA’s operations through NSI’s InterNIC. Despite this continuity in U.S. federal authority, the 1990s, and especially the mid- to late-1990s, proved controversial for Internet governance. During this period, the Internet community focused its efforts to internationalize the IANA functions beyond its initial home in the U.S., in advance of the creation of an international organization that would, in turn, serve the global community. This trend was visible in 1990, when the IAB recommended to the FNC that it remove the distinction between connected and unconnected networks, and create regionally based Internet registries.365 In 1992, the FNC, Intercontinental Engineering and Planning Group (IEPG), and RIPE supported a proposal authored by Elise Gerich of Merit,366 which built on RFC 1174 and presented a more detailed regionalized registry plan. The proposal’s justification for the plan included the following:

363 National Telecommunications and Information Administration and Internet Corporation for Assigned Names and Numbers, “Memorandum of Understanding Between the U.S. Department of Commerce and the Internet Corporation for Assigned Names and Numbers,” November 25, 1998, https://www.ntia.doc.gov/page/1998/memorandum-understanding-between-us-department-commerce- and-internet-corporation-assigned-. 364 J. Beckwith Burr and National Telecommunications and Information Administration to David Graves, “ICANN Designated as ‘NewCo’ for Certain Purposes under the Cooperative Agreement,” February 26, 1999, https://www.ntia.doc.gov/page/1999/icann-designated-newco-certain-purposes-under-cooperative- agreement. 365 Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.” 366 Gerich, “Guidelines for Management of IP Address Space.”

The Creation and Administration of Unique Identifiers, 1967-2017 86

The major reason to distribute the registration function is that the Internet serves POLICY SETTING ORGANIZATIONS (1968-2017) a more diverse global population than it did at its inception. This means that registries which are located in distinct geographic areas may be better able to serve the local community in terms of language and local customs. While there appears to be wide support for the concept of distribution of the registration function, it is important to define how the candidate delegated registries will be chosen and from which geographic areas.367

Efforts to better serve the “more diverse global population” were underway in the early 1990s, mirroring the rapidly globalizing culture that characterized the Internet during this period. Nonetheless, the IANA functions were still moored in the U.S., with a combination of NSF and DARPA funding and authority in the early 1990s, and with the U.S. Department of Commerce jurisdiction by 1997. But despite the IANA functions’ continued US foundation, the Internet community–with U.S. authorization and support–was steadily globalizing its execution. What remained was the systematization of the Regional Internet Registries, and the creation of a new organizational home that aligned with the new, global realities.

5.6
REGIONAL INTERNET REGISTRIES (RIRs) (1992-2017) The Regional Internet Registries (RIRs) have been delegated the responsibility for managing the allocation, registration, and implementation of global policies for the IP addresses and Autonomous System Numbers within their respective regions, along with developing regional policy according to their own policy definition processes. The five RIRs are the Réseaux IP Européens Network Coordination Centre (RIPE NCC, operational in 1992), the Asia-Pacific Network Information Centre (APNIC, operational 1993), the American Registry for Internet Numbers (ARIN, operational 1997), the Latin America and Caribbean Network Information Center (LACNIC, operational 2002), and the African Network Information Center (AFRINIC, operational 2005).

The organizational roots of RIRs date to a 1990 recommendation from the IAB to the FNC documented in RFC 1174. Namely, that IP address and ASNs administration be distributed to delegated registry authorities.368 The then-current Internet registry, the SRI NIC, would continue to serve as the registry for areas of the world not covered by a delegated registry authority. Delegation of authority, however, did not begin until after NSI took over from SRI and RIPE-NCC was established.

367 Ibid, 2. 368 Cerf, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.”

The Creation and Administration of Unique Identifiers, 1967-2017 87

In 1993, the FNC approved the IAB’s proposal,369 as did international networking POLICY SETTING ORGANIZATIONS (1968-2017) representatives via the Intercontinental Engineering Planning Group (IEPG)370 and the RIPE NCC. The IEPG was a body of the Coordinating Committee for Intercontinental Research Networking (CCIRN), and performed a parallel technical advisory function as the Federal Engineering Planning Group of the FNC.371 After extensive consultation, the IEPG also approved further specification of the “delegated registry authorities,” namely, that “distributed regional registries” would “work with IANA and the [Internet Registry]” to assign identifiers and develop policy for their respective regions. Approval by the FNC in the U.S, meant that the relevant policy-making U.S. federal organizations approved of the Internet community’s creation of the RIRs. RIR guidelines and policy were published in 1993,372 and in 1996 and 2013, the Internet community published a set of further goals and guidelines.373 Operational aspects of the RIRs are noted in Section 3.

RIRs utilized Classless Interdomain Routing (CIDR)374 as an important technical foundation of their operation.375 As described above, the original IP specifications used an 8-bit network prefix, that is, the segment of the address that identified the network, with the remainder specifying the host interface address. Classful addressing, also described above, created different sized classes of networks. The address classes also proved too rigid for the increasing global size of the Internet and the IETF introduced CIDR to permit flexible allocation, partitioning, and sub-allocation of IP address blocks, as well as route aggregation, as described above.

The agreed-upon functions and operational practices of the RIR system were documented in RFC 2050,376 in 1996. Most recently updated in RFC 7020 in 2013, the RIRs pursue three goals for the global address space: conservation, aggregation or, routability, and registration. Conservation refers to the fair distribution of the address space that prevents hoarding, meets end-user needs, and maximizes the address space lifespan. Aggregation refers to the

369 Gerich, “Guidelines for Management of IP Address Space.” 370 Barry Leiner, “Globalization of the Internet,” in Internet System Handbook, ed. Daniel C. Lynch and Marshall T. Rose (Addison-Wesley, 1993). 371 Robert Braden, “IAB Message: OSI Registration,” Internet Monthly Reports, no. 8 (August 1990). The CCIRN is a forum in which coordinates international development of networking. “Coordinating Committee for Intercontinental Research Networking.” n.d. Union of International Associations. Accessed September 22, 2019. https://uia.org/s/or/en/1100038180. 372 Gerich, “Guidelines for Management of IP Address Space.” 373 Hubbard et al., “Internet Registry IP Allocation Guidelines.” 374 Fuller et al., “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy.” 375 Gerich, E. 1992. “Guidelines for Management of IP Address Space.” RFC 1366. https://www.rfc- editor.org/info/rfc1366. 376 Hubbard et al., “Internet Registry IP Allocation Guidelines.”

The Creation and Administration of Unique Identifiers, 1967-2017 88

hierarchical distribution of addresses to allow for route aggregation. Registration encompasses POLICY SETTING ORGANIZATIONS (1968-2017) the administrative work necessary to ensure uniqueness.377

While RIRs agreed between themselves on global IP address policy and represented their own regions, they also agreed that “Regional IRs are established under the authority of the IANA. This requires consensus within the Internet community of the region. A consensus of Internet Service Providers in that region may be necessary to fulfill that role.”378 With the creation of ICANN, RIRs signed a joint Memorandum of Understanding to create the Address Supporting Organization (ASO).379 Today, global policies that impact number resources, as administered by Public Technical Identifiers, are ratified by the ICANN Board after they are agreed upon by all five RIRs.

RIRs share common features. They self-govern with member-elected boards, which provide oversight and guidance. Like ICANN, they also have mechanisms in place to prevent capture. Their membership is open to anyone interested in number resources, and ranges from end-users to ISPs.380

5.7
IANA FUNCTIONS AND THE INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS (ICANN) (1998-2017) The creation of ICANN was accompanied by new relationships between it and existing organizations. This section consists of two parts which address these changes.

The first part (5.7.1) documents ICANN’s IANA Functions Stewardship Transition Agreements between ICANN and other organizations. These agreements provided the basis for the IANA stewardship transition, which led to a strengthening of ICANN accountability and the termination of its IANA functions contract with the U.S. Government. The successful transition occurred when the NTIA was satisfied with the proposal from ICANN for the operation of the IANA functions.

377 Ibid. 378 Ibid. 379 Daniel Karrenberg et al., “Development of the Regional Internet Registry System,” The Internet Protocol Journal 4, no. 4 (2001): 17–29. 380 “Regional Internet Registries,” The Number Resource Organization, 2018, https://www.nro.net/about/rirs/.

The Creation and Administration of Unique Identifiers, 1967-2017 89

The second part (Section 5.7.2) addresses the stewardship transition process itself, as well as POLICY SETTING ORGANIZATIONS (1968-2017) the pre-transition implementation agreements with the IANA Partners, which determine policy in their portion of the IANA functions: the numbers community operating through Regional Internet Registries; the names community operating through ICANN; the protocol parameters community operating through the IETF, IESG, and IAB. Prior to ICANN, these partner communities had a great deal of de facto authority but did not possess the formal policy-setting authority that they now have alongside ICANN.381

5.7.1
IANA FUNCTIONS STEWARDSHIP TRANSITION AGREEMENTS The intention to perform what would become known as the IANA functions stewardship transition (or “IANA transition”) was first described in President Clinton’s July 1997 Executive Order, “Memorandum on Electronic Commerce.” ICANN was formed by members of the Internet community, and recognized by the U.S. Department of Commerce (DOC), with the intention of developing its organizational structures so that the private sector management envisioned in the 1997 Executive order and "A Framework For Global Electronic Commerce" could be achieved. The framework and Executive order charged the DOC with coordinating activities that lead to the DOC’s recognition of ICANN. The framework also cited NTIAas part of the DOC and an important participant in the described privatization activities. To achieve the goal of private sector management, ICANN established multiple agreements with not only the DOC, but also with USC-ISI, the NTIA, and NSI.

5.7.1.1 DOC-ICANN MEMORANDUM OF UNDERSTANDING (MOU), JOINT PROJECT AGREEMENT (JPA), AND AFFIRMATION OF COMMITMENTS (AOC) For the first fourteen months, ICANN operated through an MOU with NTIA signed in November 1998.382 Amendments followed in 1999, 2000, twice in 2001, 2002, 2003, and 2006.383 The first MOU established ICANN’s responsibilities and its relationship with the DOC, and the successive amendments modified the relationship as ICANN progressed toward the Transition.

The first MOU established, amidst a detailed framework, a joint framework between DOC and ICANN:

381 Prior to ICANN’s creation, the IAB, IETF, IESG, and RIRs exercised a great deal of autonomy, and enjoyed influence over policy. Nonetheless they were organized by federal policy-setting authorities. 382 National Telecommunications and Information Administration and Internet Corporation for Assigned Names and Numbers, “Memorandum of Understanding Between the U.S. Department of Commerce and the Internet Corporation for Assigned Names and Numbers.” 383 Internet Corporation for Assigned Names and Numbers and Department of Commerce, “Memorandum of Understanding/Joint Project Agreement with U.S. Department of Commerce,” 1998-2006, https://www.icann.org/resources/pages/agreements-en.

The Creation and Administration of Unique Identifiers, 1967-2017 90

In the DNS Project, the parties will jointly design, develop, and test the mechanisms, POLICY SETTING ORGANIZATIONS (1968-2017) methods, and procedures to carry out the following DNS management functions:

A.
Establishment of policy for and direction of the allocation of IP number blocks; B.
Oversight of the operation of the authoritative root server system; C.
Oversight of the policy for determining the circumstances under which new top level domains would be added to the root system; D.
Coordination of the assignment of other Internet technical parameters as needed to maintain universal connectivity on the Internet; and E.
Other activities necessary to coordinate the specified DNS management functions, as agreed by the Parties.384

This identification of the naming, numbering, and protocol parameter areas of the IANA functions were used as the framework for the contractor requirements, effectively ICANN’s statement of work, in the subsequent contracts. The MOU also identified the foundational principles of the DOC-ICANN agreement: stability;385 competition;386 private, bottom-up coordination;387 and representation.388

384 National Telecommunications and Information Administration and Internet Corporation for Assigned Names and Numbers, “Memorandum of Understanding Between the U.S. Department of Commerce and the Internet Corporation for Assigned Names and Numbers.” 385 “This Agreement promotes the stability of the Internet and allows the Parties to plan for a deliberate move from the existing structure to a private-sector structure without disruption to the functioning of the DNS. The Agreement calls for the design, development, and testing of a new management system that will not harm current functional operations.” 386 “This Agreement promotes the management of the DNS in a manner that will permit market mechanisms to support competition and consumer choice in the technical management of the DNS. This competition will lower costs, promote innovation, and enhance user choice and satisfaction.” 387 “This Agreement is intended to result in the design, development, and testing of a private coordinating process that is flexible and able to move rapidly enough to meet the changing needs of the Internet and of Internet users. This Agreement is intended to foster the development of a private sector management system that, as far as possible, reflects a system of bottom-up management.” 388 “This Agreement promotes the technical management of the DNS in a manner that reflects the global and functional diversity of Internet users and their needs. This Agreement is intended to promote the design, development, and testing of mechanisms to solicit public input, both domestic and international, into a private-sector decision making process. These mechanisms will promote the flexibility needed to adapt to changes in the composition of the Internet user community and their needs.”

The Creation and Administration of Unique Identifiers, 1967-2017 91

The seventh amendment to the DOC-ICANN MOU, signed in September 2006, was a Joint POLICY SETTING ORGANIZATIONS (1968-2017) Project Agreement (JPA), which functioned as an extension of the original MOU.389 It was in part the result of a public consultation process carried out by the NTIA. The JPA represented a major simplification of the MOU, in part due to how the JPA also could point to ICANN bylaws rather than outline individual rights and responsibilities. It also stipulated reports and a midpoint view of ICANN’s progress toward the eventual stewardship transition. The JPA expired on September 30, 2009, and was replaced by the Affirmation of Commitments (AOC).390 The AOC described much of the relationship between ICANN and the DOC that was contained in the previous JPA, MOU, and MOU amendments:

This document affirms key commitments by DOC and ICANN, including commitments to: (a) ensure that decisions made related to the global technical coordination of the DNS are made in the public interest and are accountable and transparent; (b) preserve the security, stability and resiliency of the DNS; (c) promote competition, consumer trust, and consumer choice in the DNS marketplace; and (d) facilitate international participation in DNS technical coordination.391

Unlike the JPA and MOU, however, the AOC was more of a description of ICANN rights and responsibilities, and documented a relationship between two parties of increasingly equal stature. ICANN and the NTIA formally ended the AOC in January 2017.392

389 Internet Corporation for Assigned Names and Numbers and Department of Commerce, “Memorandum of Understanding/Joint Project Agreement with U.S. Department of Commerce,” 1998-2006, https://www.icann.org/resources/pages/agreements-en. 390 Internet Corporation for Assigned Names and Numbers and U.S. Department of Commerce. 2009. “AFFIRMATION OF COMMITMENTS BY THE UNITED STATES DEPARTMENT OF COMMERCE AND THE INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS.” https://www.icann.org/resources/pages/affirmation-of-commitments-2009-09-30-en. 391 Ibid. 392 Strickling, Lawrence E., and National Telecommunications and Information Administration. Letter to Stephen D. Crocker. January 6, 2017. https://www.icann.org/en/system/files/correspondence/strickling- to-crocker-06jan17-en.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 92

5.7.1.2 USC-ICANN TRANSITION AGREEMENT POLICY SETTING ORGANIZATIONS (1968-2017) Prior to ICANN’s creation, the IANA functions were performed by USC-ISI under a DARPA contract originally in effect from July 1995 until July 1999.393 Prior to the end of this contract, USC-ISI entered into an agreement with ICANN to transfer the performance of the IANA functions, which began officially on 24 December 1998.394 The agreement reads in part that ICANN will assume responsibility from IANA for the:

(a) Establishment, oversight, and implementation of policy for allocation and assignment of IP address blocks, including delegation of assignment responsibilities to regional address registries;

(b) Establishment, oversight, and implementation of policy for the Internet Domain Name System ("DNS"), including delegation of responsibilities to DNS registries and registrars;

(c) Assignment of technical protocol parameter numbers and maintenance of assigned values; and

(d) Oversight of the operation of the Internet root server system.395

5.7.1.3 NTIA-NIST-ICANN COOPERATIVE RESEARCH AND DEVELOPMENT AGREEMENT (CRADA) In 1999, ICANN entered into an agreement with the U.S. DOC, the latter represented both by the NTIA and the U.S. National Institute for Standards and Technology (NIST).396 The agreement created a project titled, “Improvements to Management of the Internet Root Server System,” under which “the parties have been collaborating on a study and process for making the management of the Internet (DNS) root server system more robust and secure.”397

393 Office, U. S. Government Accountability, “Department of Commerce--Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions.” 394 Section Department of Commerce and Internet Corporation for Assigned Names and Numbers, “Contract for the Performance of the IANA Function,” August 11, 2006, https://www.ntia.doc.gov/files/ntia/publications/ianacontract_081406.pdf3.6. 395 University of Southern California and Internet Corporation for Assigned Names and Numbers, “USC/ICANN Transition Agreement.” 396 Internet Corporation for Assigned Names and Numbers and Department of Commerce, “Cooperative Research & Development Agreement,” 1999, https://www.icann.org/resources/unthemed-pages/crada- 2012-02-25-en. 397 Internet Corporation for Assigned Names and Numbers and Department of Commerce, “Public Summary of Reports Provided Under Cooperative Research and Development Agreement CN-1634 Between the Internet Corporation for Assigned Names and Numbers and the United States Department of Commerce,” March 14, 2003, https://www.icann.org/resources/unthemed-pages/crada-report- summary-2003-03-14-en.

The Creation and Administration of Unique Identifiers, 1967-2017 93

The 1999 agreement was also extended in 2000 and 2001. The work resulted in three documents. POLICY SETTING ORGANIZATIONS (1968-2017) The first, released in November 2002, described the then-current architecture of the root server system. The second, released in December 2002, proposed security enhancements for the root server system, as well as a plan and timeline for a transition to the proposed system. The third, released in March 2003, was a public summary of both reports.398

5.7.1.4 DOC-ICANN INTERNIC® AGREEMENT After the creation of ICANN, the DOC and ICANN entered into a 2001 agreement that gave ICANN the non-exclusive, worldwide, and royalty-free right to use the InterNIC service mark.399 As the DOC owned the InterNIC service mark, it provided ICANN the right to use it in providing services commonly associated with the mark, without relinquishing its rights to it.

5.7.1.5 DOC-ICANN IANA FUNCTIONS CONTRACTS The relationship between ICANN and the NTIA had two separate threads. One began as a MOU, which was replaced with a JPA, both of which were joint expressions of the agreement but which were eventually replaced by a confirmation of their commitments by ICANN and DOC. Separately from these, the NTIA issued a series of contracts to govern the provision of specific services. ICANN entered into its first contract with NTIA in February 2000.400 The contract referenced both ICANN’s original response to the DOC’s RFQ,401 as well as the transition agreement between ICANN and USC-ISI for the IANA functions, as documented below. ICANN’s response identified a five part work plan, consisting of:

1.
Coordination of the assignment of technical protocol parameters 2.
Administrative functions associated with root zone management 3.
Allocation of IP address blocks 4.
Refinements during course of contract 5.
Other services, including performance reporting

398 Ibid. 399 Department of Commerce and Internet Corporation for Assigned Names and Numbers, “License Agreement Concerning InterNIC,” January 2001, https://www.icann.org/resources/unthemed- pages/internic-license-2001-01-08-en. 400 Internet Corporation for Assigned Names and Numbers and Department of Commerce, “Contract Between ICANN and the United States Government for Performance of the IANA Function,” February 8, 2000, https://www.ntia.doc.gov/files/ntia/publications/ianacontract.pdf. 401 Internet Corporation for Assigned Names and Numbers, “Proposal to the U.S. Government to Perform the IANA Function,” 2000, https://archive.icann.org/en/general/iana-proposal-02feb00.htm.

The Creation and Administration of Unique Identifiers, 1967-2017 94

Tasks 1-3 summarize the three IANA functions, while “refinements during course of contract” POLICY SETTING ORGANIZATIONS (1968-2017) refers to the plan outlined in the original MOU to (as noted above) “design, develop, and test the mechanisms, methods, and procedures that should be in place and the steps necessary to transition management responsibility for Internet domain name system.” All functions historically performed through IANA were either implicitly or explicitly incorporated into the responsibilities of ICANN in performing the IANA functions. This included the use of "Other services" provisions in the contracts between NTIA and ICANN that allowed for flexibility in the identification and delivery of the IANA functions as needed to properly fulfill the contract, even if all parts of the work were not set out specifically in the contract. Whether items were set out specifically or not, the full range of ICANN work in performing the IANA functions became understood to be the expected performance level.

Furthermore, the IANA functions preceded the creation of ICANN and the contract with NTIA. In consequence, the "IANA functions" reference in the contract drew upon historical precedent and knowledge of those functions even if they were not explicitly stated in the contract terms. The contract also contained “performance exclusions,” barring ICANN from making “substantive changes” by way of “authorizing modifications, additions, or deletions” from the root zone file or “established policy associated with the performance of the IANA functions.”402 This contract served to maintain the original MOU between the NTIA and ICANN, which itself reflected the long-standing relationship between the performance of the IANA functions and the highest-level policy-setting organization, such as DARPA and the NSF.

Prior to the IANA transition, ICANN entered into four subsequent IANA functions contracts with the DOC, in 2001, 2003, 2006, and 2012.403 The 2001404 and 2003405 contracts were substantially equivalent to the first contract, although the 2003 contract included modified language to reflect outcomes from the Cooperative Research and Development Agreement (CRADA). The final, 2012406 contract added a number of performance requirements and elaborated on others, all of which were understood as included in the more general descriptions of the earlier contracts.407

402 Internet Corporation for Assigned Names and Numbers and Department of Commerce, “Contract Between ICANN and the United States Government for Performance of the IANA Function.” 403 Department of Commerce, “IANA Functions Contract,” National Telecommunications and Information Administration, accessed September 28, 2018, https://www.ntia.doc.gov/page/iana-functions- purchase-order. 404 Department of Commerce, “2001 IANA Functions Contract,” 2001, https://www.ntia.doc.gov/files/ntia/publications/sb1335-01-w-0650.pdf. 405 Department of Commerce, “2003 IANA Functions Contract,” 2003, https://www.ntia.doc.gov/files/ntia/publications/ianaorder_03142003.pdf. 406 U.S. Department of Commerce, “2012 IANA Functions Contract,” 2012, https://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf. 407 The changes to the 2012 contract resulted from a public comment process run by NTIA.

The Creation and Administration of Unique Identifiers, 1967-2017 95

It modified the numbering component of the IANA functions to include ASNs, and added more POLICY SETTING ORGANIZATIONS (1968-2017) specific tasks surrounding the management of the root zone, WHOIS domain registrant lookup, management of country-code, generic, and the international (INT) Top-Level Domains, and DNSSEC key management.

5.7.2
IANA FUNCTIONS STEWARDSHIP TRANSITION (IANA STEWARDSHIP TRANSITION) PROCESS AND IMPLEMENTATION AGREEMENTS In March 2014, the NTIA signaled to the multistakeholder community that it was ready to begin the transition process.408 The NTIA required this process to have “broad community support” and address the following principles:

Support and enhance the multistakeholder model;

Maintain the security, stability, and resiliency of the Internet DNS;

Meet the needs and expectation of the global customers and partners of the IANA services; and,

Maintain the openness of the Internet.409

Although the NTIA provided the central requirements for the transition, the process used to meet the NTIA requirements resulted in related requirements defined by the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) to also become part of the transition process, as described below. This all occurred in the context of a 2012 bipartisan resolution in the U.S. Senate and House of Representatives that:

Expresses the sense of Congress that the Secretary of State should continue working to implement the position of the United States on Internet governance that articulates the consistent and unequivocal policy of the United States to promote a global Internet free from government control and preserve and advance the multistakeholder model that governs the Internet today.410

https://www.ntia.doc.gov/federal-register-notices/2011/request-comments-internet-assigned-numbers- authority-iana-functions https://www.ntia.doc.gov/federal-register-notice/2011/internet-assigned-numbers-authority-iana- functions-further-notice-inqui 408 National Telecommunications and Information Administration, “Management of Internet Names and Addresses.” 409 Office of Public Affairs, “NTIA Announces Intent to Transition Key Internet Domain Name Functions.” 410 Marco Rubio, “S.Con.Res.50 - 112th Congress (2011-2012): A Concurrent Resolution Expressing the Sense of Congress Regarding Actions to Preserve and Advance the Multistakeholder Governance Model under Which the Internet Has Thrived,” December 5, 2012, https://www.congress.gov/bill/112th- congress/senate-concurrent-resolution/50.

The Creation and Administration of Unique Identifiers, 1967-2017 96

ICANN formed the IANA Stewardship Transition Coordination Group (ICG) to develop POLICY SETTING ORGANIZATIONS (1968-2017) the NTIA, a transition proposal, composed of 30 people from 13 communities. To meet the NTIA defined transition requirements, the ICG defined a process to meet these requirements. This process identified which activities would be directly involved in developing the final combined proposal, the processes and methods for ICG interaction with and between these activities as well as defining how the final proposal would be developed and delivered to NTIA.

The ICG developed the final combined proposal from the individual proposals originating with the communities responsible for domain names, number resources such as IP addresses and ASNs, and protocol parameters. As part of the agreed process, the ICG did not alter the proposals from each community; instead, their task was to assess these proposals for interoperability and any inconsistencies. The ICG would then facilitate any coordination necessary to make the proposals consistent.

These proposals suggested that existing relationships between ICANN, the IAB and IETF be maintained. They also led to the decision to propose a post-transition IANA (PTI; incorporated as Public Technical Identifiers prior to the transition) that would perform the IANA functions as a separate, subordinate organization. The operational communities for each component of the IANA functions would then “maintain independent authority” over those functions in PTI. The IGC agreed to the proposals on the basis that they fulfilled the NTIA’s requirements.411

While the ICG proposal focused on how the IANA functions would be organized in a post-transition ICANN, a separate proposal from the CCWG-Accountability provided recommendations for how to enhance the accountability of ICANN itself, through changes that both enhanced the power of the Internet community, while also making the ICANN Board of Directors more accountable.412 These included an enhanced Independent Review Process, as well as a range of new powers for the community, such as the right to reject board decisions such as budgets, and to recall the entire board.413

411 IANA Stewardship Transition Coordination Group (ICG). 2016. “Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions from the U.S. Commerce Department’s National Telecommunications and Information Administration (NTIA) to the Global Multistakeholder Community.” https://www.icann.org/en/system/files/files/iana-stewardship-transition- proposal-10mar16-en.pdf. 412 Cross Community Working Group on Enhancing ICANN Accountability, “CCWG-Accountability Supplemental Final Proposal on Work Stream 1 Recommendations” (Internet Corporation for Assigned Names and Numbers, February 23, 2016), https://www.icann.org/en/system/files/files/ccwg- accountability-supp-proposal-work-stream-1-recs-23feb16-en.pdf. 413 Ibid.

The Creation and Administration of Unique Identifiers, 1967-2017 97

In June 2016, the NTIA announced that the ICANN proposal developed by the ICG met POLICY SETTING ORGANIZATIONS (1968-2017) its standards.414 Its transition assessment report analyzed ICANN’s proposed changes in the three IANA areas, as well as the accountability strengthening measures developed by CCWG-Accountability. Its acceptance was based on the review at NTIA and other government agencies, as well as through assessments by corporate governance experts, and the Committee of Sponsoring Organizations of the Treadway Commission (COSO) Framework, which assesses organizations in terms of governance, ethics, risk management, and other principles.415

Following its creation in 1998, ICANN entered into its first agreements with the IETF, IESG, IAB, and RIRs. These agreements removed the need for the organizations to have their legal authorization from the NSF and its coordinating committees, and aligned these organizations with ICANN. In October 2016, Verisign entered into a new contract with ICANN. This contract replaced a portion of its earlier agreement with the NTIA dealing with root zone maintenance activities.416 The consequence was to establish the contractual authority over Verisign's root zone maintenance activities to ICANN. As noted above, Verisign acquired Network Solutions Inc. in 2000, and as such took over its responsibilities for root zone maintenance. In March 2000, the IETF entered into an agreement with ICANN through a MOU signed at the Oslo IETF meeting.417 In the MOU, ICANN agreed that IANA would comply with the existing relationship between the IETF, IESG, and IAB. It further stated that “[t]he IANA will assign and register Internet protocol parameters only as directed by the criteria and procedures specified in RFCs.”

414 National Telecommunications and Information Administration, “NTIA Finds IANA Stewardship Transition Proposal Meets Criteria to Complete Privatization” (U.S. Department of Commerce, June 9, 2016), https://www.ntia.doc.gov/press-release/2016/iana-stewardship-transition-proposal-meets-criteria- complete-privatization. 415 National Telecommunications and Information Administration. 2016. “IANA Stewardship Transition Proposal Assessment Report.” U.S. Department of Commerce. https://www.ntia.doc.gov/files/ntia/publications/iana_stewardship_transition_assessment_report.pdf. 416 U.S. Department of Commerce and VeriSign, Inc., “Amendment to Award NCR-92·18742,” October 19, 2016, https://www.ntia.doc.gov/files/ntia/publications/amendment_33.pdf. 417 B. Carpenter and F. Baker, “M. Roberts," Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority” (RFC 2860, June, 2000), https://www.rfc- editor.org/rfc/pdfrfc/rfc2860.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 98

Prior to ICANN’s creation, RFC 2050418 documented the relationship between IANA and POLICY SETTING ORGANIZATIONS (1968-2017) the RIRs–essentially an allocation framework developed collaboratively by IANA and the then existing RIRs. ICANN’s formal acceptance of IANA functions responsibility in January 1999 created the need for a new agreement between the RIRs and ICANN. The first MOU published in May 2000 outlined how each signatory RIR would collect and submit nominees for three seats on the Address Supporting Organization Council.419 This did not create an agreement between ICANN and the RIRs, but rather served to represent the RIRs in the ASO. In 2016, The RIRs and ICANN signed a Service Level Agreement (SLA) for the IANA Numbering Services, which documents the arrangements between them to take effect with the IANA stewardship transition.420

418 Hubbard et al., “Internet Registry IP Allocation Guidelines.” 419 “ICANN and RIR Relationship Agreement ICANN and REGIONAL INTERNET REGISTRIES,” April 9, 2002, https://archive.icann.org/en/general/draft-icann-rir-agreement-09apr02.htm. 420 Internet Corporation for Assigned Names and Numbers, AFRINIC Ltd, APNIC Pty Ltd, for the Asia Pacific Network Information Centre, American Registry for Internet Numbers, Ltd, Latin American and Caribbean Internet Addresses Registry, and Réseaux IP Européens Network Coordination Centre. 2016. “Service Level Agreement for the IANA Numbering Services.” https://www.nro.net/wp- content/uploads/SLA-Executed-ICANN-RIRS.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 99

6
ACKNOWLEDGMENTS ACKNOWLEDGMENTS

The authors would like to single out for thanks Vint Cerf and Steve Crocker, for their tireless and wide-ranging support for this work, as well as our collaborators at ICANN: David Conrad and Mariana Marinho in particular. We also want to acknowledge the financial support provided by the Google and ICANN organizations who made this work possible. Brad and Russ are also indebted to the many reviewers who provided invaluable feedback on earlier drafts. We also want to thank our families for their encouragement, support and patience we needed to complete the document.

The Creation and Administration of Unique Identifiers, 1967-2017 100

SOURCES 7
SOURCES

Abbate, Janet. 1999. Inventing the Internet. MIT Press. “A Beginner’s Guide to Participating in ICANN.” 2013. Internet Corporation for Assigned . https://www.icann.org/resources/pages/beginners-guides-2012-03-06-en. “A Brief History.” 1994. The National Science Foundation. July 15, 1994. https://www.nsf.gov/about/history/nsf50/nsf8816.jsp. “Agreements.” n.d. Public Technical Identifiers. Accessed September 1, 2019. https://pti.icann.org/agreements. “ARPA Becomes DARPA.” n.d. Defense Advanced Research Projects Agency. http://www.darpa.mil/about-us/timeline/arpa-name-change. Barber, Richard. 1975. “The Advanced Research Projects Agency, 1958-1974.” Washington, D.C.: Richard J. Barber Associates, Inc. http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA15 4363. Bernstein, Susan L., and James G. Herman. 1983. “NU: A Network Monitoring, Control, and Management System.” ICC’83- Integrating Communication for World Progress, 478–83. Beyster, J. Robert, Michael A. Daniels, and Vinton G. Cerf. 2013. Names, Numbers, and Network Solutions: The Monetization of the Internet. CreateSpace Independent Publishing Platform. Bhushan, A. 1971. “Scenarios for Using ARPANET Computers.” 254. Request For Comments. Massachusetts Institute of Technology. https://www.rfc-editor.org/info/rfc254. Bhushan, A. K., R. T. Braden, E. Harslem, J. F. Heafner, A. M. McKenzie, J. T. Melvin, R. L. Sundberg, R. W. Watson, and J. E. White. 1971. “Revision of the Mail Box Protocol.” https://www.rfc-editor.org/rfc/pdfrfc/rfc278.txt.pdf. Bolt Beranek and Newman Inc. 1968. “Proposal: Interface Message Processor for the ARPA Computer Network.” IMP P69-IST-5. Cambridge MA: Bolt Beranek and Newman Inc. ———. 1969a. “Initial Design for Interface Message Processors for the ARPA Computer Network.” 1763. BBN Technical Report. Bolt Beranek and Newman Inc. ———. 1969b. “Program Plan for Interface Message Processors for the ARPA Computer Network.” 1765. Cambridge MA. ———. 1969c. “Interface Message Processors for the ARPA Computer Network Quarterly Technical Report No. 1: 2 January 1969 to 31 March 1969.” 1783. Bolt Beranek and Newman Inc. ———. 1969d. “Interface Message Processor: Specifications for the Interconnection of a Host and an IMP.” 1822. Cambridge MA. ———. 1974. “Interface Message Processors for the ARPA Computer Network: Quarterly Technical Report No. 7 1 July 1974 to 30 September 1974.” 2913. Bolt Beranek and Newman Inc. Bolt Beranek and Newman, Inc. 1980. “Combined Quarterly Technical Report No. 18.” 4474. Bolt Beranek and Newman Inc.

The Creation and Administration of Unique Identifiers, 1967-2017 101

Braden, Robert. 1990. “IAB Message: OSI Registration.” Internet Monthly Reports, no. 8 SOURCES (August). ———. 1998. “The End-to-End Research Group – Internet Philosophers and ‘Physicists.’” Presented at the Internet Engineering Task Force (IETF) Plenary, March. http://www.ietf.org/proceedings/98mar/slides/plenary-braden/. Braden, Robert T., and Jon Postel. 1987. “Requirements for Internet Gateways.” https://www.rfc-editor.org/info/rfc1009. Braden, R. T. 1971. “Host Mnemonics Proposed in RFC 226 (NIC 7625).” Request For Comments. University of Southern California Information Sciences Institute. https://www.rfc-editor.org/info/rfc239. Bradner, Scott. 1996. “The Internet Standards Process--Revision 2.” https://www.rfc- editor.org/info/rfc1602. Brown, George E. 1992. Management of NSFNET. Hearing before the Subcommittee on Science of the Committee on Science, Space, and Technology, U.S. House of Representatives, One Hundred Second Congress, Second Session. Washington DC: Congress of the U.S. Burr, J. Beckwith, and National Telecommunications and Information Administration. Letter to David Graves. 1999. “ICANN Designated as ‘NewCo’ for Certain Purposes under the Cooperative Agreement,” February 26, 1999. https://www.ntia.doc.gov/page/1999/icann- designated-newco-certain-purposes-under-cooperative-agreement. “Bylaws for Internet Corporation for Assigned Names and Numbers.” 2018. Internet Corporation for Assigned Names and Numbers. June 18, 2018. https://www.icann.org/resources/pages/governance/bylaws-en/. Campbell-Kelly, M. 1987. “Data Communications at the National Physical Laboratory (1965- 1975).” Annals of the History of Computing 9 (3): 221–47. Carpenter, B., and F. Baker. 2000. “M. Roberts," Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority.” RFC 2860, June. https://www.rfc-editor.org/rfc/pdfrfc/rfc2860.txt.pdf. Cerf, V. 1969. “IMP-IMP and HOST-HOST Control Links.” 18. Request For Comments. University of California Los Angeles. https://www.rfc-editor.org/info/rfc18. Cerf, V., Y. Dalal, and C. Sunshine. 1974. “Specification of Internet Transmission Control Program.” 675. Request For Comments. Stanford University. https://www.rfc- editor.org/info/rfc0675. Cerf, V. G. 1990. “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status.” 1174. Request For Comments. https://www.rfc-editor.org/info/rfc1174. Cerf, Vint. 1978a. “2.3.2.1 A Proposed New Internet Header Format.” 26. Internet Experiment Note. ARPA. https://rfc-editor.org/ien/. ———. 1978b. “2.4.2.1 A Proposal For TCP Version 3.1 Header Format.” 27. Internet Experiment Note. ARPA. https://rfc-editor.org/ien. ———. 1978c. “The Catenet Model for Internetworking.” 48. Internet Experiment Note. Defense Advanced Research Projects Agency Information Processing Techniques Office: ARPA. https://rfc-editor.org/ien.

The Creation and Administration of Unique Identifiers, 1967-2017 102

Cerf, Vinton. 1973. “A Partial Specification of an International Transmission Protocol.” 39. SOURCES Stanford, California: Stanford University. ———. 1990. “Internet Activities Board.” 1160. https://www.rfc-editor.org/info/rfc1160. Cerf, Vinton, and Robert Kahn. 1974. “A Protocol for Packet Network Intercommunication.” IEEE Transactions on Communications. Cerf, Vinton, and P. T. Kirstein. 1978. “Issues in Packet-Network Interconnection.” Proceedings of the IEEE 66 (11): 1386–1408. Cerf, V., and B. Kahn. 1990. “Selected ARPANET Maps.” Computer Communications Review (CCR) 20: 81–110. Cerf, V., and J. Postel. 1972. “Well Known Socket Numbers.” https://www.rfc- editor.org/rfc/pdfrfc/rfc322.txt.pdf. Cheatham, Thomas E., Jr, Dan Cohen, George E. Mealy, Harvey Brooks, and Merton C. Barstow. 1970. “Proposal to the Advanced Research Projects Agency for a Continuation of Air Force Contract F19628-68-C-0379 Supporting Networking and Graphics Research.” Records Group 330. College Park. National Archives and Records Administration. Maryland. https://archives.gov/college-park. Clark, David D. 1982. “Name, Addresses, Ports, and Routes.” 814. Request For Comments. Massachusetts Institute of Technology. https://www.rfc- editor.org/rfc/pdfrfc/rfc814.txt.pdf. Clark, David D., and Danny Cohen. 1978. “A Proposal for Addressing and Routing in the Internet.” 46. Internet Experiment Note. Massachusetts Institute of Technology, USC/Information Sciences Institute. https://rfc-editor.org/ien. Clinton, William J. 1997. “Memorandum on Electronic Commerce.” Weekly Compilation of Presidential Documents Volume 33 Issue 27 (Monday, July 7, 1997). U.S. Government Publishing Office. https://www.gpo.gov/fdsys/pkg/WCPD-1997-07-07/html/WCPD-1997- 07-07-Pg1006-2.htm. Cohen, Danny. 1977. “Internetting or Beyond NCP.” 11. Internet Experiment Note. https://www.rfc-editor.org/ien/. “Community.” n.d. Internet Corporation for Assigned Names and Numbers. Accessed September 27, 2018. https://www.icann.org/community. Conway-Jones, Danielle. 2004. “Research and Development Deliverables under Government Contracts, Grants, Cooperative Agreements and CRADAs: University Roles, Government Responsibilities and Contractor Rights.” Computer Law Review & Technology Journal 9: 181. Cooper, A., and J. Postel. 1993. “The US Domain.” https://www.rfc- editor.org/rfc/pdfrfc/rfc1386.txt.pdf. “Coordinating Committee for Intercontinental Research Networking.” n.d. Union of International Associations. Accessed September 22, 2019. https://uia.org/s/or/en/1100038180. Crispin, M. R. 1979. “Universal Host Table.” Request For Comments. https://www.rfc- editor.org/info/rfc752.

The Creation and Administration of Unique Identifiers, 1967-2017 103

Crocker, S. 1994. “The Process for Organization of Internet Standards Working Group SOURCES (POISED).” RFC 1640. https://www.rfc-editor.org/rfc/pdfrfc/rfc1640.txt.pdf. Crocker, S. D. 1969. “Documentation Conventions.” RFC0003. RFC Editor. https://www.rfc- editor.org/info/rfc0003. ———. 1970a. “Network Meeting Epilogue, Etc.” 37. Request For Comments. Los Angeles, California: University of California Los Angeles. https://www.rfc-editor.org/info/rfc37. ———. 1970b. “New Host-Host Protocol.” 33. Request For Comments. Los Angeles, California: University of California Los Angeles. https://www.rfc-editor.org/info/rfc33. Crocker, S. D., J. Postel, J. Newkirk, and M. Kraley. 1970. “Official Protocol Proffering.” https://www.rfc-editor.org/info/rfc54. Crocker, Stephen. 1969. “Host Software.” 1. Request For Comments. Los Angeles, California: University of California, Los Angeles. https://www.rfc-editor.org/info/rfc1. ———. 1993. “The Process for Organization of Internet Standards Working Group [POISED].” 1396. Request For Comments. https://www.rfc-editor.org/info/rfc1396. Cross Community Working Group on Enhancing ICANN Accountability. 2016. “CCWG- Accountability Supplemental Final Proposal on Work Stream 1 Recommendations.” 1. Internet Corporation for Assigned Names and Numbers. https://www.icann.org/en/system/files/files/ccwg-accountability-supp-proposal-work- stream-1-recs-23feb16-en.pdf. Davies, D. W., K. A. Bartlett, R. A. Scantlebury, and P. T. Wilkinson. 1967. A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals. SOSP ’67. ACM. DDN Network Information Center, and Defense Communications Agency Defense Data Network Defense Communications System. 1988. “Phase II of the MILNET Domain Name Implementation.” Defense Data Network Management Bulletin, November 2, 1988. https://www.rfc-editor.org/rfc/museum/ddn-news/. Decker, William. 1992. “Internet Related Registration Services.” 9201059. National Science Foundation Division Of Computer and Network Systems. https://nsf.gov/awardsearch/showAward?AWD_ID=9201059&HistoricalAwards=false. Defense Communications Agency. 1976. “ARPANET Information Brochure.” Washington, DC. Defense Technical Information Center. http://www.dtic.mil/dtic/tr/fulltext/u2/a482154.pdf. ———. 1984. “Contract DCA200-84-C-0024.” SRI International. Defense Supply Service. 1968. “Specifications of Interface Message Processors for the ARPA Computer Network.” Request for Quotations, Request no. DAHC15 69 Q 0002. Deloche, G. 1969a. “Host Software.” https://www.rfc-editor.org/info/rfc9. ———. 1969b. “Implementation of the Host - Host Software Procedures in GORDO.” https://www.rfc-editor.org/info/rfc11. Denning, Peter J., Anthony Hearn, and C. William Kern. 1983. History and Overview of CSNET. Vol. 13. ACM.

The Creation and Administration of Unique Identifiers, 1967-2017 104

Department of Commerce. 1997. “Registration and Administration of Internet Domain Names -- SOURCES Summary of Comments.” https://www.ntia.doc.gov/other-publication/1997/registration- and-administration-internet-domain-names-summary-comments-docket. ———. 2001. “2001 IANA Functions Contract.” https://www.ntia.doc.gov/files/ntia/publications/sb1335-01-w-0650.pdf. ———. 2003. “2003 IANA Functions Contract.” https://www.ntia.doc.gov/files/ntia/publications/ianaorder_03142003.pdf. ———. n.d. “IANA Functions Contract.” National Telecommunications and Information Administration. Accessed September 28, 2018. https://www.ntia.doc.gov/page/iana- functions-purchase-order. Department of Commerce, and Internet Corporation for Assigned Names and Numbers. 2001. “License Agreement Concerning InterNIC.” https://www.icann.org/resources/unthemed- pages/internic-license-2001-01-08-en. ———. 2006a. “Contract Between ICANN and the United States Government for Performance of the IANA Function.” 909-9-0043. https://www.ntia.doc.gov/files/ntia/publications/ianacontract_081406.pdf. ———. 2006b. “Contract for the Performance of the IANA Function.” NTIA-912-6-0269. https://www.ntia.doc.gov/files/ntia/publications/ianacontract_081406.pdf. Department of Defense. 1958. “Department of Defense Directive 5105.15 1958.” Department of Defense. ———. 1961. “DoD Directive 5105.19: Defense Communications Agency.” ———. 1972. “Department of Defense Directive 5105.41 1972.” ———. 1978. “Department of Defense Directive 5105.15 1978.” ———. 1989. “Department of Defense Directive 5105.15 1989.” ———. 1995. “Department of Defense Directive 5105.15 1995.” Department of Defense Reorganization Act of 1958. 1958. Deutsch, D. P. 1979. “Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPANET Message Systems.” 757. Request For Comments. https://www.rfc- editor.org/info/rfc757. Deutsch, L. P. 1973. “Host Names on-Line.” 606. Request For Comments. Xerox Palo Alto Research Center. https://www.rfc-editor.org/info/rfc606. Dinneen, Gerald. 1978. “Host-to-Host Protocols for Data Communications Networks.” Washington, D.C.: Under Secretary of Defense for Research and Engineering. ———. 1980. “Host-to-Host Data Communications Protocols.” Washington, D.C.: Assistant Secretary of Defense, Communications, Command, Control, and Intelligence. Duvall, B. 1969. “Host Software.” 2. Request For Comments. Stanford Research Institute. https://www.rfc-editor.org/info/rfc2. Establishment, Membership, and Functions of Council. 1976. U.S. Code. Vol. 42. https://www.law.cornell.edu/uscode/text/42/6651. Farber, David. 1987. “Network Program Advisory Group.” ConneXions 1 (8): 13. Federal Networking Council. 1995a. “U.S. Government Internet Domain Names.” RFC 1811. https://www.rfc-editor.org/rfc/pdfrfc/rfc1811.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 105

———. 1995b. “Definition of ‘Internet.’” Federal Network Council. SOURCES https://web.archive.org/web/20130303021314/nitrd.gov/fnc/Internet_res.aspx. “Federal Networking Council Charter.” 1995. https://www.nitrd.gov/fnc/FNC_Charter.pdf. Feinler, E. J., K. Harrenstien, Z. Su, and V. White. 1982. “DoD Internet Host Table Specification.” 810. Request For Comments. https://www.rfc-editor.org/info/rfc810. Feinler, Elizabeth J. 1985. DDN Protocol Handbook: DARPA Internet Protocols. Vol. 2. DDN Network Information Center, SRI International. Floyd, Spencer. 1974. “Attention: Mr. Roger Lemke/PMRD Reference: SRI Proposal ISU 74-84 (ARPA Order No. 2542).” SRI ARC/NIC Records. Computer History Museum. Computer History Museum Collections. Menlo Park, CA. http://www.computerhistory.org/collections/catalog/102706170. Frazer, Karen D. 1995. “NSFNET: A Partnership for High-Speed Networking Final Report 1987-1995.” NCR 8720904. MERIT. https://web.archive.org/web/20150210181738/http://www.merit.edu/about/history/pdf/N SFNET_final.pdf. Fuller, Vince, Tony Li, Jessica Yu, and Kannan Varadhan. 1992. “Supernetting: An Address Assignment and Aggregation Strategy.” https://www.rfc-editor.org/info/rfc1338. Fuller, V., T. Li, J. Yu, and K. Varadhan. 1993. “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy.” 1519. Request For Comments. https://www.rfc-editor.org/info/rfc1519. Gerich, E. 1992. “Guidelines for Management of IP Address Space.” RFC 1366. https://www.rfc-editor.org/info/rfc1366. ———. 1993. “Guidelines for Management of IP Address Space.” 1466. Request For Comments. https://www.rfc-editor.org/info/rfc1466. G. Huston, Ed. 2001. “Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain (‘arpa’).” 3172. https://www.rfc- editor.org/info/rfc3172. Gillies, James, and Robert Cailliau. 2000. How the Web Was Born: The Story Ofthe World Wide Web. Oxford: Oxford University Press. GIRDVAINIS@BBN-TENEX. 1975. “Arpanet Management Transition,” September 26, 1975. Gore, and Albert. 1991. High-Performance Computing Act of 1991. https://www.congress.gov/bill/102nd-congress/senate-bill/272. “Governance & Policies.” n.d. Internet Society. Accessed September 18, 2018. https://www.internetsociety.org/about-internet-society/governance-policies/. Grier, D. A., and M. Campbell. 2000. “A Social History of Bitnet and Listserv, 1985-1991.” IEEE Annals of the History of Computing 22 (2): 32–41. Gross, Philip, and Allison Mankin. 1988. “Proceedings of the Ninth Internet Engineering Task Force March 1-3, 1988 in San Diego.” IETF 9. McLean, Virginia: The MITRE Corporation. Gross, Philip, and Gregory M. Vaudreuil. 1989. “Proceedings of the Fifteenth Internet Engineering Task Force University of Hawaii October 31 - November 3, 1989.” 15. Corporation for National Research Initiatives.

The Creation and Administration of Unique Identifiers, 1967-2017 106

———. 1990. “Proceedings of the Sixteenth Internet Engineering Task Force Florida State SOURCES University February 6-9, 1990.” 16. Corporation for National Research Initiatives. Gross, Phillip. 1986a. “Proceedings of the 16-17 January 1986 DARPA Gateway Algorithms and Data Structures Task Force / FIRST IETF.” 1. The MITRE Corporation. ———. 1986b. “Proceedings of the 15-17 October 1986 Joint Meeting of the Internet Engineering and Internet Architecture Task Forces.” IETF 4. McLean, Virginia: MITRE Corporation. Gross, Phillip G., and Gregory M. Vaudreuil. 1990. “Proceedings of the Seventeenth Internet Engineering Task Force.” 17. Corporation for National Research Initiatives. Harrenstien, K., V. White, and E. J. Feinler. 1982. “Hostnames Server.” 811. Request For Comments. https://www.rfc-editor.org/info/rfc811. Harslem, E., J. Heafner, and E. Meyer. 1971. “Request for Comments on Socket Name Structure.” 129. Request For Comments. RAND Corporation, Massachusetts Institute of Technology. https://www.rfc-editor.org/info/rfc0129. Haverty, J. F. 1982. “Combined Quarterly Technical Report Number 24. SATNET Development and Operation, Pluribus Satellite IMP Development, Remote Site Maintenance, Internet Operations and Maintenance, Mobile Access Terminal Network, TCP for the HP3000, TCP for VAX-UNIX.” BBN-4868. Bolt Beranek and Newman Inc. http://www.dtic.mil/dtic/tr/fulltext/u2/a112575.pdf. Heart, Frank, Alex McKenzie, John McQuillian, and David Walden. 1978. “ARPANET Completion Report.” 4799. Bolt Beranek and Newman Inc. http://walden- family.com/bbn/arpanet-completion-report.pdf. Hemmendinger, D. 2014. “Messaging in the Early SDC Time-Sharing System.” IEEE Annals of the History of Computing 36 (1): 52–57. ———. 2015. “Two Early Interactive Computer Network Experiments.” IEEE Annals of the History of Computing PP (99): 1–1. Hinden, R. M., and A. Sheltzer. 1982. “DARPA Internet Gateway.” RFC0823. RFC Editor. https://www.rfc-editor.org/info/rfc0823. Hinden, Robert, Internet Engineering Steering Group, and Others. 1993. “Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR).” https://www.rfc-editor.org/rfc/pdfrfc/rfc1517.txt.pdf. Hinton, Jan Michele. 1985. “A Study of the Communications Services Industrial Fund.” Monterey, California. Naval Postgraduate School. http://calhoun.nps.edu/handle/10945/21562. Hoffman, Paul, and Susan Harris. 2006. “The Tao of IETF-A Novice’s Guide to the Internet Engineering Task Force.” https://www.rfc-editor.org/info/rfc3160. Howell, Martha C., and Walter Prevenier. 2001. From Reliable Sources: An Introduction to Historical Methods. Ithaca, NY: Cornell University Press. Hoy, J. B., M. T. Brewer, B. A. Peterson, and G. Dittmer. 1989. “Computer Security: Virus Highlights Need for Improved Internet Management.” GAO/IMTEC-89-57. General Accounting Office, Information Management and Technology Division. http://www.dtic.mil/docs/citations/ADA344751.

The Creation and Administration of Unique Identifiers, 1967-2017 107

Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, and J. Postel. 1996. “Internet Registry IP SOURCES Allocation Guidelines.” 2050. Request For Comments. https://www.rfc- editor.org/info/rfc2050. Huitema, C. 1994. “Charter of the Internet Architecture Board (IAB).” RFC 1601. https://www.rfc-editor.org/rfc/pdfrfc/rfc1601.txt.pdf. IANA Stewardship Transition Coordination Group (ICG). 2016. “Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions from the U.S. Commerce Department’s National Telecommunications and Information Administration (NTIA) to the Global Multistakeholder Community.” https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16- en.pdf. IANA Transition Coordination Group. n.d. “IANA Stewardship Transition Proposal: Call for Public Comment.” https://www.ianacg.org/icg-files/documents/XPL- ICAN_1510_ICG_Report_Visual_Summary_09.pdf. “ICANN and RIR Relationship Agreement ICANN and REGIONAL INTERNET REGISTRIES.” 2002. https://archive.icann.org/en/general/draft-icann-rir-agreement- 09apr02.htm. “ICANN Announces Incorporation of Public Technical Identifiers (PTI).” 2016. Internet Corporation for Assigned Names and Numbers. August 11, 2016. https://www.icann.org/news/announcement-2-2016-08-11-en. International Ad Hoc Committee. 1997. “The Generic Top Level Domain Memorandum of Understanding.” The Internet Archive. December 11, 1997. https://web.archive.org/web/19971211190034/http://www.gtld-mou.org/. Internet Activities Board. 1988. “Minutes of the July 12-13, 1988 Internet Activities Board Meeting Sante Fe, New Mexico.” https://www.iab.org/documents/minutes/minutes- 1988/iab-minutes-1988-07-12/. ———. 1998. “Minutes of the March 21, 1988 Internet Activities Board Teleconference.” https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988-03-21/. Internet Activities Board, and Defense Advanced Research Projects Agency. 1988. “IAB Official Protocol Standards.” 1083. Request For Comments. https://tools.ietf.org/html/rfc1083. Internet Assigned Numbers Authority. 1999. “Wayback Machine Archive: ‘IANA Matrix for Protocol Parameter Assignment/Registration Procedures.’” Iana Internet Assigned Numbers Authority. February 18, 1999. https://web.archive.org/web/20050219042820/http://www.iana.org:80/numbers.html. ———. “Autonomous System (AS) Numbers.” https://www.iana.org/assignments/as- numbers/as-numbers.xhtml. Internet Corporation for Assigned Names and Numbers. 2000a. “Proposal to the U.S. Government to Perform the IANA Function.” https://archive.icann.org/en/general/iana- proposal-02feb00.htm. ———. 2000b. “Response to Request for Quotation Number 40SBNT067020.” https://archive.icann.org/en/general/iana-proposal-02feb00.htm.

The Creation and Administration of Unique Identifiers, 1967-2017 108

———. 2010. “Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN SOURCES Blocks to Regional Internet Registries | (Ratified by Executive Committee, on behalf of the ICANN Board in September 2010).” https://www.icann.org/resources/pages/global-policy- asn-blocks-2010-09-21-en. Internet Corporation for Assigned Names and Numbers, AFRINIC Ltd, APNIC Pty Ltd, for the Asia Pacific Network Information Centre, American Registry for Internet Numbers, Ltd, Latin American and Caribbean Internet Addresses Registry, and Réseaux IP Européens Network Coordination Centre. 2016. “Service Level Agreement for the IANA Numbering Services.” https://www.nro.net/wp-content/uploads/SLA-Executed-ICANN-RIRS.pdf. Internet Corporation for Assigned Names and Numbers, and Department of Commerce. 1998- 2006. “Memorandum of Understanding/Joint Project Agreement with U.S. Department of Commerce.” https://www.icann.org/resources/pages/agreements-en. ———. 1999. “Cooperative Research & Development Agreement.” https://www.icann.org/resources/unthemed-pages/crada-2012-02-25-en. ———. 2000. “Contract Between ICANN and the United States Government for Performance of the IANA Function.” https://www.ntia.doc.gov/files/ntia/publications/ianacontract.pdf. ———. 2003. “Public Summary of Reports Provided Under Cooperative Research and Development Agreement CN-1634 Between the Internet Corporation for Assigned Names and Numbers and the United States Department of Commerce.” https://www.icann.org/resources/unthemed-pages/crada-report-summary-2003-03-14-en. ———. 2009. “AFFIRMATION OF COMMITMENTS BY THE UNITED STATES DEPARTMENT OF COMMERCE AND THE INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS.” https://www.icann.org/resources/pages/affirmation-of-commitments-2009-09-30-en. Internet Corporation for Assigned Names and Numbers, and Public Technical Identifiers. 2016. “IANA Naming Function Agreement.” https://www.icann.org/en/system/files/files/proposed-iana-naming-function-agreement- 10aug16-en.pdf. Internet Corporation for Assigned Names and Numbers, and Internet Engineering Task Force. 2016. “ICANN-IETF MoU Supplemental Agreement.” https://www.icann.org/iana_imp_docs/59-2016-icann-ietf-mou-supplemental-agreement-v- 1-0. Internet Engineering Task Force, and Internet Corporation for Assigned Names and Numbers. 2000. “IETF-ICANN Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority.” https://www.ntia.doc.gov/files/ntia/publications/ianacontract_081406.pdf. Kahn, Robert. 2006. Oral History of Kahn, Bob (Robert) Interview by Vinton Cerf. http://www.computerhistory.org/collections/catalog/102657973. Kahn, Robert E. 1990. Oral history interview with Robert E. Kahn Interview by Judy O’Neill. http://conservancy.umn.edu/handle/11299/107387. Karp, P. M. 1971. “Standardization of Host Mnemonics.” 226. Request For Comments. MITRE. https://www.rfc-editor.org/info/rfc226.

The Creation and Administration of Unique Identifiers, 1967-2017 109

Karrenberg, Daniel, Gerard Ross, Paul Wilson, and Leslie Nobile. 2001. “Development of the SOURCES Regional Internet Registry System.” The Internet Protocol Journal 4 (4): 17–29. Kirstein, Peter T. 1978. “University College London ARPANET Project Annual Report, 1 January 1977 - 31 December 1977.” INDRA Technical Report 1978. University College London. http://www.dtic.mil/docs/citations/ADA135020. Kleinrock, Leonard, Gerald Estrin, Michel Melkanoff, and Richard R. Muntz. 1971. “Computer Network Research: Advanced Research Projects Agency Semiannual Technical Report.” University of California Los Angeles. Knopper, Mark, and S. Richardson. 1993. “Aggregation Support in the Nsfnet Policy-Based Routing Database.” https://www.rfc-editor.org/rfc/pdfrfc/rfc1482.txt.pdf. Kudlick, M. D., and E. J. Feinler. 1974. “ASCII Text File of Hostnames.” 627. Request For Comments. Stanford Research Institute. https://www.rfc-editor.org/info/rfc627. La Chapelle, Bertrand de. 2011. “Multistakeholder Governance: Principles and Challenges of an Innovative Political Paradigm.” MIND Multistakeholder Internet Dialogue, no. 2 (September): 14–25. Landweber, Lawrence, and Marvin Solomon. 1981. “Technical Support of Csnet and Service Host Functions in Support of Csnet.” 8109318. National Science Foundation Division of Computing and Communication Foundations. https://www.nsf.gov/awardsearch/showAward?AWD_ID=8109318. Lawrence G Roberts, Advanced Research Projects Agency. 1970. “Stanford Research Institute Contract, ARPA Order 967.” Records Group 330. National Archives and Records Administration. College Park, Maryland. https://www.archives.gov/college-park. Leigh Star, Susan. 2010. “This Is Not a Boundary Object: Reflections on the Origin of a Concept.” Science, Technology & Human Values 35 (5): 601–17. Leiner, Barry. 1993. “Globalization of the Internet.” In Internet System Handbook, edited by Daniel C. Lynch and Marshall T. Rose. Addison-Wesley. Leiner, Barry M., Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Lawrence G. Roberts, and Stephen Wolff. 1997. “Brief History of the Internet.” Internet Society. https://www.internetsociety.org/resources/doc/2017/brief- history-internet/. Levy, Stuart, and T. Jacobson. 1988. “Telnet X. 3 PAD Option.” https://www.rfc- editor.org/rfc/pdfrfc/rfc1053.txt.pdf. Lyon, Matthew, and Katie Hafner. 1999. Where Wizards Stay Up Late: The Origins Of The Internet. Simon and Schuster. Malkin, Gary. 1993. “The Tao of IETF-A Guide for New Attendees of the Internet Engineering Task Force.” https://www.rfc-editor.org/rfc/pdfrfc/rfc1391.txt.pdf. Mankin, Allison, and Phillip Gross. 1987. “Proceedings of the July 27-29, 1987 Internet Engineering Task Force.” IETF 7. Marill, Thomas, and Lawrence G. Roberts. 1966. Toward a Cooperative Network of Time- Shared Computers. AFIPS ’66 (Fall). ACM. McKenzie, A., and S. Crocker. 2012. “Host/Host Protocol for the ARPA Network.” 6529. Request For Comments. RFC Editor. https://www.rfc-editor.org/info/rfc6529.

The Creation and Administration of Unique Identifiers, 1967-2017 110

McKenzie, Alexander. 1972. “International Packet Network Working Group (INWG).” Alex SOURCES McKenzie Collection of Computer Networking Development Records. University of Minnesota. Charles Babbage Institute. Minneapolis and Saint Paul, Minnesota. https://archives.lib.umn.edu/repositories/3/resources/242. ———. 1975. “The ARPA Network Control Center.” Fourth Data Communications Symposium, Quebec City, Canada, October, 5–1 – 5–6. McKenzie, Alexander, B. P. Cosell, J. M. McQuillan, and M. J. Thrope. 1972. “The Network Control Center for the ARPA Network.” Proceedings of the First International Conference on Computer Communication, 185–91. McKenzie, Alexander, and David Walden. 1997. “The ARPANET, the Defense Data Network, and the Internet.” In Encyclopedia of Telecommunications, 1:341–76. Marcel Dekker, Inc. McKenzie, A. M. 1971a. “Address Tables.” RFC 208. https://www.rfc- editor.org/rfc/pdfrfc/rfc208.txt.pdf. ———. 1971b. “Initial Connection Protocol.” 93. Request For Comments. Cambridge MA: Bolt Beranek and Newman Inc. https://www.rfc-editor.org/info/rfc93. ———. 1971c. “Link Number Assignments.” 179. Request For Comments. https://www.rfc- editor.org/info/rfc179. ———. 1973a. “File Transfer Protocol-Meeting Announcement and a New Proposed Document.” https://www.rfc-editor.org/rfc/pdfrfc/rfc454.txt.pdf. ———. 1973b. “Modifications to the TELNET Specification.” https://www.rfc- editor.org/rfc/pdfrfc/rfc562.txt.pdf. ———. 1973c. “Telnet Protocol Specifications.” RFC 495. https://www.rfc- editor.org/rfc/pdfrfc/rfc495.txt.pdf. Mikulski, Barbara. 1992. Scientific and Advanced-Technology Act of 1992. https://www.congress.gov/bill/102nd-congress/senate-bill/1146. Mills, D. L. 1981. “Internet Name Domains.” 799. Request For Comments. https://www.rfc- editor.org/info/rfc799. Mills, D. L., and H. Braun. 1988. The NSFNET Backbone Network. SIGCOMM ’87. ACM. https://doi.org/10.1145/55482.55502. Mowery, David C., and Bhaven N. Sampat. 2005. “The Bayh-Dole Act of 1980 and University- Industry Technology Transfer: A Model for Other OECD Governments?” In Essays in Honor of Edwin Mansfield, edited by Albert N. Link and F. M. Scherer, 233–45. Springer US. Mowery, David C., and Timothy Simcoe. 2002. “Is the Internet a US. Invention?—an Economic and Technological History of Computer Networking.” Research Policy 31 (8–9): 1369–87. National Science Foundation. 1992. “NSF9224--Network Information Services Manager(s) for NSFNET and NREN.” 9224. National Science Foundation. https://www.nsf.gov/pubs/stis1992/nsf9224/nsf9224.txt. National Science Foundation Act. 1950. Title 42. https://www.loc.gov/law/help/us-code.php. National Science Foundation, and Network Solutions Inc. 1993. “Network Information Services Manager(s) for NSFNET and the NREN: INTERNIC Registration Services.” https://archive.icann.org/en/nsi/coopagmt-01jan93.htm.

The Creation and Administration of Unique Identifiers, 1967-2017 111

National Security Act Amendments of 1949. 1949. U.S.C. SOURCES https://catalog.archives.gov/id/299860. National Telecommunications and Information Administration. 1997. “Request for Comments on the Registration and Administration of Internet Domain Names.” https://www.ntia.doc.gov/federal-register-notice/1997/request-comments-registration-and- administration-internet-domain-names. ———. 1998a. “Statement of Policy on the Management of Internet Names and Addresses.” 980212036-8146-02. Federal Register Notices. Washington, DC: National Telecommunications and Information Administration. https://www.ntia.doc.gov/federal- register-notice/1998/statement-policy-management-internet-names-and-addresses. ———. 1998b. “Management of Internet Names and Addresses.” https://www.icann.org/resources/unthemed-pages/white-paper-2012-02-25-en. ———. 2016. “IANA Stewardship Transition Proposal Assessment Report.” U.S. Department of Commerce. https://www.ntia.doc.gov/files/ntia/publications/iana_stewardship_transition_assessment _report.pdf. ———. 2016. “NTIA Finds IANA Stewardship Transition Proposal Meets Criteria to Complete Privatization.” U.S. Department of Commerce. https://www.ntia.doc.gov/press- release/2016/iana-stewardship-transition-proposal-meets-criteria-complete-privatization. National Telecommunications and Information Administration, and Internet Corporation for Assigned Names and Numbers. 1998. “Memorandum of Understanding Between the U.S. Department of Commerce and the Internet Corporation for Assigned Names and Numbers.” https://www.ntia.doc.gov/page/1998/memorandum-understanding-between-us-department- commerce-and-internet-corporation-assigned-. Neigus, N., and J. Postel. 1973. “Socket Number List.” https://www.rfc- editor.org/rfc/pdfrfc/rfc503.txt.pdf. Network Technical Advisory Group. 1986. “Requirements for Internet Gateways - Draft.” RFC 985. National Science Foundation. https://www.rfc-editor.org/rfc/pdfrfc/rfc985.txt.pdf. Newland, Erica. 2015. “Executive Orders in Court.” The Yale Law Journal 124 (6): 1836–2201. Norberg, Arthur L., Judy E. O’Neill, and Kerry J. Freedman. 1996. Transforming Computer Technology: Information Processing for the Pentagon, 1962-1986. Baltimore: Johns Hopkins University Press. North, J. B. 1971. “ARPA Network Mailing Lists.” https://www.rfc-editor.org/info/rfc155. ———. 1972. “Official Site Idents for Organizations in the ARPA Network.” https://www.rfc- editor.org/info/rfc384. Number Resource Organization, Internet Corporation for Assigned Names and Numbers, Asia- Pacific Network Coordination Centre, American Registry for Internet Numbers, Latin American and Caribbean Internet Addresses Registry, and Réseaux IP Européens Network Coordination Centre. 2004. “ASO Memorandum of Understanding.” ICANN Address Supporting Organization. https://aso.icann.org/about-the-aso/aso-memorandum-of- understanding/. Office of Federal Procurement Policy Act. 1974. U.S.C. Vol. 41.

The Creation and Administration of Unique Identifiers, 1967-2017 112

Office of Naval Research Contract Administration. 1973. “N00014-73-C-0522, University College SOURCES London.” Records Group 330. College Park. National Archives and Records Administration. Maryland. https://www.archives.gov/college-park. Office of Public Affairs. 2014. “NTIA Announces Intent to Transition Key Internet Domain Name Functions.” National Telecommunications and Information Administration Newsroom, March 14, 2014. https://www.ntia.doc.gov/press-release/2014/ntia-announces- intent-transition-key-internet-domain-name-functions. Office of the Inspector General. 1993. “Review of NSFNET.” 9301. National Science Foundation. https://www.nsf.gov/pubs/stis1993/oig9301/oig9301.txt. Office, U. S. Government Accountability. 2016. “Department of Commerce--Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions,” no. B-327398 (September). http://www.gao.gov/products/B-327398. Oldehoeft, Arthur. 1992. “NISTIR 4734, Security Policy for Use of National Research Educational Network | CSRC.” 4734. National Institute of Standards and Technology. https://csrc.nist.gov/publications/detail/nistir/4734/archive/1992-02-01. Oldehoeft, Arthur E. 1992. “Foundations of a Security Policy for Use of the National Research and Educational Network.” NIST IR 4734. Gaithersburg, MD: National Institute of Standards and Technology. Page, David Flood. 1980. “The CMCC Terminal Process.” 132. Internet Experiment Note. Bolt Beranek and Newman Inc. https://rfc-editor.org/ien. “Performance Reporting.” n.d. Internet Assigned Numbers Authority. Accessed September 21, 2019. https://www.iana.org/performance. Pickens, J. R., E. J. Feinler, and J. E. Mathis. 1979. “NIC Name Server - a Datagram-Based Information Utility.” 756. Request For Comments. https://www.rfc-editor.org/info/rfc756. Postel, J. 1971. “Sockets in Use.” RFC 204. https://www.rfc- editor.org/rfc/pdfrfc/rfc204.txt.pdf. ———. 1972. “Official Host-Host Protocol Modification: Assigned Link Numbers.” 317. Request For Comments. https://www.rfc-editor.org/info/rfc317. ———. 1973. “Assigned Link Numbers.” 604. Request For Comments. MITRE. https://www.rfc-editor.org/info/rfc604. ———. 1975. “Protocol Informations.” https://www.rfc-editor.org/info/rfc694. ———. 1976. “Assigned Network Numbers.” 717. Request For Comments. University of Southern California Information Sciences Institute. https://www.rfc-editor.org/info/rfc717. ———. 1977a. “Extensible Field Addressing.” RFC 730. USC Information Sciences Institute. https://www.rfc-editor.org/rfc/pdfrfc/rfc730.txt.pdf. ———. 1977b. “RFC739 Assigned Numbers.” 739. Request For Comments. https://www.rfc- editor.org/info/rfc739. ———. 1983. “Domain Names Plan and Schedule.” 881. Request For Comments. https://www.rfc-editor.org/info/rfc881. ———. 1994. “Domain Name System Structure and Delegation.” 1591. Request For Comments. https://www.rfc-editor.org/info/rfc1591.

The Creation and Administration of Unique Identifiers, 1967-2017 113

———. n.d. “RFC840: Official Protocols.” 840. Request For Comments. https://www.rfc- SOURCES editor.org/info/rfc840. Postel, J. B., and S. D. Crocker. 1971. “Link 191.” https://www.rfc- editor.org/rfc/pdfrfc/rfc104.txt.pdf. Postel, Jon. 1974. “Protocol Information.” 661. Request For Comments. Stanford Research Institute Augmentation Research Center. https://www.rfc-editor.org/info/rfc661. ———. 1981a. “RFC790: Assigned Numbers.” 790. University of Southern California Information Sciences Institute. ———. 1981b. “TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION.” 793. Request For Comments. University of Southern California Information Sciences Institute and the Defense Advanced Research Projects Agency. https://www.rfc-editor.org/info/rfc793. ———. 1984. “Domain Name System Implementation Schedule-Revised.” https://www.rfc- editor.org/info/rfc921. ———. 1996. “New Registries and the Delegation of International Top Level Domains.” University of Southern California Information Sciences Institute. https://tools.ietf.org/html/draft-postel-iana-itld-admin-01. ———. n.d. “JBP Jon Postel CV.” Jon Postel Collection. University of Southern California. University of Southern California University Archives. Los Angeles CA. https://libraries.usc.edu/locations/special-collections-department/university-archives. Postel, Jonathan B. 1972. “Proposed Standard Socket Numbers.” 349. Request For Comments. University of California Los Angeles. https://www.rfc-editor.org/info/rfc349. ———. 1977. “TCP Meeting Notes 14 & 15 July 1977.” 65. Internet Experiment Note. University of Southern California Information Sciences Institute. https://rfc-editor.org/ien/. ———. 1978a. “DRAFT INTERNETWORK PROTOCOL SPECIFICATION.” 28. Internet Experiment Note. University of Southern California Information Sciences Institute. https://rfc-editor.org/ien/. ———. 1978b. “1.4.2 Meeting Notes - 1 February 1978.” 22. Internet Experiment Note. University of Southern California Information Sciences Institute. https://www.rfc- editor.org/ien/. Postel, Jonathan, and Joe Bannister. 2000. “Tera-Node Network Technology (TASK 4) Network Infrastructure Activities (NIA) Final Report.” DOE/ER/25326-1, 802104. http://www.osti.gov/servlets/purl/802104-AO0fQ0/native/. Postel, Jonathan B., Larry L. Garlick, and Raphael Rom. 1976. “Transmission Control Protocol Specification.” Menlo Park, California: Stanford Research Institute Augmentation Research Center. Postel, Jon, and DARPA. 1980. “DoD Standard Internet Protocol.” 760. Request For Comments. USC Information Sciences Institute. https://www.rfc-editor.org/info/rfc760. ———. 1981. “Internet Protocol DARPA Internet Program Protocol Specification.” 791. Request For Comments. University of Southern California Information Sciences Institute and the Defense Advanced Research Projects Agency. https://www.rfc- editor.org/info/rfc791.

The Creation and Administration of Unique Identifiers, 1967-2017 114

Postel, Jon, and Joyce K. Reynolds. 1984. “Domain Requirements.” 920. Request For SOURCES Comments. https://www.rfc-editor.org/rfc/pdfrfc/rfc920.txt.pdf. Postel, J., and J. K. Reynolds. 1983. “RFC880: Official Protocols.” https://www.rfc- editor.org/info/rfc880. Postel, J., and J. Vernon. 1982. “RFC820: Assigned Numbers.” 820. Request For Comments. https://www.rfc-editor.org/info/rfc820. “Project Solicitation for Management and Operation of the NSFNET Backbone Network.” 1987. National Science Foundation. “Regional Internet Registries.” 2018. The Number Resource Organization. 2018. https://www.nro.net/about/rirs/. Rekhter, Y., and T. Li. 1993. “An Architecture for IP Address Allocation with CIDR.” 1518. Request For Comments. https://www.rfc-editor.org/info/rfc1518. Reynolds, J. 2001. “Assigned Numbers: RFC 1700 Is Replaced by an On-Line Database.” 3232. Request For Comments. University of Southern California Information Sciences Institute. https://www.rfc-editor.org/info/rfc3232. Reynolds, J. K., and J. Postel. 1984a. “RFC900: Assigned Numbers.” RFC 900. https://www.rfc-editor.org/rfc/pdfrfc/rfc900.txt.pdf. ———. 1984b. “ARPA Internet Protocol Policy.” RFC0902. RFC Editor. https://www.rfc- editor.org/info/rfc0902. ———. 1986a. “RFC901: Official ARPA-Internet Protocols.” 901. Request For Comments. https://www.rfc-editor.org/info/rfc901. ———. 1986b. “RFC944: Official ARPA-Internet Protocols.” 944. Request For Comments. https://www.rfc-editor.org/info/rfc944. ———. 1987. “Internet Numbers.” https://www.rfc-editor.org/rfc/pdfrfc/rfc997.txt.pdf. Reynolds, Joyce K., and J. Postel. 1987. “RFC1011: Official Internet Protocols.” https://www.rfc-editor.org/info/rfc1011. Reynolds, Joyce, and Jon Postel. 1983. “RFC870: Assigned Numbers.” https://www.rfc- editor.org/info/rfc870. Reynolds, J., and J. Postel. 1994. “RFC1700: Assigned Numbers.” 1700. Request For Comments. University of Southern California Information Sciences Institute. https://www.rfc-editor.org/info/rfc1700. RFC Editor. 1999. “30 Years of RFCs.” RFC 2555. https://www.rfc- editor.org/rfc/pdfrfc/rfc2555.txt.pdf. Roberts, Lawrence G. 1967. “Multiple Computer Networks and Intercomputer Communication.” Proceedings of the First ACM Symposium on Operating System Principles, 3.1–3.6. ———. 1970. “Memorandum for the Director, Program Management: Request for Amendment to AO 865 - University of California, Santa Barbara.” Records Group 330. College Park. National Archives and Records Administration. Maryland. https://www.archives.gov/college-park. ———. 1972a. “Incremental FUnding for the University of Illinois Center for Advanced Computation (ARPA Order 1899).” Records Group 330. College Park. National Archives and Records Administration. Maryland. https://archives.gov/college-park.

The Creation and Administration of Unique Identifiers, 1967-2017 115

———. 1972b. “Request for a New ARPA Order, Proposal from Keydata Corporation, 13 Nov SOURCES 72.” Records Group 330. College Park. National Archives and Records Administration. Maryland. https://www.archives.gov/college-park. ———. 1973a. “MEMORANDUM FOR THE DIRECTOR, PROGRAM MANAGEMENT. Subject: Initiation of a New Contract with Stanford University for Research in Intelligent Systems and Network Protocol Development.” Records Group 330. College Park. National Archives and Records Administration. Maryland. https://www.archives.gov/college-park. ———. 1973b. “Request for Amendment to ARPA Order 2344 - Mitre.” Records Group 330. College Park. National Archives and Records Administration. Maryland. https://www.archives.gov/college-park. Romano, S., and M. K. Stahl. 1987. “Internet Numbers.” 1020. Stanford Research Institute. https://www.rfc-editor.org/info/rfc1020. Rosen, E. C. 1982. “Exterior Gateway Protocol (EGP).” 827. Bolt Beranek and Newman Inc. https://www.rfc-editor.org/info/rfc0827. RSSAC. 2016. “RSSAC023: History of the Root Server System.” 23. Root Server System Advisory Committee and Internet Corporation for Assigned Names and Numbers. https://www.icann.org/en/system/files/files/rssac-023-04nov16-en.pdf. Rubio, Marco. 2012. “S.Con.Res.50 - 112th Congress (2011-2012): A Concurrent Resolution Expressing the Sense of Congress Regarding Actions to Preserve and Advance the Multistakeholder Governance Model under Which the Internet Has Thrived,” December. https://www.congress.gov/bill/112th-congress/senate-concurrent-resolution/50. Shapiro, E. B. 1968. “A Study of Computer Network Design Parameters.” 7016. Melno Park, California: Stanford Research Institute. Defense Technical Information Center. http://www.dtic.mil/docs/citations/AD0784954. Shapiro, Elmer B. 1968. “Untitled Report of ARPA Contractor Meeting Held at the University of Santa Barbara, California, on 22-23 August 1968.” Stanford Research Institute. Sirbu, M. A. 1988. “Content-Type Header Field for Internet Messages.” RFC 1049. https://www.rfc-editor.org/rfc/pdfrfc/rfc1049.txt.pdf. SRI Network Information Center, and Defense Communications Agency Defense Data Network Program Management Office. 1984. “Domain Names Transition.” Defense Data Network Management Bulletin, March 16, 1984. https://www.rfc-editor.org/rfc/museum/ddn-news/. Stahl, M. K. 1987. “Domain Administrators Guide.” RFC 1032. https://www.rfc- editor.org/rfc/pdfrfc/rfc1032.txt.pdf. Strazisar, Virginia, and Radia Perlman. 1978. “Gateway Routing: An Implementation Specification.” 30. Internet Experiment Note. IEN. Strickling, Lawrence E., and National Telecommunications and Information Administration. Letter to Stephen D. Crocker. January 6, 2017. https://www.icann.org/en/system/files/correspondence/strickling-to-crocker-06jan17- en.pdf. Su, Z. 1982. “Distributed System for Internet Name Service.” 830. Request For Comments. https://www.rfc-editor.org/info/rfc830.

The Creation and Administration of Unique Identifiers, 1967-2017 116

Su, Z., and J. Postel. 1982. “The Domain Naming Convention for Internet User Applications.” SOURCES 819. Request For Comments. https://www.rfc-editor.org/info/rfc819. Takizawa, Takashi. n.d. Hosts.txt. Github. Accessed September 22, 2018. https://github.com/ttkzw/hosts.txt. Taylor, R. W. (robert William). 1989. Oral history interview with R. W. Taylor Interview by William Aspray. Charles Babbage Institute. http://conservancy.umn.edu/handle/11299/107666. Teague, Olin. 1976. An Act to Establish a Science and Technology Policy for the United States, to Provide for Scientific and Technological Advice and Assistance to the President, to Provide a Comprehensive Survey of Ways and Means for Improving the Federal Effort in Scientific Research and Information Handling, and in the Use Thereof, to Amend the National Science Foundation Act of 1950, and for Other Purposes. https://www.congress.gov/bill/94th-congress/house-bill/10230. The Address Supporting Organization (ASO ICANN). 1999. “ASO Memorandum of Understanding.” https://aso.icann.org/documents/historical-documents/memorandum-of- understanding-1999/. United States Department of Commerce. 1999. “Amendment 19 to Cooperative Agreement # NCR 92-18742 Between NSI and U.S. Government.” NCR 92-18742. https://archive.icann.org/en/nsi/coopagmt-amend19-04nov99.htm. University of Southern California, and Internet Corporation for Assigned Names and Numbers. 1999. “USC/ICANN Transition Agreement.” https://www.icann.org/resources/unthemed- pages/usc-icann-transition-2012-02-25-en. U.S. Department of Commerce. 2012. “2012 IANA Functions Contract.” https://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2- final_award_and_sacs.pdf. U.S. Department of Commerce, and VeriSign, Inc. 2016. “Amendment to Award NCR- 92·18742.” https://www.ntia.doc.gov/files/ntia/publications/amendment_33.pdf. Vohra, Quaizar, and Enke Chen. 2007. “BGP Support for Four-Octet AS Number Space.” Request For Comments. https://www.rfc-editor.org/rfc/pdfrfc/rfc4893.txt.pdf. Walden, D. 2014. “The Arpanet IMP Program: Retrospective and Resurrection.” IEEE Annals of the History of Computing 36 (2): 28–39. Waldrop, M. Mitchell. 2001. The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal. 1ST edition. New York: Viking Adult. Watson, R. W. 1971a. “NIC View of Standard Host Names.” 237. Request For Comments. Stanford Research Institute. https://www.rfc-editor.org/info/rfc237. ———. 1971b. “What We Hope Is an Official List of Host Names.” 289. Request For Comments. Stanford Research Institute. https://www.rfc-editor.org/info/rfc289. Westheimer, E. 1971. “Site Status.” 235. Request For Comments. Bolt Beranek and Newman Inc. https://www.rfc-editor.org/info/rfc235. ———. 1972. “Network Host Status.” https://www.rfc-editor.org/rfc/pdfrfc/rfc376.txt.pdf. Westine, Ann, and Karen Roubicek. 1998. “January 1998 Internet Monthly Reports.” [IMR] IMR88-01.TXT. NSFNET Information Service.

The Creation and Administration of Unique Identifiers, 1967-2017 117

White, J. 1971. “A User TELNET Description of an Initial Implementation.” 206. Request For SOURCES Comments. University of California Santa Barbara. https://www.rfc-editor.org/info/rfc206. Williamson, S. 1993. “Transition and Modernization of the Internet Registration Service.” Transition Metal Chemistry. https://www.rfc-editor.org/info/rfc1400. Winett, J. M. 1971. “Definition of a Socket.” 147. Request For Comments. https://www.rfc- editor.org/info/rfc147. Yu, J. Y., and H. W. Braun. 1989. “Routing between the NSFNET and the DDN.” https://www.rfc-editor.org/rfc/pdfrfc/rfc1133.txt.pdf.

The Creation and Administration of Unique Identifiers, 1967-2017 118