idnits 2.17.1 draft-ietf-opes-iab-02.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 114: '... "OPES processors MUST be consented to...' RFC 2119 keyword, line 146: '...t "OPES processors MUST be addressable...' RFC 2119 keyword, line 359: '.... An OPES system MUST leave its trace ...' RFC 2119 keyword, line 368: '... traces MUST include identification ...' RFC 2119 keyword, line 418: '...PES intermediary MUST leave its trace ...' (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 (September 23, 2003) is 7514 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) == Missing Reference: 'XXX' is mentioned on line 260, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-opes-end-comm-02 ** 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) Summary: 7 errors (**), 0 flaws (~~), 5 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: March 23, 2004 A. Rousskov 5 The Measurement Factory 6 September 23, 2003 8 OPES Treatment of IAB Considerations 9 draft-ietf-opes-iab-02 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 March 23, 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 when Open Pluggable Edge Services 41 (OPES) working group was being chartered at the IETF. The working 42 group was chartered under the condition that IAB considerations were 43 addressed by the group. This document describes how OPES addresses 44 those considerations. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Consideration (2.1) One-party consent . . . . . . . . . . . . 5 51 4. Consideration (2.2) IP-layer communications . . . . . . . . . 6 52 5. Notification Considerations . . . . . . . . . . . . . . . . . 8 53 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 54 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 55 5.3 Consideration (3.1) Notification . . . . . . . . . . . . . . . 10 56 5.4 Consideration (3.2) Notification . . . . . . . . . . . . . . . 12 57 6. Consideration (3.3) Non-blocking . . . . . . . . . . . . . . . 13 58 7. Consideration (4.1) URI resolution . . . . . . . . . . . . . . 14 59 8. Consideration (4.2) Reference validity . . . . . . . . . . . . 15 60 9. Consideration (4.3) Addressing extensions . . . . . . . . . . 16 61 10. Consideration (5.1) Privacy . . . . . . . . . . . . . . . . . 17 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 63 12. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 19 64 13. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 65 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 66 Normative References . . . . . . . . . . . . . . . . . . . . . 23 67 Informative References . . . . . . . . . . . . . . . . . . . . 24 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 69 Intellectual Property and Copyright Statements . . . . . . . . 25 71 1. Introduction 73 The Open Pluggable Edge Services (OPES) architecture 74 [I-D.ietf-opes-architecture], enables cooperative application 75 services (OPES services) between a data provider, a data consumer, 76 and zero or more OPES processors. The application services under 77 consideration analyze and possibly transform application-level 78 messages exchanged between the data provider and the data consumer. 80 In the process of chartering OPES, the IAB made recommendations on 81 issues that OPES solutions should be required to address. These 82 recommendations were formulated in the form of specific IAB 83 considerations [RFC3238]. IAB emphasized that its considerations did 84 not recommend specific solutions and did not mandate specific 85 functional requirements. Addressing an IAB consideration may involve 86 showing appropriate protocol mechanisms or demonstrating that the 87 issue does not apply. Addressing a consideration does not necessarily 88 mean supporting technology implied by the consideration wording. 90 The primary goal of this document is to show that all IAB 91 considerations are addressed by OPES, to the extent those 92 considerations can be addressed by an IETF working group. Limitations 93 of OPES working group ability to address certain aspects of IAB 94 considerations are explicitly documented. 96 There are nine IAB considerations [RFC3238] that OPES has to address. 97 In the core of this document are the corresponding nine 98 "Consideration" sections. For each IAB consideration, its section 99 contains general discussion as well as references to specific OPES 100 mechanisms relevant to the consideration. 102 2. Terminology 104 This document does not introduce any new terminology but uses 105 terminology from other OPES documents it quotes. 107 3. Consideration (2.1) One-party consent 109 "An OPES framework standardized in the IETF must require that the use 110 of any OPES service be explicitly authorized by one of the 111 application-layer end-hosts (that is, either the content provider or 112 the client)."[RFC3238] 114 OPES architecture requires that "OPES processors MUST be consented to 115 by either the data consumer or data provider application" 116 [I-D.ietf-opes-architecture]. This requirement alone cannot prevent 117 consent-less introduction of OPES processors. In 118 [I-D.ietf-opes-end-comm], the OPES architecture enables concerned 119 parties to detect unwanted OPES processors by examining OPES traces. 120 The use of traces in OPES is mandatory. 122 Tracing mechanism on its own is unable to detect processors that are 123 in violation of OPES specifications. Examples include OPES processors 124 operating in stealth mode. However, the OPES architecture allows the 125 use of content signature to verify the authenticity of performed 126 adaptations. Content signatures is a strong but expensive mechanism 127 that can detect any modifications of signed content provided the 128 content provider is willing to sign the data and the client is 129 willing to either check the signature or relay received content to 130 content provider for signature verification. 132 OPES adaptations may include copying and other forms of non-modifying 133 access to content. These kinds of adaptations cannot be detected by 134 the above mentioned mechanisms. Thus, "passive" OPES processors can 135 operate without consent. If presence of such processors is a concern, 136 content encryption can be used. A passive processor is no different 137 from a proxy or intermediary operating outside of OPES framework. No 138 OPES mechanism can prevent non-modifying access to content. 140 4. Consideration (2.2) IP-layer communications 142 "For an OPES framework standardized in the IETF, the OPES 143 intermediary must be explicitly addressed at the IP layer by the end 144 user."[RFC3238] 146 OPES architecture requires that "OPES processors MUST be addressable 147 at the IP layer by the end user (data consumer application)" 148 [I-D.ietf-opes-architecture]. IAB and the architecture draft mention 149 an important exception: addressing the first OPES processor in a 150 chain of processors is sufficient. That is, a chain of OPES 151 processors is viewed as a single OPES "system" at the address of the 152 first chain element. 154 The notion of a chain is not strictly defined by IAB. For the purpose 155 of addressing this consideration, we consider a group of OPES 156 processors working on a given application transaction. Such a group 157 would necessarily form a single processing chain, with a single 158 "exit" OPES processor (the processor that adapted the given message 159 last). OPES architecture essentially requires that last OPES 160 processor to be explicitly addressable at the IP layer by the end 161 user. Note that chain formation, including its exit point may depend 162 on an application message and other dynamic factors such as time of 163 day or system load. 165 Furthermore, if OPES processing is an internal processing step at 166 data consumer or provider side, then the last OPES processor may 167 reside in a private address space of the side's network and may not 168 be explicitly addressable. In such situations, the processing side 169 must designate an addressable point on the same processing chain. 170 That designated point may not be, strictly speaking, an OPES 171 processor, but it will suffice as such as far as IAB considerations 172 are concerned -- the other side will be able to address it explicitly 173 at the IP layer and it will represent the OPES processing chain to 174 the outside world. 176 Designating an addressable processing point avoids the conflict 177 between narrow interpretation of IAB consideration and real system 178 designs: It is irrational to expect a content provider to provide 179 access to internal hosts participating in content generation, whether 180 OPES processors are involved or not. Moreover, providing such access 181 would serve little practical purpose because internal OPES processors 182 are not likely to be able to answer any end user queries, being 183 completely out of content generation context. For example, an OPES 184 processor adding customer-specific information to XML pages may not 185 understand or be aware of any final HTML content that the end user 186 receives and may not be able to map end user request to any internal 187 user identification. Since OPES requires the end of the message 188 processing chain to be addressable, the conflict does not exist -- 189 OPES places no requirements on the internal architecture of data 190 producer systems while requiring the entire OPES-related content 191 production "system" to be addressable at the IP layer. 193 Public/Private Domain | Private Domain 194 | 195 +--------------+ | +------+ 196 | Data | *-------* +----------+ | | OPES | 197 | Consumer |<-->/ Network \<-->| Public IP| | +------+ 198 | Application | \(Public) / | Address |<-->| . 199 +--------------+ *-------* | OPES | | . 200 +----------+ | . 201 | +------+ 202 | | OPES | 203 | +------+ 204 | 206 Figure 1 208 (XXX: should we add a picture showing internal and external OPES 209 intermediaries? more pictures showing other OPES layouts? Move to 210 architecture draft?) 212 5. Notification Considerations 214 This section discusses how OPES framework addresses IAB Notification 215 considerations 3.1 and 3.2. 217 5.1 Notification versus trace 219 Before specific considerations are discussed, the relationship 220 between IAB notifications and OPES tracing has to be explained. OPES 221 framework concentrates on tracing rather than notification. The 222 tracing specification [I-D.ietf-opes-end-comm] defines "OPES trace" 223 as "application message information about OPES entities that adapted 224 that message" and "OPES tracing" as "the process of including, 225 manipulating, and interpreting an OPES trace" (XXX: keep these in 226 sync). Thus, OPES trace follows the application message it traces. 227 The trace is for the recipient of the application message. Traces are 228 implemented as extensions of application protocols being adapted and 229 traced. 231 As opposed to an OPES trace, provider notification (as implied by 232 IAB) notifies the sender of the application message rather than the 233 recipient. Thus, notifications propagate in the opposite direction of 234 traces. Supporting notifications directly would require a new 235 protocol. Figure XXX illustrates the differences between a trace and 236 notification from a single application message point of view. 238 sender --[message A]---> OPES --[message A' + trace]--> recipient 239 ^ V 240 | | 241 +-<-- [notification] ---+ 243 Figure 2 245 Since notifications cannot be piggy-backed to application messages, 246 they create new messages and may at least double the number of 247 messages the sender has to process (more if several intermediaries on 248 the message path emit notifications). Moreover, associating 249 notifications with application messages may require duplicating 250 application message information in notifications and/or maintaining a 251 sender state until notification is received, increasing performance 252 overhead of notifications. These concerns call for optional 253 notification, with a special protocol to enable notifications when 254 needed. 256 The level of available details in notifications versus provider 257 interest in supporting notification is another concern. Experience 258 shows that content providers often require very detailed information 259 about user actions to be interested in notifications at all. For 260 example, Hit Metering protocol [XXX] has been designed to supply 261 content providers with proxy cache hit counts, in an effort to reduce 262 cache busting behavior which was caused by content providers desire 263 to get accurate site "access counts". However, the Hit Metering 264 protocol is currently not widely deployed because the protocol does 265 not supply content providers with information such as client IP 266 addresses, browser versions, or cookies. 268 Hit Metering experience is relevant because Hit Metering protocol was 269 designed to do for HTTP caching intermediaries what OPES 270 notifications are meant to do for OPES intermediaries. Performance 271 requirements call for state reduction via aggregation of 272 notifications while provider preferences call for state preservation 273 or duplication. Achieving the right balance when two sides belong to 274 different organizations and have different optimization priorities 275 may be impossible. 277 Thus, instead of explicitly supporting notifications on a protocol 278 level, OPES concentrates on tracing facilities and supports 279 notifications indirectly, using those tracing facilities. In other 280 words, the IAB choice of "Notification" label is interpreted as 281 "Notification assistance" (i.e. making notifications meaningful) and 282 is not interpreted as a "Notification protocol". 284 Nevertheless, OPES architecture allows for an efficient and 285 meaningful notification protocol to be implemented in certain OPES 286 environments. For specific examples, see the "Optional Notification" 287 section in [I-D.ietf-opes-end-comm]. 289 5.2 An example of an OPES trace for HTTP 291 The example below illustrates adaptations done to HTTP request at an 292 OPES intermediary operated by the client ISP. Both original (as sent 293 by an end user) and adapted (as received by the origin web server) 294 requests are shown. The primary adaptation is the modification of 295 HTTP "Accept" header. The secondary adaptation is the addition of an 296 "OPES-Via" HTTP extension header. 298 GET /pub/WWW/ HTTP/1.1 299 Host: www.w3.org 300 Accept: text/plain 302 Figure 3 304 ... may be adapted by an ISP OPES system to become: 306 GET /pub/WWW/ HTTP/1.1 307 Host: www.w3.org 308 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 309 OPES-Via: http://www.isp-example.com/opes/?client-hash=1234567 311 Figure 4 313 The example below illustrates adaptations done to HTTP response at an 314 OPES intermediary operated by a Content Distribution Network (CDN). 315 Both original (as sent by the origin web server) and adapted (as 316 received by the end user) responses are shown. The primary adaptation 317 is the conversion from HTML markup to plain text. The secondary 318 adaptation is the addition of an "OPES-Via" HTTP extension header. 320 HTTP/1.1 200 OK 321 Content-Length: 12345 322 Content-Encoding: text/html 324