GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3071

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3071.txt · Last modified: 2001/02/14 20:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki