Development of the Regional Internet Registry System

The current system of managing Internet address space involves Regional Internet Registries (RIRs), which together share a global responsibility delegated to them by the Internet Assigned Numbers Authority (IANA). This regime is now well established, but it has evolved over ten years from a much simpler, centralised system. Internet number spaces were originally managed by a single individual “authority,” namely the late Jon Postel, co-inventor of some of the most important technical features of today’s Internet.

It is important to understand that the evolution of the RIR system was not simply the result of Internet growth and the natural need to refine and decentralise a growing administrative task. On the contrary, it arose from, and closely tracked, the technical evolution of the Internet Protocol, in particular the development of today’s IP addressing and routing architecture.

In a relatively short time, the Regional Internet Registry system has evolved into a stable, robust environment for Internet address management. It is maintained today through self-regulatory practices that are well established elsewhere in the Internet and other industries, and it maintains its legitimacy and relevance by firmly adhering to open, transparent, participatory decision-making processes.

Before the RIRs:

IP Address Architecture

An important feature of the Internet Protocol (IP) is the ability to transparently use a wide variety of underlying network architectures to transport IP packets. This is achieved by encapsulating IP packets in whatever packet or frame structure the underlying network uses. Routers connecting different networks forward IP traffic by decapsulating incoming IP packets and then re-encapsulating them as appropriate for the next network to carry them.

To achieve this task with full transparency, the IP needed an addressing structure, which developed as a two-level hierarchy in both addressing and routing. One part of the address, the network part, identifies the particular network a host is connected to, while the other part, the local part, identifies the particular end system on that network.

Internet routing, then, has to deal only with the network part of the address, routing the packet to a router directly connected to the destination network. The local part is not used at all in Internet routing itself; rather it is used to determine the intended address within the addressing structure of the destination network.

The method by which the local part of an IP address is translated to a local network address depends on the architecture of the destination network— static tables, simple conversions, or special-purpose protocols are used as appropriate.

The original Internet addresses comprised 32 bits, the first 8 bits providing the network part and the remaining 24 bits the local part. These addresses were used for many years. However, in June 1978, in Internet Engineering Note (IEN) 46 “A proposal for addressing and routing in the internet,” Clark and Cohen observed:

“The current internet header has space to name 256 networks. The assumption, at least for the time being, is that any network entering the internet will be assigned one of these numbers. While it is not likely that a great number of large nets, such as the ARPANET, will join the internet, the trend toward local area networking suggests that a very large number of small networks can be expected in the internet in the not too distant future. We should thus begin to prepare for the day when there are more than 256 networks participating in the internet.”

Classful Addressing

As predicted, it soon became necessary to adapt the address architecture to allow more networks to be connected. By the time the Internet Protocol itself was comprehensively specified (in RFC 790, published in 1981, edited by Jon Postel), the IP address could be segmented in numerous ways to provide three classes of network address.

In Class A, the high-order bit is zero, the next 7 bits are the network, and the last 24 bits are the local address. In Class B, the high-order 2 bits are one-zero, the next 14 bits are the network, and the last 16 bits are the local address. In Class C, the high-order 3 bits are one-one-zero, the next 21 bits are the network, and the last 8 bits are the local address.

This so-called “classful” architecture served the Internet for the next 12 years, during which time it grew from a small U.S.-based research network to a global academic network showing the first signs of commercial development.

Early Registration Models

In the 1980s, the American National Science Foundation’s (NSF’s) high-speed network, NSFNET, was connected to the ARPANET, a U.S. Defense Advanced Research Projects Agency (ARPA, now DARPA) wide-area network, which essentially formed the infrastructure that we now know as the Internet.

From these early days of the Internet, the task of assigning addresses was a necessary administrative duty, to ensure simply that no two networks would attempt to use the same network address in the Internet.

At first, the elementary task of maintaining a list of assigned network addresses was carried out voluntarily by Jon Postel, using (according to legend) a paper notebook.

As the Internet grew, and particularly as classful addressing was established, the administrative task grew accordingly. The IANA was established, and within it the Internet Registry (IR). But as the task of the IR outgrew Postel’s notebook, it was passed to SRI International in Menlo Park, California, under a NSF contract, and was called the Defense Data Network (DDN) Network Information Center (NIC).

During this time, under the classful address architecture, networks were allocated liberally and to any organization that fulfilled the simple request requirements. However, with the accelerating growth of the Internet during the late 1980s, two problems loomed: the rapid depletion of address space, due to the crude classful divisions; and the uncontrolled growth of the Internet routing table, due to unaggregated routing information.

