RFC4725 日本語訳
4725 ENUM Validation Architecture. A. Mayrhofer, B. Hoeneisen. November 2006. (Format: TXT=33216 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Mayrhofer
Request for Comments: 4725 enum.at
Category: Informational B. Hoeneisen
Switch
November 2006
コメントを求めるワーキンググループA.マイルホーファーの要求をネットワークでつないでください: 4725enum.at Category: 情報のB.Hoeneisenスイッチ2006年11月
ENUM Validation Architecture
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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ドメイン名のRegistrantが対応するE.164番号のAssigneeと同じであるかどうか確かめる過程は一般的に「合法化」と呼ばれます。 このドキュメントはENUM合法化インフラストラクチャのために合法化要件とハイレベルの構造について説明します。
Mayrhofer & Hoeneisen Informational [Page 1] RFC 4725 ENUM Validation Architecture November 2006
[1ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
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
1. 序論…3 2. 要件…3 3. モデルと役割に食糧を供給するENUM…4 3.1. 数の課題実体(NAE)…5 3.2. 指定代理人…7 3.3. 記入者…7 3.4. 合法化実体(VE)…7 3.5. 登録…8 3.6. 記録係…8 3.7. ドメインネームシステムサービスプロバイダー(DNS-SP)…8 3.8. アプリケーション・サービスプロバイダー(ASP)…8 4. 合法化過程仮定…9 4.1. 作業フロー…9 4.2. 関係を信じてください…10 4.3. データフローと形式…11 5. 例のシナリオ…11 5.1. ENUM登録に伴うE.164数の課題…11 5.2. 役割を完全にばらばらにならせてください…13 6. セキュリティ問題…14 6.1. 詐欺の防止…14 6.2. 指定代理人データ…14 7. 承認…15 8. 参照…15 8.1. 標準の参照…15 8.2. 有益な参照…15
Mayrhofer & Hoeneisen Informational [Page 2] RFC 4725 ENUM Validation Architecture November 2006
[2ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
1. Introduction
1. 序論
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数のMapping(ENUM)[1]は、E.164番号[2]からUniform Resource Identifier(URI)[3]まで参照するのにドメインネームシステム(DNS)[4]を使用します。 E.164番号はRFC3761[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.
「普通」が通常、ドメイン名がaに割り当てられる最初に来る、-、最初に、関連登録データが所有権の完全な源であるところで基礎に役立ちました。 しかしながら、ENUMドメイン名は数であることの、そして、このようにして本質的に状態に結ばれたE.164と対応するE.164番号の「指定代理人」(セクション3.2では、定義される)にリンクされます。
2. Requirements
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つと、しばしば「トライアル」が商業実現に先行する理由の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 ENUMと共に使用されるために承認された数の範囲の中に対応する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 ENUMドメイン名の登録は対応するE.164番号のAssigneeによって認可されます。 すなわち、ENUMドメイン名の登録を要求する実体は、対応するE.164番号自体のAssigneeか前述のAssigneeを代表して登録を要求するのが認可された実体のどちらかです。
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番号のAssigneeと同じです。
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
登録の間、上記の要件について確かめる過程は一般的に「初期の合法化」と呼ばれます。 この1つの時間合法化の過程に加えて、条項は上記の必要条件がもう満たされないとき、作られていて、そのENUMドメイン名代表団が取り消されるということであるに違いありません。 言い換えれば、ENUMドメイン名の州が状態と所有権におけるどんな変化も追うのを確実にしなければなりません。
Mayrhofer & Hoeneisen Informational [Page 3] RFC 4725 ENUM Validation Architecture November 2006
[3ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
corresponding E.164 number. The regular process of checking that the above requirements are still satisfied is commonly called "recurring validation" or "revalidation".
対応するE.164番号。 上記の要件がまだ満たされているのをチェックする通常の過程は、一般的に呼ばれた「再発合法化」か"再合法化"です。
The above requirements are usually part of the local registration policy issued by the authorities in charge of ENUM administration.
通常、上記の要件はENUM管理を担当して当局によって発行されたローカルの登録方針の一部です。
3. ENUM Provisioning Model and Roles
3. モデルと役割に食糧を供給する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 +-----+
+------------+
+----------+ . | 登録|- -- -- -- -- -- -- . +----------+ | . | . | | 信用DNS代表団| 関係。| 登録| . | . | | +--------+ +-----------+ +----+ | DNS-SP|-- -- -- -- --| 記録係|----------------| VE| +--------+ ネームサーバ+-----------+ 合法化+----+ : | / | : | E.164番号: | ENUM課題: NAPTR| 管理_検証: | / | : | _ : | / | +-----+ ENUMは+を可能にしました。------------+ E.164番号+-----+ | ASP|- -- -- -- -- --| 指定代理人=|-- -- -- -- --| NAE| +-----+ サービス| 記入者| 課題+-----+ +------------+
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モデル
Mayrhofer & Hoeneisen Informational [Page 4] RFC 4725 ENUM Validation Architecture November 2006
[4ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
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.
これらの異なる役割は以下でさらに説明されます。 実体が同時にこれらの役割の1つ以上で行動できることに注意してください。 例えば、単一の会社はRegistrar、DNS-SP、およびASPの役割を実行できました。
3.1. Number Assignment Entity (NAE)
3.1. 数の課題実体(NAE)
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:
Number Assignment Entity(NAE)はエンドユーザへの数をE.164に割り当てます。 いつもでない、しかし、しばしば、エンドユーザ(指定代理人)のCommunication Service Provider(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)はE.164番号の範囲をCSPsに割り当てます。 これらの範囲から、CSPsは数(または、数のブロック)を彼らの顧客(エンドユーザ、Assignees)に割り当てます。 この異形では、CSPsは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は直接Assignees(エンドユーザ)への数をE.164に割り当てます、そして、したがって、NNPAはNAEとしてこの異形で機能します。 通常、これは専用数(例えば、保険料率)の課題に関係があります。
Mayrhofer & Hoeneisen Informational [Page 5] RFC 4725 ENUM Validation Architecture November 2006
[5ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
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 |<------------------------------+
+----------+
+--------------------------------------------+ | 国際電気通信連合(ITU)| +--------------------------------------------+ | 国名略号(例えば、+44)| +に対して-------------------------------------------+ | 国家の数のプラン管理者(NNPA)|------------+ +-------------------------------------------+ | | | 数は及びます。| (+44 例えば、20 7946xxxx) | | | v| +--------------------------------------+ | | コミュニケーションサービスプロバイダー(CSP)| | +--------------------------------------+ | | | | どちらのシングルも付番するただ一つの数、(+44 例えば、909の8790879か)番号が(+44 +44 例えば、20 7946 0999、20 7946 07xx)を妨げます(異形2)。| (異形1) | | | v| +----------+ | | 指定代理人| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +----------+
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番号に関連しているAssignee(加入者)データが数の課題情報の一次資料であるので、通常、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
したがって、NAE(間接的な課題)として機能するCSPは加入者のために容易にE.164数の課題について断言するかもしれません。 いくつかの場合、彼らの加入者の番号のサービス情報を含んでいて、そのようなCSPsはデータベースを操作します。 通常権限のある機関、そのようなもの
Mayrhofer & Hoeneisen Informational [Page 6] RFC 4725 ENUM Validation Architecture November 2006
[6ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
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.
他のCSPsが契約に基づきリアルタイムで(売り出していないか、データマイニングの、または、そうでない)で支払いと合法化の限られた目的のためにこれらのデータベースにアクセスできるとき。 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がもう移植された数の正式の課題情報を持っていない状況につながるかもしれません。 古いCSP、そして/または、新しいCSPが移植された数のためのNAEとして(s)を機能させるかどうかがローカルの方針によります。
However, it is unlikely that all CSPs acting as NAEs will participate in ENUM validation.
しかしながら、NAEsとして機能するすべてのCSPsがENUM合法化に参加するのは、ありそうもないです。
3.2. Assignee
3.2. 指定代理人
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番号を配属する人か組織がこの数のAssigneeと呼ばれます。 このドキュメントの範囲のために、用語Assignee、加入者、および数所有者は同等に使用されます。
The Assignee has the "right to use" on the assigned E.164 number.
Assigneeには、割り当てられたE.164番号の「まさしく使用」があります。
3.3. Registrant
3.3. 記入者
The ENUM Registrant is the end-user, the person or organization who is the "holder" of the ENUM domain name.
ENUM RegistrantはENUMドメイン名の「所有者」であるエンドユーザ、人または組織です。
The Registrant usually has control over his ENUM domain name(s) and its DNS zone content.
通常、Registrantは彼のENUMドメイン名とそのDNSゾーン内容を管理します。
3.4. Validation Entity (VE)
3.4. 合法化実体(VE)
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.
Validation Entity(VE)は、ENUMドメイン名のRegistrantが対応するE.164番号のAssigneeと同じであるかどうか確かめます。
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番号自体のAssigneeか前述のAssigneeを代表して登録を要求するのが認可された実体のどちらかであることを確かめます。
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.
合法化方法が当てはまった実際は、よりながら、異なるかもしれません。オンです、例えば、事項はパーティーへ行きます、利用可能なデータ送信端末、Assigneeの特選していて、規定の要件。 このドキュメントの範囲の外に合法化方法があります。
Mayrhofer & Hoeneisen Informational [Page 7] RFC 4725 ENUM Validation Architecture November 2006
[7ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
3.5. Registry
3.5. 登録
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 RegistryはENUMドメイン代表団に関するマスターデータベースを操作して、e164.arpaの下の関連ゾーンへ正式のネームサーバを走らせます。 特定のゾーンへの独身の正式のENUM Registryがいつもあるに違いありません。
3.6. Registrar
3.6. 記録係
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はRegistryと対話するのによるRegistrantを代表してENUMドメイン代表団を実行します、通常Extensible Provisioningプロトコル(EPP)[5]のようなプロトコルを通して。 この役割はRegistrarsが「普通」のドメイン名登録世界に実現させるものと同様です。
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.
RegistrarはたぶんRegistrantのCSPと同じ実体でないでしょう。 したがって、Registrarは正式の数の課題情報を欠くかもしれません。 RegistrarとCSPが同じ実体(または、信頼すべきデータの源を持っている)であるなら、RegistrarはVE自身の役割を実行するかもしれません。
In any case, a Registrar has to ensure a proper validation through a VE prior to the registration of an ENUM domain name.
どのような場合でも、RegistrarはENUMドメイン名の登録の前にVEを通して適切な合法化を確実にしなければなりません。
3.7. Domain Name System Service Provider (DNS-SP)
3.7. ドメインネームシステムサービスプロバイダー(DNS-SP)
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].
ドメインネームシステムService Provider(DNS-SP)はENUM DNSゾーンにネームサーバを操作します。(ゾーンはENUM Naming Authority Pointer(NAPTR)リソースRecord(RR)エントリー[1]を含みます)。
In most cases, the Registry delegates the ENUM DNS zones to the nameservers at the DNS-SP.
多くの場合、RegistryはENUM DNSゾーンをDNS-SPのネームサーバへ代表として派遣します。
The DNS-SP is usually not involved in the validation process.
通常、DNS-SPは合法化の過程にかかわりません。
3.8. Application Service Provider (ASP)
3.8. アプリケーション・サービスプロバイダー(ASP)
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.
Application Service Provider(ASP)はRegistrantのためにサービスを操作します。 このサービスはIP電話技術サービスであるかもしれません。(他のものがその顧客のURIを発見できて、そのサービスでサービスプロバイダーは顧客のためにENUMゾーンに居住します)。
Usually, the ASP is not involved in the validation process.
通常、ASPは合法化の過程にかかわりません。
Mayrhofer & Hoeneisen Informational [Page 8] RFC 4725 ENUM Validation Architecture November 2006
[8ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
4. Validation Process Assumptions
4. 合法化過程仮定
4.1. Workflow
4.1. 作業フロー
The prototypical initial validation workflow using the above roles and definitions consists of the following steps:
上の役割と定義を使用するprototypicalの初期の合法化作業フローは以下のステップから成ります:
1. A potential Registrant approaches a Registrar, and orders an ENUM
domain name.
1. 潜在的RegistrantはRegistrarにアプローチして、ENUMドメイン名を注文します。
2. The Registrar chooses a cooperating Validation Entity, and
requests an initial validation for the ENUM domain name ordered.
2. Registrarは協力Validation Entity、およびENUMドメイン名のための初期の合法化が注文した要求を選びます。
3. The Validation Entity performs the actual validation, which could
require interaction with the Assignee/Registrant.
3. Validation Entityは実際の合法化を実行します。(それは、Assignee/記入者との相互作用を必要とすることができました)。
4. The Validation Entity indicates the result of the initial
validation to the Registrar.
4. Validation Entityは初期の合法化の結果をRegistrarに示します。
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. 合法化であるなら、過程はうまくいって、Registrar条項はRegistryがあるENUMドメイン名です。 ローカルのRegistry方針によって、合法化関連の情報をこの登録に伴うRegistryに提供するかもしれません。
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. 現在の合法化が期限が切れる前にちょうどよい時に、Registrarは、問題のドメイン名を再有効にするようValidation Entityに要求します。
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. Validation Entityは、代表団必要条件がまだ満たされているかどうか確かめます。 それは初期の合法化の間、取得するか、または登録データに関連づける情報を使用するかもしれません。
3. The Validation Entity indicates the result of the recurring
validation to the Registrar.
3. Validation Entityは再発合法化の結果をRegistrarに示します。
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. 再合法化がうまくいったといけないので、ドメイン代表団は持続するかもしれません。 ローカルのRegistry方針は、特にRegistryが合法化関連の満期情報を保つといけないのでドメイン名登録データをアップデートするのを必要とするかもしれません。
Mayrhofer & Hoeneisen Informational [Page 9] RFC 4725 ENUM Validation Architecture November 2006
[9ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
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. Registryは自動的に合法化関連の情報を保ちます。または、再合法化が失敗したといけないので、ENUMドメイン代表団は中断しなければなりません、どちらかRegistryとの明白な相互作用で--、現在の合法化が期限が切れると。 ローカルの方針は有効期限に据置期間を与えるかもしれません。
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から中断します。
4.2. Trust Relations
4.2. 信用関係
The above validation workflow implies the following trust relations:
上の合法化作業フローは以下の信用関係を含意します:
o The Registry trusts the Validation Entities to enforce the local
validation policy.
o Registryは、Validation Entitiesがローカルの合法化方針を実施すると信じます。
o The Registrars trust the Validation Entities to properly perform
validation based on the Registrar's request.
o Registrarsは、Validation Entitiesが適切にRegistrarの要求に基づく合法化を実行すると信じます。
o Depending on the amount of validation data provided to the
Registry additional trust relations may be necessary. Three cases
can be differentiated:
o Registryの追加信用関係に提供された合法化データの量に依存するのが必要であるかもしれません。 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.
* Registryはどんな合法化関連のデータも受け取りません: Registryは、実行されていた状態で合法化があったRegistrarを信じる必要があります、そして、結果は確信していました。 さらに、Registryは、それが適切にそうするRegistrarが再合法化が失敗する代表団を取り除くと信じる必要があります。
* 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.
* Registryは有効期限日を含む合法化関連のデータを受け取りますが、信憑性をチェックする手段が全くありません: Registryは、合法化データが提供したRegistrarが正統であると信じる必要があります。
* 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.
* Registryは、有効期限日を含む合法化関連のデータを受け取って、信憑性(例えばVEによって発行された暗号の署名)について確かめることを意味します: どんな追加信用関係も必要ではありません。
Mayrhofer & Hoeneisen Informational [Page 10] RFC 4725 ENUM Validation Architecture November 2006
[10ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
4.3. Data Flow and Format
4.3. データフローと形式
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 記録係は、合法化要求を開始するか、変更するか、または中止するためにValidation Entitiesとコミュニケートします。 合法化Entitiesは合法化要求に作用して、合法化結果をRegistrarsに供給します。 Registrarsが潜在的に数個のValidation Entitiesとコミュニケートするかもしれなくて、Validation Entitiesが数個のRegistrars(最悪の場合: 完全なメッシュ)に対するサービスを供給するかもしれないので、標準化されたプロトコルとデータの形式はこのデータフローで使用されるべきです。
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 地方のRegistry方針命令であるならその合法化関連の情報が代表団記録と共に格納されることであり、RegistryとRegistrarの間の合法化関連のデータフローが必要です。 登録自体が既にそれらの実体のコミュニケーションを必要とするので、標準化されたデータの形式の合法化関連の情報は既存のRegistry-記録係プロトコルデータフローに埋め込まれるべきです。
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 合法化Entitiesは、合法化を実行するためにAssigneesとコミュニケートする必要があるかもしれません。 Validation Entityは、それ自体でAssigneeに連絡するより要求しているRegistrarを通してむしろAssigneeとのすべてのコミュニケーションを実行するのを選ぶかもしれません。 実際のコミュニケーションフォームと過程が大いに異なると予想されて、それはこのためにどんなデータも指定する意味を形式か過程にしません。
5. Example Scenarios
5. 例のシナリオ
5.1. E.164 Number Assignment along with ENUM Registration
5.1. ENUM登録に伴うE.164数の課題
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.
この簡単なシナリオでは、私たちは、同じ実体(例えば、インターネットTelephony Service Provider(ITSP))によってRegistrar、VE、およびNAEの役割が実行されると思います。 このITSPはNNPAによる規定番号範囲であったCSPです。 これらの範囲から、彼は、通信サービスをそれらに提供するために数を顧客(指定代理人)に割り当てます。 ITSPは、対応するENUMドメイン名と共にE.164番号を割り当てるのを選びます。 したがって、それは単に加入者データベースの参照で合法化を実行できます。
Mayrhofer & Hoeneisen Informational [Page 11] RFC 4725 ENUM Validation Architecture November 2006
[11ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
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 | | +-----+ |
------------- | |
+-----------+
+----------+ | 登録| +----------+ ^ | |(3) | +--------------------------------------+ | | | ITSP| | +-----------+ +----+ | | | 記録係| | VE| | | +-----------+ (2) +----+ | | | +--------------------------+ | ^ | | | | | |(1) | | | | | | | | +------------+ (4) | +-----+ | | 指定代理人=| <、-、-、-、-、-、-、-、-、--、|、| NAE| | | 記入者| | +-----+ | ------------- | | +-----------+
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登録要求をRegistryに送ります。(Registryは適用された合法化に関する追加情報を含むかもしれません)。 (4) ITSPはE.164数の課題とENUM登録に関して確認を顧客に送ります。(その顧客は、現在のAssigneeとRegistrantです)。
This scenario is quite close to "ordinary" domain name registrations.
全く「普通」のドメイン名登録証明書の近くにこのシナリオはあります。
Mayrhofer & Hoeneisen Informational [Page 12] RFC 4725 ENUM Validation Architecture November 2006
[12ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
5.2. Fully Disjoint Roles
5.2. 役割を完全にばらばらにならせてください。
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がAssigneeの意志について確かめるという要件があるとさらに思います。 したがって、合法化の過程は、また、Assigneeに連絡することを伴います。
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) +-----+
+----------+ | 登録| +----------+ ^ | |(9) | | | (3) +-----------+ ---------->+----+ | 記録係| <、-、-、-、-、-、-、-、-、--、| VE| +-----------+ (8) >+----+ ^ / / ^ | | / / | | | (7)/ / | | |(2) / / | | | / / (5)| | | / / | | | / / | | | / /(6) | | | / / | |(4) | / / | | | / / | | +------------+ <。| v| 指定代理人=| +-----+ | 記入者| <、-、-、-、-、-、-、-、-、--、| NAE| +------------+ (1) +-----+
Legend:
伝説:
NAE: Number Assignment Entity
VE: Validation Entity
NAE: 数の課題実体VE: 合法化実体
Figure 4: Fully Disjoint Roles
図4: 役割を完全にばらばらにならせてください。
Mayrhofer & Hoeneisen Informational [Page 13] RFC 4725 ENUM Validation Architecture November 2006
[13ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
(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ドメイン名登録のずっと前にこの課題をしたかもしれません、例えば、Assigneeが一般的な電話サービスに加入したとき。 (2) Assigneeは彼の選択のRegistrarで対応するENUMドメイン名を注文します。 (3) Registrarは独立しているVEで合法化を要求します。 (4) VEは、E.164番号のAssigneeがENUMドメイン名のRegistrantに対応することを確かめるためにNAEに関する加入者データベースに連絡します。 (5) NAE加入者データベースの結果は上向きです。 (6) VEは、ENUMドメイン名として登録されるためにE.164番号に呼び戻しを実行して、認証に備えて、彼の意志を確認するようにAssigneeに頼みます。 (7) Assigneeが確認して、VEが記録する、この確認。 (8) VEはRegistrarの積極的な答えを返します。 答えは合法化の過程に関する何らかの追加情報を含むかもしれません、有効期限などのように、適用されて、とてもオンな合法化方法。 (9) 最終的に、RegistrarはENUM登録要求をRegistryに送ります。 登録要求と共に合法化の過程に関する追加情報を送るかもしれません。
6. Security Considerations
6. セキュリティ問題
6.1. Fraud Prevention
6.1. 詐欺防止
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展開にも重要であり、高い配慮を受けるべきです。
6.2. Assignee Data
6.2. 指定代理人データ
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.
Assigneeデータを扱うとき、プライバシーと思慮深さ問題を考えなければなりません。 インターネットの上で指定代理人データを輸送すると使用されなければならない実現は、トランスポート・プロトコルを認証して、コード化しました。 地方の登録/合法化方針と協定は明確にAssigneeデータの用法を制限するべきです。
Mayrhofer & Hoeneisen Informational [Page 14] RFC 4725 ENUM Validation Architecture November 2006
[14ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
7. Acknowledgements
7. 承認
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.
作者は彼らの貴重な提案と貢献について以下の人々に感謝したがっています: ローレンス・コンロイ、マイケル・ハーバラー、テッド・ハーディー、Otmarレンドル、ハーラMowafy、マルセル・パロディ、ジョン・ピーターソン、ペンPfautz、パトリクSchaefer、およびリチャードStastny。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。
[2] ITU-T, "The international public telecommunication numbering
plan", Recommendation E.164 (02/05), Feb 2005.
2005年2月の[2] ITU-T、「国際的な公共の電気通信付番プラン」Recommendation E.164(02/05)。
8.2. Informative References
8.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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[4]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[5] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
RFC 3730, March 2004.
2004年のS.、「広げることができる食糧を供給するプロトコル(EPP)」、RFC3730行進の[5]Hollenbeck。
Mayrhofer & Hoeneisen Informational [Page 15] RFC 4725 ENUM Validation Architecture November 2006
[15ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
Authors' Addresses
作者のアドレス
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
アレクサンダーマイルホーファーenum.at GmbH Karlsplatz1/9ウィーンA-1010オーストリア
Phone: +43 1 5056416 34 EMail: alexander.mayrhofer@enum.at URI: http://www.enum.at/
以下に電話をしてください。 +43 1 5056416 34はメールされます: alexander.mayrhofer@enum.at ユリ: http://www.enum.at/
Bernie Hoeneisen Switch Neumuehlequai 6 CH-8001 Zuerich Switzerland
バーニーHoeneisenスイッチNeumuehlequai6CH-8001 Zuerichスイス
Phone: +41 44 268 1515 EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org URI: http://www.switch.ch/
以下に電話をしてください。 +41 44 268 1515はメールされます: hoeneisen@switch.ch 、b.は@ieee.org URIをhoeneisenします: http://www.switch.ch/
Mayrhofer & Hoeneisen Informational [Page 16] RFC 4725 ENUM Validation Architecture November 2006
[16ページ]RFC4725ENUM合法化構造2006年11月の情報のマイルホーファーとHoeneisen
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Mayrhofer & Hoeneisen Informational [Page 17]
マイルホーファーとHoeneisen情報です。[17ページ]
一覧
スポンサーリンク
