Network Working Group J. Klensin

Request for Comments: 3071 February 2001

Category: Informational

Reflections on the DNS, RFC 1591, and Categories of Domains

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

RFC 1591, "Domain Name System Structure and Delegation", laid out the

basic administrative design and principles for the allocation and

administration of domains, from the top level down. It was written

before the introduction of the world wide web (WWW) and rapid growth

of the Internet put significant market, social, and political

pressure on domain name allocations. In recent years, 1591 has been

cited by all sides in various debates, and attempts have been made by

various bodies to update it or adjust its provisions, sometimes under

pressures that have arguably produced policies that are less well

thought out than the original. Some of those efforts have begun from

misconceptions about the provisions of 1591 or the motivation for

those provisions. The current directions of the Internet Corporation

for Assigned Names and Numbers (ICANN) and other groups who now

determine the Domain Name System (DNS) policy directions appear to be

drifting away from the policies and philosophy of 1591. This

document is being published primarily for historical context and

comparative purposes, essentially to document some thoughts about how

1591 might have been interpreted and adjusted by the Internet

Assigned Numbers Authority (IANA) and ICANN to better reflect today's

world while retaining characteristics and policies that have proven

to be effective in supporting Internet growth and stability. An

earlier variation of this memo was submitted to ICANN as a comment on

its evolving Top-level Domain (TLD) policies.

Klensin Informational [Page 1]



RFC 3071 Reflections on the DNS and RFC 1591 February 2001

1. Introduction

RFC 1591 [1] has been heavily discussed and referenced in the last

year or two, especially in discussions within ICANN and its

predecessors about the creation, delegation, and management of top-

level domains. In particular, the ICANN Domain Name Supporting

Organization (DNSO), and especially its ccTLD constituency, have been

the home of many discussions in which 1591 and interpretations of it

have been cited in support of a variety of sometimes-contradictory

positions. During that period, other discussions have gone on to try

to reconstruct the thinking that went into RFC 1591. Those in turn

have led me and others to muse on how that original thinking might

relate to some of the issues being raised. 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.

RFC 1591 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 seven or eight years since 1591 was written. In

particular, the Internet has become more heavily used and, because

the design of the world wide 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 physical hosts has increased very significantly.

The issues 1591 attempted to address when it was written and those we

face today have not changed significantly in principle. But one

alternative to present trends would be to take a step back to refine

it into a model that can 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 could continue to be

applied: not because it is historically significant, but because many

of its elements have 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 imply being carried out

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-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

yregistrations.

In particular, 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. These

decisions and others have produced protests from many sides,

suggesting, in turn, that a recategorization is in order. For

example, we have heard concerns by governments and managers of

traditional, "public service", in-country, ccTLDs about excessive

ICANN interference and fears of being forced to conform to

internationally-set policies for dispute resolution when their

domestic ones are considered more appropriate. 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.

ICANN has recently approved several TLDs of this type and

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 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 [2] 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 had adopted this type of three-way categorization and could

make it work, I believe it would have presented several opportunities

for ICANN and the community more generally to reduce controversies

and 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.

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 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, either 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 understand those policies 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

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 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 purportedly

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 considerations 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 and careful adherence (see

below) 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 additional 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, often known just as "3166/MA") or the UN

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 this

purpose. The others --Ascension Island, Guernsey, Isle of Man, and

Jersey --are arguably, at least in retrospect, just mistakes.

Regardless of the historical reasons (about which there has been much

speculation), it is almost certainly the case that the right way to

handle mistakes of this sort is to acknowledge them and move on,

rather than trying to use them as precedents to justify more

mistakes.

This, obviously, is also the argument against use of the "reserved"

list (technically internal to the 3166 maintenance activity, and not

part of the Standard): since IANA (or ICANN) can ask that a name be

placed on that list, there is no rule of an absolute determination by

an external organization. Purported countries can come to ICANN,

insist on having delegations made and persuade ICANN to ask that the

names be reserved. Then, since the reserved name would exist, they

could insist that the domain be delegated. Worse, someone could use

another organization to request reservation of the name by 3166/MA;

once it was reserved, ICANN might be hard-pressed not to do the

delegation. Of course, ICANN could (and probably would be forced to)

adopt additional criteria other than appearance on the "reserved

list" in order to delegate such domains. But those criteria would

almost certainly be nearly equivalent to determining which applicants

were legitimate and stable enough to be considered a country, the

exact decision process that 1591 strove to avoid.

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 purporting to be competent government

authorities asking for changes. Some of them turned out later to not

have that authority or appropriate 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 (and far more safely for ICANN than

asking the opinion of any particular other government or selection of

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 out

yourselves; if we have to decide, we will strive for a solution that

is not satisfactory to any party" stance. 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

ICANN's Government Advisory Committee (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 and for IANA to promptly and efficiently carry out

requests made by administrative contacts.

6. Implications for the current ICANN 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. 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.

7. References

[1] Postel, J., "Domain Name System Structure and Delegation", RFC

1591, March 1994.

[2] ISO 3166. ISO 3166-1. Codes for the representation of names of

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 disclaimer

These reflections have been prepared in my individual capacity and do

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, made

suggestions or offered editorial comments about earlier versions of

this document. Cord Wischhoefer, of the ISO 3166/MA, was also kind

enough to look at the draft and supplied some useful details. Those

comments contributed significantly to whatever clarity the document

has, but the author bears responsibility for the selection of

comments which were ultimately incorporated and the way in which the

conclusions were presented.

9. Security Considerations

This memo addresses the context for a set of administrative decisions

and procedures, and does not raise or address security issues.

10. Author's Address

John C. Klensin

1770 Massachusetts Ave, Suite 322

Cambridge, MA 02140, USA

EMail: klensin@jck.com

Klensin Informational [Page 9]



RFC 3071 Reflections on the DNS and RFC 1591 February 2001

11. Full Copyright Statement

Copyright (C) The Internet Society 2001. All Rights Reserved.

This document and translations of it may be copied and furnished to

others provided that the above copyright notice and this paragraph

are included on all such copies. However, this document itself may

not be modified in any way, such as by removing the copyright notice

or references to the Internet Society or other Internet

organizations, except as required to translate it into languages

other than English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the

Internet Society.

Klensin Informational [Page 10]