RFC 3238 - IAB Architectural and Policy Considerations for Open Pluggable Edge Services 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3238
タイトル : RFC 3238 - オープンプラグ可能なエッジサービスのためのIABアーキテクチャおよびポリシーの考慮事項
翻訳編集 : 自動生成

[要約] RFC 3238は、オープンプラグ可能なエッジサービスのアーキテクチャとポリシーに関するIABの考慮事項をまとめたものです。このRFCの目的は、エッジサービスの設計と展開における重要な要素となるアーキテクチャとポリシーの考慮事項を提供することです。

Network Working Group                  Internet Architecture Board (IAB)
Request for Comments: 3238                                      S. Floyd
Category: Informational                                        L. Daigle
                                                            January 2002

IAB Architectural and Policy Considerations for Open Pluggable Edge Services

オープンプラグ可能なエッジサービスのためのIABアーキテクチャおよびポリシーの考慮事項

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user.

このドキュメントには、IETFのOpen Pluggable Edge Services（OPES）のチャーターに関連するいくつかのアーキテクチャおよびポリシーの問題に関するIABによるコメントと推奨事項が含まれています。OPEは、たとえば、Origin Serverとクライアントの間のWebプロキシキャッシュなど、ネットワーク内のアプリケーションレベルの仲介者で展開されるサービスです。これらの仲介者は、コンテンツプロバイダーまたはエンドユーザーのいずれかの明示的な同意を得て、コンテンツを変換またはフィルタリングします。

1. Introduction

1. はじめに

Open Pluggable Edge Services (OPES) are services that would be deployed in the network, for example, at a web proxy cache between the origin server and the client, that would transform or filter content. Examples of proposed OPES services include assembling personalized web pages, adding user-specific regional information to web pages, virus scanning, content adaptation for clients with limited bandwidth, language translation, and the like [OPES].

Open Pluggable Edge Services（OPES）は、ネットワークに展開されるサービスです。たとえば、Origin Serverとクライアントの間のWebプロキシキャッシュで、コンテンツを変換またはフィルタリングします。提案されたOPESサービスの例には、パーソナライズされたWebページの組み立て、ユーザー固有の地域情報のWebページへの追加、ウイルススキャン、帯域幅が限られているクライアントのコンテンツ適応、言語翻訳など[OPES]が含まれます。

The question of chartering OPES in the IETF ([OPESBOF1], [OPESBOF2], [OPESBOF3]) and the related controversy in the IETF community ([Carr01], [CDT01], [Morris01], [Orman01], [Routson01]) have raised to the fore several architectural and policy issues about robustness and the end-to-end integrity of data (in terms of the disparities between what the "origin server" makes available and what the client receives). In particular, questions have been raised about the possible requirements, for a protocol to be developed and standardized in the IETF, for that protocol to protect the end-to-end privacy and integrity of data. This document attempts to address some of the architectural and policy issues that have been unresolved in the chartering of OPES, and to come to some common recommendations from the IAB regarding these issues.

IETF（[opesbof1]、[opesbof2]、[opesbof3]）のチャーターオペスの問題とIETFコミュニティの関連論争（[carr01]、[cdt01]、[morris01]、[orman01]、[routson01]）データの堅牢性とエンドツーエンドの整合性に関するいくつかのアーキテクチャおよびポリシーの問題を前面に上げました（「Origin Server」が利用できるものとクライアントが受信するものの間の格差の観点から）。特に、データのエンドツーエンドのプライバシーと整合性を保護するために、IETFでプロトコルを開発および標準化するために、可能な要件について疑問が提起されています。このドキュメントは、OPESのチャーターで解決されていない建築および政策の問題のいくつかに対処し、これらの問題に関してIABからいくつかの一般的な推奨事項に到達しようとします。

The purpose of this document is not to recommend specific solutions for OPES, or even to mandate specific functional requirements. This is also not a recommendation to the IESG about whether or not OPES should be chartered. Instead, these are recommendations on issues that any OPES solutions standardized in the IETF should be required to address, similar to the "Security Considerations" currently required in IETF documents [RFC2316]. As an example, one way to address security issues is to show that appropriate security mechanisms have been provided in the protocol, and another way to address security issues is to demonstrate that no security issues apply to this particular protocol. (Note however that a blanket sentence that "no security issues are involved" is never considered sufficient to address security concerns in a protocol with known security issues.)

このドキュメントの目的は、OPESの特定のソリューションを推奨したり、特定の機能要件を義務付けることでさえないことです。これは、OPESをチャーターするべきかどうかについてのIESGへの推奨でもありません。代わりに、これらは、IETFドキュメント[RFC2316]で現在必要とされている「セキュリティ上の考慮事項」と同様に、IETFに標準化されたOPESソリューションが対処する必要があるという問題に関する推奨事項です。例として、セキュリティの問題に対処する1つの方法は、プロトコルで適切なセキュリティメカニズムが提供されていることを示すことであり、セキュリティの問題に対処する別の方法は、この特定のプロトコルにセキュリティの問題が適用されないことを示すことです。（ただし、「セキュリティの問題がない」というブランケット文は、既知のセキュリティ問題を抱えるプロトコルでセキュリティの懸念に対処するのに十分ではないと考えることは決してないことに注意してください。）

This document will try to make our concerns underlying integrity, privacy, and security as clear as possible. We recommend that the IESG require that OPES documents address integrity, privacy, and security concerns in one way or another, either directly by demonstrating appropriate mechanisms, or by making a convincing case that there are no integrity or privacy concerns relevant to a particular document.

このドキュメントでは、根底にある誠実さ、プライバシー、セキュリティの根底にある懸念を可能な限り明確にしようとします。IESGは、OPESドキュメントが、適切なメカニズムを実証するか、特定のドキュメントに関連する整合性またはプライバシーの懸念がないという説得力のあるケースを作成することにより、何らかの形で、何らかの形での整合性、プライバシー、およびセキュリティの懸念に対処することを要求することをお勧めします。

In particular, it seems unavoidable that at some point in the future some OPES service will perform inappropriately (e.g., a virus scanner rejecting content that does not include a virus), and some OPES intermediary will be compromised either inadvertently or with malicious intent. Given this, it seems necessary for the overall architecture to help protect end-to-end data integrity by addressing, from the beginning of the design process, the requirement of helping end hosts to detect and respond to inappropriate behavior by OPES intermediaries.

特に、将来のある時点で一部のOPESサービスが不適切に機能することは避けられないように思われます（たとえば、ウイルスを含まないコンテンツを拒否するウイルススキャナー）、一部のOPES仲介者は不注意または悪意のある意図で侵害されます。これを考えると、設計プロセスの開始から、エンドホストがOPES仲介業者による不適切な行動を検出して対応するのを支援する要件に対処することにより、エンドツーエンドのデータの整合性を保護するのに役立つ必要があると思われます。

One of the goals of the OPES architecture must be to maintain the robustness long cited as one of the overriding goals of the Internet architecture [Clark88]. Given this, we recommend that the IESG require that the OPES architecture protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries. We note that in this case by "supporting end-host detection", we are referring to supporting detection by the humans responsible for the end hosts at the content provider and client. We would note that many of these concerns about the ability of end hosts to detect and respond to the inappropriate behavior of intermediaries could be applied to the architectures for web caches and content distribution infrastructures even without the additional complication of OPES.

