Network Working Group Internet Architecture Board (IAB)
Request for Comments: 3238 S. Floyd
Category: Informational L. Daigle
January 2002
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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中开放式可插拔边缘服务（OPE）租用相关架构和政策问题的评论和建议。OPE是将部署在网络中的应用程序级中介上的服务，例如，在源服务器和客户端之间的web代理缓存上。这些中介机构将在内容提供商或最终用户明确同意的情况下转换或过滤内容。
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].
开放可插拔边缘服务（OPE）是将部署在网络中的服务，例如，在源服务器和客户端之间的web代理缓存中，用于转换或过滤内容。建议的OPES服务的示例包括组装个性化网页、向网页添加用户特定的区域信息、病毒扫描、为带宽有限的客户进行内容自适应、语言翻译等[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
IETF中特许运营商的问题（[OpeSbof 1]、[OpeSbof 2]、[OpeSbof 3]）以及IETF社区中的相关争议（[Carr01]、[CDT01]、[Morris01]、[Orman01]、[Routson01]）已经突出了一些关于数据健壮性和端到端完整性的架构和政策问题（就“源服务器”提供的服务与客户端接收的服务之间的差异而言）。特别是，对于要开发的协议和
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中标准化，用于该协议，以保护数据的端到端隐私和完整性。本文件试图解决OPE租船过程中尚未解决的一些架构和政策问题，并就这些问题提出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中标准化的任何OPES解决方案应解决的问题的建议，类似于IETF文件[RFC2316]中当前要求的“安全注意事项”。例如，解决安全问题的一种方法是证明协议中提供了适当的安全机制，而解决安全问题的另一种方法是证明此特定协议不存在任何安全问题。（但是请注意，“不涉及任何安全问题”这一笼统的句子永远不足以解决具有已知安全问题的协议中的安全问题。）
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
OPES体系结构的目标之一必须是保持长久以来被认为是互联网体系结构首要目标之一的健壮性[Clark88]。有鉴于此，我们建议IESG要求OPES体系结构通过支持终端主机检测和响应OPES中介机构的不当行为来保护端到端数据完整性。我们注意到，在本例中，通过“支持终端主机检测”，我们指的是在内容提供商和客户端支持负责终端主机的人员进行检测。我们会注意到，这些问题中有许多是关于
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.
终端主机检测和响应中介机构不适当行为的能力可以应用于web缓存和内容分发基础设施的体系结构，即使没有额外的OPE复杂性。
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注意事项，我们建议OPES架构解决这些注意事项。第6节总结了所有这些注意事项。
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工程进展一致的术语。
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].
关于欧佩斯的一种观点是“欧佩斯是非常邪恶的，IETF应该远离这个可怕的可憎之物”[ODell01]。其他人则认为“运营商将降低互联网通信的完整性和对完整性的感知，并将显著增加在内容通过网络传输时可能对其采取的措施的不确定性”，因此运营商的风险大于收益[CDT01]。根据[Carr01]的建议，“假设某些隐私和完整性保护可以纳入工作组的目标”[Morris01]，在随后的电子邮件中对OPE风险的观点进行了修订。
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.
一个问题涉及一方同意模式。在一方同意模型中，需要一个终端节点（即内容提供商或最终用户）明确授权OPES服务，但不需要双方的授权。[CDT01]评论称，仅依赖OPES宪章中的一方同意模式“可能会在最终用户不知情或不同意的情况下，促进第三方或国家赞助的互联网内容审查”，以及其他不受欢迎的情况。
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缓存中）而不是将所有服务放在内容提供商或最终用户处，是否有任何架构优势。（请注意，我们在此询问是否存在架构优势，这与询问是否存在商业模式不同。）建议运营商提供的以客户为中心的服务包括病毒扫描、语言翻译、有限的客户带宽自适应、请求过滤和流媒体自适应，建议的以服务器为中心的服务包括基于位置的服务和个性化网页。
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).
第二个问题是，在网络中间提供服务的架构效益是否超过建筑成本，例如关于数据完整性的潜在成本。这类似于RFC 3135（RFC 3135）中考虑在网络中间放置性能增强代理（PEPS）以解决链路相关退化的相对成本和收益的问题。就PEP而言，潜在成本包括禁用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.
第三个问题是，主要为单个检索操作设计的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服务的情况下，一方同意必须是IETF中OPES标准化的要求。
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]，即一方同意模型本身（例如，其中一个终端主机授权OPES服务，而另一个终端主机可能不知道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标准化的安全和授权机制如何，OPE的实现可能会被修改以绕过这些机制，从而导致未经授权的内容修改。IETF中的许多协议都可以出于反社会目的进行修改——可以修改传输协议以逃避端到端的拥塞控制，可以修改路由协议以注入无效路由，甚至可以在没有OPE的情况下使用web代理缓存对内容进行未经授权的修改，等等。所有这些似乎都不是不标准化传输协议、路由协议、web缓存协议或OPE本身的令人信服的理由。在我们看来，这意味着基础设施需要尽可能地进行设计，以检测和保护自身免受受损实施的影响，协议的滥用需要在适当的场所直接解决。
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.
数字签名等机制帮助用户自己验证内容未被更改，这是检测网络中内容未经授权修改的第一步。但是，对于OPE，还需要额外的保护以确保数据的端到端完整性，例如，帮助最终用户检测OPE中介机构被授权修改内容但执行不适当修改的情况。我们注意到，在某些情况下，机制可以*帮助*最终用户检测受损的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架构是否必须与涉及OPES会话的一个或多个终端使用端到端加密兼容。如果OPES与端到端加密兼容，这将有效地确保OPES框将被限制为已知、可信、在IP层显式寻址且至少由一个端授权（通过提供解密密钥）的框。与端到端加密的兼容性还将有助于防止另一组服务的广泛部署，这些服务需要一个人将自己的数据包内容保持在透明状态，以便所有人都可以窥探。
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服务的使用由其中一个应用层终端主机（即，内容提供商或客户端）明确授权。
(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框架，终端用户必须在IP层明确寻址OPES中介。
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层显式寻址链中的第一个中介。
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服务有几种可能的形式，包括以服务器为中心的服务，如由内容提供商明确授权的动态网页组装；以客户为中心的服务，如最终用户明确授权的病毒扫描或语言翻译，以根据内容提供商的响应采取行动；以及以客户为中心的服务，例如最终用户明确授权的基于隐私的服务或内容过滤，以根据从最终用户到内容提供商的请求采取行动。我们考虑的问题，端到端的完整性数据分别为这些不同类别的服务。
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中介机构的不当行为，或者两个终端主机中的一个是否具备这种能力就足够了。我们不试图给出一个一般性的答案，但我们会在下面的章节中进一步讨论这些问题。
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服务中，对内容提供商的响应有任何担心？如果客户端请求病毒扫描或语言翻译等服务，为什么内容提供商会以这样或那样的方式关注这些服务？一个答案是IETF的一个适当关注点是设计架构，使终端主机能够检测并响应网络中的不当行为。这对于网络中功能强大的设备（如OPES中介）来说似乎特别重要，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.)
应用最终用户对网络本身中运营商提供的类似服务的控制将更少，其中最终用户的唯一控制可能是授权或不授权服务的二进制控制。（我们还注意到，以自包含方式部署在终端主机上的服务（如本地病毒扫描程序）不是网络中的服务，因此不在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服务的控制有限，以及最终用户检测不完美或损坏的中介机构的能力有限，因此需要一种体系结构来帮助内容提供商检测和响应不完美或损坏的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病毒扫描服务告知我该内容未通过病毒扫描，则有多种可能性：
(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病毒扫描程序被恶意入侵，拒绝史蒂夫·贝洛文的所有内容。
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架构，以防止客户授权的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
因此，对于客户端请求的服务，例如病毒扫描和语言翻译，如果源服务器请求，则显然希望在将内容发送到客户端之前通知其正在对其内容执行这些服务。任何这样的终端系统通知都可能伴随着应用于该内容的OPES服务的性能降低（在开销、延迟等方面）。但是某种形式的终端系统
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.
如果内容提供商要能够检测并响应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中介机构以客户为中心的行为。
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中介将地区感兴趣的天气报告或新闻标题插入请求的网页。与以客户机为中心的OPES服务一样，以服务器为中心的OPES也会出现检测和响应损坏或修改的OPES中介的问题。我们只考虑服务器中心的响应服务，因为我们不知道对于客户机到内容提供者的请求，以服务器为中心的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
终端节点如何从内容提供商授权的OPES服务中检测不适当的操作？OPES服务由网络本身的OPES中介机构执行，不受内容提供商的直接控制；特别是，内容提供商可能无法直接监控OPES中介的输出。有人可能会争辩说，内容提供商和以服务器为中心的OPES中介体是单个分布式应用程序的一部分，可以自行负责检测和处理损坏或修改的OPES中介体，而不涉及最终用户。但这并不令人信服，基本上认为，在IETF领域，执行OPES服务的标准化协议是一个网络问题，但确保服务的整体完整性是一个关键
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的范围内。在我们看来，你不能两全其美。简单地将内容提供者和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”内容，而无需OPES中介机构的修改（如果存在非OPES版本的内容），这样，最终用户就能够更好地检测和应对受损或设计不良的OPES中介机构的不当行为。因此，显然需要某种形式的最终系统通知，以允许最终用户检测和响应损坏或修改的OPES中介。如果终端用户收到OPES中介机构的行动通知，它可以通过扔掉OPES修改的内容来“否决”OPES服务。如果客户端希望直接与源服务器对话以接收“非OPES”版本，并且源服务器配置为允许此操作，则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”版本，以及OPES中介机构提供的修改版本，则最终用户能够发现他们从网络接收到的是修改版本，而不是“非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”版本的内容，OPES体系结构不得阻止用户从内容提供商检索此“非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过滤请求的内容过滤服务。对于此类服务，仍然需要帮助终端主机检测和响应不完善或损坏的中介，但这在多大程度上适用于内容提供商，以及在多大程度上适用于授权服务的最终用户，似乎不太清楚。这些要求可能必须由OPE和更广泛的IETF社区根据具体服务的具体情况确定。
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.
实践常常不同于这一理论——广告剥离器从客户端的页面中删除数据；web服务器场将客户端重定向到几个潜在的目标机器之一，以实现负载平衡或为用户提供“本地化”内容。
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解析标准（如为单个URI方案定义的，如HTTP）在客户端和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.
在以客户机为中心的OPE中，中介体代表客户机解析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.
在以服务器为中心的OPE中，“源服务器”将其权限让给中介，以确定为给定URI提供的“适当”内容。客户机可以很好地执行标准URI解析，但这只会影响到中间层。
With those distinctions firmly in mind, there are two particular areas of concern for OPES-like services.
牢记这些区别，像服务业这样的运营商有两个特别关注的领域。
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.
第一个是考虑一系列交互的影响，随着时间和位置的变化（即，不仅仅是一次文档检索）。潜在的问题包括文档内和文档间引用的不一致性——根据更改的内容，来自文档一个版本的引用可能不存在于修改后的目标中，等等。
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.
另一个问题是，这是否会导致创建只能通过使用中介访问的内容。也就是说，没有“非OPES”版本。要么这是不允许的，要么这会导致对Internet应用层寻址体系结构的扩展。
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）在遵守上述两个考虑因素的情况下无法实现的任何服务可作为Internet应用程序寻址架构扩展的潜在要求进行审查，但不得作为临时修复。
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中介机构。对于要在IETF中特许的运营商来说，为最终用户提供机制以确定运营商中介机构的隐私政策的问题似乎是一个合理的要求。对于以客户机为中心和以服务器为中心的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).
对于一个复杂的问题，如OPES体系结构，它与来自其他标准机构以及其他IETF工作组的协议交互，似乎有必要记住总体情况，同时，在特定工作组中划分要标准化的问题的特定部分。因此，要求整个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中介机构的隐私政策。
(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服务的使用由其中一个应用层终端主机（即，内容提供商或客户端）明确授权。
(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框架，终端用户必须在IP层明确寻址OPES中介。
(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) 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”版本的内容，OPES体系结构不得阻止用户从内容提供商检索此“非OPES”版本。
(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）在遵守上述两个考虑因素的情况下无法实现的任何服务可作为Internet应用程序寻址架构扩展的潜在要求进行审查，但不得作为临时修复。
(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中介机构的隐私政策。
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中与OPE包租相关的一些架构和政策问题的评论和建议。
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的一份文件，我们并不声称上面列出的其他人同意这些内容。
[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]Wayne Carr，“OPES对完整性、隐私性和安全性的建议要求”，电邮至ietf-openproxy@imc.org，2001年8月16日。URL“http://www.imc.org/ietf-openproxy/mail-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]提议的OPES工作组工作提出的政策问题，通过电子邮件发送至IESG，来自民主与技术中心，2001年8月3日。URL“http://www.imc.org/ietf-openproxy/mail-archive/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，“回复：更正-建议的OPES完整性、隐私和安全要求”，2001年9月28日。发送电子邮件至ietf-openproxy@imc.org，网址“http://www.imc.org/ietf-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，“运营商继续泡沫…”，消息Id：<200107101341。JAA30276@ccr.org>，2001年7月10日，电邮至ietf@ietf.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]打开可插拔边缘服务（OPES）网页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".
[Opesbof 1]OPES BOF，第49届IETF，2000年12月12日。议程：“http://www.ietf.org/ietf/00dec/opes-agenda.txt". 会议记录：http://www.ietf.cnri.reston.va.us/ 会议记录/00dec/toc.htm#P25_256”。
[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes: "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
[OpeSbof 2]OPES BOF，第50届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".
[OPESBOF 3]OPES BOF，第51届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，“开放式可插拔服务的数据完整性”，电邮至ietf-openproxy@imc.org，2001年8月15日。URL“http://www.imc.org/ietf-openproxy/mail-archive/msg00865.html".
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC 2316]Bellovin，S.，“IAB安全架构研讨会报告”，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.，黑山，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的边缘标准争议，2001年7月11日，星尘CDN周。URL“http://www.stardust.com/cdnweek/articles/2001/07/09/ opes.htm”。
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服务的隐私和完整性问题以及这些问题产生的体系结构要求。
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
哈拉尔·阿尔维斯特兰德（Harald Alvestrand）经营着阿特金森（Atkinson）、罗布·奥斯汀（Rob Austein）、弗雷德·贝克（Fred Baker）、史蒂夫·贝洛文（Steve Bellovin）、布莱恩·卡彭特（Brian Carpenter）、乔恩·克劳克罗夫特（Jon Crowcroft）、莱斯利·戴格尔（Leslie Daigle）、
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。