idnits 2.17.1 draft-ietf-opes-architecture-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 : ---------------------------------------------------------------------------- ** There are 41 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** 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 151: '... an OPES processor MUST include a data...' RFC 2119 keyword, line 157: '...ity control , OPES processors MUST be:...' RFC 2119 keyword, line 177: '... sources and MUST resolve into an un...' RFC 2119 keyword, line 268: '... it MUST result in the same unambigu...' RFC 2119 keyword, line 276: '...P). However, the data dispatcher MUST...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 96 has weird spacing: '... than at on...' == Line 182 has weird spacing: '...tion is maint...' == Line 524 has weird spacing: '...Tracing enabl...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The callout servers MUST be aware of the policy governing the communication path. They MUST not, for example, communicate confidential information to auxiliary servers outside the trust domain. -- 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 (December 11, 2002) is 7805 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) == Unused Reference: '4' is defined on line 618, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 634, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational draft: draft-ietf-opes-protocol-reqs (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 6 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: June 11, 2003 R. Chen 5 AT&T Labs 6 M. Hofmann 7 Bell Labs/Lucent Technologies 8 H. Orman 9 Purple Streak Development 10 R. Penno 11 Nortel Networks 12 December 11, 2002 14 An Architecture for Open Pluggable Edge Services (OPES) 15 draft-ietf-opes-architecture-04 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 11, 2003. 40 Copyright Notice 42 Copyright (C) The Internet Society (2002). All Rights Reserved. 44 Abstract 46 This memo defines an architecture that enables the creation of an 47 application service in which a data provider, a data consumer, and 48 zero or more application entities cooperatively implement a data 49 stream service. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 7 60 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . 9 61 3. Security and Privacy Considerations . . . . . . . . . . . . 11 62 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.2 Establishing Trust and Service Authorization . . . . . . . . 12 64 3.3 Callout protocol . . . . . . . . . . . . . . . . . . . . . . 13 65 3.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . 14 67 4. IAB Architectural and Policy Considerations for OPES . . . . 15 68 4.1 IAB consideration (2.1) One-party consent . . . . . . . . . 15 69 4.2 IAB consideration (2.2) IP-layer communications . . . . . . 15 70 4.3 IAB consideration (3.1 and 3.2) Notification . . . . . . . . 15 71 4.4 IAB consideration (3.3) Non-blocking . . . . . . . . . . . . 15 72 4.5 IAB consideration (4.1) URI resolution . . . . . . . . . . . 15 73 4.6 IAB consideration (4.2) Reference validity . . . . . . . . . 16 74 4.7 IAB consideration (4.3) Application addressing extensions . 16 75 4.8 IAB consideration (5.1) Privacy . . . . . . . . . . . . . . 16 76 5. Security Considerations . . . . . . . . . . . . . . . . . . 17 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 78 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 Normative References . . . . . . . . . . . . . . . . . . . . 20 80 Informative References . . . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 82 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 83 Intellectual Property and Copyright Statements . . . . . . . 24 85 1. Introduction 87 When supplying a data stream service between a provider and a 88 consumer, the need may arise to provision the use of other 89 application entities, in addition to the provider and consumer. For 90 example, some party may wish to customize a data stream as a service 91 to a consumer. The customization step might be based on the 92 customer's resource availability (e.g., display capabilities). 94 In some cases it may be beneficial to provide a customization service 95 at a network location between the provider and consumer host rather 96 than at one of these endpoints. For certain services performed on 97 behalf of the end-user, this may be the only option of service 98 deployment. In this case, zero or more additional application 99 entities may participate in the data stream service. There are many 100 possible provisioning scenarios which make a data stream service 101 attractive. The OPES Use Cases and Deployment Scenarios [1] document 102 provides examples of OPES services. The document discusses services 103 that modify requests, services that modify responses and services 104 that create responses. It is recommended that the document on OPES 105 Use Cases and Deployment Scenarios [1] be read before reading this 106 document. 108 This document presents the architectural components of Open Pluggable 109 Edge Services (OPES) that are needed in order to perform a data 110 stream service. The architecture addresses the IAB considerations 111 described in [2]. These considerations are covered in various parts 112 of the document. Section 2.5 addresses tracing, section 3 addresses 113 security considerations. In section 4 a summary of IAB 114 considerations and how the architecture addresses them is provided. 116 The document is organized as follows: Section 2 introduces the OPES 117 architecture. Section 3 discusses OPES security and privacy 118 considerations. Section 4 addresses IAB considerations for OPES. 119 Section 5 discusses security considerations. Section 6 addresses 120 IANA considerations. Section 7 provides a summary of the 121 architecture and the requirements for interoperability. 123 2. The Architecture 125 The architecture of Open Pluggable Edge Services (OPES) can be 126 described in terms of three interrelated concepts, mainly: 128 o OPES entities: processes operating in the network; 130 o OPES flows: data flows that are cooperatively realized by the 131 OPES entities; and, 133 o OPES rules: these specify when and how to execute OPES services. 135 2.1 OPES Entities 137 An OPES entity is an application that operates on a data flow between 138 a data provider application and a data consumer application. OPES 139 entities can be: 141 o an OPES service application, which analyzes and possibly 142 transforms messages exchanged between the data provider 143 application and the data consumer application; 145 o a data dispatcher, which invokes an OPES service application based 146 on an OPES ruleset and application-specific knowledge. 148 The cooperative behavior of OPES entities introduces additional 149 functionality for each data flow provided that it matches the OPES 150 rules. In the network, OPES entities reside inside OPES processors. 151 In the current work, an OPES processor MUST include a data 152 dispatcher. Furthermore, the data provider and data consumer 153 applications are not considered as OPES entities. 155 In order to provide verifiable system integrity (see section 3.1 on 156 trust domains below), facilitate deployment of end-to-end encryption 157 and data integrity control , OPES processors MUST be: 159 o explicitly addressable at the IP layer by the end user (data 160 consumer application). This requirement does not preclude a chain 161 of OPES processors with the first one in the chain explicitly 162 addressed at the IP layer by the end user (data consumer 163 application). 165 o consented to by either the data consumer or data provider 166 application. The details of this process is beyond the scope of 167 the current work. 169 The OPES architecture is largely independent of the protocol that is 170 used by the data provider application and the data consumer 171 application to exchange data. However, this document selects HTTP 172 [3] as the example for the underlying protocol in OPES flows. 174 2.1.1 Data Dispatcher 176 Data dispatchers include a ruleset that can be compiled from several 177 sources and MUST resolve into an unambiguous result. The combined 178 ruleset enables an OPES processor to determine which service 179 applications to invoke for which data flow. Accordingly, the data 180 dispatcher constitutes an enhanced policy enforcement point, where 181 policy rules are evaluated, service-specific data handlers and state 182 information is maintained, as depicted in Figure 1. 184 +----------+ 185 | callout | 186 | server | 187 +----------+ 188 || 189 || 190 || 191 || 192 +--------------------------+ 193 | +-----------+ || | 194 | | OPES | || | 195 | | service | || | 196 | |application| || | 197 | +-----------+ || | 198 | +----------------------+ | 199 OPES flow <---->| | data dispatcher and | |<----> OPES flow 200 | | policy enforcement | | 201 | +----------------------+ | 202 | OPES | 203 | processor | 204 +--------------------------+ 206 Figure 1: Data Dispatchers 208 The architecture allows for more than one policy enforcement point to 209 be present on an OPES flow. 211 2.2 OPES Flows 213 An OPES flow is a cooperative undertaking between a data provider 214 application, a data consumer application, zero or more OPES service 215 applications, and one or more data dispatchers. 217 Since policies are enforced by data dispatchers, the presence of at 218 least one data dispatcher is required in the OPES flow. 220 data OPES OPES data 221 provider processor A processor N consumer 223 +-----------+ +-----------+ . +-----------+ +-----------+ 224 | data | | OPES | . | OPES | | data | 225 | consumer | | service | . | service | | provider | 226 |application| |application| . |application| |application| 227 +-----------+ +-----------+ . +-----------+ +-----------+ 228 | | | | . | | | | 229 | HTTP | | HTTP | . | HTTP | | HTTP | 230 | | | | . | | | | 231 +-----------+ +-----------+ . +-----------+ +-----------+ 232 | TCP/IP | | TCP/IP | . | TCP/IP | | TCP/IP | 233 +-----------+ +-----------+ . +-----------+ +-----------+ 234 || || || . || || || 235 ================ =====.======== =========== 237 | <----------------- OPES flow -------------------> | 239 Figure 2: An OPES flow 241 Figure 2 depicts two data dispatchers that are present in the OPES 242 flow. The architecture allows for one or more data dispatchers to be 243 present in any flow. 245 2.3 OPES Rules 247 OPES policy regarding services and the data provided to them is 248 determined by a ruleset consisting of OPES rules. The rules consist 249 of a set of conditions and related actions. The ruleset is the 250 superset of all OPES rules on the processor. The OPES ruleset 251 determines which service applications will operate on a data stream. 252 In this model, all data dispatchers are invoked for all flows. 254 In order to ensure predictable behavior, the OPES architecture 255 requires the use of a standardized schema for the purpose of defining 256 and interpreting the ruleset. The OPES architecture does not require 257 a mechanism for configuring a ruleset into a data dispatcher. This 258 is treated as a local matter for each implementation (e.g., through 259 the use of a text editor, secure upload protocol, and so on), as long 260 as such mechanism complies with the requirements set forth in section 261 3. 263 2.4 Callout Servers 265 The evaluation of the OPES ruleset determines which service 266 applications will operate on a data stream. How the ruleset is 267 evaluated is not the subject of the architecture, except to note that 268 it MUST result in the same unambiguous result in all implementations. 270 In some cases it may be useful for the OPES processor to distribute 271 the responsibility of service execution by communicating with one or 272 more callout servers. A data dispatcher invokes the services of a 273 callout server by using the OPES callout protocol (OCP). The 274 requirements for the OCP are given in [6]. The OCP is application- 275 agnostic, being unaware of the semantics of the encapsulated 276 application protocol (e.g., HTTP). However, the data dispatcher MUST 277 incorporate a service aware vectoring capability that parses the data 278 flow according to the ruleset and delivers the data to either the 279 local or remote OPES service application. 281 The general interaction situation is depicted in Figure 3, which 282 illustrates the positions and interaction of different components of 283 OPES architecture. 285 +--------------------------+ 286 | +-----------+ | 287 | | OPES | | 288 | | service | | +---------------+ +-----------+ 289 | |application| | | Callout | | Callout | 290 | +-----------+ | | Server A | | Server X | 291 | || | | +--------+ | | | 292 | +----------------------+ | | | OPES | | | | 293 | | data dispatcher | | | | Service| | | +--------+| 294 | +----------------------+ | | | Appl A | | | | OPES || 295 | || || | | +--------+ | | |Service || 296 | +---------+ +-------+ | | || | | | Appl X || 297 | | HTTP | | | | | +--------+ | ... | +--------|| 298 | | | | OCP |=========| | OCP | | | || | 299 | +---------+ +-------+ | | +--------+ | | +------+ | 300 | | | || | +---------------+ | | OCP | | 301 | | TCP/IP | =======================================| | | 302 | | | | | +------+ | 303 | +---------+ | +-----------+ 304 +--------||-||-------------+ 305 || || 306 +--------+ || || +--------+ 307 |data |== =========================================|data | 308 |producer| |consumer| 309 +--------+ +--------+ 311 Figure 3: Interaction of OPES Entities 313 2.5 Tracing Facility 315 The OPES architecture requires that each data dispatcher provides 316 tracing facilities that allow the appropriate verification of its 317 operation. The OPES architecture requires that tracing be feasible 318 on the OPES flow per OPES processor using in-band annotation. One of 319 those annotations could be a URI with more detailed information on 320 the OPES services being executed in the OPES flow. 322 Providing the ability for in-band annotation MAY require header 323 extensions on the application protocol that is used (e.g., HTTP). 324 However, the presence of an OPES processor in the data request/ 325 response flow SHALL NOT interfere with the operations of non-OPES 326 aware clients and servers. The support of these extensions to the 327 base protocol HTTP is not required by non-OPES clients and servers. 329 OPES processors MUST obey tracing, reporting and notification 330 requirements set by the center of authority in the trust domain to 331 which OPES processor belongs. As part of these requirements OPES 332 processor may be instructed to reject or ignore such requirements 333 that originate from other trust domains. 335 3. Security and Privacy Considerations 337 Each data flow MUST be secured in accordance with several policies. 338 The primary stakeholders are the data consumer and the data provider. 339 The secondary stakeholders are the entities to which they may have 340 delegated their trust. The other stakeholders are the owners of the 341 callout servers. Any of these parties may be participants in the 342 OPES flow. 344 These parties MUST have a model, explicit or implicit, describing 345 their trust policy; which of the other parties are trusted to operate 346 on data, and what security enhancements are required for 347 communication. The trust might be delegated for all data, or it 348 might be restricted to granularity as small as an application data 349 unit. 351 All parties that are involved in enforcing policies MUST communicate 352 the policies to the parties that are involved. These parties are 353 trusted to adhere to the communicated policies. 355 In order to delegate fine-grained trust, the parties MUST convey 356 policy information by implicit contract, by a setup protocol, by a 357 dynamic negotiation protocol, or in-line with application data 358 headers. 360 3.1 Trust Domains 362 The delegation of authority starts at either a data consumer or data 363 provider and moves to more distant entities in a "stepwise" fashion. 364 Stepwise means A delegates to B and B delegates to C and so forth. 365 The entities thus "colored" by the delegation are said to form a 366 trust domain with respect to the original delegating party. Here, 367 "Colored" means that if the first step in the chain is the data 368 provider, then the stepwise delegation "colors" the chain with that 369 data "provider" color. The only colors that are defined are the data 370 "provider" and the data "consumer". Delegation of authority 371 (coloring) propagates from the content producer start of authority or 372 from the content consumer start of authority, that may be different 373 from the end points in the data flow. 375 Figure 4 illustrates administrative domains and out-of-band rules and 376 policy distribution. 378 provider administrative domain consumer administrative domain 379 +------------------------------+ +-------------------------------+ 380 | +--------------+ | | +--------------+ | 381 | |Provider | <- out-of-band rules, -> |Consumer | | 382 | |Administrative|~~>~~~: policies and ~<~|Administrative| | 383 | |Authority | : service authorization : |Authority | | 384 | +--------------+ : | | : +--------------+ | 385 | : : | | : : | 386 | : : | | : : | 387 | +----------+ : | | : +----------+ | 388 | | callout | +---------+ | | +---------+ | callout | | 389 | | server |====| | | | | |====| server | | 390 | +----------+ | | | | | | +----------+ | 391 | | OPES | | | | OPES | | 392 | +----------+ |processor| | | |processor| +----------+ | 393 | | | | | | | | | | | | 394 | | data | | | | | | | | data | | 395 | | provider | | | | | | | | consumer | | 396 | | | +---------+ | | +---------+ +----------+ | 397 | +----------+ || || | | || || +----------+ | 398 | || || || | | || || || | 399 | ============= ================= =========== | 400 | | | | 401 +-------------------------------+ +-------------------------------+ 402 | <----------------- OPES flow -----------------> | 404 Figure 4: OPES administrative domains and policy distribution 406 In order to understand the trust relationships between OPES entities, 407 each is labeled as residing in an administrative domain. Entities 408 associated with a given OPES flow may reside in one or more 409 administrative domains. 411 An OPES processor may be in several trust domains at any time. There 412 is no restriction on whether the OPES processors are authorized by 413 data consumers and/or data providers. The original party has the 414 option of forbidding or limiting redelegation. 416 An OPES processor MUST have a representation of its trust domain 417 memberships that it can report in whole or in part for tracing 418 purposes. It MUST include the name of the party that delegated each 419 privilege to it. 421 3.2 Establishing Trust and Service Authorization 423 The OPES processor will have configuration policy specifying what 424 privileges the callout servers have and how they are to be 425 identified. OPES uses standard protocols for authentication and 426 otherwise security communication with callout servers. 428 An OPES processor will have a trusted method for receiving 429 configuration information such as rules for the data dispatcher, 430 trusted callout servers, primary parties that opt-in or opt-out of 431 individual services, etc. 433 Protocol(s) for policy/rule distribution are out of scope for this 434 document, but the OPES architecture assumes the existence of such a 435 mechanism. 437 Requirements for authorization mechanism are set in a separate 438 document. 440 Certain service requests, positive or negative, may be done in-band 441 (for example OPES service bypass request, e.g. User agent can insert 442 an HTTP header like "Bypass-OPES"). Such requests MUST be 443 authenticated. The way OPES entities will honor such requests is 444 subordinate to the authorization policies effective at that moment. 446 3.3 Callout protocol 448 The determination of whether or not OPES processors will use the 449 measures that are described in the previous section during their 450 communication with callout servers depends on the details of how the 451 primary parties delegated trust to the OPES processors and the trust 452 relationship between the OPES processors and the callout server. If 453 the OPES processors are in a single administrative domain with strong 454 confidentiality guarantees, then encryption may be optional. 455 However, it is recommended that for all cases that encryption and 456 strong authentication be used. 458 If the delegation mechanism names the trusted parties and their 459 privileges in some way that permits authentication, then the OPES 460 processors will be responsible for enforcing the policy and for using 461 authentication as part of that enforcement. 463 The callout servers MUST be aware of the policy governing the 464 communication path. They MUST not, for example, communicate 465 confidential information to auxiliary servers outside the trust 466 domain. 468 A separate security association MUST be used for each channel 469 established between an OPES processor and a callout server. The 470 channels MUST be separate for different primary parties. 472 3.4 Privacy 474 Some data from data consumers is considered "private" or "sensitive", 475 and OPES processors MUST both advise the primary parties of their 476 privacy policy and respect the policies of the primary parties. The 477 privacy information MUST be conveyed on a per-flow basis. This can 478 be accomplished by using current available privacy techniques such as 479 P3P [9] and HTTP privacy capabilities. 481 The callout servers MUST also participate in the handling of private 482 data, and they MUST be prepared to announce their own capabilities 483 and to enforce the policy required by the primary parties. 485 3.5 End-to-end Integrity 487 Digital signature techniques can be used to mark data changes in such 488 a way that a third-party can verify that the changes are or are not 489 consistent with the originating party's policy. This requires an 490 inline manner of specifying policy and its binding to data, a trace 491 of changes and the party making the changes, and strong identities 492 and authentication methods. 494 Strong end-to-end integrity can fulfill some of the functions 495 required by "tracing". 497 4. IAB Architectural and Policy Considerations for OPES 499 This section addresses the IAB considerations for OPES [2] and 500 summarizes how the architecture addresses them. 502 4.1 IAB consideration (2.1) One-party consent 504 The IAB recommends that all OPES services are explicitly authorized 505 by one of the application-layer end-hosts (that is, either the data 506 consumer application or the data provider application). 508 The current work requires that either the data consumer application 509 or the data provider application consent to OPES services. These 510 requirements have been addressed in sections 2 (section 2.1) and 3. 512 4.2 IAB consideration (2.2) IP-layer communications 514 The IAB recommends that OPES processors must be explicitly addressed 515 at the IP layer by the end user (data consumer application). 517 This requirement has been addressed in section 2.1, whereby the 518 architecture requires that OPES processors be addressable at the IP 519 layer by the data consumer application. 521 4.3 IAB consideration (3.1 and 3.2) Notification 523 The IAB recommends that the OPES architecture incorporates tracing 524 facilities. Tracing enables data consumer and data provider 525 applications to detect and respond to actions performed by OPES 526 processors that are deemed inappropriate to the data consumer or data 527 provider applications. 529 Section 3.2 of this document discusses the tracing and notification 530 facilities that must be supported by OPES services. 532 4.4 IAB consideration (3.3) Non-blocking 534 The OPES architecture requires the specification of extensions to 535 HTTP. These extension will provide the data consumer application to 536 request a non-OPES version of the content from the data provider 537 application. These requirements is covered in Section 3.2 539 4.5 IAB consideration (4.1) URI resolution 541 This consideration recommends that OPES documentation must be clear 542 in describing that OPES services as being applied to the result of 543 URI resolution, not as URI resolution itself. 545 This requirement has been addressed in sections 2.5 and 3.2, whereby 546 the proposed architecture requires OPES entities to document all the 547 transformations that have been performed. 549 4.6 IAB consideration (4.2) Reference validity 551 This consideration recommends that all proposed services must define 552 their impact on inter- and intra-document reference validity. 554 This requirement has been addressed in section 2.5 and throughout the 555 document whereby OPES entities is required to document the performed 556 transformations. 558 4.7 IAB consideration (4.3) Application addressing extensions 560 This consideration recommends that any OPES services that cannot be 561 achieved while respecting the above two considerations may be 562 reviewed as potential requirements for Internet application 563 addressing architecture extensions, but must not be undertaken as ad 564 hoc fixes. 566 The current work does not require extensions of the Internet 567 application addressing architecture. 569 4.8 IAB consideration (5.1) Privacy 571 This consideration recommends that the overall OPES framework must 572 provide for mechanisms for end users to determine the privacy 573 policies of OPES intermediaries. 575 This consideration has been addressed in section 3. 577 5. Security Considerations 579 The proposed work has to deal with security from various prospective. 580 There are security and privacy issues that relate to data consumer 581 application, callout protocol and the OPES flow. In [7] threat 582 analysis of OPES entities are discussed. 584 6. IANA Considerations 586 The proposed work will evaluate current protocols for OCP. If the 587 work determines that a new protocol need to be developed, then there 588 may be a need to request new numbers from IANA. 590 7. Summary 592 Although the architecture supports a wide range of cooperative 593 transformation services, it has few requirements for 594 interoperability. 596 The necessary and sufficient elements are specified in the following 597 documents: 599 o the OPES ruleset schema [5] which defines the syntax and semantics 600 of the rules interpreted by a data dispatcher; and, 602 o the OPES callout protocol (OCP) [6] which defines the requirements 603 for the protocol between a data dispatcher and a callout server. 605 Normative References 607 [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", 608 Internet-Draft TBD, May 2002. 610 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 611 Considerations for Open Pluggable Edge Services", RFC 3238, 612 January 2002. 614 [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 615 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 616 HTTP/1.1", RFC 2616, June 1999. 618 [4] OPES working group, "OPES Service Authorization and Enforcement 619 Requirements", Internet-Draft TBD, May 2002. 621 [5] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, 622 May 2002. 624 [6] A. Beck et al., "Requirements for OPES Callout Protocols", 625 Internet-Draft http://www.ietf.org/internet-drafts/ 626 draft-ietf-opes-protocol-reqs-03.txt, December 2002. 628 [7] A. Barbir et al., "Security Threats and Risks for Open Pluggable 629 Edge Services", Internet-Draft http://www.ietf.org/ 630 internet-drafts/draft-ietf-opes-threats-00.txt, October 2002. 632 Informative References 634 [8] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 635 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 636 Waldbusser, "Terminology for Policy-Based Management", RFC 3198, 637 November 2001. 639 [9] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0 640 (P3P1.0) Specification", W3C Recommendation 16 http:// 641 www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002. 643 Authors' Addresses 645 Abbie Barbir 646 Nortel Networks 647 3500 Carling Avenue 648 Nepean, Ontario K2H 8E9 649 Canada 651 Phone: +1 613 763 5229 652 EMail: abbieb@nortelnetworks.com 654 Robin Chen 655 AT&T Labs 656 Room E219, 180 Park Avenue 657 Florham Park, NJ 07932 658 US 660 Phone: +1 973 360 8653 661 EMail: chen@research.att.com 663 Markus Hofmann 664 Bell Labs/Lucent Technologies 665 Room 4F-513 666 101 Crawfords Corner Road 667 Holmdel, NJ 07733 668 US 670 Phone: +1 732 332 5983 671 EMail: hofmann@bell-labs.com 673 Hilarie Orman 674 Purple Streak Development 675 EMail: ho@alum.mit.edu 677 Reinaldo Penno 678 Nortel Networks 679 2305 Mission College Boulevard 680 San Jose, CA 95134 681 US 683 Phone: 684 EMail: rpenno@nortelnetworks.com 686 Appendix A. Acknowledgements 688 This document is the product of OPES WG. Oskar Batuner (Independent 689 consultant) and Andre Beck (Lucent) are additional authors that have 690 contributed to this current document. 692 Earlier versions of this work was done by Gary Tomlinson (The 693 Tomlinson Group) and Michael Condry (Intel). 695 The authors gratefully acknowledge the contributions of: John Morris, 696 Mark Baker, Ian Cooper and Marshall T. Rose. 698 Intellectual Property Statement 700 The IETF takes no position regarding the validity or scope of any 701 intellectual property or other rights that might be claimed to 702 pertain to the implementation or use of the technology described in 703 this document or the extent to which any license under such rights 704 might or might not be available; neither does it represent that it 705 has made any effort to identify any such rights. Information on the 706 IETF's procedures with respect to rights in standards-track and 707 standards-related documentation can be found in BCP-11. Copies of 708 claims of rights made available for publication and any assurances of 709 licenses to be made available, or the result of an attempt made to 710 obtain a general license or permission for the use of such 711 proprietary rights by implementors or users of this specification can 712 be obtained from the IETF Secretariat. 714 The IETF invites any interested party to bring to its attention any 715 copyrights, patents or patent applications, or other proprietary 716 rights which may cover technology that may be required to practice 717 this standard. Please address the information to the IETF Executive 718 Director. 720 Full Copyright Statement 722 Copyright (C) The Internet Society (2002). All Rights Reserved. 724 This document and translations of it may be copied and furnished to 725 others, and derivative works that comment on or otherwise explain it 726 or assist in its implementation may be prepared, copied, published 727 and distributed, in whole or in part, without restriction of any 728 kind, provided that the above copyright notice and this paragraph are 729 included on all such copies and derivative works. However, this 730 document itself may not be modified in any way, such as by removing 731 the copyright notice or references to the Internet Society or other 732 Internet organizations, except as needed for the purpose of 733 developing Internet standards in which case the procedures for 734 copyrights defined in the Internet Standards process must be 735 followed, or as required to translate it into languages other than 736 English. 738 The limited permissions granted above are perpetual and will not be 739 revoked by the Internet Society or its successors or assignees. 741 This document and the information contained herein is provided on an 742 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 743 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 744 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 745 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 746 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Acknowledgement 750 Funding for the RFC Editor function is currently provided by the 751 Internet Society.