INTERNET DRAFT                                                   R. Bush
draft-ymbk-itld-admin-00.txt                                       RGnet
                                                            B. Carpenter
                                                               J. Postel
                                                            January 1996

         Delegation of International Top Level Domains (iTLDs)

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a working
   draft or work in progress.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on,,, or

0. Abstract

  This document describes policies and procedures to
    o allow open competition in domain name registration in the iTLDs,
    o allow multiple registries for the COM and other iTLDs,
    o and provide the IANA with a legal and financial umbrella

1. Introduction

  For the purpose of delegation, the top level domains (TLDs) fall into
  the categories listed below.  While all are described to provide
  context, only the last is the subject of this document.

  1.1. National TLDs

    National TLDs such as AF, FR, US, ... ZW are named in accordance

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 1]

INTERNET DRAFT            Delegation of iTLDs               January 1996

    with ISO 3166, and have, in the major part, been delegated to
    national naming registries.  Any further delegation of these TLDs is
    undertaken by the Internet Assigned Number Authority (IANA), in
    accordance with the policies described in RFC 1591.

    It is good practice for these delegated TLD registries to publicly
    document the applicable management policies and further delegation
    procedures for these national domains, as, for example, RFC 1480
    does for the US domain.

  1.2. US Governmental TLDs

    1.2.1. Delegation of the GOV zone is described by RFC 1816, and is
    under the authority of the US Federal Networking Council (FNC).

    1.2.2. Delegation of the MIL domain is under the authority of the
    DDN NIC.  [ is there a descriptive or governing document? ]

  1.3. Infrastructure TLDs

    TLDs such as IN-ADDR.ARPA and INT are under the authority of the
    IANA and may be delegated to others, e.g. IN-ADDR.ARPA is currently
    delegated to the InterNIC for day-to-day management.  They are
    created for technical needs internal to the operation of the
    internet at the discretion of the IANA in consultation with the

  1.4 The EDU TLD

    Delegation of the EDU domain is under the authority of the FNC and
    is currently delegated to the NSF which has contracted to the
    InterNIC for registration.

    Over time, the FNC and NSF may decide to use other delegation
    models, such as those described below for non-governmental zones.

    Some people (Americans and non-) feel that EDU should be restricted
    to US institutions.  That is outside the scope of this discussion.

  1.5 The International Top Level Domains (iTLDs) COM, ORG, and NET

    The iTLDs are generic top level domains which are open to general
    registration.  They are currently delegated to the InterNIC by the
    authority of the IANA.

    1.5.1. The intent for these iTLDs is discussed in RFC 1591.
    Generally, COM is for commercial entities, NET is for the internal
    infrastructure of service providers, and ORG is for miscellaneous

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 2]

INTERNET DRAFT            Delegation of iTLDs               January 1996


    1.5.2. There is a perceived need to open the market in commercial
    iTLDs to allow competition, differentiation, and change.

    1.5.3. As the net becomes larger and more commercial, the IANA needs
    a formal body to accept indemnity for the touchy legal issues which
    arise surrounding DNS policy and its implementation.

2. Goals

  To facilitate administration of the domain name subsystem within the
  Internet by ensuring that there is an open and competitive marketplace
  for clients to obtain and subsequently maintain delegation of sub-
  domains within the iTLDs, while preserving the operational integrity
  of the Internet DNS itself.

  The specific measures to achieve this objective are as follows:

  2.1. Provide the IANA with the international legal and financial
  umbrella of the Internet Society (ISOC),

  2.2. Allow open competition in domain name registration in the iTLDs,
  which will then allow registries to charge for their services,

  2.3. Allow multiple registries to operate cooperatively and fairly in
  the COM domain and/or other multi-registry iTLDs which may be created,

  2.4. Facilitate creation of new iTLDs in a fair and useful, but
  reliable, fashion,

  2.5. Provide for reliable maintenance of the registrants of an iTLD
  should the current delegatee no longer wish to maintain it, and

  2.6. Define iTLD policies and procedures by open methods, modeled on
  the IETF process and/or using IETF mechanisms when appropriate.

3.0 Scope of this Document

  This document describes the administrative structure for the operation
  of the iTLDs.  While other administrative issues may exist within the
  broader domain of the DNS, they are not addressed in this document.


  3.1. Only those relationships between the IANA, IETF, ISOC, etc. which
  are specifically necessary for responsible maintenance of the iTLDs

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 3]

