draft-ietf-opes-iab-01.txt   draft-ietf-opes-iab-02.txt 
Open Pluggable Edge Services A. Barbir Open Pluggable Edge Services A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: February 25, 2004 A. Rousskov Expires: March 23, 2004 A. Rousskov
The Measurement Factory The Measurement Factory
August 27, 2003 September 23, 2003
OPES Treatment of IAB Considerations OPES Treatment of IAB Considerations
draft-ietf-opes-iab-01 draft-ietf-opes-iab-02
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 February 25, 2004. This Internet-Draft will expire on March 23, 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 16 skipping to change at page 2, line 16
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 Notification versus trace . . . . . . . . . . . . . . . . . . 8 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8
5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9
5.3 Consideration (3.1) Notification . . . . . . . . . . . . . . . 10 5.3 Consideration (3.1) Notification . . . . . . . . . . . . . . . 10
5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12 5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12
5.5 Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 12 6. Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 13
6. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14 7. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14
7. Consideration (4.2) Reference validity . . . . . . . . . . . . 15 8. Consideration (4.2) Reference validity . . . . . . . . . . . . 15
8. Consideration (4.3) Addressing extensions . . . . . . . . . . 16 9. Consideration (4.3) Addressing extensions . . . . . . . . . . 16
9. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17 10. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Normative References . . . . . . . . . . . . . . . . . . . . . 23 Normative References . . . . . . . . . . . . . . . . . . . . . 23
Informative References . . . . . . . . . . . . . . . . . . . . 24 Informative References . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25 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
skipping to change at page 9, line 28 skipping to change at page 9, line 28
different organizations and have different optimization priorities different organizations and have different optimization priorities
may be impossible. 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".
Nevertheless, OPES architecture allows for an efficient and
meaningful notification protocol to be implemented in certain OPES
environments. For specific examples, see the "Optional Notification"
section in [I-D.ietf-opes-end-comm].
5.2 An example of an OPES trace for HTTP 5.2 An example of an OPES trace for HTTP
The example below illustrates adaptations done to HTTP request at an The example below illustrates adaptations done to HTTP request at an
OPES intermediary operated by the client ISP. Both original (as sent OPES intermediary operated by the client ISP. Both original (as sent
by an end user) and adapted (as received by the origin web server) by an end user) and adapted (as received by the origin web server)
requests are shown. The primary adaptation is the modification of requests are shown. The primary adaptation is the modification of
HTTP "Accept" header. The secondary adaptation is the addition of an HTTP "Accept" header. The secondary adaptation is the addition of an
"OPES-Via" HTTP extension header. "OPES-Via" HTTP extension header.
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
skipping to change at page 12, line 29 skipping to change at page 13, line 5
protocols may not have explicit responses (e.g., event logging protocols may not have explicit responses (e.g., event logging
service). 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.5 Consideration (3.3) Non-blocking 6. 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) [I-D.ietf-opes-end-comm]. If an application message includes draft) [I-D.ietf-opes-end-comm]. If an application message includes
bypass instructions and an OPES intermediary is not configured to bypass instructions and an OPES intermediary is not configured to
ignore them, the matching OPES intermediary will not process the ignore them, the matching OPES intermediary will not process the
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Bypass support has limitations similar to the two Bypass support has limitations similar to the two
notification-related considerations above. (XXX: but it is possible notification-related considerations above. (XXX: but it is possible
to instruct all OPES intermediaries to bypass an application message to instruct all OPES intermediaries to bypass an application message
without knowing all OPES intermediaries IDs). without knowing all OPES intermediaries IDs).
(XXX: Ideally, this section need to be polished further -- if there (XXX: Ideally, this section need to be polished further -- if there
is no non-OPES version of the content, most IAB considerations is no non-OPES version of the content, most IAB considerations
probably do not apply because there is really no adaptation, only probably do not apply because there is really no adaptation, only
creation of content; and we should not restrict content creation.) creation of content; and we should not restrict content creation.)
6. Consideration (4.1) URI resolution 7. 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
do not include URI resolution (XXX check). In some environments, it do not include URI resolution (XXX check). In some environments, it
is technically possible to adapt URIs (and other kinds of identifiers is technically possible to adapt URIs (and other kinds of identifiers
or addresses) using documented OPES mechanisms. or addresses) using documented OPES mechanisms.
7. Consideration (4.2) Reference validity 8. Consideration (4.2) Reference validity
"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) [I-D.ietf-opes-end-comm]. validity (XXX quote tracing draft) [I-D.ietf-opes-end-comm].
8. Consideration (4.3) Addressing extensions 9. 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 fixes. 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. Such actions work within IETF on potential extension requirements. Such actions
would be outside of the current OPES framework. would be outside of the current OPES framework.
9. Consideration (5.1) Privacy 10. 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
intermediaries, including their privacy policies. intermediaries, including their privacy policies.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
context (by IAB or OPES working group). OPES tracing mechanisms allow context (by IAB or OPES working group). OPES tracing mechanisms allow
end users and content providers to identify OPES intermediaries. It end users and content providers to identify OPES intermediaries. It
is believed that once an intermediary is identified, it would be is believed that once an intermediary is identified, it would be
possible to locate relevant information about that intermediary, possible to locate relevant information about that intermediary,
including information relevant to requesters perception of privacy including information relevant to requesters perception of privacy
policy or reference validity. (XXX: should we move this paragraph policy or reference validity. (XXX: should we move this paragraph
into a separate section and expand it? one the other hand, it is into a separate section and expand it? one the other hand, it is
probably the job of the architecture draft to define these things so probably the job of the architecture draft to define these things so
that we can refer to them from here.) that we can refer to them from here.)
10. Security Considerations 11. Security Considerations
XXX. XXX.
11. Compliance 12. Compliance
This document may be perceived as a proof of OPES compliance with IAB This document may be perceived as a proof of OPES compliance with IAB
implied recommendations. However, this document does not introduce implied recommendations. However, this document does not introduce
any compliance subjects. Compliance of OPES implementations is any compliance subjects. Compliance of OPES implementations is
defined in other OPES documents discussed above. defined in other OPES documents discussed above.
12. To-do 13. 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, OPES systems, and privacy policies? internal OPES intermediaries, OPES systems, and privacy policies?
Should this document be limited to a compilation of references Should this document be limited to a compilation of references
from other OPES drafts, or should we introduce/discuss new from other OPES drafts, or should we introduce/discuss new
concepts here? concepts here?
Appendix A. Change Log Appendix A. Change Log
Internal WG revision control ID: $Id: iab-cons.xml,v 1.19 2003/08/28 Internal WG revision control ID: $Id: iab-cons.xml,v 1.20 2003/09/24
03:48:32 rousskov Exp $ 05:20:21 rousskov Exp $
2003/09/23
* Added a reference to Optional Notification section of the
ietf-opes-end-comm draft.
* Fixed "Consideration (3.3) Non-blocking" section position.
head-sid15 head-sid15
* Added a figure showing a chain of internal OPES intermediaries * Added a figure showing a chain of internal OPES intermediaries
behind a public IP address. Needs more work. More cases? behind a public IP address. Needs more work. More cases?
head-sid14 head-sid14
* Rewrote the Introduction to the IP addressing consideration. * Rewrote the Introduction to the IP addressing consideration.
Do NOT explain how IAB considerations, if interpreted literary, Do NOT explain how IAB considerations, if interpreted literary,
skipping to change at page 23, line 9 skipping to change at page 23, line 9
* 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] [I-D.ietf-opes-end-comm]
Barbir, A., "OPES processor and end points Barbir, A., "OPES processor and end points
communications", draft-ietf-opes-end-comm-00 (work in communications", draft-ietf-opes-end-comm-02 (work in
progress), June 2003. progress), September 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/