--- 1/draft-ietf-opes-iab-03.txt 2006-02-05 00:56:04.000000000 +0100 +++ 2/draft-ietf-opes-iab-04.txt 2006-02-05 00:56:04.000000000 +0100 @@ -1,19 +1,19 @@ Open Pluggable Edge Services A. Barbir Internet-Draft Nortel Networks -Expires: April 26, 2004 A. Rousskov +Expires: June 1, 2004 A. Rousskov The Measurement Factory - October 27, 2003 + December 2, 2003 OPES Treatment of IAB Considerations - draft-ietf-opes-iab-03 + draft-ietf-opes-iab-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -21,21 +21,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The Internet Society (2003). All Rights Reserved. Abstract IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES @@ -43,21 +43,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6 5. Notification Considerations . . . . . . . . . . . . . . . . . 8 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 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 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 @@ -268,82 +268,90 @@ Thus, instead of explicitly supporting notifications at the protocol level, OPES concentrates on tracing facilities. In essence, OPES supports notifications indirectly, using tracing facilities. In other words, the IAB choice of "Notification" label is interpreted as "Notification assistance" (i.e. making notifications meaningful) and is not interpreted as a "Notification protocol". The above concerns call for making notification optional. The 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]. + example, a Cable Company Internet Service Provider (Cable ISP) may + 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 The example below illustrates adaptations done to HTTP request at an OPES processor 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 [I-D.ietf-opes-http] (XXX: but it is - not OPES-Via, it is OPES-System for now; OPES-Via is probably better - for a few reasons though). + OPES-System HTTP extension header [I-D.ietf-opes-http]. 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 + OPES-System: 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. + adaptation is the addition of an OPES-System HTTP extension header. HTTP/1.1 200 OK Content-Length: 12345 Content-Encoding: text/html

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 + OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=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 + In the above examples, OPES-System header values contain URIs 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 + to provide more information about performed adaptations). An OPES-Via + 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]. 5.3 Consideration (3.1) 'Notification' "The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider."[RFC3238] OPES tracing mechanisms assist content providers in detecting @@ -454,22 +462,21 @@ "All proposed services must define their impact on inter- and intra-document reference validity."[RFC3238] The OPES framework does not propose adaptation services. However, OPES tracing requirements include identification of OPES intermediaries and services (for details, see "Notification" consideration sections in this document). It is required that provided identification can be used to locate information about the OPES intermediaries, including the description of impact on reference - validity [I-D.ietf-opes-end-comm] (XXX: check tracing draft for this - requirement). + validity [I-D.ietf-opes-end-comm]. 9. Consideration (4.3) 'Addressing extensions' "Any services that cannot be achieved while respecting the above two considerations may be reviewed as potential requirements for Internet application addressing architecture extensions, but must not be undertaken as ad hoc fixes."[RFC3238] OPES framework does not contain ad hoc fixes. This document in combination with and other OPES documents should be sufficient to @@ -540,22 +547,37 @@ 13. Compliance This document may be perceived as a proof of OPES compliance with IAB implied recommendations. However, this document does not introduce any compliance subjects. Compliance of OPES implementations is defined in other OPES documents discussed above. Appendix A. Change Log - Internal WG revision control ID: $Id: iab-cons.xml,v 1.26 2003/10/27 - 11:40:33 rousskov Exp $ + RFC Editor Note: This section is to be removed during the final + 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 * Addressed hop-by-hop encryption concerns mentioned in the IAB draft. * Polished IP addressing figure. * Removed resolved XXXs. @@ -616,21 +637,21 @@ * Added Abbie Barbir as an author. head-sid7 * Initial revision Normative References [I-D.ietf-opes-end-comm] 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. [I-D.ietf-opes-architecture] Barbir, A., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opes-architecture-04 (work in progress), December 2002. [I-D.ietf-opes-scenarios] Barbir, A., "OPES Use Cases and Deployment Scenarios", draft-ietf-opes-scenarios-01 (work in progress), August @@ -647,25 +668,25 @@ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 1.1", RFC 2817, May 2000. [I-D.ietf-opes-http] 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] 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. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario CA