Network Working Group J. Klensin
Request for Comments: 3071 February 2001
Category: Informational
Network Working Group J. Klensin
Request for Comments: 3071 February 2001
Category: Informational
Reflections on the DNS, RFC 1591, and Categories of Domains
关于DNS、RFC 1591和域类别的思考
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.
版权所有（C）互联网协会（2001年）。版权所有。
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.
RFC 1591“域名系统结构和授权”从顶层到下层阐述了基本的管理设计和域分配与管理原则。它是在万维网（WWW）引入和互联网的快速发展给域名分配带来巨大的市场、社会和政治压力之前编写的。近年来，各方在各种辩论中都引用了1591，各机构也试图更新或调整其条款，有时在压力下，可以说产生了不如原来深思熟虑的政策。其中一些努力是从对1591年的规定或这些规定的动机的误解开始的。互联网名称和数字分配公司（ICANN）和其他决定域名系统（DNS）政策方向的团体目前的方向似乎偏离了1591年的政策和理念。本文件的出版主要是为了历史背景和比较目的，主要是为了记录关于互联网分配号码管理局（IANA）如何解释和调整1591的一些想法以及ICANN，以更好地反映当今世界，同时保留已证明在支持互联网增长和稳定方面有效的特征和政策。本备忘录的早期版本已提交给ICANN，作为对其不断发展的顶级域名（TLD）政策的评论。
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[1]在过去一两年中得到了大量讨论和引用，尤其是在ICANN及其前身关于顶级域名的创建、授权和管理的讨论中。特别是，ICANN域名支持组织（DNSO），特别是其ccTLD选区，一直是许多讨论的中心，其中引用了1591及其解释，以支持各种有时相互矛盾的立场。在此期间，其他讨论继续进行，试图重建进入RFC1591的思想。这些反过来又让我和其他人思考，最初的想法可能与正在提出的一些问题有何关联。1591年，我相信，是乔恩·波斯特尔的杰作之一，它将非常不同的哲学（例如，他的传统观点，即人们基本上是理性的，如果在模型不成功的情况下，通过一些更强大的机制告诉人们，他们会做正确的事情）整合成一个整体。
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.
RFC 1591是在这样一种假设的背景下编写的，即它所描述的通用TLD将受注册政策和类别的约束（参见第2节中的“此域旨在…”文本），而CCTLD预计主要用于支持一个国家及其居民内的用户和使用。不同领域将以不同方式运行的概念——尽管是在“代表互联网社区的公共服务”和“全球互联网社区的受托人”的大背景下——被认为是一种设计特征和防止各种潜在滥用的保障。显然，自1591年出版以来的七八年间，世界在许多方面发生了变化。特别是，互联网的使用越来越广泛，由于万维网的设计将域名摆在用户面前，顶级域名和域名注册的需求量也越来越大：在这段时间里，不仅主机数量急剧增加，但是注册域名和物理主机之间的比例已经显著增加。
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
1591年在撰写时试图解决的问题以及我们今天面临的问题在原则上没有发生重大变化。但替代当前趋势的另一种方法是后退一步，将其细化为一个今天能够有效运作的模型。因此，尝试重建1591的原则，并将其作为一个可以继续应用的模型考虑其今天的适用性可能是有用的：这不是因为它具有历史意义，而是因为它的许多要素已经被证明相当有效，即使在困难的情况下也是如此。特别是，对于许多领域（一些在1591年的“通用”列表中，另一些在其“国家代码”类别中），“公共服务”的概念——预计将意味着正在执行
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.
不仅在非盈利的基础上，用户不承担任何或最低的成本，而是屈服于盈利能力的计算。而且，在其他大多数国家，至少计算和收回成本的考虑已经悄然出现。虽然我们中的许多人都对旧系统怀旧，但很明显，它的时代即使没有逝去，也在逐渐消逝：也许1591年出版时人们所理解的公共服务理念无法适应互联网的快速增长和大量的注册。
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:
特别是，一些国家缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约方公约缔约。这些决定和其他决定引起了许多方面的抗议，进而表明重新分类势在必行。例如，我们听到了国家政府和传统“公共服务”的管理者对国家、国家和地区顶级域名的担忧，他们担心ICANN过度干预，担心在国内政策被认为更合适时，被迫遵守国际制定的争端解决政策。我们还听到外部销售的CCTLD的注册商和运营商对政府不合理干预的担忧，以及gTLD注册商和注册商对积极销售的CCTLD的不合理竞争的担忧。适当的区别不再是RFC 1591所描述的“通用”TLD（但其真正的目的是“特定用途”，我将在下面再次使用该术语）和CCTLD之间的区别，而是：
(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.
(i) 真正的“通用”TLD，其中任何注册都是可接受的，并且通常积极促进来自所有来源的注册。该列表目前包括（以前的特定用途）COM、NET和ORG以及一些CCTLD。不时有人提议增加此类TLD，与COM（以及最近的NET和ORG）一样，任何人（通常只受名称冲突和国家法律的约束）都可以注册谁可以支付费用。
(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.
（ii）特定目的的TLD，其中仅接受符合特定资格的组织或个人的注册，但这些资格不受国界限制。该列表目前包括INT、EDU、基础设施领域ARPA，以及（可以说）专业的美国政府TLD MIL和GOV。不时会有关于此类其他国际TLD的提案，例如，针对医生和医院等医疗实体以及博物馆的提案。ICANN最近批准了几种此类TLD，并将其描述为“赞助”TLD。
(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.
（iii）根据1591年的原始基本假设运营的国家域，即注册人主要预期为该国境内的个人或其他实体。虽然其中一些公司可能会接受外部注册，但该国不会积极宣传此类注册，也不会有人期望从中获得可观的费用收入。此类别中的所有当前域都是CCTLD，但并非所有CCTLD都属于此类别。
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.
这些类别显然与IS 3166-1注册代码列表[2]的使用和两个字母的“国家”域名之间的关联正交。如果要保持这种关系（我认为这是可取的），唯一的内在要求是，除该列表外，不得创建两个字母的TLD（以避免未来冲突）。ICANN应使用这些标准和其他标准控制TLD的分配和授权，但只有注册的3166-1双字母代码应用作双字母TLD。
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.
如果我们采用了这种三向分类法，并能使其发挥作用，我相信这将为ICANN和社区提供一些机会，以减少争议并向前迈进。当然，在某些情况下，某一特定领域的分类及其运作方式并不完全明确（见下文第3节）。但是，让ICANN制定处理这些（可能很少）情况的程序似乎比那些倾向于推动ICANN进入超出其权限或可能需要大幅扩大其授权范围的领域的战略更可取。
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.
首先，内部运营的CCTLD（上述第三类）不需要与ICANN进行大量互动，反之亦然。一旦建立并授权了此类域名，并且假设严格遵守了“该国的管理员联系人”规则，则该域名应能够在没有ICANN干预或监督的情况下有效运行。特别是，虽然一个国家可能会选择采用ICANN关于争议解决或名称管理的一般政策，但在这些领域出现的问题也可能完全按照适用的国家法律处理。如果域名选择使用耗费资源提供的ICANN服务，则应向ICANN提供支持，但如果域名选择使用ICANN服务，则ICANN不应假定向其收取ICANN运营根、根服务器成本的合理部分以外的费用，以及通常认为必要且域参与的任何目录系统。
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.
相比之下，作为通用域运行的CCTLD应被视为通用域。ICANN争议解决和名称管理政策以及为在多个注册机构或注册机构情况下保护互联网公众而制定的任何特殊规则应合理适用。
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.
如果采取适当的政策，作为通用域（上文第（i）类）运营的国家/地区域名（上文第（iii）类）运营的国家/地区域名应能够自我识别。有几个标准可用于作出这一决定。例如，要么一个域正在积极寻求外部注册，要么不是，要么一个域中的绝大多数注册人在该国，要么不是。人们还可以将这一点视为在管辖区内存在某种有形程度的问题，例如，从实际意义上讲，行政联系是否受制于国内法，或者，注册规则使得与域名相关的国家的管辖权内的法院有合理的可能对注册人行使管辖权并执行判决。
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.
ICANN可能会对所有顶级域名施加一条（相当非侵入性）规则，即它们识别并发布它们打算使用的策略。例如，如果某一领域的注册人将使用某一特定国家的法律来解决争端，则该领域的注册人应在注册前有合理的机会了解这些政策，并在该争端解决机制不可接受的情况下作出其他安排（例如，在其他地方注册）。向IANA（作为根注册机构）提供有关域的用途和使用的不正确信息应受到质疑，并应成为审查域授权适当性的理由，正如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.
为了确保准确和最新的注册信息的可用性，对于作为通用TLD运行的所有名义上的国家代码域，标准必须一致，并与更传统的GTLD一致。
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
如上所述，ICANN（和IANA）应尽可能少地参与真正的国家[代码]领域（即第（iii）类）。没有特别的原因
these domains should be subject to ICANN regulation beyond the basic principles of 1591 and associated arrangements needed to ensure Internet interoperability and stability.
除了1591的基本原则和确保互联网互操作性和稳定性所需的相关安排外，这些域还应遵守ICANN法规。
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.
ICANN避免此类介入强化了这一点：避免与国家主权、政府合法性的决定以及据称代表政府写作的人的权威发生冲突的可取性，在今天和1591年写作时一样重要。替代方案很快将我们从“行政管理”带到“互联网治理”，或者，在确定哪一个索赔人是一个国家的合法政府的情况下，带到“国际关系”，而不朝着这一特定方向发展的原因是多方面的。
The history of IANA strategy in handling ccTLDs included three major "things to avoid" considerations:
IANA处理CCTLD的策略历史包括三个主要的“避免事项”：
* 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.
这三个考虑因素显然都是为了避免IANA陷入政治泥潭，在这种泥潭中，IANA（我认为，IANA）没有能力解决这些问题，只能陷入困境。第一个考虑因素是最明显的（也是最容易的），通过严格和仔细地遵守ISO 3166注册国家代码清单（见下文）来实施。如果实体有代码，则有资格向TLD注册（尽管IANA可自由应用附加标准，其中大多数标准在1591年规定）。如果没有，也没有例外：申请人唯一的求助途径是与3166注册机构（现在的维护机构，通常称为“3166/MA”）或联合国统计局（现在的统计局）讨论，而不是与IANA讨论。
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.
严格的规则实际上有五个ccTLD例外。其中一个“UK”是历史性的：它早于为此目的采用ISO 3166。其他岛屿——阿森松岛、根西岛、马恩岛和泽西岛——可以说，至少现在回想起来，都是错误。不管历史原因如何（对此有很多猜测），几乎可以肯定的是，处理这类错误的正确方法是承认错误并继续前进，而不是试图用它们作为先例来证明更多错误的合理性。
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.
显然，这也是反对使用“保留”列表的理由（技术上是3166维护活动的内部，而不是标准的一部分）：由于IANA（或ICANN）可以要求将名称放在该列表上，因此没有外部组织绝对确定的规则。所谓的国家可以来ICANN，坚持让代表团参加，并说服ICANN要求保留这些名称。然后，由于保留名称将存在，他们可以坚持将该域委派。更糟糕的是，有人可能会利用另一个组织请求在3166/MA之前保留该名称；一旦它被保留，ICANN可能很难不进行授权。当然，ICANN可以（也可能被迫）采用“保留名单”之外的其他标准来授权这些域名。但这些标准几乎肯定相当于确定哪些申请人是合法和稳定的，足以被视为一个国家，这正是1591年极力避免的决策过程。
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).
另外两个考虑因素更为微妙，并不总是成功：在正式政策转向“政府可以随心所欲”之前和之后，IANA不时收到声称是主管政府当局的人的来信，要求做出改变。他们中的一些人后来证明没有这种权威或适当的资格。1591年的假设是，如果严格遵守“国内行政联系”规则，以及遵守行政联系要求的授权变更的规则，那么，如果一个政府真的想要维护自己，它可以迫使行政联系要求它想要的变更，在那个国家使用任何被认为是正当程序的东西。运用这一过程和压力的能力将有效地决定谁是政府，谁不是政府，并且比IANA对请求信头是否真实的评估更有效（对ICANN来说，这比征求任何特定政府或政府选择的意见要安全得多）。
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.
1591年的具体语言允许IANA采取“自己解决问题；如果我们必须做出决定，我们将努力寻求一个任何一方都不满意的解决方案”的立场。多年来，这一方法与大量教育一起被成功地使用，以避免IANA不得不在冲突各方之间担任法官的角色。
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.
类似的原则可适用于基于国家代码的通用TLD和国家域之间的边界。在不同的情况下，不同的国家可能更愿意将ccTLD作为国家服务或利润中心运营，而“客户”主要来自外部。无论历史上做出了什么样的决定，互联网总体稳定性都认为不应轻易做出改变。同时，如果政府希望做出改变，那么最好的机制是不让ICANN参与潜在的合法性决定（甚至不让ICANN的政府咨询委员会（GAC）为个别国家正式做出决定）但相关政府应使用自己的程序说服行政联系人请求变更，IANA应及时有效地执行行政联系人提出的请求。
6. Implications for the current ICANN DNSO structure.
6. 对当前ICANN DNSO结构的影响。
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.
一些ccTLD管理员认为它们与ICANN和DNSO结构的其他部分不同的论点（在此模型中）是正确的：它们是不同的。作为通用TLD运行的ccTLD应与ccTLD选区分离，并加入gTLD选区。国家CCTLD应与ICANN的直接支持组织结构分离，并以与ICANN平行的咨询能力运作，类似于与GAC使用的安排。DNSO和国家TLD不应被要求在相互自愿的基础上进行互动，如果ICANN需要所有这些TLD中的一些人的互动或建议，则以GAC等咨询机构的形式而不是DNSO选区的形式进行互动更为合适。
[1] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[1] Postel，J.，“域名系统结构和授权”，RFC15911994年3月。
[2] ISO 3166. ISO 3166-1. Codes for the representation of names of countries and their subdivisions - Part 1: Country codes (1997).
[2] ISO 3166。ISO 3166-1。国家及其分支机构名称表示代码.第1部分：国家代码（1997）。
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.
这些反思是以我个人的身份准备的，不一定反映我过去或现在雇主的观点。一些人，包括兰迪·布什、特里萨·斯温哈特、齐塔·温泽尔、杰夫·休斯顿、哈瓦德·艾恩斯和几位匿名评论员，对本文件的早期版本提出了建议或发表了编辑评论。ISO 3166/MA的Cord Wischhoefer也很友好地查看了草稿，并提供了一些有用的细节。这些评论大大有助于文件的清晰度，但作者有责任选择最终纳入的评论以及结论的提出方式。
This memo addresses the context for a set of administrative decisions and procedures, and does not raise or address security issues.
本备忘录涉及一系列行政决定和程序的背景，不提出或解决安全问题。
John C. Klensin 1770 Massachusetts Ave, Suite 322 Cambridge, MA 02140, USA
美国马萨诸塞州剑桥市马萨诸塞大道1770号322室，邮编02140
EMail: klensin@jck.com
EMail: klensin@jck.com
Copyright (C) The Internet Society 2001. All Rights Reserved.
版权所有（C）互联网协会2001。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。