RFC3245 日本語訳

Network Working Group                                    J. Klensin, Ed.
Request for Comments: 3245                                           IAB
Category: Informational                                       March 2002

ワーキンググループJ.Klensin、エドをネットワークでつないでください。コメントのために以下を要求してください。 3245年のIABカテゴリ: 情報の2002年3月

       The History and Context of Telephone Number Mapping (ENUM)
       Operational Decisions: Informational Documents Contributed
                      to ITU-T Study Group 2 (SG2)

電話番号のマッピングの(ENUM)操作上の決定の歴史と文脈: ITU-T研究グループ2に寄付された情報のドキュメント(SG2)

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 (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

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.

RFC2916はTelephone Number Mapping(ENUM)の多くの管理の、そして、操作上の細部への責任をIABに割り当てました。 また、それは、ITUがトップレベルENUMドメインに関する「国名略号」レベルサブドメインの委譲のために応募者の合法性と適切さを決定することへの責任を取ると予期しました。 最近、3つのメモがITU-T Study Group2(SG2)が関連決定のためにバックグラウンドについて説明して、推論するように準備されました。 また、IABはそれらのモデルの部分の実装のために1セットの手続き上の指示をRIPE NCCに供給しました。 本書ではIETF共同体の情報に3つのメモの中身を提供します。

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

1. 序論: ENUM基礎的な情報… 2 2. 唯一無二の1つのドメインがENUMで使用される理由… 2 3. .ARPAがENUMのためのトップ・レベル・ドメインとして選定された理由… 4 4. E164.ARPAのオペレータの選択… 7 5. RIPE NCCによって続かれるべき手順… 8 6. 参照… 8 6.1. 標準の参照… 8 6.2. 有益で説明している参照… 8 7. セキュリティ問題… 9 8. IANA問題… 9 9. 作者のアドレス… 9 10. 完全な著作権宣言文… 10

Klensin                      Informational                      [Page 1]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[1ページ]のRFC3245歴史と文脈

1. Introduction: ENUM Background Information

1. 序論: ENUM基礎的な情報

   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.

ITU-T Study Group2からの質問に対応した2002年1月、(正当であるとして参照される、「SG2"、下)、明確に「規格において、ENUM仕事とISOC副社長に責任がある領域のディレクターとして、質問1と2インチとIETFのメンバーとテレコミュニケーション共同体、スコット・ブラドナーはENUM管理に関してIETFによってされた決定に関する説明を作り出すために取り組みを開始したこと」に働いているグループ 結局それらのドキュメントを製作して、洗練する取り組みは彼、パトリクFaltstrom(RFC2916の作者)、および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が記録するように発表されています。 このドキュメントはSG2に提供された情報のコピーをIETF共同体に提供します。 以下のセクション2はCOMと同じ内容を2-11E含みます、そして、セクション3はCOMと同じ内容を2-12E含みます、そして、セクション4はSG2ドキュメントCOMと同じ内容を2-10E含みます。 「IETFを代表したインターネットの振興発展を目的とする組織」(事実にそのISOCに由来している形式的な手続きである)がIETFを代表してITUセクター会員資格を保持するとき、SG2の中で発表されるドキュメントは彼らのソースを示しています。

2. Why one and only one domain is used in ENUM

2. 唯一無二の1つのドメインがENUMで使用される理由

2.1. Introduction

2.1. 序論

   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作業部会の熟考と決定に関する基礎的な情報を提供するためにIETFによってITU-T SG2に提供されたシリーズの1つです。 この特定の貢献はENUMで単一領域しかサポートすることができなかったというIETFの決定を扱います。

2.2. The need for a single root in the DNS

2.2. DNSのただ一つの根の必要性

   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文脈でそうする同じ意味を持っていないかもしれません。

Klensin                      Informational                      [Page 2]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[2ページ]のRFC3245歴史と文脈

   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のただ一つの根の必要性のドキュメントを発表しました。 このドキュメントは詳細によりすばらしい問題を探ります。 RFC2826( http://www.ietf.org/rfc/rfc2826.txt )を見てください。

2.3. Storing E.164 numbers in the DNS

2.3. DNSにE.164番号を保存します。

   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はまさしくそれであり、店E.164への道はDNSの数です。 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がある目標は1回のパーティーが別のパーティーが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の情報を保存するパーティーがそれらの1つを選んで、選ぶ2つ(さらに)の場所を持っているなら、1秒はどのようにどんな場所が選択されたかを知るものを見上げているパーティーですか? 類推は、あるものが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/ENUM番号を調べるかを知る唯一の方法は、唯一無二の1つのドメインを使用して、皆が、そのドメインが何であるかに同意させることです。 ENUMがE.164番号がそれらの一般的で、グローバルな文脈にある使用のシステムであることに注意してください。 技術的なものは何も、防ぐことができるか、またはENUMのようなメカニズムを使用したがっているパーティー、または電話番号と同じ一般構造体を持っている他のシステムを防ごうとするべきではありません、個人的に解決するのから、バンドから、それらのアプリケーションをサポートする協定。 しかしながら、そのようなアプリケーションは、E.164でなくてまたENUMではありません、通常、PBXの数がどちらかの一部であると考えられる内部の拡大よりもっと多くのもの。

Klensin                      Informational                      [Page 3]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[3ページ]のRFC3245歴史と文脈

3. Why .ARPA was selected as the top level domain for ENUM

3. .ARPAがENUMのためのトップ・レベル・ドメインとして選定された理由

3.1. Introduction

3.1. 序論

   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作業部会の熟考と決定に関する基礎的な情報を提供するためにIETFによってSG2に提供されたシリーズの1つです。 この特定のメモはENUM DNS木が.ARPAトップ・レベル・ドメインを使用するだろうというIETFの決定を扱います。

3.2. IAB Statement on Infrastructure Domain and Subdomains

3.2. インフラストラクチャドメインとサブドメインに関するIAB声明

   (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アドレス逆マッピングドメインです。 このドメインは初期のアルパネット変遷戦略の一部としてホストテーブル命名から「コネaddr.arpa」に置かれました(RFCの881 http://www.ietf.org/rfc/ のrfc0881.txtを見てください)。 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サーバのプレースメントに関する適切な注意、および始めへの管理清潔に単一領域で新社会資本サブドメインの場所を見つけることによってこの状況を合理化するのを支払って、それへの既存のものを移行するのに支払うために、一般的なインターネットの安定性の利益のためにはそれがあります。 このために「アルパネット」のための略語から頭文字語まで「アドレスとルート設定パラメタ領域」に再指定された私たちのオリジナルのインフラストラクチャドメイン「アルパ」に合うのが最も良いように見えます。

3.3. Infrastructure subdomains

3.3. インフラストラクチャサブドメイン

   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

私たちにインフラストラクチャ目的のためのパラメタに使用されるできるだけわずかなDNSゾーンしかないなら、一般に、DNSのために良い安定性を確実にするのは操作上、簡単です。 今日、新社会資本ドメインは人工であることが、他のドメインでわたることにされるのであるということであったARPAと古い課題に入れられたARPAです。 現在ARPAがコネaddr.arpa(IPv4アドレスの逆のマッピングのための)、ip6.arpaに使用される、(

Klensin                      Informational                      [Page 4]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[4ページ]のRFC3245歴史と文脈

   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.

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として別々のドメインに保存されるかもしれません。 ICANNプロセス(1年以上かかるかもしれない)を通して作成できるだけであって、どれがあいにく不必要に作成されるだろうかはDNS木を平らにします。例えば、.URI、.UNI、.IPV6、新しいTLD、容易に作成された新しいサブドメイン(セカンドレベルドメイン)がある1TLDを持っているのははるかに簡単です、各パラメタあたり1つ。(その結果、ARPAにE.164番号を保存するのは当然でした。

3.4. The ARPA domain (derived from RFC 3172, September 2001)

3.4. ARPAドメイン(RFC3172、2001年9月から、引き出されます)

   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.

「アルパ」ドメインは、元々、以前にアルパネットで標準であるHost Tablesから変遷メカニズムを提供するためにDNSの初期の展開の一部と書き立てられました。 また、IPv4アドレスがまた以前にHost Tableメカニズムを使用することで扱われたマッピング(「マッピングを逆にする」)を命名するように永久的なホームを提供するのも使用されていました。 アイキャン(ICANN)と提携して、インターネット・アーキテクチャ委員会(IAB)は現在、「アルパ」というTop Level Domain(TLD)名を管理するのに責任があります。 このアレンジメントはRFC3172のAppendix Aに記録されます。 このドメイン名はIPアドレスの逆のマッピングの名前階層構造の根をドメイン名に提供します。 より一般に、制限された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に記録された手順によると、そのようないくつかの追加や変化があるでしょう。 [RFC3172について言及します] このドメインは「インフラストラクチャドメイン」と呼ばれます、役割がインターネットの操作インフラストラクチャをサポートすることであるので。 同じ方法で使用されないように、他のジェネリックTop Level Domainsが一般的に使用されるように特に、「アルパ」ドメインはあります(例えば、ホストを任命するために)。

   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[RFC2860]に関してIABとICANNの間のMoUに関する諸条件におけるIANAによって実行されるものとします。

Klensin                      Informational                      [Page 5]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[5ページ]のRFC3245歴史と文脈

3.5. Assignment of the .ARPA top level domain

3.5. .ARPAトップ・レベル・ドメインの課題

   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.

RFC3172の付録Aに記録される米国商務省(ICANNがある発注書の権威の下における芝居)が指示した2000年4月28日に、IABの指導の下に制限されたaとして.ARPA TLDを操作するICANNはインターネットインフラストラクチャアプリケーションにドメインを使用します。

3.6. Name Server Requirements for .ARPA (from RFC 3172)

3.6. .ARPAのためのネームサーバ要件(RFC3172からの)

   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.

「アルパ」ドメインは、それぞれの深くより入れ子にされたインフラストラクチャ名の母体名のサーバの場所を見つけるのに必要であるいくつかの操作上のドメインにかかる複数の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.

「アルパ」ドメインの効率的で正しい操作が、ルートサーバーのための操作上の要件が「アルパ」サーバの操作上の要件に適用されることに十分批判的であると考えられます。 ルートサーバーの操作上の要件に適用するのでRFC2870に述べられたすべての操作上の要件が「アルパ」サーバの操作に適用されるものとします。 また、ルートサーバーの操作と関連したRFC2870へのどんな改正も「アルパ」サーバの操作に適用されるものとします。

   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.

または、「ルートゾーンに、正式のサーバの多く、(」 . 」 ゾーン) また、現在、「アルパ」ゾーンに正式であるとして機能してください。 RFC2870に述べられるように、このアレンジメントは将来、変化しそうです。

3.7. Summary: ENUM use of .ARPA

3.7. 概要: .ARPAのENUM使用

   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

ARPAドメインはインフラストラクチャとパラメタ使用のための都合のよいTLDです。 ENUM構造は、単一領域下位木(別々の貢献を見てください、COM2-11)に置かれるべきであり、重要なインターネット基盤に発展すると予想されて、したがって、そこに置かれるべきです。 この決定はICANNとIETFの間のMOUと米国政府からICANNまでの指示で容易にされます。(ICANNはそのドメインのIAB指揮に備えます)。 米国国防総省代理店の名前への何らかの混乱にもかかわらず、DARPA、これらの用途はそうです。

Klensin                      Informational                      [Page 6]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[6ページ]のRFC3245歴史と文脈

   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.

インフラストラクチャ目的(初めは、階層的なDNSがいつまで作成されたかがアルパネットの古い平坦な名前空間を取り替える)のためのものであるARPAドメインの歴史的な用途のすべてと一致する: ドメインはどんな内部の、または、特定のDARPA目的にも決して使用されませんでした。 複数のインフラストラクチャドメインにおける潜在的困難を認識して、インターネット・アーキテクチャ委員会は、2000年5月にすべての新社会資本情報がARPAドメインに格納されることであると結論を下しました、そして、既存のインフラストラクチャ下位木は可能であるとしてそこに移動しました。 http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt は追加文脈をこれらの決定に提供します。

   The ENUM Working Group decided to follow that recommendation.

ENUM作業部会は、その推薦に続くと決めました。

4. The selection of an operator for E164.ARPA

4. E164.ARPAのオペレータの選択

4.1. Introduction

4.1. 序論

   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作業部会の熟考と決定に関する基礎的な情報を提供するためにIETFによってSG2に提供されたシリーズの1つです。 この特定の貢献はE164.ARPAドメインにIETFのオペレータの選択を記述します。

4.2. Name server operator requirements

4.2. ネームサーバオペレータ要件

   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.

RFC2870( http://www.ietf.org/rfc/rfc2780.txt )は操作DNSルートサーバーのための要件について説明します。 重要なDNSベースのインフラストラクチャサービスは、それらのサーバが同じレベルのルートサーバーが必要とする信頼性とセキュリティに関する注意で操作されるのを必要とします。 さらに、E164.ARPAなどのインフラストラクチャサービスにおいて、いくつかの追加要件がIABによって重要であると感じられました。 彼らの彼らの両方の関連手法、公正、および公平でINのADDR.ARPAやE164.ARPAなどのコアサービスを運用する組織を、DNSサーバの信頼できる操作の歴史を持っていて、高く尊敬されて、知っていなければなりません。 さらに、何らかの妥当な入会手続料がコストを取り戻すために請求されても、搾取的な振舞いによってどんな誘因も取り除くためにそのようなインフラストラクチャドメインを運用する組織が非営利的で公共にサービス志向のものであるに違いないと感じられたIABはそれがよる動機、例えばデータベースの記録の数を利益に基礎づけました。 また、IABは、彼らが、より一般に、IABとIETFと共に働いているという経験で必要であるときに、政府と共に働いているという良くて(大規模)の経験と1がある組織が欲しかったと感じました。

Klensin                      Informational                      [Page 7]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[7ページ]のRFC3245歴史と文脈

4.3. Evaluating possible operators

4.3. 可能なオペレータを評価します。

   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と共に働く長い歴史がありました。

4.4. Selecting a particular operator

4.4. 特定のオペレータを選びます。

   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サーバの彼らのいくらか大きい経験と、そして、中立法的な管轄におけるそれらの位置に基づきます。

4.5. Country administration of cc subdomains

4.5. ccサブドメインの国の運営

   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.

もちろん、国名略号に関連しているサブドメインが登録と操作のためにいったん関連国か付番プランのための適切に指定された実体に割り当てられると、そのサブドメインの管理は完全にNational Matterです、IAB/IETF、E164.ARPA登録かITUから予期されたかかわり合いなしで。

5. Procedures to be followed by RIPE NCC

5. RIPE NCCによって続かれるべき手順

   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ウェブサイトに掲示されるでしょう。

6. References

6. 参照

6.1. Normative references

6.1. 引用規格

   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.

[RFC2860]の大工、B.、ベイカー、F.、およびM.ロバーツ、「インターネットの技術的な仕事に関する了解覚書は数の権威を割り当てました」、RFC2860、2000年6月。

   [RFC 2870] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
              Name Server Operational Requirements", BCP 40, RFC 2870,
              June 2000.

[RFC2870] ブッシュ、R.、Karrenberg(D.、Kosters、M.、およびR.Plzak)は「ネームサーバの操作上の要件を根づきます」、BCP40、RFC2870、2000年6月。

Klensin                      Informational                      [Page 8]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[8ページ]のRFC3245歴史と文脈

   [RFC 2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
              2000.

[RFC2916] Faltstromと、P.と、「E.164番号とDNS」、RFC2916、9月2000日

   [RFC 3172] Huston, G., Ed., "Management Guidelines & Operational
              Requirements for the Address and Routing Parameter Area
              Domain ('arpa')", BCP 52, RFC 3172, September 2001.

[RFC3172] ヒューストンと、G.(エド)と、「アドレスとルート設定パラメタ領域ドメインのための管理ガイドラインと操作上の要件('アルパ')」、BCP52、RFC3172(2001年9月)

7. Security Considerations

7. セキュリティ問題

   This document provides information only and raises no new security
   issues.  The security issues associated with the underlying protocols
   are described in RFC 2916.

このドキュメントは、情報だけを提供して、どんな新しい安全保障問題も提起しません。 基本的なプロトコルに関連している安全保障問題はRFC2916で説明されます。

8. IANA Considerations

8. IANA問題

   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によって既に実行された動作と部分的な説明に関する記録を含みます。

9.  Authors' Addresses

9. 作者のアドレス

   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スティーブデアリング出撃フロイドジェフヒューストンジョンKlensinヘニングSchulzrinneを走らせました。

   Scott Bradner
   EMail: sob@harvard.edu

スコットブラドナーEMail: sob@harvard.edu

   Patrik Faltstrom
   EMail: paf@cisco.com

パトリクFaltstromはメールします: paf@cisco.com

Klensin                      Informational                      [Page 9]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002

2002年の決定行進の操作上のENUMのKlensinの情報[9ページ]のRFC3245歴史と文脈

10. Full Copyright Statement

10. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2002)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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ページ]