diff options
Diffstat (limited to 'doc/rfc/rfc3071.txt')
| -rw-r--r-- | doc/rfc/rfc3071.txt | 563 |
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] + |