Conservation vs. Aggregation

The problems of “three sizes fit all” highlight the basic dilemma of address space assignment: conservation versus aggregation. On the one hand, one wants to conserve the address space by assigning as little as possible; on the other hand, one wants to ease routing-table pressures by aggregating as many addresses as possible in one routing-table entry.

This can be illustrated by looking at a typical networking setup of the time. Within organizations having a single Internet connection, buildings, departments, or campuses would have their own local networks. Often the use of multiple networks was dictated by distance limitations inherent in the emerging local-area networking technologies, such as Ethernet.

These networks typically had to accommodate more than the 254 hosts addressable by a Class C address, but would rarely exceed 1000 hosts. Using pure classful addressing, one could either subdivide networks artificially to remain below the 254 host limit, or use a Class B address for each local network, possibly wasting more than 60,000 addresses in each. Whereas the latter solution is obviously wasteful in terms of address space, the former is obviously cumbersome. Less obviously, the former also puts an additional burden on the Internet routing system, because each of these networks would require a separate route propagated throughout the whole Internet.

This basic dilemma persists to this day. Assigning address space generously tends to reduce the routing-table size, but wastes address space. Assigning conservatively will waste less, but cause more stress for the routing system.

Subnetting

In order to address some of the problems of classful addressing, the technique of subnetting was invented. Described in RFC 791 in 1984, subnetting provided another level of addressing hierarchy by inserting a subnet part into the IP address between the network and local parts. Global routing remained the same using the network part of the address (Class A, B, or C) until traffic reached a router on the network identified by the network part of the address. This router, configured for subnetting, would interpret a statically configured number of bits from the local part of the address (the subnet part) to route the packet further among a set of similarly configured routers. When the packet reached a router connected to the destination subnet, the remaining bits of the local part would be used to determine the local address of the destination as usual. So, in the previous example, the organization could have used a Class B address with 6-bit subnetting, a setup that would allow for 62 networks of 1022 hosts each.

Subnetting nicely solved the routing-table problem, because now only one global routing-table entry was needed for the organization. It also helped address space conservation somewhat because it provided an obvious alternative to using many sparsely populated Class B networks.

Because the boundary between the subnet part and the local part of an address could not be determined from the address itself, this local knowledge needed to be configured into the routers. At first this was done by static configuration. Later, interior routing protocols carried that information. Refer to RFC 791 for numerous historically interesting case studies.

Supernetting

Within seven years, however, it was becoming clear that subnetting was no longer sufficient to keep up with Internet growth. RFC 1338 stated the problem:

“As the Internet has evolved and grown … in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include:

• Exhaustion of the Class-B network address space. One fundamental cause of this problem is the lack of a network class of a size that is appropriate for a midsized organization; Class C, with a maximum of 254 host addresses, is too small while Class B, which allows up to 65534 addresses, is too large to be widely allocated.
• Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage.
• Eventual exhaustion of the 32-bit IP address space.

It has become clear that the first two of these problems are likely to become critical within the next one to three years.”

The solution proposed was to extend the subnetting technique beyond the local organization, into the Internet itself. In other words, RFC 1338 proposed abolishing classful addressing, and replacing it with supernetting. The proposal was summarized as follows:

“The proposed solution is to hierarchically allocate future IP address assignment, by delegating control of segments of the IP address space to the various network service providers.”

CIDR

In 1993, the supernetting technique was published as a standards track RFC under the name Classless Inter-Domain Routing (CIDR), by which it is known and used today. Two main ingredients were necessary to make CIDR work: routing system changes and new address allocation and assignment procedures.

Under CIDR, routers could no longer determine the network part of an address from the address itself. This information now needed to be conveyed by Internet routing protocols. Fortunately, there was only one such protocol in widespread use at the time, and it was quickly extended by the major router vendor of the time. According to legend, the necessary extensions of the Border Gateway Protocol (BGP)-3 to BGP-4 were designed on a napkin, with all implementors of significant routing software present. The changes were implemented in a matter of days, but only much later described by the Internet standards track RFC 1654.

CIDR also required that forwarding decisions of routers be changed slightly. The network part of an address, now more generally called the prefix, can be of any length. This means that a router can have multiple valid routes covering a specific 32-bit destination address. Routers need to use the most specific of these routes—the longest prefix—when forwarding packets.

