RFC 1192: Commercialization of the Internet Summary Report

RFC 1192: Commercialization of the Internet summary report | RFC Editor
Skip to content
Info
RFC
1192
:
Commercialization of the Internet summary report
B. Kahin
Informational
Network Working Working Group                           B. Kahin, Editor
Request for Comments: 1192                                       Harvard
                                                           November 1990
Commercialization of the Internet
Summary Report
Status of this Memo

   This memo is based on a workshop held by the Science, Technology and
   Public Policy Program of the John F. Kennedy School of Government,
   Harvard University, March 1-3, 1990.

   This memo provides information for the Internet community.  It does
   not specify any standard.  Distribution of this memo is unlimited.

Introduction

   "The networks of Stages 2 and 3 will be implemented and operated so
   that they can become commercialized; industry will then be able to
   supplant the government in supplying these network services."  --
   Federal Research Internet Coordinating Committee, Program Plan for
   the National Research and Education Network, May 23, 1989, pp. 4-5.

   "The NREN should be the prototype of a new national information
   infrastructure which could be available to every home, office and
   factory.  Wherever information is used, from manufacturing to high-
   definition home video entertainment, and most particularly in
   education, the country will benefit from deployment of this
   technology....  The corresponding ease of inter-computer
   communication will then provide the benefits associated with the NREN
   to the entire nation, improving the productivity of all information-
   handling activities.  To achieve this end, the deployment of the
   Stage 3 NREN will include a specific, structured process resulting in
   transition of the network from a government operation a commercial
   service."  -- Office of Science and Technology Policy, The Federal
   High Performance Computing Program, September 8, 1989, pp. 32, 35.

   "The National Science Foundation shall, in cooperation with the
   Department of Defense, the Department of Energy, the Department of
   Commerce, the National Aeronautics and Space Administration, and
   other appropriate agencies, provide for the establishment of a
   national multi-gigabit-per-second research and education computer
   network by 1996, to be known as the National Research and Education
   Network, which shall:

        (1) link government, industry, and the education
Kahin                                                           [Page 1]
RFC 1192
Commercialization of the Internet       November 1990
community;
             ....
             (6) be established in a manner which fosters and
        maintains competition and private sector investment in high
        speed data networking within the telecommunications
        industry;
             ....
             (8) be phased out when commercial networks can meet the
        networking needs of American researchers."

   -- S. 1067, 101st Congress, 2nd Session, as marked up April 3, 1990
   ["High-Performance Computing Act of 1990"], Title II,
Section 201
.

Background

   This report is based on a workshop held at the John F. Kennedy School
   of Government, Harvard University March 1-3, 1990, by the Harvard
   Science, Technology and Public Policy Program.  Sponsored by the
   National Science Foundation and the U.S.  Congress Office of
   Technology Assessment, the workshop was designed to explore the
   issues involved in the commercialization of the Internet, including
   the envisioned National Research and Education Network (NREN).
   Rather than recapitulate the discussion at the workshop, this report
   attempts to synthesize the issues for the benefit of those not
   present at the workshop.  It is intended for readers familiar with
   the general landscape of the Internet, the NSFNET, and proposals and
   plans for the NREN.

   At the workshop, Stephen Wolff, Director of the NSF Division of
   Networking and Communications Research and Infrastructure,
   distinguished "commercialization" and "privatization" on the basis of
   his experience developing policy for the NSFNET.  He defined
   commercialization as permitting commercial users and providers to
   access and use Internet facilities and services and privatization as
   the elimination of the federal role in providing or subsidizing
   network services.  In principle, privatization could be achieved by
   shifting the federal subsidy from network providers to users, thus
   spurring private sector investment in network services.  Creation of
   a market for private vendors would in turn defuse concerns about
   acceptable use and commercialization.

Commercialization and Privatization

   Commercialization.  In the past, many companies were connected to the
   old ARPANET when it was entirely underwritten by the federal
   government.  Now, corporate R&D facilities are already connected to,
   and are sometimes voting members of, mid-level networks.  There are
   mail connections from the Internet to commercial services such as
Kahin                                                           [Page 2]
RFC 1192
Commercialization of the Internet       November 1990
MCIMAIL, SprintMail, and Compuserve.  DASnet provides a commercial
   mail gateway to and from the Internet and commercial mail services.
   UUNET, a nonprofit corporation, markets TCP/IP services (Alternet)
   with access to the Internet as well as mail services.  Performance
   Systems International (PSI), a startup company which now operates
   NYSERNET (the New York State regional network, partially funded by
   NSF) is aggressively marketing Internet-connected TCP/IP services on
   the East and West Coasts.  RLG is selling access to its RLIN database
   over the Internet directly to end users.  Other fee-based services
   include Clarinet, a private news filtering service, and FAST, a non-
   profit parts brokering service.  However, in all these cases, any use
   of the NSFNET backbone must, in principle, support the "purpose of
   the NSFNET."

   Under the draft acceptable use policy in effect from 1988 to mid-
   1990, use of the NSFNET backbone had to support the purpose of
   "scientific research and other scholarly activities."  The interim
   policy promulgated in June 1990 is the same, except that the purpose
   of the NSFNET is now "to support research and education in and among
   academic institutions in the U.S. by access to unique resources and
   the opportunity for collaborative work."  Despite this limitation,
   use of the NSFNET backbone has been growing at 15-20% per month or
   more, and there are regular requests for access by commercial
   services.  Even though such services may, directly or indirectly,
   support the purposes of the NSFNET, they raise prospects of
   overburdening network resources and unfair competition with private
   providers of network services (notably the public X.25 packet-
   switched networks, such as SprintNet and Tymnet).

   Privatization.  In some respects, the Internet is already
   substantially privatized.  The physical circuits are owned by the
   private sector, and the logical networks are usually managed and
   operated by the private sector.  The nonprofit regional networks of
   the NSFNET increasingly contract out routine operations, including
   network information centers, while retaining control of policy and
   planning functions.  This helps develop expertise, resources, and
   competition in the private sector and so facilitates the development
   of similar commercial services.

   In the case of NSFNET, the annual federal investment covers only a
   minor part of the backbone and the regional networks.  Although the
   NSFNET backbone is operated as a cooperative agreement between NSF
   and Merit, the Michigan higher education network, NSF contributes
   less than $3 million of approximately $10 million in annual costs.
   The State of Michigan Strategic Fund contributes $1 million and the
   balance is covered by contributed services from the subcontractors to
   Merit, IBM and MCI.
Kahin                                                           [Page 3]
RFC 1192
Commercialization of the Internet       November 1990
At the regional level, NSF provides approximately 40% of the
   operating costs of the mid-level networks it funds -- with the
   remainder covered by membership and connection fees, funding from
   state governments, and in-kind contributions.  This calculation does
   not include a number of authorized networks (e.g., PREPnet, and,
   until recently, NEARnet and CERFnet) that receive no NSF funding.
   However, NSF also funds institutional connections to the NSFNET,
   which includes payments by the institution to the regional network.
   Other agencies (DOD, NASA, and DOE) have also funded some connections
   to NSFNET networks for the benefit of their respective research
   communities -- and have occasionally funded the networks directly.

   Finally, the campus-level networks at academic institutions probably
   represent a perhaps 7-10 times larger annual investment than the
   mid-level networks and the backbone together, yet there is no federal
   funding program at this level.  Furthermore, since these local
   networks must ordinarily be built by the institution rather than
   leased, there is an additional capitalization cost incurred by the
   institutions, which, annualized and aggregated, is perhaps another
   20-50 times the annual costs of the mid-level and backbone networks.
   (These figures are the roughest of estimates, intended only for
   illustration.)

