draft-ietf-opes-iab-00.txt   draft-ietf-opes-iab-01.txt 
Open Pluggable Edge Services A. Barbir Open Pluggable Edge Services A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: December 11, 2003 A. Rousskov Expires: February 25, 2004 A. Rousskov
The Measurement Factory The Measurement Factory
June 12, 2003 August 27, 2003
OPES Treatment of IAB Considerations OPES Treatment of IAB Considerations
draft-ietf-opes-iab-00 draft-ietf-opes-iab-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 11, 2003. This Internet-Draft will expire on February 25, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
IETF Internet Architecture Board (IAB) expressed nine IETF Internet Architecture Board (IAB) expressed nine
architecture-level considerations when Open Pluggable Edge Services architecture-level considerations when Open Pluggable Edge Services
(OPES) working group was being chartered at the IETF. The working (OPES) working group was being chartered at the IETF. The working
skipping to change at page 2, line 12 skipping to change at page 2, line 12
addressed by the group. This document describes how OPES addresses addressed by the group. This document describes how OPES addresses
those considerations. those considerations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Consideration (2.1) One-party consent . . . . . . . . . . . . 5 3. Consideration (2.1) One-party consent . . . . . . . . . . . . 5
4. Consideration (2.2) IP-layer communications . . . . . . . . . 6 4. Consideration (2.2) IP-layer communications . . . . . . . . . 6
5. Notification Considerations . . . . . . . . . . . . . . . . . 8 5. Notification Considerations . . . . . . . . . . . . . . . . . 8
5.1 Consideration (3.1) Notification . . . . . . . . . . . . . . . 9 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8
5.2 Consideration (3.2) Notification . . . . . . . . . . . . . . . 10 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9
5.3 Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 11 5.3 Consideration (3.1) Notification . . . . . . . . . . . . . . . 10
6. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 12 5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12
7. Consideration (4.2) Reference validity . . . . . . . . . . . . 13 5.5 Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 12
8. Consideration (4.3) Addressing extensions . . . . . . . . . . 14 6. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14
9. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 15 7. Consideration (4.2) Reference validity . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Consideration (4.3) Addressing extensions . . . . . . . . . . 16
11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17
12. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . . . 20 12. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . . . 21 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 Normative References . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 22 Informative References . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture The Open Pluggable Edge Services (OPES) architecture
[I-D.ietf-opes-architecture], enables cooperative application [I-D.ietf-opes-architecture], enables cooperative application
services (OPES services) between a data provider, a data consumer, services (OPES services) between a data provider, a data consumer,
and zero or more OPES processors. The application services under and zero or more OPES processors. The application services under
consideration analyze and possibly transform application-level consideration analyze and possibly transform application-level
messages exchanged between the data provider and the data consumer. messages exchanged between the data provider and the data consumer.
Following controversy related to chartering OPES, IAB made In the process of chartering OPES, the IAB made recommendations on
recommendations on issues that OPES solutions should be required to issues that OPES solutions should be required to address. These
address. These recommendations were formulated in the form of recommendations were formulated in the form of specific IAB
specific IAB considerations [RFC3238]. IAB emphasized that its considerations [RFC3238]. IAB emphasized that its considerations did
considerations did not recommend specific solutions and did not not recommend specific solutions and did not mandate specific
mandate specific functional requirements. Addressing an IAB functional requirements. Addressing an IAB consideration may involve
consideration may involve showing appropriate protocol mechanisms or showing appropriate protocol mechanisms or demonstrating that the
demonstrating that the issue does not apply. issue does not apply. Addressing a consideration does not necessarily
mean supporting technology implied by the consideration wording.
The primary goal of this document is to show that all IAB The primary goal of this document is to show that all IAB
considerations are addressed by OPES, to the extent those considerations are addressed by OPES, to the extent those
considerations can be addressed by an IETF working group. We also considerations can be addressed by an IETF working group. Limitations
explicitly document limitations of our abilities to address certain of OPES working group ability to address certain aspects of IAB
aspects of IAB considerations. considerations are explicitly documented.
There are nine IAB considerations [RFC3238] that OPES has to address. There are nine IAB considerations [RFC3238] that OPES has to address.
In the core of this document are the corresponding nine In the core of this document are the corresponding nine
"Consideration" sections. For each IAB consideration, its section "Consideration" sections. For each IAB consideration, its section
contains general discussion as well as references to specific OPES contains general discussion as well as references to specific OPES
mechanisms relevant to the consideration. mechanisms relevant to the consideration.
2. Terminology 2. Terminology
This document does not introduce any new terminology but uses This document does not introduce any new terminology but uses
skipping to change at page 5, line 14 skipping to change at page 5, line 14
3. Consideration (2.1) One-party consent 3. Consideration (2.1) One-party consent
"An OPES framework standardized in the IETF must require that the use "An OPES framework standardized in the IETF must require that the use
of any OPES service be explicitly authorized by one of the of any OPES service be explicitly authorized by one of the
application-layer end-hosts (that is, either the content provider or application-layer end-hosts (that is, either the content provider or
the client)."[RFC3238] the client)."[RFC3238]
OPES architecture requires that "OPES processors MUST be consented to OPES architecture requires that "OPES processors MUST be consented to
by either the data consumer or data provider application" by either the data consumer or data provider application"
[I-D.ietf-opes-architecture]. The requirement alone cannot prevent [I-D.ietf-opes-architecture]. This requirement alone cannot prevent
consent-less introduction of OPES processors, of course. OPES consent-less introduction of OPES processors. In
enables concerned parties to detect unwanted OPES processors by [I-D.ietf-opes-end-comm], the OPES architecture enables concerned
examining OPES traces and by checking content signatures. parties to detect unwanted OPES processors by examining OPES traces.
The use of traces in OPES is mandatory.
Tracing is a weak but cheap mechanism that is unable to detect Tracing mechanism on its own is unable to detect processors that are
processors incompliant with OPES specifications on tracing and in violation of OPES specifications. Examples include OPES processors
operating in stealth mode. Content signatures is a strong but operating in stealth mode. However, the OPES architecture allows the
expensive mechanism that can detect any modifications of signed use of content signature to verify the authenticity of performed
content provided the content provider is willing to sign the data and adaptations. Content signatures is a strong but expensive mechanism
the client is willing to either check the signature or relay received that can detect any modifications of signed content provided the
content to content provider for signature verification. content provider is willing to sign the data and the client is
willing to either check the signature or relay received content to
content provider for signature verification.
OPES adaptations include copying and other forms of non-modifying OPES adaptations may include copying and other forms of non-modifying
access to content. These kinds of adaptations cannot be detected by access to content. These kinds of adaptations cannot be detected by
the above mentioned mechanisms. Thus, "passive" unwanted OPES the above mentioned mechanisms. Thus, "passive" OPES processors can
processors cannot be detected. If presence of such processors is a operate without consent. If presence of such processors is a concern,
concern, content encryption can be used. See privacy consideration content encryption can be used. A passive processor is no different
for more details. from a proxy or intermediary operating outside of OPES framework. No
OPES mechanism can prevent non-modifying access to content.
4. Consideration (2.2) IP-layer communications 4. Consideration (2.2) IP-layer communications
"For an OPES framework standardized in the IETF, the OPES "For an OPES framework standardized in the IETF, the OPES
intermediary must be explicitly addressed at the IP layer by the end intermediary must be explicitly addressed at the IP layer by the end
user."[RFC3238] user."[RFC3238]
OPES architecture requires that "OPES processors MUST be addressable OPES architecture requires that "OPES processors MUST be addressable
at the IP layer by the end user (data consumer application)" at the IP layer by the end user (data consumer application)"
[I-D.ietf-opes-architecture]. Two caveats are related to this [I-D.ietf-opes-architecture]. IAB and the architecture draft mention
requirement. First, addressing the first OPES processor in a chain of an important exception: addressing the first OPES processor in a
processors is sufficient. That is, a chain of OPES processors is chain of processors is sufficient. That is, a chain of OPES
viewed as a single OPES processor at the address of the first chain processors is viewed as a single OPES "system" at the address of the
element. (XXX: should we move these caveats into a separate section? first chain element.
they seem to affect many considerations; one the other hand, it is
probably the job of the architecture draft to define these things so
that we can refer to them from here.)
The second caveat is more controversial. Only a very limited subset The notion of a chain is not strictly defined by IAB. For the purpose
of OPES intermediaries are subject to the above requirements. The of addressing this consideration, we consider a group of OPES
situation is examined below, by considering content provider and end processors working on a given application transaction. Such a group
user sides of the architecture. would necessarily form a single processing chain, with a single
"exit" OPES processor (the processor that adapted the given message
last). OPES architecture essentially requires that last OPES
processor to be explicitly addressable at the IP layer by the end
user. Note that chain formation, including its exit point may depend
on an application message and other dynamic factors such as time of
day or system load.
OPES processors that operate under content provider consent may not Furthermore, if OPES processing is an internal processing step at
be subject to the above consideration and requirement (XXX the data consumer or provider side, then the last OPES processor may
architecture draft does not reflect this). It is irrational to expect reside in a private address space of the side's network and may not
a content provider to provide access to internal hosts participating be explicitly addressable. In such situations, the processing side
in content generation, whether OPES processors are involved or not. must designate an addressable point on the same processing chain.
Moreover, providing such access would serve little practical purpose That designated point may not be, strictly speaking, an OPES
because internal OPES processors are not likely to be able to answer processor, but it will suffice as such as far as IAB considerations
any end user queries, being completely our of content generation are concerned -- the other side will be able to address it explicitly
context. For example, an OPES processor adding customer-specific at the IP layer and it will represent the OPES processing chain to
information to XML pages may not understand or be aware of any final the outside world.
HTML content that the end user receives and may not be able to map
end user request to any internal user identification.
OPES processors that operate under end user consent may not be Designating an addressable processing point avoids the conflict
subject to the above consideration and requirement (XXX the between narrow interpretation of IAB consideration and real system
architecture draft does not reflect this). It is irrational to expect designs: It is irrational to expect a content provider to provide
a client-side ISP to provide access to internal hosts participating access to internal hosts participating in content generation, whether
in content processing, whether OPES processors are involved or not. OPES processors are involved or not. Moreover, providing such access
Moreover providing such access would serve little practical purpose would serve little practical purpose because internal OPES processors
because internal OPES processors are not likely to be able to answer are not likely to be able to answer any end user queries, being
any end user queries, being completely our of content processing completely out of content generation context. For example, an OPES
context. For example, an OPES processor making a client-authorized processor adding customer-specific information to XML pages may not
XML content translation may not understand or be aware of any final understand or be aware of any final HTML content that the end user
HTML content that the end user receives and may not be able to map receives and may not be able to map end user request to any internal
end user request to any internal user identification. user identification. Since OPES requires the end of the message
processing chain to be addressable, the conflict does not exist --
OPES places no requirements on the internal architecture of data
producer systems while requiring the entire OPES-related content
production "system" to be addressable at the IP layer.
IAB consideration 2.2 apparently was not meant to apply to "internal" Public/Private Domain | Private Domain
OPES intermediaries. It may be better interpreted as "If the first |
intermediary on end user's message processing path is an OPES +--------------+ | +------+
intermediary, that intermediary must be explicitly addressed at the | Data | *-------* +----------+ | | OPES |
IP layer by the end user". In other words, the end user is assured | Consumer |<-->/ Network \<-->| Public IP| | +------+
that the first intermediary that touches her request is explicitly | Application | \(Public) / | Address |<-->| .
addressed if it is an OPES intermediary. +--------------+ *-------* | OPES | | .
+----------+ | .
| +------+
| | OPES |
| +------+
|
Figure 1
(XXX: should we add a picture showing internal and external OPES (XXX: should we add a picture showing internal and external OPES
intermediaries?) intermediaries? more pictures showing other OPES layouts? Move to
architecture draft?)
5. Notification Considerations 5. Notification Considerations
This section discusses how OPES framework addresses IAB Notification This section discusses how OPES framework addresses IAB Notification
concerns 3.1 and 3.2. OPES framework concentrates on tracing rather considerations 3.1 and 3.2.
than notification. The tracing specification [XXX] defines "OPES
trace" as "application message information about OPES entities that 5.1 Notification versus trace
adapted that message" and "OPES tracing" as "the process of
including, manipulating, and interpreting an OPES trace" (XXX: keep Before specific considerations are discussed, the relationship
these in sync). Thus, OPES trace follows the application message it between IAB notifications and OPES tracing has to be explained. OPES
traces. It notifies the recipient of the message of what has happened framework concentrates on tracing rather than notification. The
to that message. Traces are implemented as extensions of application tracing specification [I-D.ietf-opes-end-comm] defines "OPES trace"
protocols being adapted and traced. as "application message information about OPES entities that adapted
that message" and "OPES tracing" as "the process of including,
manipulating, and interpreting an OPES trace" (XXX: keep these in
sync). Thus, OPES trace follows the application message it traces.
The trace is for the recipient of the application message. Traces are
implemented as extensions of application protocols being adapted and
traced.
As opposed to an OPES trace, provider notification (as implied by As opposed to an OPES trace, provider notification (as implied by
IAB) notifies the sender of the message of what had happened to the IAB) notifies the sender of the application message rather than the
message after the message left the sender. Thus, notifications recipient. Thus, notifications propagate in the opposite direction of
propagate in the opposite direction of traces. Supporting traces. Supporting notifications directly would require a new
notifications directly would require a new protocol. Figure XXX protocol. Figure XXX illustrates the differences between a trace and
illustrates the differences between a trace and notification from a notification from a single application message point of view.
single application message point of view.
sender --[message A]---> OPES --[message A' + trace]--> recipient sender --[message A]---> OPES --[message A' + trace]--> recipient
^ V ^ V
| | | |
+-<-- [notification] ---+ +-<-- [notification] ---+
Figure 1 Figure 2
Since notifications cannot be piggy-backed to application messages, Since notifications cannot be piggy-backed to application messages,
they create new messages and may at least double the number of they create new messages and may at least double the number of
messages the sender has to process (more if several intermediaries on messages the sender has to process (more if several intermediaries on
the message path emit notifications). Moreover, a notification the message path emit notifications). Moreover, associating
message may refer to some sender state that has to be kept around notifications with application messages may require duplicating
until notification is received, increasing performance overhead of application message information in notifications and/or maintaining a
notifications. These concerns call for optional notification, with a sender state until notification is received, increasing performance
special protocol to enable notifications when needed. overhead of notifications. These concerns call for optional
notification, with a special protocol to enable notifications when
needed.
The level of available details in notifications versus provider The level of available details in notifications versus provider
interest in supporting notification is another concern. Experience interest in supporting notification is another concern. Experience
shows that content providers often require very detailed information shows that content providers often require very detailed information
about user actions to be interested in notifications at all. For about user actions to be interested in notifications at all. For
example, Hit Metering protocol [XXX] has been designed to supply example, Hit Metering protocol [XXX] has been designed to supply
content providers with proxy cache hit counts, in an effort to reduce content providers with proxy cache hit counts, in an effort to reduce
cache busting behavior which was caused by content providers desire cache busting behavior which was caused by content providers desire
to get accurate site "access counts". However, the Hit Metering to get accurate site "access counts". However, the Hit Metering
protocol is currently not widely deployed because the protocol does protocol is currently not widely deployed because the protocol does
not supply content providers with information such as client IP not supply content providers with information such as client IP
addresses, browser versions, or cookies. addresses, browser versions, or cookies.
The Hit Metering experience is relevant because Hit Metering protocol Hit Metering experience is relevant because Hit Metering protocol was
was designed to do for HTTP caching intermediaries what OPES designed to do for HTTP caching intermediaries what OPES
notifications are meant to do for OPES intermediaries. Performance notifications are meant to do for OPES intermediaries. Performance
requirements call for state reduction via aggregation of requirements call for state reduction via aggregation of
notifications while provider preferences call for state preservation notifications while provider preferences call for state preservation
or duplication. Achieving the right balance when two sides belong to or duplication. Achieving the right balance when two sides belong to
different organizations and have different optimization priorities is different organizations and have different optimization priorities
probably impossible in general. may be impossible.
Thus, instead of explicitly supporting notifications on a protocol Thus, instead of explicitly supporting notifications on a protocol
level, OPES concentrates on tracing facilities and supports level, OPES concentrates on tracing facilities and supports
notifications indirectly, using those tracing facilities. In other notifications indirectly, using those tracing facilities. In other
words, the IAB choice of "Notification" label is interpreted as words, the IAB choice of "Notification" label is interpreted as
"Notification assistance" (i.e. making notifications meaningful) and "Notification assistance" (i.e. making notifications meaningful) and
is not interpreted as a "Notification protocol". is not interpreted as a "Notification protocol".
5.1 Consideration (3.1) Notification 5.2 An example of an OPES trace for HTTP
The example below illustrates adaptations done to HTTP request at an
OPES intermediary operated by the client ISP. Both original (as sent
by an end user) and adapted (as received by the origin web server)
requests are shown. The primary adaptation is the modification of
HTTP "Accept" header. The secondary adaptation is the addition of an
"OPES-Via" HTTP extension header.
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain
Figure 3
... may be adapted by an ISP OPES system to become:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8
OPES-Via: http://www.isp-example.com/opes/?client-hash=1234567
Figure 4
The example below illustrates adaptations done to HTTP response at an
OPES intermediary operated by a Content Distribution Network (CDN).
Both original (as sent by the origin web server) and adapted (as
received by the end user) responses are shown. The primary adaptation
is the conversion from HTML markup to plain text. The secondary
adaptation is the addition of an "OPES-Via" HTTP extension header.
HTTP/1.1 200 OK
Content-Length: 12345
Content-Encoding: text/html
<html><head><h1>Available Documenta...
Figure 5
... may be adapted by a CDN OPES system to become:
HTTP/1.1 200 OK
Content-Length: 2345
Content-Encoding: text/plain
OPES-Via: http://www.cdn-example.com/opes/?site=7654321&service=h2t
AVAILABLE DOCUMENTA...
Figure 6
In the above examples, "OPES-Via" header values contain URLs that may
point to OPES-specific documents such as description of the OPES
operator and its privacy policy. Those documents may be
parameterized to allow for customizations specific to the transaction
being traced (e.g., client or even transaction identifier may be used
to provide more information about performed adaptations). Traced OPES
URLs may be later used to request OPES bypass. (XXX: OPES specs will
need to define OPES-Via format and semantics)
5.3 Consideration (3.1) Notification
"The overall OPES framework needs to assist content providers in "The overall OPES framework needs to assist content providers in
detecting and responding to client-centric actions by OPES detecting and responding to client-centric actions by OPES
intermediaries that are deemed inappropriate by the content intermediaries that are deemed inappropriate by the content
provider."[RFC3238] provider."[RFC3238]
OPES tracing mechanisms assist content providers in detecting OPES tracing mechanisms assist content providers in detecting
client-centric actions by OPES intermediaries. Specifically, a client-centric actions by OPES intermediaries. Specifically, a
compliant OPES intermediary or system notifies a content provider of compliant OPES intermediary or system notifies a content provider of
its presence by including its tracing information in the application its presence by including its tracing information in the application
protocol requests. An OPES intermediary MUST leave its trace (XXX protocol requests. An OPES system MUST leave its trace (XXX quote
quote tracing draft). Detection assistance has its limitations. Some tracing draft) [I-D.ietf-opes-end-comm]. Detection assistance has
OPES intermediaries may work exclusively on responses and may not its limitations. Some OPES intermediaries may work exclusively on
have a chance to trace the request. Moreover, some application responses and may not have a chance to trace the request. Moreover,
protocols may not have explicit requests (e.g., a content push some application protocols may not have explicit requests (e.g., a
service). content push service).
OPES tracing mechanisms assist content providers in responding to OPES tracing mechanisms assist content providers in responding to
client-centric actions by OPES intermediaries. Specifically, OPES client-centric actions by OPES intermediaries. Specifically, OPES
traces MUST include identification of OPES systems and SHOULD include traces MUST include identification of OPES systems and SHOULD include
a list of adaptation actions performed on provider's content. This a list of adaptation actions performed on provider's content. This
tracing information may be included in the application request. tracing information may be included in the application request.
Usually, however, this information will be included in the Usually, however, this information will be included in the
application response, an adapted version of which does not reach the application response, an adapted version of which does not reach the
content provider. If OPES end points cooperate, then notification can content provider. If OPES end points cooperate, then notification can
be assisted with traces. Content providers that suspect or experience be assisted with traces. Content providers that suspect or experience
skipping to change at page 10, line 32 skipping to change at page 12, line 5
policy using appropriate OPES bypass mechanisms and/or end-to-end policy using appropriate OPES bypass mechanisms and/or end-to-end
encryption mechanisms. encryption mechanisms.
OPES detection and response assistance is limited to application OPES detection and response assistance is limited to application
protocols with support for tracing extensions. For example, HTTP protocols with support for tracing extensions. For example, HTTP
[RFC2616] has such support while DNS over UDP does not. [RFC2616] has such support while DNS over UDP does not.
(XXX: should we prohibit adaptation of application protocols that do (XXX: should we prohibit adaptation of application protocols that do
not allow for tracing?) not allow for tracing?)
5.2 Consideration (3.2) Notification 5.4 Consideration (3.2) Notification
"The overall OPES framework should assist end users in detecting the "The overall OPES framework should assist end users in detecting the
behavior of OPES intermediaries, potentially allowing them to behavior of OPES intermediaries, potentially allowing them to
identify imperfect or compromised intermediaries."[RFC3238] identify imperfect or compromised intermediaries."[RFC3238]
OPES tracing mechanisms assist end users in detecting OPES OPES tracing mechanisms assist end users in detecting OPES
intermediaries. Specifically, a compliant OPES intermediary or system intermediaries. Specifically, a compliant OPES intermediary or system
notifies an end user of its presence by including its tracing notifies an end user of its presence by including its tracing
information in the application protocol messages sent to the client. information in the application protocol messages sent to the client.
An OPES intermediary MUST leave its trace (XXX quote tracing draft). An OPES intermediary MUST leave its trace (XXX quote tracing draft)
Detection assistance has its limitations. Some OPES intermediaries [I-D.ietf-opes-end-comm]. Detection assistance has its limitations.
may work exclusively on requests and may not have a chance to trace Some OPES intermediaries may work exclusively on requests and may not
the response. Moreover, some application protocols may not have have a chance to trace the response. Moreover, some application
explicit responses (e.g., event logging service). protocols may not have explicit responses (e.g., event logging
service).
OPES detection assistance is limited to application protocols with OPES detection assistance is limited to application protocols with
support for tracing extensions. For example, HTTP [RFC2616] has such support for tracing extensions. For example, HTTP [RFC2616] has such
support while DNS over UDP does not. support while DNS over UDP does not.
(XXX: should we prohibit adaptation of application protocols that do (XXX: should we prohibit adaptation of application protocols that do
not allow for tracing?) not allow for tracing?)
5.3 Consideration (3.3) Non-blocking 5.5 Consideration (3.3) Non-blocking
"If there exists a "non-OPES" version of content available from the "If there exists a "non-OPES" version of content available from the
content provider, the OPES architecture must not prevent users from content provider, the OPES architecture must not prevent users from
retrieving this "non-OPES" version from the content retrieving this "non-OPES" version from the content
provider."[RFC3238] provider."[RFC3238]
OPES intermediaries MUST support a bypass feature (XXX quote bypass OPES intermediaries MUST support a bypass feature (XXX quote bypass
draft). If an application message includes bypass instructions, the draft) [I-D.ietf-opes-end-comm]. If an application message includes
matching OPES intermediary will not process the message. Bypass may bypass instructions and an OPES intermediary is not configured to
generate content errors since some OPES services may be essential. ignore them, the matching OPES intermediary will not process the
(Should there be a way to bypass non-essential services only?) message. An intermediary may be configured to ignore bypass
instructions only if no non-OPES version of content is available.
Bypass may generate content errors since some OPES services may be
essential but may not be configured as such.
Bypass support has limitations similar to the two Bypass support has limitations similar to the two
notification-related considerations above. notification-related considerations above. (XXX: but it is possible
to instruct all OPES intermediaries to bypass an application message
without knowing all OPES intermediaries IDs).
(XXX: Ideally, this section need to be polished further -- if there
is no non-OPES version of the content, most IAB considerations
probably do not apply because there is really no adaptation, only
creation of content; and we should not restrict content creation.)
6. Consideration (4.1) URI resolution 6. Consideration (4.1) URI resolution
"OPES documentation must be clear in describing these services as "OPES documentation must be clear in describing these services as
being applied to the result of URI resolution, not as URI resolution being applied to the result of URI resolution, not as URI resolution
itself."[RFC3238] itself."[RFC3238]
"OPES Scenarios and Use Cases" specification "OPES Scenarios and Use Cases" specification
[I-D.ietf-opes-scenarios] documents content adaptations that are in [I-D.ietf-opes-scenarios] documents content adaptations that are in
scope of the OPES framework (XXX provide a quote). These adaptations scope of the OPES framework (XXX provide a quote). These adaptations
skipping to change at page 13, line 16 skipping to change at page 15, line 16
"All proposed services must define their impact on inter- and "All proposed services must define their impact on inter- and
intra-document reference validity."[RFC3238] intra-document reference validity."[RFC3238]
OPES working group does not propose adaptation services. However, OPES working group does not propose adaptation services. However,
OPES tracing requirements include identification of OPES OPES tracing requirements include identification of OPES
intermediaries and services (for details, see "Notification" intermediaries and services (for details, see "Notification"
consideration sections in this document). It is required that consideration sections in this document). It is required that
provided identification can be used to locate information about the provided identification can be used to locate information about the
OPES intermediaries, including the description of impact on reference OPES intermediaries, including the description of impact on reference
validity (XXX quote tracing draft). validity (XXX quote tracing draft) [I-D.ietf-opes-end-comm].
8. Consideration (4.3) Addressing extensions 8. Consideration (4.3) Addressing extensions
"Any services that cannot be achieved while respecting the above two "Any services that cannot be achieved while respecting the above two
considerations may be reviewed as potential requirements for Internet considerations may be reviewed as potential requirements for Internet
application addressing architecture extensions, but must not be application addressing architecture extensions, but must not be
undertaken as ad hoc fixes."[RFC3238] undertaken as ad hoc fixes."[RFC3238]
OPES framework does not contain ad hoc services. This and other OPES OPES framework does not contain ad hoc fixes. This and other OPES
documents should be sufficient to inform service creators of IAB documents should be sufficient to inform service creators of IAB
considerations. If a service does URI resolution or silently affects considerations. If a service does URI resolution or silently affects
document reference validity, the authors are requested to review document reference validity, the authors are requested to review
service impact on Internet application addressing architecture and service impact on Internet application addressing architecture and
work within IETF on potential extension requirements. work within IETF on potential extension requirements. Such actions
would be outside of the current OPES framework.
9. Consideration (5.1) Privacy 9. Consideration (5.1) Privacy
"The overall OPES framework must provide for mechanisms for end users "The overall OPES framework must provide for mechanisms for end users
to determine the privacy policies of OPES intermediaries."[RFC3238] to determine the privacy policies of OPES intermediaries."[RFC3238]
OPES tracing mechanisms allow end users to identify OPES OPES tracing mechanisms allow end users to identify OPES
intermediaries (for details, see "Notification" consideration intermediaries (for details, see "Notification" consideration
sections in this document). It is required that provided sections in this document). It is required that provided
identification can be used to locate information about the OPES identification can be used to locate information about the OPES
skipping to change at page 18, line 14 skipping to change at page 20, line 14
12. To-do 12. To-do
security section: Does this document have any original security security section: Does this document have any original security
matters worth documenting? matters worth documenting?
normative IDs: To be normative, OPES Internet-Drafts must be replaced normative IDs: To be normative, OPES Internet-Drafts must be replaced
with corresponding RFCs when the latter are published. with corresponding RFCs when the latter are published.
architecture draft: Should architecture draft talk about external/ architecture draft: Should architecture draft talk about external/
internal OPES intermediaries and about privacy policies? Should internal OPES intermediaries, OPES systems, and privacy policies?
this document be limited to a compilation of references from other Should this document be limited to a compilation of references
OPES drafts, or should we introduce/discuss new concepts here? from other OPES drafts, or should we introduce/discuss new
concepts here?
Appendix A. Change Log Appendix A. Change Log
Internal WG revision control ID: $Id: iab-cons.xml,v 1.13 2003/06/12 Internal WG revision control ID: $Id: iab-cons.xml,v 1.19 2003/08/28
15:38:48 rousskov Exp $ 03:48:32 rousskov Exp $
head-sid15
* Added a figure showing a chain of internal OPES intermediaries
behind a public IP address. Needs more work. More cases?
head-sid14
* Rewrote the Introduction to the IP addressing consideration.
Do NOT explain how IAB considerations, if interpreted literary,
do not satisfy important real-world constraints. Instead, use
the "chain of OPES intermediaries" exception introduced by IAB
itself to show that OPES architecture addresses IAB concerns as
long as the "chain" is defined/formed for a given application
message rather than being a statically configured application
routing table of sorts. IAB had to add the "chain" exception to
cover one of the most obvious real-world usage scenario. We use
the very same exception to cover all usage scenarios we care
about.
* Polished text explaining the differences between tracing and
notification mechanisms.
* Added examples of OPES/HTTP traces.
* Be careful not to imply that all OPES intermediaries must obey
bypass instructions. Bypass should be ignored when no non-OPES
version of the content exists. Ideally, this may need to be
polished further -- if there is no non-OPES version of the
content, most IAB considerations probably do not apply because
there is really no adaptation, only creation of content (and we
should not restrict content creation).
* Added references to OPES "Communications" draft
[I-D.ietf-opes-end-comm].
head-sid9 head-sid9
* Polished to meet new xml2rfc sctrict requirements. * Polished to meet new xml2rfc strict requirements.
head-sid8 head-sid8
* Added unpolished meat for all nine considerations. * Added unpolished meat for all nine considerations.
* Added Abbie Barbir as an author. * Added Abbie Barbir as an author.
head-sid7 head-sid7
* Initial revision * Initial revision
Normative References Normative References
[I-D.ietf-opes-end-comm]
Barbir, A., "OPES processor and end points
communications", draft-ietf-opes-end-comm-00 (work in
progress), June 2003.
[I-D.ietf-opes-architecture] [I-D.ietf-opes-architecture]
Barbir, A., "An Architecture for Open Pluggable Edge Barbir, A., "An Architecture for Open Pluggable Edge
Services (OPES)", draft-ietf-opes-architecture-04 (work in Services (OPES)", draft-ietf-opes-architecture-04 (work in
progress), December 2002. progress), December 2002.
[I-D.ietf-opes-scenarios] [I-D.ietf-opes-scenarios]
Barbir, A., "OPES Use Cases and Deployment Scenarios", Barbir, A., "OPES Use Cases and Deployment Scenarios",
draft-ietf-opes-scenarios-01 (work in progress), August draft-ietf-opes-scenarios-01 (work in progress), August
2002. 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/