In additional to technical changes, the success of CIDR also relied on the development of administrative procedures to allocate and assign address space in such a way that routes could be aggregated as much as possible. Because the Internet was evolving toward the current state of arbitrarily interconnected networks of Internet Service Providers (ISPs), it was obvious that ISPs should play a role in address space distribution. In the new technique, ISPs would now, as much as possible, assign address space to their customers in contiguous blocks, which could be aggregated into single routes to the rest of the Internet.

Emergence of the RIRs:

Internationalization

While the engineering-driven need for topological address space assignment was becoming clear, there was also an emerging recognition that the administrative mechanisms of address space distribution needed further development. A central system just would not scale for numerous reasons, including:

• Sheer volume
• Distance from the address space consumers
• Lack of an appropriate global funding structure
• Lack of local community support

The need to change administrative procedures was formally recognized by August 1990, when the Internet Activities Board published a message it had sent to the U.S. Federal Networking Council, stating “it is timely to consider further delegation of assignment and registration authority on an international basis” (RFC 1174).

The increasing cultural diversity of the Internet also posed administrative challenges for the central IR. In October 1992, the Internet Engineering Task Force (IETF) published RFC 1366, which described the “growth of the Internet and its increasing globalization” and set out the basis for an evolution of the registry process, based on a regionally distributed registry model. This document stressed the need for a single registry to exist in each geographical region of the world (which would be of “continental dimensions”). Registries would be “unbiased and widely recognized by network providers and subscribers” within their region. Each registry would be charged with allocating remaining address space in a manner “compatible with potential address aggregation techniques” (or CIDR).

RIPE NCC

While in the United States the Government continued to support and fund registry functions, this was not the case in other parts of the world. In Europe, IP network operators cooperating in Réseaux IP Européens (RIPE) realized the need for professional coordination and registration functions. Establishment of the RIPE Network Coordination Centre (NCC) was proposed in the same month that RFC 1174 was published. The RIPE NCC was to “”function as a ‘Delegated Registry’ for IP numbers in Europe, as anticipated and defined in RFC 1174″ (RIPE-19).

Although consensus among IP network operators was quickly established, it took almost two years of organizing and fund-raising before the first RIR was fully operational in May 1992. The RIPE NCC was organized as a highly independent part of RARE, the organization of European research networks. It was to be funded by contributions from those networks, as well as a small number of emerging commercial networks. The RIPE NCC published its first regional address distribution policy in July 1992 (RIPE-65).

During the following months, European regional policies were refined and, for the first time, global guidelines were published as RFCs (RFC 1366, RFC 1466).

The RIPE NCC is presently organized as a membership association, performing the essential coordination and administration activities required by the RIPE community. Located in Amsterdam, Netherlands, the RIPE NCC service region incorporates 109 countries covering Europe, the Middle East, Central Asia, and African countries located north of the equator. The RIPE NCC currently consists of more than 2700 members. At the time of publication, RIPE NCC is performing the secretariat function for the Address Supporting Organization (ASO) of The Internet Corporation for Assigned Names and Numbers (ICANN). More information about RIPE NCC is available at http://www.ripe.net

APNIC

Asia Pacific Network Information Centre (APNIC), the second RIR, was established in Tokyo in 1993, as a pilot project of APCCIRN (Asia Pacific Coordination Committee for Intercontinental Research Networks, now Asia Pacific Networking Group [APNG]).

The project was an intended as a trial model for servicing the Internet addressing needs of national Network Information Centres (NICs) and other networks throughout the region.

After a successful ten-month trial period, APNIC was established as a permanent organization to serve the Asia Pacific region (which includes 62 economies from Central and South Asia to the Islands of Oceania and the Western Pacific).

Originally, APNIC relied on the support of networking organizations and national NICs. However, in 1996, APNIC implemented a tiered membership structure.

APNIC relocated to Brisbane, Australia, in mid-1998. It currently services approximately 700 member organizations, across 39 economies of the region. Within the APNIC membership, there are also five National Internet Registries (NIRs), in Japan, China, Taiwan, Korea, and Indonesia. The NIRs perform analogous functions to APNIC at a national level and together represent the interests of more than 500 additional organizations.

In 2000, APNIC hosted the secretariat functions of the ASO in its inaugural year. More information about APNIC is available at: http://www.apnic.net

ARIN

In 1991, the contract to perform the IR function was awarded to Network Solutions, Inc. in Herndon, Virginia. This included the transition of services including IP address registration, domain name registration and support, Autonomous System Number (AS) registration, user registration, online information services, help-desk operations, and RFC and Internet-Draft archive and distribution services (RFC 1261).