OPESアーキテクチャの目標の1つは、インターネットアーキテクチャの最優先目標の1つとして長い間引用されている堅牢性を維持することです[Clark88]。これを考慮して、IESGは、OPES仲介者による不適切な動作に対するエンドホストの検出と応答をサポートすることにより、OPESアーキテクチャがエンドツーエンドのデータの整合性を保護することを要求することをお勧めします。この場合、「エンドホスト検出のサポート」により、コンテンツプロバイダーとクライアントのエンドホストを担当する人間による検出のサポートをサポートすることに言及していることに注意してください。エンドホストが仲介者の不適切な行動を検出して対応する能力に関するこれらの懸念の多くは、オペーの追加の合併症がなくても、Webキャッシュおよびコンテンツ配信インフラストラクチャのアーキテクチャに適用できることに注意してください。

Each section of the document contains a set of IAB Considerations that we would recommend be addressed by the OPES architecture. Section 6 summarizes by listing all of these considerations in one place.

ドキュメントの各セクションには、OPESアーキテクチャで対処することをお勧めするIABの考慮事項のセットが含まれています。セクション6は、これらすべての考慮事項を1つの場所にリストすることで要約します。

In this document we try to use terminology consistent with RFC 3040 [RFC 3040] and with OPES works in progress.

このドキュメントでは、RFC 3040 [RFC 3040]およびOPES作業が進行中の用語を使用しようとします。

2. Some history of the controversy about chartering OPES

2. チャーターオペスについての論争の歴史

One view on OPES has been that "OPES is deeply evil and the IETF should stay far, far away from this hideous abomination" [ODell01]. Others have suggested that "OPES would reduce both the integrity, and the perception of integrity, of communications over the Internet, and would significantly increase uncertainly about what might have been done to content as it moved through the network", and that therefore the risks of OPES outweigh the benefits [CDT01]. This view of the risks of OPES was revised in later email, based on the proposals from [Carr01], "assuming that certain privacy and integrity protections can be incorporated into the goals of the working group" [Morris01].

Opesの1つの見解は、「Opesは深刻な悪であり、IETFはこの恐ろしい憎悪から遠く離れているはずです」[Odell01]ということです。他の人々は、「Opesは、インターネット上のコミュニケーションの完全性と整合性の認識の両方を減らし、ネットワークを介して移動したときにコンテンツに対して何がなされたかについて不確実に増加するだろう」と示唆している、したがってリスクはリスクOPESの利点を上回る[CDT01]。OPESのリスクのこの見解は、[Carr01]の提案に基づいて、後のメールで修正されました。

One issue concerns the one-party consent model. In the one-party consent model, one of the end-nodes (that is, either the content provider or the end user) is required to explicitly authorize the OPES service, but authorization is not required from both parties. [CDT01] comments that relying only on a one-party consent model in the OPES charter "could facilitate third-party or state-sponsored censorship of Internet content without the knowledge or consent of end users", among other undesirable scenarios.

1つの問題は、一党の同意モデルに関するものです。一党の同意モデルでは、最終ノードの1つ（つまり、コンテンツプロバイダーまたはエンドユーザーのいずれか）がOPESサービスを明示的に承認する必要がありますが、両当事者からの許可は必要ありません。[CDT01] OPESチャーターの1つのパーティ同意モデルのみに依存すると、「エンドユーザーの知識や同意なしにインターネットコンテンツのサードパーティまたは国が後援する検閲が促進される可能性がある」というコメントは、他の望ましくないシナリオの中でもあります。

A natural first question is whether there is any architectural benefit to putting specific services inside the network (e.g., at the application-level web cache) instead of positioning all services either at the content provider or the end user. (Note that we are asking here whether there is architectural benefit, which is not the same as asking if there is a business model.) Client-centric services suggested for OPES include virus scanning, language translation, limited client bandwidth adaptation, request filtering, and adaptation of streaming media, and suggested server-centric services include location-based services and personalized web pages.

自然な最初の質問は、コンテンツプロバイダーまたはエンドユーザーのいずれかですべてのサービスを配置する代わりに、特定のサービスをネットワーク内に（アプリケーションレベルのWebキャッシュに配置する）アーキテクチャの利点があるかどうかです。（ビジネスモデルがあるかどうかを尋ねるのと同じではないアーキテクチャの利点があるかどうかをここで尋ねていることに注意してください。）OPEに提案されたクライアント中心のサービスには、ウイルススキャン、言語翻訳、限られたクライアント帯域幅の適応、リクエストフィルタリング、ストリーミングメディアの適応、および提案されたサーバー中心のサービスには、ロケーションベースのサービスとパーソナライズされたWebページが含まれます。

It seems clear that there can indeed be significant architectural benefit in providing some OPES services inside the network at the application-level OPES intermediary. For example, if some content is already available from a local or regional web cache, and the end user requires some transformation (such as adaptation to a limited-bandwidth path) applied to that data, providing that service at the web cache itself can prevent the wasted bandwidth of having to retrieve more data from the content provider, and at the same time avoid unnecessary delays in providing the service to the end user.

アプリケーションレベルのOPES仲介業者でネットワーク内でいくつかのOPESサービスを提供する際に、実際に重要なアーキテクチャの利点がある可能性があることは明らかです。たとえば、一部のコンテンツがローカルまたはリージョンのWebキャッシュから既に利用可能であり、エンドユーザーがそのデータに適用されるある程度の変換（限定帯域幅パスへの適応など）を必要とする場合、Webキャッシュ自体でサービス自体が防止できることを提供するコンテンツプロバイダーからより多くのデータを取得しなければならないという無駄な帯域幅は、同時に、エンドユーザーにサービスを提供する不必要な遅延を避けます。

A second question is whether the architectural benefits of providing services in the middle of the network outweigh the architectural costs, such as the potential costs concerning data integrity. This is similar to the issues considered in RFC 3135 [RFC 3135] of the relative costs and benefits of placing performance-enhancing proxies (PEPs) in the middle of a network to address link-related degradations. In the case of PEPs, the potential costs include disabling the end-to-end use of IP layer security mechanisms; introducing a new possible point of failure that is not under the control of the end systems; adding increased difficulty in diagnosing and dealing with failures; and introducing possible complications with asymmetric routing or mobile hosts. RFC 3135 carefully considers these possible costs, the mitigations that can be introduced, and the cases when the benefits of performance-enhancing proxies to the user are likely to outweigh the costs. A similar approach could be applied to OPES services (though we do not attempt that here).

2番目の問題は、データの整合性に関する潜在的なコストなど、ネットワークの途中でサービスを提供することのアーキテクチャの利点が建築コストを上回るかどうかです。これは、リンク関連の劣化に対処するためにネットワークの中央にパフォーマンスを向上させるプロキシ（PEP）を配置することの相対的なコストと利点のRFC 3135 [RFC 3135]で考慮された問題に似ています。PEPSの場合、潜在的なコストには、IPレイヤーセキュリティメカニズムのエンドツーエンドの使用を無効にすることが含まれます。最終システムの制御下にない新しい障害点を導入します。障害の診断と対処に困難が増加する。非対称ルーティングまたはモバイルホストとの合併症の可能性を導入します。RFC 3135は、これらの可能なコスト、導入できる緩和、およびユーザーへのパフォーマンスを向上させるプロキシの利点がコストを上回る可能性が高い場合を慎重に考慮します。同様のアプローチをOPESサービスに適用できます（ただし、ここでは試みません）。