INTERNET DRAFT            Delegation of iTLDs               January 1996

  are described.

  3.2. It would not be reasonable for this document to specify what
  particular agent, board, or committee of the ISOC, IANA, or IETF acts
  for each.  Hence, they are described in generic terms, and left for
  each organization to specifcy.  This specification may change from
  time to time.

  At this writing, the Board of Trustees acts for the ISOC, the IAB for
  the IETF, and the IANA for itself.

  3.3. Long range maintenance of the IANA is not described; although it
  is believed that the IANA could draw financial support from a wider

  3.4. The IETF is not directly involved in operation of the net.  Hence
  it serves the iTLD administrative work mainly in a technical capacity,
  such as the formalization of new protocols and handling of technical

  3.5. The ISOC does not directly operate the net.  But it takes legal
  responsibility, provides ad hoc group members, manages funds, and
  participates in the appeals process.

  3.6. The IANA and any necessary ad hoc groups deal with operational

  3.7. The ISOC, the IETF, and the IANA are no be legally or financially
  responsible for the registries.  The registries must be responsible
  for themselves.

  3.8. Creation of permanent bureaucracy is not desired.

4. Technical Assumptions

  Further growth within the iTLDs can be accommodated technically, and
  tools are in evidence to automate much of the process of registration
  and maintenance of entries within the DNS as well as multiple
  administrative access to a single delegated domain.

  4.1. The size of current zones such as COM, while large, is not really
  a burden on servers, nor is it expected to become so in the near

  4.2.  Procedures which allow mutual exclusion for the creation of
  names within a single zone are being developed within the IETF's
  dnsind and dnssec WGs, and a test implementation is available.

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 4]

INTERNET DRAFT            Delegation of iTLDs               January 1996

  4.3. Tools are being developed to ease the processes of registration
  and running the information servers which are expected of registries.

5. The Process

  5.1. The IANA continues to supervise and control all operational
  aspects of the iTLDs, and is the first level of the appeals process
  after that of the registries.  It appoints members to the ad hoc iTLD

  5.2. The IETF, as part of its normal procedures, publishes documents
  which describe technical and operational aspects of the domain space
  including the iTLDs.  It also provides an appeals procedure for
  technical issues and appoints members to the ad hoc iTLD group(s).

  5.3. The ISOC provides the legal and financial umbrella, and the final
  level of the appeal process.  It provides an appeals procedure for
  procedural issues and appoints members to the ad hoc iTLD group(s).
  The ISOC assumes legal liability for the process and the iTLDs.

  5.4. Ad hoc working groups, for developing procedures and deciding
  creation of new iTLDs and chartering of registries, consist of seven
  members appointed by the IANA, the IETF, and the ISOC.

  5.5. Note that 'ad hoc' means 'for this purpose only.'  In this case,
  an ad hoc group is created and convened on a periodic basis when
  needed to change procedures or to review iTLD applications.

  5.6. Some may feel that this is too informal.  Should this opinion
  prevail, a permanent panel would be created, with two members each
  appointed by the IANA, the IETF, and the ISOC and one member mutually
  chosen from the general community.  Members would serve two year
  staggered terms.

  5.7. The process/policy development may take three to six months, and
  initial chartering another six.  It is estimated that approximately
  five new iTLDs will be created a year.

  5.8. The policies and procedures to be used by the ad hoc working
  group will be decided by the zeroeth ad hoc group in an open process
  and will be clearly documented.  This group will be appointed and
  convene in March or April 1996.  It is expected that these policies
  and procedures will mature over time.

  5.9. Multiple registries for the COM zone, and registries for new
  iTLDs will be created.

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 5]

INTERNET DRAFT            Delegation of iTLDs               January 1996

  5.10. New iTLDs will be created over time.  This is a direct change to
  RFC 1591.  New iTLDs may be created with a non-exclusive
  administration arrangement, i.e. multiple operators for any further
  iTLDs may be within the provisions of creation of an iTLD.

  5.11. The intent is similar to the licensing of radio stations in some
  countries, a few commercial ones and a few public service ones.

  5.12. Registries pay for charters, and the fees collected are kept in
  a fund managed by the ISOC and used solely for the iTLD process,
  insurance against an iTLD registry withdrawal or collapse, and
  possibly to support an evolved future funding model for the IANA.

