--- 1/draft-ietf-opes-iab-01.txt 2006-02-05 00:56:02.000000000 +0100 +++ 2/draft-ietf-opes-iab-02.txt 2006-02-05 00:56:02.000000000 +0100 @@ -1,19 +1,19 @@ Open Pluggable Edge Services A. Barbir Internet-Draft Nortel Networks -Expires: February 25, 2004 A. Rousskov +Expires: March 23, 2004 A. Rousskov The Measurement Factory - August 27, 2003 + September 23, 2003 OPES Treatment of IAB Considerations - draft-ietf-opes-iab-01 + draft-ietf-opes-iab-02 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 February 25, 2004. + This Internet-Draft will expire on March 23, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations when Open Pluggable Edge Services (OPES) working group was being chartered at the IETF. The working @@ -47,28 +47,28 @@ 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.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12 - 5.5 Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 12 - 6. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14 - 7. Consideration (4.2) Reference validity . . . . . . . . . . . . 15 - 8. Consideration (4.3) Addressing extensions . . . . . . . . . . 16 - 9. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 11. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 12. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 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. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 12. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 13. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Normative References . . . . . . . . . . . . . . . . . . . . . 23 Informative References . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 25 1. Introduction The Open Pluggable Edge Services (OPES) architecture [I-D.ietf-opes-architecture], enables cooperative application @@ -274,20 +274,25 @@ different organizations and have different optimization priorities may be impossible. Thus, instead of explicitly supporting notifications on a protocol level, OPES concentrates on tracing facilities and supports notifications indirectly, using those 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". + 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 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 @@ -416,21 +422,21 @@ protocols may not have explicit responses (e.g., event logging service). OPES detection assistance is limited to application protocols with support for tracing extensions. For example, HTTP [RFC2616] has such support while DNS over UDP does not. (XXX: should we prohibit adaptation of application protocols that do 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 content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider."[RFC3238] OPES intermediaries MUST support a bypass feature (XXX quote bypass draft) [I-D.ietf-opes-end-comm]. If an application message includes bypass instructions and an OPES intermediary is not configured to ignore them, the matching OPES intermediary will not process the @@ -442,62 +448,62 @@ Bypass support has limitations similar to the two 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 +7. Consideration (4.1) URI resolution "OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself."[RFC3238] "OPES Scenarios and Use Cases" specification [I-D.ietf-opes-scenarios] documents content adaptations that are in scope of the OPES framework (XXX provide a quote). These adaptations do not include URI resolution (XXX check). In some environments, it is technically possible to adapt URIs (and other kinds of identifiers 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 intra-document reference validity."[RFC3238] OPES working group 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 (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 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 and other OPES documents should be sufficient to inform service creators of IAB considerations. If a service does URI resolution or silently affects document reference validity, the authors are requested to review service impact on Internet application addressing architecture and work within IETF on potential extension requirements. Such actions 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 to determine the privacy policies of OPES intermediaries."[RFC3238] OPES tracing mechanisms allow end users to identify OPES intermediaries (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 their privacy policies. @@ -505,49 +511,56 @@ context (by IAB or OPES working group). OPES tracing mechanisms allow end users and content providers to identify OPES intermediaries. It is believed that once an intermediary is identified, it would be possible to locate relevant information about that intermediary, including information relevant to requesters perception of privacy policy or reference validity. (XXX: should we move this paragraph 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 that we can refer to them from here.) -10. Security Considerations +11. Security Considerations XXX. -11. Compliance +12. 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. -12. To-do +13. To-do security section: Does this document have any original security matters worth documenting? normative IDs: To be normative, OPES Internet-Drafts must be replaced with corresponding RFCs when the latter are published. architecture draft: Should architecture draft talk about external/ internal OPES intermediaries, OPES systems, and privacy policies? Should this document be limited to a compilation of references from other OPES drafts, or should we introduce/discuss new concepts here? Appendix A. Change Log - Internal WG revision control ID: $Id: iab-cons.xml,v 1.19 2003/08/28 - 03:48:32 rousskov Exp $ + Internal WG revision control ID: $Id: iab-cons.xml,v 1.20 2003/09/24 + 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 * 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, @@ -588,22 +601,22 @@ * 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-00 (work in - progress), June 2003. + communications", draft-ietf-opes-end-comm-02 (work in + progress), September 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 2002.