ID: Existing TLD Applications

INTERNET-DRAFT                                              Simon Higgs
Catagory: Informational                                   Higgs America
Expires 7/1/1997                                          December 1996

                       Existing TLD Applications
                   < draft-iahc-higgs-tld-app-00.txt >


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 and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``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 ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   This document is being distributed to members of the Internet
   community in order to solicit their reactions to the proposals
   contained in it.

   There are many applications for Top Level Domains currently
   submitted to IANA that have not been processed yet. This document
   explains why the Internet Ad Hoc Committee (IAHC) must process
   these applications. This document does not make distinctions
   between iTLDs, ISO-3166 TLDs, or any other type of TLD since
   [RFC 1591] clearly states that "the same rules are applied to all
   requests".


Introduction

In January of 1993, the InterNIC was established as a collaborative
project between AT&T, General Atomics and Network Solutions, Inc. and
supported by three five-year cooperative agreements with the National
Science Foundation. AT&T was to manage the InterNIC Directory and
Database Services project; NSI was to manage the Registration Services
project, and General Atomics was to manage the Information Services
project.

These agreements stipulated that a peer review during the second year
of performance would determine the future level of funding. The review
found that General Atomics was not providing the promised level of
service to the community and recommended that funding be discontinued.
NSF agreed with this recommendation and in February of 1995 terminated
the cooperative agreement with General Atomics. Steps were taken to
minimize the disruption to the research and education community and to
continue the services which the panel identified as having significant
value.

A key portion of the second year review is as follows:

   It is clear from the materials presented by NSI that a primary
   culprit in the RS work load is the .COM domain. The current
   management of .COM is not scalable since .COM is a flat domain name
   space, and thus the load of administering .COM falls solely on NSI.
   At present, the management of .COM is paid for by the NSF, and
   hence increasing demand for .COM registrations will require
   increasing support from the NSF. The panel recommends that NSI
   begin charging for .COM domain name registrations, and later charge
   for name registrations in all domains. Over the long run, the panel
   recommends that NSI charge for all IP registration services.

   During panel discussions a consensus emerged on a possible charging
   model that requests an initial fee for registering a name, and a
   recurring annual fee for subsequent administration of the name
   space, to cover costs due to updating entries, ensuring uniqueness
   of names in the name space, operation of root name servers, etc. It
   was noted that the charge for initial registration and recurring
   fees did not logically have to be the same amount. However,
   charging the same amount would allow NSI to state that everyone,
   including those who already have Internet domain names, will have
   to pay the same amount within the initial 12 months and this might
   prevent a last minute, "get them while they are free" rush on
   domain names. NSI should consult with the NSF in the development of
   such a policy. The NSF needs to plan mechanisms for defraying the
   costs for institutions, such as U.S. R&E sites that would fall
   under the .EDU domain, that may not be able to bear the new charges
   directly. In the ideal scenario, any new plans should be in the
   direction of a fee to the end user of a name, and thus would
   facilitate the NSF's getting out of the name registration business.
                    [http://rs.internic.net/nsf/review/section6.html]

In the summer of 1995, InterNIC Registration Services, run by Network
Solutions Inc., introduced a policy whereby it would charge $100 for an
initial domain name registration which would then be valid for two
years, and would charge $50 per year for each year that a domain name
was renewed. This event was pivotal and created a paradym shift in the
nature of the internet domain namespace as the InterNIC's registration
services, which were no longer funded by the NSF, were now allowed to
be run for-profit.

Since this event in 1995, portions of the community feel there is a
need for new TLDs (and their supporting registries) other than the
ISO-3166 TLDs. Many organizations have, as a result of the
interpretation of [RFC 1591] in the light of the internet's new
commercial environment, applied to the IANA to be delegated new top
level domains. Many feel that they could compete with NSI in providing
registration services for domain names, and others feel there is
justification in granting new TLDs in order to open up the flat domain
namespace and provide competition for what has become a domain name
monopoly. Either way, it is clear from the size of the .COM zone file
that becoming a domain name registry is a viable business opportunity,
and that appears to be driving most of the new TLD applications.


New Top Level Domain Applications

The application process is documented in [RFC 1591], which describes
the delegation and use of the existing top level domains COM. EDU, NET,
ORG, INT, GOV, MIL, and the ISO-3166 two letter country code domains.
It also describes the role of the Internet Assigned Numbers Authority
(IANA), which is responsible for the overall coordination and
management of the Domain Name System (DNS), and especially the
delegation of portions of the name space called top-level domains.

[RFC 1591] states "all requests for new top-level domains must be sent
to the Internic (at hostmaster@internic.net)". If approved, these top
level domains are added to the root.zone file which is carried by the
root DNS servers. The latest root.zone can be found at:
                           [ftp://rs.internic.net/domain/root.zone.gz]

What has caused confusion is the scope in which [RFC 1591] accepts new
top level domain name applications. Some have argued that historically
only new ISO-3166 TLDs have been granted and that is the entire scope
of this RFC. The actual paragraph that is in question is quoted here:

2.  The Top Level Structure of the Domain Names

   In the Domain Name System (DNS) naming of computers there is a
   hierarchy of names.  The root of system is unnamed.  There are a set
   of what are called "top-level domain names" (TLDs).  These are the
   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
   letter country codes from ISO-3166.  It is extremely unlikely that
   any other TLDs will be created.

Expectation and reality aren't always the same thing, just like
financial projections and earnings aren't the same. Does this paragraph
mean that:

   a) No new TLDs of any sort will be delegated in the future?
   b) Only new ISO-3166 domains will be delegated in the future?
   c) There is no perceived need for additonal TLDs at this time?

