Reflections on the DNS, RFC
1591, and Categories of Domains
John C. Klensin
1. Introduction
As
things have unfolded in the DNSO over the last several
months, I've been trying
to reconstruct the thinking that went
into RFC 1591 and musing on how that might
relate to some of the
issues. 1591 is, I believe, one of Jon Postel's masterpieces,
drawing
together very different philosophies (e.g., his
traditional view that people are
basically reasonable and will
do the right thing if told what it is with some
stronger
mechanisms when that model is not successful) into a single
whole.
It
was written in the context of the assumption that what it
described as generic
TLDs would be bound to policies and
categories of registration (see the "This
domain is intended..."
text in section 2) while ccTLDs were expected to be used
primarily
to support users and uses within and for a country and
its residents. The
notion that different domains would be run
in different ways --albeit within the
broad contexts of "public
service on behalf of the Internet community" and "trustee...
for
the global Internet community"-- was considered a design feature
and a
safeguard against a variety of potential abuses.
Obviously the world has changed
in many ways in the five or six
years since 1591 was written. In particular,
the Internet has
become more heavily used and, because the design of the
worldwide
web has put domain names in front of users, top-level
domain names and registrations
in them have been heavily in
demand: not only has the number of hosts increased
dramatically
during that time, but the ratio between registered domain names
and
hosts has increased. The issues 1591 attempted to address
when it was written
and those we face today have not changed
much in principle. But we should take
a step back to refine a
model that can be function effectively today. Therefore,
it may
be useful to try to reconstruct 1591's principles and think
about their
applicability today as a model that can continue to
be applied: not because it
is historic, but because many of its
elements are proven to work reasonably well,
even in difficult
situations. In particular, for many domains (some in 1591's
"generic"
list and others in its "country code" category)the
notion of "public service"
--expected then to be carried out at
no or minimal cost to the users, not merely
on a non-profit
basis-- has yielded to profitability calculations. And,
in most
of the rest, considerations of at least calculating and
recovering
costs have crept in. While many of us feel some
nostalgia for the old system,
it is clear that its days are
waning if not gone: perhaps the public service notions
as
understood when 1591 was written just don't scale to rapid
internet growth
and very large numbers of registrations.
In particular, as some ccTLDs have advertised
for registrations
outside the designated countries (or other entities), while
others
have made clear decisions to allow registrations by
non-nationals (e.g., the UK
or Australia) protests from many
sides suggest that a recategorization is in order.
For example,
we have heard concerns by governments and managers oof
traditional,
"public service"/ in country, ccTLDs about
excessive ICANN interference.
We have also heard concerns from
registrars and operators of externally-marketed
ccTLDs about
unreasonable government interference and from gTLD registrars
and
registries about unreasonable competition from aggressively
marketed ccTLDs. The
appropriate distinction is no longer
between what RFC 1591 described as "generic"
TLDs (but which
were really intended to be "purpose-specific", a term I will use
again
below) and ccTLDs but among:
(i) true "generic" TLDs, in which any registration
is acceptable
and, ordinarily, registrations from all sources are actively
promoted.
This list currently includes (the formerly
purpose-specific) COM, NET, and ORG,
and some ccTLDs. There have
been proposals from time to time for additional TLDs
of this
variety in which, as with COM (and, more recently, NET and ORG)
anyone
(generally subject only to name conflicts and national
law) could register who
could pay the fees.
(ii) purpose-specific TLDs, in which registration is accepted
only
from organizations or individuals meeting particular
qualifications, but where
those qualifications are not tied to
national boundaries. This list currently
includes INT, EDU, the
infrastructure domain ARPA, and, arguably, the specialized
US
Government TLDs MIL and GOV. There have been proposals from
time to
time for other international TLDs of this variety, e.g.,
for medical entities
such as physicians and hospitals and for
museums.
(iii) Country domains, operated
according to the original
underlying assumptions of 1591, i.e., registrants are
largely
expected to be people or other entities within the country.
While external
registrations might be accepted by some of these,
the country does not aggressively
advertise for such
registrations, nor does anyone expect to derive significant
fee
revenue from them. All current domains in this category are
ccTLDs,
but not all ccTLDs are in this category.
These categories are clearly orthogonal
to the association
between the use of the IS 3166-1 registered code list and
two-letter
"country" domain names . If that relationship is to
be maintained (and I
believe it is desirable), the only inherent
requirement is that no two-letter
TLDs be created except from
that list (in order to avoid future conflicts).
ICANN should
control the allocation and delegation of TLDs using these, and
other,
criteria, but only registered 3166-1 two letter codes
should be used as two-letter
TLDs.
2. Implications of the Categories
If we adopt this type of three-way
categorization and can make
it work, I believe it prevents several opportunities
for ICANN
and the community more generally to reduce controversiesand move
forward.
Of course, there will be cases where the categorization
of a particular domain
and its operating style will not be
completely clear-cut (see section 3, below).
But having ICANN
work out procedures for dealing with those (probably few)
situations
appears preferable to strategies that would tend to
propel ICANN into areas that
are beyond its competence or that
might require significant expansion of its mandate.
First,
the internally-operated ccTLDs (category iii above)
should not be required to
have much interaction with ICANN or
vice versa. Once a domain of this sort
is established and
delegated, and assuming that the "admin contact in the country"
rule
is strictly observed, the domain should be able to function
effectively without
ICANN intervention or oversight. In
particular, while a country might choose to
adopt the general
ICANN policies about dispute resolution or name management,
issues
that arise in these areas might equally well be dealt
with exclusively under applicable
national laws. If a domain
chooses to use ICANN services that cost resources
to provide, it
should contribute to ICANN's support, but, if it does not, ICANN
should
not presume to charge it for other than a reasonable
fraction of the costs to
ICANN of operating the root, root
servers, and any directory systems that are
generally agreed
upon to be necessary and in which the domain participates
By
contrast, ccTLDs operated as generic domains ought to be
treated as generic domains.
ICANN dispute resolution and name
management policies and any special rules developed
to protect
the Internet public in multiple registrar or registry situations
should
reasonably apply.
3. Telling TLD types apart
If appropriate policies
are adopted, ccTLDs operated as generic
domains (category (i) above) and those
operated as country
domains (category (iii) above) ought to be able to be
self-identified.
There are several criteria that could be
applied to make this determination. For
example, a domain is
aggressively seeking outside registrations or it is not and
either
the vast majority of registrants in a domain are
in-country or they are not. One
could also think of this as the
issue of having some tangible level of presence
in the
jurisdiction - e.g., is the administrative contact subject, in
practical
terms, to the in-country laws, or are the registration
rules such that it is reasonably
likely that a court in the
jurisdiction of the country associated with the domain
can
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 they intend to use. E.g.,
registrants in a
domain that will use the laws of one particular country to
resolve
disputes should have a reasonable opportunity to
determine that prior to registration
and to make other
arrangements (e.g., to register elsewhere) if that mechanism
for
dispute resolution is not acceptable. Giving IANA (as the root
registrar)
incorrect information about the purpose and use of a
domain should be subject
to challenge, and should be grounds for
reviewing the appropriateness of the domain
delegation, just as
not acting consistently and equitably provides such grounds
under
the original provisions of RFC 1591.
In order to ensure the availability of accurate
and up-to-date
registration information the criteria must be consistent, and
consistent
with more traditional gTLDs, for all nominally
country code domains operating
as generic TLDs.
4. The role of ICANN in country domains
ICANN (and IANA)
should, as described above, have as little
involvement as possible in the direction
of true country [code]
domains (i.e., category (iii)). There is no particular
reason
why these domains should be subject to ICANN regulation beyond
the basic
principles of 1591 and associated arrangements needed
to ensure Internet interoperability
and stability.ICANN's
avoiding such involvement strengthens it: the desirability
of
avoiding collisions with national sovereignty , determinations
about government
legitimacy, and the authority of someone
proportedly writing on behalf of a government,
is as important
today as it was when 1591 was written. The alternatives
take us
quickly from "administration" into "internet governance" or, in
the
case of determining which claimant is the legitimate
government of a country,
"international relations", and the
reasons for not moving in that particular direction
are legion.
5. The role of governments
The history of IANA strategy in handling
ccTLDs included three
major "things to avoid" considerations:
* Never get involved
in determining which entities were
countries and which ones were not.
* Never
get involved in determining who was, or was not, the
legitimate government of
a country. And, more generally, avoid
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 work
problems out among themselves. At most, adopt a
role as
mediator and educator, rather than judge, unless abuses are very
clear
and clearly will not be settled by any internal mechanism.
All three were obviously
intended to avoid IANA's being dragged
into a political morass in which it had
(and, I suggest, has) no
competence to resolve the issues and could only get bogged
down.
The first consideration was the most visible (and the easiest)
and was
implemented by strict adherence to the ISO 3166
registered Country Code list.
If an entity had a code, it was
eligible to be registered with a TLD (although
IANA was free to
apply other criteria-most of them stated in 1591). If it
did
not, there were no exceptions: the applicant's only recourse was
a discussion
with the 3166 Registration Authority (now
Maintenance Agency) or the UN Statistical
Office (now Statistics
Bureau), not with IANA.
The other two considerations
were more subtle and not always
successful: from time to time, both before and
after the formal
policy shifted toward "governments could have their way", IANA
received
letters from people proporting to be competent
government authorities asking for
changes. Some of them turned
out later to not have that authority or qualifications.
The
assumption of 1591 itself was that, if the "administrative
contact in country"
rule was strictly observed, as was the rule
that delegation changes requested
by the administrative contact
would be honored, then, if a government _really_
wanted to
assert itself, it could pressure the administrative contact into
requesting
the changes it wanted, using whatever would pass for
due process in that country.
And the ability to apply that
process and pressure would effectively determine
who was the
government and who wasn't, and would do so far more effectively
than
any IANA evaluation of, e.g., whether the letterhead on a
request looked authentic.
Specific language in 1591 permitted
IANA to adopt a "work it our yourselves; if
we have to decide,
we will strive for a solution that is not satisfactory to any
party"
stance and that approach was used successfully, along
with large doses of education,
on many occasions over the years,
to avoid IANA's having to assume the role of
judge 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 ccTLD either as a national
service or as a profit
center where the "customers" were largely external.
Whatever
decisions were made historically, general Internet stability
argues
that changes should not be made lightly. At the same
time, if a government
wishes to make a change, the best
mechanism for doing so is not to involve ICANN
in a potential
determination of legitimacy (or even to have the GAC try to
formally
make that decision for individual countries) but for
the relevant government to
use its own procedures to persuade
the administrative contact to request the change.
6.
Implications for the current DNSO structure.
The arguments by some of the ccTLD
administrators that they are
different from the rest of the ICANN and DNSO structures
are (in
this model) correct: they are different. The ccTLDs that are
operating
as generic TLDs should be separated from the ccTLD
constituency and joined to
the gTLD constituency (which could
use a few more members). The country
ccTLDs should be separated
from ICANN's immediate Supporting Organization structure,
and
operate in a parallel and advisory capacity to ICANN, similar to
the arrangements
used with the GAC.: The DNSO and country TLDs
should not be required to interact
with each other except on a
mutually voluntary basis and, if ICANN needs interaction
or
advice from some of all of those TLDs, it would be more
appropriate to get
it in the form of an advisory body like the
GAC rather than as DNSO constituency.
Acknowledgements
and disclaimer
These reflections have been prepared in my individual capacity
and
do not necessarily reflect the views of my past or present
employer. Several
people, including Randy Bush, Theresa
Swinehart, Zita Wenzel and several anonymous
reviewers, made
suggestions about earlier versions of this document. Those
comments
contributed significantly to whatever clarity the
document has, but the author
bears responsibility for the
selection of comments which were ujltimately incorporated
and
the way in which the conclusions were presented.