2.3 Who Owns the Internet?

only for RuBoard - do not distribute or recompile

Now that we've seen how the underlying Internet technology works, the next logical question to ask is, "Who do you complain to when the Internet stops working?" Another way of asking this question is, "Who runs the Internet?" And who owns it?

The Internet is a large, distributed network operated by millions of individuals and organizations. As such, it doesn't have a single owner it has many of them. When your computer is connected to the Internet it literally becomes part of the network, so in a very real sense you are one of the Internet's owners. But don't get carried away: you only own a very small part.

Let's look at the various other "owners" of the Internet.

2.3.1 Your Local Internet Service Provider

There are many ways that you can connect to the Internet. You can use a dial-up modem, a DSL line, an ISDN connection, a cable modem, or even a wireless link through your cellular phone. But no matter what sort of digital pipe you use to make the connection, at the other end of the pipe there needs to be a computer that receives your packets and routes them to other computers on the network.

The organization that operates the equipment on the other side of your Internet connection is referred to as an Internet service provider (ISP). The first ISPs were universities and research labs. They provided Internet service for their employees, students, affiliates, and frequently friends and family of the system operators.

Over the past two decades, the world of ISPs has been transformed. In the late 1980s, before commercial use of the Internet was allowed, most ISPs were poorly-funded small businesses run by the early Internet entrepreneurs. In the 1990s some of these ISPs grew large enough on their own funds that they could service tens or hundreds of thousands of customers. Others arranged for outside funding. Still more ISPs were started by wealthy individuals, banks, or venture capital funds, all seeking to get in on the Internet gold rush.

Today many universities still provide Internet service to their staff and students, and there are thousands of relatively small ISPs that provide service to a few thousand customers. But by far the majority of people who use the Internet in the United States now get their Internet service from a large ISP. Some of these large ISPs are either owned outright or affiliated with existing telephone companies and cable TV companies.

It's convenient to think of ISPs as owning their own part of the Internet. That is, most ISPs operate equipment and telecommunications systems that provide Internet service. These machines are the ISP's responsibility and they are, for the most part, under the ISP's control. When they operate properly, the ISP makes money (in theory, at least). When these systems don't work, the ISP loses money, receives angry phone calls, and eventually loses customers.

A typical ISP might operate, own or lease some or all of the following systems:

Domain nameservers, which translate host names to IP addresses.
Web servers, which store the content of web pages and send them over the network when the information on the web pages is requested.
Short and long distance data communications lines, which transmit Internet packets from one location to the other.
Data centers, where the computers reside that run their portion of the Internet. (Data centers typically include equipment racks, cabling, power systems, air conditioning systems, and physical security systems. See Figure 2-7.)
Network operations centers (NOCs), where the status and health of the network are monitored.

Figure 2-7. Two racks in a typical Internet data center (reprinted with permission of Switch and Data Corporation)

2.3.2 Network Access Points and Metropolitan Area Exchanges

For the Internet to function properly, packets must travel between ISPs. For example, the two ISPs serving the Walden network are AT&T, the cable ISP, and Megapath, the DSL ISP. But let's say that Simson wishes to send email to Debby, our editor at O'Reilly & Associates, which uses MCI WorldCom as its provider. There needs to be some place for the packets to travel from one of Simson's ISPs to O'Reilly's.

The easiest way for two ISPs to exchange Internet traffic with each other is for the ISPs to purchase a data circuit between a data center belonging to the first ISP and a data center belonging to the second ISP. But if more than a few ISPs wish to exchange traffic with each other, a much more cost-effective method is for the ISPs to rent space at a common location and to put multiple routers belonging to the different organizations on the same local area network.

In 1993, the National Science Foundation awarded MCI WorldCom a contract to set up a number of Network Access Points (NAPs) to facilitate communications between ISPs that were providing access to universities as part of the academic Internet. Since then, the number of Network Access Points has mushroomed. Two of the most successful are the Metropolitan Area Exchanges operated by MCI WorldCom in Northern Virginia (MAE East) and in San Jose (MAE West).

