RFC3238 日本語訳
3238 IAB Architectural and Policy Considerations for Open PluggableEdge Services. S. Floyd, L. Daigle. January 2002. (Format: TXT=42336 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Internet Architecture Board (IAB)
Request for Comments: 3238 S. Floyd
Category: Informational L. Daigle
January 2002
ネットワークワーキンググループインターネット・アーキテクチャ委員会(IAB)はコメントのために以下を要求します。 3238秒間フロイドCategory: 情報のL.Daigle2002年1月
IAB Architectural and Policy Considerations for
Open Pluggable Edge Services
開いているPluggable縁のサービスのためのIAB建築するのと方針問題
Status of this Memo
この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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントは建築していた状態でいくつかのIABによるコメントと推薦を含んでいます、そして、政策問題はIETFのオープンPluggable Edge Services(作品)の特許に関連しました。 作品は例えばアプリケーションレベル仲介者で発生源サーバとクライアントの間のウェブプロキシキャッシュでネットワークで配布されるサービスです。 これらの仲介者は、コンテンツプロバイダーかエンドユーザのどちらかの明白な同意で内容を変えるか、またはフィルターにかけるでしょう。
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].
開いているPluggable Edge Services(作品)がネットワークで配布されるサービスである、例えば、発生源サーバとクライアントの間のウェブプロキシキャッシュでは、それは内容を変えるか、またはフィルターにかけるでしょう。 提案された作品サービスに関する例は、個人化されたウェブページを組み立てるのを含んでいます、ウェブページ、ウイルススキャン、限られた帯域幅をもっているクライアントへの満足している適合、言語翻訳、および同様のもの[作品]にユーザ特有の地域情報を追加して。
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
IETF共同体[Carr01]でIETF[OPESBOF1]の作品、[OPESBOF2]、[OPESBOF3)、および関連する論争をチャーターする問題、[CDT01]、[Morris01]、[Orman01]、[Routson01)は丈夫さに関するいくつかの建築するのと方針問題と終わりから終わりへのデータの完全性(「発生源サーバ」が利用可能にするものとクライアントが受けるものの間の不一致に関する)を前面まで提起しました。 そして特に、疑問がプロトコルが開発されるために可能な要件に関して増加した。
IAB Informational [Page 1] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[1ページ]のRFC3238IAB問題
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では、そのプロトコルが終わりから終わりへのプライバシーとデータの完全性を保護するように、標準化されます。 このドキュメントは、作品の特許で未定である建築するのと方針の問題のいくつかを扱って、これらの問題に関して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.)
このドキュメントの目的は、作品のために特定のソリューションを推薦しないか、または特定の機能条件書を強制するのさえことです。 また、これはIESGへの作品が特許であるべきであるかどうか推薦ではありません。 代わりに、これらは扱うIETFで標準化された作品解決が必要であるべきである問題における推薦です、現在IETFドキュメント[RFC2316]で必要である「セキュリティ問題」と同様です。 セキュリティが問題であると扱う別の方法は例として、セキュリティが問題であると扱う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が直接適切な手段のデモをするか、またはそこで説得力がある弁護をそれにすることによってアドレス保全、プライバシー、およびセキュリティがいずれにしてもかかわる作品ドキュメントが特定のドキュメントに関連している保全でない、またプライバシーの問題でないことを必要とするのを推薦します。
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.
特に、未来の何らかのポイントでは、何らかの作品サービスが不適当に(例えば、ウイルスを含んでいない内容を拒絶するウイルス・スキャナー)を実行するのが避けられなく思えて、作品仲介者はうっかりか悪意で感染されるでしょう。 これを考えて、総合的なアーキテクチャが、デザイン過程の始まりから作品仲介者による終わりのホストが不適当行動に検出して、応じるのを助ける要件を扱うことによって終わりから終わりへのデータ保全を保護するのを助けるように必要に思えます。
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
作品アーキテクチャの目標の1つはインターネットアーキテクチャ[Clark88]の最優先の目標の1つが長い間挙げられた丈夫さを維持することでなければなりません。 これを考えて、私たちは、IESGが、作品アーキテクチャが終わりホスト検出と作品仲介者による不適当行動への応答をサポートすることによって終わりから終わりへのデータ保全を保護するのを必要とするのを推薦します。 私たちは、コンテンツプロバイダーとクライアントで終わりのホストに責任がある人間による検出をサポートしながら、「終わりホストに検出をサポートします」でこの場合それに注意すると言及しています。 私たちはこれらの関心のその多くに注意するでしょう。
IAB Informational [Page 2] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[2ページ]のRFC3238IAB問題
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.
ウェブキャッシュと満足している分配インフラストラクチャのために作品の追加複雑さがなくても仲介者の不適当行動に検出して、反応させる終わりのホストの能力をアーキテクチャに適用できました。
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.
それぞれのセクションのドキュメントはIAB Considerationsの1セットを含んでいます。私たちは、作品アーキテクチャによって扱われるように勧めるでしょう。 セクション6はリストで1つの場所でこれらの問題のすべてをまとめます。
In this document we try to use terminology consistent with RFC 3040 [RFC 3040] and with OPES works in progress.
本書では私たちはRFC3040[RFC3040]と作品執筆中の作品と一致した用語を使用しようとします。
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].
作品に関する1つの意見は「作品が深く不吉です、そして、IETFははるかにこのぶざまな醜態を欠席するはずである」という[ODell01]ことです。 他のものは、「作品は、インターネットの上で保全と保全、コミュニケーションの認知の両方を抑えて、ネットワークを通して移行したので内容に何をしたかもしれないかに関して不安にかなり増加し」て、したがって、作品のリスクが利益[CDT01]より重いことを提案しました。 作品のリスクのこの視点は後のメールで改訂されました、[Carr01]からの提案に基づいて、「あるプライバシーと保全保護をワーキンググループの目標に組み入れることができると仮定し」て[Morris01]。
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パーティーの同意モデルに関係があります。 1パーティーの同意モデルでは、エンドノード(すなわち、コンテンツプロバイダーかエンドユーザのどちらか)の1つが明らかに作品サービスを認可するのに必要ですが、承認は双方から必要ではありません。 [CDT01]は、作品特許で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.
自然な最初の質問はコンテンツプロバイダーにすべてのサービスを置くことの代わりにネットワーク(例えば、アプリケーションレベルウェブキャッシュにおける)に特定のサービスを置くことへのどんな建築利益かエンドユーザもいるかどうかということです。 (私たちが、ここで建築利益があるかどうか尋ねていることに注意してください。)利益はビジネスモデルがあるかどうか尋ねるのと同じではありません。 クライアント中心のサービスは、作品のためにストリーミング・メディアのウイルススキャン、言語翻訳、限られたクライアント帯域幅適合、要求フィルタリング、および適合を含めるように示して、サーバ中心のサービスがロケーションベースのサービスを含んでいるのを示して、ウェブページを個人化しました。
IAB Informational [Page 3] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[3ページ]のRFC3238IAB問題
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.
本当に、アプリケーションレベル作品仲介者でいくつかの作品サービスをネットワークに提供するのにおいて重要な建築利益があることができるのは明確に見えます。 例えば、何らかの内容が地方の、または、地方のウェブキャッシュから既に利用可能であり、エンドユーザがそのデータに適用された何らかの変換(限られた帯域幅経路への適合などの)を必要とするなら、ウェブキャッシュ自体におけるサービスが無駄な帯域幅を防ぐことができるなら、そうしなければならないのにおいてコンテンツプロバイダーからの、より多くのデータを検索してください、そして、同時に、エンドユーザに対するサービスを提供する不要な遅れを避けてください。
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番目の質問はネットワークの中央にサービスを提供する建築利益が建築コストより重いかどうかということです、データ保全に関する潜在的コストなどのように。 これは相対的なコストのRFC3135[RFC3135]とネットワークの中央の性能を高める置くプロキシ(PEPs)の利益でリンク関連の転落を扱うと考えられた問題と同様です。 PEPsの場合では、潜在的コストは、IP層のセキュリティー対策の終わりから最終用途を無効にするのを含んでいます。 失敗の新しい可能なポイントを紹介して、それがエンドシステムのコントロールの下にいません。 付加は失敗を診断して、対処しながら、困難を増やしました。 そして、非対称のルーティングかモバイルホストと共に可能な複雑さを導入すること。 ユーザの性能を高めるプロキシの利益がコストより重そうなときに、RFC3135は、これらが可能なコストと、紹介できる緩和と、ケースであると慎重に考えます。 同様のアプローチを作品サービスに適用できました(私たちはここでそれを試みませんが)。
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番目の質問は主としてただ一つの検索動作のために設計された作品サービスが応用層アドレッシング体系に影響を与えるかどうかということです。 これは、上で保全問題に関連されますが、これらのサービスがネットワークの中央で適用されているかどうかの如何にかかわらずどちらの終わりにも、あります。
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.
この大部分はデータ保全の特定の問題との作品サービスによる取引を記録します、終わりのホストを可能にするという壊れているか感染している作品仲介者から不適当行動に検出して、反応させる目標を含んでいて。
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.
私たちは、1パーティーの同意が作品が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
しかしながら、中でこのドキュメントの次のセクションについて議論するとき、私たちは、ネットワークでデータ保全を保護するのに、それ自体(例えば、終わりホストのひとりが作品サービスを認可していて、もう片方の終わりホストが恐らく作品サービスに気づかないことの)で1パーティーの同意モデルが不十分であると[CDT01]に同意します。 また、私たちは同意します。
IAB Informational [Page 4] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[4ページ]のRFC3238IAB問題
[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の作品のために標準化したセキュリティと承認にかかわらず。 非社交的な目的のためにIETFのプロトコルの多くを変更できました--終わりからエンドへの輻輳制御を回避するようにトランスポート・プロトコルを変更できて、無効のルートを注入するようにルーティング・プロトコルを変更できて、内容の権限のない変更に作品などがなくてもウェブプロキシキャッシュを使用できました。 これらのいずれもトランスポート・プロトコル、ルーティング・プロトコル、プロトコルをキャッシュするウェブ、または作品自体を標準化しない理由を強制するように見えません。 私たちの意見では、代わりにインフラ需要、できるだけ、それ自体を検出して、防御するように設計されているのが実装に感染して、プロトコルの誤用が、直接扱われる必要を意味します、それぞれ適切な開催地で。
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.
デジタル署名などのメカニズムはネットワークにおける、内容の権限のない変更の検出に向かった第一歩です。(デジタル署名は、ユーザが、自分たちのために内容が変更されていないことを確かめるのを助けます)。 しかしながら、作品の場合では、終わりから終わりへのデータの完全性を確実にする追加保護はエンドユーザが作品仲介者が内容を変更するのに権限を与えられたケースを検出するのを助けるためにまた、例えば望ましいのですが、不適当な変更を実行してください。 私たちは、*エンドユーザが*保証*ではなく、助け*エンドユーザに彼らがそうしてもいくつかの場合、作品仲介者であると感染されて、検出するなりますが、メカニズムがすべての場合で感染している作品仲介者を検出できてそうすることができることに注意するでしょう。
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.
作品が貸し切りであるなら、また、作品ワーキンググループは、明らかに決めて、作品アーキテクチャはかかわった作品セッションの1つ以上の終わりのそばでの終端間暗号化の使用と互換性があるに違いないかどうか記録しなければならないでしょう。 作品は終端間暗号化と互換性があるなら、事実上、これが、作品箱が少なくとも終わりの1つまでに知られて、信じられて、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) 1パーティーが同意します: IETFで標準化された作品フレームワークは、どんな作品サービスの使用も応用層終わりホスト(すなわち、コンテンツプロバイダーかクライアントのどちらか)のひとりによって明らかに認可されるのを必要としなければなりません。
IAB Informational [Page 5] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[5ページ]のRFC3238IAB問題
(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で標準化された作品フレームワークにおいて、エンドユーザは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.
提案された作品サービスには、いくつかの可能なフォームがあります、サーバ中心のサービスを含んでいて、コンテンツプロバイダーによって明らかに認可されたウェブページのダイナミックな集合などのように。 翻訳がエンドユーザでコンテンツプロバイダーから応答に影響するのを明らかに認可したウイルススキャンか言語などのクライアント中心のサービス。 そして、エンドユーザによってエンドユーザからコンテンツプロバイダーまでの要求に影響するのが明らかに認可されたプライバシーベースのサービスかコンテントのフィルタリングなどのクライアント中心のサービス。 私たちはこれらの異なったクラスのサービスのために別々に終わりから終わりへのデータの完全性の問題を考えます。
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.
それぞれの特定のサービス単位で、質問はコンテンツプロバイダーとエンドユーザの両方が作品仲介者による不適当行動に検出して、反応できるようにそれが必要であるかどうか、またはちょうど2人の終わりのホストのひとりにこの能力があるのが、十分であるかどうか起こります。 一般的な答えを試みませんが、私たちはさらに下のセクションで問題に取り組みます。
3.1. Data integrity with client-centric OPES services on responses
3.1. 応答のクライアント中心の作品サービスがあるデータの保全
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.
終わりから終わりへのデータの完全性に関するどんな心配もなぜコンテンツプロバイダーから応答に影響するクライアント中心の作品サービス中ですか? クライアントがウイルススキャンか言語翻訳などのサービスを要求するなら、コンテンツプロバイダーへのどんな関心のものも、なぜ何らかの方法ですか? 1つの答えはIETFの適切な関心の1つがネットワークで終わりホストが不適当な動きに検出して、応じるのを可能にするアーキテクチャを設計することであるということです。 これは強力なデバイスのために特別の重要性について作品仲介者のようなネットワークでそのエンドノードの直轄で見えます。(その仲介者は終わりのノードの1つによってネットワークでデータを影響するか、または変えるのが認可されますが、それを除いて、認可されます)。
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
例がウイルススキャンか言語翻訳のサービスであるとみなしてください。 エンドユーザは不完全であるか崩壊したウイルス・スキャナーか彼女の直轄である言語翻訳プログラム(例えば、彼女自身のマシンの)を検出して、対処する際に妥当なパワーを持っています。 エンドユーザは、どんなプログラムがインストールされるかをまさに知っていて、以前、サービスが近づく手段を持った後に内容にダイレクトに近づく手段を持っています。
IAB Informational [Page 6] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[6ページ]のRFC3238IAB問題
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.)
適用にされる。 エンドユーザはネットワーク自体における作品で同様のサービスの、より少ないコントロールを提供させるでしょう。(そこでは、エンドユーザの唯一のコントロールが認可するか、またはサービスを認可しない2進のものであるかもしれません)。 (私たちは、また、サービスが終わりのホストの上でローカルのウイルススキャンプログラムなどの自己充足的なファッションで展開したことに注意して、ネットワークにおけるサービスでなく、またしたがって、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.
崩壊した仲介者を検出しますがウイルススキャンか言語翻訳、エンドユーザはそうすることができた作品サービスのために単に出力と入力を比べる「ブラックボックス」アプローチで。 これは、また、不正確であり、何らかの取り組みを必要とします、自分自身のマシンの上にインストールされた崩壊したウイルス・スキャナーを検出するのに必要である取り組みと比べて。 例えば、ユーザは、「非作品」バージョンがあれば直接コンテンツプロバイダーからの内容の「非作品」バージョンを検索して、作品仲介者から利用可能な内容の「作品」バージョンとこれを比べることができました。 しかしながら、ダイナミックな内容の場合では、ユーザによって直接コンテンツプロバイダーから検索された内容の「非作品」バージョンは必ず内容の「非作品」バージョンが作品仲介者で考えたのと同じであるかもしれないというわけではありません。 作品サービスのエンドユーザ、および不完全であるか崩壊した仲介者を検出するエンドユーザの限られた能力によるこの限られたコントロールはそれが、コンテンツプロバイダーがまた、不完全であるか崩壊した作品仲介者に検出して、反応するのを助けるアーキテクチャについて賛成の議論をします。
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:
私たちは作品サービスとしてエンドユーザによって認可されたウイルススキャンの特定の例を考えます。 人は、ウイルスが広く配布している作品サービスとしてスキャンされると想像できました、終わりのホスト自身で行われたウイルススキャンを増大させて。 私にネットワークのセキュリティとウイルスの上でたとえばスティーブBellovinによる論文を求めて、この内容がウイルススキャンを通過しないと自分のウイルスをスキャンする認可された作品サービスで知らされるなら、多くの可能性があります:
(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) 作品ウイルス・スキャナーは有害ウイルスに関して本当の有害ウイルス、およびスティーブの論文を見分けることができません。
(4) My local OPES virus scanner has been hacked, with malicious
intent, to reject all content from Steve Bellovin.
(4) 地元の作品ウイルス・スキャナーは、スティーブBellovinからのすべての内容を拒絶するために悪意でハックされました。
IAB Informational [Page 7] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[7ページ]のRFC3238IAB問題
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.
何らかのポイントでは、何らかの内容に関して、ある作品ウイルス・スキャナーの何らかの広く配布している実装が問題(3)をもたらしそうです、そして、何らかの作品実装が、問題(4)をもたらすために崩壊しそうです。 エンドユーザが作品ウイルス・スキャナーのコントロールを制限したので、エンドユーザも作品ウイルス・スキャナーに問題(3)か(4)を検出する性能が制限されます。 さらに、コンテンツプロバイダーはたぶん作品ウイルス・スキャナーに問題(3)か(4)を検出する最も強い誘因があるものです。 (コンテンツプロバイダーには、一般に、また、問題(1)を検出する強い動機があります。) この場合、総合的な作品アーキテクチャがウイルスの作品サービスがスキャンされるのを防ぐように入念に設計されるべきであるのは慎重に思えます、クライアントによって認可されるように、不必要に事実上、ウイルスにかかっていない内容の分配を防ぐのから。
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.
明らかに、コンテンツプロバイダーが、何らかの内容がウイルススキャンなしでエンドユーザに渡されるべきであるのを単に示すよう提案するのは実行可能ではありません--ウイルススキャンのポイントはエンドユーザがこの点でコントロールを運動させることです。 しかしながら、コンテンツプロバイダーが、何らかの形式に関するエンドシステム通知で内容がエンドユーザに提供されることの代わりにウイルススキャンサービスで拒絶されているのを見つけることができるなら、コンテンツプロバイダー(この場合、スティーブ)は、この内容がいくつかの作品ウイルススキャンサービスを通過しないのがコンテンツプロバイダーによって知られていることをエンドユーザに知らせたがっているかもしれません。 次に、エンドユーザは作品ウイルススキャンサービスを迂回させるその内容を検索するかどうかに関する決定にそれら自身のを作ることができました、この特定の内容のためのそれら自身のウイルス・スキャナーか代替のウイルススキャンサービスに依存して。 コンテンツプロバイダーへのそのようなエンドシステム通知を要求されるなら実施できないで、崩壊した仲介者から当てにすることができませんが、それにもかかわらず、それは重要に見えます。
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.
もちろん、また、悪意あるユーザーはウイルススキャンサービスを回避できる悪意があるウイルスを組み立てる彼らの能力を完成させるのに彼らのウイルススキャンサービスの認識を使用できます。 これは、どんなウイルスもサービスをスキャンしている状態でとにかくして、ネットワークにおける、不完全であるか崩壊した作品サービスの気まぐれに対する何らかの保護をコンテンツプロバイダーに許す許容できる費用のように見えます。
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
したがって、ウイルススキャンや言語翻訳などのクライアントによって要求されたサービスにおいて、それを要求するなら、発生源サーバには通知があるのにおいて内容をクライアントに送る前に内容にこれらのサービスを実行しているのは明確に望ましいです。 その内容に適用された作品サービスのための減少している性能(オーバーヘッド、遅れなどに関する)でどんなそのようなエンドシステム通知も伴われるかもしれません。 しかし、何らかの形式のエンドシステム
IAB Informational [Page 8] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[8ページ]のRFC3238IAB問題
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.
コンテンツプロバイダーが必要であるなら、通知が明確に必要です。不適当であるとコンテンツプロバイダーによって考えられる作品仲介者による動作に検出して、反応できるように。
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.
同様に、言語翻訳のクライアントベースの作品サービスには、コンテンツプロバイダーが、いつ何らかの内容が言語翻訳と非互換であるとコンテンツプロバイダーによって考えられるかをエンドユーザに知らせることができるのは、明確に望ましいです。 知らせてください。または、この場合切迫した課題が作品言語翻訳が言語翻訳を発見するために何らかのメカニズムをコンテンツプロバイダーに与えるために内容、しかし、代わりに実行されるのを防がないで、エンドユーザに知らせることである、(より正確である、エンドユーザのホストコンピュータ) コンテンツプロバイダーが、この言語翻訳がこの特定の内容と両立しないと信じているなら。
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)通知: 総合的な作品フレームワークは、不適当であるとコンテンツプロバイダーによって考えられる作品仲介者によるクライアント中心の動作に検出して、応じるのにコンテンツプロバイダーを助ける必要があります。
3.2. Data integrity with server-centric OPES services
3.2. サーバ中心の作品サービスがあるデータの保全
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.
もしあればサーバ中心の作品サービスにおける終わりから終わりへのデータの完全性があるロケーションベースのサービスなどの関心は何ですか? 例えば、CNNは位置のベースの作品サービスを認可できました、作品仲介者が地方の関心に関する気象レポートかニュース見出しを要求されたウェブページに挿入するところで。 壊れているか変更された作品仲介者への検出と応答の同じ問題はクライアント中心の作品サービスのようにサーバ中心の作品で起こります。 私たちは応答のときにサーバ中心のサービスを考えるだけです、私たちがクライアントからコンテンツプロバイダーまでの要求のときにサーバ中心の作品サービスのためのどんな提案も意識していないように。
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
エンドノードはコンテンツプロバイダーによって認可された作品サービスから不適当な動きをどのように検出することになっていますか? 作品サービスはコンテンツプロバイダーの直轄の下で実行されるのではなく、作品仲介者でネットワーク自体で実行されています。 コンテンツプロバイダーには、特に、直接作品仲介者の出力をモニターする能力がないかもしれません。 1つは、コンテンツプロバイダーとサーバ中心の作品仲介者がただ一つの分配されたアプリケーションの一部であると主張できて、一人で壊れているか変更された作品仲介者を検出して、対応するのに責任がある場合があります、エンドユーザにかかわらないで。 しかし、これが納得がいきません、基本的に論争して、作品サービスを実行するためにプロトコルを標準化するのが、適切にIETFのドメインのネットワーク問題ですが、確実にするのが総合的なサービスの保全であることはaです。
IAB Informational [Page 9] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[9ページ]のRFC3238IAB問題
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.
アプリケーション物質を分配して、全くIETFのいずれの州でもそうしませんでした。 私たちにとって、あなたが両方の利を得ることができないように思えるでしょう。 同じくらいの一部がアプリケーションを配布したとき単にコンテンツプロバイダーと作品仲介者にレッテルを貼るのは作品仲介者の動作をモニターする能力をコンテンツプロバイダーに与えません。
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.
しかしながら、エンドユーザがこれらの作品サービスを提供したという何らかの形式に関する通知を受け取って、コンテンツプロバイダーから作品仲介者の変更なしで「非作品」内容を受け取るための何らかのメカニズムを持っているなら(内容の非作品バージョンのようなものがあれば)、エンドユーザは妥協しているか不十分にたくらみがある作品仲介者から不適当な動きに検出して、反応するより良い立場にいます。 したがって、何らかの形式に関するエンドシステム通知がエンドユーザが仲介者を検出して、壊れているか変更された作品に反応させるのを許容するのに必要であるのは、明確です。 エンドユーザが作品仲介者による動作の通知を持っているなら、それは遠くの作品が修理する「拒否権」作品によって単に投げるのによる変更にされる内容を持っているかもしれません。 そして、クライアントが「非作品」バージョンを受けるために直接起源サーバと話したがっていて、起源サーバがこれを許容するために構成されるなら、このエンド・ツー・エンド通信を可能にするように作品仲介者を設計しなければなりません。
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.
不完全であるか妥協している作品仲介者に検出して、応じることに関する心配に加えて、データの完全性に関する方針ベースの心配が純粋にあります。 コンテンツプロバイダーがHTTP要求からソースIPアドレスを見るか、またはどんな内容を提供したらよいかを決めるためにコインを投げるなら、それはコンテンツプロバイダーのビジネスです。 しかし、コンテンツプロバイダー、および作品仲介者から利用可能なまた、変更されたバージョンから利用可能な何らかの内容の「非作品」バージョンが存在しているなら、エンドユーザが、彼らがまた、利用可能な「非作品」バージョンではなく、ネットワークからコンテンツプロバイダーから変更されたバージョンを直接受けていると発見できるのは、重要です。
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)通知: 総合的な作品枠組みは作品仲介者の振舞いを検出するのにエンドユーザを助けるべきです、彼らが不完全であるか妥協している仲介者を特定するのを潜在的に許容して。
(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) 非ブロッキング: コンテンツプロバイダーから利用可能な内容の「非作品」バージョンが存在しているなら、ユーザは作品構造のためにコンテンツプロバイダーからこの「非作品」バージョンを検索してはいけないことができません。
IAB Informational [Page 10] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[10ページ]のRFC3238IAB問題
3.3. Data integrity with client-centric OPES services on requests
3.3. 要求のクライアント中心の作品サービスがあるデータの保全
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.
また、クライアントからコンテンツプロバイダーまでの要求のときにクライアントによって認可された作品サービスのための提案がありました。 例は加えられたプライバシーのためにHTTPヘッダから野原を取り除くサービス、およびフィルタ要求が要求されたURLに基礎づけたコンテントのフィルタリングサービスを含んでいます。 そのようなサービスのために、終わりのホストが不完全であるか崩壊した仲介者に検出して、反応するのが助けられる必要がまだありますが、それはこれがコンテンツプロバイダーに適用されるというどんな範囲と、そして、それがサービスを認可したエンドユーザに適用されるというどんな範囲により明確でないか見えます。 要件はたぶん作品と、より広い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はリモートサーバでただ一つのデータ実体について言及する構造化された方法をだいたい与えます)。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.
習慣はしばしばこの理論と異なっています--広告ストリッパーはクライアント終わりでページからデータを取り除きます。 ウェブサーバー・ファームが負荷分散のために数台の仮想ターゲットマシンの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計画のために定義されるように)はクライアントと作品仲介者の間で変わりがない状態で適用されます。 仲介者が要求を実現させるためにすることは、議論に物質的でなく、適切なURI計画定義で対応である結果を生まなければなりません。 この意味で、作品仲介者は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.
クライアント中心の作品では、仲介者は、クライアントへのデータ応答を提供するためにクライアントを代表して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.
サーバ中心の作品では、「起源サーバ」は「適切な」内容であることが与えられたURIに供給すると決心している仲介者への権威を割譲します。 クライアントはたぶん標準のURI解決を実行するでしょうが、それは仲介者より遠くに達しません。
With those distinctions firmly in mind, there are two particular areas of concern for OPES-like services.
それらの区別がしっかり念頭にある状態で、作品のようなサービスに、重要な2つの特定の領域があります。
IAB Informational [Page 11] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[11ページ]のRFC3238IAB問題
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通のドキュメントでないことの検索)の上で。 潜在的な問題はイントラにおける矛盾と相互ドキュメント指示するものを含んでいます--どんな内容を変えるかによって、ドキュメントの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.
もう片方の関心はこれが仲介者の使用で排他的にアクセス可能な内容の創造に通じるかどうかということです。 すなわち、「非作品」バージョンが全くありません。 これを許容するべきではありませんか、またはこれはインターネット応用層アドレッシング体系に拡大について賛成の議論をするでしょう。
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解決: これらのサービスが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.
ネットワークの中央の仲介者は終わりから終わりへの取引のプライバシーが妥協できた位置の数を増加させます。 これらのプライバシーの問題のいくつかがウェブキャッシュと一般に、CDNsと、そして、特に作品仲介者に適用されます。 作品仲介者のプライバシーに関する方針を決定するエンドユーザのための提供メカニズムの問題が記述されるべきであるのは作品がIETFでチャーターされるという妥当な要件に見えます。 クライアント中心とサーバの中心の作品サービスにおいて、これらのメカニズムは全く異なっているかもしれません。
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ワーキンググループからプロトコルと対話する作品構造などの複雑な問題に関しては、特定のワーキンググループで標準化されるのは同時に問題の特定の部分を開ける間、全体像を覚えておくのに必要に思えます。 したがって、総合的な作品構造がプライバシーの問題を記述するという要件は、必ずこれのためのメカニズムが、IETF、または作品ワーキンググループで開発される必要を意味するというわけではありません(それが貸し切りであるなら)。
IAB Informational [Page 12] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[12ページ]のRFC3238IAB問題
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)プライバシー: エンドユーザが作品仲介者のプライバシーに関する方針を決定するように、総合的な作品枠組みはメカニズムに備えなければなりません。
6. Summary of IAB Considerations
6. 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) 1パーティーが同意します: IETFで標準化された作品枠組みは、どんな作品サービスの使用も応用層終わりホスト(すなわち、コンテンツプロバイダーかクライアントのどちらか)のひとりによって明らかに認可されるのを必要としなければなりません。
(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で標準化された作品枠組みにおいて、エンドユーザはIP層で作品仲介者を明らかに宛てなければなりません。
(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)通知: 総合的な作品枠組みは、不適当であるとコンテンツプロバイダーによって考えられる作品仲介者によるクライアント中心の動作に検出して、応じるのにコンテンツプロバイダーを助ける必要があります。
(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)通知: 総合的な作品枠組みは作品仲介者の振舞いを検出するのにエンドユーザを助けるべきです、彼らが不完全であるか妥協している仲介者を特定するのを潜在的に許容して。
(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) 非ブロッキング: コンテンツプロバイダーから利用可能な内容の「非作品」バージョンが存在しているなら、ユーザは作品構造のためにコンテンツプロバイダーからこの「非作品」バージョンを検索してはいけないことができません。
(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解決: これらのサービスが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.1) Privacy: The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.
(5.1)プライバシー: エンドユーザが作品仲介者のプライバシーに関する方針を決定するように、総合的な作品枠組みはメカニズムに備えなければなりません。
IAB Informational [Page 13] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[13ページ]のRFC3238IAB問題
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.
このドキュメントは建築していた状態でいくつかのIABによるコメントと推薦を含んでいます、そして、政策問題はIETFの作品の特許に関連しました。
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のメンバー、作品への寄稿者、ジョン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".
[Carr01]ウェイン・カー、「保全、プライバシー、およびセキュリティのための提案された作品要件」は ietf-openproxy@imc.org 、2001年8月16日までメールされます。 URL「 http://www.imc.org/ietf- メールopenproxy/アーカイブ/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".
2001年8月3日の民主主義とTechnologyのためのセンターからのProposed作品作業部会Efforts、IESGへのメールによる[CDT01]方針Concerns Raised。 URL「 http://www.imc.org/ietf-openproxy/mail- アーカイブ/msg00828.html。」
[Clark88] David D. Clark, The Design Philosophy of the DARPA
Internet Protocols, SIGCOMM 1988.
[Clark88]デヴィッド・D.クラーク、DARPAインターネットプロトコル、SIGCOMM1988の設計理念。
[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]ジョンモリス、「Re:」 「修正されます--、Integrity、Privacy、およびSecurityのための作品Requirementsが勧めた、」、2001年9月28日。 ietf-openproxy@imc.org 、URL「http://www.imc.org/ietf-openproxy/メールアーカイブ/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]マイク・オデル、「作品の継続するあわ」…, メッセージイド: <200107101341.JAA30276@ccr.org>、2001年7月10日は ietf@ietf.org にメールされます。 URL「 http://www1.ietf.org/mail- アーカイブ/ietf/電流/msg12650.html。」
[OPES] Open Pluggable Edge Services (OPES) Web Page,
"http://www.ietf-opes.org/".
[作品]はPluggable縁のサービスウェブページ、" 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] 作品転炉、第49IETF、2000年12月12日。 議題: " http://www.ietf.org/ietf/00dec/opes-agenda.txt "。 数分: 「 http://www.ietf.cnri.reston.va.us/ 議事/00dec/toc.htm#P25_256。」
IAB Informational [Page 14] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[14ページ]のRFC3238IAB問題
[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes:
"http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
[OPESBOF2] 作品転炉、第50IETF、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] 作品転炉、第51IETF、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".
「開いているPluggableサービスのためのデータの保全」という[Orman01]Hilarie Ormanは ietf-openproxy@imc.org 、2001年8月15日までメールします。 URL「 http://www.imc.org/ietf-openproxy/mail- アーカイブ/msg00865.html。」
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin、S.、「IABセキュリティー体系ワークショップのレポート」、RFC2316、1998年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC 3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January
2001.
[RFC3040] クーパー、I.、Melve、I.、G.トムリンスン、「インターネットウェブ模写、分類学をキャッシュする」、RFC3040、1月2001日
[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.
[RFC3135]は接しています、J.、Kojo、M.、Griner、モンテネグロ、G.、およびZ.シエルビイ、J.、「パフォーマンスはリンク関連の転落を緩和することを意図するプロキシを高め」て、RFC3135、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]ジョイスRoutson、IETFの縁の規格戦慄の貴公子、2001年7月11日、夢見心地CDN週。 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.
このドキュメントは、どんな新しいプロトコルも提案しないで、またしたがって、その意味で、どんなセキュリティ問題にもかかわりません。 しかしながら、このドキュメント中に、プライバシーの議論と作品サービスの保全問題とそれらの問題によって作成された建築要件があります。
11. IANA Considerations
11. IANA問題
There are no IANA considerations regarding this document.
このドキュメントに関するIANA問題が全くありません。
IAB Informational [Page 15] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[15ページ]のRFC3238IAB問題
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
ハラルドAlvestrandはアトキンソンロブAusteinフレッドベイカースティーブBellovinブライアン大工ジョンクロウクロフトレスリーDaigleスティーブデアリング出撃フロイドジェフヒューストンジョンKlensinヘニングSchulzrinneを走らせました。
IAB Informational [Page 16] RFC 3238 IAB Considerations for OPES January 2002
作品2002年1月のためのIABの情報[16ページ]のRFC3238IAB問題
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
IAB Informational [Page 17]
IAB情報です。[17ページ]
一覧
スポンサーリンク
