doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3071.txt b/doc/rfc/rfc3071.txt
new file mode 100644
index 0000000..2c4d52f
--- /dev/null
+++ b/doc/rfc/rfc3071.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+