The NSFNET Backbone as a Free Good

   Whereas the NSF funding of mid-level networks varies greatly -- from
   0% to 75% -- the backbone is available as a free good to the NSF-
   funded mid-level networks.  It is also used free of charge by other
   authorized networks, including networks not considered part of
   NSFNET: CSNET, BITNET, UUNET, and PSI, as well as the research
   networks of other federal agencies.  As noted, their use of the
   backbone is in principle limited to the support of academic research
   and education.

   Through their use of the NSFNET backbone, these networks appear to be
   enjoying a subsidy from NSF -- and from IBM, MCI, and the State of
   Michigan.  BITNET and some agency networks even use the backbone for
   their internal traffic.  Nonetheless, these other networks generally
   add value to NSFNET for NSFNET users and regional networks insofar as
   all networks benefit from access to each other's users and resources.

   However, small or startup networks generally bring in fewer network-
   based resources, so one side may benefit more than the other.  To the
   extent that the mail traffic is predominantly mailing lists (or other
   information resources) originating on one network, questions of
   imbalance and implicit subsidy arise.  For example, because of the
   mailing lists available without charge on the Internet, three times
   as much traffic runs over the mail gateway from the Internet to
Kahin                                                           [Page 4]
RFC 1192
Commercialization of the Internet       November 1990
MCIMAIL as from MCIMAIL to the Internet.  This pattern is reinforced
   by the sender-pays fee structure of MCIMAIL, which discourages
   mailing list distribution from within MCIMAIL.

   The impact of such imbalances is not clear.  For now, the capacity of
   the NSFNET backbone is staying ahead of demand: It jumped from 56
   Kbps to 1.544 Mbps (T-1) in 1988 and will go to 45 Mbps over the next
   year.  But NSF is concerned about a possible recurrence of the
   congestion which drove users off the NSFNET prior to the 1988
   upgrade.  Given the tripling of campus-level connections over the
   past year, continued growth in users at each site, the parade of new
   resources available over the network, and, especially, the
   development of high-bandwidth uses, there is reason to fear that
   demand may again overwhelm capacity.

   Offering the NSFNET backbone at no cost to authorized networks both
   encourages undisciplined use of the backbone and inhibits private
   investment in backbone networks.  It constrains the development of a
   market for commercial TCP/IP services by diverting an established and
   rapidly growing user base to a subsidized resource.  Charging NSFNET
   regionals and other mid-level networks for the use of the NSFNET
   backbone would resolve this problem, but this would impose a
   substantial cost burden on the mid-level networks, which would in
   turn have to raise membership and connection fees dramatically.  To
   compensate, the NSF subsidy that now underwrites the backbone could
   be moved down the distribution chain to the users of the backbone --
   i.e., to the regional networks, to the campuses, or even to
   researchers themselves.

   Each option poses unique opportunities and problems.  In theory, the
   further down the chain the subsidy is pushed, the more accountable
   providers will be to end-user needs.  Funding in hands of researchers
   would make universities more responsive to researchers' networking
   needs.  Funding in the hands of universities would in turn make
   regional networks more responsive and competitive.  And funds for
   regional networks would spur a general market for backbone services.
   But the mechanisms for expressing user demand upward through these
   tiers are imperfect.  And, from an administrative standpoint, it is
   easier for NSF to simply provide one free backbone to all comers --
   rather than deal with 25 mid-level networks, or 500 universities, or
   perhaps tens or hundreds of thousands of individual researchers.

Option: Funding Researchers

   It would be possible to earmark funds for network services in agency
   research grants as a matter of course, so that no new administrative
   process would be required.  But since network costs are presently not
   usage based, such funding will not readily translate into
Kahin                                                           [Page 5]
RFC 1192
Commercialization of the Internet       November 1990
identifiable services and may simply end up in local overhead
   accounts since few institutions allocate out costs of access to the
   Internet.  The use of vouchers rather than cash add-ons might help
   ensure that federal resources are in fact applied to qualifying wide
   area network services -- and possibly avoid the imposition of
   standard institutional overhead on direct funding.  However, if
   vouchers can be sold to other institutions, as economists would
   advocate in the interests of market efficiency, these advantages may
   be compromised.  Even non-transferable vouchers may create a unique
   set of accounting problems for both funding agencies and
   institutional recipients.

   A federal subsidy channeled automatically to research grants could
   substantially limit or segregate the user community.  It would tend
   to divide the academic community by exacerbating obvious divisions
   between the resource-rich and resource-poor -- between federally
   funded researchers and other researchers, between scientists and
   faculty in other disciplines, and between research and education.
   Within the academic community, there is considerable sentiment for
   providing basic network services out of institutional overhead to
   faculty and researchers in all disciplines, at least as long as basic
   services remain unmetered and relatively low at the institutional
   level.  Of course, special costing and funding may well make sense
   for high-bandwidth usage-sensitive network services (such as remote
   imaging) as they become available in the future.

Option: Funding Institutions

   Alternatively, funding for external network services, whether in the
   form of cash or vouchers, could be provided directly to institutions
   without linking it directly to federal research funding.  As it is,
   institutions may apply for one-time grants to connect to regional
   networks, and these are awarded based on peer assessment of a number
   of different factors, not just the quality of the institution's
   research.  But redirecting the subsidy of the backbone could provide
   regular support at the institutional level in ways that need not
   involve peer review.  For example, annual funding might be tied to
   the number of PhD candidates within specific disciplines -- or to all
   degrees awarded in science.  Geographic location could be factored in
   -- as could financial need.  This, of course, would amount to an
   entitlement program, a rarity for NSF.  Nonetheless, it would allow
   institutions to make decisions based on their own needs -- without
   putting NSF in the position of judging among competing networks,
   nonprofit and for-profit.

   There are, however, questions about what sort of services the
   earmarked funding or vouchers could be used for.  Could they be used
   to pay the institution's BITNET fee?  Or a SprintNet bill?  Or to
Kahin                                                           [Page 6]
RFC 1192
Commercialization of the Internet       November 1990
acquire modems?  For information services?  And, if so, what sort?
   Such questions force the funding agency to assume a kind of
   regulatory in an environment where competing equities, demonstrated
   need, technological foresight, and politics must be constantly
   weighed and juggled.

Option: Funding Regional Networks

   Shifting the subsidy to the regional networks is appealing in that it
   appears to be the least radical alternative and would only require
   allocating funds among some two dozen contenders.  Since most of the
   regional networks are already receiving federal funding, it would be
   relatively simple to tack on funds for the purchase of backbone
   services.  However, providing additional funding at this level
   highlights the problem of competition among mid-level networks.

   Although most regional networks are to some degree creatures of NSF,
   funded to ensure the national reach of NSFNET, they do not hold
   exclusive geographic franchises, and in some areas, there is
   competition between regionals for members/customers.  NSF grants to
   regional networks, by their very size, have an effect of unleveling
   the playing field among regionals and distorting competitive
   strengths and weaknesses.

   Alternet and PSI further complicate the picture, since there is no
   clear basis for NSF or other agencies to discriminate against them.
   The presence of these privately funded providers (and the possibility
   of others) raises difficult questions about what network services the
   government should be funding: What needs is the market now capable of
   meeting?  And where will it continue to fail?

   Experience with regulation of the voice network shows that it is
   inefficient to subsidize local residential service for everybody.  If
   one is concerned about people dropping off the voice network -- or
   institutions not getting on the Internet -- the answer is to identify
   and subsidize those who really need help.  The market-driven
   suppliers of TCP/IP-based Internet connectivity are naturally going
   after those markets which can be wired at a low cost per institution,
   i.e., large metropolitan areas, especially those with a high
   concentration of R&D facilities, such as Boston, San Francisco, and
   Washington, DC.  In the voice environment, this kind of targeted
   marketing by unregulated companies is widely recognized as cream-
   skimming.

   Like fully regulated voice common carriers (i.e., the local exchange
   carriers), the non-profit NSF-funded regional networks are expected
   to serve all institutions within a large geographic area.  In areas
   with few R&D facilities, this will normally result in a
Kahin                                                           [Page 7]
RFC 1192
Commercialization of the Internet       November 1990
disproportionately large investment in leased lines.  Either remote
   institutions must pay for the leased line to the nearest network
   point of presence -- or the network must include the leased line as
   part of common costs.  If the regional network assumes such costs, it
   will not be price-competitive with other more compact networks.

   Accordingly, a subsidy redirected to the regional networks could be
   keyed to the density of the network.  This might be calculated by
   number of circuit miles per member institution or some form of
   aggregate institutional size, figured for either the network as a
   whole or for a defined subregion.  This subsidy could be available to
   both for-profit and non-profit networks, but only certain non-profit
   networks would meet the density requirement, presumably those most in
   need of help.

Increasing the Value of the Connection

   The principal advantage in underwriting the backbone is that it
   provides a evenhanded, universal benefit that does not involve NSF in
   choosing among competing networks.  By increasing the value of
   belonging to a regional network, the backbone offers all attached
   networks a continuing annual subsidy commensurate with their size.

   Increased value can also derived from access to complementary
   resources -- supercomputer cycles, databases, electronic newsletters,
   special instruments, etc. -- over the network.  Like direct funding
   of backbone, funding these resources would induce more institutions
   to join regional networks and to upgrade their connections.  For
   example, where a database already exists, mounting it on the network
   can be a very cost-effective investment, increasing the value of the
   network as well as directly benefiting the users of the database.

   Commercial information services (e.g., Dialog, Orbit, Lexis) may
   serve this function well since they represents resources already
   available without any public investment.  Marketing commercial
   services to universities over the Internet is permissible in that it
   supports academic research and education (although the guidelines
   state that such commercial uses "should be reviewed on a case-by-case
   basis" by NSF).

   But to date there has been remarkably little use of the regional
   networks, let alone the NSFNET backbone, to deliver commercial
   information services.  In part, this is because the commercial
   services are unaware of the opportunities or unsure how to market in
   this environment and are concerned about losing control of their
   product.  It is also due to uneasiness within the regional networks
   about usage policies and reluctance to compete directly with public
   packet-switched networks.  However, for weak regional networks, it
Kahin                                                           [Page 8]
RFC 1192
Commercialization of the Internet       November 1990
may be necessary to involve commercial services in order to attract
   and hold sufficient membership -- at least if NSF subsidies are
   withdrawn.  Without a critical mass of users, commercialization may
   need to precede privatization.

Impact of Removing NSF Subsidy from the Backbone

   Any shift to a less direct form of subsidy may cause some disocation
   and distress at the regional network level -- until the benefits
   begin to be felt.  No regional network has yet folded, and no
   institution has permanently dropped its connection to a regional
   network as a consequence of higher prices, but concerns about the
   viability of some regionals would suggest that any withdrawal of
   subsidy proceed in phases.

   Moreover, as the NSF subsidy vanishes, the operation of the backbone
   becomes a private concern of Merit, the Michigan Strategic Fund, IBM,
   and MCI.  While Merit and the Michigan Strategic Fund are more or
   less public enterprises within the state, they are essentially
   private entrepreneurs in the national operation of a backbone
   network.  Without NSF's imprimatur and the leveraging federal funds,
   the remaining parties are much less likely to treat the backbone as a
   charity offering and may well look to recovering costs and using
   revenues to expand service.

   The backbone operation could conceivably become either a nonprofit or
   for-profit utility.  While nonprofit status might be more appealing
   to the academic networking community now served by the backbone, it
   is not readily apparent how a broadly representative nonprofit
   corporation, or even a cooperative, could be constituted in a form
   its many heterogeneous users would embrace.  A non-profit
   organization may also have difficulty financing rapid expansion of
   services.  At the same time, the fact that it will compete with
   private suppliers may preclude recognition as a tax-exempt
   organization -- and so its ability to reinvest retained earnings.

   Operation of the backbone on a for-profit basis would attract private
   investment and could be conducted with relative efficiency.  However,
   given the dominant position of the backbone, a for-profit operation
   could conceivably get entangled in complex antitrust, regulatory, and
   political struggles.  A nonprofit organization is not immune from
   such risks, but to the extent its users are represented in policy-
   making, tensions are more likely to get expressed and resolved
   internally.

   The status of backbone or regional networks within the Internet is
   entirely separate from the question of whether network services are
   metered and charged on a usage basis.  Confusion in this regard stems
Kahin                                                           [Page 9]
RFC 1192
Commercialization of the Internet       November 1990
from the fact that the low-speed public data networks (SprintNet,
   TymNet), which are sometimes seen as competitive to Internet
   services, do bill on a connect-time basis.  However, these commercial
   services use X.25 connection-based packet-switching -- rather than
   the connectionless (datagram) TCP/IP packet-switching used on the
   Internet.  Internet services could conceivably be billed on per-
   packet basis, but the accounting overhead would be high and packets
   do not contain information about individual users.  At bottom, this
   is a marketing issue, and there is no evidence of any market for
   metered services -- except possibly among very small users.  The
   private suppliers, Alternet and PSI, both sell "pipes" not packets.

Privatization by Function

   As an alternative approach to encouraging privatization, Dr.  Wolff
   suggested barring mature services such as electronic mail from the
   subsidized network.  In particular, NSF could bar the mail and news
   protocols, SMTP and NNTP, from the backbone and thereby encourage
   private providers to offer a national mail backbone connecting the
   regional networks.  Implementation would not be trivial, but it would
   arguably help move the academic and research community toward the
   improved functionality of X.400 standards.  It would also reduce
   traffic over the backbone by about 30% -- although given continued
   growth in traffic, this would only buy two months of time.

   If mail were moved off the regional networks as well as off the
   NSFNET backbone, this would relieve the more critical congestion
   problem within certain regions.  But logistically, it would be more
   complicated since it would require diverting mail at perhaps a
   thousand institutional nodes rather than at one or two dozen regional
   nodes.  Politically, it would be difficult because NSF has
   traditionally recognized the autonomy of the regional networks it has
   funded, and the networks have been free to adopt their own usage
   guidelines.  And it would hurt the regional networks financially,
   especially the marginal networks most in need of NSF subsidies.
   Economies of scale are critical at the regional level, and the loss
   of mail would cause the networks to lose present and potential
   members.

The National Research and Education Network

   The initiative for a National Research and Education Network (NREN)
   raises a broader set of policy issues because of the potentially much
   larger set of users and diverse expectations concerning the scope and
   purpose of the NREN.  The decision to restyle what was originally
   described as a National Research Network to include education was an
   important political and strategic step.  However, this move to a
   broader purpose and constituency has made it all the more difficult
Kahin                                                          [Page 10]
RFC 1192
Commercialization of the Internet       November 1990
to limit the community of potential users -- and, by extension, the
   market for commercial services.  At the regional, and especially the
   state level, public networking initiatives may already encompass
   economic development, education at all levels, medical and public
   health services, and public libraries.

   The high bandwidth envisioned for the NREN suggests a growing
   distance between resource-intensive high-end uses and wide use of
   low-bandwidth services at low fixed prices.  The different demands
   placed on network resources by different kinds of services will
   likely lead to more sophisticated pricing structures, including
   usage-based pricing for production-quality high-bandwidth services.
   The need to relate such prices to costs incurred will in turn
   facilitate comparison and interconnection with services provided by
   commercial vendors.  This will happen first within and among
   metropolitan areas where diverse user needs, such as
   videoconferencing and medical imaging, combine to support the
   development of such services.

   As shown in Figures 1. and 2., the broadening of scope corresponds to
   a similar generalization of structure.  The path begins with
   mission-specific research activity organized within a single
   computer.  It ends with the development of a national or
   international infrastructure: a ubiquitous, orderly communications
   system that reflects and addresses all social needs and market
   demand, without being subject to artificial limitations on purpose or
   connection.  There is naturally tension between retaining the
   benefits of specialization and exclusivity and seeking the benefits
   of resource-sharing and economies of scale and scope.  But the
   development and growth of distributed computing and network
   technologies encourage fundamental structures to multiply and evolve
   as components of a generalized, heterogeneous infrastructure.  And
   the vision driving the NREN is the aggregation and maturing of a
   seamless market for specialized information and computing resources
   in a common, negotiable environment.  These resources have costs
   which are far greater than the NREN.  But the NREN can minimize the
   costs of access and spread the costs of creation across the widest
   universe of users.
Kahin                                                          [Page 11]
RFC 1192
Commercialization of the Internet       November 1990
Figure 1.  Generalization of Purpose:

   Discipline-Specific Research            CSNET, HEPnet, MFEnet

   General Research                        early NSFNET, "NRN"

   Research and Education                  BITNET, present NSFNET,
                                           early "NREN"

   Quasi-Public                            many regional networks,
                                           "NREN"

   National Infrastructure                 "commercialized NREN"

   _______________________________________________________________

Figure 2. Generalization of Structure:

   Computer                                time-sharing hosts

   Network                                 early ARPANET

   Internetwork                            ESNET, NSFNET (tiered)

   Multiple Internetworks                  present Internet

   Infrastructure                          "NREN"

Workshop Participants

   Rick Adams, UUNET
   Eric Aupperle, Merit
   Stanley Besen, RAND Corporation
   Lewis Branscomb, Harvard University
   Yale Braunstein, University of California, Berkeley
   Charles Brownstein, National Science Foundation
   Deborah Estrin, University of Southern California
   David Farber, University of Pennsylvania
   Darleen Fisher, National Science Foundation
   Thomas Fletcher, Harvard University
   Kenneth Flamm, Brookings Institution
   Lisa Heinz, U.S. Congress Office of Technology Assessment
   Fred Howlett, AT&T
   Brian Kahin, Harvard University
   Robert Kahn, Corporation for National Research Initiatives
   Kenneth King, EDUCOM
Kahin                                                          [Page 12]
RFC 1192
Commercialization of the Internet       November 1990
Kenneth Klingenstein, University of Colorado
   Joel Maloff, CICNet
   Bruce McConnell, Office of Management and Budget
   Jerry Mechling, Harvard University
   James Michalko, Research Libraries Group
   Elizabeth Miller, U.S. Congress Office of Technology Assessment
   Eli Noam, New York State Public Service Commission
   Eric Nussbaum, Bellcore
   Peter O'Neil, Digital Equipment Corporation
   Robert Powers, MCI
   Charla Rath, National Telecommunications and Information
                Administration, Department of Commerce
   Ira Richer, Defense Advanced Research Projects Agency
   William Schrader, Performance Systems International
   Howard Webber, Digital Equipment Corporation
   Allan Weis, IBM
   Stephen Wolff, National Science Foundation

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Brian Kahin
   Director, Information Infrastructure Project
   Science, Technology & Public Program
   John F. Kennedy School of Government
   Harvard University

   Phone:  617-495-8903

   EMail:  kahin@hulaw.harvard.edu

Kahin                                                          [Page 13]
RFC
1192
: Commercialization of the Internet summary report
Informational


RFC 2860: Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority | RFC Editor
Skip to content
Primary navigation
The RFC Series
For Authors
About Us
Home
RFC 2860
Info
RFC
2860
:
Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
B. Carpenter
,
F. Baker
,
M. Roberts
Informational
Network Working Group B. Carpenter
Request for Comments: 2860 IAB
Category: Informational F. Baker
IETF
M. Roberts
ICANN
June 2000
Memorandum of Understanding Concerning the Technical
Work of the Internet Assigned Numbers Authority
Status of this Memo

This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This document places on record the text of the Memorandum of
Understanding concerning the technical work of the IANA that was
signed on March 1, 2000 between the IETF and ICANN, and ratified by
the ICANN Board on March 10, 2000.

MoU text as signed

MEMORANDUM OF UNDERSTANDING CONCERNING THE TECHNICAL WORK OF THE
INTERNET ASSIGNED NUMBERS AUTHORITY

1. This Memorandum of Understanding ("MOU") defines an agreement
between the Internet Engineering Task Force and the Internet
Corporation for Assigned Names and Numbers. Its intent is exclusively
to define the technical work to be carried out by the Internet
Assigned Numbers Authority on behalf of the Internet Engineering Task
Force and the Internet Research Task Force. It is recognized that
ICANN may, through the IANA, provide similar services to other
organisations with respect to protocols not within IETF's scope (i.e.
registries not created by IETF or IRTF action); nothing in this MOU
limits ICANN's ability to do so.
Carpenter, et al. Informational [Page 1]
RFC 2860
MoU Between IETF and ICANN concerning IANA June 2000
2. This MOU will remain in effect until either modified or cancelled
by mutual consent of the Internet Engineering Task Force and the
Internet Corporation for Assigned Names and Numbers, or cancelled by
either party with at least six (6) months notice.