With explosive Internet growth in the early 1990s, the U.S. Government and the NSF decided that network support for the commercial Internet should be separated from the U.S. Department of Defense. The NSF originated a project named InterNIC under a cooperative agreement with Network Solutions, Inc. (NSI) in 1993 to provide registration and allocation of domain names and IP address numbers for Internet users.

Over time, after lengthy consultation with the IANA, the IETF, RIPE NCC, APNIC, the NSF, and the Federal Networking Council (FNC), a further consensus was reached in the general Internet community to separate the management of domain names from the management of IP numbers. This consensus was based on the recognition that the stability of the Internet relies on the careful management of IP address space.

Following the examples of RIPE NCC and APNIC, it was recommended that management of IP address space then administered by the InterNIC should be under the control of, and administered by, those that use it, including ISPs, end-user organizations, corporate entities, universities, and individuals.

As a result, ARIN (American Registry for Internet Numbers) was established in December 1997, as an independent, nonprofit corporation, with a membership structure open to all interested entities or individuals.

ARIN is located in Chantilly, Virginia, United States. Its service region incorporates 70 countries, covering North America, South America, the Caribbean, and African countries located south of the equator. ARIN currently consists of more than 1500 members. Within the ARIN region, there are two national delegated registries, located in Mexico and Brazil.

Until now, ARIN has carried the responsibility for maintaining registration of resources allocated before the inception of the RIRs. However, a major project is now under way to transfer these legacy records to the relevant RIRs. More information about ARIN is available at: http://www.arin.net

Emerging RIRs

The existing RIRs currently serve countries outside their core regions to provide global coverage; however, new RIRs are expected to emerge, necessitating changes to the existing service regions. Because the regions are defined on continental dimensions, the number of new RIRs will be low.

Currently, two groups have made significant progress in seeking to establish new RIRs. AFRINIC (for the Africa region) and LACNIC (for Latin America and the Caribbean) have each conducted public meetings, published documentation, and participated in the activities of the existing RIRs. In recognition of the regional support they have so far obtained, each organization has been granted observer status at ICANN ASO meetings. The existing RIRs have also sought to provide as much assistance and support as possible to these emerging organizations.

More information about AFRINIC is available at: http://www.AFRINIC.org/

More information about LACNIC is available at: http://lacnic.org/

The RIR System:

Goals of the RIRs

RFC 2050, published in November 1996, represented a collaboration of the global Internet addressing community to describe a set of goals and guidelines for the RIRs. Although IANA was to retain ultimate responsibility for the entire address pool, RFC 2050 recognizes that RIRs operate under the consensus of their respective regional Internet community. This document, along with a history of RIR coordination, has helped to form the basis for a set of consistent global policies.

The three primary goals of the RIR system follow:

• Conservation: to ensure efficient use of a finite resource and to avoid service instabilities due to market distortions (such as stockpiling or other forms of manipulation);
• Aggregation (routability): to assist in maintenance of Internet routing tables at a manageable size, by supporting CIDR techniques to ensure continued operational stability of the Internet;
• Registration: to provide a public registry documenting address space allocations and assignments, necessary to ensure uniqueness and provide information for Internet troubleshooting at all levels.

The Open Policy Framework

It was always recognized that these goals would often be in conflict with each other and with the interests of individuals and organizations. It was also recognized that legitimate regional interests could justify varying approaches in balancing these conflicts. Therefore, within the global framework, each regional community has always developed its own specific policies and procedures.

However, whereas the specific approaches may differ across the RIRs, all operate on a basic principle of open, transparent, consensus-based decision-making, following self-regulatory practices that exist elsewhere in the Internet and other industries. Furthermore, the RIRs all maintain not-for-profit cost-recovery systems and organizational structures that seek to be inclusive of all interested stakeholders.

The activities and services of each of the RIRs are defined, performed, discussed, and evaluated in open forums, whose participants are ultimately responsible for decision-making.

To facilitate broad participation, open policy meetings are hosted by RIRs regularly in each of the regions. Ongoing discussions are carried out on the public mailing lists of each RIR, which are open to both the RIR constituents and the broader community. The RIRs also participate actively in other Internet conferences and organizations and, importantly, each RIR has a strong tradition of participating in the public activities of the others.

A current example of the coordinated efforts of the RIRs is the Provisional IPv6 Assignment and Allocation Policy Document, a joint effort of the RIRs with the assistance of the IETF, The Internet Architecture Board (IAB), and the Internet Engineering Steering Group (IESG) to describe the allocation and assignment policies for the first release of IPv6 address numbers.

Also, the RIRs recently published the RIR Comparative Policy Overview, which is available at: http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html (moved here).

These documents help illustrate that the well-established combination of bottom-up decision-making and global cooperation of the RIRs has created a stable, robust environment for Internet address management.

RIR Functions

The primary function of each RIR is to ensure the fair distribution and responsible management of IP addresses and the related numeric resources that are required for the stable and reliable operation of the Internet. In particular, the resources allocated, assigned, and registered by RIRs are Internet address numbers (IPv4 and IPv6) and AS numbers. RIRs are also responsible for maintaining the reverse delegation registrations of the parent blocks within their respective ranges.

Complementing their registry function, the RIRs have an important role in educating and informing their communities. The activities carried out by the individual RIRs vary, but include open policy meetings, training courses, seminars, outreach activities, statistical reporting, and research.

Additionally, a crucial role for the RIRs is to represent the interests of their communities by participating in global forums and providing support to other organizations involved in Internet addressing issues.

RIRs and The Global Internet Community:

Formation of ICANN and the ASO

The global Internet governance landscape began to undergo radical changes in mid-1998, with the publication of a U.S. Government white paper outlining the formation of a “not-for-profit corporation formed by private sector Internet stakeholders to administer policy for the Internet name and address system.” ICANN was formed later that year.

At the heart of the ICANN structure are “supporting organizations” that are formed to “assist, review and develop recommendations on Internet policy and structure” within specialized areas. In October 1999, the existing RIRs and ICANN jointly signed a Memorandum of Understanding (MoU) to establish the principles for forming and operating the Address Supporting Organization (ASO). It is intended that new RIRs will sign the MoU as they emerge.

Under the ASO MoU, the policy forums within each of the RIR regions continue to be responsible for development of regional IP address policy. In addition, each signatory RIR is responsible for electing three members to the ICANN Address Council.

The purpose of the Address Council, as described in the MoU, is to review and develop recommendations on issues related to IP address space, using the open processes that exist in the three regions; and to advise the ICANN Board on these matters. In addition, the Address Council is responsible for the appointment of three ICANN Directors to the ICANN Board.

RIR–ASO Coordination

Since the formation of the ASO, the RIRs have played an integral part in facilitating its activities. By joint agreement, the RIRs will share the ASO secretariat duties, including the hosting of the ASO Web site, on a revolving basis. APNIC provided these services in the ASO’s first year of operation, and RIPE NCC is currently performing this role.

The ASO Address Council holds monthly telephone conferences, which are attended by representatives of the RIRs (and emerging RIRs on a listener basis). In accordance with the MoU, the ASO also holds regular open meetings in conjunction with the open policy meetings of the RIRs.

RIRs and Industry Development

As noted previously, the RIRs maintain high levels of participation in the conferences and activities of other organizations. Similarly, they invite the participation of interested parties in their own activities.

The RIRs are active in many areas of new technology implementation (such as General Packet Radio Service [GPRS] and Universal Telecommunications System [UMTS] mobile telephony, IPv6, and cable and Digital Subscriber Line [xDSL]-based Internet services).

The established regional processes have proved both flexible and open enough to incorporate such new developments into policy formation. Industry representatives frequently join policy discussions, present at plenary sessions, and participate in working groups.

The RIRs pursue relationships with industry bodies, particularly those with representative and developmental functions, to facilitate industry convergence on open standards and policy processes.

Many diverse parties have legitimate interests in the allocation and registration of IP addresses, and the RIRs remain committed to participating with these parties to achieve a consensus among the Internet community on IP address allocation issues.

The Future of RIRs

In Internet time it can be easy to forget that eight years is actually not long. Since it was first proposed in 1990, the RIR system has evolved rapidly, enjoyed strong community support, and has been relatively free of the political wrangling that has characterized the registration systems of other Internet resources. Without doubt, this position is largely due to the early determination to provide accessible, open forums for the interested stakeholders in the various regions.

New technologies, such as GPRS, broadband services, and IPv6 may raise operational and policy challenges to the RIRs, yet at the same time they bring opportunities for increased global cooperation, in a context where distinct regional concerns are represented more effectively than ever before.

It is hoped that the emergence of new RIRs will only serve to expand and enhance the inclusive nature of RIR activities.

References

