[要約] 要約:RFC 3071は、DNS、RFC 1591、およびドメインのカテゴリに関する考察をまとめたものです。 目的:このRFCの目的は、DNSの機能、RFC 1591の役割、およびドメインのカテゴリ分類についての洞察を提供することです。

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.

Copyright(c)The Internet Society(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、「ドメイン名システム構造と委任」は、最上位のレベルからドメインの割り当てと管理の基本的な管理設計と原則を定めました。それは、World Wide Web(www)の導入とインターネットの急速な成長の前に書かれました。近年、1591年はさまざまな議論の中ですべての側面によって引用されており、さまざまな団体によって、それを更新したり、その規定を調整したりする試みがなされてきました。これらの努力のいくつかは、1591年の規定やそれらの規定の動機に関する誤解から始まっています。割り当てられた名前と数字(ICANN)およびドメイン名システム(DNS)のポリシーの指示を決定している他のグループのインターネット企業の現在の指示は、1591のポリシーと哲学から離れているように見えます。この文書は主に公開されています。1591がインターネットに割り当てられた数字の権限(IANA)とICANNによってどのように解釈され調整されたかについてのいくつかの考えを文書化するために、歴史的なコンテキストと比較目的で、インターネットのサポートに効果的であることが証明された特性とポリシーを保持しながら、今日の世界をよりよく反映します成長と安定性。このメモの以前のバリエーションは、進化するトップレベルドメイン(TLD)ポリシーに関するコメントとしてICANNに提出されました。

1. Introduction
1. はじめに

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とその前身での議論、委任、トップレベルドメインの管理についての議論で、昨年か2年で頻繁に議論され、参照されています。特に、ICANNドメイン名サポート組織(DNSO)、特にそのCCTLD選挙区は、1591年とその解釈がさまざまな時々矛盾した立場を支持して引用されている多くの議論の本拠地でした。その期間中、他の議論は、RFC 1591に入った思考を再構築しようとしました。1591は、ジョン・ポステルの傑作の1つであり、非常に異なる哲学を描いていると信じています(例えば、人々は基本的に合理的であり、そのモデルが成功していないときに何らかの強力なメカニズムで何であるかを伝えれば正しいことをするという彼の伝統的な見解)単一の全体に。

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として説明したものが登録のポリシーとカテゴリに拘束されるという仮定の文脈で書かれました(「このドメインは意図されている...」を参照してください。主に、国内およびその住民のためにユーザーと使用をサポートするため。さまざまなドメインがさまざまな方法で実行されるという概念 - 「インターネットコミュニティに代わって公共サービス」と「グローバルなインターネットコミュニティのための受託者」の広範なコンテキスト内で - デザイン機能とさまざまな潜在的な虐待に対する保護。明らかに、1591年が書かれてから7年または8年で世界は多くの点で変化しました。特に、インターネットはより頻繁に使用されており、World Wide Webの設計がユーザーの前にドメイン名を配置したため、トップレベルのドメイン名と登録は需要が高いだけでなく、その間、ホストは劇的に増加しましたが、登録されたドメイン名と物理ホストの比率は非常に大幅に増加しています。

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 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がそれが書かれたときに対処しようとした問題と私たちが今日直面している問題は原則として大幅に変化していません。しかし、現在の傾向を提示するための1つの選択肢は、今日で効果的に機能できるモデルにそれを改良するために一歩後退することです。したがって、1591の原則を再構築し、今日の適用性を適用し続けることができるモデルとしての適用性について考えようとすると便利かもしれません。困難な状況。特に、多くのドメイン(1591年の「ジェネリック」リストの一部、およびその「カントリーコード」カテゴリの他のもの)については、「公共サービス」の概念は、ユーザーではなくユーザーにノーまたは最小限のコストで実行されるか、最小限のコストで実行されることを示唆しています。単に非営利ベースでは、収益性の計算が得られました。そして、残りのほとんどで、少なくとも計算と回復のコストの考慮事項は忍び寄ってきました。私たちの多くは古いシステムに懐かしさを感じていますが、その日がなくなっていないとしても衰退していることは明らかです。1591年が書かれたときに理解されていますが、インターネットの急速な成長と非常に多数のYregistrationに拡大しないでください。

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:

特に、一部のCCTLDは、指定された国(または他のエンティティ)以外の登録を宣伝していますが、他のCCTLDは非国家による登録を許可する明確な決定を下しました。これらの決定や他の決定は、多くの側面から抗議を生み出し、再分類が適切であることを示唆しています。たとえば、私たちは、政府や伝統的な「公共サービス」、国内、CCTLDの政府や管理者が、過度のICANN干渉と、国内の解決のために国際的に設定されたポリシーに適合することを余儀なくされることの恐怖について聞いています。適切な。また、不合理な政府の干渉に関する外部市場のCCTLDのレジストラやオペレーターから、およびGTLDレジストラとレジストリから、積極的に販売されているCCTLDとの不合理な競争についての懸念を聞いています。適切な区別は、RFC 1591が「一般的な」TLD(ただし「目的固有」であることを意図したもの、以下で再び使用する用語)とCCTLDSの間ではなくなりましたが、以下の間ではありません。

(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(および最近では、ネットや組織)と同様に、誰でも(一般的には紛争と国の法律の名前のみ)、料金を支払うことができる人を登録できるという提案が時々ありました。

(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、およびおそらく、特別な米国政府のTLDS 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]と2文字の「国」ドメイン名との間の関連性の明確な直交です。その関係が維持される場合(そして私はそれが望ましいと思う)、唯一の固有の要件は、そのリストから(将来の対立を避けるため)を除いて2文字のTLDが作成されないことです。ICANNは、これらおよびその他の基準を使用してTLDの割り当てと委任を制御する必要がありますが、登録された3166-1の2文字コードのみを2文字のTLDとして使用する必要があります。

2. Implications of the Categories
2. カテゴリの意味

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.

このタイプの3方向分類を採用し、それを機能させることができれば、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(上記のカテゴリIII)は、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の紛争解決と名前管理ポリシー、および複数のレジストラまたはレジストリの状況でインターネットを保護するために開発された特別なルールは、合理的に適用されるはずです。

3. Telling TLD types apart
3. TLDタイプを区別していることを伝えます

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.

適切なポリシーが採用されている場合、CCTLDは一般的なドメイン(上記のカテゴリ(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がすべてのトップレベルドメインに課す可能性のある(かなり侵入しない)ルールの1つは、使用する予定のポリシーを特定して公開することです。たとえば、特定の国の法律を使用して紛争を解決するドメインの登録者は、登録前にそれらのポリシーを理解し、紛争解決のメカニズムがそうではない場合に他の取り決め(例えば、他の場所に登録する)を行う合理的な機会があるはずです許容できる。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と一致する必要があります。

4. The role of ICANN in country domains
4. 国のドメインにおけるICANNの役割

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(およびIANA)は、上記のように、真の国[コード]ドメイン(つまり、カテゴリ(III))の方向にできるだけ関与しない必要があります。これらのドメインが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年が書かれたときと同じくらい重要です。代替案は、「管理」から「インターネットガバナンス」に迅速に取り入れます。または、どの請求者が国の合法的な政府であるか、「国際関係」であるかを決定する場合、その特定の方向に移動しない理由は軍団です。

5. The role of governments
5. 政府の役割

The history of IANA strategy in handling ccTLDs included three major "things to avoid" considerations:

CCTLDSの処理におけるIANA戦略の歴史には、3つの主要な「回避するもの」の考慮事項が含まれていました。

* 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.

3つの考慮事項はすべて、問題を解決する能力がなく、迷惑をかけることしかできなかった(そして、私が提案する)政治的泥沼に引きずり込まれていることを避けることを明らかに意図していました。最初の考慮事項は最も目に見える(そして最も簡単な)であり、ISO 3166登録国コードリストの厳格で慎重なアドヒアランス(以下を参照)によって実装されました。エンティティにコードがある場合、TLDに登録される資格がありました(ただし、IANAは1591年に記載されている追加の基準を自由に適用できましたが)。そうしなかった場合、例外はありませんでした。申請者の唯一の頼みは、3166登録局(現在は「3166/MA」としばしば知られているメンテナンス機関)または国連統計局(現在の統計局)とではなく、議論でした。イアナ。

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.

実際には、厳格なルールには5つのCCTLD例外があります。「英国」の1つは歴史的です。この目的のために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に来ることができ、代表団に名前が予約されるように依頼するように委任し、説得することを主張することができます。その後、予約済みの名前が存在するため、ドメインが委任されることを主張することができます。さらに悪いことに、誰かが別の組織を使用して、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).

他の2つの考慮事項はより微妙であり、常に成功したわけではありませんでした。「政府が道を持つ可能性がある」という正式な政策がシフトする前と後の両方で、イアナは、変更を求める有能な政府当局であると主張する人々から手紙を受け取りました。それらのいくつかは、その権限または適切な資格を持っていないことが後で判明しました。1591自体の仮定は、「国の管理上の連絡先」規則が厳密に観察された場合、行政接触によって要求された代表団の変更が尊重されるというルールが尊重されるということでした。その国の正当なプロセスに合格するものを使用して、必要な変更を要求するように管理上の接触に圧力をかけます。そして、そのプロセスとプレッシャーを適用する能力は、誰が政府であり、誰がそうではなかったかを効果的に決定するでしょう。特定の他の政府の意見や政府の選択をするよりも、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年に特定の言語は、イアナが「自分でそれを解決することを採用することを許可しました。私たちが決定しなければならない場合、私たちはどの政党にとっても満足のない解決策を求めて努力します」。そのアプローチは、イアナが対立する当事者間の裁判官の役割を引き受けなければならないことを避けるために、長年にわたって大量の教育の用量とともに成功裏に使用されました。

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の即時のサポート組織構造から分離され、GACで使用される配置と同様に、ICANNに対して並行したアドバイザリー能力で動作する必要があります。DNSOと国のTLDは、相互に自発的なベースで互いに対話する必要はありません。ICANNがこれらのTLDの一部からのやり取りまたはアドバイスを必要とする場合、アドバイザリーの形でそれを取得する方が適切ですDNSO選挙区としてではなく、GACのような体。

7. References
7. 参考文献

[1] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.

[1] Postel、J。、「ドメイン名システム構造と代表団」、RFC 1591、1994年3月。

[2] ISO 3166. ISO 3166-1. Codes for the representation of names of countries and their subdivisions - Part 1: Country codes (1997).

[2] ISO3166。ISO3166-1。国の名前とその細分化の表現のためのコード - パート1:国コード(1997)。

8. Acknowledgements and disclaimer
8. 謝辞と免責事項

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も、ドラフトを見るのに十分親切で、いくつかの有用な詳細を提供しました。これらのコメントは、文書が持っているどんな明確さに大きく貢献しましたが、著者は、最終的に組み込まれたコメントの選択と結論が提示された方法に責任を負います。

9. Security Considerations
9. セキュリティに関する考慮事項

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
10. 著者の連絡先

John C. Klensin 1770 Massachusetts Ave, Suite 322 Cambridge, MA 02140, USA

ジョンC.クレンシン1770マサチューセッツアベニュー、スイート322ケンブリッジ、マサチューセッツ州02140、米国

   EMail: klensin@jck.com
        
11. 完全な著作権声明

Copyright (C) The Internet Society 2001. All Rights Reserved.

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.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。