3. Definition of terms and abbreviations used in this document.

ICANN - Internet Corporation for Assigned Names and Numbers, a
California non-profit corporation.

IANA - Internet Assigned Numbers Authority (a traditional name, used
here to refer to the technical team making and publishing the
assignments of Internet protocol technical parameters). The IANA
technical team is now part of ICANN.

IETF - the Internet Engineering Task Force, the unincorporated
association operating under such name that creates Internet Standards
and related documents.

IAB - the Internet Architecture Board, an oversight committee of the
IETF. The IAB is chartered to designate the IANA on behalf of the
IETF.

IESG - the Internet Engineering Steering Group, a management
committee of the IETF.

IRTF - the Internet Research Task Force, an unincorporated
association also overseen by the IAB.

IRSG - the Internet Research Steering group, a management committee
of the IRTF.

RFC - "Request For Comments", the archival document series of the
IETF, also used by the IRTF and by third parties.

ISOC - the Internet Society, a not-for-profit corporation that
supports the IETF.

4. Agreed technical work items. ICANN agrees that during the term of
this MOU it shall cause IANA to comply, for protocols within IETF's
scope, with the following requirements, which ICANN and IETF
acknowledge reflect the existing arrangements under which the IANA is
operated:

4.1. The IANA will assign and register Internet protocol parameters
only as directed by the criteria and procedures specified in RFCs,
including Proposed, Draft and full Internet Standards and Best
Current Practice documents, and any other RFC that calls for IANA
Carpenter, et al. Informational [Page 2]
RFC 2860
MoU Between IETF and ICANN concerning IANA June 2000
assignment. If they are not so specified, or in case of ambiguity,
IANA will continue to assign and register Internet protocol
parameters that have traditionally been registered by IANA, following
past and current practice for such assignments, unless otherwise
directed by the IESG.

