diff --git a/doc/draft/draft-klensin-1591-reflections-01.txt b/doc/draft/draft-klensin-1591-reflections-01.txt new file mode 100644 index 0000000000..85c98b3055 --- /dev/null +++ b/doc/draft/draft-klensin-1591-reflections-01.txt @@ -0,0 +1,393 @@ +INTERNET-DRAFT John C. Klensin +Expires May 2001 +November 10, 2000 + + Reflections on the DNS, RFC 1591, and Categories of Domains + + draft-klensin-1591-reflections-01.txt + +Status 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 stimulate +other discussions: it is not expected to be, or evolve into, a +standard of any form. + + +0. Abstract + +RFC 1591, "Domain Name System Structure and Delegation" [1] 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 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. This memo includes some thoughts about how 1591 +might be interpreted and adjusted by the 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 TLD policies. + + + +1. Introduction + +RFC1591 has been heavily discussed and referenced in recent months, +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 five or six 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 we should +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 can 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 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 registrations. + +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 (e.g., the UK +or Australia). 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. Some of these proposals are in front of ICANN as this + document is being written; ICANN 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 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 adopt this type of three-way categorization and can make it +work, I believe it presents 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. + +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 +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 proportedly +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 adherence 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 +other 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. +This, obviously, is also the argument against use of the "reserved" +list, at least without explicit agreement with 3166/MA: 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. +Proported 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, 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 proporting to be competent government +authorities asking for changes. Some of them turned out later to not +have that authority or those 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). + +Specific language in 1591 permitted IANA to adopt a "work it our +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 the +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. + + +6. Implications for the current 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 (which could use a few more members). +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, Jon. Domain Name System Structure and Delegation, + RFC 1591. USC Information Sciences Institute: March 1994. + +[2] ISO 3166. Codes for the identification of names of countries (??) + +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 +and several anonymous reviewers, made suggestions about earlier +versions of this document. 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 +klensin@jck.com