Once an ISP has rented space at a NAP or MAE and installed its equipment, two more important events need to take place before the ISP can exchange traffic. First, the ISP needs to lease or purchase one or more high-speed data circuits from the NAP or MAE to the ISP's own facilities. Second, the ISP needs to make a deal with one or more other ISPs to exchange the actual traffic. Such deals are referred to as either peering agreements or transit agreements.

2.3.2.1 Peering

Peering is the simplest way for two ISPs to interconnect. The two ISPs exchange electronic maps of each other's networks. Each ISP then programs its routers so that if the router receives a packet for the other ISP, the packet is automatically sent to the peering point and over the shared connection. Peering makes good financial and technical sense if two ISPs have a lot of users that typically access each other's services.^[16] For example, in Cambridge, AT&T's cable modem network peers with the university networks for both MIT and Harvard. As a result, the round-trip time between the Walden network and the MIT network is less than 3 milliseconds:

^[16] Although the financial aspects of peering agreements are usually kept secret, they typically do not involve the exchange of money between the two peered ISPs. More frequently, peering agreements involve the exchange of favors between engineers or network architects at the ISPs favors such as technical assistance, high-quality sushi dinners, or additional peering agreements.

walden% traceroute web.mit.edu traceroute to web.mit.edu (18.7.21.70), 30 hops max, 40 byte packets  1  24.147.16.1 (24.147.16.1)  2.309 ms  1.885 ms  2  CMBRMA1-RTR01-CMBRMA1-RTR02.ne.mediaone.net (24.128.190.85)  3.394 ms  2.034 ms  3  bsgsr01-srp4.rr.com (24.218.189.169)  2.481 ms  2.349 ms  4  cmbrt01-srp3.rr.com (24.218.189.172)  2.391 ms  2.792 ms  5  MIT-MEDIAONE.MIT.EDU (18.3.1.1)  2.692 ms  2.506 ms   6  W92-RTR-1-BACKBONE.MIT.EDU (18.168.0.20)  3.499 ms  3.453 ms   7  SALTICUS-PECKHAMAE.MIT.EDU (18.7.21.70) 3.245 ms 3.245 ms walden%

The disadvantage of peering is that two ISPs that are in a peering agreement can only send traffic to each other that is destined for each other's network.

2.3.2.2 Transit

The alternative to peering is called transit. You can think of transit as a promise between the two ISPs: the ISP providing the transit promises the second ISP that it will deliver the other's traffic to wherever the traffic is going on the Internet, no matter whether the traffic's ultimate destination is within the first ISP's network or on some other ISP's network.

Unlike peering, which is normally bartered, transit is invariably purchased. Typically, smaller ISPs purchase transit from larger ISPs. Like peering, the financial aspects of transit deals are usually secret. Unlike peering, transit is almost always very expensive.

The Walden DSL ISP appears to purchase transit from Exodus, a company that specializes in operating Internet data centers. We can determine this by looking at the traceroutes of packets sent between Simson's home network and the same web server at MIT:

Walden2% traceroute -q 2 web.mit.edu traceroute to web.mit.edu (18.7.21.77), 30 hops max, 40 byte packets  1  SIMSON.NET (64.7.15.233)  1.083 ms  1.040 ms   2  sdsl-216-36-94-1.dsl.bos.megapath.net (216.36.94.1)  62.548 ms  32.031 ms   3  64.28.72.98 (64.28.72.98)  20.712 ms  19.834 ms   4  64.14.80.153 (64.14.80.153)  33.078 ms  16.630 ms   5  ibr02-g2-0.wlhm01.exodus.net (64.14.70.69)  16.621 ms 27.349 ms  6  p5-1.bstnma1-cr7.bbnplanet.net (4.24.92.101)  15.617 ms  15.742 ms  7  p5-0.bstnma1-ba2.bbnplanet.net (4.24.4.225)  15.632 ms  15.818 ms   8  p1-0.bstnma1-ba1.bbnplanet.net (4.24.4.193)  14.564 ms  14.410 ms   9  p5-2.cambridge1-nbr1.bbnplanet.net (4.0.2.173)  15.337 ms  15.443 ms 10  p1-0-0.cambridge1-br1.bbnplanet.net (4.0.1.22)  14.880 ms  14.812 ms 11  h3-0.cambridge2-br2.bbnplanet.net (4.0.1.202)  16.325 ms  20.244 ms 12  ihtfp.mit.edu (192.233.33.3)  20.664 ms  18.496 ms 13  W92-RTR-1-BACKBONE.MIT.EDU (18.168.0.20)  33.733 ms 34.790 ms 14  SICARIUS-SPATULATUS.MIT.EDU (18.7.21.77)  40.954 ms 53.178 ms Walden2%

