summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3835.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3835.txt')
-rw-r--r--doc/rfc/rfc3835.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3835.txt b/doc/rfc/rfc3835.txt
new file mode 100644
index 0000000..4b84d2a
--- /dev/null
+++ b/doc/rfc/rfc3835.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group A. Barbir
+Request for Comments: 3835 R. Penno
+Category: Informational Nortel Networks
+ R. Chen
+ AT&T Labs
+ M. Hofmann
+ Bell Labs/Lucent Technologies
+ H. Orman
+ Purple Streak Development
+ August 2004
+
+
+ An Architecture for Open Pluggable Edge Services (OPES)
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This memo defines an architecture that enables the creation of an
+ application service in which a data provider, a data consumer, and
+ zero or more application entities cooperatively implement a data
+ stream service.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 1]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2 . The Architecture . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. OPES Entities. . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1.1. Data Dispatcher. . . . . . . . . . . . . . . . . 5
+ 2.2. OPES Flows . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3. OPES Rules . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.4. Callout Servers. . . . . . . . . . . . . . . . . . . . . 7
+ 2.5. Tracing Facility . . . . . . . . . . . . . . . . . . . . 8
+ 3. Security and Privacy Considerations . . . . . . . . . . . . . 9
+ 3.1. Trust Domains. . . . . . . . . . . . . . . . . . . . . . 9
+ 3.2. Establishing Trust and Service Authorization . . . . . . 11
+ 3.3. Callout Protocol . . . . . . . . . . . . . . . . . . . . 11
+ 3.4. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 3.5. End-to-end Integrity . . . . . . . . . . . . . . . . . . 12
+ 4. IAB Architectural and Policy Considerations for OPES . . . . . 12
+ 4.1. IAB consideration (2.1) One-party Consent. . . . . . . . 12
+ 4.2. IAB consideration (2.2) IP-Layer Communications. . . . . 13
+ 4.3. IAB consideration (3.1 and 3.2) Notification . . . . . . 13
+ 4.4. IAB consideration (3.3) Non-Blocking . . . . . . . . . . 13
+ 4.5. IAB consideration (4.1) URI Resolution . . . . . . . . . 13
+ 4.6. IAB consideration (4.2) Reference Validity . . . . . . . 13
+ 4.7. IAB consideration (4.3) Application Addressing
+ Extensions . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.8. IAB consideration (5.1) Privacy. . . . . . . . . . . . . 14
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 15
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+ 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
+ 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
+
+1. Introduction
+
+ When supplying a data stream service between a provider and a
+ consumer, the need to provision the use of other application
+ entities, in addition to the provider and consumer, may arise. For
+ example, some party may wish to customize a data stream as a service
+ to a consumer. The customization step might be based on the
+ customer's resource availability (e.g., display capabilities).
+
+ In some cases it may be beneficial to provide a customization service
+ at a network location between the provider and consumer host rather
+ than at one of these endpoints. For certain services performed on
+
+
+
+Barbir, et al. Informational [Page 2]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+ behalf of the end-user, this may be the only option of service
+ deployment. In this case, zero or more additional application
+ entities may participate in the data stream service. There are many
+ possible provisioning scenarios which make a data stream service
+ attractive. The OPES Use Cases and Deployment Scenarios [1] document
+ provides examples of OPES services. The document discusses services
+ that modify requests, services that modify responses, and services
+ that create responses. It is recommended that the document on OPES
+ Use Cases and Deployment Scenarios [1] be read before reading this
+ document.
+
+ This document presents the architectural components of Open Pluggable
+ Edge Services (OPES) that are needed in order to perform a data
+ stream service. The architecture addresses the IAB considerations
+ described in [2]. These considerations are covered in various parts
+ of the document. Section 2.5 addresses tracing; section 3 addresses
+ security considerations. Section 4 provides a summary of IAB
+ considerations and how the architecture addresses them.
+
+ The document is organized as follows: Section 2 introduces the OPES
+ architecture. Section 3 discusses OPES security and privacy
+ considerations. Section 4 addresses IAB considerations for OPES.
+ Section 5 discusses security considerations. Section 6 addresses
+ IANA considerations. Section 7 provides a summary of the
+ architecture and the requirements for interoperability.
+
+2. The Architecture
+
+ The architecture of Open Pluggable Edge Services (OPES) can be
+ described in terms of three interrelated concepts, mainly:
+
+ o OPES entities: processes operating in the network;
+
+ o OPES flows: data flows that are cooperatively realized by the
+ OPES entities; and,
+
+ o OPES rules: these specify when and how to execute OPES services.
+
+2.1. OPES Entities
+
+ An OPES entity is an application that operates on a data flow between
+ a data provider application and a data consumer application. OPES
+ entities can be:
+
+ o an OPES service application, which analyzes and possibly
+ transforms messages exchanged between the data provider
+ application and the data consumer application;
+
+
+
+
+Barbir, et al. Informational [Page 3]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+ o a data dispatcher, which invokes an OPES service application based
+ on an OPES ruleset and application-specific knowledge.
+
+ The cooperative behavior of OPES entities introduces additional
+ functionality for each data flow provided that it matches the OPES
+ rules. In the network, OPES entities reside inside OPES processors.
+ In the current work, an OPES processor MUST include a data
+ dispatcher. Furthermore, the data provider and data consumer
+ applications are not considered as OPES entities.
+
+ To provide verifiable system integrity (see section 3.1 on trust
+ domains below) and to facilitate deployment of end-to-end encryption
+ and data integrity control, OPES processors MUST be:
+
+ o explicitly addressable at the IP layer by the end user (data
+ consumer application). This requirement does not preclude a chain
+ of OPES processors with the first one in the chain explicitly
+ addressed at the IP layer by the end user (data consumer
+ application).
+
+ o consented to by either the data consumer or data provider
+ application. The details of this process are beyond the scope of
+ the current work.
+
+ The OPES architecture is largely independent of the protocol that is
+ used by the data provider application and the data consumer
+ application to exchange data. However, this document selects HTTP
+ [3] as the example for the underlying protocol in OPES flows.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 4]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+2.1.1. Data Dispatcher
+
+ Data dispatchers include a ruleset that can be compiled from several
+ sources and MUST resolve into an unambiguous result. The combined
+ ruleset enables an OPES processor to determine which service
+ applications to invoke for which data flow. Accordingly, the data
+ dispatcher constitutes an enhanced policy enforcement point, where
+ policy rules are evaluated and service-specific data handlers and
+ state information are maintained, as depicted in Figure 1.
+
+ +----------+
+ | callout |
+ | server |
+ +----------+
+ ||
+ ||
+ ||
+ ||
+ +--------------------------+
+ | +-----------+ || |
+ | | OPES | || |
+ | | service | || |
+ | |application| || |
+ | +-----------+ || |
+ | +----------------------+ |
+ OPES flow <---->| | data dispatcher and | |<----> OPES flow
+ | | policy enforcement | |
+ | +----------------------+ |
+ | OPES |
+ | processor |
+ +--------------------------+
+
+ Figure 1: Data Dispatchers
+
+ The architecture allows for more than one policy enforcement point to
+ be present on an OPES flow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 5]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+2.2. OPES Flows
+
+ An OPES flow is a cooperative undertaking between a data provider
+ application, a data consumer application, zero or more OPES service
+ applications, and one or more data dispatchers.
+
+ Since policies are enforced by data dispatchers, the presence of at
+ least one data dispatcher is required in the OPES flow.
+
+ data OPES OPES data
+ consumer processor A processor N provider
+
+ +-----------+ +-----------+ . +-----------+ +-----------+
+ | data | | OPES | . | OPES | | data |
+ | consumer | | service | . | service | | provider |
+ |application| |application| . |application| |application|
+ +-----------+ +-----------+ . +-----------+ +-----------+
+ | | | | . | | | |
+ | HTTP | | HTTP | . | HTTP | | HTTP |
+ | | | | . | | | |
+ +-----------+ +-----------+ . +-----------+ +-----------+
+ | TCP/IP | | TCP/IP | . | TCP/IP | | TCP/IP |
+ +-----------+ +-----------+ . +-----------+ +-----------+
+ || || || . || || ||
+ ================ =====.======== ===========
+
+ | <----------------- OPES flow -------------------> |
+
+ Figure 2: An OPES flow
+
+ Figure 2 depicts two data dispatchers that are present in the OPES
+ flow. The architecture allows for one or more data dispatchers to be
+ present in any flow.
+
+2.3. OPES Rules
+
+ OPES' policy regarding services and the data provided to them is
+ determined by a ruleset consisting of OPES rules. The rules consist
+ of a set of conditions and related actions. The ruleset is the
+ superset of all OPES rules on the processor. The OPES ruleset
+ determines which service applications will operate on a data stream.
+ In this model, all data dispatchers are invoked for all flows.
+
+ In order to ensure predictable behavior, the OPES architecture
+ requires the use of a standardized schema for the purpose of defining
+ and interpreting the ruleset. The OPES architecture does not require
+ a mechanism for configuring a ruleset into a data dispatcher. This
+
+
+
+
+Barbir, et al. Informational [Page 6]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+ is treated as a local matter for each implementation (e.g., through
+ the use of a text editor or a secure upload protocol), as long as
+ such a mechanism complies with the requirements set forth in section
+ 3.
+
+2.4. Callout Servers
+
+ The evaluation of the OPES ruleset determines which service
+ applications will operate on a data stream. How the ruleset is
+ evaluated is not the subject of the architecture, except to note that
+ it MUST result in the same unambiguous result in all implementations.
+
+ In some cases it may be useful for the OPES processor to distribute
+ the responsibility of service execution by communicating with one or
+ more callout servers. A data dispatcher invokes the services of a
+ callout server by using the OPES callout protocol (OCP). The
+ requirements for the OCP are given in [5]. The OCP is application-
+ agnostic, being unaware of the semantics of the encapsulated
+ application protocol (e.g., HTTP). However, the data dispatcher MUST
+ incorporate a service aware vectoring capability that parses the data
+ flow according to the ruleset and delivers the data to either the
+ local or remote OPES service application.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 7]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+ The general interaction situation is depicted in Figure 3, which
+ illustrates the positions and interaction of different components of
+ OPES architecture.
+
+ +--------------------------+
+ | +-----------+ |
+ | | OPES | |
+ | | service | | +---------------+ +-----------+
+ | |application| | | Callout | | Callout |
+ | +-----------+ | | Server A | | Server X |
+ | || | | +--------+ | | |
+ | +----------------------+ | | | OPES | | | |
+ | | data dispatcher | | | | Service| | | +--------+|
+ | +----------------------+ | | | Appl A | | | | OPES ||
+ | || || | | +--------+ | | |Service ||
+ | +---------+ +-------+ | | || | | | Appl X ||
+ | | HTTP | | | | | +--------+ | ... | +--------||
+ | | | | OCP |=========| | OCP | | | || |
+ | +---------+ +-------+ | | +--------+ | | +------+ |
+ | | | || | +---------------+ | | OCP | |
+ | | TCP/IP | =======================================| | |
+ | | | | | +------+ |
+ | +---------+ | +-----------+
+ +--------||-||-------------+
+ || ||
+ +--------+ || || +--------+
+ |data |== =========================================|data |
+ |producer| |consumer|
+ +--------+ +--------+
+
+ Figure 3: Interaction of OPES Entities
+
+2.5. Tracing Facility
+
+ The OPES architecture requires that each data dispatcher provides
+ tracing facilities that allow the appropriate verification of its
+ operation. The OPES architecture requires that tracing be feasible
+ on the OPES flow, per OPES processor, using in-band annotation. One
+ of those annotations could be a URI with more detailed information on
+ the OPES services being executed in the OPES flow.
+
+ Providing the ability for in-band annotation MAY require header
+ extensions on the application protocol that is used (e.g., HTTP).
+ However, the presence of an OPES processor in the data request/
+ response flow SHALL NOT interfere with the operations of non-OPES
+ aware clients and servers. Non-OPES clients and servers need not
+ support these extensions to the base protocol.
+
+
+
+
+Barbir, et al. Informational [Page 8]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+ OPES processors MUST obey tracing, reporting, and notification
+ requirements set by the center of authority in the trust domain to
+ which an OPES processor belongs. As part of these requirements, the
+ OPES processor may be instructed to reject or ignore such
+ requirements that originate from other trust domains.
+
+3. Security and Privacy Considerations
+
+ Each data flow MUST be secured in accordance with several policies.
+ The primary stakeholders are the data consumer and the data provider.
+ The secondary stakeholders are the entities to which they may have
+ delegated their trust. The other stakeholders are the owners of the
+ callout servers. Any of these parties may be participants in the
+ OPES flow.
+
+ These parties MUST have a model, explicit or implicit, describing
+ their trust policy, which of the other parties are trusted to operate
+ on data, and what security enhancements are required for
+ communication. The trust might be delegated for all data, or it
+ might be restricted to granularity as small as an application data
+ unit.
+
+ All parties that are involved in enforcing policies MUST communicate
+ the policies to the parties that are involved. These parties are
+ trusted to adhere to the communicated policies.
+
+ In order to delegate fine-grained trust, the parties MUST convey
+ policy information by implicit contract, by a setup protocol, by a
+ dynamic negotiation protocol, or in-line with application data
+ headers.
+
+3.1. Trust Domains
+
+ The delegation of authority starts at either a data consumer or data
+ provider and moves to more distant entities in a "stepwise" fashion.
+ Stepwise means A delegates to B, and B delegates to C, and so forth.
+ The entities thus "colored" by the delegation are said to form a
+ trust domain with respect to the original delegating party. Here,
+ "Colored" means that if the first step in the chain is the data
+ provider, then the stepwise delegation "colors" the chain with that
+ data "provider" color. The only colors defined are the data
+ "provider" and the data "consumer". Delegation of authority
+ (coloring) propagates from the content producer start of authority or
+ from the content consumer start of authority, which may be different
+ from the end points in the data flow.
+
+
+
+
+
+
+Barbir, et al. Informational [Page 9]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+ Figure 4 illustrates administrative domains, out-of-band rules, and
+ policy distribution.
+
+ provider administrative domain consumer administrative domain
+ +------------------------------+ +-------------------------------+
+ | +--------------+ | | +--------------+ |
+ | |Provider | <- out-of-band rules, -> |Consumer | |
+ | |Administrative|~~>~~~: policies and ~<~|Administrative| |
+ | |Authority | : service authorization : |Authority | |
+ | +--------------+ : | | : +--------------+ |
+ | : : | | : : |
+ | : : | | : : |
+ | +----------+ : | | : +----------+ |
+ | | callout | +---------+ | | +---------+ | callout | |
+ | | server |====| | | | | |====| server | |
+ | +----------+ | | | | | | +----------+ |
+ | | OPES | | | | OPES | |
+ | +----------+ |processor| | | |processor| +----------+ |
+ | | | | | | | | | | | |
+ | | data | | | | | | | | data | |
+ | | provider | | | | | | | | consumer | |
+ | | | +---------+ | | +---------+ +----------+ |
+ | +----------+ || || | | || || +----------+ |
+ | || || || | | || || || |
+ | ============= ================= =========== |
+ | | | |
+ +-------------------------------+ +-------------------------------+
+ | <----------------- OPES flow -----------------> |
+
+ Figure 4: OPES administrative domains and policy distribution
+
+ In order to understand the trust relationships between OPES entities,
+ each is labeled as residing in an administrative domain. Entities
+ associated with a given OPES flow may reside in one or more
+ administrative domains.
+
+ An OPES processor may be in several trust domains at any time. There
+ is no restriction on whether the OPES processors are authorized by
+ data consumers and/or data providers. The original party has the
+ option of forbidding or limiting redelegation.
+
+ An OPES processor MUST have a representation of its trust domain
+ memberships that it can report in whole or in part for tracing
+ purposes. It MUST include the name of the party that delegated each
+ privilege to it.
+
+
+
+
+
+
+Barbir, et al. Informational [Page 10]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+3.2. Establishing Trust and Service Authorization
+
+ The OPES processor will have a configuration policy specifying what
+ privileges the callout servers have and how they are to be
+ identified. OPES uses standard protocols for authentication and
+ other security communication with callout servers.
+
+ An OPES processor will have a trusted method for receiving
+ configuration information, such as rules for the data dispatcher,
+ trusted callout servers, primary parties that opt-in or opt-out of
+ individual services, etc.
+
+ Protocol(s) for policy/rule distribution are out of scope for this
+ document, but the OPES architecture assumes the existence of such a
+ mechanism.
+
+ Requirements for the authorization mechanism are set in a separate
+ document [4].
+
+ Service requests may be done in-band. For example, a request to
+ bypass OPES services could be signalled by a user agent using an HTTP
+ header string "Bypass-OPES". Such requests MUST be authenticated.
+ The way OPES entities will honor such requests is subordinate to the
+ authorization policies effective at that moment.
+
+3.3. Callout Protocol
+
+ The determination of whether or not OPES processors will use the
+ measures that are described in the previous section during their
+ communication with callout servers depends on the details of how the
+ primary parties delegated trust to the OPES processors and the trust
+ relationship between the OPES processors and the callout server.
+ Strong authentication, message authentication codes, and encryption
+ SHOULD be used. If the OPES processors are in a single
+ administrative domain with strong confidentiality and integrity
+ guarantees, then cryptographic protection is recommended but
+ optional.
+
+ If the delegation mechanism names the trusted parties and their
+ privileges in some way that permits authentication, then the OPES
+ processors will be responsible for enforcing the policy and for using
+ authentication as part of that enforcement.
+
+ 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.
+
+
+
+
+Barbir, et al. Informational [Page 11]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+ A separate security association MUST be used for each channel
+ established between an OPES processor and a callout server. The
+ channels MUST be separate for different primary parties.
+
+3.4. Privacy
+
+ Some data from OPES flow endpoints is considered "private" or
+ "sensitive", and OPES processors MUST advise the primary parties of
+ their privacy policy and respect the policies of the primary parties.
+ The privacy information MUST be conveyed on a per-flow basis. This
+ can be accomplished by using current available privacy techniques
+ such as P3P [7] and HTTP privacy capabilities.
+
+ The callout servers MUST also participate in the handling of private
+ data, they MUST be prepared to announce their own capabilities, and
+ enforce the policy required by the primary parties.
+
+3.5. End-to-End Integrity
+
+ Digital signature techniques can be used to mark data changes in such
+ a way that a third-party can verify that the changes are or are not
+ consistent with the originating party's policy. This requires an
+ inline method to specify policy and its binding to data, a trace of
+ changes and the identity of the party making the changes, and strong
+ identification and authentication methods.
+
+ Strong end-to-end integrity can fulfill some of the functions
+ required by "tracing".
+
+4. IAB Architectural and Policy Considerations for OPES
+
+ This section addresses the IAB considerations for OPES [2] and
+ summarizes how the architecture addresses them.
+
+4.1. IAB Consideration (2.1) One-Party Consent
+
+ The IAB recommends that all OPES services be explicitly authorized by
+ one of the application-layer end-hosts (that is, either the data
+ consumer application or the data provider application).
+
+ The current work requires that either the data consumer application
+ or the data provider application consent to OPES services. These
+ requirements have been addressed in sections 2 (section 2.1) and 3.
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 12]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+4.2. IAB Consideration (2.2) IP-Layer Communications
+
+ The IAB recommends that OPES processors must be explicitly addressed
+ at the IP layer by the end user (data consumer application).
+
+ This requirement has been addressed in section 2.1, by the
+ requirement that OPES processors be addressable at the IP layer by
+ the data consumer application.
+
+4.3. IAB Consideration (3.1 and 3.2) Notification
+
+ The IAB recommends that the OPES architecture incorporate tracing
+ facilities. Tracing enables data consumer and data provider
+ applications to detect and respond to actions performed by OPES
+ processors that are deemed inappropriate to the data consumer or data
+ provider applications.
+
+ Section 3.2 of this document discusses the tracing and notification
+ facilities that must be supported by OPES services.
+
+4.4. IAB Consideration (3.3) Non-Blocking
+
+ The OPES architecture requires the specification of extensions to
+ HTTP. These extensions will allow the data consumer application to
+ request a non-OPES version of the content from the data provider
+ application. These requirements are covered in Section 3.2.
+
+4.5. IAB Consideration (4.1) URI Resolution
+
+ This consideration recommends that OPES documentation must be clear
+ in describing OPES services as being applied to the result of URI
+ resolution, not as URI resolution itself.
+
+ This requirement has been addressed in sections 2.5 and 3.2, by
+ requiring OPES entities to document all the transformations that have
+ been performed.
+
+4.6. IAB Consideration (4.2) Reference Validity
+
+ This consideration recommends that all proposed services must define
+ their impact on inter- and intra-document reference validity.
+
+ This requirement has been addressed in section 2.5 and throughout the
+ document whereby OPES entities are required to document the performed
+ transformations.
+
+
+
+
+
+
+Barbir, et al. Informational [Page 13]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+4.7. IAB Consideration (4.3) Application Addressing Extensions
+
+ This consideration recommends that any OPES services that cannot be
+ achieved while respecting the above two considerations may be
+ reviewed as potential requirements for Internet application
+ addressing architecture extensions, but must not be undertaken as ad
+ hoc fixes.
+
+ The current work does not require extensions of the Internet
+ application addressing architecture.
+
+4.8. IAB Consideration (5.1) Privacy
+
+ This consideration recommends that the overall OPES framework must
+ provide for mechanisms for end users to determine the privacy
+ policies of OPES intermediaries.
+
+ This consideration has been addressed in section 3.
+
+5. Security Considerations
+
+ The proposed work has to deal with security from various
+ perspectives. There are security and privacy issues that relate to
+ data consumer application, callout protocol, and the OPES flow. In
+ [6], there is an analysis of the threats against OPES entities.
+
+6. IANA Considerations
+
+ The proposed work will evaluate current protocols for OCP. If the
+ work determines that a new protocol needs to be developed, then there
+ may be a need to request new numbers from IANA.
+
+7. Summary
+
+ Although the architecture supports a wide range of cooperative
+ transformation services, it has few requirements for
+ interoperability.
+
+ The necessary and sufficient elements are specified in the following
+ documents:
+
+ o the OPES ruleset schema, which defines the syntax and semantics of
+ the rules interpreted by a data dispatcher; and,
+
+ o the OPES callout protocol (OCP) [5], which defines the
+ requirements for the protocol between a data dispatcher and a
+ callout server.
+
+
+
+
+Barbir, et al. Informational [Page 14]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+8. References
+
+8.1. Normative References
+
+ [1] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R.
+ Penno, "Open Pluggable Edge Services (OPES) Use Cases and
+ Deployment Scenarios", RFC 3752, April 2004.
+
+ [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
+ Considerations for Open Pluggable Edge Services", RFC 3238,
+ January 2002.
+
+ [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+ Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [4] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman,
+ "Policy, Authorization, and Enforcement Requirements of the Open
+ Pluggable Edge Services (OPES)", RFC 3838, August 2004.
+
+ [5] Beck, A., Hofmann, M., Orman, H., Penno, R., and A. Terzis,
+ "Requirements for Open Pluggable Edge Services (OPES) Callout
+ Protocols", RFC 3836, August 2004.
+
+ [6] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
+ Orman, "Security Threats and Risks for Open Pluggable Edge
+ Services (OPES)", RFC 3837, August 2004.
+
+8.2. Informative References
+
+ [7] Cranor, L. et. al, "The Platform for Privacy Preferences 1.0
+ (P3P1.0) Specification", W3C Recommendation 16
+ http://www.w3.org/TR/2002/REC-P3P-20020416/, April 2002.
+
+9. Acknowledgements
+
+ This document is the product of OPES WG. Oskar Batuner (Independent
+ consultant) and Andre Beck (Lucent) are additional authors that have
+ contributed to this document.
+
+ Earlier versions of this work were done by Gary Tomlinson (The
+ Tomlinson Group) and Michael Condry (Intel).
+
+ The authors gratefully acknowledge the contributions of: John Morris,
+ Mark Baker, Ian Cooper and Marshall T. Rose.
+
+
+
+
+
+
+Barbir, et al. Informational [Page 15]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+10. Authors' Addresses
+
+ Abbie Barbir
+ Nortel Networks
+ 3500 Carling Avenue
+ Nepean, Ontario K2H 8E9
+ Canada
+
+ Phone: +1 613 763 5229
+ EMail: abbieb@nortelnetworks.com
+
+
+ Yih-Farn Robin Chen
+ AT&T Labs - Research
+ 180 Park Avenue
+ Florham Park, NJ 07932
+ US
+
+ Phone: +1 973 360 8653
+ EMail: chen@research.att.com
+
+
+ Markus Hofmann
+ Bell Labs/Lucent Technologies
+ Room 4F-513
+ 101 Crawfords Corner Road
+ Holmdel, NJ 07733
+ US
+
+ Phone: +1 732 332 5983
+ EMail: hofmann@bell-labs.com
+
+
+ Hilarie Orman
+ Purple Streak Development
+
+ EMail: ho@alum.mit.edu
+
+
+ Reinaldo Penno
+ Nortel Networks
+ 600 Technology Park Drive
+ Billerica, MA 01821
+ USA
+
+ EMail: rpenno@nortelnetworks.com
+
+
+
+
+
+Barbir, et al. Informational [Page 16]
+
+RFC 3835 An Architecture for OPES August 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Barbir, et al. Informational [Page 17]
+