6. Selection of iTLDs and Registries

  6.1. There are useful proposals for registries and iTLDs which are not
  able to demonstrate solid financial stability and/or raise sufficient
  funding to ensure continued operation to protect the registrants
  should their efforts fail.  Yet it is desirable that these technical
  and social experiments be conducted.

  Hence, two types of charter are provided, commercial and public
  service, with the understanding that fees from commercial registry
  charters cross-subsidize low fees from public service efforts.

  This is intended to provide, among other benefits, a path for
  migration of the EDU and other TLDs.

  iTLD and registry charter applications specify whether they are
  commercial or public service.

  6.2 An application is for chartering a new registry for an existing
  iTLD, or for creation of a new iTLD and creation of one or more

  If a new iTLD is proposed, then it is assumed to allow chartering of
  multiple registries unless exclusive registration charter is specified
  in the application.  Request for exclusive registration must be well
  motivated and well justified.

  6.3. Financial and business aspects of proposals are kept confidential
  during the evaluation process, as a bidding war is not desirable.

  Charter approval does not necessarily go to the highest bidder.
  Reliability, quality of service, sustainability, etc. are more
  important criteria.

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 6]

INTERNET DRAFT            Delegation of iTLDs               January 1996

  6.4. When a registry which has provided good quality and reliable
  service comes up for charter renewal, barring unusual circumstances,
  the charter renewal application should be approved.

  6.5. All applications are judged on
    6.5.1. a clear statement of charter, policies, and procedures,
    including whether the iTLD is to have shared registries or be
    6.5.2. organizational and technical competence to run a registry and
    the expected accompanying information services,
    6.5.3. innovation in type of service, audience, or technology,
    6.5.4. a statement of registrant qualification procedures and a
    statement that they will be non-discriminatory,
    6.5.5. a clear description of the appeals mechanism within the
    registry, including its guaranteed response time,
    6.5.6. a statement that the registry will abide by the results of
    the appeals process and the direction of the IANA,
    6.5.7. indemnification of ISOC, IANA, IETF, ad hoc committees, and
    all others believed to be at risk from this process, as well as the
    usual prudent insurance, and
    6.5.8. guaranteed availability of the registration data in a useful
    form should transfer of responsibility become necessary, e.g.
    regular publication of the information, or regular deposits of
    copies of the information with a reputable escrow agent instructed
    to release the information to the IANA.

  6.6. In addition, commercial applications are judged on
    6.6.1. a business and financial plan which shows sufficient
    viability that the registry is likely to operate successfully for at
    least five years,
    6.6.2. a bid to be paid to the iTLD fund if charter is awarded, and
    6.6.3. a bid to be paid annually to the iTLD fund.

  6.7. In addition, public service applications are judged on
    6.7.1. clear demonstration of goals and means which are in the
    public good and which have not been or might not be satisfied by a
    commercial applicant,
    6.7.2. a business and financial plan which need only show viability
    and cost recovery, and which might even rely on income from donor
    agencies, and
    6.7.3. a minimal annual fee of USD5,000 to the iTLD fund.

  6.8. Charters are for a period of five years, but annual progress
  reports are submitted for review by IANA and the ad hoc group.  Only
  in exceptional cases of radical change or abuse of a charter may the
  IANA or the ad hoc group recommend to the IANA and ISOC that the
  charter be reevaluated before the charter period is reached (see
  appeals process).

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 7]

INTERNET DRAFT            Delegation of iTLDs               January 1996

7. Finances

  7.1. A registry may charge as it sees fit, within the bounds of the
  policy published when it is chartered.

  7.2. iTLD registries may decide they no longer wish to operate their
  registry.  Likely, the operation will not be profitable when this
  occurs, yet the registrants under the iTLD may need to be supported
  for a considerable time.

  A significant amount of the chartering fees in the ISOC-managed iTLD
  fund are reserved to pay for some other entity to operate the failing
  iTLD or registry until it again becomes viable or until the
  registrants have safely migrated elsewhere.

  The iTLD process must be prepared for the case where a very popular,
  possibly because it is low cost, iTLD or registry fails.  Bailing out
  the registrants of a failing domain could be very expensive, even on
  the order of a million USD (remember, a likely failure mode may be
  because someone thought they could do it for less).  So prudent
  reserves must be kept.

  7.3. The ISOC manages all finances in a separate iTLD fund with open
  reporting and published budgets.  Agreement of the ISOC, the IANA, and
  the IETF is required on all budgets.

  7.4. Charter fee income is used to pay legal costs of the IANA, IETF,
  ISOC, and ad hoc groups when serious legal disputes arise from the

  7.5. Charter fee income is also used to pay modest and publicly
  visible costs of the chartering process, e.g. the costs of the ad hoc

  7.6. Charter fee income may also be used to fund the IANA if and when
  the IANA becomes more openly funded.

  7.7. Should the reserves be embarrassingly large, a consensus of the
  IANA, IETF, and ISOC Board would allow disbursements for the general
  network good, e.g. scholarships for engineers from developing
  countries, etc.

  7.8. The ISOC charges a modest amount for administering the iTLD