A third question is whether an OPES service, designed primarily for a single retrieval action, has an impact on the application layer addressing architecture. This is related to the integrity issue above, but is independent of whether these services are applied in the middle of the network or at either end.

3番目の質問は、主に単一の検索アクション用に設計されたOPESサービスが、アプリケーションレイヤーアドレス指定アーキテクチャに影響を与えるかどうかです。これは上記の整合性の問題に関連していますが、これらのサービスがネットワークの中央または両端で適用されるかどうかとは無関係です。

Most of this document deals with the specific issue of data integrity with OPES services, including the goal of enabling end hosts to detect and respond to inappropriate behavior from broken or compromised OPES intermediaries.

このドキュメントのほとんどは、OPESサービスとのデータ整合性の特定の問題を扱っています。これには、エンドホストが壊れたOPES仲介業者または侵害された仲介者から不適切な動作を検出および応答できることを可能にするという目標が含まれます。

We agree that one-party consent, with one of the end-hosts explicitly authorizing the OPES service, must be a requirement for OPES to be standardized in the IETF.

OPESサービスを明示的に許可しているエンドホストの1つである1つのパーティの同意は、OPEがIETFに標準化される必要があることに必要であることに同意します。

However, as we discuss in the next section of this document, we agree with [CDT01] that the one-party consent model by itself (e.g., with one of the end-hosts authorizing the OPES service, and the other end-host perhaps being unaware of the OPES service) is insufficient for protecting data integrity in the network. We also agree with

ただし、このドキュメントの次のセクションで説明しているように、[CDT01]は、1つのパーティ同意モデル自体（たとえば、OPESサービスを承認するエンドホストの1つと、おそらくエンドホストが承認されていることに同意します。OPESサービスに気付いていない）は、ネットワーク内のデータの整合性を保護するには不十分です。また同意します

[CDT01] that, regardless of the security and authorization mechanisms standardized for OPES in the IETF, OPES implementations could probably be modified to circumvent these mechanisms, resulting in the unauthorized modification of content. Many of the protocols in the IETF could be modified for anti-social purposes - transport protocols could be modified to evade end-to-end congestion control, routing protocols could be modified to inject invalid routes, web proxy caches could be used for the unauthorized modification of content even without OPES, and so on. None of these seem like compelling reasons not to standardize transport protocols, routing protocols, web caching protocols, or OPES itself. In our view, it means instead that the infrastructure needs, as much as possible, to be designed to detect and defend itself against compromised implementations, and misuses of protocols need to be addressed directly, each in the appropriate venue.

[CDT01] IETFのOPEに標準化されたセキュリティと承認のメカニズムに関係なく、OPESの実装はおそらくこれらのメカニズムを回避するために変更され、コンテンツの不正な変更をもたらすことができます。IETFのプロトコルの多くは反社会的目的で変更できます。輸送プロトコルを変更してエンドツーエンドの混雑制御を回避することができます。ルーティングプロトコルは、無効なルートを注入するために変更できます。OPESなどがなくてもコンテンツの変更など。これらのどれも、輸送プロトコル、ルーティングプロトコル、Webキャッシュプロトコル、またはOPES自体を標準化しないという説得力のある理由のようには見えません。私たちの見解では、その代わりに、インフラストラクチャは、可能な限り、妥協した実装を検出して防御するために設計されることを意味し、プロトコルの誤用はそれぞれ適切な会場で直接対処する必要があります。

Mechanisms such as digital signatures, which help users to verify for themselves that content has not been altered, are a first step towards the detection of the unauthorized modification of content in the network. However, in the case of OPES, additional protection to ensure the end-to-end integrity of data is desirable as well, for example, to help end-users to detect cases where OPES intermediaries were authorized to modify content, but perform inappropriate modifications. We would note that mechanisms can *help* end-users to detect compromised OPES intermediaries in some cases even if they do not *guarantee* that end-users will be able to detect compromised OPES intermediaries in all cases.

ユーザーがコンテンツが変更されていないことを自分で確認するのに役立つデジタル署名などのメカニズムは、ネットワーク内のコンテンツの不正な変更の検出に向けた最初のステップです。ただし、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. Compatibility with end-to-end encryption would also help to prevent the widespread deployment of yet another set of services that, to benefit from, require one to keep one's packet contents in the clear for all to snoop.

OPESがチャーターされている場合、Opesワーキンググループは、OPESが関与したセッションの1つ以上の端によるエンドツーエンドの暗号化の使用と互換性があるかどうかを明示的に決定し、文書化する必要があります。OPESがエンドツーエンドの暗号化と互換性がある場合、これにより、OPESボックスが既知、信頼、IPレイヤーで明示的に対処され、少なくとも復号化キーの提供によって）承認されたものに制限されることを効果的に保証します。終わりの1つ。エンドツーエンドの暗号化との互換性は、すべての人がスヌープするために、自分のパケットコンテンツを明確に保つ必要がある、さらに別のサービスセットの広範な展開を防ぐのにも役立ちます。

IAB Considerations:

IABの考慮事項：

(2.1) One-party consent: 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).

（2.1）一党の同意：IETFに標準化されたOPESフレームワークは、OPESサービスの使用をアプリケーションレイヤーのエンドホストの1つ（つまり、コンテンツプロバイダーまたはクライアントのいずれか）によって明示的に承認することを要求する必要があります。

(2.2) IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user.

（2.2）IP層通信：IETFに標準化されたOPESフレームワークの場合、OPES仲介業者は、エンドユーザーによってIPレイヤーで明示的に対処する必要があります。

We note that (2.2) is not intended to preclude a chain of intermediaries, with the first intermediary in the chain explicitly addressed at the IP layer by the end user.

（2.2）は、エンドユーザーによってIPレイヤーで明示的に対処されているチェーンの最初の仲介者とともに、仲介者のチェーンを排除することを意図していないことに注意してください。

3. End-to-end Integrity

3. エンドツーエンドの完全性

The proposed OPES services have several possible forms, including server-centric services, such as the dynamic assembling of web pages, explicitly authorized by the content provider; client-centric services such as virus scanning or language translation explicitly authorized by the end user to act on the response from the content provider; and client-centric services such as privacy-based services or content-filtering explicitly authorized by the end user to act on the request from the end user to the content provider. We consider the issue of the end-to-end integrity of data separately for these different classes of services.

提案されたOPESサービスには、コンテンツプロバイダーによって明示的に承認されたWebページの動的なアセンブリなど、サーバー中心のサービスを含むいくつかの可能なフォームがあります。ウイルススキャンや言語翻訳などのクライアント中心のサービスは、エンドユーザーがコンテンツプロバイダーからの応答に基づいて行動することを明示的に許可しています。プライバシーベースのサービスやコンテンツフィルタリングなどのクライアント中心のサービスは、エンドユーザーからエンドユーザーからコンテンツプロバイダーへのリクエストに応じて行動することを明示的に許可しています。これらのさまざまなクラスのサービスについて、データのエンドツーエンドの整合性の問題を考慮します。

