Movatterモバイル変換

Network Working Group                                         J. KlensinRequest for Comments: 3071                                 February 2001Category: InformationalReflections on the DNS,RFC 1591, and Categories of DomainsStatus 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.AbstractRFC 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 andRFC 1591      February 20011.  IntroductionRFC 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 intoRFC 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 insection 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 outKlensin                      Informational                      [Page 2]

RFC 3071          Reflections on the DNS andRFC 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   whatRFC 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 andRFC 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 (seesection 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 andRFC 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 ofRFC1591.   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 whyKlensin                      Informational                      [Page 5]

RFC 3071          Reflections on the DNS andRFC 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 andRFC 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 andRFC 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",RFC1591, 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 andRFC 1591      February 20018. 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.comKlensin                      Informational                      [Page 9]

RFC 3071          Reflections on the DNS andRFC 1591      February 200111. 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]