If in doubt or in case of a technical dispute, IANA will seek and
follow technical guidance exclusively from the IESG. Where
appropriate the IESG will appoint an expert to advise IANA.

The IANA will work with the IETF to develop any missing criteria and
procedures over time, which the IANA will adopt when so instructed by
the IESG.

4.2. In the event of technical dispute between the IANA and the IESG,
both will seek guidance from the IAB whose decision shall be final.

4.3. Two particular assigned spaces present policy issues in addition
to the technical considerations specified by the IETF: the assignment
of domain names, and the assignment of IP address blocks. These
policy issues are outside the scope of this MOU.

Note that (a) assignments of domain names for technical uses (such as
domain names for inverse DNS lookup), (b) assignments of specialised
address blocks (such as multicast or anycast blocks), and (c)
experimental assignments are not considered to be policy issues, and
shall remain subject to the provisions of this
Section 4
. (For
purposes of this MOU, the term "assignments" includes allocations.)
In the event ICANN adopts a policy that prevents it from complying
with the provisions of this
Section 4
with respect to the assignments
described in (a) - (c) above, ICANN will notify the IETF, which may
then exercise its ability to cancel this MOU under
Section 2
above.

4.4. The IANA shall make available to the public, on-line and free of
charge, information about each current assignment, including contact
details for the assignee. Assignments published in RFCs by the RFC
Editor and available publicly will be deemed to meet the requirements
of this
Section 4.4
.

4.5. The IANA shall provide on-line facilities for the public to
request Internet protocol parameter assignments and shall either
execute such assignments, or deny them for non- conformance with
applicable technical requirements, in a timely manner. There shall be
no charge for assignments without the consent of the IAB. Requests
shall only be denied on legitimate technical grounds.
Carpenter, et al. Informational [Page 3]
RFC 2860
MoU Between IETF and ICANN concerning IANA June 2000
For protocols within the IETF scope (i.e., registries created by IETF
action), appeals against such denials may be made to the IESG and
subsequently to the IAB as provided in 4.2 above.

4.6. The IANA shall have non-voting liaison seats on appropriate IETF
committees as determined by the IETF, and may participate in all IETF
discussions concerning technical requirements for protocol parameter
assignment through such liaisons.

4.7. The IANA shall review all documents in IETF Last Call to
identify any issues of concern to the IANA, and shall raise these
issues with the IESG.

5. Application to IRTF/IRSG. The parties understand that certain of
the protocol parameters to be assigned by IANA will be relevant to
IRTF, rather than IETF. With respect to these protocol parameters,
IANA will comply with the procedures set forth in
Section 4
, with the
understanding that IRTF and IRSG shall be substituted for IETF and
IESG, respectively, in such procedures. In the event of any question
as to whether a particular protocol parameter relates principally to
IETF or IRTF, the IAB shall have the authority to answer such
question in its discretion.

6. General. This MOU does not constitute any of the parties as a
partner, joint venturer, agent, principal or franchisee of any other
party. The waiver of any provision of this MOU on any occasion shall
not constitute a waiver for purposes of any other occasion. No party
may transfer or assign any interest, right or obligation arising
under this MOU without the prior written consent of each other party
to this MOU.

7. Effectiveness of MOU. This Agreement requires the approval or
ratification of the ICANN Board of Directors. The signatory for
ICANN shall use his best efforts to secure and deliver to IETF such
approval or ratification within two months of signing.
Carpenter, et al. Informational [Page 4]
RFC 2860
MoU Between IETF and ICANN concerning IANA June 2000
IN WITNESS WHEREOF, this Memorandum of Understanding is executed as
of this first day of March 2000 by the undersigned, acting through
their duly authorized representatives:

INTERNET ENGINEERING TASK FORCE

By: __________________________ Fred Baker, IETF Chair

Approved by:

INTERNET ARCHITECTURE BOARD

By: __________________________ Brian Carpenter, IAB Chair

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

By:___________________________ Mike Roberts, President

Security considerations

This document does not directly impact the security of the Internet.
Carpenter, et al. Informational [Page 5]
RFC 2860
MoU Between IETF and ICANN concerning IANA June 2000
Acknowledgements

The technical heart of this document was discussed in the IETF
POISSON working group in 1998 and 1999 and reviewed by the IESG and
IAB. Jorge Contreras, Joyce K. Reynolds, and Louis Touton assisted in
its finalisation.

Authors' Addresses

Brian E. Carpenter
iCAIR
Suite 150
1890 Maple Avenue
Evanston IL 60201
USA

EMail: brian@icair.org

Fred Baker
519 Lado Drive
Santa Barbara, CA 93111
USA

EMail: fred@cisco.com

Michael M. Roberts
Internet Corporation for Assigned Names and Numbers (ICANN)
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
USA

EMail: roberts@icann.org
Carpenter, et al. Informational [Page 6]
RFC 2860
MoU Between IETF and ICANN concerning IANA June 2000
Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Carpenter, et al. Informational [Page 7]
RFC
2860
: Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
Informational
About this RFC
Errata
Details
Date published
June 2000
Authors
B. Carpenter
,
F. Baker
,
M. Roberts
IAB Stream
IAB
DOI
https://doi.org/10.17487/RFC2860
Formats
TXT
,
HTML
.
Cite this RFC
TXT
,
XML
,
BibTeX
.
Document history
View history of
RFC
2860
:
Footer
rfc-editor.org is maintained by the
Internet Engineering Task Force
System Status
·
Report a Bug
·
Version 1.76.1
Useful links
IETF.org
IRTF.org
IAB.org
Datatracker
Author Resources
Contact Us
RFC Editor
rfc-dist Info Page
rfc-interest Info Page
Expand sidebar

RFC publication date from document header


