As per Relevance of the word provider, we have this rfc below:
Network Working Group Internet Architecture Board (IAB
Request for Comments: 3238 S.
Category: Informational L.
January 2002
IAB Architectural and Policy Considerations
Open Pluggable Edge
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document includes comments and recommendations by the IAB
some architectural and policy issues related to the chartering
Open Pluggable Edge Services (OPES) in the IETF. OPES are
that would be deployed at application-level intermediaries in
network, for example, at a web proxy cache between the origin
and the client. These intermediaries would transform or
content, with the explicit consent of either the content provider
the end user
1.
Open Pluggable Edge Services (OPES) are services that would
deployed in the network, for example, at a web proxy cache
the origin server and the client, that would transform or
content. Examples of proposed OPES services include
personalized web pages, adding user-specific regional information
web pages, virus scanning, content adaptation for clients
limited bandwidth, language translation, and the like [OPES].
The question of chartering OPES in the IETF ([OPESBOF1], [OPESBOF2],
[OPESBOF3]) and the related controversy in the IETF
([Carr01], [CDT01], [Morris01], [Orman01], [Routson01]) have
to the fore several architectural and policy issues about
and the end-to-end integrity of data (in terms of the
between what the "origin server" makes available and what the
receives). In particular, questions have been raised about
possible requirements, for a protocol to be developed
IAB Informational [Page 1]
RFC 3238 IAB Considerations for OPES January 2002
standardized in the IETF, for that protocol to protect the end-to-
privacy and integrity of data. This document attempts to
some of the architectural and policy issues that have been
in the chartering of OPES, and to come to some common
from the IAB regarding these issues
The purpose of this document is not to recommend specific
for OPES, or even to mandate specific functional requirements.
is also not a recommendation to the IESG about whether or not
should be chartered. Instead, these are recommendations on
that any OPES solutions standardized in the IETF should be
to address, similar to the "Security Considerations"
required in IETF documents [RFC2316]. As an example, one way
address security issues is to show that appropriate
mechanisms have been provided in the protocol, and another way
address security issues is to demonstrate that no security
apply to this particular protocol. (Note however that a
sentence that "no security issues are involved" is never
sufficient to address security concerns in a protocol with
security issues.)
This document will try to make our concerns underlying integrity
privacy, and security as clear as possible. We recommend that
IESG require that OPES documents address integrity, privacy,
security concerns in one way or another, either directly
demonstrating appropriate mechanisms, or by making a convincing
that there are no integrity or privacy concerns relevant to
particular document
In particular, it seems unavoidable that at some point in the
some OPES service will perform inappropriately (e.g., a virus
rejecting content that does not include a virus), and some
intermediary will be compromised either inadvertently or
malicious intent. Given this, it seems necessary for the
architecture to help protect end-to-end data integrity by addressing
from the beginning of the design process, the requirement of
end hosts to detect and respond to inappropriate behavior by
intermediaries
One of the goals of the OPES architecture must be to maintain
robustness long cited as one of the overriding goals of the
architecture [Clark88]. Given this, we recommend that the
require that the OPES architecture protect end-to-end data
by supporting end-host detection and response to
behavior by OPES intermediaries. We note that in this case
"supporting end-host detection", we are referring to
detection by the humans responsible for the end hosts at the
provider and client. We would note that many of these concerns
IAB Informational [Page 2]
RFC 3238 IAB Considerations for OPES January 2002
the ability of end hosts to detect and respond to the
behavior of intermediaries could be applied to the architectures
web caches and content distribution infrastructures even without
additional complication of OPES
Each section of the document contains a set of IAB
that we would recommend be addressed by the OPES architecture
Section 6 summarizes by listing all of these considerations in
place
In this document we try to use terminology consistent with RFC 3040
[RFC 3040] and with OPES works in progress
2. Some history of the controversy about chartering
One view on OPES has been that "OPES is deeply evil and the
should stay far, far away from this hideous abomination" [ODell01].
Others have suggested that "OPES would reduce both the integrity,
the perception of integrity, of communications over the Internet,
would significantly increase uncertainly about what might have
done to content as it moved through the network", and that
the risks of OPES outweigh the benefits [CDT01]. This view of
risks of OPES was revised in later email, based on the proposals
[Carr01], "assuming that certain privacy and integrity
can be incorporated into the goals of the working group" [Morris01].
One issue concerns the one-party consent model. In the one-
consent model, one of the end-nodes (that is, either the
provider or the end user) is required to explicitly authorize
OPES service, but authorization is not required from both parties
[CDT01] comments that relying only on a one-party consent model
the OPES charter "could facilitate third-party or state-
censorship of Internet content without the knowledge or consent
end users", among other undesirable scenarios
A natural first question is whether there is any
benefit to putting specific services inside the network (e.g., at
application-level web cache) instead of positioning all
either at the content provider or the end user. (Note that we
asking here whether there is architectural benefit, which is not
same as asking if there is a business model.) Client-
services suggested for OPES include virus scanning,
translation, limited client bandwidth adaptation, request filtering
and adaptation of streaming media, and suggested server-
services include location-based services and personalized web pages
IAB Informational [Page 3]
RFC 3238 IAB Considerations for OPES January 2002
It seems clear that there can indeed be significant
benefit in providing some OPES services inside the network at
application-level OPES intermediary. For example, if some content
already available from a local or regional web cache, and the
user requires some transformation (such as adaptation to a limited
bandwidth path) applied to that data, providing that service at
web cache itself can prevent the wasted bandwidth of having
retrieve more data from the content provider, and at the same
avoid unnecessary delays in providing the service to the end user
A second question is whether the architectural benefits of
services in the middle of the network outweigh the
costs, such as the potential costs concerning data integrity.
is similar to the issues considered in RFC 3135 [RFC 3135] of
relative costs and benefits of placing performance-enhancing
(PEPs) in the middle of a network to address link-
degradations. In the case of PEPs, the potential costs
disabling the end-to-end use of IP layer security mechanisms
introducing a new possible point of failure that is not under
control of the end systems; adding increased difficulty in
and dealing with failures; and introducing possible
with asymmetric routing or mobile hosts. RFC 3135
considers these possible costs, the mitigations that can
introduced, and the cases when the benefits of performance-
proxies to the user are likely to outweigh the costs. A
approach could be applied to OPES services (though we do not
that here).
A third question is whether an OPES service, designed primarily for
single retrieval action, has an impact on the application
addressing architecture. This is related to the integrity
above, but is independent of whether these services are applied
the middle of the network or at either end
Most of this document deals with the specific issue of data
with OPES services, including the goal of enabling end hosts
detect and respond to inappropriate behavior from broken
compromised OPES intermediaries
We agree that one-party consent, with one of the end-hosts
authorizing the OPES service, must be a requirement for OPES to
standardized in the IETF
However, as we discuss in the next section of this document, we
with [CDT01] that the one-party consent model by itself (e.g.,
one of the end-hosts authorizing the OPES service, and the
end-host perhaps being unaware of the OPES service) is
for protecting data integrity in the network. We also agree
IAB Informational [Page 4]
RFC 3238 IAB Considerations for OPES January 2002
[CDT01] that, regardless of the security and authorization
standardized for OPES in the IETF, OPES implementations
probably be modified to circumvent these mechanisms, resulting in
unauthorized modification of content. Many of the protocols in
IETF could be modified for anti-social purposes - transport
could be modified to evade end-to-end congestion control,
protocols could be modified to inject invalid routes, web
caches could be used for the unauthorized modification of
even without OPES, and so on. None of these seem like
reasons not to standardize transport protocols, routing protocols
web caching protocols, or OPES itself. In our view, it means
that the infrastructure needs, as much as possible, to be designed
detect and defend itself against compromised implementations,
misuses of protocols need to be addressed directly, each in
appropriate venue
Mechanisms such as digital signatures, which help users to verify
themselves that content has not been altered, are a first
towards the detection of the unauthorized modification of content
the network. However, in the case of OPES, additional protection
ensure the end-to-end integrity of data is desirable as well,
example, to help end-users to detect cases where OPES
were authorized to modify content, but perform
modifications. We would note that mechanisms can *help* end-users
detect compromised OPES intermediaries in some cases even if they
not *guarantee* that end-users will be able to detect
OPES intermediaries in all cases
If OPES is chartered, the OPES working group will also have
explicitly decide and document whether the OPES architecture must
compatible with the use of end-to-end encryption by one or more
of an OPES-involved session. If OPES was compatible with end-to-
encryption, this would effectively ensure that OPES boxes would
restricted to ones that are known, trusted, explicitly addressed
the IP layer, and authorized (by the provision of decryption keys)
at least one of the ends. Compatibility with end-to-end
would also help to prevent the widespread deployment of yet
set of services that, to benefit from, require one to keep one'
packet contents in the clear for all to snoop
IAB Considerations
(2.1) One-party consent: An OPES framework standardized in the
must require that the use of any OPES service be
authorized by one of the application-layer end-hosts (that is,
the content provider or the client).
IAB Informational [Page 5]
RFC 3238 IAB Considerations for OPES January 2002
(2.2) IP-layer communications: For an OPES framework standardized
the IETF, the OPES intermediary must be explicitly addressed at
IP layer by the end user
We note that (2.2) is not intended to preclude a chain
intermediaries, with the first intermediary in the chain
addressed at the IP layer by the end user
3. End-to-end
The proposed OPES services have several possible forms,
server-centric services, such as the dynamic assembling of web pages
explicitly authorized by the content provider; client-
services such as virus scanning or language translation
authorized by the end user to act on the response from the
provider; and client-centric services such as privacy-based
or content-filtering explicitly authorized by the end user to act
the request from the end user to the content provider. We
the issue of the end-to-end integrity of data separately for
different classes of services
For each specific service, the question arises of whether it
necessary for both the content provider and the end user to be
to detect and respond to inappropriate behavior by
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,
we do discuss the issues further in the sections below
3.1. Data integrity with client-centric OPES services on
Why is there any concern about the end-to-end integrity of data in
client-centric OPES service acting on a response from a
provider? If the client requests a service such as virus scanning
language translation, why is that of any concern to the
provider one way or another? One answer is that one of the
concerns of the IETF is to design architectures that enable end-
to detect and respond to inappropriate actions in the network.
seems of particular importance for powerful devices in the
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
are not under the direct control of that end-node
Consider as an example the services of virus scanning or
translation. The end user has reasonable power in detecting
dealing with imperfect or corrupted virus scanners or
translators that are under her direct control (e.g., on her
machine). The end user knows exactly what program is installed,
has direct access to the content before and after the service
IAB Informational [Page 6]
RFC 3238 IAB Considerations for OPES January 2002
applied. The end user would have less control over similar
offered by OPES in the network itself, where the end user's
control might be the binary one of authorizing or not authorizing
service. (We also note that services deployed on the end host in
self-contained fashion, such as a local virus scanning program,
not a service in the network, and therefore are not in the
of the IETF one way or another.)
For a OPES service such as virus scanning or language translation
the end user could detect a corrupted intermediary, but only
a "black-box" approach of comparing the input with the output.
is also imprecise and requires some effort, compared to the
required to detect a corrupted virus scanner installed on one's
machine. For example, the user could retrieve the "non-OPES"
of the content directly from the content provider, if there is
"non-OPES" version, and compare this with the "OPES" version of
content available from the OPES intermediary. However, in the
of dynamic content, the "non-OPES" version of the content
by the user directly from the content provider might not
be the same as the "non-OPES" version of the content considered
the OPES intermediary. This limited control by the end user of
OPES service, and the limited ability of the end user to
imperfect or corrupted intermediaries, argues for an
that helps the content provider to detect and respond to imperfect
corrupted OPES intermediaries as well
We consider the specific example of virus scanning, authorized by
end user as an OPES service. One could imagine virus scanning as
widely deployed OPES service, augmenting the virus scanning done
the end host itself. If I ask for, say, a paper by Steve Bellovin
security and viruses in the network, and am informed by my
OPES virus-scanning service that this content does not pass
virus-scan, there are a number of possibilities
(1) Unknown to Steve, the content (that is, Steve's paper) contains
harmful virus
(2) Steve inserted a harmful virus in the content on purpose,
playful or malicious intent
(3) The OPES virus scanner can't distinguish between a true
virus, and Steve's paper about harmful viruses
(4) My local OPES virus scanner has been hacked, with
intent, to reject all content from Steve Bellovin
IAB Informational [Page 7]
RFC 3238 IAB Considerations for OPES January 2002
At some point, for some content, some widely-deployed
of some OPES virus scanner is likely to result in problem (3),
some OPES implementation is likely to be corrupted to result
problem (4). Because the end user has limited control over the
virus scanner, the end user also is limited in its ability to
problems (3) or (4) in the OPES virus scanner. In addition,
content provider is probably the one with the strongest incentive
detect problems (3) or (4) in the OPES virus scanner. (The
provider generally has a strong incentive to detect problem (1)
well.) In this case, it seems prudent that the overall
architecture should be carefully designed to prevent the OPES
of virus scanning, as authorized by the client, from
preventing the distribution of content that in fact does not
viruses
Obviously, it is not viable to propose that content providers
indicate that some content should be passed to the end user
virus scanning - the point of virus scanning is for the end user
exercise control in this regard. However, if some form of end-
notification allows the content provider to find out that the
is being rejected by a virus scanning service instead of
delivered to the end user, then the content provider (Steve, in
case) might want to inform end users that this content is known
the content provider not to pass some OPES virus scanning services
End users could then make their own decisions about whether or not
retrieve that content bypassing the OPES virus scanning service
relying on their own virus scanner or an alternate virus
service for this particular content. Such end-system notification
the content provider, if requested, cannot be enforced, and cannot
relied upon from corrupted intermediaries, but it seems
nevertheless
Of course, malicious users can also use their awareness of the
scanning service to perfect their ability to construct
viruses that can evade the virus scanning service. This will be
anyway, with any virus scanning service, and seems like an
cost to allow content providers some protection against the
of imperfect or corrupted OPES services in the network
Thus, for client-requested services such as virus scanning
language translation, it is clearly desirable for the origin
to have notification, if it requests it, that these services
being performed on its content before the content is sent to
client. Any such end-system notification might be accompanied
reduced performance (in terms of overhead, delays, etc.) for the
service applied to that content. But some form of end-
IAB Informational [Page 8]
RFC 3238 IAB Considerations for OPES January 2002
notification is clearly necessary if content providers are to be
to detect and respond to actions by OPES intermediaries that
deemed inappropriate by the content provider
Similarly for a client-based OPES service of language translation,
is clearly desirable for content providers to be able to inform
users when some content is deemed by the content provider to
incompatible with language translation. In this case, the
issue is not to prevent the OPES language translation from
performed on the content, but instead to give the content
some mechanism to discover the language translation, and to
the end user (or more precisely, to inform the end user's
computer) if the content provider believes that this
translation is incompatible with this particular content
IAB Considerations
(3.1) Notification: The overall OPES framework needs to
content providers in detecting and responding to client-
actions by OPES intermediaries that are deemed inappropriate by
content provider
3.2. Data integrity with server-centric OPES
What are the concerns, if any, with the end-to-end integrity of
in a server-centric OPES service such as location-based services
For example, CNN could authorize a location-based OPES service,
the OPES intermediary inserts the weather report or news headline
regional interest into the requested web page. The same issue of
detection and response to broken or modified OPES
occurs with server-centric OPES as with client-centric OPES services
We only consider server-centric services on responses, as we are
aware of any proposals for server-centric OPES services on
from the client to the content provider
How are the end-nodes to detect inappropriate actions from
services authorized by the content provider? The OPES service
being performed at an OPES intermediary in the network itself,
not under the direct control of the content provider; in particular
the content provider might not have the ability to monitor
the output of the OPES intermediary. One could argue that
content provider and server-centric OPES intermediary are part of
single distributed application, and can be responsible on their
for detecting and dealing with broken or modified
intermediaries, without involving the end user. But this
unconvincing, basically arguing that standardizing protocols
performing OPES services is a network issue properly in the domain
the IETF, but the ensuring the overall integrity of the service is
IAB Informational [Page 9]
RFC 3238 IAB Considerations for OPES January 2002
distributed application matter, and not in the province of the
at all. It would seem to us that you can't have it both ways
Simply labeling the content provider and the OPES intermediary
part of the same distributed application does not give the
provider the ability to monitor the actions of the OPES intermediary
However, if the end user receives some form of notification
these OPES services have been provided, and has some mechanism
receiving the "non-OPES" content from the content provider
the OPES intermediary's modifications (if there is such a thing as
non-OPES version of the content), then the end user is in a
position to detect and react to inappropriate actions
compromised or poorly-designed OPES intermediaries. Thus, it
clear that some form of end-system notification is required to
the end user to detect and respond to broken or modified
intermediaries. If the end user has notification of action by
intermediaries, it could "veto" an OPES service simply by
the OPES-modified content away. And if the client wants to
directly to the origin server to receive the "non-OPES" version,
the origin server is configured to allow this, then the
intermediary must be designed to permit this end-to-
communication
In addition to concerns about detecting and responding to faulty
compromised OPES intermediaries, there are purely policy-
concerns about the integrity of data. If the content provider
at the source IP address from the HTTP request, or tosses a coin,
order to decide what content to provide, then that is the
provider's business. But if there exists a "non-OPES" version
some content available from the content provider, and also
versions available from OPES intermediaries, then it is
that end users would be able to discover that they are receiving
modified version from the network, and not the "non-OPES"
that is also available from the content provider directly
IAB Considerations
(3.2) Notification: The overall OPES framework should assist
users in detecting the behavior of OPES intermediaries,
allowing them to identify imperfect or compromised intermediaries
(3.3) Non-blocking: If there exists a "non-OPES" version of
available from the content provider, the OPES architecture must
prevent users from retrieving this "non-OPES" version from
content provider
IAB Informational [Page 10]
RFC 3238 IAB Considerations for OPES January 2002
3.3. Data integrity with client-centric OPES services on
There have also been proposals for OPES services authorized by
client on requests from the client to the content provider.
include services that remove fields from the HTTP header for
privacy, and content-filtering services that filter requests based
the requested URL. For such services, there is still a need for
hosts to be assisted in detecting and responding to imperfect
corrupted intermediaries, but it seems less clear to what extent
applies to the content provider, and to what extent it applies to
end user that authorized the service. The requirements will
have to be determined by the OPES and wider IETF communities on
case-by-case basis for each specific service
4. Application Layer
Most application layer addressing revolves around URIs, which,
the most part, give a structured method to refer to a single
entity on a remote server. URIs are universal in that, in principle
the same result is obtained irrespective of the location of
client performing the resolution
Practice often differs from this theory -- ad-strippers remove
from pages at the client end; web server farms redirect clients
one of several potential target machines for load-balancing or
give the user "localized" content
However, from an architectural standpoint, it is important to
clear about what is being done here. In all cases, URI
standards (as defined for individual URI schemes, such as HTTP)
unchanged between the client and the OPES intermediary. What
intermediary does to fulfill the request is not material to
discussion, and must produce a result that is compliant with
applicable URI scheme definition. In this sense, the
intermediary is the "endpoint" of URI resolution
In client-centric OPES, the intermediary is resolving the URI
behalf of the client, and then applying client-requested services
provide a data response to the client. The client gets the data
wanted, but it did not carry out the URI resolution
In server-centric OPES, the "origin server" cedes its authority
the intermediary to determine what is the "appropriate" content
supply for a given URI. The client may well perform standard
resolution, but that reaches no further than the intermediary
With those distinctions firmly in mind, there are two
areas of concern for OPES-like services
IAB Informational [Page 11]
RFC 3238 IAB Considerations for OPES January 2002
The first is the consideration of the effect of a series
interactions, over time and location (i.e., not just one
retrieval). Potential problems include inconsistencies in intra
and inter-document references -- depending on what content
changed, references from one version of a document might not exist
a modified target, etc
The other concern is whether this leads to the creation of
that is exclusively accessible through the use of an intermediary
That is, there is no "non-OPES" version. Either this should not
allowed, or this would argue for an extension to the
application layer addressing architecture
IAB Considerations
(4.1) URI resolution: OPES documentation must be clear in
these services as being applied to the result of URI resolution,
as URI resolution itself
(4.2) Reference validity: All proposed services must define
impact on inter- and intra-document reference validity
(4.3) Any services that cannot be achieved while respecting the
two considerations may be reviewed as potential requirements
Internet application addressing architecture extensions, but must
be undertaken as ad hoc fixes
5.
Intermediaries in the middle of the network increase the number
locations where the privacy of an end-to-end transaction could
compromised. Some of these privacy concerns apply to web caches
CDNs in general as well as specifically to OPES intermediaries.
seems a reasonable requirement, for OPES to be chartered in the IETF
that the issue of providing mechanisms for end users to determine
privacy policies of OPES intermediaries should be addressed.
mechanisms could be quite different for client-centric and server
centric OPES services
For a complex issue such as an OPES architecture, which
with protocols from other standards bodies as well as from other
working groups, it seems necessary to keep in mind the
picture while, at the same time, breaking out specific parts of
problem to be standardized in particular working groups. Thus,
requirement that the overall OPES architecture address
concerns does not necessarily mean that the mechanisms for this
to be developed in the IETF, or in the OPES working group (if it
chartered).
IAB Informational [Page 12]
RFC 3238 IAB Considerations for OPES January 2002
IAB Considerations
(5.1) Privacy: The overall OPES framework must provide for
for end users to determine the privacy policies of
intermediaries
6. Summary of IAB
(2.1) One-party consent: An OPES framework standardized in the
must require that the use of any OPES service be
authorized by one of the application-layer end-hosts (that is,
the content provider or the client).
(2.2) IP-layer communications: For an OPES framework standardized
the IETF, the OPES intermediary must be explicitly addressed at
IP layer by the end user
(3.1) Notification: The overall OPES framework needs to
content providers in detecting and responding to client-
actions by OPES intermediaries that are deemed inappropriate by
content provider
(3.2) Notification: The overall OPES framework should assist
users in detecting the behavior of OPES intermediaries,
allowing them to identify imperfect or compromised intermediaries
(3.3) Non-blocking: If there exists a "non-OPES" version of
available from the content provider, the OPES architecture must
prevent users from retrieving this "non-OPES" version from
content provider
(4.1) URI resolution: OPES documentation must be clear in
these services as being applied to the result of URI resolution,
as URI resolution itself
(4.2) Reference validity: All proposed services must define
impact on inter- and intra-document reference validity
(4.3) Any services that cannot be achieved while respecting the
two considerations may be reviewed as potential requirements
Internet application addressing architecture extensions, but must
be undertaken as ad hoc fixes
(5.1) Privacy: The overall OPES framework must provide for
for end users to determine the privacy policies of
intermediaries
IAB Informational [Page 13]
RFC 3238 IAB Considerations for OPES January 2002
7.
This document includes comments and recommendations by the IAB
some architectural and policy issues related to the chartering
OPES in the IETF
8.
This document has benefited from discussions with members of the
and the IESG, contributors to OPES, John Wroclawski, and others
However, this is a document of the IAB, and we do not claim that
other people listed above agree with the contents
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".
[CDT01] Policy Concerns Raised by Proposed OPES Working
Efforts, email to the IESG, from the Center for
& Technology, August 3, 2001.
"http://www.imc.org/ietf-openproxy/mail
archive/msg00828.html".
[Clark88] David D. Clark, The Design Philosophy of the
Internet Protocols, SIGCOMM 1988.
[Morris01] John Morris, "Re: corrected - Suggested
Requirements for Integrity, Privacy and Security",
September 28, 2001. Email to 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
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/".
[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".
IAB Informational [Page 14]
RFC 3238 IAB Considerations for OPES January 2002
[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes
"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".
[Orman01] Hilarie Orman, "Data Integrity for Open
Services", email to ietf-openproxy@imc.org, August 15,
2001. URL "http://www.imc.org/ietf-openproxy/mail
archive/msg00865.html".
[RFC 2316] Bellovin, S., "Report of the IAB Security
Workshop", RFC 2316, April 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[RFC 3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet
Replication and Caching Taxonomy", RFC 3040,
2001.
[RFC 3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z
Shelby, "Performance Enhancing Proxies Intended
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[Routson01] Joyce Routson, IETF's Edge Standards Controversy,
11, 2001, Stardust CDN Week.
"http://www.stardust.com/cdnweek/articles/2001/07/09/
opes.htm".
10. Security
This document does not propose any new protocols, and therefore
not involve any security considerations in that sense. However
throughout this document there are discussions of the privacy
integrity issues of OPES services and the architectural
created by those issues
11. IANA
There are no IANA considerations regarding this document
IAB Informational [Page 15]
RFC 3238 IAB Considerations for OPES January 2002
Authors'
Internet Architecture
EMail: iab@iab.
Membership at time this document was completed
Harald
Ran
Rob
Fred
Steve
Brian
Jon
Leslie
Steve
Sally
Geoff
John
Henning
IAB Informational [Page 16]
RFC 3238 IAB Considerations for OPES January 2002
12. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
IAB Informational [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
