draft-ietf-opes-iab-03.txt   draft-ietf-opes-iab-04.txt 
Open Pluggable Edge Services A. Barbir Open Pluggable Edge Services A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: April 26, 2004 A. Rousskov Expires: June 1, 2004 A. Rousskov
The Measurement Factory The Measurement Factory
October 27, 2003 December 2, 2003
OPES Treatment of IAB Considerations OPES Treatment of IAB Considerations
draft-ietf-opes-iab-03 draft-ietf-opes-iab-04
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 April 26, 2004. This Internet-Draft will expire on June 1, 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 for the Open Pluggable Edge architecture-level considerations for the Open Pluggable Edge
Services (OPES) framework. This document describes how OPES Services (OPES) framework. This document describes how OPES
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 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' . . . . . . . . . . . . . . 11
5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12
6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13
7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14
8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15
9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16
10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17
11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 9, line 27 skipping to change at page 9, line 27
Thus, instead of explicitly supporting notifications at the protocol Thus, instead of explicitly supporting notifications at the protocol
level, OPES concentrates on tracing facilities. In essence, OPES level, OPES concentrates on tracing facilities. In essence, OPES
supports notifications indirectly, using tracing facilities. In other supports notifications indirectly, using 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".
The above concerns call for making notification optional. The OPES The above concerns call for making notification optional. The OPES
architecture allows for an efficient and meaningful notification architecture allows for an efficient and meaningful notification
protocol to be implemented in certain OPES environments. For protocol to be implemented in certain OPES environments. For
specific examples, see the "Optional Notification" section in example, a Cable Company Internet Service Provider (Cable ISP) may
[I-D.ietf-opes-end-comm]. provide a user-configurable porn filtering service to its subscribers
while having an agreement with the parent Cable Company to send
notifications to the content provider when clients (content
consumers) use the same filter to block Company's advertisement
images. If the Cable Company deems such subscriber actions
inappropriate, the company may contact individual subscribers and
enforce their ISP usage policy according to the terms of the service
agreement. In this example, ISP cooperation is expected, the volume
of notifications would be relatively low, and notifications can be
handled in an automated manner.
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 processor operated by the client ISP. Both original (as sent by OPES processor operated by the client ISP. Both original (as sent by
an end user) and adapted (as received by the origin web server) 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 [I-D.ietf-opes-http] (XXX: but it is OPES-System HTTP extension header [I-D.ietf-opes-http].
not OPES-Via, it is OPES-System for now; OPES-Via is probably better
for a few reasons though).
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.w3.org Host: www.w3.org
Accept: text/plain Accept: text/plain
Figure 3 Figure 3
... may be adapted by an ISP OPES system to become: ... may be adapted by an ISP OPES system to become:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.w3.org Host: www.w3.org
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 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 OPES-System: http://www.isp-example.com/opes/?client-hash=1234567
Figure 4 Figure 4
The example below illustrates adaptations done to HTTP response at an The example below illustrates adaptations done to HTTP response at an
OPES intermediary operated by a Content Distribution Network (CDN). OPES intermediary operated by a Content Distribution Network (CDN).
Both original (as sent by the origin web server) and adapted (as Both original (as sent by the origin web server) and adapted (as
received by the end user) responses are shown. The primary adaptation received by the end user) responses are shown. The primary adaptation
is the conversion from HTML markup to plain text. The secondary is the conversion from HTML markup to plain text. The secondary
adaptation is the addition of an "OPES-Via" HTTP extension header. adaptation is the addition of an OPES-System HTTP extension header.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 12345 Content-Length: 12345
Content-Encoding: text/html Content-Encoding: text/html
<html><head><h1>Available Documenta... <html><head><h1>Available Documenta...
Figure 5 Figure 5
... may be adapted by a CDN OPES system to become: ... may be adapted by a CDN OPES system to become:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 2345 Content-Length: 2345
Content-Encoding: text/plain Content-Encoding: text/plain
OPES-Via: http://www.cdn-example.com/opes/?site=7654321&service=h2t OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t
AVAILABLE DOCUMENTA... AVAILABLE DOCUMENTA...
Figure 6 Figure 6
In the above examples, "OPES-Via" header values contain URLs that may In the above examples, OPES-System header values contain URIs that
point to OPES-specific documents such as description of the OPES may point to OPES-specific documents such as description of the OPES
operator and its privacy policy. Those documents may be operator and its privacy policy. Those documents may be
parameterized to allow for customizations specific to the transaction parameterized to allow for customizations specific to the transaction
being traced (e.g., client or even transaction identifier may be used being traced (e.g., client or even transaction identifier may be used
to provide more information about performed adaptations). Traced OPES to provide more information about performed adaptations). An OPES-Via
URLs may be later used to request OPES bypass header may be used to provide a more detailed trace of specific OPES
entities within an OPES System that adapted the message. Traced OPES
URIs may be later used to request OPES bypass
[I-D.ietf-opes-end-comm]. [I-D.ietf-opes-end-comm].
5.3 Consideration (3.1) 'Notification' 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
skipping to change at page 15, 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]
The OPES framework does not propose adaptation services. However, The OPES framework 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 [I-D.ietf-opes-end-comm] (XXX: check tracing draft for this validity [I-D.ietf-opes-end-comm].
requirement).
9. 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 document in OPES framework does not contain ad hoc fixes. This document in
combination with and other OPES documents should be sufficient to combination with and other OPES documents should be sufficient to
skipping to change at page 21, line 7 skipping to change at page 21, line 7
13. Compliance 13. 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.
Appendix A. Change Log Appendix A. Change Log
Internal WG revision control ID: $Id: iab-cons.xml,v 1.26 2003/10/27 RFC Editor Note: This section is to be removed during the final
11:40:33 rousskov Exp $ publication of the document.
Internal WG revision control ID: $Id: iab-cons.xml,v 1.32 2003/12/03
06:46:04 rousskov Exp $
2003/11/18
* Added an example where an efficient and meaningful notification
protocol can be implemented in OPES.
* Assume Communications draft will contain wording about
documenting impact on reference validity.
* Use OPES-System HTTP header for examples and mention OPES-Via.
We still need to get HTTP Adaptations draft in sync with this
change, but the text now assumes that has been done.
2003/10/24 2003/10/24
* Addressed hop-by-hop encryption concerns mentioned in the IAB * Addressed hop-by-hop encryption concerns mentioned in the IAB
draft. draft.
* Polished IP addressing figure. * Polished IP addressing figure.
* Removed resolved XXXs. * Removed resolved XXXs.
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-04 (work in communications", draft-ietf-opes-end-comm-05 (work in
progress), October 2003. progress), October 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
skipping to change at page 24, line 19 skipping to change at page 24, line 19
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/
1.1", RFC 2817, May 2000. 1.1", RFC 2817, May 2000.
[I-D.ietf-opes-http] [I-D.ietf-opes-http]
Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", Rousskov, A. and M. Stecher, "HTTP adaptation with OPES",
draft-ietf-opes-http-00 (work in progress), August 2003. draft-ietf-opes-http-01 (work in progress), October 2003.
[I-D.ietf-opes-ocp-core] [I-D.ietf-opes-ocp-core]
Rousskov, A., "OPES Callout Protocol Core", Rousskov, A., "OPES Callout Protocol Core",
draft-ietf-opes-ocp-core-01 (work in progress), August draft-ietf-opes-ocp-core-03 (work in progress), November
2003. 2003.
Authors' Addresses Authors' Addresses
Abbie Barbir Abbie Barbir
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Nepean, Ontario Nepean, Ontario
CA CA
 End of changes. 

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