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
