As per Relevance of the word registration, we have this rfc below:
Network Working Group J.
Request for Comments: 3071 February 2001
Category:
Reflections on the DNS, RFC 1591, and Categories of
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
RFC 1591, "Domain Name System Structure and Delegation", laid out
basic administrative design and principles for the allocation
administration of domains, from the top level down. It was
before the introduction of the world wide web (WWW) and rapid
of the Internet put significant market, social, and
pressure on domain name allocations. In recent years, 1591 has
cited by all sides in various debates, and attempts have been made
various bodies to update it or adjust its provisions, sometimes
pressures that have arguably produced policies that are less
thought out than the original. Some of those efforts have begun
misconceptions about the provisions of 1591 or the motivation
those provisions. The current directions of the Internet
for Assigned Names and Numbers (ICANN) and other groups who
determine the Domain Name System (DNS) policy directions appear to
drifting away from the policies and philosophy of 1591.
document is being published primarily for historical context
comparative purposes, essentially to document some thoughts about
1591 might have been interpreted and adjusted by the
Assigned Numbers Authority (IANA) and ICANN to better reflect today'
world while retaining characteristics and policies that have
to be effective in supporting Internet growth and stability.
earlier variation of this memo was submitted to ICANN as a comment
its evolving Top-level Domain (TLD) policies
Klensin Informational [Page 1]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
1.
RFC 1591 [1] has been heavily discussed and referenced in the
year or two, especially in discussions within ICANN and
predecessors about the creation, delegation, and management of top
level domains. In particular, the ICANN Domain Name
Organization (DNSO), and especially its ccTLD constituency, have
the home of many discussions in which 1591 and interpretations of
have been cited in support of a variety of sometimes-
positions. During that period, other discussions have gone on to
to reconstruct the thinking that went into RFC 1591. Those in
have led me and others to muse on how that original thinking
relate to some of the issues being raised. 1591 is, I believe,
of Jon Postel's masterpieces, drawing together very
philosophies (e.g., his traditional view that people are
reasonable and will do the right thing if told what it is with
stronger mechanisms when that model is not successful) into a
whole
RFC 1591 was written in the context of the assumption that what
described as generic TLDs would be bound to policies and
of registration (see the "This domain is intended..." text
section 2) while ccTLDs were expected to be used primarily to
users and uses within and for a country and its residents.
notion that different domains would be run in different ways --
within the broad contexts of "public service on behalf of
Internet community" and "trustee... for the global
community"-- was considered a design feature and a safeguard
a variety of potential abuses. Obviously the world has changed
many ways in the seven or eight years since 1591 was written.
particular, the Internet has become more heavily used and,
the design of the world wide web has put domain names in front
users, top-level domain names and registrations in them have
heavily in demand: not only has the number of hosts
dramatically during that time, but the ratio between
domain names and physical hosts has increased very significantly
The issues 1591 attempted to address when it was written and those
face today have not changed significantly in principle. But
alternative to present trends would be to take a step back to
it into a model that can function effectively today. Therefore,
may be useful to try to reconstruct 1591's principles and think
their applicability today as a model that could continue to
applied: not because it is historically significant, but because
of its elements have proven to work reasonably well, even
difficult situations. In particular, for many domains (some
1591's "generic" list and others in its "country code" category)
notion of "public service" --expected then to imply being carried
Klensin Informational [Page 2]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
at no or minimal cost to the users, not merely on a non-
basis-- has yielded to profitability calculations. And, in most
the rest, considerations of at least calculating and recovering
have crept in. While many of us feel some nostalgia for the
system, it is clear that its days are waning if not gone: perhaps
public service notions as understood when 1591 was written just don'
scale to rapid internet growth and very large numbers
yregistrations
In particular, some ccTLDs have advertised for registrations
the designated countries (or other entities), while others have
clear decisions to allow registrations by non-nationals.
decisions and others have produced protests from many sides
suggesting, in turn, that a recategorization is in order.
example, we have heard concerns by governments and managers
traditional, "public service", in-country, ccTLDs about
ICANN interference and fears of being forced to conform
internationally-set policies for dispute resolution when
domestic ones are considered more appropriate. We have also
concerns from registrars and operators of externally-marketed
about unreasonable government interference and from gTLD
and registries about unreasonable competition from
marketed ccTLDs. The appropriate distinction is no longer
what RFC 1591 described as "generic" TLDs (but which were
intended to be "purpose-specific", a term I will use again below)
ccTLDs but among
(i) true "generic" TLDs, in which any registration is
and, ordinarily, registrations from all sources are
promoted. This list currently includes (the formerly purpose
specific) COM, NET, and ORG, and some ccTLDs. There have
proposals from time to time for additional TLDs of this variety
which, as with COM (and, more recently, NET and ORG)
(generally subject only to name conflicts and national law)
register who could pay the fees
(ii) purpose-specific TLDs, in which registration is accepted
from organizations or individuals meeting
qualifications, but where those qualifications are not tied
national boundaries. This list currently includes INT, EDU,
infrastructure domain ARPA, and, arguably, the specialized
Government TLDs MIL and GOV. There have been proposals from
to time for other international TLDs of this variety, e.g.,
medical entities such as physicians and hospitals and for museums
ICANN has recently approved several TLDs of this type
describes them as "sponsored" TLDs
Klensin Informational [Page 3]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
(iii) Country domains, operated according to the
underlying assumptions of 1591, i.e., registrants are
expected to be people or other entities within the country.
external registrations might be accepted by some of these,
country does not aggressively advertise for such registrations
nor does anyone expect to derive significant fee revenue
them. All current domains in this category are ccTLDs, but
all ccTLDs are in this category
These categories are clearly orthogonal to the association
the use of the IS 3166-1 registered code list [2] and two-
"country" domain names. If that relationship is to be
(and I believe it is desirable), the only inherent requirement
that no two-letter TLDs be created except from that list (in order
avoid future conflicts). ICANN should control the allocation
delegation of TLDs using these, and other, criteria, but
registered 3166-1 two letter codes should be used as two-letter TLDs
2. Implications of the
If we had adopted this type of three-way categorization and
make it work, I believe it would have presented several
for ICANN and the community more generally to reduce
and move forward. Of course, there will be cases where
categorization of a particular domain and its operating style
not be completely clear-cut (see section 3, below). But having
work out procedures for dealing with those (probably few)
appears preferable to strategies that would tend to propel ICANN
areas that are beyond its competence or that might
significant expansion of its mandate
First, the internally-operated ccTLDs (category iii above) should
be required to have much interaction with ICANN or vice versa.
a domain of this sort is established and delegated, and assuming
the "admin contact in the country" rule is strictly observed,
domain should be able to function effectively without
intervention or oversight. In particular, while a country
choose to adopt the general ICANN policies about dispute
or name management, issues that arise in these areas might
well be dealt with exclusively under applicable national laws. If
domain chooses to use ICANN services that cost resources to provide
it should contribute to ICANN's support, but, if it does not,
should not presume to charge it for other than a reasonable
of the costs to ICANN of operating the root, root servers, and
directory systems that are generally agreed upon to be necessary
in which the domain participates
Klensin Informational [Page 4]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
By contrast, ccTLDs operated as generic domains ought to be
as generic domains. ICANN dispute resolution and name
policies and any special rules developed to protect the
public in multiple registrar or registry situations should
apply
3. Telling TLD types
If appropriate policies are adopted, ccTLDs operated as
domains (category (i) above) and those operated as country
(category (iii) above) ought to be able to be self-identified.
are several criteria that could be applied to make
determination. For example, either a domain is aggressively
outside registrations or it is not and either the vast majority
registrants in a domain are in-country or they are not. One
also think of this as the issue of having some tangible level
presence in the jurisdiction - e.g., is the administrative
subject, in practical terms, to the in-country laws, or are
registration rules such that it is reasonably likely that a court
the jurisdiction of the country associated with the domain
exercise jurisdiction and enforce a judgment against the registrant
One (fairly non-intrusive) rule ICANN might well impose on all top
level domains is that they identify and publish the policies
intend to use. E.g., registrants in a domain that will use the
of one particular country to resolve disputes should have
reasonable opportunity to understand those policies prior
registration and to make other arrangements (e.g., to
elsewhere) if that mechanism for dispute resolution is
acceptable. Giving IANA (as the root registrar)
information about the purpose and use of a domain should be
to challenge, and should be grounds for reviewing the
of the domain delegation, just as not acting consistently
equitably provides such grounds under the original provisions of
1591.
In order to ensure the availability of accurate and up-to-
registration information the criteria must be consistent,
consistent with more traditional gTLDs, for all nominally
code domains operating as generic TLDs
4. The role of ICANN in country
ICANN (and IANA) should, as described above, have as
involvement as possible in the direction of true country [code
domains (i.e., category (iii)). There is no particular reason
Klensin Informational [Page 5]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
these domains should be subject to ICANN regulation beyond the
principles of 1591 and associated arrangements needed to
Internet interoperability and stability
ICANN's avoiding such involvement strengthens it: the desirability
avoiding collisions with national sovereignty, determinations
government legitimacy, and the authority of someone
writing on behalf of a government, is as important today as it
when 1591 was written. The alternatives take us quickly
"administration" into "internet governance" or, in the case
determining which claimant is the legitimate government of a country
"international relations", and the reasons for not moving in
particular direction are legion
5. The role of
The history of IANA strategy in handling ccTLDs included three
"things to avoid" considerations
* Never get involved in determining which entities were
and which ones were not
* Never get involved in determining who was, or was not,
legitimate government of a country. And, more generally,
deciding what entity --government, religion, commercial
academic, etc.-- has what legitimacy or rights
* If possible, never become involved in in-country disputes
Instead, very strongly encourage internal parties to
problems out among themselves. At most, adopt a role
mediator and educator, rather than judge, unless abuses are
clear and clearly will not be settled by any internal mechanism
All three considerations were obviously intended to avoid IANA'
being dragged into a political morass in which it had (and,
suggest, has) no competence to resolve the issues and could only
bogged down. The first consideration was the most visible (and
easiest) and was implemented by strict and careful adherence (
below) to the ISO 3166 registered Country Code list. If an
had a code, it was eligible to be registered with a TLD (
IANA was free to apply additional criteria-most of them stated
1591). If it did not, there were no exceptions: the applicant's
recourse was a discussion with the 3166 Registration Authority (
Maintenance Agency, often known just as "3166/MA") or the
Statistical Office (now Statistics Bureau), not with IANA
Klensin Informational [Page 6]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
There are actually five ccTLD exceptions to the strict rules. One
"UK", is historical: it predates the adoption of ISO 3166 for
purpose. The others --Ascension Island, Guernsey, Isle of Man,
Jersey --are arguably, at least in retrospect, just mistakes
Regardless of the historical reasons (about which there has been
speculation), it is almost certainly the case that the right way
handle mistakes of this sort is to acknowledge them and move on
rather than trying to use them as precedents to justify
mistakes
This, obviously, is also the argument against use of the "reserved
list (technically internal to the 3166 maintenance activity, and
part of the Standard): since IANA (or ICANN) can ask that a name
placed on that list, there is no rule of an absolute determination
an external organization. Purported countries can come to ICANN
insist on having delegations made and persuade ICANN to ask that
names be reserved. Then, since the reserved name would exist,
could insist that the domain be delegated. Worse, someone could
another organization to request reservation of the name by 3166/MA
once it was reserved, ICANN might be hard-pressed not to do
delegation. Of course, ICANN could (and probably would be forced to
adopt additional criteria other than appearance on the "
list" in order to delegate such domains. But those criteria
almost certainly be nearly equivalent to determining which
were legitimate and stable enough to be considered a country,
exact decision process that 1591 strove to avoid
The other two considerations were more subtle and not
successful: from time to time, both before and after the
policy shifted toward "governments could have their way",
received letters from people purporting to be competent
authorities asking for changes. Some of them turned out later to
have that authority or appropriate qualifications. The assumption
1591 itself was that, if the "administrative contact in country"
was strictly observed, as was the rule that delegation
requested by the administrative contact would be honored, then, if
government _really_ wanted to assert itself, it could pressure
administrative contact into requesting the changes it wanted,
whatever would pass for due process in that country. And the
to apply that process and pressure would effectively determine
was the government and who wasn't, and would do so far
effectively than any IANA evaluation of, e.g., whether the
on a request looked authentic (and far more safely for ICANN
asking the opinion of any particular other government or selection
governments).
Klensin Informational [Page 7]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
Specific language in 1591 permitted IANA to adopt a "work it
yourselves; if we have to decide, we will strive for a solution
is not satisfactory to any party" stance. That approach was
successfully, along with large doses of education, on many
over the years, to avoid IANA's having to assume the role of
between conflicting parties
Similar principles could be applied to the boundary between country
code-based generic TLDs and country domains. Different countries
under different circumstances, might prefer to operate the
either as a national service or as a profit center where
"customers" were largely external. Whatever decisions were
historically, general Internet stability argues that changes
not be made lightly. At the same time, if a government wishes
make a change, the best mechanism for doing so is not to
ICANN in a potential determination of legitimacy (or even to
ICANN's Government Advisory Committee (GAC) try to formally make
decision for individual countries) but for the relevant government
use its own procedures to persuade the administrative contact
request the change and for IANA to promptly and efficiently carry
requests made by administrative contacts
6. Implications for the current ICANN DNSO structure
The arguments by some of the ccTLD administrators that they
different from the rest of the ICANN and DNSO structures are (in
model) correct: they are different. The ccTLDs that are operating
generic TLDs should be separated from the ccTLD constituency
joined to the gTLD constituency. The country ccTLDs should
separated from ICANN's immediate Supporting Organization structure
and operate in a parallel and advisory capacity to ICANN, similar
the arrangements used with the GAC. The DNSO and country TLDs
not be required to interact with each other except on a
voluntary basis and, if ICANN needs interaction or advice from
of all of those TLDs, it would be more appropriate to get it in
form of an advisory body like the GAC rather than as
constituency
7.
[1] Postel, J., "Domain Name System Structure and Delegation",
1591, March 1994.
[2] ISO 3166. ISO 3166-1. Codes for the representation of names
countries and their subdivisions - Part 1: Country codes (1997).
Klensin Informational [Page 8]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
8. Acknowledgements and
These reflections have been prepared in my individual capacity and
not necessarily reflect the views of my past or present employers
Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel
Geoff Huston, Havard Eidnes, and several anonymous reviewers,
suggestions or offered editorial comments about earlier versions
this document. Cord Wischhoefer, of the ISO 3166/MA, was also
enough to look at the draft and supplied some useful details.
comments contributed significantly to whatever clarity the
has, but the author bears responsibility for the selection
comments which were ultimately incorporated and the way in which
conclusions were presented
9. Security
This memo addresses the context for a set of administrative
and procedures, and does not raise or address security issues
10. Author's
John C.
1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140,
EMail: klensin@jck.
Klensin Informational [Page 9]
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
11. Full Copyright
Copyright (C) The Internet Society 2001. All Rights Reserved
This document and translations of it may be copied and furnished
others provided that the above copyright notice and this
are included on all such copies. However, this document itself
not be modified in any way, such as by removing the copyright
or references to the Internet Society or other
organizations, except as required to translate it into
other than English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Klensin Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
