Network Working Group A. Barbir
Request for Comments: 3838 Nortel Networks
Category: Informational O. Batuner
Consultant
A. Beck
Lucent Technologies
T. Chan
Nokia
H. Orman
Purple Streak Development
August 2004
Policy, Authorization, and Enforcement Requirements
of the Open Pluggable Edge Services (OPES)
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 Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow.
この文書では、与えられたオープンプラグイン可能なエッジサービス（OPES）のフローに適用されるサービスを選択するための方針、許可、および執行の要件について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Policy Architecture . . . . . . . . . . . . . . . . . . . . . 4
3.1. Policy Components and Functions . . . . . . . . . . . . 4
3.2. Requirements for Policy Decision Points. . . . . . . . . 5
3.3. Requirements for Policy Enforcement Points . . . . . . . 5
4. Requirements for Interfaces . . . . . . . . . . . . . . . . . 6
4.1. Service Bindings Requirements . . . . . . . . . . . . . 7
4.1.1. Environment Variables . . . . . . . . . . . . . 7
4.1.2. Requirements for Using State Information . . . . 8
4.1.3. Requirements for Passing Information Between
Services . . . . . . . . . . . . . . . . . . . . 8
4.2. Requirements for Rule and Rules Management . . . . . . . 8
4.2.1. Requirements for Rule Providers . . . . . . . . 8
4.2.2. Requirements for Rule Formats and Protocols . . 9
4.2.3. Requirements for Rule Conditions . . . . . . . . 9
4.2.4. Requirements for Rule Actions . . . . . . . . . 9
4.3. Requirements for Policy Expression . . . . . . . . . . . 10
5. Authentication of Principals and Authorization of Services . . 10
5.1. End users, Publishers and Other Considerations . . . . . 11
5.1.1. Considerations for End Users . . . . . . . . . . 11
5.1.2. Considerations for Publishing Sites. . . . . . . 12
5.1.3. Other Considerations . . . . . . . . . . . . . . 12
5.2. Authentication . . . . . . . . . . . . . . . . . . . . . 12
5.3. Authorization . . . . . . . . . . . . . . . . . . . . . 13
5.4. Integrity and Encryption . . . . . . . . . . . . . . . . 14
5.4.1. Integrity and Confidentiality of Authentication
and Requests/Responses for Service . . . . . . . 14
5.4.2. Integrity and Confidentiality of Application
Content . . . . . . . . . . . . . . . . . . . . 14
5.5. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers.
オープンプラグイン可能なエッジサービス（OPES）[1]アーキテクチャは、データプロバイダとの間の連携アプリケーションサービス（OPESサービス）、データコンシューマ、およびゼロ以上OPESプロセッサを可能にします。検討中のアプリケーションサービスは、分析し、おそらくデータプロバイダとデータコンシューマの間でやり取りするアプリケーションレベルのメッセージを変換します。 OPESプロセッサは、通信および1つ以上のリモートコールアウトサーバとの連携により、サービス実行の責任を配布することができます。
The execution of such services is governed by a set of rules installed on the OPES processor. The rule evaluation can trigger the execution of service applications local to the OPES processor or on a remote callout server.
このようなサービスの実行はOPESプロセッサにインストールされている一連の規則によって支配されています。ルール評価は、OPESプロセッサまたはリモートコールアウトサーバ上のローカルサービスアプリケーションの実行をトリガすることができます。
Policies express the goals of an OPES processor as a set of rules used to administer, manage, and control access to resources. The requirements in this document govern the behavior of OPES entities in determining which of the available services are to be applied to a given message, if any.
ポリシーは、管理、管理、およびリソースへのアクセスを制御するために使用されるルールのセットとしてOPESプロセッサの目標を表現します。このドキュメントの要件があれば、与えられたメッセージに適用される利用可能なサービスのかを決定するにOPESエンティティの行動を支配します。
The scope of OPES policies described in this document are limited to those that describe which services to call and, if appropriate, with what parameters. These policies do not include those that prescribe the behavior of the called services. It is desirable to enable a common management framework for specifying policies for both the calling of and the behavior of a service. The integration of such a function is the domain of policy administration user interaction applications.
このドキュメントで説明OPESポリシーの範囲が適切であればどのようなパラメータを指定して、呼び出し、ためにどのサービスを記述するものに限定されています。これらのポリシーはと呼ばれるサービスの動作を規定するものが含まれていません。の呼び出しとサービスの動作の両方のポリシーを指定するための共通の管理フレームワークを有効にすることが望ましいです。そのような機能の統合は、ポリシー管理、ユーザインタラクションアプリケーションのドメインです。
The document is organized as follows: Section 2 considers policy framework. Section 3 discusses requirements for interfaces, while section 4 examines authentication of principals and authorization of services.
次のように文書が構成されています。第2節では、政策の枠組みを検討します。セクション4は、プリンシパルとサービスの許可の認証を検証しながら、第3節では、インターフェイスの要件を論じています。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications.
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにあります[4]で説明されるように解釈されます。規範的な意味で使用する場合、これらのキーワードは、すべて大文字になります。小文字でこれらの単語の出現は、無規範的な意味で、通常の散文の使用を含みます。
This section describes the architectural policy decomposition requirements. It also describes the requirements for the interfaces between the policy components. Many of the rules here were determined under the influence of RFC 3238 [2].
このセクションでは、建築政策分解要件について説明します。それはまた、ポリシーコンポーネント間のインタフェースの要件を記載しています。ここでのルールの多くは、RFC 3238の影響を受けて決定した[2]。
The policy functions are decomposed into three components: a Rule Author, a Policy Decision Point (PDP) [6], and a Policy Enforcement Point (PEP) [6]. The Rule Author provides the rules to be used by an OPES entity. These rules control the invocation of services on behalf of the rule author. The PDP and the PEP interpret the collected rules and appropriately enforce them. The decomposition is illustrated in Figure 1.
ルール作成者、ポリシー決定ポイント（PDP）[6]、およびポリシー施行点（PEP）[6]：ポリシー機能は三つの成分に分解されます。 Rule Authorでは、OPESエンティティによって使用されるルールが用意されています。これらのルールは、ルール作成者に代わってサービスの呼び出しを制御します。 PDPとPEPは、収集したルールを解釈し、それらを適切に施行します。分解は、図1に示されています。
+--------+ +--------+
| Rule | | Rule |
| Author | ... | Author |
+--------+ +--------+
| |
| |
| +----------+ |
| | Policy | | <- PDP Interface
+--------->| Decision |<----------+
| Point |
+----------+
| ^
| |
| | <- PEP Interface
| |
V |
+--------------+ ...
---> | Policy | --->
| Enforcement | Data Traffic
<--- | Point | <---
+--------------+
Figure 1: Policy Components
図1：ポリシーコンポーネント
The decomposition of policy control into a PDP and a PEP permit the offloading of some tasks to an administrative service that may be located on a server separate from the real-time enforcement services of the PEP that reside on the OPES processor.
PDPとPEPへのポリシー制御の分解は、OPESプロセッサ上に存在するPEPのリアルタイム執行サービスとは別のサーバー上に配置されてもよい行政サービスにいくつかのタスクのオフロードを許可します。
The PDP provides for the authentication and authorization of rule authors and the validation and compilation of rules.
PDPは、ルールの作成者とルールの検証およびコンパイルの認証および承認のために用意されています。
The PEP resides in the data filter where the data from an OPES flow is evaluated against the compiled rules and appropriate calls to the requested services are performed.
PEPはOPESフローからのデータがコンパイルされたルールに照らして評価され、要求されたサービスへの適切な呼び出しが行われ、データフィルタに存在します。
Interfaces between these architectural components are points of interoperability. The interface between rule authors and the policy decision points (PDP Interface) MUST use the format that may result from the requirements as described in this document.
これらのアーキテクチャコンポーネント間のインタフェースは、相互運用性のポイントです。ルール作成者とポリシー決定ポイント（PDPインタフェース）との間のインターフェースは、この文書に記載されているような要件に起因し得るフォーマットを使用しなければなりません。
The interface between the policy decision points and the policy enforcement points (PEP Interface) can be internal to a specific vendor implementation of an OPES processor. Implementations MUST use standard interface only if the PDP and the PEP reside on different OPES processors.
ポリシー決定ポイントとポリシー実施ポイント（PEPインタフェース）との間のインターフェースは、OPESプロセッサの特定のベンダの実装の内部であってもよいです。 PDPとPEPは異なるOPESプロセッサ上に存在する場合にのみ実装は、標準インタフェースを使用しなければなりません。
The Policy Decision Point is essentially a policy compiler. The PDP MUST be a service that provides administrative support to the enforcement points. The PDP service MUST authenticate the rule authors.
ポリシー決定ポイントは、基本的に政策コンパイラです。 PDPは、実施ポイントに管理サポートを提供するサービスでなければなりません。 PDPサービスは、ルールの作成者を認証する必要があります。
The PDP MUST verify that the specified rules are within the scope of the rule authors authority. The PDP MUST be a component of the OPES Administration Authority.
PDPは、指定されたルールは、ルールの作成者の権限の範囲内であることを確かめなければなりません。 PDPはOPES管理権限のコンポーネントでなければなりません。
In the OPES architecture, the data filter represents a Policy Enforcement point (PEP). At this point, data from an OPES flow is evaluated against the compiled rules, and appropriate calls to the requested services are performed.
OPESアーキテクチャでは、データ・フィルタは、ポリシー施行点（PEP）を表します。この時点で、OPESフローからのデータがコンパイルされたルールに照らして評価され、要求されたサービスへの適切な呼び出しが実行されています。
In the PEP rules MAY chain actions together, where a series of services to be called are specified. Implementation MUST ensure the passing of information from one called service to another. Implementation MUST NOT prohibit the re-evaluation of a message to determine if another service or set of services should be called.
PEPのルールでは、一連のサービスが呼び出される一緒にチェーンアクションは、指定されているかもしれません。実装は、別のと呼ばれるサービスからの情報の受け渡しを確実にしなければなりません。実装は、別のサービスまたはサービスのセットが呼び出されるべきかどうかを判断するために、メッセージの再評価を禁止してはなりません。
The execution of an action (i.e., the triggering of a rule) may lead to the modification of message property values. For example, an OPES service that under some circumstances converts JPEG images to GIF images modifies the content type of the requested web object.
アクション（すなわち、ルールのトリガ）の実行は、メッセージプロパティ値の変更につながる可能性があります。例えば、いくつかの状況下でGIF画像にJPEG画像を変換OPESサービスは、要求されたWebオブジェクトのコンテンツタイプを変更します。
Such modification of message property values may change the behavior of subsequently performed OPES actions. The data filter SHOULD act on matched rules before it evaluates subsequent rules. Multiple matched rules can be triggered simultaneously if the data filter can determine in advance that there are no side effects from the execution of any specific rule.
メッセージのプロパティ値のそのような修正は、その後に行わOPESアクションの動作を変更することがあります。それは、その後のルールを評価する前に、データフィルタがマッチしたルールに基づいて行動すべきです。データフィルタは、任意の特定のルールの実行からの副作用がないことを事前に判断することができるならば、複数のマッチルールが同時にトリガすることができます。
A data filter MAY evaluate messages several times in the course of handling an OPES flow. The rule processing points MAY be defined by administratively defined names. The definition of such names can serve as a selector for policy rules to determine the applicability of a rule or a set of rules at each processing point.
データフィルタは、OPESフローを処理する過程でメッセージを数回評価してもよいです。ルール処理のポイントは、管理者が定義名によって定義することができます。ポリシールールは、ルールの適用または各加工点でのルールのセットを決定するためにそのような名前の定義は、セレクタとして機能することができます。
Policy roles ([5] and [6]) SHOULD be used where they aid in the development of the OPES policy model.
ポリシーロール（[5]および[6]）は、OPESポリシーモデルの開発に役立つ場合に使用されるべきです。
Figure 2 expresses a typical message data flow between a data consumer application, an OPES processor, and a data provider application. There are four commonly used processing points identified by the numbers 1 through 4.
図2は、データ・コンシューマ・アプリケーション、OPESプロセッサ、及びデータ・プロバイダ・アプリケーションとの間の典型的なメッセージ・データの流れを表しています。 4を通じて番号1によって同定された4つの一般的に使用される加工点があります。
+--------+ +-----------+ +---------+
| |<------|4 3|<------| |
| Data | | OPES | | Data |
|Consumer| | Processor | |Provider |
| Appl. |------>|1 2|------>| Appl. |
+--------+ +-----------+ +---------+
Figure 2: Processing Execution Points
図2：処理の実行ポイント
Any data filter (PEP) or any administrative (PDP) implementation MUST support the four rule processing points.
任意のデータフィルタ（PEP）、または任意の管理（PDP）の実装は、4つのルール処理ポイントをサポートしなければなりません。
o Data Consumer Request handling role: This involves request processing when received from a Data Consumer Application. o OPES Processor Request handling role: This involves request processing before forwarding to Data Provider Application. o Data Provider Response handling role: This involves response processing when forwarding to Data Consumer Application. o OPES Processor Response handling role: This involves response processing when forwarding to Data Consumer Application.
Oデータ消費者要求処理の役割：データ消費者アプリケーションから受信したときには、要求処理を必要とします。 O OPESプロセッサ要求処理の役割：これは、データ・プロバイダのアプリケーションに転送する前に、要求の処理を必要とします。 Oデータプロバイダ応答処理の役割：データ消費者アプリケーションに転送するとき、これは、応答処理を必要とします。 O OPESプロセッサの応答処理の役割：データ消費者アプリケーションに転送するとき、これは、応答処理を必要とします。
The interface between the policy system and OPES services needs to include the ability to pass system state information as well as the subject message.
ポリシーシステムとOPESサービスとの間のインターフェースは、システム状態情報、ならびに対象メッセージを通過する能力を含む必要があります。
The invoked OPES services MUST be able to be specified in a location independent fashion. That is, the rule authors need not know and need not specify the instance of an OPES service in the rules.
呼び出されたOPESサービスは、場所に依存しない方法で指定することができなければなりません。これは、ルールの作成者は知っている必要はなくて、ルールでOPESサービスのインスタンスを指定する必要はありません。
The rule author SHOULD be able to identify the required service at the detail level that is appropriate for his or her needs. The rule author SHOULD be able to specify a type of service or be able to specify any service that fits a general category of service to be applied to its traffic.
ルール作成者は、彼または彼女のニーズに適している詳細レベルで必要なサービスを識別することができるべきです。ルール作成者は、サービスの種類を指定するか、そのトラフィックに適用されるサービスの一般的なカテゴリに合った任意のサービスを指定することが可能であるべきです。
The binding of OPES service names to a specific service MAY be distributed between the PDP and the PEP. As rules are compiled and validated by the PDP, they MUST be resolved to a specific installations' set of homogeneous OPES service.
特定のサービスへOPESサービス名の結合は、PDPとPEPとの間で分配されてもよいです。ルールはPDPによってコンパイルされ、検証されると、それらは均質OPESサービスの具体的なインストールのセットに解決されなければなりません。
The selection of a specific instance MAY be postponed and left to PEP to select at either the rule installation time or at run time. To achieve interoperability, PEP MUST support resolving a generic name to a specific instance. It is possible to use services such as SLP or UDDI to resolve generic service names to specific OPES service instances.
特定のインスタンスの選択は、いずれかのルールのインストール時または実行時に選択することがPEPに延期して残すことができます。相互運用性を実現するために、PEPは、特定のインスタンスへの一般的な名前を解決するサポートしなければなりません。特定のOPESサービスインスタンスへの汎用サービス名を解決するためにSLPやUDDIなどのサービスを利用することが可能です。
The policy system MAY support dynamic discovery of service bindings. The rule author may not know specific service bindings, such as protocol and parameters, when a rule (as specified on the PDP Interface) is general in nature. The required binding information MUST be provided by the PDP and conveyed on the PEP Interface. A service description methodology such as WSDL [8] MUST be present in the policy system.
政策システムは、サービスバインディングの動的な発見をサポートするかもしれません。ルールは、（PDPインターフェイスで指定された）自然界に一般的である場合、ルール作成者は、そのようなプロトコルおよびパラメータのような特定のサービスバインディングを知らないかもしれません。必要な結合情報は、PDPによって提供され、PEPインタフェース上を搬送されなければなりません。例えばWSDLなどのサービス記述方法[8]は、ポリシーシステムに存在していなければなりません。
There may be a need to define and support a means for maintaining state information that can be used in both condition evaluation and action execution. Depending on the execution environment, OPES services MAY have the freedom to define variables that are needed and use these variables to further define their service behavior without the data filter support.
条件評価とアクション実行の両方で使用可能な状態情報を維持するための手段を定義し、サポートする必要があるかもしれません。実行環境によっては、OPESサービスが必要とされている変数を定義し、さらにデータフィルタサポートすることなく、サービスの動作を定義するためにこれらの変数を使用する自由を持っているかもしれません。
Policy rules MAY specify that state information be used as part of the evaluation of the rules against a given message in an OPES flow. Thus, the policy system SHOULD support the maintenance of groups that can be used in evaluating rule conditions. Membership in such groups can be used as action triggers.
ポリシールールは、状態情報がOPESフロー内の指定されたメッセージに対するルールの評価の一部として使用されることを指定してもよいです。したがって、ポリシーシステムは、ルールの条件を評価する際に使用することができるグループの維持をサポートしなければなりません。そのようなグループのメンバーシップは、アクションのトリガーとして使用することができます。
For example, an authorized site blocking service might conclude that a particular user shouldn't be permitted access to a certain web site. Rather than calling the service for each request sent by such a user, a rule might be created to determine whether a user is a member of blocked users and if a requested site is a member of blocked-sites, and then invoke a local blocking service to return an appropriate message to the user.
例えば、認可サイトブロックサービスは、特定のユーザが特定のWebサイトへのアクセスを許可すべきではないと結論付けてあります。むしろ、そのようなユーザーが送信要求ごとにサービスを呼び出すよりも、ルールは、ユーザーがブロックされたユーザーのメンバーであり、要求されたサイトはブロックされ、サイトのメンバーであるかどうかどうかを判断するために作成し、ローカルブロッキングサービスを呼び出すことがありますユーザーに適切なメッセージを返します。
Environment variables can be used to pass state information between services. For example, analysis of the request or modifications to the request may need to be captured as state information that can be passed to other services on the request path or to services on the response(s) associated with that request.
環境変数は、サービス間の状態情報を渡すために使用することができます。例えば、要求に対して要求または修飾の分析は、要求経路上またはその要求に関連する応答（S）上のサービスを他のサービスに渡すことができる状態情報として取得する必要があるかもしれません。
In the PEP, there SHOULD be provisions to enable setting up variables when returning from a service call and passing variables to other called services based on policy.
PEPでは、サービスコールからの復帰時の変数を設定し、ポリシーに基づいて、他のサービスと呼ばれるに変数を渡す可能にするための規定があるはずです。
This section provides the requirements for rule management. The rules are divided into two groups. Some rules are provided by the data consumer application, and other rules are provided by the data provider application.
このセクションでは、ルール管理のための要件を提供します。ルールは2つのグループに分けています。いくつかのルールは、データ・コンシューマ・アプリケーションによって提供され、他のルールは、データ・プロバイダ・アプリケーションによって提供されます。
The requirements for rule providers are:
ルール・プロバイダーのための要件は次のとおりです。
o Rule providers MUST be authenticated and authorized for rules that apply to their network role. o Rule providers MUST NOT be able to specify rules that are NOT within their scope of authority. o Rule providers SHOULD be able to specify only what is needed for their services. o Compilation of rules from different sources MUST NOT lead to execution of conflicting rules. o The resolution of such rule conflicts is out of scope.
Oルールのプロバイダーは、ネットワークの役割に適用される規則のための認証および承認されなければなりません。 Oルールプロバイダは、権限の彼らの範囲に含まれないルールを指定できるようにはなりません。 Oルールプロバイダは、彼らのサービスのために必要なものだけを指定することができるべきです。 O異なるソースからのルールのコンパイルが競合ルールの実行を招いてはなりません。 Oこのような規則の競合の解決は範囲外です。
o Rules are assumed to be static and applied to current network state.
Oルールは、静的であると仮定し、現在のネットワーク状態に適用されます。
It is desirable to choose standard technologies like XML to specify the rule language format.
ルール言語の形式を指定するには、XMLなどの標準的な技術を選択することが望ましいです。
Rules need to be sent from the rule authors to the OPES administrative server for service authorization, rule validation, and compilation. The mechanisms for doing that are out of scope of the current work.
ルールは、サービス認可、ルールの検証、およびコンパイルのOPES管理サーバーにルールの作成者から送信される必要があります。現在の仕事の範囲外である行うための仕組み。
Once the rules are authorized, validated, and compiled by the administrative server, the rules need to be sent to the OPES processor. The mechanisms for doing that are out of scope of the current work.
ルールは、許可検証、および管理サーバーでコンパイルされると、ルールはOPESプロセッサに送信する必要があります。現在の仕事の範囲外である行うための仕組み。
Rule conditions MUST be matched against attribute values of the encapsulated protocol as well as environment variable values. Attribute values of the encapsulated protocol include protocol header values and possibly also protocol body values.
ルールの条件は、属性カプセル化されたプロトコルの値だけでなく、環境変数の値と照合しなければなりません。カプセル化されたプロトコルの値は、プロトコルヘッダ値およびおそらくはプロトコル本体値を含む属性。
Some OPES services may need to be invoked for all user requests or server responses, such as services with logging functionality, for example. The rule system SHOULD allow unconditional rules rather than requiring rule authors to specify rule conditions that are always true.
いくつかのOPESサービスは、例えば、ログ記録機能を備えたサービスとして、すべてのユーザーの要求やサーバの応答に呼び出される必要があるかもしれません。ルールシステムではなく、常に真であるルールの条件を指定するには、ルールの作成者を必要とするよりも、無条件のルールを可能にしなければなりません。
The rule system MUST allow for the specification of rule actions that are triggered if the conditions of a rule are met. Matched rules typically lead to the invocation of local or remote services. Rule actions MUST identify the OPES service that is to be executed for the current message request or response.
ルールシステムは、ルールの条件が満たされた場合にトリガされたルールのアクションの仕様を考慮しなければなりません。一致したルールは、通常、ローカルまたはリモートサービスの呼び出しにつながります。ルールのアクションは、現在のメッセージの要求または応答のために実行されるOPESサービスを特定しなければなりません。
Rule actions MAY contain run-time parameters which can be used to control the behavior of an OPES service. If specified, these parameters MUST be passed to the executed OPES service.
ルールのアクションは、OPESサービスの動作を制御するために使用することができる実行時パラメータを含むかもしれません。指定された場合は、これらのパラメータは、実行OPESサービスに通過しなければなりません。
OPES processors MUST enforce policy requirements set by data consumers and/or data publishers in accordance with the architecture [1] and this document. They cannot do this consistently unless there are an unambiguous semantics and representation of the data elements mentioned in the policy. For example, this document mentions protection of user "identity" and "profile" information. If a user specifies that his identity must not be shared with other OPES administrative trust domains, and later discovers that his family name has been shared, he might complain. If he were told that "family names are not considered 'identities' by this site", he would probably feel that he had cause for complaint. Or, he might be told that when he selected "do not share identity" on a web form offered by the OPES service provider, that this only covered his login name, and that a different part of the form had to be filled out to protect the family name. A further breakdown can occur if the configuration information provided by such a web form gets translated into configuration elements given to an OPES processor, and those configuration elements are difficult for a software engineer to translate into policy enforcement. The data elements might have confusing names or be split into groupings that are difficult to relate to one another.
OPESプロセッサは、アーキテクチャ[1]及び本文書に従って、データ消費者及び/又はデータ・パブリッシャーによって設定されたポリシー要件を適用しなければなりません。明確な意味論と政策に言及したデータ要素の表現がない限り、彼らは一貫してこれを行うことはできません。たとえば、このドキュメントでは、ユーザ「同一性」と「プロファイル」情報の保護に言及しています。ユーザーは自分のアイデンティティが他のOPES行政の信頼ドメインと共有してはならないことを指定し、後で彼の家族の名前が共有されていることを発見した場合、彼は文句を言うかもしれません。彼は「家族の名前は、このサイトによる 『アイデンティティ』とみなされていない」と言われた場合、彼はおそらく彼が苦情のために起こしていたことを感じるだろう。それとも、彼は彼が選択したときに、これが唯一の彼のログイン名をカバーしていること、OPESサービス・プロバイダーが提供するWebフォームの「アイデンティティを共有していない」こと、およびフォームの異なる部分を保護するために記入されなければならなかったと言われるかもしれません家族の名前。このようなウェブの形態によって提供される構成情報がOPESプロセッサに所与の構成要素に翻訳し、これらの構成要素は、ポリシー施行に変換するためのソフトウェアエンジニアのために困難で取得した場合、さらに絶縁破壊が発生する可能性があります。データ要素は、紛らわしい名前を持つ可能性があるか、相互に関連することが困難なグループに分けること。
The examples illustrate why the OPES policy MUST have definitions of data elements, their relationships, and how they relate to enforcement. These semantics of essential items do not require a separate protocol, but they MUST be agreed upon by all OPES service providers, and the users of OPES services MUST be assured that they have the ability to know their settings, to change them if the service provider policy allows the changes, and to have reasonable assurance that they are enforced with reasonable interpretations.
OPESポリシーはデータ要素の定義は、それらの関係、およびそれらがどのように執行に関係を持っていなければならない理由例が示しています。必須項目のこれらのセマンティクスは、別のプロトコルを必要としませんが、それらはすべてOPESサービスプロバイダによって合意されなければならない、とOPESサービスのユーザがサービスプロバイダであればそれらを変更するために、彼らはその設定を知る能力を持っていることを保証しなければなりません政策変更を可能にし、それらが合理的な解釈で施行されていることを合理的な保証を持っています。
The requirements for policy data elements in the OPES specification do not have to be all-inclusive, but they MUST cover the minimal set of elements that enable the policies that protect the data of end users and publishers.
OPES仕様のポリシーデータ要素のための要件は、オールインクルーシブである必要はありませんが、エンドユーザーや出版社のデータを保護するポリシーを有効要素の最小セットをカバーしなければなりません。
This section considers the authorization and authentication of OPES services.
このセクションでは、OPESサービスの許可および認証を検討します。
An OPES rule determines which attributes of traffic will trigger the application of OPES services. The author of the service can supply rules, but the author cannot supply the necessary part of the rule precondition that determines which network users will have the OPES services applied for them. This section discusses how users are identified in the rule preconditions, and how users can select and deselect OPES services for their traffic, how an OPES service provider SHOULD identify the users, and how they determine whether or not to add their service selection to an OPES enforcement point.
OPESルールは、OPESサービスのアプリケーションをトリガーするトラフィックの属性を決定します。サービスの著者は、ルールを供給することができますが、著者は、ネットワークユーザーが彼らのために適用されるOPESサービスを持ってするかを決定するルールの前提の必要な部分を供給することはできません。このセクションでは、ユーザーがルールの前提条件で識別されている方法について説明し、どのようにユーザーが自分のトラフィックのためOPESサービスを選択し、選択解除することができ、OPESサービスプロバイダがユーザーを識別する方法、およびどのように彼らはOPESに彼らのサービスの選択を追加するかどうかを決定します実施ポイント。
An OPES service provider MUST satisfy these major requirements:
OPESサービスプロバイダは、これらの主要な要件を満たしている必要があります。
o Allow all users to request addition, deletion, or blocking of OPES services for their traffic (blocking means "do not use this service for my traffic"). o Prevent untrusted users from causing OPES services to interfere with the traffic of other users. o Allow users to see their OPES service profiles and notify them of changes. o Keep a log of all profile activity for audit purposes. o Adhere to a privacy policy guarding users' profiles.
Oすべてのユーザーが（「私のトラフィックのために、このサービスを使用していない」手段を遮断する）彼らのトラフィックのためOPESサービスの追加、削除、またはブロックを要求することを許可します。 O OPESサービスは、他のユーザのトラフィックに干渉させることから、信頼できないユーザーを防止します。 Oユーザーが自分のOPESサービスプロファイルを参照し、変更内容を通知することを許可します。 O監査の目的のために、すべてのプロファイルのアクティビティのログを保管してください。 Oユーザーのプロファイルを守っプライバシーポリシーに準拠しています。
The administrator of the PDP is a trusted party and can set policy for individuals or groups using out-of-band communication and configuration files. However, users MUST always be able to query the PDP in order to learn what rules apply to their traffic.
PDPの管理者は、信頼できる当事者であるとアウト・オブ・バンド通信およびコンフィギュレーションファイルを使用して、個人またはグループのためのポリシーを設定することができます。ただし、ユーザーが常にルールがそのトラフィックに適用するものを学ぶために、PDPを照会することができなければなりません。
Rules can be deposited in the PDP with no precondition relating to network users. This is the way rules are packaged with an OPES service when it is delivered for installation. The PDP is responsible for binding identities to the rules and transmitting them to the PEP. The identity used by the PDP for policy decisions MUST be strictly mapped to the identity used by the PEP. Thus, if a user goes through an identification and authentication procedure with the PDP and is known by identity "A", and if the PEP uses IP addresses for identities, then the PDP MUST provide the PEP with a binding between "A" and A's current IP address.
ルールは、ネットワークユーザに関連がない前提でPDPに堆積することができます。これは、それがインストール用に配信されたときにルールがOPESサービスとパッケージ化されている方法です。 PDPは、規則にアイデンティティを結合し、PEPにそれらを送信するための責任があります。政策決定のためのPDPで使用されるIDは厳密にPEPが使用するIDにマップする必要があります。これにより、ユーザは、PDPとの識別と認証手続きを経て、「A」のIDで知られており、PEPはアイデンティティのためのIPアドレスを使用している場合、その後、PDPは、「A」の間の結合とAさんとのPEPを提供しなければならない場合現在のIPアドレス。
An OPES service provider acting on behalf of different publishing sites SHOULD keep all the above considerations in mind when implementing an OPES site. Because each publishing site may be represented by only a single identity, the authentication and authorization databases may be easier for the PEP to handle.
OPESサイトを実装する際に異なる発行サイトのために行動するOPESサービスプロバイダは、心の中で上記のすべての考慮事項を維持する必要があります。各発行サイトは、単一のアイデンティティで表すことができるので、認証と承認のデータベースはPEPが処理しやすいかもしれません。
Authentication may be necessary between PDP's and PEP's, PEP's and callout servers, PEP's and other PEP's, and callout servers and other callout servers, for purposes of validating privacy policies. In any case where user data or traffic crosses trust domain boundaries, the originating trust domain SHOULD have a policy describing which other domains are trusted, and it SHOULD authenticate the domains and their policies before forwarding information.
認証は、プライバシーポリシーを検証する目的で、PDPのとPEPの、PEPのとコールアウトサーバ、PEPのおよび他のPEPの、およびコールアウトサーバや他のコールアウトサーバ間で必要になる場合があります。ユーザデータまたはトラフィックが信頼ドメインの境界を横切るいずれの場合も、元の信頼ドメインは、他のドメインが信頼され、それが情報を転送する前に、ドメインとそのポリシーを認証する記述したポリシーを持っているべきです。
When an individual selects (or deselects) an OPES service, the individual MUST be authenticated by the OPES service provider. This means that a binding between the user's communication channel and an identity known to the service provider is made in a secure manner. This SHOULD be done using a strong authentication method with a public key certificate for the user; this will be helpful in resolving later disputes. It is recommended that the service provider keep a log of all requests for OPES services. The service provider SHOULD use public key certificates to authenticate responses to requests.
場合、個々の選択（または選択解除）OPESサービス、個人がOPESサービス・プロバイダによって認証されなければなりません。これは、ユーザの通信チャネルとサービスプロバイダに知られている同一の間の結合は、安全な方法で行われることを意味します。これは、ユーザーの公開鍵証明書を持つ強力な認証方式を使用して行われるべきです。これは、後に紛争を解決に役立つであろう。サービスプロバイダがOPESサービスに対するすべての要求のログを保存することをお勧めします。サービスプロバイダは、要求への応答を認証するために公開鍵証明書を使用すべきです。
The service provider may have trusted users who through explicit or implicit contract can assign, remove, or block OPES services for particular users. The trusted users MUST be authenticated before being allowed to take actions which will modify the policy base, and thus, the actions of the PEP's.
サービスプロバイダは、明示的または暗黙の契約を通じて、割り当て、削除、または特定のユーザーのためOPESサービスをブロックすることができ、ユーザーに信頼されている可能性があります。信頼されたユーザーは、ポリシーベースを修正するアクションを実行するために許可される前に、認証、およびPEPののように、行動しなければなりません。
Because of the sensitivity of user profiles, the PEP Interface between the PEP and the PDP MUST use a secure transport protocol. The PEP's MUST adhere to the privacy preferences of the users.
なぜならユーザプロファイルの感度、PEPとPDPの間のPEPインターフェースは、セキュアトランスポートプロトコルを使用しなければなりません。 PEPのは、ユーザーのプライバシー設定に準拠する必要があります。
When an OPES service provider accepts an OPES service, there MUST be a unique name for the service provided by the entity publishing the service. Users MAY refer to the unique name when requesting a service. The unique name MUST be used when notifying users about their service profiles. PEP's MUST be aware of the unique name for each service that can be accessed from their domain. There MUST be a cryptographic binding between the unique name and the entity responsible for the functional behavior of the service, i.e., if it is a human language translating service, then the name of company that wrote the software SHOULD be bound to the unique name.
OPESサービスプロバイダは、OPESサービスを受け付けると、サービスを公開するエンティティによって提供されるサービスの一意の名前があるに違いありません。サービスを要求する場合、ユーザーは、一意の名前を参照することができます。そのサービスプロファイルをユーザーに通知する際に一意の名前を使用しなければなりません。 PEPのは、彼らのドメインからアクセスできる各サービスの固有の名前を知っていなければなりません。それは人間の言語の翻訳サービスである場合、すなわち、その後、ソフトウェアを書いた会社の名前は一意の名前にバインドする必要があり、固有の名前とサービスの機能上の動作を担当するエンティティ間の暗号結合があるに違いありません。
In addition to requesting or terminating specific services, users MAY block particular services, indicating that the services should not be applied to their traffic. The "block all OPES" directive MUST be supported on a per user basis.
特定のサービスを要求するか、終了することに加えて、ユーザは、サービスがそのトラフィックに適用されるべきでないことを示す、特定のサービスを遮断することができます。 「ブロックすべてOPES」ディレクティブは、ユーザーごとにサポートしなければなりません。
A response to a request for an OPES service can be positive or negative. Reasons for a negative response include "service unknown" or "service denied by PDP policy". Positive responses SHOULD include the identity of the requestor and the service and the type of request.
OPESサービスの要求に対する応答は、正または負とすることができます。否定応答の理由は「不明なサービス」または「PDPポリシーによって拒否されたサービス」が挙げられます。陽性反応は、要求者のアイデンティティとサービス要求の種類を含むべきです。
As described in the OPES Architecture [1], requests for OPES services originate in either the end user or the publisher domain. The PDP bases its authorization decision on the requestor and the domain. There are some cases where the decision may be complicated.
OPESアーキテクチャで説明したように、[1]、OPESサービスに対する要求は、エンドユーザーやパブリッシャードメインのいずれかに由来します。 PDPは、要求者とドメイン上の認可判断を根拠と。決定が複雑になる場合があります。
o The end user has blocked a service, but a trusted user of the PDP wants it applied anyway. In this case, the end user SHOULD prevail, unless there are security or legal reasons to leave it in place. o The publisher and the end user are in the same domain. If the publisher and end user are both clients of a PDP, can they make requests that effect each other's processing? In this case, the PDP MUST have policy rules naming the identities that are allowed to set such rules. o The publisher requests a service for an end user. In this case, where the PDP and PEP are in the publisher's administrative domain, the publisher has some way of identifying the end user and his traffic, and the PDP MUST enable the PEP to enforce the policy. This is allowed, but the PDP MUST use strong methods to identify the user and his traffic. The user MUST be able to request and receive information about the service profile that a publisher site keeps about him. o The end user requests a service specific to a publisher's identity (e.g., nfl.com), but the publisher prohibits the service (e.g., through a "NO OPES" application header). As in the case above, the publisher MUST be able to request and receive profile information that a user keeps about a publisher.
Oエンドユーザはサービスをブロックしたが、PDPの信頼されたユーザーは、それがとにかく適用したいと考えています。場所にそれを残すために、セキュリティや法的な理由がない限りこの場合、エンドユーザは、優先すべきです。 oを発行者とエンドユーザーは、同じドメイン内にあります。出版社やエンドユーザがPDPの両方のクライアントであれば、彼らはその旨互いの処理要求を行うことができますか？この場合、PDPは、このようなルールを設定することが許可されているアイデンティティを命名ポリシールールを持たなければなりません。 O発行者は、エンドユーザーのためのサービスを要求します。 PDPとPEPは、出版社の管理ドメイン内にある。この場合では、出版社は、エンドユーザーと彼のトラフィックを識別するいくつかの方法があり、PDPは、ポリシーを適用するためにPEPを有効にする必要があります。これは許可されていますが、PDPは、ユーザーと彼のトラフィックを識別するための強力な方法を使用しなければなりません。ユーザーは、出版社のサイトは彼について続けるためのサービスプロファイルに関する情報を要求し、受け取ることができなければなりません。 Oエンドユーザは、発行者のアイデンティティ（例えば、nfl.com）に特定のサービスを要求するが、出版社は（「NO OPES」アプリケーションヘッダを介して、例えば、）サービスを禁止します。上記と同様に、サイト運営者は、ユーザーがサイト運営者について続けることプロファイル情報を要求し、受け取ることができなければなりません。
In general, the PDP SHOULD keep its policy base in a manner that makes the decision procedure for all cases easy to understand.
一般的に、PDPは、理解しやすい、すべてのケースのための決定手続きを行う方法で、その政策の基盤を維持する必要があります。
5.4.1. Integrity and Confidentiality of Authentication and Requests/ Responses for Service
5.4.1. 認証およびサービスに対する要求/応答の完全性と機密性
The requests and responses SHOULD be cryptographically tied to the identities of the requestor and responder, and the messages SHOULD NOT be alterable without detection. A certificate-based digital signature is strongly recommended as part of the authentication process. A binding between the request and response SHOULD be established using a well-founded cryptographic means, to show that the response is made in reply to a specific request.
要求と応答は、暗号要求者と応答者のアイデンティティに接続する必要があり、そしてメッセージが検出されず、変更可能であるべきではありません。証明書ベースのデジタル署名が強く、認証プロセスの一部として推奨されています。要求と応答との間の結合反応は、特定の要求に対する応答で行われることを示すために、十分な根拠暗号化手段を使用して確立されるべきです。
As directed by the PEP, content will be transformed in whole or in part by OPES services. This means that end-to-end cryptographic protections cannot be used. This is probably acceptable for the vast majority of traffic, but in cases where a lesser form of content protection is desirable, hop-by-hop protections can be used instead. The requirements for such protections are:
PEPによって指示されるように、コンテンツは、OPESサービスによって全体的にまたは部分的に変換されます。これは、エンドツーエンドの暗号化保護は使用できないことを意味します。これは、トラフィックの大部分のために、おそらく許容可能であるが、コンテンツ保護の少ない形が望ましい場合には、ホップバイホップの保護を代わりに使用することができます。このような保護のための要件は次のとおりです。
o Integrity using shared secrets MUST be used between all processing points, end-to-end (i.e., the two ends of a "hop" MUST share a secret, but the secret can be different between "hops"). The processing points include the callout servers. o Encryption can be requested separately, with the same secret sharing requirement between "hops". When requested, encryption applies to all processing points, including callout servers. o The signal for integrity (and optionally encryption) MUST originate from either the requestor (in which case it is applied to the response as well) or the responder (in which case it covers only the response). o The shared secrets MUST be unique (to within a very large probabilistic certainty) for each requestor/responder pair. This helps to protect the privacy of end user data from insider attacks or configuration errors while it transits the provider's network.
O共有秘密を使用して整合性は、すべての加工点との間で使用されなければならない、エンド・ツー・エンド（すなわち、両端「ホップ」の秘密を共有しなければならないが、秘密は「ホップ」の間で異なっていてもよいです）。処理ポイントは、コールアウトサーバが含まれます。 O暗号化は、「ホップ」の間で同じ秘密分散要件を、個別に要求することができます。要求された場合、暗号化は、コールアウトサーバを含め、すべての処理ポイントに適用されます。完全性（および必要に応じて暗号化）するための信号（それは同様に反応に適用した場合）のいずれかリクエスタから発信する必要があり、またはレスポンダO（その場合にのみ応答をカバーします）。 O共有秘密は、各リクエスタ/応答ペアの（非常に大きな確率的確実性内に）一意でなければなりません。これは、プロバイダのネットワークを通過しながら、インサイダー攻撃や設定ミスからエンドユーザーのデータのプライバシーを保護するのに役立ちます。
The PDP MUST have a privacy policy regarding OPES data such as user profiles for services. Users MUST be able to limit the promulgation of their profile data and their identities.
PDPは、このようなサービスのためのユーザプロファイルとしてOPESデータに関するプライバシーポリシーを持たなければなりません。ユーザーは、自分のプロファイルデータとそのアイデンティティの公布を制限することができなければなりません。
Supported limitations MUST include:
サポートされている制限事項が含まれている必要があります
o The ability to prevent Identity from being given to callout servers.
コールアウトサーバに与えられているからアイデンティティを防ぐ能力O。
o The ability to prevent Profile information from being shared. o The ability to prevent Traffic data from being sent to callout servers run by third parties. o The ability to prevent Traffic from particular sites from being given to OPES callout servers.
共有されるからプロファイル情報を防ぐ能力O。第三者が運営するコールアウトサーバに送信されたトラフィックデータを防ぐ能力O。 OPESコールアウトサーバに与えられているから特定のサイトからのトラフィックを阻止する能力は、O。
When an OPES service is provided by a third-party, it MUST have a privacy policy and identify itself to upstream and downstream parties, telling them how to access its privacy policy. A mechanism is needed to specify these preferences and a protocol to distribute them (see section 3.3).
OPESサービスは、サードパーティから提供された場合は、プライバシーポリシーを持っていなければならず、そのプライバシーポリシーにアクセスするためにそれらをどのように言って、パーティーを上流と下流に自身を識別します。機構は、これらの設定し、それらを配布するプロトコルを指定するために必要とされる（セクション3.3を参照）。
This document discusses policy, authorization and enforcement requirements of OPES. In [3] multiple security and privacy issues related to the OPES services are discussed.
この文書は、OPESの方針、承認及び執行要件について説明します。 OPESサービスに関連した[3]複数のセキュリティとプライバシーの問題で議論されています。
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[1] Barbir、A.、Penno、R.、陳、R.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのためのアーキテクチャ（OPES）"、RFC 3835、2004年8月。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[2]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[3] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.
[3] Barbir、A.、Batuner、O.、スリニバス、B.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのセキュリティ脅威とリスク（OPES）"、RFC 3837、2004年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[5]ムーア、B.、Ellesson、E.、Strassner、J.、およびA. Westerinen、 "方針コア情報モデル - バージョン1つの仕"、RFC 3060、2001年2月。
[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[6] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、およびS 。Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、2001年11月。
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[7]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[8] Christensen, et al., Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001, http://www.w3.org/TR/wsdl
[8]クリステンセンら、Webサービス記述言語（WSDL）1.1、W3Cノート2001年3月15日、http://www.w3.org/TR/wsdl
Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Condry (Intel), Randy Presuhn (Mindspring), and B. Srinivas (Nokia).
アンドレアスTerzis、L. Rafalow（IBM）、L.ヤン（インテル）、M. Condry（インテル）、ランディPresuhn（MindSpringの）、およびB. Srinivas氏（ノキア）に感謝します。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
アビーBarbir Nortel Networksの3500カーリングアベニューオタワ、オンタリオK2H 8E9カナダ電話：+1 613 763 5229 Eメール：abbieb@nortelnetworks.com
Oskar Batuner Consultant EMail: batuner@attbi.com
オスカーBatunerコンサルタント電子メール：batuner@attbi.com
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA EMail: abeck@bell-labs.com
アンドレ・ベックルーセント・テクノロジーズ101 Crawfordsコーナー道路ホルムデル、NJ 07733 USA電子メール：abeck@bell-labs.com
Tat Chan Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: Tat.Chan@nokia.com
タットチャンノキア5ウェイサイド道路バーリントン、MA 01803 USA電子メール：Tat.Chan@nokia.com
Hilarie Orman Purple Streak Development EMail: ho@alum.mit.edu
ヒラリーオーマンパープルストリーク開発メール：ho@alum.mit.edu
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 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 HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。