This traceroute was done a few minutes after the traceroute from Walden using the cable modem. As you can see, the network connection has tenfold higher latency than the preceding one. Part of the speed difference can be attributed to the difference between the cable modem connection and the DSL connection, but part of the difference is caused by the longer path that the packets need to follow.

2.3.3 The Root and Top-Level Nameservers

Most ISPs will operate DNS servers for their own customers. But that's only half the story. When Simson's desktop computer attempted to resolve the name www.icann.org, the computer first went to one of the root domain nameservers to get the address for the org domain nameserver. It then went to the org domain nameserver to get the address for the icann.org domain nameserver. Without root and top-level domain nameservers, the DNS could not function properly.

So how does a DNS server find the root nameservers to start the whole process? Currently, this information is distributed in a file that is provided with most Unix operating systems. (Overwhelmingly, it is Unix systems that run the Internet's DNS infrastructure.) The current root nameserver file contains 13 entries in this file, with the names A.ROOT-SERVERS.NET through M.ROOT-SERVERS.NET.

2.3.3.1 Who runs the root?

Perhaps nowhere is the Internet's history as a project between the U.S. Department of Defense and America's universities more evident than in the ownership and operation of these 13 nameservers. In February 2001, more than 25 years after the Internet's founding, six of the Internet's 13 root servers were still being operated by the U.S. military, U.S. government, U.S. universities, and U.S. military contractors. The list of root nameservers is in Table 2-1.

Table 2-1. Root nameservers on February 1, 2001
Official name	Original name	Operating agency
A.ROOT-SERVERS.NET.	NS.INTERNIC.NET	Network Solutions, Inc.
B.ROOT-SERVERS.NET.	NS1.ISI.EDU	University of Southern California Information Sciences Institute
C.ROOT-SERVERS.NET.	C.PSI.NET	PSINet, Inc
D.ROOT-SERVERS.NET.	TERP.UMD.EDU	University of Maryland
E.ROOT-SERVERS.NET.	NS.NASA.GOV	National Aeronautics and Space Administration
F.ROOT-SERVERS.NET.	NS.ISC.ORG	Internet Software Consortium
G.ROOT-SERVERS.NET.	NS.NIC.DDN.MIL	U.S. Department of Defense Defense Data Network
H.ROOT-SERVERS.NET.	AOS.ARL.ARMY.MIL	U.S. Army
I.ROOT-SERVERS.NET.	NIC.NORDU.NET	Nordic national networks for research and education
J.ROOT-SERVERS.NET.	-	Network Solutions, Inc.
K.ROOT-SERVERS.NET.	-	RIPE Network Coordination Centre
L.ROOT-SERVERS.NET.	-	University of Southern California Information Sciences Institute
M.ROOT-SERVERS.NET.	-	Asia Pacific Network Information Center

Each root domain server maintains a list of top-level generic domains (e.g., .com, .net, .org, .gov, and so on), and the roughly 250 top-level domains associated with country codes (e.g., .uk for the United Kingdom, .ca for Canada). With the exception of the master root server, A.ROOT-SERVERS.NET, all of the top-level domains are run on computers that are not directly associated with the master root servers.

2.3.3.2 An example

For example, if you ask the root server A.ROOT-SERVERS.NET for the address of ICANN.ORG's domain server, you will get it:

% dig @a.root-servers.net icann.org ; <<>> DiG 8.3 <<>> @a.root-servers.net icann.org  ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 ;; QUERY SECTION: ;;      icann.org, type = A, class = IN ;; AUTHORITY SECTION: icann.org.              2D IN NS        NS.APNIC.NET. icann.org.              2D IN NS        NS.ISI.EDU. icann.org.              2D IN NS        VENERA.ISI.EDU. icann.org.              2D IN NS        NS.RIPE.NET. icann.org.              2D IN NS        RIP.PSG.COM. icann.org.              2D IN NS        SVC00.APNIC.NET. ;; ADDITIONAL SECTION: NS.APNIC.NET.           2D IN A         203.37.255.97 NS.ISI.EDU.             2D IN A         128.9.128.127 VENERA.ISI.EDU.         2D IN A         128.9.176.32 NS.RIPE.NET.            2D IN A         193.0.0.193 RIP.PSG.COM.            2D IN A         147.28.0.39 SVC00.APNIC.NET.        2D IN A         202.12.28.131 ;; Total query time: 133 msec ;; FROM: r2.nitroba.com to SERVER: a.root-servers.net  198.41.0.4 ;; WHEN: Wed Feb  7 11:17:14 2001 ;; MSG SIZE  sent: 27  rcvd: 261 %

But if you ask the same question of the root server C.ROOT-SERVERS.NET, you will be advised to seek your answer elsewhere at one of the generic top-level domain servers for the org domain:

% dig @c.root-servers.net icann.org ; <<>> DiG 8.3 <<>> @c.root-servers.net icann.org  ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 12 ;; QUERY SECTION: ;;      icann.org, type = A, class = IN ;; AUTHORITY SECTION: org.                    6D IN NS        A.ROOT-SERVERS.NET. org.                    6D IN NS        E.GTLD-SERVERS.NET. org.                    6D IN NS        F.GTLD-SERVERS.NET. org.                    6D IN NS        J.GTLD-SERVERS.NET. org.                    6D IN NS        K.GTLD-SERVERS.NET. org.                    6D IN NS        A.GTLD-SERVERS.NET. org.                    6D IN NS        M.GTLD-SERVERS.NET. org.                    6D IN NS        G.GTLD-SERVERS.NET. org.                    6D IN NS        C.GTLD-SERVERS.NET. org.                    6D IN NS        I.GTLD-SERVERS.NET. org.                    6D IN NS        B.GTLD-SERVERS.NET. org.                    6D IN NS        D.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4 E.GTLD-SERVERS.NET.     6D IN A         207.200.81.69 F.GTLD-SERVERS.NET.     6D IN A         198.17.208.67 J.GTLD-SERVERS.NET.     6D IN A         210.132.100.101 K.GTLD-SERVERS.NET.     6D IN A         213.177.194.5 A.GTLD-SERVERS.NET.     6D IN A         198.41.3.38 M.GTLD-SERVERS.NET.     6D IN A         202.153.114.101 G.GTLD-SERVERS.NET.     6D IN A         198.41.3.101 C.GTLD-SERVERS.NET.     6D IN A         205.188.185.18 I.GTLD-SERVERS.NET.     6D IN A         192.36.144.133 B.GTLD-SERVERS.NET.     6D IN A         203.181.106.5 D.GTLD-SERVERS.NET.     6D IN A         208.206.240.5 ;; Total query time: 376 msec ;; FROM: r2.nitroba.com to SERVER: c.root-servers.net  192.33.4.12 ;; WHEN: Wed Feb  7 11:18:33 2001 ;; MSG SIZE  sent: 27  rcvd: 440 %

Finally, if you should ask A.ROOT-SERVERS.NET for the domain server of a domain that is in England, you're likely to be referred to some nameservers on the other side of the Atlantic:

% dig @a.root-servers.net virgin.co.uk ; <<>> DiG 8.3 <<>> @a.root-servers.net virgin.co.uk  ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5 ;; QUERY SECTION: ;;      virgin.co.uk, type = A, class = IN ;; AUTHORITY SECTION: UK.                     2D IN NS        NS1.NIC.UK. UK.                     2D IN NS        NS.EU.NET. UK.                     2D IN NS        NS0.JA.NET. UK.                     2D IN NS        NS.UU.NET. ;; ADDITIONAL SECTION: NS1.NIC.UK.             2D IN A         195.66.240.130 NS.EU.NET.              2D IN A         192.16.202.11 NS0.JA.NET.             2D IN A         128.86.1.20 NS0.JA.NET.             2D IN A         193.63.94.20 NS.UU.NET.              2D IN A         137.39.1.3 ;; Total query time: 136 msec ;; FROM: r2.nitroba.com to SERVER: a.root-servers.net  198.41.0.4 ;; WHEN: Wed Feb  7 11:19:42 2001 ;; MSG SIZE  sent: 30  rcvd: 198 %

For the most part, the ownership and operation of these domain nameservers is transparent to most of the Internet's users. The nameservers are an incredibly critical part of the Internet, and as a result they are carefully watched and maintained. Moreover, because there are 13 separate root nameservers, the majority of them can be down without significantly affecting the reliability of the Internet.

But every now and then there is a problem that affects all of the domain nameservers. When things go wrong, there is not much that most users of the Internet can do except wait for the outage to pass or fall back on using IP addresses instead of host names provided that you know the IP address of the web server you wish to reach.

2.3.4 The Domain Registrars

The database of domain names and IP addresses for each top-level domain is maintained by an organization called an Internet registrar. These organizations maintain a database for their top-level domain and of all the subdomains, consisting of a list of all of the domains, the IP address for each domain server, and the names of the individuals who are authorized to make changes in the records.

For most of the 1990s, the Virginia-based government contractor Network Solutions, Inc., maintained registration services for the Internet's generic top-level domains as part of a contract that was issued by the National Science Foundation, and then later by the U.S. Department of Commerce. In 1999, the services provided by NSI were split into two pieces. Although Network Solutions maintained monopoly control over the backend database, the aspects of the business that involve taking orders and payments from the public were opened to a competitive process. There are now more than two dozen corporations that are authorized to register names in the top-level domains com, net, and org. We'll describe Network Solutions' role and history in greater detail in the final section of this chapter.

2.3.5 Internet Number Registries

Just as the proper functioning of the Internet relies on the fact that no two organizations can have the same domain name, proper functioning of the Internet also requires that no two organizations use the same IP address.

Most organizations and individuals that connect to the Internet use IP addresses that are borrowed from their upstream provider. But in some cases, it makes sense for organizations to have their own IP addresses. For example, a medium-to-large ISP that peers with a variety of other ISPs needs to have its own IP addresses for the peering and routing protocols to function properly. There are also many large organizations that want to have their own IP addresses so that their networks do not need to be renumbered if the organization changes Internet service providers.

Until 1996, Internet IP addresses were freely available for the asking. Since then, IP addresses have been distributed by regional Internet number registries. In North America, IP addresses allocations are controlled by ARIN, the American Registry of Internet Numbers.

2.3.6 The Internet Corporation for Assigned Names and Numbers

Created in 1998 by Joe Sims, an attorney in Washington, D.C., and later awarded a contract by the National Telecommunications and Information Administration (NTIA), the Internet Corporation for Assigned Names and Numbers (ICANN) is a nonprofit California corporation that has responsibility for assigning and managing IP address space, protocol parameters, the DNS root servers, and management in general of the Domain Name Service. This responsibility theoretically makes ICANN the arbitrator of all Internet policy issues having to do with allocation policy.^[17]

^[17] Information in this section is from the ICANN web site http://www.icann.org/, and from the Center for Democracy and Technology's Domain Name Management Policy Report, http://www.cdt.org/dns/icann/study/.

You may wonder why the NTIA, a unit of the U.S. Department of Commerce, gave a California-based corporation that is controlled by a board of directors with extremely limited public accountability the power to manage a public resource such as the Internet. Or you may wonder how it came to be that a branch of the U.S. government had power over the Internet in the first place. Or you may wonder if ICANN is really in control of the Internet, because its authority comes by right of a contract that it was granted by the U.S. government, rather than from the Internet's actual owners, users, and operators.

ICANN's short and somewhat torturous history is the result of the origin of the Internet itself. Started as a Department of Defense research project, one of the original government contractors for the network development was the University of California at Los Angeles (UCLA). At UCLA, a graduate student, Jon Postel, took it upon himself to maintain the Internet's list of host names and to edit and maintain the Requests for Comments (RFCs) that were prepared by the ARPANET research. The original Internet had no central coordinating authority for names and numbers.

Postel was widely respected for both his technical skills and his ability as a technical mediator. In March 1977, Postel moved from UCLA to the Information Sciences Institute (ISI) at the University of Southern California. Postel devoted much of his work to documenting the design of protocols, the allocation of addresses, and the creation of procedures for the Internet, from its inception through its first three decades. As the task grew, Postel began to delegate the job to graduate students, but he maintained technical oversight. As the importance of this project became clear, Postel coined the term "Internet Assigned Numbers Authority" to describe the unincorporated, voluntary organization that coordinated the assignment process. His friends called him the "Numbers Czar."

IANA proved to be critical to the proper functioning of the Internet. The problem wasn't so much the rational allocation of scarce resources, but the coordination of multiple parties that needed unique addresses, identifiers, and port numbers. Consider that there are 65,535 TCP port numbers. That's quite a lot, considering that each port might be used for a different Internet protocol, and that only a few dozen protocols are widely used. The telnet protocol is assigned to port 23; the SMTP protocol is assigned to port 25; HTTP is assigned to port 80; and so on. But somebody needed to make sure that no two developers would accidentally choose the same port number for the same protocol. That was IANA's job. It did the same thing for IP address space and domain names that is, it made sure that two different people didn't pick the same domain name.

As the Internet grew in the 1980s into thousands of hosts, the registration process became too much for Postel and his graduate students to handle. DARPA wrote a contract to SRI International for the management of the Network Information Center, which soon was known as SRI-NIC. When universities became the dominant users, management and funding of the NIC was transferred from DARPA to the National Science Foundation. In 1993, the NSF wrote three contracts for the management of the Internet. They were awarded to General Atomics, AT&T, and a new company called Network Solutions. The first two contracts were for managing different aspects of directory services what would later become known as search engines. Both Atomics International and AT&T failed to produce anything tremendously interesting. The third contract was for the management of the DNS.

From the Internet's birth until the mid-1990s, Internet resources other than bandwidth, hardware, and consulting time were largely free. Specifically, neither IANA nor SRI-NIC charged for domain names or IP address space. But the one thing that was not free was the growing management burden. Network Solutions' contract was originally for a set fee plus an overhead cost. But in 1995, complaining that it simply could not keep up with the Internet's growth without substantial investment, Network Solutions sought and was granted permission to charge a $50/year fee for each newly registered domain name.^[18] This charge was allowed under Amendment #4 of the original contract, rather than having a new contract put out for competitive bid. This fee proved to be a significant revenue source. Based on Network Solution's position as the Internet's sole registrar, the company achieved significant growth and investment, and in September 1997 staged a tremendously successful initial public offering (IPO) of its stock, with a 40% increase in value on the first day despite the fact that its five-year contract to manage the NIC was due to expire in March 1998.

^[18] The $50 included a $35 fee and $15 that was provided to the U.S. government for "infrastructure." The $15 charge was declared to be an illegal tax, but Congress enacted special legislation to allow the fee to be retained rather than refunded.

The growing wealth of Network Solutions and the power that the company enjoyed through its control of the Domain Name System was not lost upon policy makers in Washington, D.C. On July 1, 1997, President Clinton directed the Secretary of Commerce to privatize the Domain Name System in a manner that would "increase competition and facilitate international participation in its management."^[19] The following day, the Department of Commerce issued a request for proposals on how the DNS administration should be redesigned. On January 30, 1998, the National Telecommunications and Information Administration (NTIA), an agency of the Department of Commerce, published "A Proposal to Improve the Technical Management of Internet Names and Addresses." This was published in the Federal Register on February 20, referred to as the "Green Paper," and put up for public comment. Six months later, the Department of Commerce issued a "White Paper," which largely codified the policy statements of the Green Paper.

^[19] "Management of Internet Names and Addresses," U.S. Department of Commerce, Docket Number 980212036-8146-02. Currently archived at http://www.icann.org/general/white-paper-05jun98.htm.

The key goals of the Internet corporation envisioned by the Department of Commerce were:

Stability: "During the transition and thereafter, the stability of the Internet should be the first priority of any DNS management system."
Competition: "Where possible, market mechanisms that support competition and consumer choice should drive the management of the Internet because they will lower costs, promote innovation, encourage diversity, and enhance user choice and satisfaction."
Private sector, bottom-up coordination: "A private coordinating process is likely to be more flexible than government and to move rapidly enough to meet the changing needs of the Internet and of Internet users. The private process should, as far as possible, reflect the bottom-up governance that has characterized development of the Internet to date."
Representation: "Management structures should reflect the functional and geographic diversity of the Internet and its users. Mechanisms should be established to ensure international participation in decision making."

Joe Sims was Postel's attorney. His law firm drafted the incorporation document and charter for an organization called the Internet Corporation for Assigned Names and Numbers (ICANN). The Department of Commerce accepted the proposal in September 1998. Then Postel suffered a heart attack and died on October 16, 1998.

In the days following Postel's death, Sims contacted a number of individuals and told them that they had been chosen for ICANN's board. Esther Dyson was chosen as ICANN's Interim Chairman of the Board and Michael M. Roberts was chosen as ICANN's Interim President and Chief Executive Officer. A board of directors was selected and the organization had its first board meeting at an airport in New York City. The first public meeting followed on November 14-15, 1998, in Cambridge, Massachusetts.

ICANN was not the only possibility for Internet governance. One was the International Forum on the White Paper, of which Michael Robers was one of the leaders (see http://www.domainhandbook.com/ifwp.html). Another was the Boston Working Group (see http://www.cavebear.com/bwg). The means by which NTIA chose the ICANN proposal over the others remains unclear.

Since its first meeting, ICANN has licensed additional companies to compete with Network Solutions for registration services (although NSI still operates the backend domain database), and the company has authorized the creation of several new top-level domains. ICANN has also organized a worldwide Internet election for its "at large" membership and has allowed that membership to elect a number of "at large directors."

As of this writing in September 2001, ICANN has not lived up to many of the white paper's goals. The DNS remains relatively stable there have been no serious outages or interruptions of service. But attempts to create more than a token number of new top-level domains have been stymied by ICANN's go-slow approach. There is essentially no "bottom up," private sector coordination or "representation."

On the other hand, ICANN's power really does come from the consent of the governed. If the major ISPs wished to do so, they could do away with ICANN and set up a replacement organization. They could revise the way that the top-level domains are managed and the rules governing IP address assignment. The ISPs don't do this because ICANN works, overall at least it works well and cheaply enough that the ISPs can afford to let it continue doing what it is doing while the ISPs concentrate on the task of making money.

Whether or not ICANN will suceed in the long run is unclear. But if ICANN fails, the ISPs will need to set up something a lot like ICANN to replace it, if for no other reason than to assure that people do not pick the same names and numbers for different computers and protocols.

only for RuBoard - do not distribute or recompile

2.3 Who Owns the Internet?