Network Working Group J. Klensin, Ed.
Request for Comments: 3245 IAB
Category: Informational March 2002
The History and Context of Telephone Number Mapping (ENUM)
Operational Decisions: Informational Documents Contributed
to ITU-T Study Group 2 (SG2)
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.
RFC 2916は、IABの電話番号マッピング（ENUM）の管理および動作の詳細の数の責任を割り当てます。また、ITUがトップレベルのENUMドメインの「国コード」レベルのサブドメインの委譲のために応募者の正当性と妥当性を判断するための責任を取るだろうと予想しました。最近、3個のメモは、関連する意思決定のための背景、と推論を説明するために、ITU-T研究グループ2（SG2）のために用意されています。 IABは、モデルのその部分の実装のためにRIPE NCCに手続き命令のセットを提供してきました。 3つのメモの内容は、IETFコミュニティの情報については、このドキュメントで提供されています。
Table of Contents
目次
1. Introduction: ENUM Background Information ..................... 2
2. Why one and only one domain is used in ENUM ................... 2
3. Why .ARPA was selected as the top level domain for ENUM ....... 4
4. The selection of an operator for E164.ARPA .................... 7
5. Procedures to be followed by RIPE NCC ......................... 8
6. References .................................................... 8
6.1. Normative references ........................................ 8
6.2. Informative and explanatory references ...................... 8
7. Security Considerations ....................................... 9
8. IANA Considerations ........................................... 9
9. Authors' Addresses ............................................ 9
10. Full Copyright Statement ..................................... 10
In January 2002, in response to questions from the ITU-T Study Group 2 (referred to just as "SG2", below), specifically its group working on "Questions 1 and 2", and members of the IETF and telecommunications communities, Scott Bradner, as Area Director responsible for the ENUM work and ISOC Vice President for Standards, initiated an effort to produce explanations of the decisions made by the IETF about ENUM administration. The effort to produce and refine those documents eventually involved him, Patrik Faltstrom (author of RFC 2916), and several members of the IAB.
2002年1月には、特にその「質問1と2」にワーキンググループ、およびIETFおよび電気通信共同体のメンバー、スコット（ちょうど下の「SG2」、と呼ばれる）ITU-T研究グループ2、からの質問に応じて、ブラドナーのは、標準化のためのENUM作業を担当する地域ディレクターとISOC副社長として、IETF ENUM程度投与することによって行われた決定の説明を生成するための努力を開始しました。最終的に彼を関係者のドキュメントを生成し、洗練するための努力、パトリックFaltstrom（RFC 2916の作者）、およびIABのいくつかのメンバー。
The documents have now been contributed to ITU-T, and are being published as internal SG2 documents. This document provides the IETF community a copy of the information provided to SG2. Section 2 below contains the same content as COM 2-11-E, section 3 contains the same content as COM 2-12-E, and section 4 contains the same content as SG2 document COM 2-10-E. The documents being published within SG2 show their source as "THE INTERNET SOCIETY ON BEHALF OF THE IETF", which is a formality deriving from the fact that ISOC holds an ITU sector membership on behalf of the IETF.
文書は現在、ITU-Tに貢献してきた、と内部SG2文書として公開されています。この文書は、IETFコミュニティSG2に提供される情報のコピーを提供します。セクション2は、以下のセクション3は、COM 2-12-Eと同じ内容を含んでいる、COM 2-11-Eと同じ内容を含んでおり、セクション4は、SG2文書COM 2-10-Eと同じ内容を含んでいます。 SG2内で公開されている文書は、ISOCはIETFを代表してITUセクターメンバーシップを保持しているという事実から派生する形式で、「IETFを代表してインターネット社会」としてのソースを示しています。
This contribution is one of a series provided by the IETF to ITU-T SG2 to provide background information about the IETF's ENUM Working Group deliberations and decisions. This particular contribution addresses the IETF's decision that only a single domain could be supported in ENUM.
この貢献はIETFのENUMワーキンググループの審議・決定に関する背景情報を提供するために、ITU-T SG2にIETFにより提供されるシリーズの一つです。この特定の貢献は、単一のドメインがENUMでサポートすることができIETFの決定を扱います。
In the Domain Name System (DNS), each domain name is globally unique. This is a fundamental fact in the DNS system and follows mathematically from the structure of that system as well as the resource identification requirements of the Internet. Which DNS server is authoritative for a specific domain is defined by delegations from the parent domain, and this is repeated recursively until the so-called root zone, which is handled by a well-known set of DNS servers. Note that words like "authoritative" and "delegation" and their variations are used here in their specific, technical, DNS sense and may not have the same meanings they normally would in an ITU context.
ドメインネームシステム（DNS）では、各ドメイン名はグローバルに一意です。これは、DNSシステムの基本的な事実であり、そのシステムの構造だけでなく、インターネットのリソース識別要件から数学的には以下。どのDNSサーバーは親ドメインからの代表団によって定義される特定のドメインの権威であり、これは、DNSサーバーのよく知られたセットによって処理される、いわゆるルートゾーンまで再帰的に繰り返されます。 「権威」と「委任」のような単語とそのバリエーションは、その具体的、技術的、DNSの意味で使用されていると、彼らは通常、ITUコンテキストの場合と同じ意味を持っていないことに注意してください。
Given that one starts with the well-known root zone, every party querying the DNS system will end up at the same set of servers for the same domain, regardless of who is sending the query, when the query is sent and where in the network the query is initiated. In May 2000 the IAB published a document on the need for a single root in the DNS. This document explores the issues in greater detail. See RFC 2826 (http://www.ietf.org/rfc/rfc2826.txt).
1は、よく知られているルートゾーンで始まっていることを考えると、DNSシステムを検索し、すべての当事者は関係なく、クエリがネットワークに送信され、どこでされたときに、クエリを送信している人の、同じドメインのサーバの同じセットになってしまいますクエリが開始されます。 2000年5月にはIABは、DNSでの単一のルートの必要性についての文書を発表しました。この文書では、より詳細に問題を探ります。 RFC 2826（http://www.ietf.org/rfc/rfc2826.txt）を参照してください。
An E.164 number is also globally unique, and because of that it has most of the same properties as a domain name. This was the reason why storing E.164 numbers in the DNS system is technically a simple mapping. ENUM is just that, a way to store E.164 numbers in the DNS. Multiple ENUM trees in the DNS hierarchy would have the telephony equivalent of permitting every carrier to assign a different meaning to an E.164 country code, with each one potentially mapping a given number to a different circuit or rejecting it entirely. For the Internet, if there were multiple trees, there would be no way to determine which domains might contain ENUM records. Thus, each application that uses ENUM facilities would have to be manually configured with a list of domains to be searched. This would incur the same problems of scaling and updates that led to the development of the DNS.
E.164番号もグローバルにユニークで、かつそのためには、ドメイン名と同じ性質のほとんどを持っています。これは、DNSシステムのE.164番号を格納することは技術的に簡単なマッピングである理由でした。 ENUMは、ちょうどそのDNSにE.164番号を格納するための方法です。 DNS階層内の複数のENUMツリーはそれぞれが潜在的に異なる回路に与えられる番号をマッピングするか、それを完全に拒否して、E.164国コードに異なる意味を割り当てる毎にキャリアを許可する電話等価を有するであろう。複数の木があった場合、インターネットについては、ENUMレコードが含まれている可能性のあるドメインを決定する方法はありません。従って、ENUM設備を使用する各アプリケーションは、手動で検索するドメインのリストで構成されなければなりません。これは、DNSの開発につながったスケーリングや更新の同じ問題を被ります。
The goal with ENUM is that one party should be able to look up information in DNS, which another party has stored in DNS. This must be possible with only the E.164 number as input to the algorithm.
ENUMとの目標は、一方の当事者が他の当事者がDNSに保存されたDNSの情報を、調べることができるはずということです。これは、アルゴリズムへの入力としてのみE.164番号で可能でなければなりません。
If the party storing information in DNS has two (or more) places to choose from, and chooses one of them, how is a second party looking up things to know what place was selected? An analogy would be if one knew only www.whitehouse, and not the TLD, and ask people to go to that website. Is the correct domain name www.whitehouse.gov, www.whitehouse.com or www.whitehouse.se? It should be noted that www.whitehouse.com exists and is a pornography site.
DNSで情報を記憶パーティから選択する2つ（またはそれ以上）の場所を持ち、そのうちの一つを選択した場合、どのように第二のパーティには、選択したどのような場所を知るために物事を見ていますか？アナロジーは、1つのTLDをのみwww.whitehouse知っていた、とされていない場合も、そのWebサイトにアクセスする人を求めるだろう。正しいドメイン名www.whitehouse.gov、www.whitehouse.comまたはwww.whitehouse.seのですか？ www.whitehouse.comが存在し、ポルノサイトであることに留意すべきです。
Thus, the only way of knowing where to look up E.164/ENUM numbers in DNS is to use one and only one domain, and have everyone agree on what that domain is. Note that ENUM is a system for use with E.164 numbers in their general, global, context. Nothing technical can, or should, try to prevent parties that wish to use ENUM-like mechanisms, or other systems that have the same general structure as telephone numbers, from working out private, out of band, agreements to support those applications. However, such applications are neither E.164 nor ENUM, any more than internal extension numbers in a PBX are normally considered to be part of either.
このように、どこDNSにE.164 / ENUM番号を検索する方法を知る唯一の方法は、唯一のドメインを使用し、誰もがそのドメインが何であるかに同意することです。 ENUMは彼らの一般的な、世界的、文脈でE.164番号で使用するためのシステムであることに注意してください。技術的な何もすることができ、または、それらのアプリケーションをサポートするために、民間、バンドのうち、契約のワークアウトから、ENUMのようなメカニズム、または電話番号と同じ一般的な構造を持っている他のシステムを使用したい政党を防ぐために試してみてください。しかし、そのようなアプリケーションは、どちらもE.164やENUMは、PBX内の任意以上内線番号は、通常のいずれかの一部と見なされています。
This memo is one of a series provided by the IETF to SG2 to provide background information about the IETF's ENUM Working Group deliberations and decisions. This particular memo addresses the IETF's decision that the ENUM DNS tree would use the .ARPA top level domain.
このメモはIETFのENUMワーキンググループの審議・決定に関する背景情報を提供するために、SG2にIETFにより提供されるシリーズの一つです。この特定のメモはENUMのDNSツリーが.ARPAトップレベルドメインを使用するIETFの決定を扱います。
(Taken from http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt, May 2000.)
（2000年5月、http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txtから撮影）
Over the last several months, the IAB has been reviewing, and discussing with ICANN and other parties, the handling of various Internet Protocol-related infrastructure components that the community has concluded should be placed into the DNS.
過去数ヶ月の間、IABが見直しされており、ICANNおよび他の関係者と協議、コミュニティが締結している様々なインターネットプロトコル関連のインフラストラクチャコンポーネントの取り扱いはDNSの中に配置する必要があります。
Historically, the most visible infrastructure domain has been the IPv4 address reverse-mapping domain. This domain was placed in "in-addr.arpa" as part of the initial ARPANET transition strategy from host table naming (see RFC 881-http://www.ietf.org/rfc/ rfc0881.txt). Other than the IPv4 reverse-mapping subdomain, it became the only active subdomain of that domain as the <host-table-name>.ARPA names that were also part of the transition were gradually removed. Other infrastructure domains were, in the past, placed under the "INT" TLD and various organizational names.
歴史的に、最も目に見えるインフラストラクチャドメインは、IPv4アドレスの逆マッピングドメインとなっています。 （：//www.ietf.org/rfc/ rfc0881.txt RFC 881-HTTPを参照してください）このドメインは、ホストテーブルの命名から最初のARPANET移行戦略の一環として、「in-addr.arpa」に入れました。 IPv4の逆マッピングサブドメイン以外に、それが徐々に取り除かれたもの移行の一部であった<ホストテーブル名> .ARPA名とそのドメインの唯一のアクティブなサブドメインとなりました。他のインフラストラクチャドメインは「INT」TLDとさまざまな組織名の下に置かれ、過去にありました。
It is in the interest of general Internet stability, to pay adequate attention to the placement of secondary DNS servers, and administrative cleanliness, to start rationalizing this situation by locating new infrastructure subdomains in a single domain and migrating existing ones to it as appropriate. It appears that our original infrastructure domain "ARPA", redesignated from an abbreviation for "ARPANET" to an acronym for "Address and Routing Parameters Area" is best suited for this purpose.
これは、単一のドメインで新しいインフラストラクチャのサブドメインを探し、必要に応じて、それに既存のものを移行することで、この状況を合理化を開始するために、セカンダリDNSサーバーの配置、および管理清潔に十分な注意を払うように、一般的なインターネットの安定性の関心です。 「アドレスとルーティングパラメータエリア」の頭文字に「ARPANET」の略称から再指定独自のインフラドメイン「ARPA」は、この目的のために最も適していることが表示されます。
Operationally, it is easier to ensure good stability for DNS in general if we have as few DNS zones as possible that are used for parameters for infrastructure purposes. Today, new infrastructure domains are put in ARPA and old assignments which were made in other domains are being migrated to ARPA. Currently, ARPA is used for in-addr.arpa (for reverse mapping of IPv4 addresses), ip6.arpa, (for reverse mapping of IPv6 addresses), and e164.arpa, (the subject of this memo). In the future, URI schemes, URN namespaces and other new address families will be stored in ARPA.
操作上、我々がインフラの目的のためのパラメータのために使用されている可能な限り少数のDNSゾーンを持っている場合、一般的にはDNSのための良好な安定性を確保することが容易です。今日では、新しいインフラストラクチャドメインはARPAに置かれ、他のドメインで行われた古い割り当てはARPAに移行されています。現在、ARPAは（このメモの主題）、in-addr.arpa（IPv6アドレスの逆マッピング用）（IPv4アドレスの逆マッピング用）、ip6.arpa、およびe164.arpaのために使用されます。将来的には、URIスキーム、URN名前空間と他の新しいアドレスファミリーはARPAに保存されます。
Theoretically, each set of infrastructure parameters could be stored in a separate domain as a TLD. (For example, .URI, .UNI, .IPV6, new TLD, which only can be created via the ICANN process (which might take a year or more) and would unnecessarily and undesirably flatten the DNS tree. It is much easier to have one TLD with easily created new subdomains (2nd level domains), one for each parameter. Thus it was logical to store E.164 numbers in ARPA.
理論的には、インフラストラクチャ・パラメータの各セットは、TLDのような別個の領域に記憶することができます。 （例えば、.URI、.UNI、.IPV6、だけ年以上かかることがありますICANNプロセス（）を使用して作成することができ、不必要と望ましくないDNSツリーをフラット化する新しいTLDは、。持っている方がはるかに簡単です簡単に作成された新しいサブドメイン（第2レベルドメイン）、各パラメータのための1つ。を有するものTLDは、したがって、ARPAでE.164番号を格納する論理的でした。
The "arpa" domain was originally established as part of the initial deployment of the DNS, to provide a transition mechanism from the Host Tables that were previously standard in the ARPANET. It was also used to provide a permanent home for IPv4 address to name mappings ("reverse mappings") which were previously also handled using the Host Table mechanism. The Internet Architecture Board (IAB), in cooperation with the Internet Corporation for Assigned Names and Numbers (ICANN), is currently responsible for managing the Top Level Domain (TLD) name "arpa". This arrangement is documented in Appendix A of RFC 3172. This domain name provides the root of the name hierarchy of the reverse mapping of IP addresses to domain names. More generally, this domain name undertakes a role as a limited use domain for Internet infrastructure applications, by providing a name root for the mapping of particular protocol values to names of service entities. This domain name provides a name root for the mapping of protocol values into lookup keys to retrieve operationally critical protocol infrastructure data records or objects for the Internet.
「ARPA」ドメインは当初ARPANETで以前に標準たホストテーブルからの遷移機構を提供するために、DNSの初期の展開の一部として確立されました。また、以前にも、ホストテーブルのメカニズムを使用して処理された名前のマッピング（「逆マッピング」）にIPv4アドレスのための永久的な家を提供するために使用されました。インターネットアーキテクチャ委員会（IAB）は、割り当てられた名前と番号（ICANN）のためのインターネット株式会社と共同で、現在トップレベルドメイン（TLD）の名前「アルパ」を管理する責任があります。この配置は、このドメイン名は、ドメイン名にIPアドレスの逆マッピングの名前階層のルートを提供してRFC 3172の付録Aに記載されています。より一般的には、このドメイン名は、サービスエンティティの名前に特定のプロトコル値のマッピングの名前のルートを提供することで、インターネット・インフラストラクチャ・アプリケーションのための限定使用のドメインとしての役割を引き受けます。このドメイン名は、インターネットのための操作上の重要なプロトコルインフラストラクチャデータレコードまたはオブジェクトを取得するために、検索キーにプロトコル値のマッピングの名前のルートを提供します。
The IAB may add other infrastructure uses to the "arpa" domain in the future. Any such additions or changes will be in accordance with the procedures documented in Section 2.1 and Section 3 of this document. [referring to RFC 3172] This domain is termed an "infrastructure domain", as its role is to support the operating infrastructure of the Internet. In particular, the "arpa" domain is not to be used in the same manner (e.g., for naming hosts) as other generic Top Level Domains are commonly used.
IABは、他のインフラストラクチャは、将来的に「アルパ」ドメインに使用しています追加することができます。任意のそのような追加または変更は、セクション2.1およびこのドキュメントのセクション3に記載の手順に従ってあろう。その役割は、インターネットの操作インフラストラクチャをサポートするためにあるように、このドメインは、「インフラドメイン」と呼ばれている[RFC 3172を参照]。具体的には、「ARPA」ドメインは、同じ方法で使用されるべきではない（例えば、ホストに名前を付けるための）他の一般的なトップレベルドメインとして一般的に使用されます。
The operational administration of this domain, in accordance with the provisions described in this document, shall be performed by the IANA under the terms of the MoU between the IAB and ICANN concerning the IANA [RFC 2860].
このドメインの動作投与は、本文書に記載の規定に従い、IANA [RFC 2860]に関するIABとICANNの間の覚書の条件の下でIANAによって実行されなければなりません。
As documented in appendix A of RFC 3172, on April 28, 2000 the US Department of Commerce, acting under the authority of its purchase order with ICANN, directed ICANN to operate the .ARPA TLD under the guidance of the IAB, as a limited use domain for internet infrastructure applications.
RFC 3172の付録Aに記載されているように、2000年4月28日米国商務省に、ICANNとの購入注文の権限の下で働く、限られた使用として、IABの指導の下.ARPA TLDを動作させるためにICANNを監督インターネット・インフラストラクチャ・アプリケーション用のドメイン。
As this domain is part of the operationally critical infrastructure of the Internet, the stability, integrity and efficiency of the operation of this domain is a matter of importance for all Internet users.
このドメインは、インターネットの操作上重要なインフラストラクチャの一部であるように、このドメインの動作の安定性、整合性と効率は、すべてのインターネットユーザーのために重要な問題です。
The "arpa" domain is positioned as a top level domain in order to avoid potential operational instabilities caused by multiple DNS lookups spanning several operational domains that would be required to locate the servers of each of the parent names of a more deeply nested infrastructure name. The maximal lookup set for ARPA is a lookup of the name servers for the "arpa" domain from a root server, and the query agent is then provided with a list of authoritative "arpa" name servers.
「ARPA」ドメインは、より深くネストされたインフラ名の親の名前のそれぞれのサーバーを検索するために必要とされるであろういくつかの動作のドメインにまたがる複数のDNSルックアップによって引き起こされる潜在的な運用不安定性を回避するためには、トップレベルドメインとして位置付けています。 ARPAのために設定された最大のルックアップはルートサーバーからの「アルパ」ドメインのネームサーバの検索で、クエリ・エージェントは、その後正式な「アルパ」のネームサーバのリストが提供されます。
The efficient and correct operation of the "arpa" domain is considered to be sufficiently critical that the operational requirements for the root servers apply to the operational requirements of the "arpa" servers. All operational requirements noted in RFC 2870, as they apply to the operational requirements of the root servers, shall apply to the operation of the "arpa" servers. Any revision to RFC 2870 in relation to the operation of the root servers shall also apply to the operation of the "arpa" servers.
「ARPA」ドメインの効率的かつ正確な操作は、ルートサーバの運用要件は「アルパ」のサーバの運用要件に適用されることを十分に重要であると考えられています。すべての運用上の要件は、彼らはルートサーバの運用要件に適用される、「アルパ」のサーバーの動作に適用されるものと、RFC 2870で述べました。ルートサーバの動作に関連したRFC 2870に任意の改正も「ARPA」のサーバーの動作に適用されるものとします。
Many of the servers that are authoritative for the root zone (or the "." zone) also currently serve as authoritative for the "arpa" zone. As noted in RFC 2870, this arrangement is likely to change in the future.
ルートゾーン（または「」ゾーン）に対して権限のあるサーバーの多くは、現在 『アルパ』ゾーンの権威としての役割を果たす。 RFC 2870で述べたように、この配置は、将来変更する可能性があります。
The ARPA domain is the preferred TLD for infrastructure and parameter use. The ENUM structure should be placed in a single domain subtree (see separate contribution, COM 2-11), and is expected to evolve into important Internet infrastructure, and hence should be placed there. This decision is facilitated by the MOU between ICANN and IETF and the instructions from the US Government to ICANN, which provide for IAB supervision of that domain. Despite some confusion with the name of a US Department of Defense agency, DARPA, these uses are consistent with all of the historical uses of the ARPA domain, which have been for infrastructure purposes (initially when the hierarchical DNS was created to replace the old flat namespace of ARPANET): the domain was never used for any internal or specific DARPA purpose. Recognizing the potential difficulties with multiple infrastructure domains, the Internet Architecture Board concluded in May 2000 that all new infrastructure information was to be stored in the ARPA domain and existing infrastructure subtrees migrated there as feasible. http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt provides additional context for these decisions.
ARPAドメインは、インフラストラクチャとパラメータの使用のための好適なTLDです。 ENUM構造は、（別の寄与、COM 2-11を参照）は、単一のドメイン・サブツリーに配置する必要があり、重要なインターネットインフラストラクチャに発展することが予想され、従ってそこに置かれるべきです。この決定は、ICANNとIETFとそのドメインのIAB監督を提供するICANNへの米国政府からの指示、とのMOUによって促進されます。米国国防総省の機関、DARPAの名前を持ついくつかの混乱にもかかわらず、これらの用途では、階層DNSが古いフラットを置き換えるために作成された当初とき、インフラストラクチャのためになっているARPAドメインの歴史的な使用、（のすべてと一致していますARPANETの名前空間）：ドメインは、任意の内部または特定のDARPAの目的のために使用されていませんでした。複数のインフラストラクチャドメインとの潜在的な難しさを認識し、インターネットアーキテクチャ委員会は、すべての新しいインフラ情報はARPAドメインに保存され、既存のインフラストラクチャのサブツリーが可能とそこに移行されるようになったことを2000年5月に締結しました。 http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txtは、これらの決定のための追加のコンテキストを提供します。
The ENUM Working Group decided to follow that recommendation.
ENUM作業部会は、その勧告に従うことを決めました。
This contribution is one of a series provided by the IETF to SG2 to provide background information about the IETF's ENUM Working Group deliberations and decisions. This particular contribution addresses the IETF's selection of an operator for the E164.ARPA domain.
この貢献はIETFのENUMワーキンググループの審議・決定に関する背景情報を提供するために、SG2にIETFにより提供されるシリーズの一つです。この特定の貢献はE164.ARPAドメインのためのオペレータのIETFの選択に対応しています。
RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes the requirements for operating DNS root servers. Important DNS-based infrastructure services require that their servers be operated with the same level of attention to reliability and security that the root servers require. In addition, for an infrastructure service such as E164.ARPA some additional requirements were felt by the IAB to be important. Organizations that operate core services such as IN-ADDR.ARPA and E164.ARPA must have a history of reliable operation of DNS servers and be highly respected and known for both their relevant technical skills and their fairness and impartiality. In addition, the IAB felt that the organization that operates such infrastructure domains must be a non-profit and public-service-oriented one to remove any incentive for exploitative behavior based on profit motives that depend on, e.g., the number of records in the database even if some reasonable registration fee is charged to recover costs. The IAB also felt that they wanted an organization with good (and extensive) experience working with governments when necessary and one with experience working with the IAB and the IETF more generally.
RFC 2870（http://www.ietf.org/rfc/rfc2780.txt）は、オペレーティングDNSルートサーバーの要件について説明します。重要DNSベースのインフラストラクチャサービスは、そのサーバは、ルートサーバが必要と信頼性とセキュリティへの配慮の同じレベルで操作する必要があります。また、このようなE164.ARPAなどのインフラストラクチャサービスのためにいくつかの追加要件が重要であるとIABが感じられました。このようIN-ADDR.ARPAやE164.ARPAなどのコアサービスを運用する組織は、DNSサーバの信頼性の高い動作の歴史を持っており、非常に尊敬とその関連技術スキルとその公正性と公平性の両方のために知らなければなりません。また、IABは、このようなインフラのドメインを運用する組織は、内のレコードの数、例えば、依存利益の動機に基づいて搾取的行動のためのインセンティブを削除する非営利および公共サービス指向のいずれかである必要があることを感じましたデータベースも、いくつかの合理的な登録料がコストを回収するために充電されている場合。 IABはまた、彼らは良い（と豊富な）必要な政府で働いた経験や、より一般的にIABとIETFでの作業経験を持つものと組織を望んでいたことを感じました。
The IAB researched various options for operators and came to the conclusion that the regional IP address registries (RIRs) met all of the criteria. They all had extensive experience providing and supporting infrastructure services reliably and securely and all three of them had a long history of working with the IETF.
IABは、事業者のためのさまざまなオプションを調査し、地域のIPアドレスレジストリ（RIRが）が基準のすべてを満たしたという結論に達しました。彼らはすべて提供し、確実かつ安全にインフラストラクチャサービスをサポートする豊富な経験を持っていたし、それらのすべての3つは、IETFでの作業の長い歴史を持っていました。
Given that all of the RIRs would have met the criteria, the selection of a particular RIR required looking at other factors. The IAB concluded that RIPE NCC would be the best operator for E164.ARPA, based largely on their somewhat greater experience in running DNS servers and on their location in a neutral legal jurisdiction.
RIRのすべてが基準を満たしているだろうことを考えると、特定のRIRの選択は、他の要因を見て必要。 IABは、RIPE NCCは、主にDNSサーバーを実行中に彼らのやや大きな経験に中立法的管轄内の位置に基づいてE164.ARPAための最良のオペレータ、だろうと結論付けました。
Of course, once a subdomain associated with a country code is assigned for registration and operations to an appropriately-designated entity for the associated country or numbering plan, administration of that subdomain is entirely a National Matter, with no involvement anticipated from the IAB/IETF, the E164.ARPA registry, or from the ITU.
国コードに関連付けられたサブドメインが関連付けられている国や番号計画のために、適切に指定されたエンティティへの登録や操作のために割り当てられるともちろん、そのサブドメインの投与は、IAB / IETFから予想される無関与して、完全に国家の問題です、E164.ARPAレジストリ、またはITUから。
The IAB and the RIPE NCC have agreed on procedures for the latter to follow in making ENUM registrations at the country code level. Those instructions are expected to evolve as experience is accumulated. Current versions will be posted on the IAB and/or RIPE NCC web sites.
IABとRIPE NCCは、国コードレベルでのENUMの登録を行う際に従うべき後者の手続きに合意しました。これらの命令は、経験が蓄積されるように進化することが期待されています。現在のバージョンでは、IABおよび/またはRIPE NCCのウェブサイトに掲載されます。
None. This document is intended to be self-contained and purely informational.
無し。この文書は自己完結型と純粋に情報提供することを意図しています。
[RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC 2860]大工、B.、ベイカー、F.およびM.ロバーツ、RFC 2860、2000年6月「インターネット割り当て番号機関の技術的な仕事に関する覚書」。
[RFC 2870] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
[RFC 2870]ブッシュ、R.、Karrenberg、D.、Kosters、M.とR. Plzak、 "ルートネームサーバの運用要件"、BCP 40、RFC 2870、2000年6月。
[RFC 2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[RFC 2916] Faltstrom、P.、 "E.164番号とDNS"、RFC 2916、2000年9月。
[RFC 3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ('arpa')", BCP 52, RFC 3172, September 2001.
[RFC 3172]ヒューストン、G.編、 "管理ガイドライン＆アドレスの運用要件とルーティングパラメータエリアドメイン（ 'ARPA'）"、BCP 52、RFC 3172、2001年9月。
This document provides information only and raises no new security issues. The security issues associated with the underlying protocols are described in RFC 2916.
この文書は情報のみを提供し、新たなセキュリティ問題を提起していません。基本的なプロトコルに関連するセキュリティ上の問題は、RFC 2916に記述されています。
There are no IANA considerations regarding this document. Sections 3 and 4 contain a record of actions already performed by IANA and partial explanations for them.
この文書に関する一切IANAの考慮事項はありません。セクション3と4は、すでにIANAおよびそれらのための部分的な説明によって実行されるアクションの記録が含まれます。
Internet Architecture Board EMail: iab@iab.org
インターネットアーキテクチャ委員会メールアドレス：iab@iab.org
Membership at time this document was completed:
このドキュメントが完成した時点で会員：
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Steve Bellovin Brian Carpenter Jon Crowcroft Leslie Daigle Steve Deering Sally Floyd Geoff Huston John Klensin Henning Schulzrinne
ハラルドAlvestrandはアトキンソンロブAusteinとフレッド・ベイカー、スティーブBellovin氏ブライアン・カーペンタージョンクロウクロフトレスリーDaigle氏スティーブデアリングサリーフロイドジェフ・ヒューストンジョン・クレンシンヘニングSchulzrinneと蘭
Scott Bradner EMail: sob@harvard.edu
スコット・ブラッドナーEメール：sob@harvard.edu
Patrik Faltstrom EMail: paf@cisco.com
パトリックFaltstrom Eメール：paf@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. 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 needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or 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機能のための基金は現在、インターネット協会によって提供されます。