Membership — RIPE Network Coordination Centre
Skip to main content
IPs & ASNs
IPs & ASNs
We distribute Internet number resources to our members and provide tools to help them manage their allocations and assignments.
Visit page
IPv4
Request /24 Allocation
IPv4 Run-out
How Does The IPv4 Waiting List Work?
IPv4 Transfer Request
IPv4 Waiting List
IPv6
Request IPv6
IPv6 Info Centre
AS Numbers
Reassigning Referenced AS Numbers
RIPE Database
Whois Search
Webupdates
Database Support
LIR Portal
DNS
Reverse DNS
DNSSEC
Resource Transfers and Mergers
Inter-RIR Transfers
Mergers and Acquisitions
Legacy Internet Resources
Documentation
Documentation for Resource Management
Resource Public Key Infrastructure (RPKI)
Policy Implementation
Assisted Registry Check
Close
Analyse
Analyse
We collect a wide range of Internet data and provide statistics and tools you can use for your own operations and analyses.
Visit page
Statistics
Internet Measurements
RIPE Atlas
RIPEstat
RIS
RIPE IPMap
Internet Traffic Maps
Analyses and Use Cases
IXP Country Jedi (Alpha)
DNS
K-root
AuthDNS
Reverse DNS Zonecheck
DNS Monitoring Service (DNSMON)
Raw Datasets
RIPE Atlas Raw Data Format
RIPE Atlas Raw Data
RIS Raw Data
Terms and Conditions
Archived Projects
RIS Tools and Web Interfaces
TTM
RRCC
DISI
IRRToolset
Re-implementation Project
DBConstat
Sponsorship
Close
Community
Community
More information about RIPE
Visit page
Working Groups
Working Group Chairs
Active Working Groups
Task Forces
Policy Development
Policy Implementation Status
Current Policy Proposals
Internet Governance
Internet Technical Community
Multi-stakeholder Engagement
Internet Governance News
RIPE Labs
NRO NC
About the NRO NC
NRO NC Nominations - October 2025
ICP-2 Review
Initiatives
Academic Cooperation (RACI)
RIPE Fellowship
Diversity
Community Projects Fund
Rob Blokzijl Foundation
Community Sponsorship
RIPE Governance
The RIPE Chair Team
RIPE Code of Conduct
RIPE Community Plenary
The History of RIPE
RIPE Document Store
Participate
How to Participate
RIPE Mailing Lists
Close
Membership
Membership
Get information about your membership, the benefits you get and how you can participate and shape RIPE NCC's activities.
Visit page
RIPE NCC Membership
Become a Member
LIR Basics for Members
RIPE NCC Access
RIPE NCC Surveys
General Meetings
General Meeting October 2026
Meetings
Billing, Payment and Fees
Charging Schemes
Billing Procedure 2026
Billing Procedure 2025
Tax Information
Financial Information
RIPE NCC Organisational Documents
Activity Plan and Budget
Annual Reports
Financial Reports
Charging Schemes
Quarterly Sanctions Transparency Reports
RIPE NCC Strategy
Join a Discussion
Membership Mailing Lists
RIPE Mailing Lists
Consultations
RIPE NCC Forum
Close
Events
Events
The RIPE community carries out much of its work through mailing lists, but face-to-face meetings are equally important.
Visit page
RIPE Meetings
Presenting at a RIPE Meeting
Programme Committee
Upcoming RIPE Meetings
Previous RIPE Meetings
Regional Meetings
CAPIF
MENOG
SEE
RIPE NCC Days
Next Regional Meetings
Roundtable Meetings
Previous Meetings
General Meetings
Open House
Previous Events
Internet Measurement Days
Sofia
Bucharest
Hackathons
Events Calendar
Event Sponsorship
Close
Training
Training
Follow our courses, build skills, and earn certifications. Browse topics and skill levels for the learning path that best matches your goals and learning style.
Visit page
In-Person Training Courses
Upcoming Training Courses
Host a Training Course
Training Material
Webinars
Webinar Recordings
RIPE NCC Academy
Certified Professionals
Schedule an Exam
BGP Security Associate
IPv6 Fundamentals - Analyst
IPv6 Security Expert
Local Internet Registry (LIR) Fundamentals
RIPE Database Associate
Practical Information
Exam Vouchers
Videos
Summer School 2026
Close
Docs
Docs
Find the documents that you need from the RIPE Document Store, the RIPE NCC's technical documentation and IPv6 resources.
Visit page
RIPE Document Store
RIPE Documents by Number
RIPE Documents by Category
RIPE Policies
Documentation
Developer Documentation
Quarterly Plans
RIPE Atlas Documentation
RIPE Database Documentation
RIS Documentation
RIPE IPmap Documentation
RIPEstat Documentation
Disclosures and Reports
IPv6 Information Centre
About IPv6
Deploy IPv6 Now
Statistics and Tools
Training and Materials
Documents
Community
Close
About
About
We're a not-for-profit membership association, a Regional Internet Registry and the secretariat for the RIPE community supporting the Internet.
Visit page
What We Do
Regional Internet Registry
RIPE NCC Service Region
Coordination Function
Statistics
Transition to IPv6
List of RIPE NCC Services
User Research
Staff
RIPE NCC Staff
Careers at the RIPE NCC
Executive Board
Functions and Expectations
Minutes from Executive Board Meetings
Financial Information
Current Charging Scheme
Current Billing Procedure
Press Centre
RIPE NCC in the News
Publications and Presentations
Press Releases
Press Quality Photos
Legal
Arbitration
Corporate Governance
Internet Number Resources
Other RIPE NCC Services
Information for LEA
News
RSS News Feeds
RIPE NCC Member Updates
Support
Contact Us
Spam, Hacking and Phishing
Service and Security Announcements
RIPE NCC Trust Portal
RIPE NCC Middle East
Close
Languages
Find information about the RIPE NCC translated into eight languages. Use the menu to read text in Arabic, Spanish, Farsi, French, Italian, Turkish, Ukrainian and Russian.
Visit page
English
How to Become a Member
Billing, Fees and Payments
How to Get IP Addresses
How to Transfer IP Addresses and ASNs
How to get involved at the RIPE NCC
How the RIPE NCC is Run
How to Find Abuse Contact Information
Training and Certification
Türkçe
RIPE NCC’ye Nasıl Üye Olabilirsiniz?
Faturalandırma, Ücretler ve Ödemeler
IP Adresleri Nasıl Alınır
IP Adreslerinin ve ASN'lerin Aktarılması
RIPE NCC’nin faaliyetlerinde nasıl yer alınır
RIPE NCC Nasıl Çalışır
Kötüye Kullanımdan Sorumlu İrtibat Kişisinin Bilgileri Nasıl Bulunur?
Eğitim ve Sertifikalar
Español
Cómo hacerse miembro
Facturación, Tarifas y Pagos
Cómo obtener direcciones IP
Cómo transferir direcciones IP y ASN
Cómo involucrarse en RIPE NCC
Cómo funciona el RIPE NCC
Cómo encontrar información de contacto de abuso
Formación y certificación
Italiano
Come associarsi
Costi, fatturazione e pagamenti
Come ottenere indirizzi IP
Come trasferire indirizzi IP e ASN
Come partecipare al RIPE NCC
Come viene gestito il RIPE NCC
Come trovare informazioni di contatto sugli abusi
Formazione e certificazione
Pусский
Как стать членом RIPE NCC
Оформление счетов, взносы и платежи
Как получить IP-адреса
Как передавать IP-адреса и ASN
Как принять участие в работе RIPE NCC
Кто руководит RIPE NCC
Как найти контактную информацию для обращений касательно злоупотреблений
Обучение и сертификация
عربي
كيف تصبح عضوًا
رسوم العضوية
كيفية الحصول على عناوين IP
كيفية نقل عناوين IP وأرقام ASN
كيف تشارك في RIPE NCC
كيف تُدار RIPE NCC
كيف تصل إلى معلومات الاتصال الخاصة بإساءة الاستخدام
التدريب والشهادات
فارسی
نحوۀ عضویت
صدور صورتحساب، هزینه‌ها و پرداخت‌ها
چگونه میتوان آدرس های IPرا گرفت
نحوۀ انتقال آدرس های IP و شماره های سیستم خودمختار
نحوۀ همکاری با مرکز هماهنگی شبکه RIPE NCC
RIPE NCC نحوۀ ادارۀ
نحوۀ یافتن اطلاعات تماس سوءاستفاده‌گر
آموزش و اعطای گواهی
Українська
Як стати членом RIPE NCC
Виставлення рахунків, збори та платежі
Як отримати IP-адреси
Як передавати IP-адреси та ASN
Навчання та сертифікація
Як функціонує RIPE NCC
Як знайти контактну інформацію для повідомлення про зловживання
Français
Comment devenir membre ?
Facturation, frais et paiements
Comment obtenir des adresses IP
Comment transférer des adresses IP et des numéros de système autonome (ASN)
Comment s'impliquer au sein du RIPE NCC
Comment fonctionne le RIPE NCC
Comment trouver les Informations de Contact d'Abus
Formation et certification
Close
Search
Search
Your IP Address is:
193.171.242.40
Tip: try using "quotes around your search phrase"
Apps
RIPE.NET
LIR Portal
RIPE Database
RIPE Labs
RIPEstat
RIPE Atlas
RIPE NCC Academy
RPKI
DNSMON
Log in
Menu
Close
Apps
RIPE.NET
LIR Portal
RIPE Database
RIPE Labs
RIPEstat
RIPE Atlas
RIPE NCC Academy
RPKI
DNSMON
Log in
RIPE NCC Membership
General Meetings
Billing, Payment and Fees
RIPE NCC Organisational Documents
Join a Discussion
RIPE NCC Forum
Membership
The smooth running of the Internet depends on the involvement of those who give their input on membership and policy issues. And there are many ways to get involved, online and in person.
RIPE NCC Membership
Membership Information
Our members can benefit from a wide range of membership services, such as training and Internet analysis tools, that the RIPE NCC provides to help organisations with their technical operations. The RIPE NCC also carries out coordination activities that allow members to discuss issues of common interest online and at events throughout its service region.
Become a Member
If your organisation needs IPv6 address space and AS Numbers, and/or makes assignments to End Users or customers, you should become a RIPE NCC member.
Become a Member
LIR Basics for Members
This page outlines the steps you need to take in order to take advantage of all the services that the RIPE NCC has to offer.
LIR Basics
Billing, Costs and Fees
Find out what costs and fees are associated with being a member.
Billing and Fees
Read the Member Update
Get all you need to know of what's happening in the RIPE NCC Member Update.
Read more
Join the Mailing Lists
The RIPE NCC offers several mailing lists for its members to stay up to date with news and announcements and to discuss topics of interest with other members.
Mailing Lists for Members
Attend a General Meeting
The RIPE NCC holds a General Meeting (GM) twice a year - in spring and in autumn.
General Meetings
RIPE NCC Services
View the list of services offered by the RIPE NCC
View Services
Upcoming Events
The RIPE NCC facilitates a range of meetings for different audiences.
CAPIF 5
24 Sep 2026
—
25 Sep 2026
Dushanbe, Tajikistan
RIPE 93
26 Oct 2026
—
30 Oct 2026
Sofia, Bulgaria
SEE 15
13 Apr 2027
—
14 Apr 2027
Tirana, AL
RIPE 94
24 May 2027
—
28 May 2027
Vilnius, Lithuania
RIPE 95
15 Nov 2027
—
19 Nov 2027
Madrid, Spain
RIPE 96
15 May 2028
—
19 May 2028
View all events
Latest news
NRO NC Nominations 2026: Call to Fill One Seat
NRO call for nomination to fill one seat for October 2026.
Publish Date:
30 Jul 2026
This news item has been tagged with:
news
+1
RIPE NCC Member Update: July 2026
Read the monthly RIPE NCC Member Update for July 2026.
Publish Date:
29 Jul 2026
This news item has been tagged with:
member update
ASO AC delivers Recommended Draft RIR Governance Document to NRO EC
The Address Supporting Organization Address Council (ASO AC) has delivered Recommended Draft RIR Governance Document to NRO EC.
Publish Date:
28 Jul 2026
This news item has been tagged with:
news
+2
RIPE NCC Quarterly Sanctions Transparency Report (Q3 2026) Published
We have published our third sanctions transparency report of the year.
Publish Date:
24 Jul 2026
This news item has been tagged with:
news
RIPE NCC Strategy 2027-31 Published
The RIPE NCC Strategy 2027-31 is now available. This strategy builds upon our existing vision, mission and values and sets the long-term direction for the organisation. The document explains RIPE NCC’s role in the Internet ecosystem, sets out six strategic focus areas for the coming five-year period and the external factors that influence our operating environment.
Publish Date:
13 Jul 2026
This news item has been tagged with:
news
+2
RIPE 95: Call for Host
The RIPE NCC is looking for a host for RIPE 95 that will take place in Madrid at the Meliá Castilla Hotel from 15-19 November 2027.
Publish Date:
09 Jul 2026
This news item has been tagged with:
news
+1
View all news
Working Groups
Task Forces
RIPE Governance
Initiatives
RIPE 93
How to Participate
IPs & ASNs
IPv4
IPv6
AS Numbers
RIPE Database
LIR Portal
DNS
Resource Transfers and Mergers
Legacy Internet Resources
Documentation for Resource Management
Analyse
Statistics
Internet Measurements
DNS
Raw Datasets
Archived Projects
Sponsorship
Community
Working Groups
Task Forces
Policy Development
Internet Governance
RIPE Labs
NRO NC
Initiatives
RIPE Governance
RIPE Document Store
Participate
Membership
RIPE NCC Membership
General Meetings
Billing, Payment and Fees
RIPE NCC Organisational Documents
Join a Discussion
RIPE NCC Forum
Events
RIPE Meetings
Regional Meetings
Roundtable Meetings
General Meetings
Open House
Internet Measurement Days
Hackathons
Events Calendar
Event Sponsorship
Training
In-Person Training Courses
Webinars
RIPE NCC Academy
Certified Professionals
Videos
Summer School 2026
Docs
RIPE Document Store
Documentation
IPv6 Information Centre
About
What We Do
Staff
Executive Board
Financial Information
Press Centre
Legal
News
Support
RIPE NCC Trust Portal
RIPE NCC Middle East
Languages
English
Türkçe
Español
Italiano
Pусский
عربي
فارسی
Українська
Français
© 1992–2026 RIPE NCC
Your IP Address is:
193.171.242.40
Home
Sitemap
Contact Us
Careers
Service Announcements
Privacy Statement
Legal
Cookies
Copyright Statement
Terms of Service
RSS Feeds


