idnits 2.17.1 draft-ietf-opes-iab-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '... "OPES processors MUST be consented to...' RFC 2119 keyword, line 147: '...requires that "OPES processors MUST be...' RFC 2119 keyword, line 353: '...s. An OPES system MUST leave its trace...' RFC 2119 keyword, line 362: '... traces MUST include identification ...' RFC 2119 keyword, line 409: '... An OPES system MUST leave its trace [I-D.ietf-opes-end-comm]....' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2003) is 7480 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-opes-end-comm-04 ** Downref: Normative reference to an Informational draft: draft-ietf-opes-end-comm (ref. 'I-D.ietf-opes-end-comm') ** Downref: Normative reference to an Informational draft: draft-ietf-opes-architecture (ref. 'I-D.ietf-opes-architecture') ** Downref: Normative reference to an Informational draft: draft-ietf-opes-scenarios (ref. 'I-D.ietf-opes-scenarios') ** Downref: Normative reference to an Informational RFC: RFC 3238 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-03) exists of draft-ietf-opes-http-00 == Outdated reference: A later version (-05) exists of draft-ietf-opes-ocp-core-01 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: April 26, 2004 A. Rousskov 5 The Measurement Factory 6 October 27, 2003 8 OPES Treatment of IAB Considerations 9 draft-ietf-opes-iab-03 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 26, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 IETF Internet Architecture Board (IAB) expressed nine 40 architecture-level considerations for the Open Pluggable Edge 41 Services (OPES) framework. This document describes how OPES 42 addresses those considerations. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5 49 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6 50 5. Notification Considerations . . . . . . . . . . . . . . . . . 8 51 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 52 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 53 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 10 54 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12 55 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 56 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 57 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 58 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 59 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 60 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 61 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 62 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 63 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 64 Normative References . . . . . . . . . . . . . . . . . . . . . 23 65 Informative References . . . . . . . . . . . . . . . . . . . . 24 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 67 Intellectual Property and Copyright Statements . . . . . . . . 25 69 1. Introduction 71 The Open Pluggable Edge Services (OPES) architecture 72 [I-D.ietf-opes-architecture], enables cooperative application 73 services (OPES services) between a data provider, a data consumer, 74 and zero or more OPES processors. The application services under 75 consideration analyze and possibly transform application-level 76 messages exchanged between the data provider and the data consumer. 78 In the process of chartering OPES, the IAB made recommendations on 79 issues that OPES solutions should be required to address. These 80 recommendations were formulated in the form of a specific IAB 81 considerations document [RFC3238]. In that document, IAB emphasized 82 that its considerations did not recommend specific solutions and did 83 not mandate specific functional requirements. Addressing an IAB 84 consideration may involve showing appropriate protocol mechanisms or 85 demonstrating that the issue does not apply. Addressing a 86 consideration does not necessarily mean supporting technology implied 87 by the consideration wording. 89 The primary goal of this document is to show that all IAB 90 recommendations are addressed by OPES, to the extent that those 91 considerations can be addressed by an IETF working group. The 92 limitations of OPES working group to address certain aspects of IAB 93 considerations are also explicitly documented. 95 There are nine IAB considerations [RFC3238] that OPES has to address. 96 In the core of this document are the corresponding nine 97 "Consideration" sections. For each IAB consideration, its section 98 contains general discussion as well as references to specific OPES 99 mechanisms relevant to the consideration. 101 2. Terminology 103 This document does not introduce any new terminology but uses 104 terminology from other OPES documents it quotes. 106 3. Consideration (2.1) 'One-party consent' 108 "An OPES framework standardized in the IETF must require that the use 109 of any OPES service be explicitly authorized by one of the 110 application-layer end-hosts (that is, either the content provider or 111 the client)."[RFC3238] 113 OPES architecture requires that "OPES processors MUST be consented to 114 by either the data consumer or data provider application" 115 [I-D.ietf-opes-architecture]. This requirement alone cannot prevent 116 consent-less introduction of OPES processors. In 117 [I-D.ietf-opes-end-comm], the OPES architecture enables concerned 118 parties to detect unwanted OPES processors by examining OPES traces. 119 The use of traces in OPES is mandatory. 121 A tracing mechanism on its own cannot detect processors that are in 122 violation of OPES specifications. Examples include OPES processors 123 operating in stealth mode. However, the OPES architecture allows the 124 use of content signature to verify the authenticity of performed 125 adaptations. Content signatures is a strong but expensive mechanism 126 that can detect any modifications of signed content provided that the 127 content provider is willing to sign the data and that the client is 128 willing to either check the signature or relay received content to 129 the content provider for signature verification. 131 OPES adaptations may include copying and other forms of non-modifying 132 access to content. These kinds of adaptations cannot be detected by 133 the above mentioned mechanisms. Thus, "passive" OPES processors can 134 operate on the content without the data consumer or provider consent. 135 If presence of such processors is a concern, then content encryption 136 can be used. A passive processor is no different from a proxy or an 137 intermediary operating outside of OPES framework. No OPES mechanism 138 (existing or foreseeable) can prevent non-modifying access to 139 content. 141 4. Consideration (2.2) 'IP-layer communications' 143 "For an OPES framework standardized in the IETF, the OPES 144 intermediary must be explicitly addressed at the IP layer by the end 145 user."[RFC3238] 147 The OPES architecture requires that "OPES processors MUST be 148 addressable at the IP layer by the end user (data consumer 149 application)" [I-D.ietf-opes-architecture]. The IAB and the 150 architecture documents mention an important exception: addressing the 151 first OPES processor in a chain of processors is sufficient. That is, 152 a chain of OPES processors is viewed as a single OPES "system" at the 153 address of the first chain element. 155 The notion of a chain is not strictly defined by IAB. For the purpose 156 of addressing this consideration, a group of OPES processors working 157 on a given application transaction is considered. Such a group would 158 necessarily form a single processing chain, with a single "exit" OPES 159 processor (i.e., the processor that adapted the given message last). 160 The OPES architecture essentially requires that last OPES processor 161 to be explicitly addressable at the IP layer by the data consumer 162 application. The chain formation, including its exit point may depend 163 on an application message and other dynamic factors such as time of 164 the day or system load. 166 Furthermore, if OPES processing is an internal processing step at a 167 data consumer or a data provider application side, then the last OPES 168 processor may reside in a private address space and may not be 169 explicitly addressable from the outside. In such situations, the 170 processing side must designate an addressable point on the same 171 processing chain. That designated point may not be, strictly 172 speaking, an OPES processor, but it will suffice as such as far as 173 IAB considerations are concerned -- the data consumer application 174 will be able to address it explicitly at the IP layer and it will 175 represent the OPES processing chain to the outside world. 177 Designating an addressable processing point avoids the conflict 178 between narrow interpretation of the IAB consideration and real 179 system designs. It is irrational to expect a content provider to 180 provide access to internal hosts participating in content generation, 181 whether OPES processors are involved or not. Moreover, providing such 182 access would serve little practical purpose because internal OPES 183 processors are not likely to be able to answer any data consumer 184 queries, being completely out of content generation context. For 185 example, an OPES processor adding customer-specific information to 186 XML pages may not understand or be aware of any final HTML content 187 that the data consumer application receives and may not be able to 188 map end user request to any internal user identification. Since OPES 189 requires the end of the message processing chain to be addressable, 190 the conflict does not exist. OPES places no requirements on the 191 internal architecture of data producer systems while requiring the 192 entire OPES-related content production "system" to be addressable at 193 the IP layer. 195 Private Domain | Public Domain | Private Domain 196 | | 197 +--------------+ | +-------------+ +--------+ 198 | Data | | | OPES System | |Data | 199 | Consumer |<--- network -->| with public |<---->|Provider| 200 | Application | | | IP address | |App | 201 +--------------+ | +-------------+ +--------+ 202 | | 203 | | 205 Figure 1 207 5. Notification Considerations 209 This section discusses how OPES framework addresses IAB Notification 210 considerations 3.1 and 3.2. 212 5.1 Notification versus trace 214 Before specific considerations are discussed, the relationship 215 between IAB notifications and OPES tracing has to be explained. OPES 216 framework concentrates on tracing rather than notification. The OPES 217 Communications specification [I-D.ietf-opes-end-comm] defines "OPES 218 trace" as information about OPES adaptations that is embedded in an 219 application message. Thus, OPES trace follows the application message 220 it traces. The trace is for the recipient of the application message. 221 Traces are implemented as extensions of application protocols being 222 adapted and traced. 224 As opposed to an OPES trace, provider notification (as implied by 225 IAB) notifies the sender of the application message rather than the 226 recipient. Thus, notifications propagate in the opposite direction of 227 traces. Supporting notifications directly would require a new 228 protocol. Figure 2 illustrates the differences between a trace and 229 notification from a single application message point of view. 230 sender --[message A]--> OPES --[message A']--> recipient 231 ^ V [with trace] 232 | | 233 +-<-- [notification] ---+ 235 Figure 2 237 Since notifications cannot be piggy-backed to application messages, 238 they create new messages and may double the number of messages the 239 sender has to process. The number of messages that need to be proceed 240 is larger if several intermediaries on the message path generate 241 notifications). Associating notifications with application messages 242 may require duplicating application message information in 243 notifications and may require maintaining a sender state until 244 notification is received. These actions increase the performance 245 overhead of notifications. 247 The level of available details in notifications versus provider 248 interest in supporting notification is another concern. Experience 249 shows that content providers often require very detailed information 250 about user actions to be interested in notifications at all. For 251 example, Hit Metering protocol [RFC2227] has been designed to supply 252 content providers with proxy cache hit counts, in an effort to reduce 253 cache busting behavior which was caused by content providers desire 254 to get accurate site "access counts". However, the Hit Metering 255 protocol is currently not widely deployed because the protocol does 256 not supply content providers with information such as client IP 257 addresses, browser versions, or cookies. 259 Hit Metering experience is relevant because Hit Metering protocol was 260 designed to do for HTTP caching intermediaries what OPES 261 notifications are meant to do for OPES intermediaries. Performance 262 requirements call for state reduction via aggregation of 263 notifications while provider preferences call for state preservation 264 or duplication. Achieving the right balance when two sides belong to 265 different organizations and have different optimization priorities 266 may be impossible. 268 Thus, instead of explicitly supporting notifications at the protocol 269 level, OPES concentrates on tracing facilities. In essence, OPES 270 supports notifications indirectly, using tracing facilities. In other 271 words, the IAB choice of "Notification" label is interpreted as 272 "Notification assistance" (i.e. making notifications meaningful) and 273 is not interpreted as a "Notification protocol". 275 The above concerns call for making notification optional. The OPES 276 architecture allows for an efficient and meaningful notification 277 protocol to be implemented in certain OPES environments. For 278 specific examples, see the "Optional Notification" section in 279 [I-D.ietf-opes-end-comm]. 281 5.2 An example of an OPES trace for HTTP 283 The example below illustrates adaptations done to HTTP request at an 284 OPES processor operated by the client ISP. Both original (as sent by 285 an end user) and adapted (as received by the origin web server) 286 requests are shown. The primary adaptation is the modification of 287 HTTP "Accept" header. The secondary adaptation is the addition of an 288 "OPES-Via" HTTP extension header [I-D.ietf-opes-http] (XXX: but it is 289 not OPES-Via, it is OPES-System for now; OPES-Via is probably better 290 for a few reasons though). 292 GET /pub/WWW/ HTTP/1.1 293 Host: www.w3.org 294 Accept: text/plain 296 Figure 3 298 ... may be adapted by an ISP OPES system to become: 300 GET /pub/WWW/ HTTP/1.1 301 Host: www.w3.org 302 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 303 OPES-Via: http://www.isp-example.com/opes/?client-hash=1234567 305 Figure 4 307 The example below illustrates adaptations done to HTTP response at an 308 OPES intermediary operated by a Content Distribution Network (CDN). 309 Both original (as sent by the origin web server) and adapted (as 310 received by the end user) responses are shown. The primary adaptation 311 is the conversion from HTML markup to plain text. The secondary 312 adaptation is the addition of an "OPES-Via" HTTP extension header. 314 HTTP/1.1 200 OK 315 Content-Length: 12345 316 Content-Encoding: text/html 318