mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-03 16:15:27 +00:00
Code Issues Releases Wiki Activity

Another draft from the IAB chair about domain names. It is more

Browse Source 
ICANN relevant than IETF relevant -- not a technical standard -- but
would be good for many domain administrators to read.
This commit is contained in:
David Lawrence
2000-12-12 18:34:30 +00:00
parent bf00f50cf4
commit c0d3ee33c4
1 changed files with 393 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

393
doc/draft/draft-klensin-1591-reflections-01.txt Normal file
View File

@@ -0,0 +1,393 @@
INTERNET-DRAFT John C. Klensin
Expires May 2001
November 10, 2000
Reflections on the DNS, RFC 1591, and Categories of Domains
draft-klensin-1591-reflections-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 except that the
right to produce derivative works is not granted.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is purely informational, for comment, and to stimulate
other discussions: it is not expected to be, or evolve into, a
standard of any form.
0. Abstract
RFC 1591, "Domain Name System Structure and Delegation" [1] 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 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. This memo includes some thoughts about how 1591
might be interpreted and adjusted by the 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 TLD policies.
1. Introduction
RFC1591 has been heavily discussed and referenced in recent months,
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 five or six 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 we should
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 can 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 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, 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). 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. Some of these proposals are in front of ICANN as this
document is being written; ICANN describes them as "sponsored"
TLDs.
(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 adopt this type of three-way categorization and can make it
work, I believe it presents 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.
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
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 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 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, often
known just as "3166/MA") or the UN Statistical Office (now Statistics
Bureau), not with IANA.
This, obviously, is also the argument against use of the "reserved"
list, at least without explicit agreement with 3166/MA: 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.
Proported 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, 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 proporting to be competent government
authorities asking for changes. Some of them turned out later to not
have that authority or those 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).
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. 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.
7. References
[1] Postel, Jon. Domain Name System Structure and Delegation,
RFC 1591. USC Information Sciences Institute: March 1994.
[2] ISO 3166. Codes for the identification of names of countries (??)
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
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 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
klensin@jck.com