What's the effect of ICANN's role and work on the Internet? - ICANN
Skip to main content
Search ICANN.org
Log In
Sign Up
Get Started
About ICANN
ICANN for Beginners
Fellowship Program
NextGen@ICANN Program
History
News and Media
Announcements
Blog
Media Resources
Press Releases
Global Newsletters
ICANN News Subscriptions
Regional Reports
Policy
Develop Policy
Operational Design Phase (ODP)
Implement Policy
Community Participation Guidelines
Public Comment
Public Comment Home
Upcoming Proceedings
Open Proceedings
Closed Proceedings
About Public Comment
Other Public Consultations
Resources
Board Activities and Meetings
Accountability Mechanisms
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
Contractual Compliance
Domain Name Security Threats
Privacy and Proxy Services
Government Engagement
Careers
Complaints Office
I Need Help
ICANN 25th Anniversary Photo Mosaic
Community
Engagement Calendar
Address Supporting Organization (ASO)
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)
Root Server System Advisory Committee (RSSAC)
Security and Stability Advisory Committee (SSAC)
Quicklinks
Board Activities and Meetings
Data Protection and Privacy
Domain Name Registrants
Engagement Calendar
IANA Services
ICANN Acronyms and Terms
ICANN Grant Program
New gTLD Program
Public Technical Identifiers (PTI)
Open Data
Question About A Domain Name?
Technology @ ICANN
WSIS+20 Outreach Network
Resources
About ICANN
Academic Engagement
Acronyms and Terms
Courses and Learning
ICANN for Beginners
Participate
What ICANN Does
Effect on the Internet
What's Going On Now
How to Participate
Fellowship Program
Committee
Terms & Conditions
NextGen@ICANN Program
President's Corner
ICANN Management Organization Chart
Staff
Careers
In Focus
ICANN Response Planning Framework
DNSSEC
Standards
IANA DNSSEC Root Information
TLD DNSSEC Report
Root Deployment
Deployment Graph
Tools
Training
Key Ceremony
News
Blog Posts
Presentations
Related Sites
GNSO Improvements
Travel Support
Media Resources
ICANN News
About ICANN
Subscribe and Follow
Contacts
Board Activities and Meetings
Accountability
Accountability Mechanisms
Reconsideration
Independent Review Process
Updating the IRP
Ombuds
About the Ombuds Office
Contact the Ombuds Office
Ombuds Office Services
Complaints About Unfairness
Complaints About Harassment
Collaborative Conflict Resolution
Request for Reconsideration
Resources for Community Members
Ombuds Office Accountability
Ombud's Blogs
Empowered Community
Empowered Community Administration
Empowered Community Administration Mailing List
Empowered Community Correspondence
Document Disclosure
Reviews
Organizational Reviews
ALAC
ASO
Board
ccNSO
GNSO
Nominating Committee
RSSAC
SSAC
Technical Liaison Group
Specific Reviews
Accountability & Transparency
Registration Directory Service
Security, Stability, and Resiliency
Competition, Consumer Trust & Consumer Choice
CCT Metrics
Expected Standards of Behavior
Employee Practices and Resources
Enhancing ICANN Accountability – Work Stream 2 Implementation
Governance
Governance Documents
Evolving ICANN’s Multistakeholder Model
Agreements
NTIA IANA Functions' Stewardship Transition
Call for Public Input: Draft Process to Develop the Proposal (8 April-8 May 2014
Process to Develop the Proposal and Next Steps
Registry
Archive
Affirmation of Commitments
AOC Tracking
ccTLD
Partnership Memorandums of Understanding
Registrar
Archive
Annual Reports
Financials
Financial Reports
Policies, Guidelines and Procedures
Annual Disclosure of Payments to Suppliers
Lobbying Disclosures & Contribution Reports
Planning
Strategic Plan
ICANN Strategic Plan for FY26-30
ICANN's Annual Strategy Review Program
ICANN Strategic Plan for FY21-25
Strategic Outlook Trends Program
ICANN Strategic Plan for FY16-20
Operating Plan
Presentations
RFPs
Litigation
Newsletter
Correspondence
2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
Quarterly Reports
Groups
2023 ICANN CEO Search Committee
RSSAC
Charter
SSAC
GAC
At-Large
ASO
ccNSO
GNSO
Technical Liaison Group
Technical Experts Group (TEG)
NomCom
Past NomComs
Customer Standing Committee
Root Zone Evaluation Review Committee (RZERC)
Business
Civil Society
Complaints Office
Complaints Report
Domain Name System Abuse
Contractual Compliance
About
Enforcement of DNS Abuse Obligations
Formal Enforcement Notices
Archive
Contractual Compliance Metrics
Blogs
Contractual Compliance Audit Program
Notice of Bankruptcy, Convictions and Security Breaches
Contractual Compliance Reports
Audit Reports
Enforcement of DNS Abuse Mitigation Requirements: Periodic Reviews
Contractual Compliance Monthly Reports
gTLD Registry Compliance
Accredited Registrar Compliance
General Questions
Outreach
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
About Domain Names
ICANN Policies
Registration Data Policies
WHOIS and Registration Data Directory Services
The Domain Name Registration Process
Using Domain Name Registration Data
Keeping Registration Data Accurate
Access and the Evolution of the WHOIS System
Domain Name Industry
Registering Domain Names
Managing Domain Names
Contact Information and WDRP
Securely Managing Your Domain Name
Transferring Domain Names
Renewing Domain Names
Rights and Responsibilities
Spam, Phishing, and Website Content
Trademark Infringement
GDS Metrics
Identifier Systems Security, Stability and Resiliency (OCTO-SSR)
ccTLDs
Background Materials
Agreements
Delegation
Root Zone Database
Model MOU
Workshops
ICANN and ISO
Internationalized Domain Names
Root Zone Label Generation Rules (LGR)
Generation Panel Update
Maximal Starting Repertoire
Proposals for Root Zone Label Generation Ruleset
IDN Variant TLD Implementation
LGR Toolset
IDN ccTLD Fast Track
IDN Implementation Guidelines
Second-Level LGR Reference
Resources
Announcements and Blogs Posts
New gTLD Program
Universal Acceptance Initiative
Make your systems UA-ready
UA Training
UA Day
UA Readiness Evaluations
UA Initiatives
Announcements and Blogs Posts
Policy
Policy Mission
Policy Staff Goals
Presentations
Global Addressing
IPv6 Allocation
ASN Allocation
Post Exhaustion IPv4 Allocation
New RIRs Criteria
Review Procedures
Policy Updates
Operational Design Phase (ODP)
Implementation
Public Comment
Open
Upcoming
Archive
Root Zone KSK Rollover
Technical Functions
Tech Day Archive
ICANN Locations
Report Security Issues
PGP Keys
Certificate Authority
Registry Liaison
Ombudsman
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Charter Eligibility Dispute Resolution Policy
Providers
Rules
Eligibility Requirements Dispute Resolution Policy
Providers
Rules
Intellectual Property Defensive Registration Challenge Policy
Providers
Rules
Qualification Challenge Policy
Providers
Rules
Restrictions Dispute Resolution Policy
Providers
Rules
Transfer Dispute Resolution Policy
Providers
Uniform Domain Name Dispute Resolution Policy
Policy Document
Providers
Provider Approval Process
Rules
Principal Documents
Proceedings
Historical Documents
Timeline
Name Collision
Registrar Problems
Whois Data Correction
Independent Review Process
Request for Reconsideration
Document
What's the effect of ICANN's role and work on the Internet?
This page is available in:
English
العربية
Deutsch
Español
Français
Italiano
日本語
한국어
Português
Pусский
中文
ICANN plays a unique role in the infrastructure of the Internet. Through
its contracts with registries (such as dot-com or dot-info) and registrars
(companies that sell domains names to individuals and organisations),
ICANN helps define how the domain name system functions and expands.
Registrars
ICANN created the registrar market (together with an accreditation system)
in order to introduce greater competition on the Internet. The result
has been several hundred companies able to sell domains which itself led
to a dramatic reduction in the cost of domains - an 80 percent fall. There
is now a diverse and vibrant market in the supply of the Internet’s
basic building block.
That accreditation process is currently undergoing reform in order to
keep in up-to-date with a rapidly changing domain name market.
Dispute resolution
ICANN helped design and implement a low-cost system for resolving disputes
over domain name ownership. The Uniform Domain Name Dispute Resolution
Policy (UDRP) has been used tens of thousands of times to resolve ownership
disputes, avoiding the need for costly and complex recourse to the courts.
New top-level domains
ICANN approves the introduction of new "generic top-level domains" to
the Internet - a process that expands the online space available. So far,
ICANN has introduced 13 new top-level domains to the Internet, ranging
from dot-asia to dot-travel, accounting for over six million domains.
ICANN has also developed a refined process to introduce further TLDs that
is being finalised with applications expected in early 2010.
Internationalized domain names
Through its decision-making processes, ICANN has adopted guidelines
for the introduction of internationalised domain names (IDNs), opening
the way for domain registrations in hundreds of the world’s languages
- something that will expand the use and the influence of the Internet
globally to new heights.
ICANN is not responsible for profile content or verification of user details.
YouTube
Twitter
LinkedIn
Flickr
Facebook
Newsletters
Community Wiki
ICANN Blog
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability And Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Request for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers.
Privacy Policy
Terms of Service
Cookies Policy
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."

Year pattern in URL — weak evidence, not a verified publication date