idnits 2.17.1 draft-ietf-opes-end-comm-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 321 has weird spacing: '...ces) to be by...' == Line 329 has weird spacing: '...or then bypas...' == Line 384 has weird spacing: '...cluding those...' == Line 541 has weird spacing: '...ic with bypas...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 565, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 569, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 574, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 586, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-opes-scenarios (ref. '1') -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-05) exists of draft-ietf-opes-iab-02 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: March 31, 2004 Oct. 2003 6 OPES entities and end points communication 7 draft-ietf-opes-end-comm-05 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on March 31, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo documents tracing and non-blocking (bypass) requirements 38 for Open Pluggable Edge Services (OPES). 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5 45 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5 46 3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . 6 47 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7 48 3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7 49 4. Requirements for OPES System Bypass (Non-blocking feature) . . 8 50 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . 8 51 4.2 Bypass requirements for OPES System . . . . . . . . . . . . . 9 52 4.3 Bypass requirements for OPES processors . . . . . . . . . . . 10 53 4.4 Bypass requirements for callout servers . . . . . . . . . . . 10 54 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 55 6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12 56 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 58 8.1 Tracing security considerations . . . . . . . . . . . . . . . 14 59 8.2 Bypass security considerations . . . . . . . . . . . . . . . . 15 60 Normative References . . . . . . . . . . . . . . . . . . . . . 17 61 Informative References . . . . . . . . . . . . . . . . . . . . 18 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 63 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 64 Intellectual Property and Copyright Statements . . . . . . . . 20 66 1. Introduction 68 The Open Pluggable Edge Services (OPES) architecture [8] enables 69 cooperative application services (OPES services) between a data 70 provider, a data consumer, and zero or more OPES processors. The 71 application services under consideration analyze and possibly 72 transform application-level messages exchanged between the data 73 provider and the data consumer. 75 This work specifies the requirements for providing tracing 76 functionality for the OPES architecture [8]. Tracing functionality 77 enables a data provider or a data consumer application to detect 78 inappropriate actions that are performed by OPES entities. The work 79 also develops requirements that can be used to fulfill IAB 80 Notification and Bypass (Non-Blocking) requirements [2]. 82 The architecture document requires [8] that tracing is supported 83 in-band. This design goal limits the type of application protocols 84 that OPES can support. The details of what a trace record can convey 85 are also dependent on the choice of the application level protocol. 87 For these reasons, this work documents requirements for application 88 protocols that need to support OPES traces and non-blocking 89 mechanism. The architecture does not prevent implementers of 90 developing out-of-band protocols and techniques to address these 91 limitation. In this document the key words that are used to signify 92 requirements are based on RFC 2119 [3]. 94 2. OPES System 96 This sections provides a definition of OPES System. This is needed in 97 order to define what is traceable in an OPES Flow. 99 Definition: An OPES System is a set of all OPES entities [8] 100 authorized by either the data provider or the data consumer 101 application to process a given application message. 103 The nature of the authorization agreement determines if authority 104 delegation is transitive (meaning an authorized entity is authorized 105 to include other entities). 107 If specific authority agreements allow for re-delegation, an OPES 108 system can be formed by induction. In this case, an OPES system 109 starts with entities directly authorized by a data provider (or a 110 data consumer) application. The OPES system then includes any OPES 111 entity authorized by an entity that is already in the OPES system. 112 The authority delegation is always viewed in the context of a given 113 application message. 115 An OPES System is defined on an application message basis. Having an 116 authority to process a message does not imply being involved in 117 message processing. Thus, some OPES system members may not 118 participate in processing of a message. Similarly, some members may 119 process the same message several times. 121 The above definition implies that there can be no more than two OPES 122 systems [Client-side and server-side OPES systems can process the 123 same message at the same time] processing the same message at a given 124 time. This is based on the assumption that there is a single data 125 provider and a single data consumer as far as a given application 126 message is concerned. 128 For example, consider a Content Delivery Network (CDN) delivering an 129 image on behalf of a busy web site. OPES processors and services that 130 the CDN uses to adapt and deliver the message comprise an OPES 131 System. In a more complex example, an OPES System would contain CDN 132 entries as well as 3rd-party OPES entities that CDN engages to 133 perform adaptations (e.g., to adjust image quality). 135 3. Requirements for OPES Tracing 137 In an OPES System tracing is defined as the inclusion of necessary 138 information within a message in an OPES Flow that identify the 139 collection of transformations or adaptations that have been performed 140 on it before its delivery to an end point (for example, the data 141 consumer application). An OPES trace represents a snap shot of the 142 tracing information that have been added to a given application 143 message. A trace represents the collections of transformations on an 144 application message in the order that were performed. A traceable 145 entity can appear multiple times in a trace (every time it acts on a 146 message). 148 In an OPES System tracing is performed on per message basis. Trace 149 format is dependent on the application protocol that is being adapted 150 by OPES. A data consumer application can use OPES trace to infer the 151 actions that have been performed by the OPES System. Actions are the 152 set of OPES services that were performed by OPES entities in an OPES 153 System. 155 In an OPES System, the task of providing tracing information, can 156 depend on many factors. Some considerations are: 158 o Providers may be hesitant to reveal information about their 159 internal network infrastructure. 161 o Within a service provider network, OPES processors may be 162 configured to use non-routable, private IP addresses. 164 o A data consumer applications would prefer to have a single point 165 of contact regarding the trace information. 167 In an OPES System some OPES services are message-agnostic and operate 168 on message content or parts of a message. Such services do not 169 manipulate message headers. Other services can manipulate message 170 headers. OPES providers require some freedom in the way they deliver 171 tracing information to an end point. 173 3.1 What is traceable in an OPES Flow? 175 This section focuses on identifying traceable entities in an OPES 176 Flow. 178 Tracing information provides a data consumer application (or a data 179 provider application) with information about OPES entities that 180 adapted the data. There are two distinct uses of OPES traces. First, 181 a trace enables an "end (content provider or consumer) to detect the 182 presence of OPES processors within an OPES System. Such "end" should 183 be able to see a trace entry, but does not need to be able to 184 interpret it beyond identification of the OPES System. 186 Second, the OPES System administrator is expected to be able to 187 interpret the contents of an OPES trace. The trace can be relayed to 188 the administrator by an end (data consumer or provider) without 189 interpretation, as opaque data (e.g., a TCP packet or an HTTP message 190 snapshot). The administrator can use the trace information to 191 identify the participating OPES entities. The administrator can use 192 the trace to identify the applied adaptation services along with 193 other message-specific information. 195 Since the administrators of various OPES Systems can have various 196 ways of looking into tracing, they require the choice of freedom in 197 what to put in trace records and how to format them. Trace records 198 should be easy to extend beyond basic OPES requirements. Trace 199 management algorithms should treat trace records as opaque data to 200 the extent possible. 202 At the implementation level, for a given trace, an OPES entity 203 involved in handling the corresponding application message is 204 traceable or traced if information about it appears in that trace. 205 OPES entities have different levels of traceability requirements. 206 Specifically, 208 o An OPES processor MUST add its entry to the trace. 210 o An OPES service MAY add its entry to the trace. 212 o An OPES entity MAY delegate addition of its trace entry to another 213 OPES entity. For example, an OPES System can have a dedicated OPES 214 processor for adding System entries; an OPES processor can use a 215 callout service to manage all OPES trace manipulations (since such 216 manipulations are OPES adaptations). 218 In an OPES context, a good tracing approach is similar to a trouble 219 ticket ready for submission to a known address. The address is 220 printed on the ticket. The trace in itself is not necessarily a 221 detailed description of what has happened. It is the responsibility 222 of the operator to resolve the problems. 224 3.2 Requirements for OPES System 226 The following requirements apply for information as related to an 227 OPES System: 229 o An OPES System MUST trace itself. 231 o An OPES System MUST include information about its privacy policy. 233 o An OPES System MUST identify the party responsible for setting and 234 enforcing that policy. 236 o An OPES System MUST include information pointing to a technical 237 contact. 239 o An OPES System MUST include information that identifies, to the 240 technical contact, the OPES processors involved in processing the 241 message. 243 o When providing required information, an OPES System MAY use a 244 single URI to identify a resource containing several required 245 items. For example, an OPES System can point to a single web page 246 with a reference to System privacy policy and technical contact 247 information. 249 This specification does not define the meaning of the terms privacy 250 policy, policy enforcement, or technical contact and contains no 251 requirements regarding encoding, language, format, or any other 252 aspects of that information. Furthermore, an example of System 253 identification would be something like http://www.examplecompany.com/ 254 opes/?client=example.com. 256 3.3 Requirements for OPES processors 258 Tracing requirements for OPES processors are: 260 o OPES processor MUST add its unique identification to the trace. 261 Here, uniqueness scope is the OPES System containing the 262 processor. 264 o OPES processor MUST be able to trace it's own invocation and 265 service(s) execution. 267 3.4 Requirements for callout servers 269 In an OPES system, it is the task of an OPES processor to add trace 270 records to application messages. However, in some cases, callout 271 servers may add trace information to application messages. This 272 should be done under the control of the OPES System provider. 274 4. Requirements for OPES System Bypass (Non-blocking feature) 276 IAB recommendation (3.3) [2] requires that the OPES architecture does 277 not prevent a data consumer application from retrieving non-OPES 278 version of content from a data provider application, provided that 279 the non-OPES content exists. IAB recommendation (3.3) suggests that 280 the Non-blocking feature (Bypass) be used to bypass faulty OPES 281 intermediaries (once they have been identified, by some method). 283 In addressing IAB consideration (3.3), one need to specify what 284 constitute non-OPES content. In this work the definition of 285 "non-OPES" content is provider dependent. However, in some cases, the 286 availability of "non-OPES" content can also be a function of the 287 internal policy of a given organization that has contracted the 288 services of an OPES provider. For example, Company A has as contract 289 with an OPES provider to perform virus checking on all e-mail 290 attachments. An employee X of Company A can issue a non-blocking 291 request for the virus scanning service. However, the request could be 292 ignored by the OPES provider since it contradicts its agreement with 293 Company A. 295 The above examples illustrates that the availability of non-OPES 296 content can be a function of content providers (or consumers or both) 297 policy and deployment scenarios [1]. For this reason, this work does 298 not attempt to define what is an OPES content as opposed to non-OPES 299 content. The meaning of OPES versus non-OPES content is assumed to be 300 determined through various agreements between the OPES provider, data 301 provider and data consumer application. The agreement will also 302 determine what OPES services can be bypassed and in what order (if 303 applicable). 305 In an OPES System a bypass request is defined as the act of avoiding 306 the invocation of a service(s) that is identified by a URI within a 307 message in an OPES Flow before its delivery to an end point (for 308 example, the data consumer application). The availability of non-OPES 309 content is a precondition to whether a bypass instruction is honored 310 or not in an OPES System. 312 4.1 What can be bypassed in an OPES Flow? 314 In this work, the focus is on developing a bypass feature that allow 315 a user to instruct the OPES System to bypass some or all of its 316 services. The collection of OPES services that can be bypassed is a 317 function of the agreement of the OPES provider with either (or both) 318 the content provider or the content consumer applications. In the 319 general case, a bypass request is viewed as a bypass instruction that 320 contains a URI that identifies an OPES entity or a group of OPES 321 entities that perform a service (or services) to be bypassed. An 322 instruction may contain more than one such URI. A special wildcard 323 identifier can be used to represent all possible URIs (i.e., all 324 possible OPES services that are relevant to an OPES processor). 326 In an OPES Flow, a bypass request is processed in a local manner by 327 each involved OPES processor. This means that an OPES processor 328 examines the bypass instruction and if non-OPES content is available, 329 the processor then bypasses services that are local to itself. This 330 may include the act of bypassing itself completely depending on what 331 is specified in the URI. The request is then forwarded to the next 332 OPES processor in the OPES Flow. The next OPES processor would then 333 honor all bypass requests that are relevant to it provided that the 334 non-OPES content is available. The processing chain continues 335 throughout the whole processors that are involved in the OPES Flow. 336 If an OPES processor does not know how to honor a bypass request it 337 forwards the message to the next processor in the OPES Flow. At the 338 OPES system level, a bypass instruction is honored when at least one 339 OPES processor bypasses the services that are specified by the URI 340 that is specified in the instruction (provided that the non-OPES 341 content is available). 343 4.2 Bypass requirements for OPES System 345 In an OPES System bypass requests are generally client centric and go 346 in the opposite direction of tracing requests. Bypass can be 347 performed out of band or in-band. This work requires that the Bypass 348 feature be performed in-band as an extension to an application 349 specific protocol. Non-OPES entities should be able to safely ignore 350 these extensions. The work does not prevent OPES Systems from 351 developing their own out of band protocols. 353 The following requirements apply for Bypass feature as related to an 354 OPES System (the availability of a non-OPES content is a 355 precondition) : 357 o An OPES system MUST support a Bypass feature. This means that the 358 OPES System bypasses an entity whose URI is identified by an OPES 359 end (usually data consumer application). 361 In order to facilitate the debugging (or data consumer user 362 experience) of the bypass feature in an OPES System, it would be 363 beneficial if non-bypassed entities include information related to 364 why they ignored the bypass instruction. It is important to note that 365 in some cases the tracing facility itself may be broken and the whole 366 OPES System (or part) may need to be bypassed through the issue of a 367 bypass instruction. 369 4.3 Bypass requirements for OPES processors 371 For a given application protocol, in an OPES System there can be 372 services that operate on application message headers and those that 373 just operate on content. This mix of service requires that an OPES 374 processor that is calling the service(s) to handle the bypass 375 request. In some cases, the first OPES processor that will get the 376 bypass request may not be the first OPES processor that will know 377 whether a non-OPES version of the content is available or not. 379 Bypass requirements for OPES processors are (the availability of a 380 non-OPES content is a precondition): 382 o OPES processor SHOULD be able to interpret and process a bypass 383 instruction. This requirement applies to all bypass instructions, 384 including those that identify known-to-recipient services. 386 o OPES processors that do not know how to process a bypass request 387 MUST forward the request to the next application hop provided that 388 the next hop speaks application protocol with OPES bypass support. 390 o OPES processor SHOULD be able to bypass it's service(s) execution. 392 Provided that non-OPES content is available, those OPES processors 393 that know how to process and interpret a bypass instruction have the 394 following requirements: 396 o The recipient of a bypass instruction with a URI that does not 397 identify any known-to-recipient OPES entity MUST treat that URI as 398 a wildcard identifier (meaning bypass all applicable local 399 services). 401 4.4 Bypass requirements for callout servers 403 In an OPES system, it is the task of an OPES processor to process 404 bypass requests. However, in some cases, callout servers may be 405 involved in processing Bypass requests. This should be done under the 406 control of the OPES System provider. 408 5. Protocol Binding 410 The task of encoding tracing and bypass features is application 411 protocol specific. Separate documents will address HTTP and other 412 protocols. 414 6. Compliance Considerations 416 This work specifies high level requirements for tracing and bypass. 417 Protocol binding specifications MUST consider and follow all MUSTs in 418 this draft. Protocol binding specifications MUST be compliant to this 419 draft. As such any implementation compliant to the binding 420 specification is also compliant to this draft. 422 7. IANA considerations 424 This specification contains no IANA considerations. Application 425 bindings MAY contain application-specific IANA considerations. 427 8. Security Considerations 429 The security considerations for OPES are documented in [7]. This 430 document is a requirement document for tracing and Bypass feature. 431 The requirements that are stated in this document can be used to 432 extend an application level protocol to support these features. As 433 such, the work has security precautions. 435 8.1 Tracing security considerations 437 The tracing facility for OPES architecture is implemented as a 438 protocol extension. Inadequate implementations of the tracing 439 facility may defeat safeguards built into the OPES architecture. The 440 tracing facility by itself can become a target of malicious attacks 441 or used to lunch attacks on an OPES System. 443 Threats caused by or against the tracing facility can be viewed as 444 threats at the application level in an OPES Flow. In this case, the 445 threats can affect the data consumer and the data provider 446 application. 448 Since tracing information is a protocol extension, these traces can 449 be injected in the data flow by non-OPES entities. In this case, 450 there are risks that non-OPES entities can be compromised in a 451 fashion that threat the overall integrity and effectiveness of an 452 OPES System. For example, a non-OPES proxy can add fake tracing 453 information into a trace. This can be done in the form of wrong, or 454 unwanted, or non existent services. A non-OPES entity can inject 455 large size traces that may cause buffer overflow in a data consumer 456 application. The same threats can arise from compromised OPES 457 entities. An attacker can control an OPES entity and inject wrong, or 458 very large trace information that can overwhelm an end or the next 459 OPES entity in an OPES flow. Similar threats can result from bad 460 implementations of the tracing facility in trusted OPES entities. 462 Compromised tracing information can be used to launch attacks on an 463 OPES System that give the impression that unwanted content 464 transformation was performed on the data. This can be achieved by 465 inserting wrong entity (such OPES processor) identifiers. A 466 compromised trace can affect the overall message integrity structure. 467 This can affect entities that use message header information to 468 perform services such as accounting, load balancing, or 469 reference-based services. 471 Compromised trace information can be used to launch DoS attacks that 472 can overwhelm a data consumer application or an OPES entity in an 473 OPES Flow. Inserting wrong tracing information can complicates the 474 debugging tasks performed by system administrator during trouble 475 shooting of OPES System behavior. 477 As a precaution, OPES entities ought to be capable of verifying that 478 the inserted traces are performed by legal OPES entities. This can be 479 done as part of the authorization and authentication face. Policy can 480 be used to indicate what trace information can be expected from a 481 peer entity. Other application level related security concerns can be 482 found in [7]. 484 8.2 Bypass security considerations 486 The bypass facility for OPES architecture is implemented as a 487 protocol extension. Inadequate implementations of the bypass facility 488 may defeat safeguards built into the OPES architecture. The bypass 489 facility by itself can become a target of malicious attacks or used 490 to lunch attacks on an OPES System. 492 Threats caused by or against the bypass facility can be viewed as 493 threats at the application level in an OPES Flow. In this case, the 494 threats can affect the data consumer and the data provider 495 application. 497 There are risks for the OPES System by non-OPES entities, whereby, 498 these entities can insert bypass instructions into the OPES Flow. The 499 threat can come from compromised non-OPES entities. The threat might 500 affect the overall integrity and effectiveness of an OPES System. For 501 example, a non-OPES proxy can add bypass instruction to bypass 502 legitimate OPES entities. The attack might result in overwhelming the 503 original content provider servers, since the attack essentially 504 bypass any load balancing techniques. In addition, such an attack is 505 also equivalent to a DoS attack, whereby, a legitimate data consumer 506 application may not be able to access some content from a content 507 provider or its OPES version. 509 Since an OPES Flow may include non-OPES entities, it is susceptible 510 to man-in-the-middle attacks, whereby an intruder may inject bypass 511 instructions into the data path. These attacks may affect content 512 availability or disturb load balancing techniques in the network. 514 The above threats can also arise by compromised OPES entities. An 515 intruder can compromise an OPES entities and then use 516 man-in-the-middle techniques to disturb content availability to a 517 data consumer application or overload a content provider server 518 (essentially, some form of a DoS attack). 520 Attackers can use the bypass instruction to affect the overall 521 integrity of the OPES System. The ability to introduce bypass 522 instructions into a data flow may effect the accounting of the OPES 523 System. It may also affect the quality of content that is delivered 524 to the data consumer applications. Similar threats can arise from bad 525 implementations of the bypass facility. 527 Inconsistent or selective bypass is also a threat. Here, one end can 528 try to bypass a subset of OPES entities so that the resulting content 529 is malformed and crashes or compromises entities that process that 530 content (and expect that content to be complete and valid). Such 531 exceptions are often not tested because implementers do not expect a 532 vital service to disappear from the processing loop. 534 Other threats can arise from configuring access control policies for 535 OPES entities. It is possible that systems implementing access 536 controls via OPES entities may be incorrectly configured to honor 537 bypass and, hence, give unauthorized access to intruders. 539 Tap bypass can also be a threat. This is because systems implementing 540 wiretaps via OPES entities may be incorrectly configured to honor 541 bypass and, hence, ignore (leave undetected) traffic with bypass 542 instructions that should have been tapped or logged. It is also 543 possible for one end to bypass services such as virus scanning at the 544 receiving end. This threat can be used by hackers to inject viruses 545 throughout the network. 547 Other application level related security concerns can be found in 548 [7]. 550 Normative References 552 [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", 553 Internet-Draft http://www.ietf.org/internet-drafts/ 554 draft-ietf-opes-scenarios-01.txt, August 2002. 556 Informative References 558 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 559 Considerations for Open Pluggable Edge Services", RFC 3238, 560 January 2002. 562 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 563 Levels", RFC 2119, March 1997. 565 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 566 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 567 HTTP/1.1", RFC 2616, June 1999. 569 [5] A. Barbir et al., "Policy, Authorization and Enforcement 570 Requirements of OPES", Internet-Draft http://www.ietf.org/ 571 internet-drafts/draft-ietf-opes-authorization-02.txt, February 572 2003. 574 [6] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft 575 http://www.ietf.org/internet-drafts/draft-ietf-opes-http-00.txt, 576 July 2003. 578 [7] A. Barbir et al., "Security Threats and Risks for Open Pluggable 579 Edge Services", Internet-Draft http://www.ietf.org/ 580 internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. 582 [8] A. Barbir et al., "An Architecture for Open Pluggable Edge 583 Services (OPES)", Internet-Draft http://www.ietf.org/ 584 internet-drafts/draft-ietf-opes-architecture-04, December 2002. 586 [9] A. Barbir et al., "OPES Treatment of IAB Considerations", 587 Internet-Draft http://www.ietf.org/internet-drafts/ 588 draft-ietf-opes-iab-02.txt, September 2003. 590 Author's Address 592 Abbie Barbir 593 Nortel Networks 594 3500 Carling Avenue 595 Nepean, Ontario K2H 8E9 596 Canada 598 Phone: +1 613 763 5229 599 EMail: abbieb@nortelnetworks.com 601 Appendix A. Acknowledgements 603 Several people has contributed to this work. Many thanks to: Alex 604 Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin 605 Stecher, Marshall Rose and Reinaldo Penno. 607 Intellectual Property Statement 609 The IETF takes no position regarding the validity or scope of any 610 intellectual property or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; neither does it represent that it 614 has made any effort to identify any such rights. Information on the 615 IETF's procedures with respect to rights in standards-track and 616 standards-related documentation can be found in BCP-11. Copies of 617 claims of rights made available for publication and any assurances of 618 licenses to be made available, or the result of an attempt made to 619 obtain a general license or permission for the use of such 620 proprietary rights by implementors or users of this specification can 621 be obtained from the IETF Secretariat. 623 The IETF invites any interested party to bring to its attention any 624 copyrights, patents or patent applications, or other proprietary 625 rights which may cover technology that may be required to practice 626 this standard. Please address the information to the IETF Executive 627 Director. 629 Full Copyright Statement 631 Copyright (C) The Internet Society (2003). All Rights Reserved. 633 This document and translations of it may be copied and furnished to 634 others, and derivative works that comment on or otherwise explain it 635 or assist in its implementation may be prepared, copied, published 636 and distributed, in whole or in part, without restriction of any 637 kind, provided that the above copyright notice and this paragraph are 638 included on all such copies and derivative works. However, this 639 document itself may not be modified in any way, such as by removing 640 the copyright notice or references to the Internet Society or other 641 Internet organizations, except as needed for the purpose of 642 developing Internet standards in which case the procedures for 643 copyrights defined in the Internet Standards process must be 644 followed, or as required to translate it into languages other than 645 English. 647 The limited permissions granted above are perpetual and will not be 648 revoked by the Internet Society or its successors or assignees. 650 This document and the information contained herein is provided on an 651 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 652 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 653 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 654 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 655 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 657 Acknowledgment 659 Funding for the RFC Editor function is currently provided by the 660 Internet Society.