idnits 2.17.1 draft-ietf-opes-end-comm-04.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 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 206: '...n OPES processor SHOULD add its entry ...' RFC 2119 keyword, line 210: '... An OPES entity MAY delegate addition...' RFC 2119 keyword, line 227: '... An OPES system MUST add its identifi...' RFC 2119 keyword, line 229: '... An OPES System MUST include informat...' RFC 2119 keyword, line 231: '... An OPES System MUST identify the par...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 313 has weird spacing: '...ces) to be by...' == Line 374 has weird spacing: '...cluding those...' -- 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: '3' is defined on line 534, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 538, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 554, 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. '3') (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 (~~), 9 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-04 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 requirements for Open 38 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 . . . . . . . . . . . 9 53 4.4 Bypass requirements for callout servers . . . . . . . . . . . 10 54 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 55 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 57 7.1 Tracing security considerations . . . . . . . . . . . . . . . 13 58 7.2 Bypass security considerations . . . . . . . . . . . . . . . . 14 59 Normative References . . . . . . . . . . . . . . . . . . . . . 16 60 Informative References . . . . . . . . . . . . . . . . . . . . 17 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 62 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 63 Intellectual Property and Copyright Statements . . . . . . . . 19 65 1. Introduction 67 The Open Pluggable Edge Services (OPES) architecture [7] enables 68 cooperative application services (OPES services) between a data 69 provider, a data consumer, and zero or more OPES processors. The 70 application services under consideration analyze and possibly 71 transform application-level messages exchanged between the data 72 provider and the data consumer. 74 This work specifies the requirements for providing tracing 75 functionality for the OPES architecture [7]. Tracing functionality 76 enables a data provider or a data consumer application to detect 77 inappropriate actions that are performed by OPES entities. The work 78 also develops requirements that can be used to fulfill IAB 79 Notification and Bypass (Non-Blocking) requirements [2]. 81 The architecture document requires [7] that tracing is supported 82 in-band. This design goal limits the type of application protocols 83 that OPES can support. The details of what a trace record can convey 84 are also dependent on the choice of the application level protocol. 86 For these reasons, this work documents requirements for application 87 protocols that need to support OPES traces and non-blocking 88 mechanism. However, the architecture does not prevent implementers of 89 developing out-of-band protocols and techniques to address these 90 limitation. 92 2. OPES System 94 This sections provides a definition of OPES System. This is needed in 95 order to define what is traceable in an OPES Flow. 97 Definition: An OPES System is a set of all OPES entities [7] 98 authorized by either the data provider or the data consumer 99 application to process a given application message. 101 The nature of the authorization agreement determines if authority 102 delegation is transitive (meaning an authorized entity is authorized 103 to include other entities). 105 If specific authority agreements allow for re-delegation, an OPES 106 system can be formed by induction. In this case, an OPES system 107 starts with entities directly authorized by a data provider (or a 108 data consumer) application. The OPES system then includes any OPES 109 entity authorized by an entity that is already in the OPES system. 110 The authority delegation is always viewed in the context of a given 111 application message. 113 An OPES System is defined on an application message basis. Having an 114 authority to process a message does not imply being involved in 115 message processing. Thus, some OPES system members may not 116 participate in processing of a message. Similarly, some members may 117 process the same message several times. 119 The above definition implies that there can be no more than two OPES 120 systems [Client-side and server-side OPES systems can process the 121 same message at the same time] processing the same message at a given 122 time. This is based on the assumption that there is a single data 123 provider and a single data consumer as far as a given application 124 message is concerned. 126 For example, consider a Content Delivery Network (CDN) delivering an 127 image on behalf of a busy web site. OPES processors and services that 128 the CDN uses to adapt and deliver the message comprise an OPES 129 System. In a more complex example, an OPES System would contain CDN 130 entries as well as 3rd-party OPES entities that CDN engages to 131 perform adaptations (e.g., to adjust image quality). 133 3. Requirements for OPES Tracing 135 In an OPES System tracing is defined as the inclusion of necessary 136 information within a message in an OPES Flow that identify the 137 collection of transformations or adaptations that have been performed 138 on it before its delivery to an end point (for example, the data 139 consumer application). An OPES trace represents a snap shot of the 140 tracing information that have been added to a given application 141 message. A trace represents the collections of transformations on an 142 application message in the order that were performed. A traceable 143 entity can appear multiple times in a trace (every time it acts on a 144 message). 146 In an OPES System tracing is performed on per message basis. Trace 147 format is dependent on the application protocol that is being adapted 148 by OPES. A data consumer application can use OPES trace to infer the 149 actions that have been performed by the OPES System. Actions are the 150 set of OPES services that were performed by OPES entities in an OPES 151 System. 153 In an OPES System, the task of providing tracing information, can 154 depend on many factors. Some considerations are: 156 o Providers may be hesitant to reveal information about their 157 internal network infrastructure. 159 o Within a service provider network, OPES processors may be 160 configured to use non-routable, private IP addresses. 162 o A data consumer applications would prefer to have a single point 163 of contact regarding the trace information. 165 In an OPES System some OPES services are message-agnostic and operate 166 on message content or parts of a message. Such services do not 167 manipulate message headers. Other services can manipulate message 168 headers. OPES providers require some freedom in the way they deliver 169 tracing information to an end point. 171 3.1 What is traceable in an OPES Flow? 173 This section focuses on identifying traceable entities in an OPES 174 Flow. 176 Tracing information provides a data consumer application (or a data 177 provider application) with information about OPES entities that 178 adapted the data. There are two distinct uses of OPES traces. First, 179 a trace enables an "end (content provider or consumer) to detect the 180 presence of OPES processors within an OPES System. Such "end" should 181 be able to see a trace entry, but does not need to be able to 182 interpret it beyond identification of the OPES System. 184 Second, the OPES System administrator is expected to be able to 185 interpret the contents of an OPES trace. The trace can be relayed to 186 the administrator by an end (data consumer or provider) without 187 interpretation, as opaque data (e.g., a TCP packet or an HTTP message 188 snapshot). The administrator can use the trace information to 189 identify the participating OPES entities. The administrator can use 190 the trace to identify the applied adaptation services along with 191 other message-specific information. 193 Since the administrators of various OPES Systems can have various 194 ways of looking into tracing, they require the choice of freedom in 195 what to put in trace records and how to format them. Trace records 196 should be easy to extend beyond basic OPES requirements. Trace 197 management algorithms should treat trace records as opaque data to 198 the extent possible. 200 At the implementation level, for a given trace, an OPES entity 201 involved in handling the corresponding application message is 202 traceable or traced if information about it appears in that trace. 203 OPES entities have different levels of traceability requirements. 204 Specifically, 206 o An OPES processor SHOULD add its entry to the trace. 208 o An OPES service May add its entry to the trace. 210 o An OPES entity MAY delegate addition of its trace entry to another 211 OPES entity. For example, an OPES System can have a dedicated OPES 212 processor for adding System entries; an OPES processor can use a 213 callout service to manage all OPES trace manipulations (since such 214 manipulations are OPES adaptations). 216 In an OPES context, a good tracing approach is similar to a trouble 217 ticket ready for submission to a known address. The address is 218 printed on the ticket. The trace in itself is not necessarily a 219 detailed description of what has happened. It is the responsibility 220 of the operator to resolve the problems. 222 3.2 Requirements for OPES System 224 The following requirements apply for information as related to an 225 OPES System: 227 o An OPES system MUST add its identification to the trace. 229 o An OPES System MUST include information about its privacy policy. 231 o An OPES System MUST identify the party responsible for setting and 232 enforcing that policy. 234 o An OPES System MUST include information pointing to a technical 235 contact. 237 o An OPES System MUST include information that identifies, to the 238 technical contact, the OPES processors involved in processing the 239 message. 241 In addressing the above requirements and in order to reduce the size 242 of the trace, an OPES System can provide a URL to the OPES System web 243 page that has links to privacy and other policies. 245 3.3 Requirements for OPES processors 247 Tracing requirements for OPES processors are: 249 o Each OPES processor MUST support tracing, policy can be used to 250 turn tracing on and to determine its granularity. 252 o If tracing is turned on, OPES processor SHOULD add its unique 253 identification to the trace. Here, uniqueness scope is the OPES 254 System containing the processor. 256 o OPES processor SHOULD be able to trace it's own invocation and 257 service(s) execution since it understands the application 258 protocol. 260 3.4 Requirements for callout servers 262 In an OPES system, it is the task of an OPES processor to add trace 263 records to application messages. However, in some cases, callout 264 servers May add trace information to application messages. This 265 should be done under the control of the OPES System provider. 267 4. Requirements for OPES System Bypass (Non-blocking feature) 269 IAB recommendation (3.3) [2] requires that the OPES architecture does 270 not prevent a data consumer application from retrieving non-OPES 271 version of content from a data provider application, provided that 272 the non-OPES content exists. IAB recommendation (3.3) suggests that 273 the Non-blocking feature (Bypass) be used to bypass faulty OPES 274 intermediaries (once they have been identified, by some method). 276 In addressing IAB consideration (3.3), one need to specify what 277 constitute non-OPES content. In some cases, the definition of 278 "non-OPES" content is provider-dependent and may include content 279 adapted by OPES. Examples include content that is adapted for Black 280 and White hand held devices or logging services. In other cases, the 281 availability of certain content can be a function of the internal 282 policy of a given organization that has contracted the services of an 283 OPES provider. For example, Company A has as contract with an OPES 284 provider to perform virus checking on all e-mail attachments. An 285 employee X of Company A can issue a non-blocking request for the 286 virus scanning service. However, the request could be ignored by the 287 OPES provider since it contradicts its agreement with Company A. 289 The above examples illustrates that the availability of non-OPES 290 content can be a function of content providers (or consumers or both) 291 policy and deployment scenarios [1]. For this reason, this work does 292 not attempt to define what is an OPES content as opposed to non-OPES 293 content. The meaning of OPES versus non-OPES content is assumed to be 294 determined through various agreements between the OPES provider, data 295 provider and data consumer application. The agreement will also 296 determine what OPES services can be bypassed and in what order (if 297 applicable). 299 In an OPES System a Bypass request is defined as the act of avoiding 300 the invocation of a service(s) that is identified by a URI within a 301 message in an OPES Flow before its delivery to an end point (for 302 example, the data consumer application). 304 4.1 What can be bypassed in an OPES Flow? 306 In this work, the focus is on developing a bypass feature that allow 307 a user to instruct the OPES System to bypass some or all of its 308 services. The collection of OPES services that can be bypassed is a 309 function of the agreement of the OPES provider with either (or both) 310 the content provider or the content consumer applications. In the 311 general case, a Bypass request is viewed as a bypass instruction that 312 contains a URI that identifies an OPES entity or a group of OPES 313 entities that perform a service (or services) to be bypassed. An 314 instruction may contain more than one such URI. A special wildcard 315 identifier can be used to represent all possible URIs (i.e., all 316 possible OPES services). 318 4.2 Bypass requirements for OPES System 320 In an OPES System the Bypass feature is an end-to-end operation as 321 opposed to a hop-by-hop operation. Bypass requests are generally 322 client centric and go in the opposite direction of tracing requests. 323 Bypass can be performed out of band or in-band. This work requires 324 that the Bypass feature be performed in-band as an extension to an 325 application specific protocol. Non-OPES entities should be able to 326 safely ignore these extensions. The work does not prevent OPES 327 Systems from developing their own out of band protocols. 329 The following requirements apply for Bypass feature as related to an 330 OPES System: 332 o An OPES system MUST support a Bypass feature. This means that the 333 OPES System bypasses an entity whose URI is identified by an OPES 334 end (usually data consumer application). 336 o An OPES System MUST treat a Bypass request as an end-to-end 337 operation. This applies to the whole system. 339 o An OPES System MUST include information about its bypass policy. 341 o An OPES System MUST identify the party responsible for setting and 342 enforcing the bypass policy. 344 o An OPES System MUST include information that identifies, to a 345 technical contact, the OPES processors involved in processing the 346 bypass request. 348 In addressing the above requirements an OPES System can provide a URL 349 to the OPES System web page that has links to Bypass and other 350 policies. 352 In order to facilitate the debugging (or data consumer user 353 experience) of the bypass feature in an OPES System, it would be 354 beneficial if non-bypassed entities include information related to 355 why they ignored the bypass instruction. It is important to note that 356 in some cases the tracing facility itself may be broken and the whole 357 OPES System (or part) may need to be bypassed through the issue of a 358 bypass instruction. 360 4.3 Bypass requirements for OPES processors 362 For a given application protocol, in an OPES System there can be 363 services that operate on application message headers and those that 364 just operate on content. This mix of service requires that an OPES 365 processor that is calling the service(s) to handle the bypass 366 request. In some cases, the first OPES processor that will get the 367 bypass request may not be the first OPES processor that will know 368 whether a non-OPES version of the content is available or not. 370 Bypass requirements for OPES processors are: 372 o There MUST be at least one OPES processor in an OPES System that 373 knows how to interpret and process a bypass request. This 374 requirement applies to all bypass instructions, including those 375 that identify known-to-recipient entities. 377 o OPES processors that do not know how to process a bypass request 378 MUST forward the request to the next application hop provided that 379 the next hop speaks application protocol with OPES bypass support. 381 o The recipient of a bypass instruction with a URI that does not 382 identify any known-to-recipient OPES entity MUST treat that URI as 383 a wildcard identifier (meaning bypass all applicable services). 385 o OPES processor SHOULD be able to bypass it's own invocation and 386 service(s) execution since it understands the application 387 protocol. 389 4.4 Bypass requirements for callout servers 391 In an OPES system, it is the task of an OPES processor to process 392 bypass requests. However, in some cases, callout servers May be 393 involved in processing Bypass requests. This should be done under the 394 control of the OPES System provider. 396 5. Protocol Binding 398 The task of encoding tracing and bypass features is application 399 protocol specific. Separate documents will address HTTP and other 400 protocols. 402 6. IANA considerations 404 This specification contains no IANA considerations. Application 405 bindings MAY contain application-specific IANA considerations. 407 7. Security Considerations 409 The security considerations for OPES are documented in [6]. This 410 document is a requirement document for tracing and Bypass feature. 411 The requirements that are stated in this document can be used to 412 extend an application level protocol to support these features. As 413 such, the work has security precautions. 415 7.1 Tracing security considerations 417 The tracing facility for OPES architecture is implemented as a 418 protocol extension. Inadequate implementations of the tracing 419 facility may defeat safeguards built into the OPES architecture. The 420 tracing facility by itself can become a target of malicious attacks 421 or used to lunch attacks on an OPES System. 423 Threats caused by or against the tracing facility can be viewed as 424 threats at the application level in an OPES Flow. In this case, the 425 threats can affect the data consumer and the data provider 426 application. 428 Since tracing information is a protocol extension, these traces can 429 be injected in the data flow by non-OPES entities. In this case, 430 there are risks that non-OPES entities can be compromised in a 431 fashion that threat the overall integrity and effectiveness of an 432 OPES System. For example, a non-OPES proxy can add fake tracing 433 information into a trace. This can be done in the form of wrong, or 434 unwanted, or non existent services. A non-OPES entity can inject 435 large size traces that may cause buffer overflow in a data consumer 436 application. The same threats can arise from compromised OPES 437 entities. An attacker can control an OPES entity and inject wrong, or 438 very large trace information that can overwhelm an end or the next 439 OPES entity in an OPES flow. Similar threats can result from bad 440 implementations of the tracing facility in trusted OPES entities. 442 Compromised tracing information can be used to launch attacks on an 443 OPES System that give the impression that unwanted content 444 transformation was performed on the data. This can be achieved by 445 inserting wrong entity (such OPES processor) identifiers. A 446 compromised trace can affect the overall message integrity structure. 447 This can affect entities that use message header information to 448 perform services such as accounting, load balancing, or 449 reference-based services. 451 Compromised trace information can be used to launch DoS attacks that 452 can overwhelm a data consumer application or an OPES entity in an 453 OPES Flow. Inserting wrong tracing information can complicates the 454 debugging tasks performed by system administrator during trouble 455 shooting of OPES System behavior. 457 Specific protocol binding documents ought to take these security 458 threats into consideration. It is recommended that protocol bindings 459 provide safe features into their specifications. Such features may 460 include a place holder in the message header that indicates the size 461 of the trace. Other holders can include the option of signing the 462 trace information as a proof of authenticity. 464 As a precaution, OPES entities ought to be capable of verifying that 465 the inserted traces are performed by legal OPES entities. This can be 466 done as part of the authorization and authentication face. Policy can 467 be used to indicate what trace information can be expected from a 468 peer entity. Other application level related security concerns can be 469 found in [6]. 471 7.2 Bypass security considerations 473 The bypass facility for OPES architecture is implemented as a 474 protocol extension. Inadequate implementations of the bypass facility 475 may defeat safeguards built into the OPES architecture. The bypass 476 facility by itself can become a target of malicious attacks or used 477 to lunch attacks on an OPES System. 479 Threats caused by or against the bypass facility can be viewed as 480 threats at the application level in an OPES Flow. In this case, the 481 threats can affect the data consumer and the data provider 482 application. 484 There are risks for the OPES System by non-OPES entities, whereby, 485 these entities can insert bypass instructions into the OPES Flow. The 486 threat can come from compromised non-OPES entities. The threat might 487 affect the overall integrity and effectiveness of an OPES System. For 488 example, a non-OPES proxy can add bypass instruction to bypass 489 legitimate OPES entities. The attack might result in overwhelming the 490 original content provider servers, since the attack essentially 491 bypass any load balancing techniques. In addition, such an attack is 492 also equivalent to a DoS attack, whereby, a legitimate data consumer 493 application may not be able to access some content from a content 494 provider or its OPES version. 496 Since an OPES Flow may include non-OPES entities, it is susceptible 497 to man-in-the-middle attacks, whereby an intruder may inject bypass 498 instructions into the data path. These attacks may affect content 499 availability or disturb load balancing techniques in the network. 501 The above threats can also arise by compromised OPES entities. An 502 intruder can compromise an OPES entities and then use 503 man-in-the-middle techniques to disturb content availability to a 504 data consumer application or overload a content provider server 505 (essentially, some form of a DoS attack). 507 Attackers can use the bypass instruction to affect the overall 508 integrity of the OPES System. The ability to illegally introduce 509 bypass instructions into a data flow may effect the accounting of the 510 OPES System. It may also affect the quality of content that is 511 delivered to the data consumer applications. Similar threats can 512 arise from bad implementations of the bypass facility. 514 Specific protocol binding documents ought to take these security 515 threats into consideration. It is recommended that protocol bindings 516 provide safe features into their specifications. Such features may 517 include a place holder in the message header that indicates who 518 originated the bypass request. Other holders can include the option 519 of signing the bypass request as a proof of identity. Other 520 application level related security concerns can be found in [6]. 522 Normative References 524 [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", 525 Internet-Draft http://www.ietf.org/internet-drafts/ 526 draft-ietf-opes-scenarios-01.txt, August 2002. 528 Informative References 530 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 531 Considerations for Open Pluggable Edge Services", RFC 3238, 532 January 2002. 534 [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 535 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 536 HTTP/1.1", RFC 2616, June 1999. 538 [4] A. Barbir et al., "Policy, Authorization and Enforcement 539 Requirements of OPES", Internet-Draft http://www.ietf.org/ 540 internet-drafts/draft-ietf-opes-authorization-02.txt, February 541 2003. 543 [5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, 544 September 2003. 546 [6] A. Barbir et al., "Security Threats and Risks for Open Pluggable 547 Edge Services", Internet-Draft http://www.ietf.org/ 548 internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. 550 [7] A. Barbir et al., "An Architecture for Open Pluggable Edge 551 Services (OPES)", Internet-Draft http://www.ietf.org/ 552 internet-drafts/draft-ietf-opes-architecture-04, December 2002. 554 [8] A. Barbir et al., "OPES Treatment of IAB Considerations", 555 Internet-Draft http://www.ietf.org/internet-drafts/ 556 draft-ietf-opes-iab-02.txt, February 2004. 558 Author's Address 560 Abbie Barbir 561 Nortel Networks 562 3500 Carling Avenue 563 Nepean, Ontario K2H 8E9 564 Canada 566 Phone: +1 613 763 5229 567 EMail: abbieb@nortelnetworks.com 569 Appendix A. Acknowledgements 571 Several people has contributed to this work. Many thanks to: Alex 572 Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin 573 Stecher, Marshall Rose and Reinaldo Penno. 575 Intellectual Property Statement 577 The IETF takes no position regarding the validity or scope of any 578 intellectual property or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; neither does it represent that it 582 has made any effort to identify any such rights. Information on the 583 IETF's procedures with respect to rights in standards-track and 584 standards-related documentation can be found in BCP-11. Copies of 585 claims of rights made available for publication and any assurances of 586 licenses to be made available, or the result of an attempt made to 587 obtain a general license or permission for the use of such 588 proprietary rights by implementors or users of this specification can 589 be obtained from the IETF Secretariat. 591 The IETF invites any interested party to bring to its attention any 592 copyrights, patents or patent applications, or other proprietary 593 rights which may cover technology that may be required to practice 594 this standard. Please address the information to the IETF Executive 595 Director. 597 Full Copyright Statement 599 Copyright (C) The Internet Society (2003). All Rights Reserved. 601 This document and translations of it may be copied and furnished to 602 others, and derivative works that comment on or otherwise explain it 603 or assist in its implementation may be prepared, copied, published 604 and distributed, in whole or in part, without restriction of any 605 kind, provided that the above copyright notice and this paragraph are 606 included on all such copies and derivative works. However, this 607 document itself may not be modified in any way, such as by removing 608 the copyright notice or references to the Internet Society or other 609 Internet organizations, except as needed for the purpose of 610 developing Internet standards in which case the procedures for 611 copyrights defined in the Internet Standards process must be 612 followed, or as required to translate it into languages other than 613 English. 615 The limited permissions granted above are perpetual and will not be 616 revoked by the Internet Society or its successors or assignees. 618 This document and the information contained herein is provided on an 619 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 620 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 621 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 622 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 623 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 625 Acknowledgment 627 Funding for the RFC Editor function is currently provided by the 628 Internet Society.