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

Available Documenta... 326 Figure 5 328 ... may be adapted by a CDN OPES system to become: 330 HTTP/1.1 200 OK 331 Content-Length: 2345 332 Content-Encoding: text/plain 333 OPES-Via: http://www.cdn-example.com/opes/?site=7654321&service=h2t 335 AVAILABLE DOCUMENTA... 337 Figure 6 339 In the above examples, "OPES-Via" header values contain URLs that may 340 point to OPES-specific documents such as description of the OPES 341 operator and its privacy policy. Those documents may be 342 parameterized to allow for customizations specific to the transaction 343 being traced (e.g., client or even transaction identifier may be used 344 to provide more information about performed adaptations). Traced OPES 345 URLs may be later used to request OPES bypass. (XXX: OPES specs will 346 need to define OPES-Via format and semantics) 348 5.3 Consideration (3.1) Notification 350 "The overall OPES framework needs to assist content providers in 351 detecting and responding to client-centric actions by OPES 352 intermediaries that are deemed inappropriate by the content 353 provider."[RFC3238] 355 OPES tracing mechanisms assist content providers in detecting 356 client-centric actions by OPES intermediaries. Specifically, a 357 compliant OPES intermediary or system notifies a content provider of 358 its presence by including its tracing information in the application 359 protocol requests. An OPES system MUST leave its trace (XXX quote 360 tracing draft) [I-D.ietf-opes-end-comm]. Detection assistance has 361 its limitations. Some OPES intermediaries may work exclusively on 362 responses and may not have a chance to trace the request. Moreover, 363 some application protocols may not have explicit requests (e.g., a 364 content push service). 366 OPES tracing mechanisms assist content providers in responding to 367 client-centric actions by OPES intermediaries. Specifically, OPES 368 traces MUST include identification of OPES systems and SHOULD include 369 a list of adaptation actions performed on provider's content. This 370 tracing information may be included in the application request. 371 Usually, however, this information will be included in the 372 application response, an adapted version of which does not reach the 373 content provider. If OPES end points cooperate, then notification can 374 be assisted with traces. Content providers that suspect or experience 375 difficulties can do any of the following: 377 Check whether requests they receive pass through OPES 378 intermediaries. Presence of OPES tracing info will determine that. 379 This check is only possible for request/response protocols. For 380 other protocols (e.g., broadcast or push), the provider would have 381 to assume that OPES intermediaries are involved until proven 382 otherwise. 384 If OPES intermediaries are suspected, request OPES traces from 385 potentially affected user(s). The trace will be a part of the 386 application message received by the user software. If users 387 cooperate, the provider(s) have all the information they need. If 388 users do not cooperate, the provider(s) cannot do much about it 389 (they might be able to deny service to uncooperative users in some 390 cases). 392 Some traces may indicate that more information is available by 393 accessing certain resources on the specified OPES intermediary or 394 elsewhere. Content providers may query for more information in 395 that case. 397 If everything else fails, providers can enforce no-adaptation 398 policy using appropriate OPES bypass mechanisms and/or end-to-end 399 encryption mechanisms. 401 OPES detection and response assistance is limited to application 402 protocols with support for tracing extensions. For example, HTTP 403 [RFC2616] has such support while DNS over UDP does not. 405 (XXX: should we prohibit adaptation of application protocols that do 406 not allow for tracing?) 408 5.4 Consideration (3.2) Notification 410 "The overall OPES framework should assist end users in detecting the 411 behavior of OPES intermediaries, potentially allowing them to 412 identify imperfect or compromised intermediaries."[RFC3238] 414 OPES tracing mechanisms assist end users in detecting OPES 415 intermediaries. Specifically, a compliant OPES intermediary or system 416 notifies an end user of its presence by including its tracing 417 information in the application protocol messages sent to the client. 418 An OPES intermediary MUST leave its trace (XXX quote tracing draft) 419 [I-D.ietf-opes-end-comm]. Detection assistance has its limitations. 420 Some OPES intermediaries may work exclusively on requests and may not 421 have a chance to trace the response. Moreover, some application 422 protocols may not have explicit responses (e.g., event logging 423 service). 425 OPES detection assistance is limited to application protocols with 426 support for tracing extensions. For example, HTTP [RFC2616] has such 427 support while DNS over UDP does not. 429 (XXX: should we prohibit adaptation of application protocols that do 430 not allow for tracing?) 432 6. Consideration (3.3) Non-blocking 434 "If there exists a "non-OPES" version of content available from the 435 content provider, the OPES architecture must not prevent users from 436 retrieving this "non-OPES" version from the content 437 provider."[RFC3238] 439 OPES intermediaries MUST support a bypass feature (XXX quote bypass 440 draft) [I-D.ietf-opes-end-comm]. If an application message includes 441 bypass instructions and an OPES intermediary is not configured to 442 ignore them, the matching OPES intermediary will not process the 443 message. An intermediary may be configured to ignore bypass 444 instructions only if no non-OPES version of content is available. 445 Bypass may generate content errors since some OPES services may be 446 essential but may not be configured as such. 448 Bypass support has limitations similar to the two 449 notification-related considerations above. (XXX: but it is possible 450 to instruct all OPES intermediaries to bypass an application message 451 without knowing all OPES intermediaries IDs). 453 (XXX: Ideally, this section need to be polished further -- if there 454 is no non-OPES version of the content, most IAB considerations 455 probably do not apply because there is really no adaptation, only 456 creation of content; and we should not restrict content creation.) 458 7. Consideration (4.1) URI resolution 460 "OPES documentation must be clear in describing these services as 461 being applied to the result of URI resolution, not as URI resolution 462 itself."[RFC3238] 464 "OPES Scenarios and Use Cases" specification 465 [I-D.ietf-opes-scenarios] documents content adaptations that are in 466 scope of the OPES framework (XXX provide a quote). These adaptations 467 do not include URI resolution (XXX check). In some environments, it 468 is technically possible to adapt URIs (and other kinds of identifiers 469 or addresses) using documented OPES mechanisms. 471 8. Consideration (4.2) Reference validity 473 "All proposed services must define their impact on inter- and 474 intra-document reference validity."[RFC3238] 476 OPES working group does not propose adaptation services. However, 477 OPES tracing requirements include identification of OPES 478 intermediaries and services (for details, see "Notification" 479 consideration sections in this document). It is required that 480 provided identification can be used to locate information about the 481 OPES intermediaries, including the description of impact on reference 482 validity (XXX quote tracing draft) [I-D.ietf-opes-end-comm]. 484 9. Consideration (4.3) Addressing extensions 486 "Any services that cannot be achieved while respecting the above two 487 considerations may be reviewed as potential requirements for Internet 488 application addressing architecture extensions, but must not be 489 undertaken as ad hoc fixes."[RFC3238] 491 OPES framework does not contain ad hoc fixes. This and other OPES 492 documents should be sufficient to inform service creators of IAB 493 considerations. If a service does URI resolution or silently affects 494 document reference validity, the authors are requested to review 495 service impact on Internet application addressing architecture and 496 work within IETF on potential extension requirements. Such actions 497 would be outside of the current OPES framework. 499 10. Consideration (5.1) Privacy 501 "The overall OPES framework must provide for mechanisms for end users 502 to determine the privacy policies of OPES intermediaries."[RFC3238] 504 OPES tracing mechanisms allow end users to identify OPES 505 intermediaries (for details, see "Notification" consideration 506 sections in this document). It is required that provided 507 identification can be used to locate information about the OPES 508 intermediaries, including their privacy policies. 510 The terms "privacy" and "privacy policy" are not defined in this 511 context (by IAB or OPES working group). OPES tracing mechanisms allow 512 end users and content providers to identify OPES intermediaries. It 513 is believed that once an intermediary is identified, it would be 514 possible to locate relevant information about that intermediary, 515 including information relevant to requesters perception of privacy 516 policy or reference validity. (XXX: should we move this paragraph 517 into a separate section and expand it? one the other hand, it is 518 probably the job of the architecture draft to define these things so 519 that we can refer to them from here.) 521 11. Security Considerations 523 XXX. 525 12. Compliance 527 This document may be perceived as a proof of OPES compliance with IAB 528 implied recommendations. However, this document does not introduce 529 any compliance subjects. Compliance of OPES implementations is 530 defined in other OPES documents discussed above. 532 13. To-do 534 security section: Does this document have any original security 535 matters worth documenting? 537 normative IDs: To be normative, OPES Internet-Drafts must be replaced 538 with corresponding RFCs when the latter are published. 540 architecture draft: Should architecture draft talk about external/ 541 internal OPES intermediaries, OPES systems, and privacy policies? 542 Should this document be limited to a compilation of references 543 from other OPES drafts, or should we introduce/discuss new 544 concepts here? 546 Appendix A. Change Log 548 Internal WG revision control ID: $Id: iab-cons.xml,v 1.20 2003/09/24 549 05:20:21 rousskov Exp $ 551 2003/09/23 553 * Added a reference to Optional Notification section of the 554 ietf-opes-end-comm draft. 556 * Fixed "Consideration (3.3) Non-blocking" section position. 558 head-sid15 560 * Added a figure showing a chain of internal OPES intermediaries 561 behind a public IP address. Needs more work. More cases? 563 head-sid14 565 * Rewrote the Introduction to the IP addressing consideration. 566 Do NOT explain how IAB considerations, if interpreted literary, 567 do not satisfy important real-world constraints. Instead, use 568 the "chain of OPES intermediaries" exception introduced by IAB 569 itself to show that OPES architecture addresses IAB concerns as 570 long as the "chain" is defined/formed for a given application 571 message rather than being a statically configured application 572 routing table of sorts. IAB had to add the "chain" exception to 573 cover one of the most obvious real-world usage scenario. We use 574 the very same exception to cover all usage scenarios we care 575 about. 577 * Polished text explaining the differences between tracing and 578 notification mechanisms. 580 * Added examples of OPES/HTTP traces. 582 * Be careful not to imply that all OPES intermediaries must obey 583 bypass instructions. Bypass should be ignored when no non-OPES 584 version of the content exists. Ideally, this may need to be 585 polished further -- if there is no non-OPES version of the 586 content, most IAB considerations probably do not apply because 587 there is really no adaptation, only creation of content (and we 588 should not restrict content creation). 590 * Added references to OPES "Communications" draft 591 [I-D.ietf-opes-end-comm]. 593 head-sid9 595 * Polished to meet new xml2rfc strict requirements. 597 head-sid8 599 * Added unpolished meat for all nine considerations. 601 * Added Abbie Barbir as an author. 603 head-sid7 605 * Initial revision 607 Normative References 609 [I-D.ietf-opes-end-comm] 610 Barbir, A., "OPES processor and end points 611 communications", draft-ietf-opes-end-comm-02 (work in 612 progress), September 2003. 614 [I-D.ietf-opes-architecture] 615 Barbir, A., "An Architecture for Open Pluggable Edge 616 Services (OPES)", draft-ietf-opes-architecture-04 (work in 617 progress), December 2002. 619 [I-D.ietf-opes-scenarios] 620 Barbir, A., "OPES Use Cases and Deployment Scenarios", 621 draft-ietf-opes-scenarios-01 (work in progress), August 622 2002. 624 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 625 Considerations for Open Pluggable Edge Services", RFC 626 3238, January 2002. 628 Informative References 630 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 631 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 632 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 634 Authors' Addresses 636 Abbie Barbir 637 Nortel Networks 638 3500 Carling Avenue 639 Nepean, Ontario 640 CA 642 Phone: +1 613 763 5229 643 EMail: abbieb@nortelnetworks.com 645 Alex Rousskov 646 The Measurement Factory 648 EMail: rousskov@measurement-factory.com 649 URI: http://www.measurement-factory.com/ 651 Intellectual Property Statement 653 The IETF takes no position regarding the validity or scope of any 654 intellectual property or other rights that might be claimed to 655 pertain to the implementation or use of the technology described in 656 this document or the extent to which any license under such rights 657 might or might not be available; neither does it represent that it 658 has made any effort to identify any such rights. Information on the 659 IETF's procedures with respect to rights in standards-track and 660 standards-related documentation can be found in BCP-11. Copies of 661 claims of rights made available for publication and any assurances of 662 licenses to be made available, or the result of an attempt made to 663 obtain a general license or permission for the use of such 664 proprietary rights by implementors or users of this specification can 665 be obtained from the IETF Secretariat. 667 The IETF invites any interested party to bring to its attention any 668 copyrights, patents or patent applications, or other proprietary 669 rights which may cover technology that may be required to practice 670 this standard. Please address the information to the IETF Executive 671 Director. 673 Full Copyright Statement 675 Copyright (C) The Internet Society (2003). All Rights Reserved. 677 This document and translations of it may be copied and furnished to 678 others, and derivative works that comment on or otherwise explain it 679 or assist in its implementation may be prepared, copied, published 680 and distributed, in whole or in part, without restriction of any 681 kind, provided that the above copyright notice and this paragraph are 682 included on all such copies and derivative works. However, this 683 document itself may not be modified in any way, such as by removing 684 the copyright notice or references to the Internet Society or other 685 Internet organizations, except as needed for the purpose of 686 developing Internet standards in which case the procedures for 687 copyrights defined in the Internet Standards process must be 688 followed, or as required to translate it into languages other than 689 English. 691 The limited permissions granted above are perpetual and will not be 692 revoked by the Internet Society or its successors or assignees. 694 This document and the information contained herein is provided on an 695 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 696 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 697 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 698 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 699 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 701 Acknowledgement 703 Funding for the RFC Editor function is currently provided by the 704 Internet Society.