Internet Engineering Task Force (IETF) S. Channabasappa, Ed.
Request for Comments: 6461 CableLabs
Category: Informational January 2012
ISSN: 2070-1721
Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS)
Use Cases and Protocol Requirements
Abstract
抽象
This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry".
この文書では、ユースケースとセッション・ルーティングを支援するセッション開始プロトコル（SIP）サービスプロバイダコンポーネントに提供セッション確立データインターフェイスの関連要件を取り込みます。具体的には、この文書は、1つのそのような要素のプロビジョニングに焦点を当てた「レジストリ」と呼ばれます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6461.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6461で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Overview ........................................................2
2. Terminology .....................................................5
3. Registry Use Cases ..............................................6
3.1. Category: Provisioning Mechanisms ..........................6
3.2. Category: Interconnect Schemes .............................7
3.3. Category: SED Exchange and Discovery Models ................8
3.4. Category: SED Record Content ...............................9
3.5. Category: Separation and Facilitation of Data Management ...9
3.6. Category: Public Identifiers, TN Ranges, and RNs ..........10
3.7. Category: Misc ............................................11
4. Requirements ...................................................11
4.1. Provisioning Mechanisms ...................................12
4.2. Interconnect Schemes ......................................12
4.3. SED Exchange and Discovery Requirements ...................12
4.4. SED Record Content Requirements ...........................12
4.5. Data Management Requirements ..............................13
4.6. Public Identifier, TN Range, and RN Requirements ..........13
4.7. Misc. Requirements ........................................13
5. Security Considerations ........................................14
6. Acknowledgments ................................................14
7. References .....................................................15
7.1. Normative References ......................................15
7.2. Informative References ....................................15
[RFC5486] (Section 3.3) defines Session Establishment Data, or SED, as the data used to route a call to the next hop associated with the called domain's ingress point. More specifically, the SED is the set of parameters that the outgoing signaling path border elements (SBEs) need to establish a session. However, [RFC5486] does not specify the protocol(s) or format(s) to provision SED. To pave the way to specify such a protocol, this document presents the use cases and associated requirements that have been proposed to provision SED.
[RFC5486]（セクション3.3）と呼ばれるドメインの入口ポイントに関連付けられている次のホップへの呼の経路に使用されるデータとして、セッション確立データ、またはSEDを定義します。より具体的には、SEDは、発信シグナリングパスの境界要素（残りのSBE）がセッションを確立する必要があるパラメータのセットです。しかしながら、[RFC5486]は規定SEDにプロトコル（単数または複数）またはフォーマット（複数可）を指定していません。そのようなプロトコルを指定するための道を開くために、このドキュメントでは、ユースケースと規定SEDに提案されている関連する要件を提示します。
SED is typically created by the terminating or next-hop SIP service provider (SSP) and consumed by the originating SSP. To avoid a multitude of bilateral exchanges, SED is often shared via intermediary systems -- termed "registries" within this document. Such registries receive data via provisioning transactions from SSPs, and then distribute the received data into Local Data Repositories (LDRs). These LDRs are used for call routing by outgoing SBEs. This is depicted in Figure 1.
SEDは、典型的には、終端またはネクストホップSIPサービスプロバイダ（SSP）によって作成され、元のSSPによって消費されます。二国間交流の多数を避けるために、SEDは、多くの場合、仲介システムを介して共有される - このドキュメント内の「レジストリ」と呼ばれます。そのようなレジストリはのSSPからトランザクションをプロビジョニングを介してデータを受信し、次いで、ローカルデータリポジトリ（LDRを）に受信したデータを分配します。これらのLDRを発信残りのSBEによってコールルーティングのために使用されています。これは、図1に示されています。
*-------------*
1. Provision SED | |
-----------------------> | Registry |
| |
*-------------*
/ \
/ \
/ \
/ \
/ \
/ \
/ 2.Distribute \
/ SED \
V V
+----------+ +----------+
|Local Data| |Local Data|
|Repository| |Repository|
+----------+ +----------+
Figure 1: General Diagram
図1：一般的なダイアグラム
In this document, we address the use cases and requirements for provisioning registries. Data distribution to local data repositories is out of scope for this document. The resulting provisioning protocol can be used to provision data into a registry or between multiple registries operating in parallel. In Figure 2, the case of multiple registries is depicted with dotted lines.
この文書では、我々は、レジストリをプロビジョニングするためのユースケースと要件に対応します。ローカルのデータリポジトリへのデータの分布は、この文書の範囲外です。得られたプロビジョニングプロトコルは、レジストリにまたは並列に動作する複数のレジストリ間で提供データを使用することができます。図2では、複数のレジストリの場合には、点線で示されています。
. . . . . . .
. . . . . . . registry . . . . . . .
. . . . . . . . .
. . .
. . .
. . provision .
+-----------+ . +-----------+
| | provision +----------+ provision | |
| SSP 1 |------------>| Registry |<-----------| SSP 2 |
| | +----------+ | |
| +-----+ | /\ | +-----+ |
| | LDR | <-------------------- ------------------>| LDR | |
| +-----+ | distribute distribute | +-----+ |
| | | |
+-----------+ +-----------+
. .
. . . . . . . . . . . . . . . . . . . . . . . .
(provision / distribute)
Figure 2: Functional Overview
図2：機能の概要
In addition, this document proposes two aggregation groups, as follows:
次のように加えて、この文書は、2つの集約グループを提案しています：
o Aggregation of public Identifiers into a destination group.
先のグループへの公開識別子のO集約。
o Aggregation of SED records into a route group.
O SEDの集約は、ルートグループに記録します。
The use cases in Section 3.5 provide the rationale. The data model depicted in Figure 3 shows the various entities, aggregations, and the relationships between them.
3.5節でのユースケースは、理論的根拠を提供しています。図3に示されたデータ・モデルは、様々なエンティティ、集計、及びそれらの間の関係を示しています。
+---------+ +--------------+ +---------+
| Data |0..n 0..n| Route | 1 0..n| SED |
|Recipient|------------| Group | --------------| Record |
+---------+ +--------------+ +---------+
|0..n |0..n
| |
| |
| |
|0..n |
1 +--------------+ 0..1 |
---------| Destination |--------- |
| | Group | | |
| +--------------+ | |
| | | |
| 1| | |
| | | |
| | | |
0..n | 0..n | | 0..n |
+---------+ +---------+ +----------+ |
| RN | | TN | | Public |----
| | | Range | |Identifier| 1
+---------+ +---------+ +----------+
Figure 3: Data Model Diagram
図3：データモデル図
The relationships are as described below:
後述のような関係は以下のとおりです。
- A public identifier object can be directly related to zero or more SED Record objects, and a SED Record object can be related to exactly one public identifier object.
- 公開識別子オブジェクトは、ゼロ以上SED Recordオブジェクトに直接関連することができ、SED Recordオブジェクトは、1つの公開識別子オブジェクトに関連付けることができます。
- A destination group object can contain zero or more TN (telephone number) Range objects, and a TN Range object can be contained in exactly one destination group object.
- 宛先グループオブジェクトは、ゼロ以上のTN（電話番号）の範囲のオブジェクトを含むことができ、及びTN範囲オブジェクトは、正確に1つの宛先グループオブジェクトに含まれることができます。
- A destination group object can contain zero or more public identifier objects, and a public identifier object can be contained in exactly one destination group object.
- 宛先グループオブジェクトは、ゼロ以上のパブリック識別子オブジェクトを含むことができ、公開識別子のオブジェクトは、正確に1つの宛先グループオブジェクトに含まれることができます。
- A destination group object can contain zero or more RN (routing number) objects, and an RN object can be contained in exactly one destination group object.
- 宛先グループオブジェクトは、ゼロ以上RN（ルーティング番号）オブジェクトを含むことができ、及びRNオブジェクトは、正確に1つの宛先グループオブジェクトに含まれることができます。
- A route group object can contain zero or more SED Record objects, and a SED Record object can be contained in exactly one route group object.
- ルートグループのオブジェクトは、ゼロ以上SEDレコードオブジェクトを含むことができ、及びSED Recordオブジェクトは、1つのルートグループオブジェクトに含まれることができます。
- A route group object can be associated with zero or more destination group objects, and a destination group object can be associated with zero or more route group objects.
- ルートグループのオブジェクトは、ゼロ以上の宛先グループオブジェクトに関連付けることができ、及び宛先グループのオブジェクトは、ゼロ以上のルートグループオブジェクトに関連付けることができます。
- A data recipient object can be associated with zero or more route group objects, and a route group object can refer to zero or more data recipient objects.
- データの受信者オブジェクトは、ゼロ以上のルートグループオブジェクトに関連付けることができ、およびルートグループのオブジェクトは、ゼロ以上のデータ受信者オブジェクトを参照することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document reuses terms from [RFC3261] (e.g., SIP), [RFC5486] (e.g., SSP, LUF, LRF, SED) and [RFC5067] (carrier-of-record and transit provider). In addition, this document specifies the following additional terms.
このドキュメントは[RFC3261]（例えば、SIP）、[RFC5486]（例えば、SSP、LUF、LRF、SED）および[RFC5067]（キャリアのレコードとトランジット・プロバイダ）からの用語を再利用します。また、この文書は、以下の追加条件を指定します。
Registry: The authoritative source for provisioned session establishment data (SED) and related information. A registry can be part of an SSP or be an independent entity.
レジストリ：プロビジョニングセッション確立データ（SED）および関連情報の信頼できるソース。レジストリは、SSPの一部であるか、または独立したエンティティすることができます。
Registrar: An entity that provisions and manages data into the registry. An SSP can act as its own registrar or -- additionally or alternatively -- delegate this function to a third party (who acts as its registrar).
レジストラ：条項とは、レジストリにデータを管理するエンティティ。 SSPは独自のレジストラとして動作するか、することができます - 加えて、またはその代わりに - （そのレジストラとして動作する）第三者にこの機能を委任します。
Local Data Repository (LDR): The data store component of an addressing server that provides resolution responses.
ローカルデータリポジトリ（LDR）：解像度の応答を提供するアドレッシングサーバーのデータストアコンポーネント。
Public Identifier: A public identifier refers to a telephone number (TN), a SIP address, or other identity as deemed appropriate, such as a globally routable URI of a user address (e.g., sip:john.doe@example.net).
公開識別子：（：john.doe@example.net例えば、SIP）公開識別子は、ユーザのアドレスのグローバルにルーティング可能なURIとして電話番号（TN）、SIPアドレス、または、適切と思われるような他の同一性をいいます。
Telephone Number (TN) Range: A numerically contiguous set of telephone numbers.
電話番号（TN）範囲：電話番号の数値的に連続したセット。
Telephone Number (TN) Prefix: A preceding portion of the digits common across a series of E.164 numbers. A given TN prefix will include all the valid E.164 numbers that satisfy the expansion rules mandated by the country or the region with which the TNs comply.
電話番号（TN）プレフィックス：E.164番号の一連の間で共通の数字の前の部分。与えられたTNの接頭辞は、TNSが遵守されて、国や地域によって義務付けられた拡張ルールを満たすすべての有効なE.164番号が含まれます。
Routing Number (RN): A Routing Number. For more information, see [RFC4694].
ルーティング番号（RN）：ルーティング番号。詳細については、[RFC4694]を参照してください。
Destination Group: An aggregation of a set of public identifiers, TN Ranges, or RNs that share common SED, which is exposed to a common set of peers.
デスティネーショングループ：公開識別子のセットの集約、TNは、範囲、または共通SEDを共有するのRN、ピアの共通セットにさらされています。
Data Recipient: An entity with visibility into a specific set of public identifiers (or TN Ranges or RNs), the destination groups that contain these public identifiers (or TN Ranges and RNs), and a route group's SED records.
データ受信者：特定のパブリック識別子のセット（またはTN範囲またはRNS）への可視性を持つエンティティ、これらの公開識別子（またはTN範囲とのRN）を含有する先のグループ、およびルートグループのSEDを記録。
Route Group: An aggregation that contains a related set of SED records and is associated with a set of destination groups. Route groups facilitate the management of SED records for one or more data recipients.
ルートグループ：SEDレコードの関連セットが含まれ、宛先グループのセットに関連付けられている集約。ルートグループは、1つ以上のデータの受信者のためのSED記録の管理を容易にします。
This section documents use cases related to the provisioning of the registry. Any request to provision, modify, or delete data is subject to several security considerations (see Section 5). The protocols that implement these use cases (and associated requirements) will need to explicitly identify and address them.
このセクションの文書は、レジストリのプロビジョニングに関連した例を使用しています。提供するすべての要求、変更、またはデータを削除するには、（第5節を参照）、いくつかのセキュリティ問題を受けることです。これらのユースケース（および関連する要件）を実装するプロトコルは、明示的に特定し、それらに対処する必要があります。
UC PROV #1 Real-Time Provisioning: Registrars have operational systems that provision public identifiers (or TN Ranges or RNs) in association with their SED. These systems often function in a manner that expects or requires that these provisioning activities be completed immediately, as opposed to an out-of-band or batch provisioning scheme that can occur at a later time. This type of provisioning is referred to as "real-time" or "on-demand" provisioning.
UC PROV＃1リアルタイムプロビジョニング：レジストラは、彼らのSEDに関連して提供する公開識別子（またはTNは範囲またはRNS）の運用システムを持っています。これらのシステムは、多くの場合、期待又は後の時点で発生する可能性の帯域外またはバッチプロビジョニング方式とは対照的に、これらのプロビジョニング活動は、すぐに完了されることを要求するように機能します。プロビジョニングのこのタイプは、「リアルタイム」または「オンデマンド」のプロビジョニングと呼ばれています。
UC PROV #2 Non-Real-Time Bulk Provisioning: Operational systems that provision public identifiers (or TN Ranges or RNs) and associated SED sometimes expect that these provisioning activities be batched up into large sets. These batched requests are then processed using a provisioning mechanism that is out of band and occurs at a later time.
UC PROV＃2非リアルタイムバルクプロビジョニング：業務システムの提供公開識別子（またはTN範囲またはRNS）と関連したSEDは時々これらのプロビジョニング活動は大きなセットにアップバッチ処理することを期待しています。これらのバッチリクエストはその後、バンドの外であると後で発生プロビジョニングメカニズムを使用して処理されます。
UC PROV #3 Multi-Request Provisioning: Regardless of whether or not a provisioning action is performed in real time, SSPs often perform several provisioning actions on several objects in a single request or transaction. This is done for performance and scalability reasons, and for transactional reasons, such that the set of provisioning actions either fail or succeed atomically, as a complete set.
UC PROV＃3マルチリクエストプロビジョニング：関係なく、プロビジョニング・アクションをリアルタイムで実行されているかどうかの、のSSPは、多くの場合、単一の要求またはトランザクションで複数のオブジェクトのいくつかのプロビジョニングアクションを実行します。これは、パフォーマンスとスケーラビリティの理由から、そのような失敗や完全なセットとして、アトミックに成功のいずれかのアクションをプロビジョニングする一連のそのトランザクションの理由で行われます。
UC INTERCONNECT #1 Inter-SSP SED: SSPs create peering relationships with other SSPs in order to establish interconnects. Establishing these interconnects involves, among other things, communicating and enabling the points of ingress and other SED used to establish sessions.
UCの相互接続＃1のInter-SSP SED：SSPが相互接続を確立するために、他のSSPとのピアリング関係を作成します。これらの相互接続を確立することは、入力およびその他のSEDのポイントは、セッションを確立するために使用される通信と有効化、とりわけ、必要とします。
UC INTERCONNECT #2 Direct and Indirect Peering: Some inter-SSP peering relationships are created to enable the establishment of sessions to the public identifiers for which an SSP is the carrier-of-record. This is referred to as "direct peering". Other inter-SSP peering relationships are created to enable the establishment of sessions to public identifiers for which an SSP is a transit provider. This is referred to as "indirect peering". Some SSPs take into consideration an SSP's role as a transit or carrier-of-record provider when selecting a route to a public identifier.
UCの相互接続＃2、直接的および間接的ピアリング：一部の間SSPピアリング関係は、SSPは、キャリアのレコードであるため、公開識別子にセッションの確立を可能にするために作成されます。これは、「直接ピアリング」と呼ばれています。その他の相互SSPピアリング関係は、SSPはトランジットプロバイダーであるため、公開識別子にセッションの確立を可能にするために作成されます。これは「間接的なピアリング」と呼ばれています。公開識別子へのルートを選択する際に、一部のSSPを考慮にトランジットやキャリアのレコードプロバイダとしてSSPの役割を取ります。
UC INTERCONNECT #3 Intra-SSP SED: SSPs support the establishment of sessions between their own public identifiers, not just to other SSPs' public identifiers. Enabling this involves, among other things, communicating and enabling intra-SSP signaling points and other SED that can differ from inter-SSP signaling points and SED.
UCの相互接続＃3イントラSSP SED：SSPがちょうど他のSSPの公開識別子に、自分の公開識別子間のセッションの確立をサポートしていません。通信およびインターSSPシグナリングポイントとSEDと異なることがイントラSSPシグナリングポイントと他のSEDを可能にする、とりわけ、これが含むことができます。
UC INTERCONNECT #4 Selective Peering (a.k.a. per-peer policies): SSPs create peering relationships with other SSPs in order to establish interconnects. However, SSP peering relationships often result in different points of ingress or other SED for the same set of public identifiers. This is referred to as "selective peering" and is done on a route group basis.
UCの相互接続＃4の選択ピアリング（別称、ピアごとのポリシー）：SSPのは、相互接続を確立するために、他のSSPとのピアリング関係を作成。しかし、SSPピアリング関係は、多くの場合、公開識別子の同じセットのための入力または他のSEDの異なる点につながります。これは、「選択ピアリング」と呼ばれ、ルートグループごとに行われます。
UC INTERCONNECT #5 Provisioning of a delegated hierarchy: An SSP may decide to maintain its own infrastructure to contain the route records that constitute the terminal step in the LUF. In such cases, the SSP will provision registries to direct queries for the SSP's public identifiers to its own infrastructure rather than provisioning the route records directly. For example, in the case of DNS-based route records, such a delegated hierarchy would make use of NS and CNAME records, while a flat structure would make use of NAPTR resource records.
委任された階層のUC INTERCONNECT＃5プロビジョニング：SSPはLUFにおける最終ステップを構成するルートレコードを含むように、独自のインフラを維持することを決定することができます。このような場合には、SSP意志提供レジストリではなく、直接ルートレコードをプロビジョニングするよりも、独自のインフラストラクチャへのSSPの公開識別子のクエリを指示します。フラット構造は、NAPTRリソースレコードを利用するだろうが、例えば、DNSベースのルート・レコードの場合には、そのような委任階層は、NSとCNAMEレコードを利用することになります。
UC SED EXCHANGE #1 SED Exchange and Discovery using unified LUF/LRF: When establishing peering relationships, some SSPs may wish to communicate or receive SED (e.g., points of ingress) that constitutes the aggregated result of both LUF and LRF.
統一LUF / LRFを用いてUC SED EXCHANGE＃1 SED Exchangeとディスカバリー：ピアリング関係を確立する場合、いくつかのSSPはLUFとLRF両方の集約結果を構成するSED（入力の例えば、点）通信または受信することを望むかもしれません。
UC SED EXCHANGE #2 SED Exchange and Discovery using LUF's Domain Name: When establishing peering relationships, some SSPs may not wish to communicate or receive points of ingress and other SED using a registry. They only wish to communicate or receive domain names (LUF step only), and then independently resolve those domain names via [RFC3263] to the final points of ingress data (and other SED).
LUFのドメイン名を使用してUC SED EXCHANGE＃2 SED Exchangeおよびディスカバリー：ピアリング関係を確立すると、いくつかのSSPは、レジストリを使用して進入し、他のSEDのポイントを伝えるか、受け取りたくない場合があります。彼らは、通信またはドメイン名を受信する（LUFのみ工程）、その後、独立に入力データ（および他のSED）の最終点に[RFC3263]を介して、それらのドメイン名を解決することを望みます。
UC SED EXCHANGE #3 SED Exchange and Discovery using LUF's Administrative Domain Identifier: When establishing peering relationships, some SSPs may not wish to communicate or receive points of ingress and other SED using a registry. They only wish to communicate or receive an administrative domain identifier, which is not necessarily resolvable via DNS. The subsequent process of using that administrative domain identifier to select points of ingress or other SED can be SSP specific and is out of scope for this document.
LUFの管理ドメイン識別子を使用してUC SED EXCHANGE＃3 SED Exchangeおよびディスカバリー：ピアリング関係を確立すると、いくつかのSSPは、レジストリを使用して進入し、他のSEDのポイントを伝えるか、受け取りたくない場合があります。彼らは、通信したり、必ずしもDNS経由で解決できない管理ドメイン識別子を、受け取りたいです。入力または他のSEDの点を選択するために、その管理ドメイン識別子を用いて、その後のプロセスは、SSP特異的で、本書の範囲外であることができます。
UC SED EXCHANGE #4 Coexistent SED Exchange and Discovery Models: When supporting multiple peering relationships, some SSPs have the need to concurrently support all three of the SED Exchange and Discovery Models already described in this section (Section 3.3) for the same set of public identifiers.
UC SED EXCHANGE＃4共存SED Exchangeおよびディスカバリーモデル：複数のピアリング関係をサポートする場合、いくつかのSSPは、同時に公共の同じセットのために、すでにこのセクションで説明SED Exchangeおよびディスカバリーモデル（3.3節）の3つのすべてをサポートする必要があります識別子。
UC SED RECORD #1 SED Record Content: Establishing interconnects between SSPs involves, among other things, communicating points of ingress, the service types (SIP, SIPS, etc.) supported by each point of ingress, and the relative priority of each point of ingress for each service type.
UC SEDレコード＃1 SED記録内容：SSPの間の確立の相互接続は、入口の点を通信、とりわけ、関与、入口の各ポイントによってサポートされるサービスタイプ（SIP、SIPS、等）、及び各点の相対的な優先順位各サービスタイプの侵入。
UC SED RECORD #2 Time-To-Live (TTL): For performance reasons, querying SSPs sometimes cache SED that had been previously looked up for a given public identifier. In order to accomplish this, SSPs sometimes specify the TTL associated with a given SED record.
UC SED RECORD＃2のTime-To-Live（TTL）は：パフォーマンス上の理由から、照会のSSP時々キャッシュSED以前に与えられた公開識別子のために見上げていたという。これを達成するためには、SSPが時々所与SEDレコードに関連付けられたTTLを指定します。
UC DATA #1 Separation of Provisioning Responsibility: An SSP's operational practices often separate the responsibility of provisioning the points of ingress and other SED from the responsibility of provisioning public identifiers (or TN Ranges or RNs). For example, a network engineer can establish a physical interconnect with a peering SSP's network and provision the associated domain name, host, and IP addressing information. Separately, for each new subscriber, the SSP's provisioning systems provision the associated public identifiers.
責任をプロビジョニングのUCデータ＃1の分離：SSPの運用慣行は、多くの場合、公開識別子をプロビジョニングする（またはTNは範囲またはRNS）の責任から進入し、他のSEDのポイントをプロビジョニングの責任を分けます。たとえば、ネットワークエンジニアは、ピアリングSSPのネットワークと提供に関連したドメイン名、ホスト、およびIPアドレス情報を物理的な相互接続を確立することができます。これとは別に、それぞれの新しい加入者のために、SSPのプロビジョニングシステムの提供は、公開識別子を関連付けられています。
UC DATA #2 Destination Groups: SSPs often provision identical SED for large numbers of public identifiers (or TN Ranges or RNs). For reasons of efficiency, groups of public identifiers that have the same SED can be aggregated. These aggregations are known as destination groups. The SED is then indirectly associated with destination groups rather than with each individual public identifier (or TN Ranges or RNs).
UC DATA＃2宛先グループ：SSPの多くの場合、規定の同一の公開識別子の多数のためのSED（またはTN範囲またはRNS）。効率の理由のために、同じSEDを有する公開識別子のグループを集約することができます。これらの集計は、宛先グループとして知られています。 SEDは、次いで間接宛先グループではなく、それぞれの個々の公開識別子（又はTN範囲またはRNS）と関連しています。
UC DATA #3 Route Groups: SSPs often provision identical SED for large numbers of public identifiers (or TN Ranges or RNs), and then expose that relationship between a group of SED records and a group of public identifiers (or TN Ranges or RNs) to one or more SSPs. This combined grouping of SED records and destination groups facilitates efficient management of relationships and the list of peers (data recipients) that can look up public identifiers and receive the associated SED. This dual set of SED records and destination groups is termed a "route group".
その後のSSPしばしば規定の同一の公開識別子の多数のためのSED（またはTNは範囲またはRNS）、およびSEDのレコードのグループと公開識別子（またはTN範囲またはRNS）のグループ間の関係を公開：UCデータ＃3ルートグループ一の以上のSSPへ。 SEDレコードと送信先グループのこの組み合わせグループ化は公開識別子を検索し、関連するSEDを受けることができ、効率的な関係の管理・ピア（データ受信者）のリストを容易にします。 SEDレコードと送信先グループのこの二重のセットは、「ルートグループ」と呼ばれています。
UC PI #1 Additions and Deletions: SSPs often allocate and de-allocate specific public identifiers to and from end-users. This involves, among other things, activating or deactivating specific public identifiers (TN Ranges or RNs), and directly or indirectly associating them with the appropriate points of ingress and other SED.
UC PI＃1の追加および削除：SSPのは、往々に割り当てるとすると、エンドユーザーから特定の公開識別子を割り当て解除。これは（TNが範囲やRNS）特定の公開識別子を活性化または無効化、とりわけ、関与し、直接または間接的に進入し、他のSEDの適切なポイントに関連付けます。
UC PI #2 Carrier-of-Record versus Transit Provisioning: Some inter-SSP peering relationships are created to enable the establishment of sessions to the public identifiers (or TN Ranges or RNs) for which an SSP is the carrier-of-record. Other inter-SSP peering relationships are created to enable the establishment of sessions for which an SSP is a transit provider. Some SSPs take into consideration an SSP's role as a transit or carrier-of-record provider when selecting a route.
＃2キャリアの-録音トランジットプロビジョニング対UC PI：一部の間SSPピアリング関係はSSPは、キャリアのレコードであるため公開識別子（またはTN範囲またはRNS）へのセッションの確立を可能にするために作成されます。その他の相互SSPピアリング関係は、SSPはトランジットプロバイダーであるため、セッションの確立を可能にするために作成されます。ルートを選択する際に、一部のSSPを考慮にトランジットやキャリアのレコードプロバイダとしてSSPの役割を取ります。
UC PI #3 Multiplicity: As described in previous use cases, SSPs provision public identifiers (or TN Ranges or RNs) and their associated SED for multiple peering SSPs, and as both the carrier-of-record and transit provider. As a result, a given public identifier (or TN Range or RN) key can reside in multiple destination groups at any given time.
UC PI＃3繰り返し：以前のユースケースで説明したように、SSPを提供公開識別子（又はTN範囲またはRNS）とその関連SED複数ピアリングのSSPのための、およびのレコードキャリアおよびトランジット・プロバイダの両方として。その結果、指定された公開識別子（又はTN範囲またはRN）キーは、任意の時点で複数の宛先グループに存在することができます。
UC PI #4 Destination Group Modification: SSPs often change the SED associated with a given public identifier (or TN Range or RN). This involves, among other things, directly or indirectly associating them with a different point of ingress, different services, or different SED.
UC PI＃4デスティネーショングループ変更：SSPが、多くの場合、指定された公開識別子（またはTN範囲またはRN）に関連したSEDを変更します。これは、直接的または間接的に侵入、異なるサービス、または異なるSEDの別のポイントに関連付ける、とりわけ、必要とします。
UC PI #5 Carrier-of-Record versus Transit Modification: SSPs may have the need to change their carrier-of-record versus transit role for public identifiers (or TN Ranges or RNs) that they previously provisioned.
＃5キャリアの-録音トランジット変更対UC PI：SSPのは、彼らのキャリアのレコード、彼らが以前にプロビジョニングすることを公開識別子（またはTN範囲またはRNS）の中継役割対を変更する必要があります。
UC PI #6 Modification of Authority: An SSP indicates that it is the carrier-of-record for an existing public identifier or TN Range. If the public identifier or TN Range were previously associated with a different carrier-of-record, then there are multiple possible outcomes, such as a) the previous carrier-of-record is disassociated, b) the previous carrier-of-record is relegated to transit status, or c) the new carrier-of-record is placed in inactive mode. The choice may be dependent on the deployment scenario and is out of scope for this document.
UC PI当局の＃6変更：SSPは、それがキャリアのレコード既存の公開識別子またはTN範囲のためであることを示しています。パブリック識別子またはTN範囲が以前に異なるキャリアのレコードに関連付けられていた場合、以前のキャリアのレコードが解離されるような、複数の可能な結果）があり、b）は、前キャリアのレコードでありますトランジット状況に追いやら、またはc）新しいキャリア・オブ・レコードが非アクティブモードになります。選択が展開シナリオに依存すると、このドキュメントの範囲外であることがあります。
UC MISC #1 Number Portability: The SSP wishes to provide, in query response to public identifiers, an associated routing number (RN). This is the case where a set of public identifiers is no longer associated with the original SSP but has been ported to a recipient SSP, who provides access to these identifiers via a switch on the Signaling System Number 7 network identified by the RN.
UC MISC＃1番号ポータビリティ：SSPが公開識別子にクエリ応答、関連するルーティング番号（RN）で、提供することを望みます。これは、公開識別子のセットは、もはや元SSPに関連付けられているが、RNによって識別されるシグナリングシステムナンバー7ネットワーク上のスイッチを介してこれらの識別子へのアクセスを提供し、受信者SSPに移植されている場合です。
UC MISC #2 Data Recipient Offer and Accept: When a peering relationship is established (or invalidated), SSPs provision (or remove) data recipients in the registry. However, a peer may first need to accept its role (as a data recipient) before such a change is made effective. Alternatively, an auto-accept feature can be configured for a given data recipient.
UC MISC＃2データ受信者のオファーと受諾：ピアリング関係が確立（または無効化）されると、SSPの提供（または削除）レジストリ内のデータ受信者。しかし、ピアは、最初のそのような変更が有効となる前に（データ受信者など）の役割を受け入れる必要があるかもしれません。あるいは、自動受け入れる機能は、所与のデータ受信者のために構成することができます。
UC MISC #3 Open Numbering Plans: In several countries, an open numbering plan is used, where the carrier-of-record is only aware of a portion of the E.164 number (i.e., the TN prefix). The carrier-of-record may not know the complete number or the number of digits in the number. The rest of the digits are handled offline (e.g., by a Private Branch Exchange, or PBX). For example, an SSP can be the carrier-of-record for "+123456789" and be the carrier-of-record for every possible expansion of that number, such as "+12345678901" and "+123456789012", even though the SSP does not know what those expansions could be. This can be described as the carrier-of-record effectively being authoritative for the TN prefix.
UC MISC＃3を開き番号計画は：キャリアのレコードは、E.164番号（すなわち、TNプレフィックス）の一部のみを知っている場合、いくつかの国では、オープン番号計画は、使用されています。キャリアのレコードは、完全な番号または番号の桁数を知らなくてもよいです。数字の残りの部分は、（構内交換機またはPBXによって、例えば）オフラインで処理されます。例えば、SSPは、キャリアのレコード「123456789」であることができるともかかわらず、すべての可能な例えば「12345678901」などのその数の拡大、及び「123456789012」のキャリアのレコードであることSSPこれらの拡張は、何ができるかを知りません。これは、キャリアのレコードが効果的にTNプレフィックスの権威あるものとして説明することができます。
This section lists the requirements extracted from the use cases in Section 3. The objective is to make it easier for protocol designers to understand the underlying requirements and to reference and list the requirements that they support (or not). The requirements listed here, unless explicitly indicated otherwise, are expected to be supported. Protocol proposals are also expected to indicate their compliance with these requirements and highlight ones that they don't meet (if any). Furthermore, the requirements listed here are not meant to be limiting, i.e., protocol implementations and deployments may choose to support additional requirements based on use cases that are not listed in this document.
このセクションでは、目的はそれが簡単にプロトコル設計者は、基礎となる要件を理解し、それらがサポート要件（またはしない）を参照して一覧表示するようにすることです、セクション3のユースケースから抽出された要件を示しています。明示的に別段の指示がない限り、ここに記載されている要件は、サポートされることが期待されます。プロトコルの提案は、これらの要件の遵守を示し、彼らは（もしあれば）を満たしていないものを強調するために期待されています。さらに、ここに記載されている要件は、すなわち、プロトコル実装と展開は、このドキュメントに記載されていないユースケースに基づいて追加の要件をサポートすることを選択でき、限定するものではありません。
REQ-PROV-1: Real-time provisioning.
REQ-PROV-1：リアルタイムプロビジョニング。
REQ-PROV-2: (Optional) Non-real-time bulk provisioning.
REQ-PROV-2：（オプション）非リアルタイムのバルクプロビジョニング。
REQ-PROV-3: Multi-request provisioning.
REQ-PROV-3：マルチリクエストのプロビジョニング。
REQ-INTERCONNECT-1: Inter-SSP peering.
REQ-相互接続-1：インターSSPピアリング。
REQ-INTERCONNECT-2: Direct and Indirect peering.
REQ-相互接続-2：直接および間接ピアリング。
REQ-INTERCONNECT-3: Intra-SSP SED.
REQ-相互接続-3：イントラSSP SED。
REQ-INTERCONNECT-4: Selective peering.
REQ-相互接続-4：選択ピアリング。
REQ-INTERCONNECT-5: Provisioning of a delegated hierarchy.
REQ-相互接続-5：委任階層のプロビジョニング。
REQ-SED-1: SED containing unified LUF and LRF content.
REQ-SED-1：SEDは統一LUFとLRFの内容を含みます。
REQ-SED-2: SED containing LUF-only data using domain names.
REQ-SED-2：SEDは、ドメイン名を使用してLUFのみのデータを含みます。
REQ-SED-3: SED containing LUF-only data using administrative domains.
REQ-SED-3：SEDは、管理ドメインを使用してLUFのみのデータを含みます。
REQ-SED-4: Support for all the other REQ-SED requirements (listed in this section), concurrently, for the same public identifier (or TN Range or RN).
REQ-SED-4：同じ公開識別子（又はTN範囲またはRN）のために、同時に（このセクションに記載されている）他のすべてのREQ-SED要件のサポート、、。
REQ-SED-RECORD-1: Ability to provision SED record content.
REQ-SED-RECORD-1：準備SEDのレコードの内容に能力。
REQ-SED-RECORD-2: (Optional) Communication of an associated TTL for a SED Record.
REQ-SED-RECORD-2：SEDレコードの関連するTTL（オプション）通信。
REQ-DATA-MGMT-1: Separation of responsibility for the provisioning the points of ingress and other SED, from the responsibility of provisioning public identifiers.
REQ-DATA-MGMT-1：公開識別子をプロビジョニングの責任からポイントの入力およびその他のSEDのプロビジョニング、責任の分離。
REQ-DATA-MGMT-2: Ability to aggregate a set of public identifiers as destination groups.
REQ-DATA-MGMT-2：宛先グループとして公開識別子のセットを集約する機能。
REQ-DATA-MGMT-3: Ability to create the aggregation termed route group.
REQ-DATA-MGMT-3：集約を作成する機能は、ルートグループと呼ばれます。
REQ-PI-TNR-RN-1: Provisioning of, and modifications to, the following aggregations: destination group and route groups.
REQ-PI-TNR-RN-1：のプロビジョニング、および以下の集計、への変更：宛先グループとルートグループ。
REQ-PI-TNR-RN-2: Ability to distinguish an SSP as either the carrier-of-record provider or the transit provider.
REQ-PI-TNR-RN-2：キャリアのレコードプロバイダまたはトランジット・プロバイダのいずれかとしてSSPを識別する能力。
REQ-PI-TNR-RN-3: A given public identifier (or TN Range or RN) can reside in multiple destination groups at the same time.
REQ-PI-TNR-RN-3：指定された公開識別子（又はTN範囲またはRN）は、同時に複数の宛先グループに存在することができます。
REQ-PI-TNR-RN-4: Modification of public identifier (or TN Range or RN) by allowing them to be moved to a different destination group via an atomic operation.
REQ-PI-TNR-RN-4：パブリック識別子の変更（又はTN範囲またはRN）それらがアトミック操作を介して別の宛先グループに移動できるようにすることによって。
REQ-PI-TNR-RN-5: SSPs can indicate a change to their role from carrier-of-record provider to transit, or vice versa.
REQ-PI-TNR-RN-5：SSPのが輸送にキャリアのレコードプロバイダーからそれらの役割に変更を示す、またはその逆のことができます。
REQ-PI-TNR-RN-6: Support for modification of authority with the conditions described in UC PI #6.
REQ-PI-TNR-RN-6：UC PI＃6に記載の条件と権限の変更をサポートします。
REQ-MISC-1: Number portability support.
REQ-MISC-1：番号ポータビリティのサポート。
REQ-MISC-2: Ability for the SSP to be offered a peering relationship and for the SSP to accept (explicitly or implicitly) or reject such an offer.
REQ-MISC-2：SSPの能力は、ピアリング関係を提供するとSSPのために受け入れる（明示的または暗黙的に）、またはそのような申し出を拒絶します。
REQ-MISC-3: Support for open numbering plans.
REQ-MISC-3：オープン番号計画のサポート。
Session establishment data allows for the routing of SIP sessions within, and between, SIP Service Providers. Access to this data can compromise the routing of sessions and expose a SIP Service Provider to attacks such as service hijacking and denial of service. The data can be compromised by vulnerable functional components and interfaces identified within the use cases.
セッション確立データ内、及びSIPサービスプロバイダとの間のSIPセッションのルーティングを可能にします。このデータへのアクセスは、セッションのルーティングを侵害し、そのようなサービスの乗っ取りやサービス拒否などの攻撃へのSIPサービスプロバイダを公開することができます。データは、ユースケース内で識別脆弱な機能コンポーネントおよびインターフェースによって妥協することができます。
A provisioning framework or protocol that implements the described use cases MUST, therefore, provide data confidentiality and message integrity. Such frameworks and protocols MUST specify mechanisms to authenticate and authorize any entity that provisions data into the registry, i.e., that the entity is who it says it is and is allowed to use the provisioning interface. The determination of whether such an entity is authorized to provision specific data elements (e.g., a certain public identifier or TN Range) -- while REQUIRED -- may be left to local policy.
説明ユースケースを実装するプロビジョニング・フレームワークまたはプロトコルは、従って、データの機密性及びメッセージ完全性を提供しなければなりません。そのようなフレームワークおよびプロトコルは、企業がそれであり、プロビジョニング・インターフェースを使用することが許可されていると言う人であること、すなわち、レジストリに任意のエンティティ規定データを認証および承認するためのメカニズムを指定しなければなりません。そのようなエンティティのプロビジョニング特定のデータ要素に許可されているか否かの決意は、（例えば、特定の公開識別子またはTNレンジ） - REQUIREDつつ - ローカルポリシーに残すことができます。
This document is a result of various contributions from (and discussions within) the IETF DRINKS Working Group; specifically, in alphabetical order: Alexander Mayrhofer, Deborah A Guyton, Gregory Schumacher, Jean-Francois Mule, Kenneth Cartwright, Manjul Maharishi, Penn Pfautz, Ray Bellis, Richard Shockey, and Syed Ali.
この文書では、さまざまなからの貢献（と内部の議論）IETF DRINKSワーキンググループの結果です。具体的には、アルファベット順に：アレクサンダーMayrhofer、デボラAガイトン、グレゴリー・シューマッハ、ジャン=フランソワラバ、ケネス・カートライト、マンジュールマハリシ、ペンPfautz、レイ・ベリス、リチャードショッキー、とサイード・アリ。
The editor also wishes to thank the following for their comments and suggestions: Otmar Lendl, Sohel Khan, Peter Koch, Brian Rosen, Jon Peterson, Gonzalo Camarillo, and Stephen Farrell.
オトマールレンドル、Sohelカーン、ピーター・コッホ、ブライアン・ローゼン、ジョンピーターソン、ゴンサロ・カマリロ、そしてステファン・ファレル：エディタはまた、彼らのコメントや提案のために次のことを感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]マラス、D.とD.マイヤー、 "マルチメディアインターコネクトのためのセッションピアリング（SPEERMINT）用語"、RFC 5486、2009月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[RFC4694] Yu, J., "Number Portability Parameters for the "tel" URI", RFC 4694, October 2006.
[RFC4694] TEL "URI "ゆう、J.、" 用の番号ポータビリティパラメータ"、RFC 4694、2006年10月。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.
[RFC5067]リンド、S.とP. Pfautz、 "インフラストラクチャENUM要件"、RFC 5067、2007年11月。
Author's Address
著者のアドレス
Sumanth Channabasappa (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA
スーマンスChannabasappa（エディタ）CableLabsの858コールクリークサークルルイビル、CO 80027 USA
EMail: sumanth@cablelabs.com
メールアドレス：sumanth@cablelabs.com