RFC3071 日本語訳
3071 Reflections on the DNS, RFC 1591, and Categories of Domains. J.Klensin. February 2001. (Format: TXT=24892 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 3071 February 2001 Category: Informational
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3071 2001年2月のカテゴリ: 情報
Reflections on the DNS, RFC 1591, and Categories of Domains
DNS、RFC1591、およびドメインのカテゴリに関するReflections
Status of this Memo
この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)インターネット協会(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.
「ドメインネームシステム構造と代表団」というRFC1591はドメインの配分と管理のために基本的な管理デザインと原則を広げました、最高平らな下であるのから。 インターネットの世界的なウェブ(WWW)と急速な成長の導入が重要な市場(ドメイン名配分に対する社会的で、政治上の圧力)を置く前にそれは書かれました。 近年、様々な討論における四方で1591を引用しました、そして、様々なボディーでそれをアップデートするか、または条項を調整するのを試みをしました、時々論証上考え抜かれた井戸よりオリジナルである方針を作成した圧力の下で。 それらの努力のいくつかが1591年の条項かそれらの条項に関する動機に関する誤解から始まりました。 現在ドメインネームシステム(DNS)政策の方向性を決定するアイキャン(ICANN)と他のグループの現在の指示は1591年の方針と哲学からゆっくり流れているように見えます。 このドキュメントは、本質的には1591がインターネットの成長と安定性を支持するのにおいて有効であると判明した特性と方針を保有している間、今日の世界をよりよく反映するようにインターネットAssigned民数記Authority(IANA)とICANNによってどう解釈されて、調整されたかもしれないかに関するいくつかの考えを記録するためには主として歴史的背景のために発行されて、比較目的です。 Top-レベルDomain(TLD)方針を発展するコメントとしてこのメモの以前の変化をICANNに提出しました。
Klensin Informational [Page 1] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[1ページ]のRFC3071Reflections
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.
RFC1591[1]は特に最後の年か2年とICANNの中の議論と先端の平らなドメインの創造、代表団、および管理に関するその前任者で大いに議論して、参照をつけられました。 ICANN Domain Name Supporting Organization(DNSO)、および特にそのccTLD選挙民は特に、時々さまざまな矛盾する立場を支持してそれの1591と解釈が引用された多くの議論の家です。 その期間、他の議論は、RFC1591に入った考えを再建しようとし続けています。 ものは、私と他のものがそのオリジナルの考えがどう提起される問題のいくつかに関連するかもしれないかを熟考するように順番に導きました。 私は、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.
主として居住者以内と国とその居住者ようにユーザと用途を支持するのにccTLDsが使用されると予想されましたが、RFC1591はそれが一般的なTLDsを何として記述したかが登録の方針とカテゴリに縛られる(セクション2の「このドメインは意図する」という…テキストを見る)と仮定の文脈に書かれました。 異なったドメインが「インターネットコミュニティを代表した社会奉仕」と「世界的なインターネット共同体の受託者…」の広い文脈の中で異なった道に立候補することであるだろうという概念は設計上の特徴とさまざまな潜在的乱用に対する安全装置であると考えられました。 明らかに、世界が様々な意味で7で変化したか、または1591年以来の8年は書かれました。 特に、インターネットは大いにより使用されるようになりました、そして、世界的なウェブのデザインがユーザの正面にドメイン名を置いたので、それらの最上位のドメイン名と登録証明書はずっしりと需要があります: ホストの数がその時の間、劇的に増加しているだけではなく、登録されたドメイン名と物理ホストの間の比率は非常にかなり増加しました。
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がそれが書かれたとき、記述するのを試みた問題と私たちが今日面しているものは原則としてかなり変化していません。 しかし、現在の傾向への1つの選択肢は今日有効に機能できるモデルにそれを精製するために一歩退くだろうことです。 したがって、適用され続けることができたモデルとして1591年代の原則を再建して、今日彼らの適用性について考えようとするのは役に立つかもしれません: それが歴史的に重要であるのではなく、要素の多くが困難な状況でさえ合理的にうまくいくと判明したので。 (の何らかのコネ1591「ジェネリック」が記載する多くのドメインと他のもののために「国名略号」カテゴリで特定のコネ) 行われながら含意する次に、期待している「社会奉仕」の概念
Klensin Informational [Page 2] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[2ページ]のRFC3071Reflections
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が書かれたとき、恐らく理解されるとしての社会奉仕概念はただ急速なインターネットの成長と多くの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:
特に、いくつかのccTLDsが指定された国(または、他の実体)の外で登録証明書を公募しました、他のものは非同胞による登録証明書を許容するという決定を明らかにしましたが。 再分類が整然としていると順番に示唆して、これらの決定と他のものは多くの側から抗議を起こしました。 それらの国内のものが、より適切であると考えられるとき、例えば、私たちは過度のICANN干渉の周りの国の伝統的な「社会奉仕」ccTLDsの政府とマネージャと方針を国際的に設定するために従わされることへの恐怖で論争の解決に関して関心を聞きました。 また、私たちは無理な競争に関して無理な政府による干渉の周りの外部的に売り出されたccTLDsの記録係とオペレータとgTLD記録係と登録から積極的に売り出されたccTLDsから関心を聞きました。 以下の中で適切な区別はことで間RFC1591が「一般的な」TLDs(どれが「目的特有」私が再び以下で使用するつもりである用語であることを本当に意図した)と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)の本当の「ジェネリック」TLDs。(そこでは、どんな登録も許容できて、通常、すべてのソースからの登録証明書は活発に促進されます)。 このリストは現在、COM、NET、ORG、およびいくつかのccTLDsを含んでいます(以前目的特有)。 中に提案がこのバラエティーの追加TLDsのために時々あった、どれ、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)目的特有のTLDs。(登録は特定の資格を満たす組織か個人だけから受け入れられますが、そこでは、それらの資格は国境に結ばれません)。 提案がこのバラエティーの他の国際的なTLDsのために時々ありました、例えば、医師や病院と博物館への医学の実体のために。このリストは現在、論証上専門化している米国政府のINT、EDU、インフラストラクチャドメインARPA、TLDs MIL、およびGOVを含んでいます。ICANNは最近、このタイプの数個のTLDsを承認して、「後援された」TLDsとして彼らを記述します。
Klensin Informational [Page 3] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[3ページ]のRFC3071Reflections
(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年のオリジナルの基本的な仮定によると、操作されています、すなわち、記入者は国内で人々か他の実体であると主に予想されます。 これらのいくつかで外部の登録証明書を受け入れるかもしれませんが、国は積極的にそのような登録証明書を公募しません、そして、だれもそれらから重要な料金収入を得ると予想しません。 このカテゴリにおけるすべての現在のドメインがccTLDsですが、すべてのccTLDsがこのカテゴリにおいてccTLDsであるというわけではありません。
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.
これらのカテゴリは明確に3166-1が登録されたコードリスト[2]と2文字「国」であるというドメイン名の使用の間の協会と直交しています。 その関係が維持される(私は、それが望ましいと信じています)ことであるなら、唯一の固有の要件はそのリスト以外に、2文字のTLDsが全く作成されないということ(今後の闘争を避けるために)です。 ICANNはこれらを使用することでTLDsの配分と代表団を制御するはずです、そして、3166-1twoの他の、そして、評価基準の、しかし、登録されただけのレター・コードが2文字のTLDsとして使用されるべきです。
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.
まず最初に、内部的に操作されたccTLDs(上のカテゴリiii)はICANNとの多くの相互作用を持つのが必要であるべきではありませんか、逆もまた同様です。 かつて、この種類のドメインを設立して、代表として派遣します、そして、「国でのアドミン接触」規則が厳密に守られると仮定する場合、ドメインはICANN介入も見落としなしで有効に機能できるべきです。 国が、論争の解決か名前管理に関する一般的なICANN方針を採るのを選んでいるかもしれない間、特に、排他的に適切な国内法令の下でこれらの領域に起こる問題に等しくよく対処するかもしれません。 ドメインが、提供するリソースかかるICANNサービスを利用するのを選ぶなら、それはICANNのサポートに貢献するべきです。(それに根、ルートサーバー、およびどんなディレクトリシステムも操作するICANNへの一般に、必要になるように同意されるコストの妥当な部分以外に、ICANNだけがそうしないならあえてそれを請求するはずがなくて、ドメインは参加します)。
Klensin Informational [Page 4] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[4ページ]のRFC3071Reflections
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.
対照的に、一般ドメインが一般ドメインとして扱われるべきであるので、ccTLDsは作動しました。 複数の記録係か登録状況でインターネット公衆を保護するために開発された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.
適切な方針が採られるなら、国のドメイン(上のカテゴリ(iii))が自己に特定できるべきであるので一般ドメイン(上のカテゴリ(i))とものが作動したとき、ccTLDsは作動しました。 この決断をするように適用できたいくつかの評価基準があります。 例えば、登録証明書かそれがドメインが外で積極的に探しているどちらかではありません、そして、ドメインのかなりの大多数の記入者が国です、またはそれらはそのようなどちらかではありません。 また、人は管轄で何らかの触知できるレベルの存在を持つ問題としてこれを考えることができました--例えば、実際的な言い方をするなら国の法にはドメイン管理者対象があるか、または登録規則がそのようなものであるので、ドメインに関連している国の管轄における法廷は、記入者に対して管轄を運動させて、合理的に判断を実施しそうであることができます。
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つの(かなり非押しつけがましい)の規則はそれらが使用するつもりである方針を特定して、発行するということです。 例えば、論争を解決するのに1つの特定の国の法を使用するドメインの記入者には、論争の解決のためのそのメカニズムが許容できないなら、登録の前にそれらの方針を理解して、他の手配(例えばほかの場所に登録する)をする妥当な機会があるはずです。 IANA(根の記録係としての)にドメインの目的と使用に関する不正確な情報を与えるのは、挑戦するためになることがあるべきであり、一貫して代理であるだけではないとしてドメイン代表団の適切さを見直す根拠であるべきであり、公正にRFC1591のオリジナルの条項の下にそのような根拠を提供します。
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.
評価基準は、正確で最新のレジスト情報の有用性を確実にするために名目上は一致していて、すべてにおいて、より伝統的なgTLDsと一致していなければなりません。ジェネリックとしてTLDsを操作する国名略号ドメイン。
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
ICANN(そして、IANA)には、上で説明されるように、かかわり合いが本当の国[コード]のドメイン(すなわち、カテゴリ(iii))の向きにできるだけほとんどあるはずがありません。 どんな特定の理由もありません。
Klensin Informational [Page 5] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[5ページ]のRFC3071Reflections
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が書かれた時であるのと同じくらい重要です。 代替手段は私たちを「管理」から「インターネット支配」かどの主張者が国の合法政府であるかを決定する場合における「国際関係」にすぐに連れて行きます、そして、その特定の指示に入って来ない理由は多数です。
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つの問題が、IANAがあるのをそれがそうした政局の混乱に引きずられた状態で避けることを明らかに意図した、(私が示す、有、)、どんな能力、も問題を解決して、泥沼に落ち込ませることができるだけではありませんでした。 第1要件は、最も目に見えるのと(最も簡単)であり、厳しくて慎重な固守でISO3166の登録されたCountry Codeリストに実行されました(以下を見ます)。 実体にコードがあったなら、TLDに登録されるのが適任でした(IANAは自由に1591年に述べられたそれらの追加最も評価基準を適用できましたが)。 そうしなかったなら、例外が全くありませんでした: 応募者の唯一の償還請求はIANAではなく、3166Registration Authority(現在のちょうど「3166/MA」としてしばしば知られているMaintenance Agency)か国連統計局(現在の統計局)との議論でした。
Klensin Informational [Page 6] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[6ページ]のRFC3071Reflections
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つは歴史的です: それはこのためにISO3166の採用より前に起こります。 他のもの(アセンション島、ガーンジー、マン島、およびジャージー)は論証上追憶、まさしく少なくとも誤りでそうです。 歴史的な理由(多くの思惑があった)にかかわらず、より多くの誤りを正当化するのに先例としてそれらを使用しようとするよりむしろこの種類の誤りを扱う正しい方法にそれらを承認して、移動することになっているのは、ほぼ確実に事実です。
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.
また、これは「予約された」リスト(Standardの一部ではなく、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).
他の2つの問題が、より微妙であって、いつもうまくいったというわけではありません: 時々、ともに「政府は意地を通すことができたこと」に向かって移行する正式な方針の前後に、IANAが変化を求める十分な政府当局であることを意味する人々から手紙を受け取りました。 彼らの何人かが、後でその権威か適切な資格を持たないように判明しました。 1591年自体の仮定は次に、ドメイン管理者によって要求された代表団変化が_本当に、_が政府であるならそれ自体について断言したがっていたと光栄に思っているだろうという規則のように、それが欲しかった変化を要求するのにドメイン管理者に圧力をかけるかもしれません、その国で適正手続きに適用するものなら何でも使用して「国のドメイン管理者」規則が厳密に守られたならことでした。 そして、その過程と圧力を加える能力が事実上、だれが政府であったか、そして、だれがいなかったかを決定して、今までのところどんなIANA評価よりも効果的にするだろう、例えば、要求でのレターヘッドが正統に(遠くに安全に他のどんな特定の政府にも意見を尋ねるか、政府の品揃えよりICANNのために)見えたか否かに関係なく。
Klensin Informational [Page 7] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[7ページ]のRFC3071Reflections
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.
aを採用する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.
国のコードベースの一般的なTLDsと国のドメインの間の境界に同様の原則を適用できました。 異なった状況で、異なった国は、徴兵として、または、「顧客」が主に外部であったプロフィットセンターとしてccTLDを操作するのを好むかもしれません。 何が決定を歴史的にしたかとしても、一般的なインターネットの安定性は、変更が軽く行われるべきでないと主張します。 同時に、そうするための最も良いメカニズムは政府が変更を加えたいなら、変化を要求するようにドメイン管理者を説得して、IANAが即座に、効率的にドメイン管理者によってされた要求を行うのに関連政府が合法性の潜在的決断にICANNにかかわるのではなく(ICANNの政府Advisory Committee(GAC)が正式に個々の国とのその決定をしようとするのをさせるのさえ)、それ自身の手順を用いることです。
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構造が異なるという主張(このモデルの)は以下を修正します。 それらは異なっています。 一般的なTLDsとして作動しているccTLDsはccTLD選挙民と切り離されて、gTLD選挙民で加わられるべきです。 国のccTLDsはICANNの即座のSupporting Organization構造と切り離されて、平行で顧問の容量でICANNに作動するはずです、GACと共に使用されるアレンジメントと同様です。 DNSOと国のTLDsは互いに自発的のベースを除いて、互いに対話するのが必要であるべきではありません、そして、ICANNがそれらのTLDsのすべてのいくつかから相互作用かアドバイスを必要とするなら、DNSO選挙民としてというよりむしろGACのような諮問機関の形でそれを得るのは、より適切でしょう。
7. References
7. 参照
[1] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[1] ポステルと、J.と、「ドメインネームシステム構造と代表団」(RFC1591)は1994を行進させます。
[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)。
Klensin Informational [Page 8] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[8ページ]のRFC3071Reflections
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.
これらの反射は、個人の資格で準備されて、必ず私の過去の、または、現在の雇い主の視点を反映するというわけではありません。 ランディ・ブッシュ、テレサSwinehart、Zitaウェンツェル、ジェフ・ヒューストン、Havard Eidnes、および数人の匿名の評者を含む数人が、このドキュメントの以前のバージョンに関して提案をしたか、または編集のコメントを提供しました。 コードWischhoeferはISO3166/MAについてまた、草稿を見るほど親切であり、いくつかの役に立つ詳細を提供しました。 それらのコメントはドキュメントにはどういった明快があるかにかなり貢献しましたが、作者は結局法人組織であるコメントと結論が提示された入口の選択のために責任を負います。
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.
このメモは、安全保障問題は1セットの管理的意思決定と手順のための文脈を記述して、提起するか、または記述しません。
10. Author's Address
10. 作者のアドレス
John C. Klensin 1770 Massachusetts Ave, Suite 322 Cambridge, MA 02140, USA
Ave、Suite322ケンブリッジ、MA 02140、ジョンC.Klensin1770マサチューセッツ米国
EMail: klensin@jck.com
メール: klensin@jck.com
Klensin Informational [Page 9] RFC 3071 Reflections on the DNS and RFC 1591 February 2001
DNSとRFC1591 2001年2月に関するKlensinの情報[9ページ]のRFC3071Reflections
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society 2001. All Rights Reserved.
Copyright(C)インターネット協会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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Klensin Informational [Page 10]
Klensin情報です。[10ページ]
一覧
スポンサーリンク