[要約] RFC 3838は、Open Pluggable Edge Services（OPES）のポリシー、認可、および強制要件に関するものです。その目的は、OPESアーキテクチャのセキュリティとプライバシーの要件を定義し、OPESサービスプロバイダーが適切な認可とポリシーの実装を行うためのガイドラインを提供することです。
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)
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）The Internet Society（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.
Open Pluggable Edge Services（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では、ポリシーフレームワークを検討します。セクション3では、インターフェイスの要件について説明しますが、セクション4では、プリンシパルの認証とサービスの承認を調べます。
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.
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommented "、" "、" 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]の3つのコンポーネントに分解されます。ルール著者は、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は、指定されたルールがRule Authors Authorityの範囲内であることを確認する必要があります。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.
アクションの実行（つまり、ルールのトリガー）は、メッセージプロパティ値の変更につながる可能性があります。たとえば、状況によってはJPEG画像をGIF画像に変換する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プロセッサ、およびデータプロバイダーアプリケーションの間の典型的なメッセージデータフローを示しています。数字1〜4で識別される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が特定のインスタンスに汎用名を解決することをサポートする必要があります。SLPやUDDIなどのサービスを使用して、一般的なサービス名を特定のOPESサービスインスタンスに解決することができます。
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.
環境変数を使用して、サービス間の状態情報を渡すことができます。たとえば、リクエストまたはリクエストの変更の分析は、要求パス上の他のサービスまたはその要求に関連する応答に関するサービスに渡すことができる状態情報としてキャプチャする必要がある場合があります。
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]およびこのドキュメントに従って、データ消費者および/またはデータパブリッシャーによって設定されたポリシー要件を実施する必要があります。ポリシーに記載されているデータ要素の明確なセマンティクスと表現がない限り、彼らは一貫してこれを行うことはできません。たとえば、このドキュメントでは、ユーザーの「ID」と「プロファイル」情報の保護が言及されています。ユーザーが自分の身元を他のOpes Administrative Trustドメインと共有してはならないことを指定し、後で彼の姓が共有されていることを発見した場合、彼は文句を言うかもしれません。「姓はこのサイトによって「アイデンティティ」とは見なされない」と言われた場合、彼はおそらく彼が苦情の原因を持っていると感じるでしょう。または、Opesサービスプロバイダーが提供するWebフォームに「アイデンティティを共有しない」を選択したとき、これは彼のログイン名のみをカバーし、フォームの別の部分を保護するために記入する必要があると言われるかもしれません。姓。このような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サービスプロバイダーがユーザーを識別する方法、およびオペスにサービス選択を追加するかどうかを判断する方法について説明します。施行ポイント。
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を使用して識別と認証手順を実行し、ID「A」で知られている場合、PEPがIPアドレスを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サイトを実装する際に、上記のすべての考慮事項を念頭に置いておく必要があります。各パブリッシングサイトは単一のIDのみで表される可能性があるため、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、Callout Servers、PEPとその他のPEP、およびその他のCalloutサーバーの間で認証が必要になる場合があります。ユーザーデータまたはトラフィックが信頼ドメインの境界を越えている場合には、発信元の信頼ドメインには、他のドメインが信頼されているかを説明するポリシーが必要であり、情報を転送する前にドメインとそのポリシーを認証する必要があります。
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サービスプロバイダーによって認証されなければなりません。これは、ユーザーの通信チャネルとサービスプロバイダーに知られているIDとの間の拘束力が安全な方法で作成されることを意味します。これは、ユーザーの公開キー証明書を使用した強力な認証方法を使用して行う必要があります。これは、後の紛争を解決するのに役立ちます。サービスプロバイダーは、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など）に固有のサービスを要求しますが、パブリッシャーはサービスを禁止しています（たとえば、「opes 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は、すべてのケースの決定手続きを理解しやすくする方法でポリシーベースを維持する必要があります。
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 CalloutサーバーにIDが与えられないようにする機能。
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サードパーティが実行するコールアウトサーバーにトラフィックデータが送信されるのを防ぐ機能。o特定のサイトからのトラフィックがOpes Calloutサーバーに与えられないようにする機能。
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.
このドキュメントでは、OPEのポリシー、承認、および執行要件について説明します。[3]では、OPESサービスに関連する複数のセキュリティおよびプライバシーの問題について説明します。
[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.、Chen、R.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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] Floyd、S。and L. Daigle、「Open Pluggable Edge Servicesの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.、Srinivas、B.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[5] Moore、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.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-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] Christensen、et al。、Web Services説明言語（WSDL）1.1、W3C Note 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).
Andreas Terzis、L。Rafalow（IBM）、L。Yang（Intel）、M。Condry（Intel）、Randy Presuhn（Mindspring）、およびB. Srinivas（Nokia）に感謝します。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean、Ontario K2H 8e9 Canada：1 613 763 5229メール：abbieb@nortelnetworks.com
Oskar Batuner Consultant EMail: batuner@attbi.com
Oskar Batunerコンサルタントメール：batuner@attbi.com
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA EMail: abeck@bell-labs.com
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel、NJ 07733 USAメール：abeck@bell-labs.com
Tat Chan Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: Tat.Chan@nokia.com
Tat Chan Nokia 5ウェイサイドロードバーリントン、マサチューセッツ州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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。