[要約] RFC 3245は、ITU-T Study Group 2（SG2）に提供されたENUM（電話番号マッピング）の運用上の決定に関する情報文書であり、ENUMの歴史と背景について説明しています。このRFCの目的は、ENUMの運用上の決定に関する情報を提供し、その背景と歴史を理解することです。
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)
電話番号マッピング（列挙）の履歴とコンテキスト運用上の決定：情報文書がITU-T研究グループ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.
Copyright（c）The Internet Society（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への電話番号マッピング（列挙）の多くの管理および運用の詳細に対する責任を割り当てました。また、ITUは、トップレベルの列挙ドメインの「国」レベルのサブドメインの委任のための応募者の正当性と適切性を決定する責任を負うことを予想していました。最近、関連する決定の背景と推論を説明するために、ITU-T研究グループ2（SG2）の3つのメモが準備されました。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月、ITU-T研究グループ2（以下の「SG2」と呼ばれる）からの質問、特に「質問1と2」に取り組んでいるグループ、およびIETFおよび通信コミュニティのメンバーであるScottのメンバーに応えてBradnerは、Enum Workを担当し、ISOCの標準副社長を担当するエリアディレクターとして、IETFが列挙管理に関する決定の説明を作成する努力を開始しました。これらの文書を作成して洗練する努力は、最終的に彼、パトリック・ファルトストローム（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には、com 2-11-eと同じコンテンツが含まれ、セクション3にはcom 2-12-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からITU-T SG2からIETFが提供するシリーズの1つであり、IETFの列挙ワーキンググループの審議と決定に関する背景情報を提供します。この特定の貢献は、単一のドメインのみが列挙でサポートできるという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).
よく知られているルートゾーンから始まることを考えると、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番号を保存することが技術的には単純なマッピングである理由でした。列挙は、DNSにE.164番号を保存する方法です。DNS階層内の複数の列挙ツリーは、すべてのキャリアがE.164カントリーコードに異なる意味を割り当てることを許可すると同等のテレフォニーを持ち、それぞれが特定の番号を別の回路にマッピングするか、それを完全に拒否します。インターネットの場合、複数のツリーがある場合、どのドメインが列挙レコードを含むかを決定する方法はありません。したがって、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つを選択した場合、2番目のパーティーはどのような場所が選択されたかを知るためにどのように検索していますか？類推は、TLDではなくwww.whitehouseのみを知っていて、そのウェブサイトに行くように人々に頼む場合です。正しいドメイン名は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/列挙数値を調べる場所を知る唯一の方法は、1つのドメインのみを使用し、そのドメインが何であるかについて全員に同意することです。Enumは、一般、グローバル、コンテキストでE.164の数値で使用するシステムであることに注意してください。技術的なものは、列挙のようなメカニズムを使用したい当事者や、電話番号と同じ一般構造を持つ他のシステムを使用することを希望する、またはそれらのアプリケーションをサポートするためのプライベート、バンド、契約から、電話番号と同じ一般構造を持つ他のシステムを防ぐことはできません。ただし、そのようなアプリケーションはE.164でも列挙でもありません。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からSG2からSG2から提供されるシリーズの1つであり、IETFの列挙ワーキンググループの審議と決定に関する背景情報を提供します。この特定のメモは、ENUM DNSツリーが.ARPAトップレベルドメインを使用するというIETFの決定に対処しています。
(Taken from http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt, May 2000.)
（http://www.iab.org/iab/documents/iab-arpa-stmt.txt、2000年5月から取得。）
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アドレスリバースマッピングドメインです。このドメインは、ホストテーブルネーミングからの最初のARPANET遷移戦略の一部として「In-Addr.Arpa」に配置されました（RFC 881-http：//www.ietf.org/rfc/ rfc0881.txtを参照）。IPv4リバースマッピングサブドメインを除き、遷移の一部でもあった<ホスト-table-name> .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（IPv4アドレスの逆マッピング用）、IP6.ARPA（IPv6アドレスの逆マッピング用）、および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、new TLD。これは、ICANNプロセス（1年以上かかる可能性がある）を介してのみ作成でき、DNSツリーを不必要かつ望ましくないほど平らにすることができます。簡単に作成された新しいサブドメイン（2番目のレベルドメイン）を備えた1つのTLD、各パラメーターの1つ。したがって、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」ドメインは、元々DNSの初期展開の一部として確立され、以前はARPANETで標準であったホストテーブルからの遷移メカニズムを提供しました。また、ホストテーブルメカニズムを使用して以前に処理されていた名前マッピング（「逆マッピング」）のIPv4アドレスの恒久的なホームを提供するためにも使用されていました。インターネットアーキテクチャ委員会（IAB）は、割り当てられた名前と番号（ICANN）についてインターネットコーポレーションと協力して、現在、トップレベルドメイン（TLD）の名前「ARPA」の管理を担当しています。この配置は、RFC 3172の付録Aに文書化されています。このドメイン名は、ドメイン名へのIPアドレスの逆マッピングの名前階層のルートを提供します。より一般的には、このドメイン名は、特定のプロトコル値をサービスエンティティの名前にマッピングするための名前のルートを提供することにより、インターネットインフラストラクチャアプリケーションの限られた使用ドメインとしての役割を引き受けます。このドメイン名は、プロトコル値をルックアップキーにマッピングするための名前のルートを提供し、インターネット用の運用上重要なプロトコルインフラストラクチャデータレコードまたはオブジェクトを取得します。
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は、将来的には「ARPA」ドメインに他のインフラストラクチャの使用を追加する場合があります。このような追加または変更は、このドキュメントのセクション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].
このドメインの運用上の管理は、この文書に記載されている規定に従って、IAABとICANNの間のMOUの条件に基づいてIANAによって実行されるものとします[RFC 2860]。
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.
2000年4月28日にRFC 3172の付録Aに記録されているように、米国商務省は、ICANNとの注文の権限の下で行動し、ICANNにIABのガイダンスの下で.ARPA TLDを運用するよう指示しました。インターネットインフラストラクチャアプリケーションのドメイン。
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の最大ルックアップセットは、ルートサーバーからの「ARPA」ドメインの名前サーバーのルックアップであり、クエリエージェントには、権威ある「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」ドメインの効率的かつ正しい動作は、ルートサーバーの運用要件が「ARPA」サーバーの運用要件に適用されるほど十分に重要であると考えられています。RFC 2870に記載されているすべての運用要件は、ルートサーバーの運用要件に適用されるため、「ARPA」サーバーの動作に適用するものとします。ルートサーバーの動作に関連する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.
ルートゾーン（または「。」ゾーン）に対して権威あるサーバーの多くは、現在「ARPA」ゾーンの権威あるものとしても機能しています。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です。列挙構造は、単一のドメインサブツリーに配置する必要があり（個別の貢献、COM 2-11を参照）、重要なインターネットインフラストラクチャに進化すると予想されるため、そこに配置する必要があります。この決定は、ICANNとIETFの間のMOUによって促進され、米国政府からICANNへの指示は、そのドメインのIAB監督を規定しています。米国国防総省機関であるDARPAの名前との混乱にもかかわらず、これらの用途は、インフラストラクチャの目的であったARPAドメインのすべての歴史的使用と一致しています（最初は階層DNSが古いフラットを置き換えるために作成されたときですArpanetの名前空間）：ドメインは、内部または特定のDARPAの目的に使用されませんでした。複数のインフラストラクチャドメインでの潜在的な困難を認識して、インターネットアーキテクチャボードは2000年5月に、すべての新しいインフラストラクチャ情報がARPAドメインに保存され、既存のインフラストラクチャサブツリーが実現可能に移行することを結論付けました。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がSG2に提供するシリーズの1つであり、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はまた、必要に応じて政府との仕事と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アドレスレジストリ（RIRS）がすべての基準を満たしているという結論に達しました。彼らは皆、インフラストラクチャサービスを確実に安全に提供およびサポートする豊富な経験があり、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.
すべてのRIRSが基準を満たしていたことを考えると、特定のRIRの選択は他の要因を調べる必要がありました。IABは、RIPE NCCがE164.ARPAの最高のオペレーターになると結論付けました。これは、主にDNSサーバーを実行していることと、中立の法的管轄区域での場所にある程度の経験に基づいています。
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と熟したNCCは、国のコードレベルで列挙登録を行う際に後者が従うための手順に同意しました。これらの指示は、経験が蓄積されるにつれて進化すると予想されます。現在のバージョンは、IABおよび/またはRIPE NCC Webサイトに投稿されます。
None. This document is intended to be self-contained and purely informational.
なし。このドキュメントは、自己完結型で純粋に情報を提供することを目的としています。
6.2. Informative and explanatory references.
6.2. 有益で説明的な参照。
[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] Carpenter、B.、Baker、F。、およびM. Roberts、「インターネットが割り当てられた番号当局の技術作業に関する覚書」、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] Bush、R.、Karrenberg、D.、Kosters、M。and 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] Huston、G.、ed。、「アドレスおよびルーティングパラメーターエリアドメイン（「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
ハラルド・アルベスランドはアトキンソン・ロブ・オーストイン・フレッド・ベイカー・ベロヴィン・ブライアン・カーペンタージョン・クロフト・レスリー・デイグル・スティーブ・ディーリング・フロイド・ジェフ・ヒューストン・ジョン・クレンシン・ヘニング・シュルズンヌ
Scott Bradner EMail: sob@harvard.edu
Scott Bradnerメール：sob@harvard.edu
Patrik Faltstrom EMail: paf@cisco.com
Patrik Faltstromメール：paf@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。