[要約] RFC 4725は、ENUM（電話番号とインターネットリソースの対応付け）の検証アーキテクチャに関するものであり、ENUMデータの信頼性と正確性を確保するためのガイドラインを提供しています。このRFCの目的は、ENUMデータの検証プロセスを改善し、信頼性の高いENUMサービスの提供を促進することです。
Network Working Group A. Mayrhofer
Request for Comments: 4725 enum.at
Category: Informational B. Hoeneisen
Switch
November 2006
ENUM Validation Architecture
列挙検証アーキテクチャ
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 IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure.
列挙ドメイン名は、基礎となるE.164番号と密接に結びついています。列挙ドメイン名の登録者が対応するE.164番号の譲受人と同一であるかどうかを確認するプロセスは、一般に「検証」と呼ばれます。このドキュメントは、検証要件と、列挙検証インフラストラクチャ用の高レベルアーキテクチャについて説明しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements ....................................................3
3. ENUM Provisioning Model and Roles ...............................4
3.1. Number Assignment Entity (NAE) .............................5
3.2. Assignee ...................................................7
3.3. Registrant .................................................7
3.4. Validation Entity (VE) .....................................7
3.5. Registry ...................................................8
3.6. Registrar ..................................................8
3.7. Domain Name System Service Provider (DNS-SP) ...............8
3.8. Application Service Provider (ASP) .........................8
4. Validation Process Assumptions ..................................9
4.1. Workflow ...................................................9
4.2. Trust Relations ...........................................10
4.3. Data Flow and Format ......................................11
5. Example Scenarios ..............................................11
5.1. E.164 Number Assignment along with ENUM Registration ......11
5.2. Fully Disjoint Roles ......................................13
6. Security Considerations ........................................14
6.1. Fraud Prevention ..........................................14
6.2. Assignee Data .............................................14
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
E.164 Number Mapping (ENUM) [1] uses the Domain Name System (DNS) [4] to refer from E.164 numbers [2] to Uniform Resource Identifiers (URIs) [3]. E.164 numbers are mapped to domain names through means described further in RFC 3761 [1].
E.164番号マッピング（ENUM）[1]は、ドメイン名システム（DNS）[4]を使用して、E.164番号[2]から均一なリソース識別子（URIS）[3]を参照します。E.164数は、RFC 3761 [1]でさらに説明されている手段を通じてドメイン名にマッピングされます。
"Ordinary" domain names are usually allocated on a first-come-first-served basis, where the associated registration data is the complete source of ownership. However, ENUM domain names are linked to E.164 numbers, and thus intrinsically tied to the status and the "Assignee" (defined in Section 3.2) of the corresponding E.164 number.
「通常の」ドメイン名は、通常、関連する登録データが完全な所有権のソースである先着順で割り当てられます。ただし、列挙ドメイン名はE.164の数値にリンクされているため、対応するE.164番号のステータスと「譲受人」（セクション3.2で定義）に本質的に結び付けられています。
Preserving integrity between ENUM and E.164 is one of the main concerns in ENUM implementations, and often one of the reasons why "trials" precede commercial implementations.
EnumとE.164の間の完全性を維持することは、列挙の実装における主な関心事の1つであり、多くの場合、「試行」が商業実装に先行する理由の1つです。
To maintain this relationship between E.164 numbers and ENUM domain names, registration processes must ensure that the following requirements are fulfilled during the entire lifetime of an ENUM delegation:
e.164数と列挙ドメイン名の間のこの関係を維持するには、登録プロセスが列挙の全寿命の間に次の要件が満たされることを保証する必要があります。
o The ENUM domain name corresponds either to an assigned E.164 number or to a respective E.164 number that is assigned during the registration process itself.
o 列挙ドメイン名は、割り当てられたE.164番号または登録プロセス中に割り当てられたそれぞれのE.164番号のいずれかに対応します。
o The corresponding E.164 number is within a number range approved to be used with ENUM.
o 対応するE.164数は、列挙で使用されることが承認された数値範囲内です。
o The registration of the ENUM domain name is authorized by the Assignee of the corresponding E.164 number; i.e., the entity requesting the registration of an ENUM domain name is either the Assignee of the corresponding E.164 number itself or an entity authorized to request registration on behalf of said Assignee.
o
o The "Registrant" (see Section 3.3) of the ENUM domain is identical to the Assignee of the corresponding E.164 number.
o Enumドメインの「登録者」（セクション3.3を参照）は、対応するE.164番号の譲受人と同一です。
The process of verifying the above requirements during registration is commonly called "initial validation". In addition to this one-time validation process, provisions must be made that ENUM domain name delegations are revoked when the above requirements are no longer met. In other words, it must be ensured that the state of the ENUM domain name tracks any change in state and ownership of the corresponding E.164 number. The regular process of checking that the above requirements are still satisfied is commonly called "recurring validation" or "revalidation".
登録中に上記の要件を確認するプロセスは、一般に「初期検証」と呼ばれます。この1回限りの検証プロセスに加えて、上記の要件が満たされなくなったときにドメイン名委任が取り消されるという規定を作成する必要があります。言い換えれば、enumドメイン名の状態が、州の変更と対応するe.164数の所有権を追跡することを保証する必要があります。上記の要件がまだ満たされていることを確認する定期的なプロセスは、一般に「繰り返し検証」または「再検証」と呼ばれます。
The above requirements are usually part of the local registration policy issued by the authorities in charge of ENUM administration.
上記の要件は通常、列挙管理を担当する当局が発行したローカル登録ポリシーの一部です。
The above requirements lead to the introduction of a new role in the provisioning model, an entity performing validation related tasks: The Validation Entity (VE). A typical ENUM provisioning model, on which this document is based, is depicted in Figure 1:
上記の要件は、プロビジョニングモデルに新しい役割を導入することにつながります。これは、検証関連のタスクである検証エンティティ（VE）を実行するエンティティです。このドキュメントの基礎となる典型的な列挙プロビジョニングモデルを図1に示します。
+----------+
.| Registry |- -- -- -- -- -- --
. +----------+ |
. |
. | | Trust
DNS Delegation | Relation
. | Registration |
. |
. | |
+--------+ +-----------+ +----+
| DNS-SP |-- -- -- -- --| Registrar |----------------| VE |
+--------+ Nameservers +-----------+ Validation +----+
: | / |
: | E.164 Number
: | ENUM Assignment
: NAPTR | Management _ Verification
: | / |
: | _
: | / |
+-----+ ENUM enabled +------------+ E.164 Number +-----+
| ASP |- -- -- -- -- --| Assignee = |-- -- -- -- --| NAE |
+-----+ Service | Registrant | Assignment +-----+
+------------+
Legend:
伝説：
ASP: Application Service Provider DNS-SP: Domain Name System Service Provider NAE: Number Assignment Entity VE: Validation Entity
ASP：アプリケーションサービスプロバイダーDNS-SP：ドメイン名システムサービスプロバイダーNAE：番号割り当てエンティティVE：検証エンティティ
Figure 1: ENUM Model
図1：列挙モデル
These different roles are described further below. Note that an entity can act in more than one of these roles simultaneously; for example, the Registrar, the DNS-SP, and the ASP roles could be performed by a single company.
これらの異なる役割については、さらに以下に説明します。エンティティは、これらの役割の複数で同時に行動できることに注意してください。たとえば、レジストラ、DNS-SP、およびASPの役割は、単一の会社によって実行される可能性があります。
A Number Assignment Entity (NAE) assigns E.164 numbers to end-users. Often, but not always, the Communication Service Provider (CSP) of the end-user (Assignee) acts as NAE. There are two main variants for E.164 number assignments:
番号割り当てエンティティ（NAE）は、E.164番号をエンドユーザーに割り当てます。多くの場合、常にではありませんが、エンドユーザー（譲受人）の通信サービスプロバイダー（CSP）がNAEとして機能します。E.164の割り当てには2つの主要なバリエーションがあります。
1. Indirect assignment:
1. 間接的な割り当て：
The National Number Plan Administrator (NNPA) assigns ranges of E.164 numbers to CSPs. Out of these ranges, the CSPs assign numbers (or number blocks) to their customers (end-users, Assignees). In this variant, the CSPs perform the role of the NAE.
National Number Plan Administrator（NNPA）は、CSPにE.164番号の範囲を割り当てます。これらの範囲のうち、CSPは顧客（エンドユーザー、譲受人）に番号（または数字ブロック）を割り当てます。このバリアントでは、CSPはNAEの役割を実行します。
2. Direct assignment:
2. 直接割り当て：
In certain cases, an NNPA assigns E.164 numbers directly to Assignees (end-users), and therefore the NNPA acts as NAE in this variant. Typically, this concerns the assignment of special purpose numbers (e.g., premium rate).
特定の場合、NNPAはe.164番号を譲受人（エンドユーザー）に直接割り当てるため、NNPAはこのバリアントのNAEとして機能します。通常、これは特別な目的の数値（プレミアムレートなど）の割り当てに関係しています。
These two variants of E.164 number assignment are depicted in Figure 2:
E.164番号の割り当てのこれら2つのバリアントを図2に示します。
+--------------------------------------------+
| International Telecommunication Union (ITU)|
+--------------------------------------------+
|
Country codes (e.g., +44)
|
v
+-------------------------------------------+
| National Number Plan Administrator (NNPA) |------------+
+-------------------------------------------+ |
| |
Number Ranges |
(e.g., +44 20 7946 xxxx) |
| |
v |
+--------------------------------------+ |
| Communication Service Provider (CSP) | |
+--------------------------------------+ |
| |
| Single Numbers
Either Single Numbers (e.g., +44 909 8790879)
or Number Blocks (Variant 2)
(e.g., +44 20 7946 0999, +44 20 7946 07xx) |
(Variant 1) |
| |
v |
+----------+ |
| Assignee |<------------------------------+
+----------+
Figure 2: E.164 Number Assignment
図2：E.164番号割り当て
(Note: Numbers above are "drama" numbers and are shown for illustrative purpose only. Assignment polices for similar "real" numbers in country code +44 may differ.)
（注：上記の数字は「ドラマ」番号であり、説明のみで表示されます。カントリーコード44の同様の「実際の」番号の割り当てポリシーは異なる場合があります。）
As the Assignee (subscriber) data associated with an E.164 number is the primary source of number assignment information, the NAE usually holds the authoritative information required to confirm the assignment.
E.164番号に関連付けられた譲受人（サブスクライバー）データが数値割り当て情報の主要なソースであるため、NAEは通常、割り当てを確認するために必要な信頼できる情報を保持します。
A CSP that acts as NAE (indirect assignment) may therefore easily assert the E.164 number assignment for its subscribers. In some cases, such CSPs operate database(s) containing service information on their subscribers' numbers. Typically, authorized entities such as other CSPs are allowed to access these databases, in real-time, under contract for the limited purposes of billing and validation (no marketing, data mining, or otherwise). These databases could be re-used for ENUM validation purposes.
したがって、NAE（間接的な割り当て）として機能するCSPは、加入者のE.164番号の割り当てを簡単に主張する場合があります。場合によっては、このようなCSPは、サブスクライバーの番号に関するサービス情報を含むデータベースを操作します。通常、他のCSPなどの認定されたエンティティは、これらのデータベースにリアルタイムで、請求と検証の限られた目的で契約の下でアクセスすることが許可されています（マーケティング、データマイニングなど）。これらのデータベースは、列挙検証の目的で再利用できます。
Number portability transactions may lead to situations where the CSP that originally acted as NAE no longer has authoritative assignment information about ported numbers. Whether the old and/or the new CSP act(s) as NAE for ported numbers depends on local policy.
数の携帯性トランザクションは、元々NAEとして機能していたCSPに、移植された数値に関する権威ある割り当て情報がなくなった状況につながる可能性があります。移植された数字のNAEとしての古いCSP法および/または新しいCSP法がローカルポリシーに依存するかどうか。
However, it is unlikely that all CSPs acting as NAEs will participate in ENUM validation.
ただし、NAESとして機能するすべてのCSPが列挙検証に参加する可能性は低いです。
The person or organization to whom a NAE assigns an E.164 number is called Assignee of this number. For the scope of this document, the terms Assignee, subscriber, and number-holder are used equivalently.
NAEがE.164番号を割り当てる個人または組織は、この番号の譲受人と呼ばれます。このドキュメントの範囲では、譲受人、サブスクライバー、および番号保有者という用語が同等に使用されます。
The Assignee has the "right to use" on the assigned E.164 number.
譲受人は、割り当てられたE.164番号に「使用する権利」を持っています。
The ENUM Registrant is the end-user, the person or organization who is the "holder" of the ENUM domain name.
列挙登録者は、エンドユーザー、enumドメイン名の「ホルダー」である個人または組織です。
The Registrant usually has control over his ENUM domain name(s) and its DNS zone content.
登録者は通常、列挙ドメイン名とそのDNSゾーンコンテンツを制御します。
The Validation Entity (VE) verifies whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number.
検証エンティティ（VE）は、列挙ドメイン名の登録者が対応するE.164番号の譲受人と同一であるかどうかを確認します。
Often it also verifies that the entity requesting the registration of an ENUM domain name is either the Assignee of the corresponding E.164 number itself or an entity authorized to request registration on behalf of said Assignee.
多くの場合、列挙ドメイン名の登録を要求するエンティティは、対応するE.164番号自体の譲受人またはその譲受人に代わって登録を要求する権限を与えられたエンティティのいずれかであることを確認します。
This role may be performed by several parties and is not necessarily limited to a single entity.
この役割は、いくつかの当事者によって実行される場合があり、必ずしも単一のエンティティに限定されるわけではありません。
The actual validation methods applied may vary depending on, e.g., the particular party, available data sources, Assignee's choice, and regulatory requirements. Validation methods are out of scope of this document.
適用される実際の検証方法は、たとえば、特定の当事者、利用可能なデータソース、譲受人の選択、規制要件によって異なる場合があります。検証方法は、このドキュメントの範囲外です。
The ENUM Registry operates the master database of ENUM domain delegations and runs the authoritative nameservers for the relevant zone under e164.arpa. There must always be a single authoritative ENUM Registry for a specific zone.
Enumレジストリは、Enum Domain Dedegationsのマスターデータベースを操作し、E164.ARPAに基づく関連ゾーンの権威ある名前アーバーを実行します。特定のゾーンには常に単一の権威ある列挙レジストリが必要です。
An ENUM Registrar performs ENUM domain delegations on behalf of a Registrant by interacting with the Registry, typically through a protocol like Extensible Provisioning Protocol (EPP) [5]. This role is similar to the one that Registrars fulfill in the "ordinary" domain name registration world.
Enum Registrarは、レジストリとの対話により、通常は拡張可能なプロビジョニングプロトコル（EPP）[5]を使用して、レジストリと対話することにより、登録者に代わって列挙ドメイン代表団を実行します。この役割は、レジストラが「通常の」ドメイン名登録の世界で満たすものと似ています。
The Registrar may well not be the same entity as the CSP of the Registrant. Therefore, a Registrar may lack authoritative number-assignment information. If the Registrar and the CSP are the same entity (or has a source of authoritative data), the Registrar could perform the role of the VE itself.
レジストラは、登録者のCSPと同じエンティティではない場合があります。したがって、レジストラには権威ある番号割り当て情報がない場合があります。レジストラとCSPが同じエンティティである（または権威あるデータのソースがある）場合、レジストラはVE自体の役割を実行できます。
In any case, a Registrar has to ensure a proper validation through a VE prior to the registration of an ENUM domain name.
いずれにせよ、レジストラは、列挙ドメイン名の登録前にVEを通じて適切な検証を確保する必要があります。
The Domain Name System Service Provider (DNS-SP) operates the nameservers for the ENUM DNS zones, which contain the ENUM Naming Authority Pointer (NAPTR) Resource Record (RR) entries [1].
ドメイン名システムサービスプロバイダー（DNS-SP）は、Enum DNSゾーンのネームサーバーを操作します。これには、Enum Naming Authority Pointer（NAPTR）リソースレコード（RR）エントリが含まれています[1]。
In most cases, the Registry delegates the ENUM DNS zones to the nameservers at the DNS-SP.
ほとんどの場合、レジストリは列挙DNSゾーンをDNS-SPの名前サーバーに委任します。
The DNS-SP is usually not involved in the validation process.
DNS-SPは通常、検証プロセスには関与していません。
The Application Service Provider (ASP) operates a service for the Registrant. This service could be an IP telephony service, whereby the service provider populates the ENUM zone for its customers so that others can discover that customer's URI.
アプリケーションサービスプロバイダー（ASP）は、登録者向けのサービスを運営しています。このサービスはIPテレフォニーサービスである可能性があります。これにより、サービスプロバイダーは顧客の列挙ゾーンに登録され、他の人が顧客のURIを発見できるようになります。
Usually, the ASP is not involved in the validation process.
通常、ASPは検証プロセスに関与していません。
The prototypical initial validation workflow using the above roles and definitions consists of the following steps:
上記の役割と定義を使用したプロトタイプの初期検証ワークフローは、次の手順で構成されています。
1. A potential Registrant approaches a Registrar, and orders an ENUM domain name.
1. 潜在的な登録者がレジストラに近づき、列挙ドメイン名を注文します。
2. The Registrar chooses a cooperating Validation Entity, and requests an initial validation for the ENUM domain name ordered.
2. レジストラは、協力的な検証エンティティを選択し、注文した列挙ドメイン名の初期検証を要求します。
3. The Validation Entity performs the actual validation, which could require interaction with the Assignee/Registrant.
3. 検証エンティティは実際の検証を実行します。これには、譲受人/登録者とのやり取りが必要になる可能性があります。
4. The Validation Entity indicates the result of the initial validation to the Registrar.
4. 検証エンティティは、レジストラへの最初の検証の結果を示します。
5. If the validation process was successful, the Registrar provisions the ENUM domain name with the Registry. Depending on the local Registry policy, validation-related information may be provided to the Registry along with this registration.
5. 検証プロセスが成功した場合、レジストラはレジストリに列挙ドメイン名を規定します。ローカルレジストリポリシーに応じて、この登録とともに検証関連の情報がレジストリに提供される場合があります。
In most cases, local policy mandates expiration dates to be imposed on successful validations. If the ENUM delegation is to be kept beyond this expiration date, recurring validation has to be performed. A typical revalidation workflow involves the following steps:
ほとんどの場合、現地のポリシーは、有効期限が検証の成功に課されることを義務付けています。列挙委任がこの有効期限を超えて保持される場合、繰り返し検証を実行する必要があります。典型的な再検証ワークフローには、次の手順が含まれます。
1. In good time before the current validation expires, the Registrar requests the Validation Entity to revalidate the domain name in question.
1. 現在の検証が期限切れになる前の良い時期に、レジストラは検証エンティティに問題のドメイン名を再確認するよう要求します。
2. The Validation Entity verifies if the delegation requirements are still met. It may use information acquired during the initial validation or associated to the registration data.
2. 委任要件がまだ満たされている場合、検証エンティティは検証されます。最初の検証中に取得した情報を使用するか、登録データに関連付けられている場合があります。
3. The Validation Entity indicates the result of the recurring validation to the Registrar.
3. 検証エンティティは、レジストラへの繰り返し検証の結果を示します。
4. In case the revalidation has been successful, the domain delegation may persist. Local Registry policy may require updating domain name registration data, especially in case the Registry keeps validation-related expiry information.
4. 再検証が成功した場合、ドメイン代表団が持続する可能性があります。ローカルレジストリポリシーでは、特にレジストリが検証関連の有効性情報を保持している場合に備えて、ドメイン名登録データの更新が必要になる場合があります。
5. In case the revalidation has failed, the ENUM domain delegation must be suspended, either by explicit interaction with the Registry or -- if the Registry keeps validation-related information -- automatically when the current validation expires. Local policy may grant a grace period on the expiration date.
5. 再検証が失敗した場合、レジストリとの明示的な相互作用のいずれかによって、またはレジストリが検証関連の情報を保持している場合、現在の検証が期限切れになったときに自動的に導入する必要があります。現地のポリシーは、有効期限に猶予期間を付与する場合があります。
This workflow ensures the integrity between the E.164 and ENUM namespaces. ENUM domain delegations that fail to meet the validation requirements are suspended from the DNS.
このワークフローにより、E.164とenumの名前空間の間の完全性が保証されます。検証要件を満たさない列挙ドメイン代表団は、DNSから停止されます。
The above validation workflow implies the following trust relations:
上記の検証ワークフローは、次の信頼関係を意味します。
o The Registry trusts the Validation Entities to enforce the local validation policy.
o レジストリは、検証エンティティがローカル検証ポリシーを実施することを信頼しています。
o The Registrars trust the Validation Entities to properly perform validation based on the Registrar's request.
o レジストラは、検証エンティティがレジストラの要求に基づいて検証を適切に実行することを信頼しています。
o Depending on the amount of validation data provided to the Registry additional trust relations may be necessary. Three cases can be differentiated:
o レジストリに提供される検証データの量に応じて、追加の信頼関係が必要になる場合があります。3つのケースを区別できます。
* The Registry receives no validation-related data: The Registry needs to trust the Registrar that validation has been performed, and the result was positive. In addition, the Registry needs to trust the Registrar that it will properly remove delegations for which revalidation fails.
* レジストリは検証関連のデータを受け取りません。レジストリは、検証が実行されたことをレジストラに信頼する必要があり、結果は肯定的でした。さらに、レジストリは、再検証が失敗する代表団を適切に削除することをレジストラに信頼する必要があります。
* The Registry receives validation-related data including expiry date, but there are no means of checking its authenticity: The Registry needs to trust the Registrar that the validation data provided is authentic.
* レジストリは有効期限を含む検証関連のデータを受信しますが、その信頼性をチェックする手段はありません。レジストリは、提供された検証データが本物であるレジストラを信頼する必要があります。
* The Registry receives validation-related data including expiry date and means to verify its authenticity (e.g., a cryptographic signature issued by the VE): No additional trust relations are necessary.
* レジストリは、有効期限を含む検証関連のデータを受信し、その信頼性を検証するための手段（たとえば、VEが発行した暗号化署名）：追加の信頼関係は必要ありません。
The validation process requires the following regular data flows (Note: data flows not directly related to validation are out of scope of this document):
検証プロセスでは、次の通常のデータフローが必要です（注：検証に直接関係しないデータフローは、このドキュメントの範囲外です）：
o Registrars communicate with Validation Entities to initiate, modify, or cancel validation requests. Validation Entities act upon validation requests and provide validation results to Registrars. Since Registrars could potentially communicate with several Validation Entities, and Validation Entities could provide services to several Registrars (worst case: full mesh), a standardized protocol and data format should be used in this data flow.
o レジストラは、検証エンティティと通信して、検証要求を開始、変更、またはキャンセルします。検証エンティティは、検証要求に基づいて行動し、レジストラに検証結果を提供します。レジストラはいくつかの検証エンティティと通信する可能性があり、検証エンティティはいくつかのレジストラにサービスを提供できるため（最悪の場合：フルメッシュ）、このデータフローで標準化されたプロトコルとデータ形式を使用する必要があります。
o If the local Registry policy mandates that validation-related information is to be stored along with delegation records, a validation-related data flow between Registry and Registrar is required. Since the registration itself already requires communication between those entities, validation-related information in a standardized data format should be embedded into the existing Registry-Registrar protocol data flow.
o ローカルレジストリポリシーが、検証関連の情報を委任記録とともに保存することを義務付けている場合、レジストラとレジストラの間の検証関連のデータフローが必要です。登録自体はすでにそれらのエンティティ間の通信を必要としているため、標準化されたデータ形式の検証関連情報は、既存のレジストリ登録プロトコルデータフローに埋め込む必要があります。
o Validation Entities may need to communicate with Assignees to perform validation. A Validation Entity may choose to perform all communication with the Assignee via the requesting Registrar rather than contacting the Assignee by itself. Since the actual communication form and process are expected to greatly vary, it does not make sense to specify any data formats or processes for this purpose.
o 検証エンティティは、検証を実行するために譲受人と通信する必要がある場合があります。検証エンティティは、譲受人に単独で連絡するのではなく、要求レジストラを介して譲受人とのすべての通信を実行することを選択できます。実際の通信フォームとプロセスは大きく異なると予想されるため、この目的のためにデータ形式またはプロセスを指定することは意味がありません。
In this simple scenario, we assume that the roles of the Registrar, the VE, and the NAE are performed by the same entity, e.g., an Internet Telephony Service Provider (ITSP). This ITSP is a CSP that was assigned number ranges by the NNPA. Out of these ranges he assigns numbers to his customers (Assignees) to provide those with communication services. The ITSP chooses to assign an E.164 number together with the corresponding ENUM domain name. Therefore, it can perform the validation simply by reference to its subscriber database.
この単純なシナリオでは、レジストラ、VE、およびNAEの役割が同じエンティティ、たとえばインターネットテレフォニーサービスプロバイダー（ITSP）によって実行されると想定しています。このITSPは、NNPAによって番号の範囲が割り当てられたCSPです。これらの範囲のうち、彼は顧客（譲受人）に番号を割り当てて、人々に通信サービスを提供します。ITSPは、対応する列挙ドメイン名とともにE.164番号を割り当てることを選択します。したがって、サブスクライバーデータベースを参照するだけで検証を実行できます。
Figure 3 shows the external interactions needed for the ENUM domain name provisioning process:
図3は、enumドメイン名プロセスプロセスに必要な外部インタラクションを示しています。
+----------+
| Registry |
+----------+
^
|
|(3)
|
+--------------------------------------+
| |
| ITSP |
| +-----------+ +----+ |
| | Registrar | | VE | |
| +-----------+ (2) +----+ |
| |
+--------------------------+ |
^ | |
| | |
|(1) | |
| | |
| | |
+------------+ (4) | +-----+ |
| Assignee = |<----------| | NAE | |
| Registrant | | +-----+ |
------------- | |
+-----------+
Legend:
伝説：
ITSP: Internet Telephony Service Provider NAE: Number Assignment Entity VE: Validation Entity
ITSP：インターネットテレフォニーサービスプロバイダーNAE：番号割り当てエンティティVE：検証エンティティ
Figure 3: E.164 Number Assignment along with ENUM Registration
図3：E.164登録とともに番号の割り当て
(1) The ITSP receives an order for ENUM services. (2) The ITSP assigns a free E.164 number and performs the validation at the same time. (3) The ITSP sends an ENUM registration request to the Registry, which might contain additional information about the validation applied. (4) The ITSP sends a confirmation about the E.164 number assignment and the ENUM registration to its customer, who is now Assignee and Registrant.
(1) ITSPは、Enumサービスの注文を受け取ります。（2）ITSPは無料のE.164番号を割り当て、同時に検証を実行します。（3）ITSPは、列挙登録要求をレジストリに送信します。これには、適用される検証に関する追加情報が含まれる場合があります。（4）ITSPは、現在譲受人であり登録者である顧客にE.164番号の割り当てと列挙登録に関する確認を送信します。
This scenario is quite close to "ordinary" domain name registrations.
このシナリオは、「通常の」ドメイン名登録に非常に近いものです。
In this more complex scenario, we assume that all roles of the ENUM provisioning model are performed by different entities. In contrast with the previous example (in Section 5.1), we assume that the ENUM domain name to be registered is based on an already assigned E.164 number and the NAE in question provides the VE with access to the subscriber database. We further assume that there is a requirement for the VE to verify the intention of the Assignee. The validation process therefore involves also contacting the Assignee.
このより複雑なシナリオでは、列挙プロビジョニングモデルのすべての役割が異なるエンティティによって実行されると想定しています。前の例（セクション5.1）とは対照的に、登録する列挙ドメイン名は既に割り当てられているE.164番号に基づいており、問題のNAEはサブスクライバーデータベースへのアクセスを提供します。さらに、VEが譲受人の意図を検証する要件があると仮定します。したがって、検証プロセスには、譲受人にも連絡します。
Figure 4 shows the interactions needed for the ENUM domain name provisioning process:
図4は、列挙ドメイン名のプロビジョニングプロセスに必要な相互作用を示しています。
+----------+
| Registry |
+----------+
^
|
|(9)
|
|
| (3)
+-----------+ ---------->+----+
| Registrar |<---------- | VE |
+-----------+ (8) > +----+
^ / / ^ |
| / / | |
| (7)/ / | |
|(2) / / | |
| / / (5)| |
| / / | |
| / / | |
| / /(6) | |
| / / | |(4)
| / / | |
| / / | |
+------------+< | v
| Assignee = | +-----+
| Registrant |<---------- | NAE |
+------------+ (1) +-----+
Legend:
伝説：
NAE: Number Assignment Entity VE: Validation Entity
NAE：番号割り当てエンティティVE：検証エンティティ
Figure 4: Fully Disjoint Roles
図4：完全にばらばらの役割
(1) The NAE assigns an E.164 number. This assignment could have been done long before the ENUM domain name registration, e.g., at the time when the Assignee subscribed to a common telephony service. (2) The Assignee orders the corresponding ENUM domain name at a Registrar of his choice. (3) The Registrar requests validation at an independent VE. (4) The VE contacts the subscriber database of the NAE, to verify that the Assignee of the E.164 number corresponds to the Registrant of the ENUM domain name. (5) The result of the NAE subscriber database is positive. (6) The VE performs a call-back to the E.164 number to be registered as ENUM domain name, makes provisions for authentication, and asks the Assignee to confirm his intention. (7) The Assignee confirms and the VE documents this confirmation. (8) The VE returns a positive answer to the Registrar. The answer might contain some additional information about the validation process, such as expiration date, validation method applied, and so on. (9) Finally, the Registrar sends an ENUM registration request to the Registry. Additional information about the validation process might be sent along with the registration request.
(1) NAEはE.164番号を割り当てます。この割り当ては、列挙ドメイン名登録のずっと前に、たとえば、譲受人が共通のテレフォニーサービスに購読していたときに行われた可能性があります。（2）譲受人は、選択したレジストラで対応するenumドメイン名を注文します。（3）レジストラは、独立したVEで検証を要求します。（4）VEは、NAEのサブスクライバーデータベースに連絡し、E.164番号の譲受人がEnumドメイン名の登録者に対応していることを確認します。（5）NAEサブスクライバーデータベースの結果は肯定的です。（6）VEは、列挙ドメイン名として登録されるE.164番号へのコールバックを実行し、認証の規定を作成し、譲受人に意図を確認するよう求めます。（7）譲受人が確認し、VEはこの確認を文書化します。（8）VEはレジストラに対する肯定的な答えを返します。答えには、有効期限、適用された検証方法など、検証プロセスに関するいくつかの追加情報が含まれる場合があります。（9）最後に、レジストラは列挙登録要求をレジストリに送信します。検証プロセスに関する追加情報は、登録要求とともに送信される場合があります。
Situations where an entity has control over the ENUM domain of a third party's E.164 number impose high fraud potential. Unauthorized control over an ENUM domain of a bank could, for example, be used for "man in the middle" attacks on telephone banking applications. Cases of such attacks could discredit ENUM as a whole.
エンティティが第三者のE.164数の列挙ドメインを制御している状況は、高い詐欺の可能性を課します。たとえば、銀行の列挙ドメインに対する不正制御は、電話銀行のアプリケーションに対する「中央の人間」攻撃に使用する可能性があります。そのような攻撃の場合は、列挙全体として信用を傷つける可能性があります。
Implementing high-quality validation processes is therefore crucial to any ENUM deployment and should receive high attention.
したがって、高品質の検証プロセスを実装することは、列挙展開にとって重要であり、高い注目を集める必要があります。
When handling Assignee data, privacy and discretion issues must be considered. Implementations transporting assignee data over the Internet must use authenticated and encrypted transport protocols. Local registration/validation policy and agreements should clearly limit usage of Assignee data.
譲受人のデータを処理する場合、プライバシーと裁量の問題を考慮する必要があります。インターネット上の譲受人データを輸送する実装は、認証された暗号化されたトランスポートプロトコルを使用する必要があります。ローカル登録/検証ポリシーと契約は、譲受人データの使用法を明確に制限する必要があります。
The authors would like to thank the following persons for their valuable suggestions and contributions: Lawrence Conroy, Michael Haberler, Ted Hardie, Otmar Lendl, Hala Mowafy, Marcel Parodi, Jon Peterson, Penn Pfautz, Patrik Schaefer, and Richard Stastny.
著者は、Lawrence Conroy、Michael Haberler、Ted Hardie、Otmar Lendl、Hala Mowafy、Marcel Parodi、Jon Peterson、Penn Pfautz、Patrik Schaefer、Richard Stastnyなど、貴重な提案と貢献について、次の人に感謝したいと思います。
[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。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[2] ITU-T, "The international public telecommunication numbering plan", Recommendation E.164 (02/05), Feb 2005.
[2] ITU-T、「国際公開通信番号計画」、推奨事項E.164（02/05）、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、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[4] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[4] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[5] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[5] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）」、RFC 3730、2004年3月。
Authors' Addresses
著者のアドレス
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
Alexander Mayrhofer Enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Bernie Hoeneisen Switch Neumuehlequai 6 CH-8001 Zuerich Switzerland
Bernie Hoeneisen Switch Neumuehlequai 6 CH-8001 Zuerich Switzerland
Phone: +41 44 268 1515
EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。