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).
著作権（C）IETFトラスト（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.
ENUMのドメイン名は、しっかりと基礎をなすE.164番号に連結されています。 ENUMドメイン名の登録者が対応するE.164番号の譲受人と同じであるか否かを検証するプロセスは、一般的に「検証」と呼ばれています。このドキュメントは、検証要件とENUMの検証インフラストラクチャの高レベルのアーキテクチャについて説明します。
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]ユニフォームリソース識別子（URIの）にE.164番号[2]から参照するために使用する[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.
「普通の」ドメイン名は、通常、関連する登録データは、所有権の完全なソースで先着順、に割り当てられます。しかし、ENUMドメイン名は、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間の整合性を維持することがENUMの実装における主な関心事の一つであり、「裁判」は商用の実装の前に理由の多くの場合、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番号とENUMドメイン名の間にこの関係を維持するためには、登録プロセスは、以下の要件がENUM団の全体の寿命の間に満たされていることを確認する必要があります。
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 ENUMドメイン名が割り当てられたE.164番号または登録プロセス自体の間に割り当てられたそれぞれのE.164番号のいずれかに相当します。
o The corresponding E.164 number is within a number range approved to be used with ENUM.
O対応するE.164番号は、ENUMで使用することを承認番号の範囲内です。
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 ENUMドメイン名の登録は、対応するE.164番号の譲受人によって認可され;即ち、ENUMドメイン名の登録を要求しているエンティティは、対応するE.164番号の譲受人自体又は前記譲受人に代わって登録を要求する権限をエンティティのいずれかです。
o The "Registrant" (see Section 3.3) of the ENUM domain is identical to the Assignee of the corresponding E.164 number.
「登録者」O ENUMドメインの対応するE.164番号の譲受人と同一である（3.3節参照）。
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ドメイン名の代表団が取り消されていないことを行わなければなりません。言い換えれば、ENUMドメイン名の状態が状態と対応するE.164番号の所有権の変更を追跡することが保証されなければなりません。上記の要件は、まだ一般に「定期的な検証」または「再検証」と呼ばれて満たされていることを確認する定期的なプロセス。
The above requirements are usually part of the local registration policy issued by the authorities in charge of ENUM administration.
上記の要件は、通常、ENUMの管理を担当する当局によって発行されたローカルの登録ポリシーの一部です。
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）：上記の要件は、プロビジョニングモデル、検証関連のタスクを実行するエンティティにおける新しい役割の導入につながります。この文書の基礎となる一般的なENUMプロビジョニングモデルは、図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：ENUMモデル
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として機能します。 164番号の割り当てのための2つの主要なバリエーションがあります。
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.
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).
These two variants of E.164 number assignment are depicted in Figure 2:
E.164番号の割り当てのこれら二つの変異体は、図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はデータベース（s）はその加入者番号のサービス情報を含むを運営しています。一般的に、そのような他のCSPとして認可エンティティが課金およびバリデーション（ノーマーケティング、データマイニング、またはそれ以外）の限定された目的のために契約の下で、リアルタイムで、これらのデータベースにアクセスすることを許可されています。これらのデータベースは、ENUMの検証目的のために再使用することができます。
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行為（S）かどうかをローカルポリシーに依存します。
However, it is unlikely that all CSPs acting as NAEs will participate in ENUM validation.
しかし、NAESとして動作するすべてのCSPは、ENUMの検証に参加することはほとんどありません。
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登録者は、エンドユーザー、ENUMドメイン名の「所有者」である人または組織です。
The Registrant usually has control over his ENUM domain name(s) and its DNS zone content.
登録者は通常、自分のENUMドメイン名（複数可）とその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）ENUMドメイン名の登録者は、対応する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.
多くの場合、それはまた、ENUMドメイン名の登録を要求しているエンティティは、対応する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ドメイン代表団のマスターデータベースを操作し、e164.arpaの下で、関連するゾーンの権限ネームサーバを実行します。常に特定のゾーンのための単一の権威ENUMレジストリが存在する必要があります。
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レジストラは、典型的には、拡張可能なプロビジョニングプロトコル（EPP）のようなプロトコルを介して、レジストリと相互作用することにより、登録者に代わってENUMドメイン委任を実行する[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.
いずれの場合においても、レジストラはENUMドメイン名の登録に先立っ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）は、[1]権限ポインタ（NAPTR）リソースレコード（RR）エントリネーミングENUMを含むENUMのDNSゾーンのネームサーバを動作させます。
In most cases, the Registry delegates the ENUM DNS zones to the nameservers at the DNS-SP.
多くの場合、レジストリに委譲DNS-SPでのネームサーバへのENUM DNSゾーン。
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）は、登録者のためのサービスを提供しています。このサービスは、他の人がその顧客のURIを発見することができるように、サービスプロバイダが顧客のためにENUMのゾーンを移入することにより、IP電話サービス、である可能性があります。
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.潜在的な登録者は、レジストラに近づき、ENUMドメイン名を注文します。
2. The Registrar chooses a cooperating Validation Entity, and requests an initial validation for the ENUM domain name ordered.
2. Registrarは協力検証エンティティを選択し、注文したENUMドメイン名の初期検証を要求します。
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.検証プロセスは、レジストリとレジストラの規定ENUMドメイン名に成功した場合。ローカルレジストリポリシーに応じて、検証に関連する情報は、この登録に伴ってレジストリに提供することができます。
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:
ほとんどの場合、ローカルポリシーの義務の有効期限は、成功した検証に課せられたことにまでさかのぼります。 ENUMの代表団は、この有効期限を超えて保持する場合は、定期的な検証が実行されなければなりません。典型的な再検証のワークフローは、次の手順を実行します。
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.ケースで再検証が失敗した、ENUMドメインの代表団は、レジストリで明示的に相互作用するかのどちらか、一時停止しなければなりません。ローカルポリシーは、有効期限の猶予期間を与えることができます。
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の名前空間との整合性が保証されます。検証要件を満たすことができない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は、対応するENUMドメイン名と一緒に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：ENUMの登録と一緒に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適用の検証に関する追加情報が含まれている可能性がレジストリにENUM登録要求を送信します。 （4）ITSPは、E.164番号の割り当てとなりました譲受人と登録者である顧客へのENUM登録に関する確認を送信します。
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.
このより複雑なシナリオでは、ENUMのプロビジョニングモデルのすべての役割が異なるエンティティによって実行されていることを前提としています。 （セクション5.1）前の例とは対照的に、我々は、登録するENUMドメイン名が既に割り当てられてE.164番号と当該NAEザは、加入者データベースへのアクセスを提供VEに基づいていると仮定する。私たちは、さらにインクルードは、譲受人の意思を確認するために、VEの要件があることを前提としています。検証プロセスは、したがって、譲受人を接触させることを含みます。
Figure 4 shows the interactions needed for the ENUM domain name provisioning process:
図4は、ENUMドメイン名プロビジョニング・プロセスに必要な相互作用を示しています。
+----------+
| 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：番号の割り当てエンティティ金：検証エンティティ
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番号を割り当てます。この割り当ては、譲受人が共通の電話サービスに加入時に、例えば、ENUMドメイン名登録の前に長い間行われている可能性があります。 （2）譲受人は、彼の選択のレジストラに対応するENUMドメイン名を注文します。 （3）独立に登録要求の検証はVE。 （4）ザは、E.164番号の譲受人は、ENUMドメイン名の登録者に対応することを検証するために、接点NAEの加入者データベースをVE。 （5）NAE加入者データベースの結果が肯定的です。 （6）ザ・はENUMドメイン名として登録されるE.164番号にコールバックを実行し、VE、認証のための規定を作り、彼の意思を確認するために、譲受人を要求します。 （7）譲受人が確認され、インクルードは、この確認書類をVE。 （8）ザ・返品にレジストラへの肯定的な回答をVE。答えはように、このような有効期限、適用される検証方法として、検証プロセスに関するいくつかの追加情報が含まれている、とあります。 （9）最後に、レジストラは、レジストリにENUM登録要求を送信します。検証プロセスに関する追加情報は、登録要求とともに送信される可能性があります。
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番号のENUMドメインの制御を持っている状況は、高詐欺の可能性を課します。銀行のENUMドメインを超える不正な制御は、例えば、電話バンキングアプリケーションへの攻撃「中間者」を使用することができます。このような攻撃の事例は、全体として、ENUMの信用を傷つける可能性があります。
Implementing high-quality validation processes is therefore crucial to any ENUM deployment and should receive high attention.
高品質の検証プロセスを実装する任意のENUMを展開することが重要であり、高い注目を受けるべきです。
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.
ローレンス・コンロイ、マイケルHaberler、テッドハーディー、オトマールレンドル、ハラMowafy、マルセル・パロディ、ジョンピーターソン、ペンPfautz、パトリックシェーファー、そしてリチャード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.及び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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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]ホレンベック、S.、 "拡張プロビジョニングプロトコル（EPP）"、RFC 3730、2004年3月。
Authors' Addresses
著者のアドレス
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
アレクサンダーMayrhoferは1010年オーストリアウィーンGmbH社カールス1/9をenum.at
Phone: +43 1 5056416 34 EMail: alexander.mayrhofer@enum.at URI: http://www.enum.at/
電話：+43 1 5056416 34電子メール：URI alexander.mayrhofer@enum.at：http://www.enum.at/
Bernie Hoeneisen Switch Neumuehlequai 6 CH-8001 Zuerich Switzerland
バーニーHoeneisenはNeumuehlequai 6 CH-8001チューリッヒスイスの切り替え
Phone: +41 44 268 1515 EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org URI: http://www.switch.ch/
電話：+41 44 268 1515 Eメール：hoeneisen@switch.ch、b.hoeneisen@ieee.org URI：http://www.switch.ch/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。