For each specific service, the question arises of whether it is necessary for both the content provider and the end user to be able to detect and respond to inappropriate behavior by OPES intermediaries, or if it is sufficient for just one of the two end-hosts to have this ability. We don't attempt a general answer, but we do discuss the issues further in the sections below.

特定のサービスごとに、コンテンツプロバイダーとエンドユーザーの両方がOPES仲介業者による不適切な動作を検出および応答できるかどうか、または2つのエンドホストのうちの1つだけに十分であるかどうかという疑問が生じます。この能力を持つこと。一般的な答えは試みませんが、以下のセクションでさらに問題について説明します。

3.1. Data integrity with client-centric OPES services on responses

3.1. 応答に関するクライアント中心のOPESサービスとのデータの整合性

Why is there any concern about the end-to-end integrity of data in a client-centric OPES service acting on a response from a content provider? If the client requests a service such as virus scanning or language translation, why is that of any concern to the content provider one way or another? One answer is that one of the proper concerns of the IETF is to design architectures that enable end-hosts to detect and respond to inappropriate actions in the network. This seems of particular importance for powerful devices in the network such as OPES intermediaries, which are authorized by one of the end-nodes to act on or transform data in the network, but other than that are not under the direct control of that end-node.

コンテンツプロバイダーからの応答に基づいて行動するクライアント中心のOPESサービスにおけるデータのエンドツーエンドの整合性について懸念があるのはなぜですか？クライアントがウイルススキャンや言語翻訳などのサービスを要求した場合、コンテンツプロバイダーにとって何らかの懸念が何らかの形であるのはなぜですか？答えの1つは、IETFの適切な懸念の1つは、エンドホストがネットワーク内の不適切なアクションを検出および応答できるようにするアーキテクチャを設計することです。これは、ネットワーク内のデータに基づいて行動または変換するための最終ノードの1つによって許可されているOPES仲介業者など、ネットワーク内の強力なデバイスにとって特に重要であるように思われますが、それ以外はその終了の直接制御下にありません。ノード。

Consider as an example the services of virus scanning or language translation. The end user has reasonable power in detecting and dealing with imperfect or corrupted virus scanners or language translators that are under her direct control (e.g., on her own machine). The end user knows exactly what program is installed, and has direct access to the content before and after the service is applied. The end user would have less control over similar services offered by OPES in the network itself, where the end user's only control might be the binary one of authorizing or not authorizing the service. (We also note that services deployed on the end host in a self-contained fashion, such as a local virus scanning program, are not a service in the network, and therefore are not in the province of the IETF one way or another.)

例として、ウイルススキャンまたは言語翻訳のサービスを検討してください。エンドユーザーは、不完全または破損したウイルススキャナーまたは彼女の直接制御下にある言語翻訳者（たとえば、自分のマシン）を検出および処理する合理的な力を持っています。エンドユーザーは、どのプログラムがインストールされているかを正確に把握しており、サービスが適用される前後にコンテンツに直接アクセスできます。エンドユーザーは、ネットワーク自体のOPESが提供する同様のサービスに対する制御が少なくなります。エンドユーザーの唯一のコントロールは、サービスを承認または承認していないバイナリのものです。（また、ローカルウイルススキャンプログラムなど、自己完結型の方法でエンドホストに展開されたサービスは、ネットワーク内のサービスではないため、IETFの州に何らかの形でないことに注意してください。）

For a OPES service such as virus scanning or language translation, the end user could detect a corrupted intermediary, but only through a "black-box" approach of comparing the input with the output. This is also imprecise and requires some effort, compared to the effort required to detect a corrupted virus scanner installed on one's own machine. For example, the user could retrieve the "non-OPES" version of the content directly from the content provider, if there is a "non-OPES" version, and compare this with the "OPES" version of the content available from the OPES intermediary. However, in the case of dynamic content, the "non-OPES" version of the content retrieved by the user directly from the content provider might not necessarily be the same as the "non-OPES" version of the content considered by the OPES intermediary. This limited control by the end user of the OPES service, and the limited ability of the end user to detect imperfect or corrupted intermediaries, argues for an architecture that helps the content provider to detect and respond to imperfect or corrupted OPES intermediaries as well.

ウイルススキャンや言語翻訳などのOPESサービスの場合、エンドユーザーは、入力と出力を比較する「ブラックボックス」アプローチを介してのみ、破損した仲介者を検出できます。これも不正確であり、自分のマシンに取り付けられた破損したウイルススキャナーを検出するために必要な努力と比較して、ある程度の努力が必要です。たとえば、ユーザーは、「非オープ」バージョンがある場合、コンテンツプロバイダーからコンテンツの「非オープ」バージョンを直接取得し、OPESから利用可能なコンテンツの「OPES」バージョンと比較できます。仲介者。ただし、動的コンテンツの場合、コンテンツプロバイダーから直接ユーザーが直接取得したコンテンツの「非オープ」バージョンは、OPES仲介者が検討したコンテンツの「非視線」バージョンと必ずしも同じではない場合があります。。OPESサービスのエンドユーザーによるこの制限制御、およびエンドユーザーが不完全または破損した仲介者を検出する能力が限られているため、コンテンツプロバイダーが不完全または破損したOPES仲介者を検出して応答するのに役立つアーキテクチャを主張します。

We consider the specific example of virus scanning, authorized by the end user as an OPES service. One could imagine virus scanning as a widely deployed OPES service, augmenting the virus scanning done on the end host itself. If I ask for, say, a paper by Steve Bellovin on security and viruses in the network, and am informed by my authorized OPES virus-scanning service that this content does not pass the virus-scan, there are a number of possibilities:

エンドユーザーがOPESサービスとして承認したウイルススキャンの具体的な例を検討します。ウイルススキャンが広く展開されているOPESサービスとしてスキャンし、エンドホスト自体で行われたウイルススキャンを強化することを想像できます。たとえば、ネットワーク内のセキュリティとウイルスに関するSteve Bellovinの論文を求め、私の認定Opes Virus-Scanningサービスからこのコンテンツがウイルススキャンに合格しないことを通知された場合、多くの可能性があります。

