INTERNET-DRAFT                                    John C. KlensinDecember 13, 2000Expires June 2000	 Reflections on the DNS, RFC 1591, and Categories of Domains				draft-klensin-1591-reflections-02.txtStatus 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 stimulateother discussions: it is not expected to be, or evolve into, astandard of any form.0. AbstractRFC 1591, "Domain Name System Structure and Delegation" [1] laid outthe basic administrative design and principles for the allocation andadministration of domains, from the top level down.  It was writtenbefore the introduction of the world wide web and rapid growth of theInternet put significant market, social, and political pressure ondomain name allocations.  In recent years, 1591 has been cited by allsides in various debates, and attempts have been made by variousbodies to update it or adjust its provisions, sometimes underpressures that have arguably produced policies that are less wellthought out than the original.  Some of those efforts have begun frommisconceptions about the provisions of 1591 or the motivation forthose provisions.  The current directions of ICANN and other groupswho now determine DNS policy directions appear to be drifting awayfrom policies and philosophy of 1591.  This document is beingpublished primarily for historical context and comparative purposes,essentially to document some thoughts about how 1591 might have beeninterpreted and adjusted by the IANA and ICANN to better reflecttoday's world while retaining characteristics and policies that haveproven to be effective in supporting Internet growth and stability.An earlier variation of this memo was submitted to ICANN as a commenton its evolving TLD policies.1.  IntroductionRFC1591 has been heavily discussed and referenced in the last year ortwo, especially in discussions within ICANN and its predecessorsabout 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 manydiscussions in which 1591 and interpretations of it have been citedin support of a variety of sometimes-contradictory positions.  Duringthat period, other discussions have gone on to try to reconstruct thethinking that went into RFC 1591.  Those in turn have led me andothers to muse on how that original thinking might relate to some ofthe issues being raised.  1591 is, I believe, one of Jon Postel'smasterpieces, drawing together very different philosophies (e.g., histraditional view that people are basically reasonable and will do theright thing if told what it is with some stronger mechanisms whenthat model is not successful) into a single whole.RFC 1591 was written in the context of the assumption that what itdescribed as generic TLDs would be bound to policies and categoriesof registration (see the "This domain is intended..."  text insection 2) while ccTLDs were expected to be used primarily to supportusers and uses within and for a country and its residents.  Thenotion that different domains would be run in different ways --albeitwithin the broad contexts of "public service on behalf of theInternet community" and "trustee... for the global Internetcommunity"-- was considered a design feature and a safeguard againsta variety of potential abuses.  Obviously the world has changed inmany ways in the six or seven years since 1591 was written.  Inparticular, the Internet has become more heavily used and, becausethe design of the world wide web has put domain names in front ofusers, top-level domain names and registrations in them have beenheavily in demand: not only has the number of hosts increaseddramatically during that time, but the ratio between registereddomain names and physical hosts has increased very significantly.The issues 1591 attempted to address when it was written and those weface today have not changed significantly in principle. But onealternative to present trends would be to take a step back to refineit into a model that can function effectively today.  Therefore, itmay be useful to try to reconstruct 1591's principles and think abouttheir applicability today as a model that could continue to beapplied: not because it is historically significant, but because manyof its elements have proven to work reasonably well, even indifficult situations.  In particular, for many domains (some in1591's "generic" list and others in its "country code" category) thenotion of "public service" --expected then to imply being carried outat no or minimal cost to the users, not merely on a non-profitbasis-- has yielded to profitability calculations.  And, in most ofthe rest, considerations of at least calculating and recovering costshave crept in.  While many of us feel some nostalgia for the oldsystem, it is clear that its days are waning if not gone: perhaps thepublic service notions as understood when 1591 was written just don'tscale to rapid internet growth and very large numbers ofregistrations.In particular, some ccTLDs have advertised for registrations outsidethe designated countries (or other entities), while others have madeclear decisions to allow registrations by non-nationals.  Thesedecisions and others have produced protests from many sides,suggesting, in turn, that a recategorization is in order. Forexample, we have heard concerns by governments and managers oftraditional, "public service", in-country, ccTLDs about excessiveICANN interference and fears of being forced to conform tointernationally-set policies for dispute resolution when theirdomestic ones are considered more appropriate.  We have also heardconcerns from registrars and operators of externally-marketed ccTLDsabout unreasonable government interference and from gTLD registrarsand registries about unreasonable competition from aggressivelymarketed ccTLDs. The appropriate distinction is no longer betweenwhat RFC 1591 described as "generic" TLDs (but which were reallyintended to be "purpose-specific", a term I will use again below) andccTLDs 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.   (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 betweenthe 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 isthat no two-letter TLDs be created except from that list (in order toavoid future conflicts).  ICANN should control the allocation anddelegation of TLDs using these, and other, criteria, but onlyregistered 3166-1 two letter codes should be used as two-letter TLDs.2. Implications of the CategoriesIf we had adopted this type of three-way categorization and couldmake it work, I believe it would have presented several opportunitiesfor ICANN and the community more generally to reduce controversiesand move forward. Of course, there will be cases where thecategorization of a particular domain and its operating style willnot be completely clear-cut (see section 3, below).  But having ICANNwork out procedures for dealing with those (probably few) situationsappears preferable to strategies that would tend to propel ICANN intoareas that are beyond its competence or that might requiresignificant expansion of its mandate.First, the internally-operated ccTLDs (category iii above) should notbe required to have much interaction with ICANN or vice versa.  Oncea domain of this sort is established and delegated, and assuming thatthe "admin contact in the country" rule is strictly observed, thedomain should be able to function effectively without ICANNintervention or oversight. In particular, while a country mightchoose to adopt the general ICANN policies about dispute resolutionor name management, issues that arise in these areas might equallywell be dealt with exclusively under applicable national laws.  If adomain chooses to use ICANN services that cost resources to provide,it should contribute to ICANN's support, but, if it does not, ICANNshould not presume to charge it for other than a reasonable fractionof the costs to ICANN of operating the root, root servers, and anydirectory systems that are generally agreed upon to be necessary and