It is quite apparent that any two letter country codes identified by
ISO-3166 could be added at the request of that country's government at
any time. It does not say other TLDs will not be created, just that it
is unlikely that they will. It was, presumably, left open like this in
case there was a future need for other types of TLDs. It certainly
does not say that new TLD applications outside of ISO-3166 (such as
the majority of new TLD applications currently submitted to IANA), are
not valid applications. [RFC 1591] is quite clear on the issue of
processing applications for new TLDs:

   3) The designated manager must be equitable to all groups in the
      domain that request domain names.

      This means that the same rules are applied to all requests, all
      requests must be processed in a non-discriminatory fashion, and
      academic and commercial (and other) users are treated on an equal
      basis.  No bias shall be shown regarding requests that may come
      from customers of some other business related to the manager --
      e.g., no preferential service for customers of a particular data
      network provider.  There can be no requirement that a particular
      mail system (or other application), protocol, or product be used.

      There are no requirements on subdomains of top-level domains
      beyond the requirements on higher-level domains themselves.  That
      is, the requirements in this memo are applied recursively.  In
      particular, all subdomains shall be allowed to operate their own
      domain name servers, providing in them whatever information the
      subdomain manager sees fit (as long as it is true and correct).

It quite clearly states that the same rules are applied to all TLD
requests. This means that the assumption by some that only ISO-3166
TLDs should be processed is incorrect.

It also says that all requests must be processed in a
non-discriminatory fashion, and academic and commercial (and other)
users are treated on an equal basis. It is quite clear that every
application received by IANA must be processed, and that this (because
the requirements are applied recursively), includes all the existing
TLD applications received by IANA.

No word has come from IANA as to why these new TLD applications
have not been processed. It has however, in conjunction with the
Internet Society (ISOC), International Telecommunication Union (ITU),
World Intellectual Property Organization (WIPO), International
Trademark Association (INTA), and the Internet Architecture Board
(IAB), created the International Ad Hoc Committee (IAHC) which will
address the legal, administrative, technical and operational concerns,
with particular attention to the questions of fairness and functional
stability of the domain name space. It is now before this working group
that these exisitng TLD applications must wait.


Why The Concern?

There is a trust issue at stake here. The voluntary acceptance of the
IETF/RFC authority structure by the internet community has ensured that
the domain name space, and the internet as a whole, have not become
divided or fragmented. Losing that trust invites organizations to build
incompatible standards, alternative DNS root servers, and ultimately
issue name space which is incompatible or duplicates the IANA delegated
namespace.

Should the existing TLD applications not be processed, and the public
trust and confidence in the IETF/RFC authority structure be lost, the
repercussions will irrevocably damage IANA, and IAHC and it's
participating members ability to manage the namespace. As a result,
government intervention and uneccessary regulation and taxation will be
forced upon the internet community in order to resolve issues that
could quite easily be avoided now with a little diplomacy.


Recommendations Of This Memo

It is the recommendation of this memo, to the IAHC, to process the
existing TLD applications that have been filed per RFC1591 with IANA.
This memo does not explain how to go about the processing of
applications, only that it must be done.




Author's Address

      Simon Higgs
      Higgs America
      P.O. Box XXXX
      XXXXXXXX, XX XXXXX-XXXX
      Phone: XXX-XXX-XXXX
      Fax:   XXX-XXX-XXXX
      email: XXXXX@XXXXX.XXX

This document expires 7/1/1997