[要約] 要約：RFC 3914は、Open Pluggable Edge Services（OPES）に関連するIABの考慮事項について説明しています。 目的：このRFCの目的は、OPESアーキテクチャの設計と実装において、IABの考慮事項を適切に扱うためのガイドラインを提供することです。
Network Working Group A. Barbir
Request for Comments: 3914 Nortel Networks
Category: Informational A. Rousskov
The Measurement Factory
October 2004
Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
IABの考慮事項のプラグ可能なエッジサービス（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
概要
IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations.
IETFインターネットアーキテクチャボード（IAB）は、Open Pluggable Edge Services（OPES）フレームワークについて、9つのアーキテクチャレベルの考慮事項を表明しました。このドキュメントでは、Opesがこれらの考慮事項にどのように対処するかについて説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 3
4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 4
5. Notification Considerations . . . . . . . . . . . . . . . . . 5
5.1. Notification versus trace. . . . . . . . . . . . . . . . 6
5.2. An example of an OPES trace for HTTP . . . . . . . . . . 8
5.3. Consideration (3.1) 'Notification' . . . . . . . . . . . 9
5.4. Consideration (3.2) 'Notification' . . . . . . . . . . . 10
6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 10
7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 11
8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 11
9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 12
10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 12
11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
The Open Pluggable Edge Services (OPES) architecture [RFC3835], 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.
Open Pluggable Edge Services（OPES）アーキテクチャ[RFC3835]は、データプロバイダー、データ消費者、およびゼロ以上のOPESプロセッサ間の協力アプリケーションサービス（OPESサービス）を可能にします。検討中のアプリケーションサービスは、データプロバイダーとデータ消費者との間で交換されるアプリケーションレベルのメッセージを分析し、おそらく変換する可能性があります。
In the process of chartering OPES, the IAB made recommendations on issues that OPES solutions should be required to address. These recommendations were formulated in the form of a specific IAB considerations document [RFC3238]. In that document, IAB emphasized that its considerations did not recommend specific solutions and did not mandate specific functional requirements. Addressing an IAB consideration may involve showing appropriate protocol mechanisms or demonstrating that the issue does not apply. Addressing a consideration does not necessarily mean supporting technology implied by the consideration wording.
OPESをチャーター化する過程で、IABは、OPESソリューションを対処する必要があるという問題について推奨しました。これらの推奨事項は、特定のIAB考慮事項文書[RFC3238]の形式で策定されました。その文書では、IABは、その考慮事項は特定のソリューションを推奨せず、特定の機能要件を義務付けていないことを強調しました。IABの考慮事項に対処するには、適切なプロトコルメカニズムを表示するか、問題が適用されないことを実証する場合があります。考慮事項に対処することは、必ずしも検討の文言によって暗示されるサポート技術を意味するわけではありません。
The primary goal of this document is to show that all formal IAB recommendations are addressed by OPES, to the extent that those considerations can be addressed by an IETF working group. The limitations of OPES working group to address certain aspects of IAB considerations are also explicitly documented.
このドキュメントの主な目標は、すべての正式なIABの推奨事項がOPESによって対処されていることを示すことです。これらの考慮事項は、IETFワーキンググループで対処できる範囲で説明します。IABの考慮事項の特定の側面に対処するためのOPESワーキンググループの制限も明示的に文書化されています。
IAB considerations document [RFC3238] contains many informal recommendations. For example, while the IAB informally requires OPES architecture to "protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries", the IAB has chosen to formalize these requirements via a set of more specific recommendations, such as Notification considerations addressed in Section 5.3 and Section 5.4 below. OPES framework addresses informal IAB recommendations by addressing corresponding formal considerations.
IABの考慮事項ドキュメント[RFC3238]には、多くの非公式の推奨事項が含まれています。たとえば、IABは非公式にOPESアーキテクチャを「OPES仲介者による不適切な行動に対するエンドホスト検出と応答をサポートすることにより、エンドツーエンドのデータの整合性を保護する」ために必要ですが、IABは、より具体的なセットを介してこれらの要件を形式化することを選択しました以下のセクション5.3およびセクション5.4で説明されている通知に関する考慮事項などの推奨事項。OPESフレームワークは、対応する正式な考慮事項に対処することにより、非公式のIABの推奨事項に対処します。
There are nine formal IAB considerations [RFC3238] that OPES has to address. In the core of this document are the corresponding nine "Consideration" sections. For each IAB consideration, its section contains general discussion as well as references to specific OPES mechanisms relevant to the consideration.
OPESが対処する必要がある9つの正式なIABの考慮事項[RFC3238]があります。このドキュメントの中核には、対応する9つの「考慮事項」セクションがあります。IABの考慮事項ごとに、そのセクションには一般的な議論と、考慮に関連する特定のOPESメカニズムへの参照が含まれています。
This document does not introduce any new terminology but uses terminology from other OPES documents.
このドキュメントでは、新しい用語を導入するものではなく、他のOPESドキュメントの用語を使用します。
"An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client)." [RFC3238]
「IETFに標準化されたOPESフレームワークは、OPESサービスの使用を、アプリケーションレイヤーのエンドホストの1つ（つまり、コンテンツプロバイダーまたはクライアントのいずれか）によって明示的に許可されることを要求する必要があります。」[RFC3238]
OPES architecture requires that "OPES processors MUST be consented to by either the data consumer or data provider application" [RFC3835]. While this requirement directly satisfies IAB concern, no requirement alone can prevent consent-less introduction of OPES processors. In other words, OPES framework requires one-party consent but cannot guarantee it in the presence of incompliant OPES entities.
OPESアーキテクチャでは、「OPESプロセッサは、データ消費者またはデータプロバイダーアプリケーションのいずれかによって同意する必要があります」[RFC3835]が必要です。この要件はIABの懸念を直接満たしますが、OPESプロセッサの同意のない導入を防ぐことはできません。言い換えれば、OPESフレームワークには1つのパーティの同意が必要ですが、非充実したOPESエンティティの存在下でそれを保証することはできません。
In [RFC3897], the OPES architecture enables concerned parties to detect unwanted OPES processors by examining OPES traces. While the use of traces in OPES is mandatory, a tracing mechanism on its own cannot detect processors that are in violation of OPES specifications. Examples include OPES processors operating in stealth mode. However, the OPES architecture allows the use of content signature to verify the authenticity of performed adaptations. Content signatures is a strong but expensive mechanism that can detect any modifications of signed content provided that the content provider is willing to sign the data and that the client is willing to either check the signature or relay received content to the content provider for signature verification.
[RFC3897]では、OPESアーキテクチャにより、関係者はOPESトレースを調べて不要なOPESプロセッサを検出できます。OPESでのトレースの使用は必須ですが、それ自体のトレースメカニズムは、OPES仕様に違反しているプロセッサを検出することはできません。例には、ステルスモードで動作するOPESプロセッサが含まれます。ただし、OPESアーキテクチャにより、コンテンツ署名を使用して、実行された適応の信頼性を確認できます。コンテンツシグネチャは、コンテンツプロバイダーがデータに署名する意思があり、クライアントが署名コンテンツをコンテンツプロバイダーにリレーして署名検証を確認することをいとわない場合、署名されたコンテンツの変更を検出できる強力でありながら高価なメカニズムです。
OPES entities may copy or otherwise access content without modifying it. Such access cannot be detected using content signatures. Thus, "passive" OPES entities can operate on signed content without the data consumer or provider consent. If content privacy is a concern, then content encryption can be used. A passive processor is no different from any intermediary operating outside of OPES framework. No OPES mechanism (existing or foreseeable) can prevent non-modifying access to content.
Opesエンティティは、コンテンツを変更せずにコピーまたはアクセスする場合があります。このようなアクセスは、コンテンツ署名を使用して検出できません。したがって、「パッシブ」OPESエンティティは、データ消費者またはプロバイダーの同意なしに署名されたコンテンツで動作することができます。コンテンツのプライバシーが懸念される場合、コンテンツの暗号化を使用できます。受動的なプロセッサは、OPESフレームワークの外で動作する中間監督と違いはありません。OPESメカニズム（既存または予見可能）は、コンテンツへの非変更アクセスを防ぐことができません。
In summary, the one-party consent is satisfied by including the corresponding requirement in the IAB architecture document. That requirement alone cannot stop incompliant OPES entities to perform consent-less adaptations, but OPES framework allows for various means of detecting and/or preventing such adaptations. These means typically introduce overheads and require some level of producer-consumer cooperation.
要約すると、IABアーキテクチャドキュメントに対応する要件を含めることにより、1つのパーティの同意が満たされます。その要件だけでも、同意のない適応を実行するために不浸透性のOPESエンティティを停止することはできませんが、OPESフレームワークは、そのような適応を検出および/または防止するさまざまな手段を可能にします。これらの手段は通常、オーバーヘッドを導入し、ある程度の生産者消費者協力を必要とします。
"For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user" [RFC3238].
「IETFに標準化されたOPESフレームワークの場合、OPES仲介者は、エンドユーザーによってIPレイヤーで明示的に対処されなければなりません」[RFC3238]。
The OPES architecture requires that "OPES processors MUST be addressable at the IP layer by the end user (data consumer application)" [RFC3835]. The IAB and the architecture documents mention an important exception: addressing the first OPES processor in a chain of processors is sufficient. That is, a chain of OPES processors is viewed as a single OPES "system" at the address of the first chain element.
OPESアーキテクチャでは、「OPESプロセッサは、エンドユーザー（Data Consumer Application）がIPレイヤーでアドレス指定する必要があります」[RFC3835]が必要です。IABとアーキテクチャ文書は、重要な例外に言及しています。一連のプロセッサで最初のOPESプロセッサに対処するだけで十分です。つまり、OPESプロセッサのチェーンは、最初のチェーン要素のアドレスで単一のOPES「システム」と見なされます。
The notion of a chain is not strictly defined by IAB. For the purpose of addressing this consideration, a group of OPES processors working on a given application transaction is considered. Such a group would necessarily form a single processing chain, with a single "exit" OPES processor (i.e., the processor that adapted the given message last). The OPES architecture essentially requires that last OPES processor to be explicitly addressable at the IP layer by the data consumer application. The chain formation, including its exit point may depend on an application message and other dynamic factors such as time of the day or system load.
チェーンの概念は、IABによって厳密に定義されていません。この考慮事項に対処するために、特定のアプリケーショントランザクションに取り組むOPESプロセッサのグループが考慮されます。このようなグループは、単一の「Exit」Opesプロセッサ（つまり、指定されたメッセージを最後に適応させたプロセッサ）を使用して、必然的に単一の処理チェーンを形成します。OPESアーキテクチャでは、基本的に、Last OpesプロセッサがデータコンシューマーアプリケーションによってIPレイヤーで明示的にアドレス指定できることを要求しています。その終了ポイントを含むチェーンの形成は、アプリケーションメッセージや時間の時間やシステムの負荷などの他の動的要因に依存する場合があります。
Furthermore, if OPES processing is an internal processing step at a data consumer or a data provider application side, then the last OPES processor may reside in a private address space and may not be explicitly addressable from the outside. In such situations, the processing side must designate an addressable point on the same processing chain. That designated point may not be, strictly speaking, an OPES processor, but it will suffice as such as far as IAB considerations are concerned -- the data consumer application will be able to address it explicitly at the IP layer and it will represent the OPES processing chain to the outside world.
さらに、OPES処理がデータ消費者またはデータプロバイダーアプリケーション側の内部処理ステップである場合、最後のOPESプロセッサはプライベートアドレススペースに存在し、外部から明示的にアドレス指定できない場合があります。このような状況では、処理側は同じ処理チェーンのアドレス指定可能なポイントを指定する必要があります。厳密に言えば、その指定されたポイントはOPESプロセッサではないかもしれませんが、IABの考慮事項に関する限り、それは十分になります - データ消費者アプリケーションはIPレイヤーで明示的に対処でき、OPESを表します外の世界へのチェーンの処理。
Designating an addressable processing point avoids the conflict between narrow interpretation of the IAB consideration and real system designs. It is irrational to expect a content provider to provide access to internal hosts participating in content generation, whether OPES processors are involved or not. Moreover, providing such access would serve little practical purpose because internal OPES processors are not likely to be able to answer any data consumer queries, being completely out of content generation context. For example, an OPES processor adding customer-specific information to XML pages may not understand or be aware of any final HTML content that the data consumer application receives and may not be able to map end user request to any internal user identification. Since OPES requires the end of the message processing chain to be addressable, the conflict does not exist. OPES places no requirements on the internal architecture of data producer systems while requiring the entire OPES-related content production "system" to be addressable at the IP layer.
アドレス指定可能な処理ポイントを指定すると、IABの考慮事項の狭い解釈と実際のシステム設計の間の対立が回避されます。OPESプロセッサが関与しているかどうかにかかわらず、コンテンツプロバイダーがコンテンツ生成に参加する内部ホストへのアクセスを提供することを期待することは不合理です。さらに、内部OPESプロセッサは、コンテンツ生成のコンテキストから完全に外れているデータ消費者のクエリに答えることができない可能性が低いため、そのようなアクセスを提供することはほとんど実用的な目的に役立ちません。たとえば、XMLページに顧客固有の情報を追加するOPESプロセッサは、データ消費者アプリケーションが受け取る最終的なHTMLコンテンツを理解していないか、認識していない場合があり、エンドユーザー要求を内部ユーザー識別にマッピングできない場合があります。OPESはメッセージ処理チェーンの終了を扱う必要があるため、競合は存在しません。OPESは、データ生産者システムの内部アーキテクチャに要件を掲載していませんが、OPES関連のコンテンツ生産「システム」全体をIPレイヤーでアドレス指定できるように要求します。
Private Domain | Public Domain | Private Domain
| |
+--------------+ | +-------------+ +--------+
| Data | | | OPES System | |Data |
| Consumer |<--- network -->| with public |<---->|Provider|
| Application | | | IP address | |App |
+--------------+ | +-------------+ +--------+
| |
| |
Figure 1
図1
This section discusses how OPES framework addresses IAB Notification considerations 3.1 and 3.2.
このセクションでは、OPESフレームワークがIAB通知の考慮事項3.1および3.2にどのように対処するかについて説明します。
Before specific considerations are discussed, the relationship between IAB notifications and OPES tracing has to be explained. OPES framework concentrates on tracing rather than notification. The OPES Communications specification [RFC3897] defines "OPES trace" as application message information about OPES entities that adapted the message. Thus, OPES trace follows the application message it traces. The trace is for the recipient of the application message. Traces are implemented as extensions of application protocols being adapted and traced.
具体的な考慮事項を議論する前に、IAB通知とOPESトレースの関係を説明する必要があります。Opesフレームワークは、通知ではなくトレースに集中しています。OPES通信仕様[RFC3897]は、メッセージを適応させたOPESエンティティに関するアプリケーションメッセージ情報として「Opes Trace」を定義しています。したがって、Opes Traceは、トレースするアプリケーションメッセージに従います。トレースは、アプリケーションメッセージの受信者向けです。トレースは、アプリケーションプロトコルの拡張が適応およびトレースされているため実装されます。
As opposed to an OPES trace, provider notification (as implied by IAB) notifies the sender of the application message rather than the recipient. Thus, notifications propagate in the opposite direction of traces. Supporting notifications directly would require a new protocol. Figure 2 illustrates the differences between a trace and notification from a single application message point of view.
OPESトレースとは対照的に、プロバイダー通知（IABが暗示している）は、受信者ではなくアプリケーションメッセージの送信者に通知します。したがって、通知はトレースの反対方向に伝播します。通知を直接サポートするには、新しいプロトコルが必要です。図2は、単一のアプリケーションメッセージの視点からのトレースと通知の違いを示しています。
sender --[message A]--> OPES --[message A']--> recipient
^ V [with trace]
| |
+-<-- [notification] ---+
Figure 2
図2
Since notifications cannot be piggy-backed to application messages, they create new messages and may double the number of messages the sender has to process. The number of messages that need to be proceed is larger if several intermediaries on the message path generate notifications. Associating notifications with application messages may require duplicating application message information in notifications and may require maintaining a sender state until notification is received. These actions increase the performance overhead of notifications.
通知をアプリケーションメッセージに貯めることはできないため、新しいメッセージを作成し、送信者が処理しなければならないメッセージの数を2倍にすることができます。進行する必要があるメッセージの数は、メッセージパス上の複数の仲介者が通知を生成する場合に大きくなります。通知をアプリケーションメッセージに関連付けるには、通知でアプリケーションメッセージ情報を複製する必要があり、通知が受信されるまで送信者状態を維持する必要がある場合があります。これらのアクションは、通知のパフォーマンスオーバーヘッドを増加させます。
The level of available details in notifications versus provider interest in supporting notification is another concern. Experience shows that content providers often require very detailed information about user actions to be interested in notifications at all. For example, Hit Metering protocol [RFC2227] has been designed to supply content providers with proxy cache hit counts, in an effort to reduce cache busting behavior which was caused by content providers desire to get accurate site "access counts". However, the Hit Metering protocol is currently not widely deployed because the protocol does not supply content providers with information such as client IP addresses, browser versions, or cookies.
通知で利用可能な詳細のレベルと、通知のサポートにプロバイダーの関心が別の懸念事項です。経験によると、コンテンツプロバイダーは、通知に全く関心を持つために、ユーザーアクションに関する非常に詳細な情報が必要になることがよくあります。たとえば、HIT Metering Protocol [RFC2227]は、コンテンツプロバイダーが正確なサイト「アクセスカウント」を取得したいと考えているキャッシュバスティング動作を減らすために、プロキシキャッシュヒットカウントをコンテンツプロバイダーに提供するように設計されています。ただし、プロトコルはクライアントIPアドレス、ブラウザバージョン、Cookieなどの情報をコンテンツプロバイダーに提供していないため、HITメータープロトコルは現在広く展開されていません。
Hit Metering experience is relevant because Hit Metering protocol was designed to do for HTTP caching intermediaries what OPES notifications are meant to do for OPES intermediaries. Performance requirements call for state reduction via aggregation of notifications while provider preferences call for state preservation or duplication. Achieving the right balance when two sides belong to different organizations and have different optimization priorities may be impossible.
HTTPキャッシング仲介業者のために行うように設計されたため、HITメータリングエクスペリエンスは関連性があります。パフォーマンス要件は、プロバイダーの選好が州の保存または複製を求める一方で、通知の集約を介して州の削減を求めています。2つの側面が異なる組織に属し、最適化の優先順位が異なる場合に適切なバランスを達成することは不可能かもしれません。
Thus, instead of explicitly supporting notifications at the protocol level, OPES concentrates on tracing facilities. In essence, OPES supports notifications indirectly, using tracing facilities. In other words, the IAB choice of "Notification" label is interpreted as "Notification assistance" (i.e., making notifications meaningful) and is not interpreted as a "Notification protocol".
したがって、プロトコルレベルでの通知を明示的にサポートする代わりに、OPEはトレース施設に集中します。本質的に、Opesはトレース施設を使用して間接的に通知をサポートしています。言い換えれば、「通知」ラベルのIAB選択は「通知支援」（つまり、通知を意味のあるものにする）として解釈され、「通知プロトコル」と解釈されません。
The above concerns call for making notification optional. The OPES architecture allows for an efficient and meaningful notification protocol to be implemented in certain OPES environments. For example, an OPES callout server attached to a gateway or firewall may scan outgoing traffic for signs of worm or virus activity and notify a local Intrusion Detection System (IDS) of potentially compromised hosts (e.g., servers or client PCs) inside the network. Such notifications may use OPES tracing information to pinpoint the infected host (which could be another OPES entity). In this example, notifications are essentially sent back to the content producer (the local network) and use OPES tracing to supply details.
上記の懸念は、通知をオプションにすることを求めています。OPESアーキテクチャにより、特定のOPES環境で効率的で意味のある通知プロトコルを実装できます。たとえば、ゲートウェイまたはファイアウォールに接続されたOPESコールアウトサーバーは、ネットワーク内の潜在的に侵害されたホスト（サーバーやクライアントPCなど）のローカル侵入検知システム（IDS）のローカル侵入検知システム（ID）を通知している場合があります。このような通知は、感染したホストを特定するためにOPESトレース情報を使用する場合があります（これは別のOPESエンティティになる可能性があります）。この例では、通知は基本的にコンテンツプロデューサー（ローカルネットワーク）に送り返され、OPESトレースを使用して詳細を提供します。
Another environment where efficient and meaningful notification using OPES tracing is possible are Content Delivery Networks (CDNs). A CDN node may use multiple content adaptation services to customize generic content supplied by the content producer (a web site). For example, a callout service may insert advertisements for client-local events. The CDN node itself may not understand specifics of the ad insertion algorithm implemented at callout servers. However, the node may use information in the OPES trace (e.g., coming from the callout service) to notify the content producer. Such notifications may be about the number of certain advertisements inserted (i.e., the number of "impressions" delivered to the customer) or even the number of ad "clicks" the customer made (e.g., if the node hosts content linked from the ads). Callout services doing ad insertion may lack details (e.g., a customer ID/address or a web server authentication token) to contact the content producer directly in this case. Thus, OPES trace produced by an OPES service becomes essential in enabling meaningful notifications that the CDN node sends to the content producer.
OPESトレースを使用した効率的で意味のある通知が可能な別の環境は、コンテンツ配信ネットワーク（CDN）です。CDNノードは、コンテンツプロデューサー（Webサイト）が提供する一般的なコンテンツをカスタマイズするために、複数のコンテンツ適応サービスを使用する場合があります。たとえば、Calloutサービスは、クライアントローカルイベントの広告を挿入する場合があります。CDNノード自体は、Calloutサーバーで実装された広告挿入アルゴリズムの詳細を理解できない場合があります。ただし、ノードはOPESトレースの情報（たとえば、コールアウトサービスから来る）を使用してコンテンツプロデューサーに通知する場合があります。このような通知は、挿入された特定の広告の数（つまり、顧客に配信される「インプレッション」の数）または顧客が作成した「クリック」の「クリック」の数（たとえば、ノードが広告からリンクされたコンテンツをホストする場合）である場合があります。。広告挿入を行うコールアウトサービスには、詳細（顧客ID/アドレスやWebサーバー認証トークンなど）が欠けている場合があり、この場合はコンテンツプロデューサーに直接連絡してください。したがって、OPESサービスによって生成されたOPESトレースは、CDNノードがコンテンツプロデューサーに送信する意味のある通知を有効にするために不可欠になります。
The example below illustrates adaptations done to HTTP request at an OPES processor operated by the client ISP. Both original (as sent by an end user) and adapted (as received by the origin web server) requests are shown. The primary adaptation is the modification of HTTP "Accept" header. The secondary adaptation is the addition of an OPES-System HTTP extension header [I-D.ietf-opes-http].
以下の例は、クライアントISPが操作するOPESプロセッサでHTTP要求に加えられた適応を示しています。元の（エンドユーザーによって送信された）と適応された（Origin Webサーバーで受信）リクエストの両方が表示されます。主な適応は、HTTPの「Accept」ヘッダーの変更です。二次適応は、Opes-System HTTP拡張ヘッダー[i-d.ietf-opes-http]の追加です。
GET /pub/WWW/ HTTP/1.1 Host: www.w3.org Accept: text/plain Figure 3
get/pub/www/http/1.1ホスト：www.w3.org Accept：Text/Plain図3
... may be adapted by an ISP OPES system to become:
... ISP Opesシステムによって次のように適応する場合があります。
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8
OPES-System: http://www.isp-example.com/opes/?client-hash=1234567
Figure 4
図4
The example below illustrates adaptations done to HTTP response at an OPES intermediary operated by a Content Distribution Network (CDN). Both original (as sent by the origin web server) and adapted (as received by the end user) responses are shown. The primary adaptation is the conversion from HTML markup to plain text. The secondary adaptation is the addition of an OPES-System HTTP extension header.
以下の例は、コンテンツディストリビューションネットワーク（CDN）が運営するOPES仲介者でHTTP応答に行われた適応を示しています。元の（Origin Webサーバーによって送信された）と適応された（エンドユーザーが受信）応答の両方が示されています。主な適応は、HTMLマークアップからプレーンテキストへの変換です。二次的適応は、Opes-System HTTP拡張ヘッダーの追加です。
HTTP/1.1 200 OK Content-Length: 12345 Content-Encoding: text/html
HTTP/1.1 200 OKコンテンツレングス：12345コンテンツエンコード：Text/HTML
<html><head><h1>Available Documenta...
Figure 5
図5
... may be adapted by a CDN OPES system to become:
...次のようになるためにCDN Opesシステムによって適応される場合があります。
HTTP/1.1 200 OK
Content-Length: 2345
Content-Encoding: text/plain
OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t
AVAILABLE DOCUMENTA... Figure 6
利用可能なドキュメンタ...図6
In the above examples, OPES-System header values contain URIs that may point to OPES-specific documents such as description of the OPES operator and its privacy policy. Those documents may be parameterized to allow for customizations specific to the transaction being traced (e.g., client or even transaction identifier may be used to provide more information about performed adaptations). An OPES-Via header may be used to provide a more detailed trace of specific OPES entities within an OPES System that adapted the message. Traced OPES URIs may be later used to request OPES bypass [RFC3897].
上記の例では、OPESシステムヘッダーの値には、OPESオペレーターの説明やそのプライバシーポリシーなどのOPES固有のドキュメントを指す可能性のあるURIが含まれています。これらのドキュメントは、トレースされるトランザクションに固有のカスタマイズを可能にするためにパラメーター化される場合があります（たとえば、クライアントまたはトランザクション識別子を使用して、実行された適応に関するより多くの情報を提供できます）。OPES-VIAヘッダーを使用して、メッセージを適応させるOPESシステム内の特定のOPESエンティティのより詳細なトレースを提供できます。トレースされたOpes Urisは、後でオペスバイパス[RFC3897]を要求するために使用される場合があります。
"The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider" [RFC3238].
「OPES全体のフレームワークは、コンテンツプロバイダーがコンテンツプロバイダーによって不適切とみなされるOPES仲介者によるクライアント中心のアクションを検出および対応するのを支援する必要があります」[RFC3238]。
OPES tracing mechanisms assist content providers in detecting client-centric actions by OPES intermediaries. Specifically, a compliant OPES intermediary or system notifies a content provider of its presence by including its tracing information in the application protocol requests. An OPES system MUST leave its trace [RFC3897]. Detection assistance has its limitations. Some OPES intermediaries may work exclusively on responses and may not have a chance to trace the request. Moreover, some application protocols may not have explicit requests (e.g., a content push service).
OPESトレースメカニズムは、コンテンツプロバイダーがOPES仲介者によるクライアント中心のアクションを検出するのを支援します。具体的には、準拠したOPES仲介者またはシステムは、アプリケーションプロトコル要求にトレース情報を含めることにより、コンテンツプロバイダーにその存在を通知します。OPESシステムは、そのトレース[RFC3897]を離れる必要があります。検出支援には制限があります。一部のOpes仲間は、回答のみに取り組むことができ、リクエストをトレースする機会がない場合があります。さらに、一部のアプリケーションプロトコルには明示的な要求がない場合があります（たとえば、コンテンツプッシュサービス）。
OPES tracing mechanisms assist content providers in responding to client-centric actions by OPES intermediaries. Specifically, OPES traces MUST include identification of OPES systems and SHOULD include a list of adaptation actions performed on provider's content. This tracing information may be included in the application request. Usually, however, this information will be included in the application response, an adapted version of which does not reach the content provider. If OPES end points cooperate, then notification can be assisted with traces. Content providers that suspect or experience difficulties can do any of the following:
OPESトレースメカニズムは、コンテンツプロバイダーがOPES仲介者によるクライアント中心のアクションに対応するのを支援します。具体的には、OPESトレースにはOPESシステムの識別を含める必要があり、プロバイダーのコンテンツで実行される適応アクションのリストを含める必要があります。このトレース情報は、アプリケーションリクエストに含まれる場合があります。ただし、通常、この情報はアプリケーション応答に含まれ、その適応バージョンはコンテンツプロバイダーに届きません。Opesのエンドポイントが協力する場合、通知は痕跡を支援できます。困難を疑ったり経験したりするコンテンツプロバイダーは、次のいずれかを行うことができます。
o Check whether requests they receive pass through OPES intermediaries. Presence of OPES tracing info will determine that. This check is only possible for request/response protocols. For other protocols (e.g., broadcast or push), the provider would have to assume that OPES intermediaries are involved until proven otherwise.
o RequestがOpes仲介業者を通過するかどうかを確認します。OPESトレース情報の存在はそれを決定します。このチェックは、リクエスト/応答プロトコルでのみ可能です。他のプロトコル（ブロードキャストやプッシュなど）の場合、プロバイダーは、OPES仲介者が別の方法で証明されるまで関与していると仮定する必要があります。
o If OPES intermediaries are suspected, request OPES traces from potentially affected user(s). The trace will be a part of the application message received by the user software. If involved parties cooperate, the provider(s) may have access to all the needed information. Certainly, lack of cooperation may hinder access to tracing information. To encourage cooperation, data providers might be able to deny service to uncooperative users.
o OPES仲介者が疑われる場合、潜在的に影響を受けるユーザーからOPESトレースを要求します。トレースは、ユーザーソフトウェアが受信したアプリケーションメッセージの一部になります。関係者が協力する場合、プロバイダーは必要なすべての情報にアクセスできる場合があります。確かに、協力の欠如は、トレース情報へのアクセスを妨げる可能性があります。協力を奨励するために、データプロバイダーは非協力的なユーザーへのサービスを拒否できる可能性があります。
o Some traces may indicate that more information is available by accessing certain resources on the specified OPES intermediary or elsewhere. Content providers may query for more information in this case.
o 一部のトレースは、指定されたOPES仲介業者または他の場所で特定のリソースにアクセスすることにより、より多くの情報が利用可能であることを示している場合があります。コンテンツプロバイダーは、この場合の詳細について質問することができます。
o If everything else fails, providers can enforce no-adaptation policy using appropriate OPES bypass mechanisms and/or end-to-end encryption mechanisms.
o 他のすべてが失敗した場合、プロバイダーは、適切なOPESバイパスメカニズムおよび/またはエンドツーエンド暗号化メカニズムを使用して、適切な適応ポリシーを実施できます。
OPES detection and response assistance is limited to application protocols with support for tracing extensions. For example, HTTP [RFC2616] has such support while DNS over UDP does not.
OPESの検出および応答支援は、トレース拡張機能をサポートするアプリケーションプロトコルに限定されます。たとえば、HTTP [RFC2616]にはこのようなサポートがありますが、UDPを超えるDNSはそうではありません。
"The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries" [RFC3238].
「OPES全体のフレームワークは、エンドユーザーがOPES仲介者の動作を検出するのを支援し、不完全または妥協した仲介者を特定できる可能性がある」[RFC3238]。
OPES tracing mechanisms assist end users in detecting OPES intermediaries. Specifically, a compliant OPES intermediary or system notifies an end user of its presence by including its tracing information in the application protocol messages sent to the client. An OPES system MUST leave its trace [RFC3897]. However, detection assistance has its limitations. Some OPES systems may work exclusively on requests and may not have a chance to trace the response. Moreover, some application protocols may not have explicit responses (e.g., event logging service).
OPESトレースメカニズムは、エンドユーザーがOPES仲介業者を検出するのに役立ちます。具体的には、準拠したOPES仲介者またはシステムは、クライアントに送信されたアプリケーションプロトコルメッセージにトレース情報を含めることにより、エンドユーザーにその存在を通知します。OPESシステムは、そのトレース[RFC3897]を離れる必要があります。ただし、検出支援には制限があります。一部のOPESシステムは、リクエストに応じて独占的に機能する場合があり、応答をトレースする機会がない場合があります。さらに、一部のアプリケーションプロトコルには明示的な応答がない場合があります（例：イベントロギングサービス）。
OPES detection assistance is limited to application protocols with support for tracing extensions. For example, HTTP [RFC2616] has such support while DNS over UDP does not.
OPES検出支援は、トレース拡張機能をサポートするアプリケーションプロトコルに限定されています。たとえば、HTTP [RFC2616]にはこのようなサポートがありますが、UDPを超えるDNSはそうではありません。
"If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider" [RFC3238].
「コンテンツプロバイダーから利用可能なコンテンツの「非視線」バージョンが存在する場合、OPESアーキテクチャは、ユーザーがコンテンツプロバイダーからこの「非オープ」バージョンを取得できないようにしてはなりません」[RFC3238]。
"OPES entities MUST support a bypass feature" [RFC3897]. If an application message includes bypass instructions and an OPES intermediary is not configured to ignore them, the matching OPES intermediary will not process the message. An OPES intermediary may be configured to ignore bypass instructions only if no non-OPES version of content is available. Bypass may generate content errors since some OPES services may be essential but may not be configured as such.
「OPESエンティティはバイパス機能をサポートする必要があります」[RFC3897]。アプリケーションメッセージにバイパス命令が含まれており、OPES仲介がそれらを無視するように構成されていない場合、一致するOPES仲介者はメッセージを処理しません。OPES仲介者は、コンテンツの非OPEバージョンが利用可能でない場合にのみ、バイパス命令を無視するように構成できます。一部のOPESサービスが不可欠かもしれないが、そのように構成されていない可能性があるため、バイパスはコンテンツエラーを生成する場合があります。
Bypass support has limitations similar to the two notification-related considerations above.
バイパスサポートには、上記の2つの通知関連の考慮事項と同様の制限があります。
"OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself" [RFC3238].
「OPESのドキュメントは、これらのサービスをURI解像度自体ではなくURI解像度の結果に適用していると説明する際に明確でなければなりません」[RFC3238]。
"OPES Scenarios and Use Cases" specification [RFC3752] documents content adaptations that are in scope of the OPES framework. Scenarios include content adaptation of requests and responses. These documented adaptations do not include URI resolution. In some environments, it is technically possible to use documented OPES mechanisms to resolve URIs (and other kinds of identifiers or addresses). The OPES framework cannot effectively prevent any specific kind of adaptation.
「OPESシナリオとユースケース」仕様[RFC3752]は、OPESフレームワークの範囲にあるコンテンツの適応を文書化しています。シナリオには、リクエストと応答のコンテンツ適応が含まれます。これらの文書化された適応には、URI解像度は含まれていません。一部の環境では、文書化されたOPESメカニズムを使用してURI（および他の種類の識別子またはアドレス）を解決することができます。OPESフレームワークは、特定の種類の適応を効果的に防ぐことはできません。
For example, a CDN node may substitute domain names in URLs with CDN-chosen IP addresses, essentially performing a URI resolution on behalf of the content producer (i.e., the web site owner). An OPES callout service running on a user PC may rewrite all HTML-embedded advertisement URLs to point to a user-specified local image, essentially performing a URI redirection on behalf of the content consumer (i.e., the end user). Such URI manipulations are outside of the OPES framework scope, but cannot be effectively eliminated from the real world.
たとえば、CDNノードは、CDNを選択したIPアドレスでURLのドメイン名を置き換えることができ、コンテンツプロデューサー（つまり、Webサイトの所有者）に代わってURI解像度を基本的に実行できます。ユーザーPCで実行されているOPESコールアウトサービスは、すべてのHTML埋め込み広告URLを書き換えて、ユーザーが指定したローカル画像を指す場合があり、基本的にコンテンツコンシューマー（つまり、エンドユーザー）に代わってURIリダイレクトを実行します。このようなURI操作は、Opesフレームワークの範囲外ですが、現実の世界から効果的に排除することはできません。
"All proposed services must define their impact on inter- and intra-document reference validity" [RFC3238].
「提案されたすべてのサービスは、文書間の参照妥当性への影響を定義する必要があります」[RFC3238]。
The OPES framework does not propose adaptation services. However, OPES tracing requirements include identification of OPES intermediaries and services (for details, see "Notification" consideration sections in this document). It is required that provided identification can be used to locate information about the OPES intermediaries, including the description of impact on reference validity [RFC3897].
OPESフレームワークは、適応サービスを提案していません。ただし、OPESトレースの要件には、OPES仲介者とサービスの識別が含まれます（詳細については、このドキュメントの「通知」考慮セクションを参照）。識別を使用して、参照有効性への影響の説明を含むOPES仲介者に関する情報を見つけるために使用できることが必要です[RFC3897]。
"Any services that cannot be achieved while respecting the above two considerations may be reviewed as potential requirements for Internet application addressing architecture extensions, but must not be undertaken as ad hoc fixes" [RFC3238].
「上記の2つの考慮事項を尊重しながら達成できないサービスは、インターネットアプリケーションにアドレス指定するアーキテクチャ拡張の潜在的な要件としてレビューされる可能性がありますが、アドホックの修正として実施してはなりません」[RFC3238]。
OPES framework does not contain ad hoc fixes. This document in combination with and other OPES documents should be sufficient to inform service creators of IAB considerations. If a service does URI resolution or silently affects document reference validity, the authors are requested to review service impact on Internet application addressing architecture and work within IETF on potential extension requirements. Such actions would be outside of the current OPES framework.
Opesフレームワークには、アドホックな修正は含まれていません。このドキュメントと組み合わせた文書およびその他のOPESドキュメントは、IABの考慮事項をサービスクリエイターに通知するのに十分である必要があります。サービスがURIの解像度を行うか、ドキュメントの参照の有効性に静かに影響を与える場合、著者は、潜在的な拡張要件に関するIETF内でのアーキテクチャと作業へのインターネットアプリケーションへのサービスへの影響を確認するよう要求されます。このようなアクションは、現在のOPESフレームワークの外にあります。
"The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries" [RFC3238].
「OPES全体のフレームワークは、エンドユーザーがOPES仲介者のプライバシーポリシーを決定するためのメカニズムを提供する必要があります」[RFC3238]。
OPES tracing mechanisms allow end users to identify OPES intermediaries (for details, see "Notification" consideration sections in this document). It is required that provided identification can be used to locate information about the OPES intermediaries, including their privacy policies.
OPESトレースメカニズムにより、エンドユーザーはOPES仲介業者を識別できます（詳細については、このドキュメントの「通知」検討セクションを参照）。識別を使用して、プライバシーポリシーを含むOPES仲介業者に関する情報を見つけるために使用できることが必要です。
The term "privacy policy" is not defined in this context (by IAB or OPES working group). OPES tracing mechanisms allow end users and content providers to identify an OPES system and/or intermediaries. It is believed that once an OPES system is identified, it would be possible to locate relevant information about that system, including information relevant to requesters perception of privacy policy or reference validity.
「プライバシーポリシー」という用語は、このコンテキストでは定義されていません（IABまたはOPESワーキンググループによって）。OPESトレースメカニズムにより、エンドユーザーとコンテンツプロバイダーはOPESシステムおよび/または仲介者を特定できます。OPESシステムが特定されると、プライバシーポリシーまたは参照有効性の認識に関連する情報を含む、そのシステムに関する関連情報を見つけることが可能であると考えられています。
"If OPES is chartered, the OPES working group will also have to explicitly decide and document whether the OPES architecture must be compatible with the use of end-to-end encryption by one or more ends of an OPES-involved session. If OPES was compatible with end-to-end encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends" [RFC3238].
「OPESがチャーターされている場合、Opesワーキンググループは、OPESアーキテクチャがOPES関与セッションの1つ以上の端によるエンドツーエンドの暗号化の使用と互換性があるかどうかを明示的に決定し、文書化する必要があります。エンドツーエンドの暗号化と互換性があるため、これにより、OPESボックスが、IPレイヤーで既知、信頼、明示的に対処され、少なくとも1つの1つによって（復号化キーの提供によって）承認されたものに制限されることが効果的に保証されます。終了」[RFC3238]。
The above quoted requirement was not explicitly listed as on of the IAB considerations, but still needs to be addressed. The context of the quote implies that the phrase "end-to-end encryption" refers to encryption along all links of the end-to-end path, with the OPES intermediaries as encrypting/decrypting participants or hops (e.g., encryption between the provider and the OPES intermediaries, and between the OPES intermediaries and the client).
上記の引用要件は、IABの考慮事項のように明示的にリストされていませんでしたが、それでも対処する必要があります。引用のコンテキストは、「エンドツーエンド暗号化」というフレーズが、エンドツーエンドパスのすべてのリンクに沿った暗号化を指すことを意味します。OPES仲介者、およびOpes仲介者とクライアントの間）。
Since OPES processors are regular hops on the application protocol path, OPES architecture allows for such encryption, provided the application protocol being adapted supports it. Hop-by-hop encryption would do little good for the overall application message path protection if callout services have to receive unencrypted content. To allow for complete link encryption coverage, OPES callout protocol (OCP) supports encryption of OCP connections between an OPES processor and a callout server via optional (negotiated) transport encryption mechanisms [I-D.ietf-opes-ocp-core].
OPESプロセッサはアプリケーションプロトコルパスの定期的なホップであるため、OPESアーキテクチャは、アプリケーションプロトコルがサポートされている場合、そのような暗号化を許可します。コールアウトサービスが暗号化されていないコンテンツを受信する必要がある場合、ホップバイホップ暗号化は、アプリケーションメッセージパス保護全体にほとんど役に立たないでしょう。完全なリンク暗号化カバレッジを可能にするために、OPES Callout Protocol（OCP）は、オプション（ネゴシエートされた）輸送暗号化メカニズム[I-D.IETF-OPES-OCP-CORE]を介してOPESプロセッサとコールアウトサーバー間のOCP接続の暗号化をサポートします。
For example, TLS encryption [RFC2817] can be used among HTTP hops (some of which could be OPES processors) and between each OPES processor and a callout server.
たとえば、TLS暗号化[RFC2817]は、HTTPホップ（その一部はOPESプロセッサである可能性があります）および各OPESプロセッサとコールアウトサーバー間で使用できます。
This document does not define any mechanisms that may be subject to security considerations. This document scope is to address specific IAB considerations. Security of OPES mechanisms are discussed in Security Considerations sections of the corresponding OPES framework documents.
このドキュメントは、セキュリティ上の考慮事項の対象となる可能性のあるメカニズムを定義していません。このドキュメントの範囲は、特定のIABの考慮事項に対処することです。OPESメカニズムのセキュリティは、対応するOPESフレームワークドキュメントのセキュリティに関する考慮事項セクションで説明されています。
For example, OPES tracing mechanisms assist content providers and consumers in protecting content integrity and confidentiality by requiring OPES intermediaries to disclose their presence. Security of the tracing mechanism is discussed in the Security Considerations section of [RFC3897].
たとえば、OPESトレースメカニズムは、OPES仲介者がその存在を開示することを要求することにより、コンテンツプロバイダーと消費者がコンテンツの完全性と機密性を保護するのに役立ちます。トレースメカニズムのセキュリティについては、[RFC3897]のセキュリティに関する考慮事項セクションで説明します。
This document may be perceived as a proof of OPES compliance with IAB implied recommendations. However, this document does not introduce any compliance subjects. Compliance of OPES implementations is defined in other OPES documents discussed above.
このドキュメントは、IABの暗黙の推奨事項へのOPESコンプライアンスの証明として認識される場合があります。ただし、このドキュメントでは、コンプライアンスの科目は導入されていません。OPES実装のコンプライアンスは、上記の他のOPESドキュメントで定義されています。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238] Floyd、S。およびL. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
[RFC3752] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H. and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004.
[RFC3752] Barbir、A.、Burger、E.、Chen、R.、Mchenry、S.、Orman、H。、およびR. Penno、「Open Pluggable Edge Services（OPES）ユースケースと展開シナリオ」、RFC 3752、2004年4月。
[RFC3835] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[RFC3835] Barbir、A.、Penno、R.、Chen、R.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（OPES）のアーキテクチャ」、RFC 3835、2004年8月。
[RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.
[RFC3897] Barbir、A。、「Open Pluggable Edge Services（OPES）エンティティとエンドポイント通信」、RFC 3897、2004年9月。
[RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.
[RFC2227] Mogul、J。およびP. Leach、「HTTPの単純なヒットメタリングと使用制限」、RFC 2227、1997年10月。
[RFC2616] 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.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R。およびS. Lawrence、「HTTP/1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[I-D.ietf-opes-http] Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", Work in Progress, October 2003.
[i-d.ietf-opes-http] rousskov、A。and M. Stecher、「OpesによるHTTP適応」、2003年10月、進行中の作業。
[I-D.ietf-opes-ocp-core] Rousskov, A., "OPES Callout Protocol Core", Work in Progress, November 2003.
[i-d.ietf-opes-ocp-core] Rousskov、A。、「Opes Callout Protocol Core」、2003年11月、作業中。
Authors' Addresses
著者のアドレス
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario CA
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean、オンタリオ州カリフォルニア州
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Alex Rousskov The Measurement Factory
Alex Rousskov測定工場
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、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エディター機能の資金は現在、インターネット協会によって提供されています。