(1) Unknown to Steve, the content (that is, Steve's paper) contains a harmful virus.

(1) スティーブには知られていない、コンテンツ（つまり、スティーブの論文）には有害なウイルスが含まれています。

(2) Steve inserted a harmful virus in the content on purpose, with playful or malicious intent.

(2) スティーブは、遊び心のあるまたは悪意のある意図を持って、意図的にコンテンツに有害なウイルスを挿入しました。

(3) The OPES virus scanner can't distinguish between a true harmful virus, and Steve's paper about harmful viruses.

(3) OPESウイルススキャナーは、真の有害なウイルスと、有害なウイルスに関するスティーブの論文を区別することはできません。

(4) My local OPES virus scanner has been hacked, with malicious intent, to reject all content from Steve Bellovin.

(4) 私の地元のOpesウイルススキャナーは、Steve Bellovinからすべてのコンテンツを拒否するために、悪意を持ってハッキングされています。

At some point, for some content, some widely-deployed implementation of some OPES virus scanner is likely to result in problem (3), and some OPES implementation is likely to be corrupted to result in problem (4). Because the end user has limited control over the OPES virus scanner, the end user also is limited in its ability to detect problems (3) or (4) in the OPES virus scanner. In addition, the content provider is probably the one with the strongest incentive to detect problems (3) or (4) in the OPES virus scanner. (The content provider generally has a strong incentive to detect problem (1) as well.) In this case, it seems prudent that the overall OPES architecture should be carefully designed to prevent the OPES service of virus scanning, as authorized by the client, from unnecessarily preventing the distribution of content that in fact does not have viruses.

ある時点で、一部のコンテンツについては、一部のOPESウイルススキャナーの広く展開された実装が問題を引き起こす可能性が高く（3）、一部のOPES実装は破損して問題を引き起こす可能性があります（4）。エンドユーザーはOPESウイルススキャナーの制御が制限されているため、エンドユーザーは、OPESウイルススキャナーの問題（3）または（4）を検出する能力も制限されています。さらに、コンテンツプロバイダーは、おそらくOPESウイルススキャナーの問題（3）または（4）を検出する最も強いインセンティブを持つものです。（コンテンツプロバイダーは一般に問題を検出するための強力なインセンティブ（1）も同様です。この場合、クライアントが許可されているように、オペスアーキテクチャ全体がウイルススキャンのOPESサービスを防ぐために慎重に設計する必要があることは賢明なようです。実際にはウイルスがないコンテンツの分布を不必要に防止することから。

Obviously, it is not viable to propose that content providers simply indicate that some content should be passed to the end user without virus scanning - the point of virus scanning is for the end user to exercise control in this regard. However, if some form of end-system notification allows the content provider to find out that the content is being rejected by a virus scanning service instead of being delivered to the end user, then the content provider (Steve, in this case) might want to inform end users that this content is known by the content provider not to pass some OPES virus scanning services. End users could then make their own decisions about whether or not to retrieve that content bypassing the OPES virus scanning service, relying on their own virus scanner or an alternate virus scanning service for this particular content. Such end-system notification to the content provider, if requested, cannot be enforced, and cannot be relied upon from corrupted intermediaries, but it seems important nevertheless.

明らかに、コンテンツプロバイダーがウイルススキャンなしで一部のコンテンツをエンドユーザーに渡す必要があることを単に示すことを提案することは実行不可能です。ウイルススキャンのポイントは、この点でエンドユーザーが制御を行使することです。ただし、何らかの形の最終システム通知を使用すると、コンテンツプロバイダーがエンドユーザーに配信される代わりにウイルススキャンサービスによってコンテンツが拒否されていることを確認できる場合、コンテンツプロバイダー（この場合はSteve）が望む場合があります。エンドユーザーに、このコンテンツがコンテンツプロバイダーがいくつかのOpesウイルススキャンサービスに合格しないことを知らせることを通知するため。エンドユーザーは、OPESウイルススキャンサービスをバイパスするコンテンツを取得するかどうかについて独自の決定を下すことができます。これは、この特定のコンテンツのための独自のウイルススキャナーまたは代替ウイルススキャンサービスに依存しています。コンテンツプロバイダーへのこのような最終システム通知は、要求された場合、執行することはできず、破損した仲介者から依存することはできませんが、それでも重要と思われます。

Of course, malicious users can also use their awareness of the virus scanning service to perfect their ability to construct malicious viruses that can evade the virus scanning service. This will be done anyway, with any virus scanning service, and seems like an acceptable cost to allow content providers some protection against the vagaries of imperfect or corrupted OPES services in the network.

もちろん、悪意のあるユーザーは、ウイルススキャンサービスに対する認識を使用して、ウイルススキャンサービスを回避できる悪意のあるウイルスを構築する能力を完成させることもできます。とにかく、これはウイルススキャンサービスで行われ、コンテンツプロバイダーがネットワーク内の不完全または破損したOPESサービスの気まぐれからある程度の保護を可能にするための許容コストのように思われます。

Thus, for client-requested services such as virus scanning and language translation, it is clearly desirable for the origin server to have notification, if it requests it, that these services are being performed on its content before the content is sent to the client. Any such end-system notification might be accompanied by reduced performance (in terms of overhead, delays, etc.) for the OPES service applied to that content. But some form of end-system notification is clearly necessary if content providers are to be able to detect and respond to actions by OPES intermediaries that are deemed inappropriate by the content provider.

したがって、ウイルススキャンや言語翻訳などのクライアントが要求したサービスの場合、Origin Serverがコンテンツがクライアントに送信される前にコンテンツで実行されていることを要求する場合、Origin Serverが通知を要求することが明確に望ましいです。このような最終システム通知には、そのコンテンツに適用されるOPESサービスのパフォーマンスの低下（オーバーヘッド、遅延など）が伴う場合があります。しかし、コンテンツプロバイダーがコンテンツプロバイダーによって不適切とみなされるOPES仲介者によるアクションを検出して応答できる場合、何らかの形のエンドシステム通知が明らかに必要です。

Similarly for a client-based OPES service of language translation, it is clearly desirable for content providers to be able to inform end users when some content is deemed by the content provider to be incompatible with language translation. In this case, the important issue is not to prevent the OPES language translation from being performed on the content, but instead to give the content provider some mechanism to discover the language translation, and to inform the end user (or more precisely, to inform the end user's host computer) if the content provider believes that this language translation is incompatible with this particular content.

同様に、クライアントベースの言語翻訳のOPESサービスでは、コンテンツプロバイダーがコンテンツプロバイダーによって一部のコンテンツが言語翻訳と互換性がないとみなされた場合、コンテンツプロバイダーがエンドユーザーに通知できることが明らかに望ましいです。この場合、重要な問題は、OPES言語翻訳がコンテンツで実行されるのを防ぐことではなく、コンテンツプロバイダーに言語翻訳を発見するためのメカニズムを提供し、エンドユーザーに通知する（またはより正確には、通知することです。エンドユーザーのホストコンピューター）コンテンツプロバイダーが、この言語翻訳がこの特定のコンテンツと互換性がないと考えている場合。

IAB Considerations:

IABの考慮事項：

(3.1) Notification: 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.

（3.1）通知：OPES全体のフレームワークは、コンテンツプロバイダーによって不適切と見なされるOPES仲介者によるクライアント中心のアクションの検出と対応をコンテンツプロバイダーを支援する必要があります。

3.2. Data integrity with server-centric OPES services

3.2. サーバー中心のOPESサービスとのデータの整合性

What are the concerns, if any, with the end-to-end integrity of data in a server-centric OPES service such as location-based services? For example, CNN could authorize a location-based OPES service, where the OPES intermediary inserts the weather report or news headline of regional interest into the requested web page. The same issue of the detection and response to broken or modified OPES intermediaries occurs with server-centric OPES as with client-centric OPES services. We only consider server-centric services on responses, as we are not aware of any proposals for server-centric OPES services on requests from the client to the content provider.

ロケーションベースのサービスなどのサーバー中心のOPESサービスにおけるデータのエンドツーエンドの整合性がある場合、もしあれば、懸念は何ですか？たとえば、CNNはロケーションベースのOPESサービスを承認することができます。このサービスでは、OPES仲介業者がリクエストされたWebページに気象レポートまたは地域の関心の見出しを挿入します。クライアント中心のOPESサービスと同様に、壊れたまたは修正されたOPES仲介業者に対する検出と応答の同じ問題は、サーバー中心のOPEで発生します。クライアントからコンテンツプロバイダーへのリクエストに応じて、サーバー中心のOPESサービスの提案を認識していないため、回答に関するサーバー中心のサービスのみを検討します。

How are the end-nodes to detect inappropriate actions from OPES services authorized by the content provider? The OPES service is being performed at an OPES intermediary in the network itself, and not under the direct control of the content provider; in particular, the content provider might not have the ability to monitor directly the output of the OPES intermediary. One could argue that the content provider and server-centric OPES intermediary are part of a single distributed application, and can be responsible on their own for detecting and dealing with broken or modified OPES intermediaries, without involving the end user. But this is unconvincing, basically arguing that standardizing protocols for performing OPES services is a network issue properly in the domain of the IETF, but the ensuring the overall integrity of the service is a distributed application matter, and not in the province of the IETF at all. It would seem to us that you can't have it both ways. Simply labeling the content provider and the OPES intermediary as part of the same distributed application does not give the content provider the ability to monitor the actions of the OPES intermediary.

コンテンツプロバイダーによって承認されたOPESサービスから不適切なアクションを検出するための最終ノードはどのようにしていますか？OPESサービスは、コンテンツプロバイダーの直接制御下ではなく、ネットワーク自体のOPES仲介業者で実行されています。特に、コンテンツプロバイダーには、OPES仲介業者の出力を直接監視する機能がない場合があります。コンテンツプロバイダーとサーバー中心のOPES仲介業者は、単一の分散アプリケーションの一部であり、エンドユーザーを巻き込むことなく、壊れたOPES仲介業者または修正された仲介業者を検出および処理することについて独力で責任を負うことができると主張することができます。しかし、これは説得力がありません。基本的には、OPESサービスを実行するための標準化プロトコルがIETFのドメインでネットワークの問題であると主張していますが、サービスの全体的な整合性を保証することは、IETFの州ではなく分散型アプリケーションの問題です。全て。あなたがそれを両方の方法で持つことはできないように思えます。コンテンツプロバイダーとOPES仲介者に同じ分散アプリケーションの一部としてラベルを付けるだけでも、コンテンツプロバイダーにOPES仲介業者のアクションを監視する機能を提供しません。

However, if the end user receives some form of notification that these OPES services have been provided, and has some mechanism for receiving the "non-OPES" content from the content provider without the OPES intermediary's modifications (if there is such a thing as a non-OPES version of the content), then the end user is in a better position to detect and react to inappropriate actions from compromised or poorly-designed OPES intermediaries. Thus, it is clear that some form of end-system notification is required to allow the end user to detect and respond to broken or modified OPES intermediaries. If the end user has notification of action by OPES intermediaries, it could "veto" an OPES service simply by throwing the OPES-modified content away. And if the client wants to talk directly to the origin server to receive the "non-OPES" version, and the origin server is configured to allow this, then the OPES intermediary must be designed to permit this end-to-end communication.

ただし、エンドユーザーがこれらのOPESサービスが提供されているという何らかの形の通知を受け取った場合、OPES仲介者の変更なしにコンテンツプロバイダーから「非OPE」コンテンツを受信するためのメカニズムがある場合（そのようなものがある場合コンテンツの非OPEバージョン）、エンドユーザーは、侵害または設計されていないOPES仲介者から不適切なアクションを検出および対応するためのより良い位置にあります。したがって、エンドユーザーが壊れたOPES仲介または変更された仲介者を検出して応答できるようにするには、何らかの形の最終システム通知が必要であることは明らかです。エンドユーザーがOPES仲介者によるアクションの通知を持っている場合、Opes修正コンテンツを捨てるだけで、Opesサービスを「拒否」することができます。また、クライアントがOrigin Serverに直接通信して「非Opes」バージョンを受信したい場合、Origin Serverがこれを許可するように構成されている場合、OPES仲介はこのエンドツーエンドの通信を許可するように設計する必要があります。

In addition to concerns about detecting and responding to faulty or compromised OPES intermediaries, there are purely policy-based concerns about the integrity of data. If the content provider looks at the source IP address from the HTTP request, or tosses a coin, in order to decide what content to provide, then that is the content provider's business. But if there exists a "non-OPES" version of some content available from the content provider, and also modified versions available from OPES intermediaries, then it is important that end users would be able to discover that they are receiving a modified version from the network, and not the "non-OPES" version that is also available from the content provider directly.

OPES仲介業者の障害を検出および侵害したことに対する懸念に加えて、データの完全性について純粋に政策に基づいた懸念があります。コンテンツプロバイダーが、HTTP要求からソースIPアドレスを調べたり、コインを投げたりする場合、コンテンツを提供するコンテンツを決定する場合、それがコンテンツプロバイダーのビジネスです。ただし、コンテンツプロバイダーから利用可能なコンテンツの「非オープ」バージョンが存在し、OPES仲介者から利用可能な変更バージョンも存在する場合、エンドユーザーは、エンドユーザーが変更されたバージョンを受信していることを発見できることが重要です。ネットワークは、コンテンツプロバイダーから直接入手できる「非オープ」バージョンではありません。

IAB Considerations:

IABの考慮事項：

(3.2) Notification: The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries.

（3.2）通知：OPES全体のフレームワークは、エンドユーザーがOPES仲介業者の動作を検出するのを支援し、不完全または侵害された仲介者を特定できるようにする必要があります。

(3.3) Non-blocking: 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.

（3.3）ノンブロッキング：コンテンツプロバイダーから利用可能なコンテンツの「非オープ」バージョンが存在する場合、OPESアーキテクチャは、ユーザーがコンテンツプロバイダーからこの「非オープ」バージョンを取得できないようにしてはなりません。

3.3. Data integrity with client-centric OPES services on requests

3.3. リクエストに応じて、クライアント中心のOPESサービスとのデータの整合性

There have also been proposals for OPES services authorized by the client on requests from the client to the content provider. Examples include services that remove fields from the HTTP header for added privacy, and content-filtering services that filter requests based on the requested URL. For such services, there is still a need for end hosts to be assisted in detecting and responding to imperfect or corrupted intermediaries, but it seems less clear to what extent this applies to the content provider, and to what extent it applies to the end user that authorized the service. The requirements will probably have to be determined by the OPES and wider IETF communities on a case-by-case basis for each specific service.

また、クライアントからコンテンツプロバイダーへのリクエストに応じて、クライアントによって承認されたOPESサービスの提案もありました。例には、HTTPヘッダーからフィールドを削除してプライバシーを追加するサービス、要求されたURLに基づいてリクエストをフィルタリングするコンテンツフィルタリングサービスが含まれます。このようなサービスの場合、エンドホストが不完全または破損した仲介者の検出と応答を支援する必要がありますが、これがコンテンツプロバイダーにどの程度適用されるか、そしてそれがエンドユーザーにどの程度適用されるかはあまり明確ではないようですそれはサービスを承認しました。要件は、おそらく、特定のサービスごとにケースバイケースでOPESおよびより広いIETFコミュニティによって決定される必要があります。

4. Application Layer Addresses

4. アプリケーションレイヤーアドレス

Most application layer addressing revolves around URIs, which, for the most part, give a structured method to refer to a single data entity on a remote server. URIs are universal in that, in principle, the same result is obtained irrespective of the location of the client performing the resolution.

対処するほとんどのアプリケーションレイヤーは、URIを中心に展開します。これは、ほとんどの場合、リモートサーバー上の単一のデータエンティティを参照する構造化された方法を提供します。URIは、原則として、解像度を実行するクライアントの場所に関係なく同じ結果が得られるという点で普遍的です。

Practice often differs from this theory -- ad-strippers remove data from pages at the client end; web server farms redirect clients to one of several potential target machines for load-balancing or to give the user "localized" content.

多くの場合、練習はこの理論とは異なります。広告ストリッパーは、クライアントの端のページからデータを削除します。Webサーバーファームは、クライアントを、ロードバランスのために、またはユーザーに「ローカライズされた」コンテンツを提供するためのいくつかの潜在的なターゲットマシンの1つにリダイレクトします。

However, from an architectural standpoint, it is important to be clear about what is being done here. In all cases, URI resolution standards (as defined for individual URI schemes, such as HTTP) apply unchanged between the client and the OPES intermediary. What the intermediary does to fulfill the request is not material to the discussion, and must produce a result that is compliant with the applicable URI scheme definition. In this sense, the OPES intermediary is the "endpoint" of URI resolution.

ただし、建築の観点からは、ここで何が行われているかを明確にすることが重要です。すべての場合において、URI解像度標準（HTTPなどの個々のURIスキームに対して定義されている）は、クライアントとOPES仲介者の間に変更されていません。リクエストを満たすために仲介者が行うことは議論の重要なものではなく、該当するURIスキーム定義に準拠した結果を生成する必要があります。この意味で、OPES仲介はURI解像度の「エンドポイント」です。

In client-centric OPES, the intermediary is resolving the URI on behalf of the client, and then applying client-requested services to provide a data response to the client. The client gets the data it wanted, but it did not carry out the URI resolution.

クライアント中心のOPESでは、仲介者はクライアントに代わってURIを解決し、クライアント要求サービスを適用してクライアントにデータ応答を提供します。クライアントは必要なデータを取得しますが、URI解像度は実行されませんでした。

In server-centric OPES, the "origin server" cedes its authority to the intermediary to determine what is the "appropriate" content to supply for a given URI. The client may well perform standard URI resolution, but that reaches no further than the intermediary.

サーバー中心のOpesでは、「Origin Server」は、特定のURIに提供する「適切な」コンテンツとは何かを決定するために、仲介者にその権限を拡張します。クライアントは標準のURI解像度をうまく実行できますが、それは仲介者よりもそれ以上に達します。

With those distinctions firmly in mind, there are two particular areas of concern for OPES-like services.

これらの区別をしっかりと念頭に置いて、Opesのようなサービスには2つの特定の懸念領域があります。

The first is the consideration of the effect of a series of interactions, over time and location (i.e., not just one document retrieval). Potential problems include inconsistencies in intra-and inter-document references -- depending on what content is changed, references from one version of a document might not exist in a modified target, etc.

1つ目は、一連の相互作用の効果を考慮して、時間と場所（つまり、ドキュメントの検索だけでなく）です。潜在的な問題には、ドキュメント内参照の矛盾が含まれます。コンテンツが変更されたコンテンツに応じて、ドキュメントの1つのバージョンからの参照は、変更されたターゲットなどに存在しない場合があります。

The other concern is whether this leads to the creation of content that is exclusively accessible through the use of an intermediary. That is, there is no "non-OPES" version. Either this should not be allowed, or this would argue for an extension to the Internet application layer addressing architecture.

もう1つの懸念は、これが仲介者の使用を通じてのみアクセスできるコンテンツの作成につながるかどうかです。つまり、「非オープ」バージョンはありません。これは許可されるべきではないか、これはアーキテクチャにアドレス指定するインターネットアプリケーションレイヤーの拡張を主張するでしょう。

IAB Considerations:

IABの考慮事項：

(4.1) URI resolution: OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself.

（4.1）URI解像度：OPESドキュメントは、これらのサービスをURI解像度自体ではなく、URI解像度の結果に適用されていると説明する際に明確でなければなりません。

(4.2) Reference validity: All proposed services must define their impact on inter- and intra-document reference validity.

（4.2）参照の妥当性：提案されたすべてのサービスは、文書内および文書内参照の妥当性への影響を定義する必要があります。

(4.3) 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.

（4.3）上記の2つの考慮事項を尊重しながら達成できないサービスは、インターネットアプリケーションにアドレス指定するアーキテクチャ拡張の潜在的な要件としてレビューされる可能性がありますが、アドホックの修正として実施してはなりません。

5. Privacy

5. プライバシー

Intermediaries in the middle of the network increase the number of locations where the privacy of an end-to-end transaction could be compromised. Some of these privacy concerns apply to web caches and CDNs in general as well as specifically to OPES intermediaries. It seems a reasonable requirement, for OPES to be chartered in the IETF, that the issue of providing mechanisms for end users to determine the privacy policies of OPES intermediaries should be addressed. These mechanisms could be quite different for client-centric and server-centric OPES services.

ネットワークの途中の仲介者は、エンドツーエンドのトランザクションのプライバシーが損なわれる可能性のある場所の数を増やします。これらのプライバシーの懸念のいくつかは、一般的にWebキャッシュやCDN、特にOPES仲介者に適用されます。OPEがIETFでチャーターされることは、OPES仲介業者のプライバシーポリシーを決定するためのエンドユーザーにメカニズムを提供するという問題に対処する必要があることが合理的な要件のようです。これらのメカニズムは、クライアント中心およびサーバー中心のOPESサービスではまったく異なる可能性があります。

For a complex issue such as an OPES architecture, which interacts with protocols from other standards bodies as well as from other IETF working groups, it seems necessary to keep in mind the overall picture while, at the same time, breaking out specific parts of the problem to be standardized in particular working groups. Thus, a requirement that the overall OPES architecture address privacy concerns does not necessarily mean that the mechanisms for this need to be developed in the IETF, or in the OPES working group (if it is chartered).

他の標準団体や他のIETFワーキンググループのプロトコルと相互作用するOPESアーキテクチャなどの複雑な問題の場合、全体像を念頭に置いていると同時に、同時に、同時に、の特定の部分を分割する必要があると思われます。特定のワーキンググループで標準化される問題。したがって、OPES全体のアーキテクチャがプライバシーの懸念に対処するという要件は、このメカニズムがIETF、またはOPESワーキンググループ（チャーターされている場合）で開発する必要があることを必ずしも意味するものではありません。

IAB Considerations:

IABの考慮事項：

(5.1) Privacy: The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.

（5.1）プライバシー：OPES全体のフレームワークは、OPES仲介者のプライバシーポリシーを決定するためのエンドユーザーがメカニズムを提供する必要があります。

6. Summary of IAB Considerations

6. IABの考慮事項の概要

(2.2) IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user.

(3.2) Notification: The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries.

(4.1) URI resolution: OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself.

(4.2) Reference validity: All proposed services must define their impact on inter- and intra-document reference validity.

（4.2）参照の妥当性：提案されたすべてのサービスは、文書内および文書内参照の妥当性への影響を定義する必要があります。

(5.1) Privacy: The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.

7. Conclusions

7. 結論

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of OPES in the IETF.

このドキュメントには、IETFのOPESのチャーターに関連するいくつかのアーキテクチャおよびポリシーの問題に関するIABによるコメントと推奨事項が含まれています。

8. Acknowledgements

8. 謝辞

This document has benefited from discussions with members of the IAB and the IESG, contributors to OPES, John Wroclawski, and others. However, this is a document of the IAB, and we do not claim that the other people listed above agree with the contents.

この文書は、IABおよびIESGのメンバー、Opes、John Wroclawskiなどの貢献者との議論から恩恵を受けています。ただし、これはIABの文書であり、上記の他の人が内容に同意しているとは主張していません。

9. References

9. 参考文献

[Carr01] Wayne Carr, "Suggested OPES Requirements for Integrity, Privacy and Security", email to ietf-openproxy@imc.org, August 16, 2001. URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00869.html".

Wayne Carr、「整合性、プライバシー、セキュリティに関するOPESの要件を提案する」、2001年8月16日、ietf-openproxy@imc.orgに電子メール-ARCHIVE/MSG00869.HTML "。

[CDT01] Policy Concerns Raised by Proposed OPES Working Group Efforts, email to the IESG, from the Center for Democracy & Technology, August 3, 2001. URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00828.html".

[CDT01] 2001年8月3日、民主主義＆テクノロジーセンターからのIESGへの電子メール、提案されたOPESワーキンググループの努力によって提起された政策の懸念。/msg00828.html "。

[Clark88] David D. Clark, The Design Philosophy of the DARPA Internet Protocols, SIGCOMM 1988.

[Clark88] David D. Clark、DARPAインターネットプロトコルの設計哲学、Sigcomm 1988。

[Morris01] John Morris, "Re: corrected - Suggested OPES Requirements for Integrity, Privacy and Security", September 28, 2001. Email to ietf-openproxy@imc.org, URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00935.html".

[Morris01] John Morris、「Re：Corrected-整合性、プライバシー、セキュリティのためのOPES要件を提案」、2001年9月28日。ietf -openproxy@imc.orgにメールしてください。-openproxy/mail-archive/msg00935.html "。

[ODell01] Mike O'Dell, "OPES continuing froth...", Message-Id: <200107101341.JAA30276@ccr.org>, July 10, 2001, email to ietf@ietf.org. URL "http://www1.ietf.org/mail-archive/ietf/Current/msg12650.html".

[Odell01] Mike O'Dell、「Opes Continuing Froth ...」、Message-ID：<200107101341.jaa30276@ccr.org>、2001年7月10日、ietf@itf.orgにメールしてください。url "http://www1.ietf.org/mail-archive/ietf/current/msg12650.html"。

[OPES] Open Pluggable Edge Services (OPES) Web Page, "http://www.ietf-opes.org/".

[Opes] Open Pluggable Edge Services（OPES）Webページ、「http://www.ietf-opes.org/」。

[OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda: "http://www.ietf.org/ietf/00dec/opes-agenda.txt". Minutes: "http://www.ietf.cnri.reston.va.us/ proceedings/00dec/toc.htm#P25_256".

[Opesbof1] Opes Bof、49th IETF、2000年12月12日。アジェンダ：「http://www.ietf.org/ietf/00dec/opes-agenda.txt」議事録： "http://www.ietf.cnri.reston.va.us/ Proceedings/00dec/toc.htm＃p25_256" "。

[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes: "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".

[Opesbof2] Opes Bof、50th IETF、2001年3月9日。議事録： "http://www.ietf.org/proceedings/01mar/ietf50-40.htm"。

[OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda: "http://www.ietf.org/ietf/01aug/opes.txt". Minutes: "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".

[Opesbof3] Opes Bof、51st IETF、2001年8月。アジェンダ：「http://www.ietf.org/ietf/01aug/opes.txt」。議事録：「http://www.ietf.org/proceedings/01aug/minutes/opes.htm」。

[Orman01] Hilarie Orman, "Data Integrity for Open Pluggable Services", email to ietf-openproxy@imc.org, August 15, 2001. URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00865.html".

[Orman01] Hilarie Orman、「オープンプラグ可能なサービスのデータの整合性」、2001年8月15日、ietf-openproxy@imc.orgに電子メールを送信します。msg00865.html "。

[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.

[RFC 2316] Bellovin、S。、「IAB Security Architecture Workshopのレポート」、RFC 2316、1998年4月。

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。

[RFC 3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.

[RFC 3040] Cooper、I.、Melve、I.およびG. Tomlinson、「インターネットWebレプリケーションとキャッシュ分類法」、RFC 3040、2001年1月。

[RFC 3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.

[RFC 3135] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の分解を緩和することを目的としたプロキシを向上させるパフォーマンス」、RFC 3135、2001年6月。

[Routson01] Joyce Routson, IETF's Edge Standards Controversy, July 11, 2001, Stardust CDN Week. URL "http://www.stardust.com/cdnweek/articles/2001/07/09/ opes.htm".

[Routson01] Joyce Routson、IETFのEdge Standards論争、2001年7月11日、Stardust CDN Week。url "http://www.stardust.com/cdnweek/articles/2001/07/09/ opes.htm"。

10. Security Considerations

10. セキュリティに関する考慮事項

This document does not propose any new protocols, and therefore does not involve any security considerations in that sense. However, throughout this document there are discussions of the privacy and integrity issues of OPES services and the architectural requirements created by those issues.

このドキュメントは新しいプロトコルを提案していないため、その意味でのセキュリティ上の考慮事項は含まれません。ただし、このドキュメント全体で、OPESサービスのプライバシーと整合性の問題、およびそれらの問題によって作成されたアーキテクチャの要件に関する議論があります。

11. IANA Considerations

11. IANAの考慮事項

There are no IANA considerations regarding this document.

このドキュメントに関するIANAの考慮事項はありません。

Authors' Addresses

著者のアドレス

Internet Architecture Board EMail: iab@iab.org

インターネットアーキテクチャボードメールメール：iab@iab.org

Membership at time this document was completed:

このドキュメントが完了したときのメンバーシップ：

Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Steve Bellovin Brian Carpenter Jon Crowcroft Leslie Daigle Steve Deering Sally Floyd Geoff Huston John Klensin Henning Schulzrinne

ハラルド・アルベスランドはアトキンソン・ロブ・オーストイン・フレッド・ベイカー・ベロヴィン・ブライアン・カーペンタージョン・クロフト・レスリー・デイグル・スティーブ・ディーリング・フロイド・ジェフ・ヒューストン・ジョン・クレンシン・ヘニング・シュルズンヌ

12. Full Copyright Statement

12. 完全な著作権声明

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。