8. Appeals

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 8]

INTERNET DRAFT            Delegation of iTLDs               January 1996

  Arbitration to resolve conflicts is encouraged.  That an appeals
  process is specified should not preclude use of arbitration.  The
  appeals process described here is for when arbitration has failed or
  when the parties decide not to use arbitration, yet they do not wish
  to exercise recourse to lawyers and the courts.

  8.1. The appeals process does not apply to disputes over Intellectual
  Property Rights on names (trademark, service mark, copyright).  These
  disputes are best left to arbitration or the courts.  Registries may
  require appropriate waivers from registrants.

  8.2. The appeals process does not apply to charging and billing.  This
  is left to market forces, arbitration, and the courts.

  8.3. The appeals process applies to all other aspect of registry
  processing of registration requests.

  8.4. A registrant's first recourse is to the registry which has denied
  them registration or otherwise annoyed them.

  8.5. All registries must specify in their applications an entry point
  and a process for appeals, as well as a response time, and must
  subsequently conform to them.

  8.6. If appellant is dissatisfied with the registry response, appeal
  may be escalated to the IANA.

  8.7. The IANA must define its entry point for appeals and must respond
  to appeals within four weeks.

  8.8. If appellant is dissatisfied with the IANA response, and the
  appeal has nontrivial technical aspects, the appeal may be escalated
  to the IETF.  The IETF hears appeals based only on technical issues.

  8.9. If appellant is dissatisfied with the IANA and, if invoked, the
  IETF response, appeal may be escalated to the ISOC.  The ISOC appeals
  process hears appeals only against breach of appeals procedure.  I.e.
  the decision of IANA and/or IETF is final, unless there is an appeal
  against breach of appeals procedure.

  8.10. The appeals process works by email.  Appellant must provide
  concise history of the case and summarize grounds of appeal.  The
  IANA, The IETF, or the ISOC may ask for information from third
  parties.  All information is normally treated as nonconfidential and
  may be made publicly available.  Confidential information is
  considered only in special circumstances.

  8.11. The IANA, the IETF and the ISOC establish appeals sub-committees

Bush, Carpenter, Postel   Expires Jul 22, 1996                  [Page 9]

INTERNET DRAFT            Delegation of iTLDs               January 1996

  chosen either from their own membership or outside of it by whatever
  means each deems reasonable for their procedures and purposes.

9. Appendix A - A Thousand Domains Experiment

  It has been suggested that the root domain be opened up to a fairly
  arbitrary registration of new iTLDs.  While the idea has its social
    o it would be an irreversible decision with no prior experience and
    o some argue that TLDs, like global variables, should be few and
      created with great care.

  Therefore we suggest that one of the early public service proposals
  that should be seriously considered would be one which proposes a
  shared iTLD which would have very open creation of sub-registries;
  thereby conducting the 1,000 domain experiment one level down.

10. Security Considerations

  There are no known security considerations beyond those already extant
  in the DNS.

11. Acknowledgments

  A lot of significant and constructive input and review was received
  from the following kind folk:

    Alan Barrett <>
    Robert Elz   <>
    Geoff Huston <>
    John Klensin <>

12. Authors' Addresses

    Randy Bush
    Unaligned geek
    9501 SW Westhaven                        Phone: +1 503 227-5665
    Portland, Oregon 97225                   Fax:   +1 503 297-9078
    USA                                      Email:

    Brian E. Carpenter
    IAB Chair
    Group Leader, Communications Systems      Phone: +41 22 767-4967

Bush, Carpenter, Postel   Expires Jul 22, 1996                 [Page 10]

INTERNET DRAFT            Delegation of iTLDs               January 1996

    Computing and Networks Division           Fax:   +41 22 767-7155
    European Laboratory for Particle Physics  Email:
    1211 Geneva 23, Switzerland

    Jon Postel
    IANA                                      Phone: +1 310 822-1511
    USC/Information Sciences Institute        Fax:   +1 310 823-6714
    4676 Admiralty Way
    Marina del Rey, CA 90292                  Email: Postel@ISI.EDU

Bush, Carpenter, Postel   Expires Jul 22, 1996                 [Page 11]