rfc3071.txt

bind 9.3结合mysql数据库

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]