[1] Clark, D., and Cohen, D., “A Proposal for Addressing and Routing in the Internet,” IEN 46, June 1978.

[2] Postel, J., “Assigned Numbers,” RFC 790, September 1981.

[3] Information Sciences Institute, “Internet Protocol, DARPA Internet Program, Protocol Specification,” RFC 791, September 1981.

[4] Cerf, V., “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status,” RFC 1174, August 1990.

[5] Williamson, S., and Nobile, L., “Transition of NIC Services,” RFC 1261, September 1991.

[6] Fuller, V., Li, T., Yu, J., and Varadhan, K., “Supernetting: An Address Assignment and Aggregation Strategy,” RFC 1338, June 1992.

[7] Gerich, E., “Guidelines for Management of IP Address Space,” RFC 1366, October 1992.

[8] Gerich, E., “Guidelines for Management of IP Address Space,” RFC 1466, May 1993.

[9] Rekhter, Y., and Li, T., “A Border Gateway Protocol 4 (BGP-4),” RFC 1654, July 1994.

[10] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and Postel, J., “Internet Registry IP Guidelines,” RFC 2050, November 1996.

[11] Blokzijl, R., Devillers, Y., Karrenberg, D., and Volk, R., “RIPE Network Coordination Center,” RIPE-19, September 1990.

[12] Terpstra, M., “RIPE NCC Internet Numbers Registration Procedures,” RIPE-65, July 1992.

DANIEL KARRENBERG has helped to build the European Internet since the early 1980s. As one of the founding members of the German UNIX Users Group, he has been involved in the setting up of EUnet, a pan-European coperative network providing electronic mail and news to businesses and academic institutions all over Europe. While at CWI in Amsterdam, Karrenberg helped to expand this network and convert it to a fully IP-based service. During this time he created a whois database of operational contacts, which was the nucleus of the current RIPE database. Karrenberg is one of the founders of RIPE, the IP coordination body for Europe and surrounding areas. In 1992 he was asked to set up the RIPE NCC, the first regional Internet registry providing IP numbers to thousands of Internet service providers in more than 90 countries. Karrrenberg led the RIPE NCC until 1999, when it had an international staff of 59 with more than 20 nationalities; he currently helps to develop new RIPE NCC services. Recently his contributions have been recognized by the Internet Society with its Jon Postel Service Award. Karrenberg’s current interests include measurements of Internet performance and routing as well as security within the Internet infrastructure. In general he likes building new and interesting things. Mr. Karrenberg holds an MSc in computer science from Dortmund University. E-mail: Daniel.Karrenberg@ripe.net

GERARD ROSS holds a BA and LLB from University of Queensland and a Grad.Dip. (Communication) from Queensland Institute of Technology. He was employed as the technical writer at APNIC in 1998 and has been involved in the development and drafting of several major policy documents both in the APNIC region and as part of coordinated global RIR activities. He was the ASO webmaster in its inaugral year. He is currently the APNIC Documentation Manager. E-mail: gerard@apnic.net

PAUL WILSON has been Director-General of APNIC since August 1998. Previously, he was a founding staff member and subsequently Chief Executive Officer at Pegasus Networks, the first private ISP in Australia. Over an eight-year period he worked as a consultant to the United Nations and other international agencies on Internet projects in many countries. Since 1994, he has worked with the International Development Research Centre (IDRC) on its Pan-Asia Networking (PAN) Programme, supporting projects in Mongolia, Vietnam, Cambodia, Maldives, Nepal, Bhutan, PNG, and China. He continues to serve as a member of the PAN Research and Development Grants Comittee. E-mail: pwilson@apnic.net

LESLIE NOBILE received her B.A. from the American University in Washington, D.C. She has over 15 years of experience in the Internet field, and has been involved with the Internet Registry system since 1991. Prior to that, she held various technical management positions while working under a U.S. Government contract that supported the engineering and implementation of the Defense Data Network, a high-speed data network that evolved from the ARPANET. Her experience with the Registry system began in 1991 working as one of the Operations managers who transitioned the Internet Network Information Center (NIC) from SRI to Network Solutions, Inc. She remained a registration services manager with the DDN/DoD NIC until August 2000, when she became Director of Registration Services at the American Registry for Internet Numbers (ARIN). She has been a contributing author to RFCs, Internet Society (ISOC) articles, and various other industry publications and has been actively involved in the global coordination of Internet addressing policy. Her e-mail address is leslie@arin.net

Last modified on 31/07/2018