[要約] RFC 5067は、インフラストラクチャENUMの要件に関するガイドラインであり、ENUMを使用して電話番号とインターネットリソースを関連付けるための要件を定義しています。その目的は、インフラストラクチャENUMの実装と展開を支援し、通信インフラストラクチャの効率と柔軟性を向上させることです。
Network Working Group S. Lind
Request for Comments: 5067 AT&T Labs
Category: Informational P. Pfautz
AT&T
November 2007
Infrastructure ENUM Requirements
インフラストラクチャENUMの要件
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Abstract
概要
This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.)
このドキュメントでは、「インフラストラクチャ」または「キャリア」のENUM（E.164番号マッピング）の要件を提供します。これは、RFC 3761テクノロジーを使用してE.164番号アドレスサービスのネットワークの相互接続を容易にすることとして定義されています。 Voice over IP。）
Table of Contents
目次
1. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Infrastructure ENUM . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Infrastructure ENUM is defined as the use of the technology in RFC 3761 [1] by the carrier-of-record (as defined below) for a specific E.164 number [2] to publish the mapping of the E.164 number into a URI [3] that identifies a specific point of interconnection to that service provider's network. It is separate from any URIs that the end user, who registers their E.164 number, may wish to associate with that E.164 number.
インフラストラクチャENUMは、特定のE.164番号[2]のレコードキャリアによって、RFC 3761 [1]のテクノロジーの使用として定義され、E.164番号のマッピングをそのサービスプロバイダーのネットワークへの相互接続の特定のポイントを識別するURI [3]。これは、E.164番号を登録するエンドユーザーがそのE.164番号との関連付けを希望する可能性があるURIとは異なります。
"Infrastructure ENUM" is distinguished from "End User ENUM", defined in RFC3761 [1], in which the entity or person having the right to use a number has the sole discretion about the content of the associated domain and thus the zone content. From a domain registration perspective, the end user number assignee is thus the registrant. Within the infrastructure ENUM namespace, we use the term "carrier-of-record" for the entity having discretion over the domain and zone content and acting as the registrant. The "carrier-of-record" is:
「インフラストラクチャENUM」は、RFC3761 [1]で定義されている「エンドユーザーENUM」とは区別されます。この場合、番号を使用する権利を持つエンティティまたは個人は、関連付けられたドメインのコンテンツ、したがってゾーンのコンテンツについて単独の裁量権を持ちます。したがって、ドメイン登録の観点からは、エンドユーザー番号の割り当て先は登録者です。インフラストラクチャENUMネームスペース内では、ドメインとゾーンのコンテンツに対して裁量権を持ち、登録者として機能するエンティティに対して「記録保持者」という用語を使用します。 「記録保持者」は次のとおりです。
o The Service Provider to which the E.164 number was allocated for end user assignment, whether by the National Regulatory Authority (NRA) or the International Telecommunication Union (ITU), for instance, a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878) or,
o E.164番号がエンドユーザーの割り当てに割り当てられたサービスプロバイダー。たとえば、National Regulatory Authority（NRA）またはInternational Telecommunication Union（ITU）のいずれかによるもので、たとえば、「International Networks」（+ 882）または「Universal Personal Telecommunications（UPT）」（+ 878）または、
o if the number is ported, the service provider to which the number was ported, or
o 番号が移植された場合、番号が移植されたサービスプロバイダー、または
o where numbers are assigned directly to end users, the service provider that the end user number assignee has chosen to provide a Public Switched Telephone Network/Public Land Mobile Network (PSTN/ PLMN) point-of-interconnect for the number.
o 番号がエンドユーザーに直接割り当てられる場合、エンドユーザー番号割り当て先が番号に公衆電話交換網/公衆陸上移動網（PSTN / PLMN）の相互接続ポイントを提供するために選択したサービスプロバイダー。
It is understood that the definition of carrier-of-record within a given jurisdiction is subject to modification by national authorities.
所与の管轄区域内の記録保持者の定義は、国内当局による修正の対象となることが理解されている。
Voice service providers use E.164 numbers currently as their main naming and routing vehicle. Infrastructure ENUM in e164.arpa or another publicly available tree allows service providers to link Internet-based resources such as URIs to E.164 numbers. This allows service providers, in addition to interconnecting via the PSTN/PLMN (or exclusively), to peer via IP-based protocols. Service providers may announce all E.164 numbers or number ranges they host, regardless of whether the final end user device is on the Internet, on IP-based open or closed Next Generation Networks (NGNs), or on the PSTN or PLMN, provided that an access point of some type to the destination service provider's network is available on the Internet. There is also no guarantee that the originating service provider querying infrastructure ENUM is able to access the ingress network element of the destination provider's network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of providers, resolving the final destination network within the shared network.
音声サービスプロバイダーは、現在、主要な命名およびルーティング手段としてE.164番号を使用しています。 e164.arpaまたは他の公に利用可能なツリーのインフラストラクチャENUMにより、サービスプロバイダーは、URIなどのインターネットベースのリソースをE.164番号にリンクできます。これにより、サービスプロバイダーは、PSTN / PLMN（または排他的）を介した相互接続に加えて、IPベースのプロトコルを介してピアリングできます。サービスプロバイダーは、最終エンドユーザーデバイスがインターネット上にあるか、IPベースのオープンまたはクローズド次世代ネットワーク（NGN）上にあるか、提供されているPSTNまたはPLMN上にあるかに関係なく、ホストするすべてのE.164番号または番号範囲をアナウンスすることができます。宛先サービスプロバイダーのネットワークへのあるタイプのアクセスポイントがインターネット上で利用できること。また、元のサービスプロバイダーのクエリインフラストラクチャENUMが宛先プロバイダーのネットワークの入口ネットワーク要素にアクセスできるという保証はありません。認証を必要とする追加のピアリングおよびアカウンティング契約が必要になる場合があります。提供されるアクセスは、プロバイダーのグループの共有ネットワークへのアクセスでもよく、共有ネットワーク内の最終宛先ネットワークを解決します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC2119 [4].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC2119 [4]で説明されているように解釈されます。
1. Infrastructure ENUM SHALL provide a means for a provider to populate DNS resource records (RRs) for the E.164 numbering resources for which it is the carrier-of-record in a single common publicly accessible namespace. The single common namespace ultimately designated may or may not be the same as that designated for End User ENUM (e164.arpa.) The Fully-Qualified Domain Name (FQDN) in the resulting resource records will not necessarily belong to or identify the carrier-of-record.
1. インフラストラクチャENUMは、プロバイダーがE.164ナンバリングリソースのDNSリソースレコード（RR）にデータを入力する手段を提供する必要があります。これは、単一の共通のパブリックにアクセス可能な名前空間のレコードキャリアです。最終的に指定された単一の共通名前空間は、エンドユーザーENUM（e164.arpa。）に指定されたものと同じであってもなくてもかまいません。結果のリソースレコードの完全修飾ドメイン名（FQDN）は、必ずしもキャリアに属したり、キャリアを識別したりしません。レコードの。
2. Queries of infrastructure ENUM fully qualified domain names MUST return a result, even if the result is Refused (RCODE = 5). Queries must not be rejected without response, e.g., based on access control lists.
2. インフラストラクチャのクエリENUM完全修飾ドメイン名は、結果が拒否された（RCODE = 5）場合でも結果を返す必要があります。クエリは、アクセス制御リストなどに基づいて、応答なしで拒否されてはなりません。
3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery to the carrier-of-record of communications addressed to the E.164 number.
3. インフラストラクチャENUMは、E.164番号を宛先とする通信の記録担体への配信のための相互接続ポイントを識別できるURIを提供するRRをサポートする必要があります（SHALL）。
4. Infrastructure ENUM SHOULD be able to support an Internet Registry Information Service (IRIS) [5] capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. Determination of what information, if any, shall be available which parties for geographic numbers is a national matter.
4. インフラストラクチャENUMは、インターネットレジストリ情報サービス（IRIS）[5]機能をサポートできる必要があります。これにより、資格のある関係者は、E.164番号付けリソースと対応する記録担体に関する情報を取得できます。地理的番号のどの関係者が国の問題であるか、もしあれば、どの情報が利用可能であるかの決定。
5. Implementation of infrastructure ENUM MUST NOT restrict the ability of an end user, in a competitive environment, to choose a Registrar and/or name server provider for End User ENUM registrations.
5. インフラストラクチャENUMの実装は、競争環境において、エンドユーザーENUM登録用のレジストラまたはネームサーバープロバイダーを選択するエンドユーザーの能力を制限してはなりません。
6. The domain name chosen for infrastructure ENUM and any parent domains MUST be hosted on name servers that have performance characteristics and supporting infrastructure that is comparable to those deployed for the Internet root name servers. Those name servers for infrastructure ENUM should be configured and operated according to the guidelines described in [6].
6. インフラストラクチャENUMおよびすべての親ドメイン用に選択されたドメイン名は、インターネットルートネームサーバーにデプロイされたものと同等のパフォーマンス特性とサポートインフラストラクチャを備えたネームサーバーでホストする必要があります。インフラストラクチャENUMのこれらのネームサーバーは、[6]で説明されているガイドラインに従って構成および運用する必要があります。
7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information over which an end user has no control. It should, for example, support mechanisms to prevent discovery of unlisted numbers by comparison of ENUM registrations against directory listings, or inadvertent disclosure of user identity.
7.インフラストラクチャENUMは、エンドユーザーが制御できない情報の可視性に関するすべての合理的なプライバシーの懸念を満たす必要があります。たとえば、ENUM登録とディレクトリリストの比較によるリストされていない番号の検出、またはユーザーIDの不注意による開示を防ぐメカニズムをサポートする必要があります。
8. Proposed implementations of infrastructure ENUM SHOULD:
8. インフラストラクチャの提案された実装ENUM SHOULD：
A. Minimize changes required to existing requirements that are part of RFC 3761.
A. RFC 3761の一部である既存の要件に必要な変更を最小限に抑えます。
B. Work with open as well as closed numbering plans.
B.オープンおよびクローズの番号計画を処理します。
C. Not require additional functionality of resolvers at large though they may require additional functionality in service provider resolvers that would make use of infrastructure ENUM.
C.インフラストラクチャENUMを利用するサービスプロバイダーリゾルバーに追加機能が必要になる場合がありますが、リゾルバー全体の追加機能は必要ありません。
D. Minimize the number of lookups required to obtain as many NAPTR (Naming Authority Pointer) records (end user and infrastructure) as possible.
D.可能な限り多くのNAPTR（Naming Authority Pointer）レコード（エンドユーザーとインフラストラクチャ）を取得するために必要なルックアップの数を最小限に抑えます。
E. Minimize knowledge of the numbering plan required of resolvers making use of Infrastructure ENUM.
E. Infrastructure ENUMを使用するリゾルバーに必要な番号計画の知識を最小限に抑えます。
F. Maximize synergies with End User ENUM.
F.エンドユーザーENUMとの相乗効果を最大化します。
G. Support interworking with private ENUM trees. (In this context, a private ENUM tree is one that is not under e164.arpa or whatever namespace is chosen for infrastructure ENUM but uses instead a privately held domain.)
G.プライベートENUMツリーとの相互作用をサポートします。 （このコンテキストでは、プライベートENUMツリーは、e164.arpaの下ではなく、インフラストラクチャENUMに選択された名前空間ではなく、プライベートに保持されたドメインを使用するツリーです。）
Existing security considerations for ENUM (detailed in [1]) still apply. Since infrastructure ENUM involves carriers where RFC 3761 mainly considered indviduals, implementations meeting these requirements SHOULD reconsider the RFC 3761 security model given this difference in actors concerned. Note that some registration validation issues concerning End User ENUM may not apply to infrastructure ENUM. Where the Tier 1 registry is able to identify the provider serving a number, e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required.
ENUMの既存のセキュリティに関する考慮事項（[1]で詳述）は引き続き適用されます。インフラストラクチャENUMには、RFC 3761が主に個人を考慮しているキャリアが含まれているため、これらの要件を満たす実装では、関係するアクタにこの違いがある場合、RFC 3761セキュリティモデルを再検討する必要があります。エンドユーザーENUMに関する一部の登録検証の問題は、インフラストラクチャENUMには適用されない場合があることに注意してください。番号ブロック割り当てや番号ポータビリティの業界データに基づいて、Tier 1レジストリが番号を提供するプロバイダーを識別できる場合、登録はより簡単に自動化でき、個別のレジストラは不要です。
Some parties have expressed concern that an infrastructure ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if providers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the provider's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, provider registration of a number in ENUM provides no more information about the status of a number than could be obtained by dialing it.
一部の関係者は、インフラストラクチャENUMがENUMでの登録に基づいて非公開または非公開の番号を識別できるようにすることで、エンドユーザーのプライバシーを侵害する可能性があると懸念を表明しています。これは、プロバイダーが割り当てられた（割り当てられた番号ではなく）番号のすべてを登録する場合に回避できます。割り当てられていない番号をプロビジョニングして、割り当てられた番号と同じ方法でプロバイダーのネットワークにルーティングし、割り当てられていないことを示す必要があります。このようにして、プロバイダーがENUMに番号を登録しても、番号をダイヤルすることで取得できる情報以上の情報は提供されません。
Implementers should take care to avoid inadvertent disclosure of user identities, for example, in the URIs returned in response to infrastructure ENUM queries.
実装者は、たとえばインフラストラクチャのENUMクエリに応答して返されるURIで、ユーザーIDが不注意に開示されないように注意する必要があります。
This document includes no actions to be taken by IANA. The architecture ultimately chosen to meet the requirements may require IANA actions.
このドキュメントには、IANAが実行するアクションは含まれていません。要件を満たすために最終的に選択されたアーキテクチャには、IANAアクションが必要になる場合があります。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom、P。およびM. Mealling、「The E.164 to Uniform Resource Identifiers（URI）Dynamic Delegation Discovery System（DDDS）Application（ENUM）」、RFC 3761、2004年4月。
[2] International Telecommunication Union-Telecommunication Standardization Sector, "The International Public Telecommunication Numbering Plan", Recommendation E.164", February 2005.
[2] 国際電気通信連合通信標準化部門、「国際公衆電気通信番号計画」、勧告E.164」、2005年2月。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[5] ニュートンA.およびM.サンズ、「IRIS：The Internet Registry Information Service（IRIS）Core Protocol」、RFC 3981、2005年1月。
[6] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
[6] Bush、R.、Karrenberg、D.、Kosters、M.、and R. Plzak、 "Root Name Server Operational Requirements"、BCP 40、RFC 2870、June 2000。
Authors' Addresses
著者のアドレス
Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA
Steven Lind AT＆T Labs 180 Park Ave Florham Park、NJ 07932-0971 USA
EMail: sdlind@att.com
Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA
Penn Pfautz AT＆T 200 S. Laurel Ave Middletown、NJ 07748 USA
EMail: ppfautz@att.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。