From owner-ietf-openproxy@mail.imc.org Thu Aug 1 18:01:22 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17491 for ; Thu, 1 Aug 2002 18:01:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71LYp011044 for ietf-openproxy-bks; Thu, 1 Aug 2002 14:34:51 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g71LYnw11040 for ; Thu, 1 Aug 2002 14:34:50 -0700 (PDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g71LYNR10848; Thu, 1 Aug 2002 17:34:23 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 17:34:23 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75403134085@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'Ian Cooper'" , "'ietf-openproxy@imc.org'" Subject: RE: Comments on Architecture draft (-02) Date: Thu, 1 Aug 2002 17:34:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C239A3.32622320" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C239A3.32622320 Content-Type: text/plain; charset="iso-8859-1" this may had problems (due to size to get into the list) I am reforwording abbie > -----Original Message----- > From: Barbir, Abbie [CAR:1A00:EXCH] > Sent: Thursday, August 01, 2002 9:18 AM > To: Ian Cooper; ietf-openproxy@imc.org > Cc: Barbir, Abbie [CAR:1A00:EXCH] > Subject: RE: Comments on Architecture draft (-02) > > > Ian, > > Thanks for the feedback. > > Here is the plan, > > 1. I will fix the typos. > 2. I will reconsider your objections on the intro. > 3. I will reconsider your suggestions for the Figures. > 4. The use of any rfc language without referencing it is pury > a conincidence. > 5. I will provide the feedback to the callout protocol team. > 5. I will update the draft to -03 ASAP. > > > For every one else, please send your feedback ASAP. > > Regards > Abbie > > > > > > -----Original Message----- > > From: Ian Cooper [mailto:ian@the-coopers.org] > > Sent: Tuesday, July 30, 2002 9:29 AM > > To: ietf-openproxy@imc.org > > Subject: Comments on Architecture draft (-02) > > big SNIP ------_=_NextPart_001_01C239A3.32622320 Content-Type: text/html; charset="iso-8859-1" RE: Comments on Architecture draft (-02)

this may had problems (due to size to get into the list)
I am reforwording

abbie

> -----Original Message-----
> From: Barbir, Abbie [CAR:1A00:EXCH]
> Sent: Thursday, August 01, 2002 9:18 AM
> To: Ian Cooper; ietf-openproxy@imc.org
> Cc: Barbir, Abbie [CAR:1A00:EXCH]
> Subject: RE: Comments on Architecture draft (-02)
>
>
> Ian,
>
> Thanks for the feedback.
>
> Here is the plan,
>
> 1. I will fix the typos.
> 2. I will reconsider your objections on the intro.
> 3. I will reconsider your suggestions for the Figures.
> 4. The use of any rfc language without referencing it is pury
> a conincidence.
> 5. I will provide the feedback to the callout protocol team.
> 5. I will update the draft to -03 ASAP.
>
>
> For every one else, please send your feedback ASAP.
>
> Regards
> Abbie
>
>
>
>
> > -----Original Message-----
> > From: Ian Cooper [mailto:ian@the-coopers.org]
> > Sent: Tuesday, July 30, 2002 9:29 AM
> > To: ietf-openproxy@imc.org
> > Subject: Comments on Architecture draft (-02)
> >
big SNIP

------_=_NextPart_001_01C239A3.32622320-- From owner-ietf-openproxy@mail.imc.org Fri Aug 2 15:30:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02876 for ; Fri, 2 Aug 2002 15:29:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72J4EZ01239 for ietf-openproxy-bks; Fri, 2 Aug 2002 12:04:14 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72J4Dw01235 for ; Fri, 2 Aug 2002 12:04:13 -0700 (PDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72J3vQ03119; Fri, 2 Aug 2002 15:03:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 15:03:57 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540313467F@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'ietf-openproxy@imc.org'" Cc: Markus Hofmann , Marshall Rose , "Abbie Barbir" , "'Ian Cooper'" Subject: [arch-03 draft] Architecture draft (-03) Date: Fri, 2 Aug 2002 15:03:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C23A57.54DF20B0" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C23A57.54DF20B0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A57.54DF20B0" ------_=_NextPart_001_01C23A57.54DF20B0 Content-Type: text/plain; charset="iso-8859-1" hi all, attached is the arch draft -03. I would like feedback from the list first before i submit it as a new ietf draft. I basically have used a lot Ian Cooper feedback to update the draft Baisc work that was done. 1. deleted old figure 1and 4 2. changed the intro in paragraph 1. 3. changed the opes entity section 4. callout section was modified. 5. changed old figure 5. 6. changed section 2.5 7. in section 3 establishing trust changed to recommend strong encryption/authentication always. 8. changed the summary section item 2. please provide feedback. I will send the draft to the ietf list tuesday morning. abbie ------_=_NextPart_001_01C23A57.54DF20B0 Content-Type: text/html; charset="iso-8859-1" RE: Comments on Architecture draft (-02)
hi all,
 
attached is the arch draft -03.
 
I would like feedback from the list first before i submit it as a new ietf draft.
 
I basically have used a lot Ian Cooper feedback to update the draft
 
Baisc work that was done.
1. deleted old  figure 1and 4
2. changed the intro in paragraph 1.
3. changed the opes entity section
4. callout section was modified.
5. changed old figure 5.
6. changed section 2.5
7. in section 3 establishing trust changed to recommend strong encryption/authentication always.
8. changed the summary section item 2.
 
 
please provide feedback. I will send the draft to the ietf list tuesday morning.
 
 
abbie
 
------_=_NextPart_001_01C23A57.54DF20B0-- ------_=_NextPart_000_01C23A57.54DF20B0 Content-Type: text/plain; name="draft-ietf-opes-architecture-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-architecture-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Abbie. Barbir Internet-Draft Nortel = Networks Expires: January 31, 2003 R. = Chen AT&T = Labs M. = Hofmann Bell Labs/Lucent = Technologies H. = Orman Purple Streak = Development R. = Penno Nortel = Networks G. = Tomlinson The Tomlinson = Group August 2, = 2002 An Architecture for Open Pluggable Edge Services (OPES) draft-ietf-opes-architecture-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 31, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines an architecture for a cooperative application service in which a data provider, a data consumer, and zero or more Barbir , et al. Expires January 31, 2003 [Page = 1] Internet-Draft OPES Architecture August = 2002 application entities cooperatively realize a data stream service. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . = 4 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . = 4 2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . = 4 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . = 5 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . = 6 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . = 7 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . = 8 3. Security and Privacy Considerations . . . . . . . . . . . . = 10 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . = 10 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . = 11 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . = 11 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . = 11 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . = 12 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . = 13 References . . . . . . . . . . . . . . . . . . . . . . . . . = 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . = 17 Barbir , et al. Expires January 31, 2003 [Page = 2] Internet-Draft OPES Architecture August = 2002 1. Introduction When supplying a data stream service between a provider and a consumer, the need may arise to provision the use of other application entities, in addition to the provider and consumer. 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 in 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 end-user behalf this may be the only option of service deployment. In this case, one 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. In [1] a description of several scenarios is provided. 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 the various parts of the document, specifically with respect to tracing (Section 2.5) and security considerations (Section 3). The document is organized as follows: Section 2 introduces the OPES architecture. Section 3 discusses security considerations. Section 4 provides a summary of the architecture and the requirements for interoperability. Barbir , et al. Expires January 31, 2003 [Page = 3] Internet-Draft OPES Architecture August = 2002 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 intermediary 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; o a data dispatcher, which invokes an OPES service application = based on OPES ruleset and application-specific knowledge. In the network, OPES entities reside inside OPES processors. The cooperative behavior of OPES entities introduces additional functionality for each data flow provided that it matches the OPES rules. In the current work, the data provider and data consumer = applications are not considered as OPES entities. The OPES architecture is largely independent of the protocol that is used by the OPES = entities to exchange data. However, this document selects HTTP [4] as the example for the underlying protocol in OPES flows. 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, service-specific data handlers and state information is maintained, as depicted in Figure 1. Barbir , et al. Expires January 31, 2003 [Page = 4] Internet-Draft OPES Architecture August = 2002 ---------------------------------------------------------------------= +----------+ | callout | | server | +----------+ || || || || +--------------------------+ | +----------+ || | | | OPES | || | | | service | || | | | appl | || | | +----------+ || | | +----------------------+ | OPES flow <---->| | data dispatcher and | |<----> OPES flow | | policy enforcement | | | +----------------------+ | | OPES | | processor | +--------------------------+ Figure 1: Data Dispatchers = --------------------------------------------------------------------- The architecture allows more than one policy enforcement point to be present on an OPES flow. 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 zero or more data dispatchers. 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. For example, Figure 2 depicts a data flow (also known as an "OPES flow"), that spans two administrative domains. Barbir , et al. Expires January 31, 2003 [Page = 5] Internet-Draft OPES Architecture August = 2002 = --------------------------------------------------------------------- consumer administrative domain provider administrative domain +------------------------------+ = +------------------------------+ | | | = | | data OPES | | OPES data = | | consumer processor | | processor provider = | | | | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | data | | OPES | | | | OPES | | data | = | | | consumer | |service | | | |service | | provider | = | | | appl | | appl | | | | appl | | appl | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | | | | | | | | | | = | | | HTTP | | HTTP | | | | HTTP | | HTTP | = | | | | | | | | | | | | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | = | | +----------+ +--------+ | | +--------+ +----------+ = | | || || || | | || || || = | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | = | +------------------------------+ = +------------------------------+ | <----------------- OPES flow -----------------> | Figure 2: An OPES flow = --------------------------------------------------------------------- Figure 2 depicts two data dispatchers that are present in the OPES flow. However, the architecture allows for zero 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. The communication of data stream elements to an application is performed by data dispatchers. In this model, all data filters are invoked for all flows. In order to ensure predictable behavior, the OPES architecture Barbir , et al. Expires January 31, 2003 [Page = 6] Internet-Draft OPES Architecture August = 2002 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 is treated as a local matter for each implementation (e.g., through the use of a text editor, secure upload protocol, and so on). = Future revisions of the architecture may introduce such a requirement. 2.4 Callout Servers The evaluation of 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 evaluation 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 [7]. The OCP is application- agnostic, being unaware of the semantics of the encapsulated application protocol (e.g., HTTP). However, the OCP must incorporate a service aware vectoring capability that parses the = data flow according to the ruleset and delivers the data to the OPES service application that can be local or remote. In this model, OPES applications may be executed either on the same processor (or even in the same application environment) with the dispatcher or on a different OPES processor through OCP. The = general interaction situation is depicted in Figure 3, which illustrates the positions and interaction of different components of OPES architecture. Barbir , et al. Expires January 31, 2003 [Page = 7] Internet-Draft OPES Architecture August = 2002 = --------------------------------------------------------------------- +--------------------------+ | +----------+ | | | OPES | | | | service | | +---------------+ = +-----------+ | | appl | | |Callout Server | | Callout = | | +----------+ | | A | | Server = | | || | | +--------+ | | X = | | +----------------------+ | | | OPES | | | = | | | data dispatcher | | | | Service| | | = +--------+| | +----------------------+ | | | App2 | | | | OPES = || | || | | +--------+ | | = |Service || | +-------+ | | || | | | AppX = || | +---------+ | | | | +--------+ | ... | = +--------|| | | HTTP | | OCP |=3D=3D=3D=3D=3D=3D=3D=3D=3D| | OCP | = | | || | | +---------| +-------+ | | +--------+ | | = +------+ | | +---------+ || | +---------------+ | | OCP = | | | | | = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | | = +------+ | | | TCP/IP | | | = | =3D=3D=3D=3D=3D| | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OPES =3D=3D=3D=3D=3D=3D | = | | +---------+ | Data Flow = +-----------+ +--------------------------+ Figure 3: Interaction of OPES Entities = --------------------------------------------------------------------- 2.5 Tracing Facility The OPES architecture requires that each data dispatcher to provide 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 transformation that occurred to the data on 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/ Barbir , et al. Expires January 31, 2003 [Page = 8] Internet-Draft OPES Architecture August = 2002 response flow SHALL NOT interfere with the operations of non-OPES aware clients and servers. The support of these extensions to the base protocol HTTP is not required by non-OPES clients and servers. OPES processors must obey tracing, reporting and notification requirements set by the center of authority in the trust domain to which OPES processor belongs. As part of these requirements OPES processor may be instructed to reject or ignore such requirements that originate from other trust domains. Barbir , et al. Expires January 31, 2003 [Page = 9] Internet-Draft OPES Architecture August = 2002 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 that are 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, that may be different from the end points in the data flow. 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 which delegated = each Barbir , et al. Expires January 31, 2003 [Page = 10] Internet-Draft OPES Architecture August = 2002 privilege to it. 3.2 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. If the OPES processors are in a single administrative domain with = strong confidentiality guarantees, then encryption may be optional. However, it is recommended that for all cases that encryption and strong authentication be used. 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. 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.3 Privacy Some data from data consumers is considered "private" or = "sensitive", and OPES processors must both advise the primary parties of the = their privacy policy and respect the policies of the primary parties. The privacy information must be conveyed on a per-flow basis. The callout servers must also participate in handling of private data, and they must be prepared to announce their own capabilities and to enforce the policy required by the primary parties. 3.4 Establishing trust The OPES processor will have configuration policy specifying what privileges the callout servers have and how they are to be identified. This is especially critical for third-party (fourth- party, etc.) callout servers. OPES uses standard protocols for authenticating and otherwise security communication with callout servers. Barbir , et al. Expires January 31, 2003 [Page = 11] Internet-Draft OPES Architecture August = 2002 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. 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 manner of specifying policy and its binding to data, a trace of changes and the party making the changes, and strong identities and authentication methods. Strong end-to-end integrity can fulfill some of the functions required by "tracing". Barbir , et al. Expires January 31, 2003 [Page = 12] Internet-Draft OPES Architecture August = 2002 4. 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 [6] which defines the syntax and = semantics of the rules interpreted by a data dispatcher; and, o the OPES callout protocol (OCP) [7] which defines the = requirements for the protocol between a data dispatcher and a callout server. Barbir , et al. Expires January 31, 2003 [Page = 13] Internet-Draft OPES Architecture August = 2002 References [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet- Draft TBD, May 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC = 3198, November 2001. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [5] OPES working group, "OPES Service Authorization and Enforcement Requirements", Internet-Draft TBD, May 2002. [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, May 2002. [7] A. Beck et al., "Requirements for OPES Callout Protocols", Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf- opes-protocol-reqs-00.txt, May 2002. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir , et al. Expires January 31, 2003 [Page = 14] Internet-Draft OPES Architecture August = 2002 Robin Chen AT&T Labs Room E219, 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 4555 Great America Parkway Santa Clara, CA 95054 US EMail: rpenno@nortelnetworks.com Gary Tomlinson The Tomlinson Group EMail: gary@tomlinsongroup.net Barbir , et al. Expires January 31, 2003 [Page = 15] Internet-Draft OPES Architecture August = 2002 Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Marshall T. Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper. Barbir , et al. Expires January 31, 2003 [Page = 16] Internet-Draft OPES Architecture August = 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Barbir , et al. Expires January 31, 2003 [Page = 17] ------_=_NextPart_000_01C23A57.54DF20B0-- From owner-ietf-openproxy@mail.imc.org Fri Aug 2 16:19:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04769 for ; Fri, 2 Aug 2002 16:19:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72JsDn02597 for ietf-openproxy-bks; Fri, 2 Aug 2002 12:54:13 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72JsCw02593 for ; Fri, 2 Aug 2002 12:54:13 -0700 (PDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72JrS729192; Fri, 2 Aug 2002 15:53:28 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 15:53:28 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754031346FB@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: markus@mhof.com, Marshall Rose , "'ietf-openproxy@imc.org'" , "Abbie Barbir" Subject: Publish Draft: draft-ietf-opes-architecture-03 Date: Fri, 2 Aug 2002 15:53:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C23A5E.41B332B8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C23A5E.41B332B8 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A5E.41B332B8" ------_=_NextPart_001_01C23A5E.41B332B8 Content-Type: text/plain; charset="iso-8859-1" Please publish the following as Publish Draft: draft-ietf-opes-architecture-03 thanks abbie ------_=_NextPart_001_01C23A5E.41B332B8 Content-Type: text/html; charset="iso-8859-1" Publish Draft: draft-ietf-opes-architecture-03

Please publish the following as
Publish Draft: draft-ietf-opes-architecture-03

thanks
abbie

  ------_=_NextPart_001_01C23A5E.41B332B8-- ------_=_NextPart_000_01C23A5E.41B332B8 Content-Type: text/plain; name="draft-ietf-opes-architecture-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-architecture-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Abbie. Barbir Internet-Draft Nortel = Networks Expires: January 31, 2003 R. = Chen AT&T = Labs M. = Hofmann Bell Labs/Lucent = Technologies H. = Orman Purple Streak = Development R. = Penno Nortel = Networks G. = Tomlinson The Tomlinson = Group August 2, = 2002 An Architecture for Open Pluggable Edge Services (OPES) draft-ietf-opes-architecture-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 31, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines an architecture for a cooperative application service in which a data provider, a data consumer, and zero or more Barbir , et al. Expires January 31, 2003 [Page = 1] Internet-Draft OPES Architecture August = 2002 application entities cooperatively realize a data stream service. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . = 4 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . = 4 2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . = 4 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . = 5 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . = 6 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . = 7 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . = 8 3. Security and Privacy Considerations . . . . . . . . . . . . = 10 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . = 10 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . = 11 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . = 11 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . = 11 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . = 12 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . = 13 References . . . . . . . . . . . . . . . . . . . . . . . . . = 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . = 17 Barbir , et al. Expires January 31, 2003 [Page = 2] Internet-Draft OPES Architecture August = 2002 1. Introduction When supplying a data stream service between a provider and a consumer, the need may arise to provision the use of other application entities, in addition to the provider and consumer. 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 in 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 end-user behalf this may be the only option of service deployment. In this case, one 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. In [1] a description of several scenarios is provided. 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 the various parts of the document, specifically with respect to tracing (Section 2.5) and security considerations (Section 3). The document is organized as follows: Section 2 introduces the OPES architecture. Section 3 discusses security considerations. Section 4 provides a summary of the architecture and the requirements for interoperability. Barbir , et al. Expires January 31, 2003 [Page = 3] Internet-Draft OPES Architecture August = 2002 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 intermediary 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; o a data dispatcher, which invokes an OPES service application = based on OPES ruleset and application-specific knowledge. In the network, OPES entities reside inside OPES processors. The cooperative behavior of OPES entities introduces additional functionality for each data flow provided that it matches the OPES rules. In the current work, the data provider and data consumer = applications are not considered as OPES entities. The OPES architecture is largely independent of the protocol that is used by the OPES = entities to exchange data. However, this document selects HTTP [4] as the example for the underlying protocol in OPES flows. 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, service-specific data handlers and state information is maintained, as depicted in Figure 1. Barbir , et al. Expires January 31, 2003 [Page = 4] Internet-Draft OPES Architecture August = 2002 ---------------------------------------------------------------------= +----------+ | callout | | server | +----------+ || || || || +--------------------------+ | +----------+ || | | | OPES | || | | | service | || | | | appl | || | | +----------+ || | | +----------------------+ | OPES flow <---->| | data dispatcher and | |<----> OPES flow | | policy enforcement | | | +----------------------+ | | OPES | | processor | +--------------------------+ Figure 1: Data Dispatchers = --------------------------------------------------------------------- The architecture allows more than one policy enforcement point to be present on an OPES flow. 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 zero or more data dispatchers. 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. For example, Figure 2 depicts a data flow (also known as an "OPES flow"), that spans two administrative domains. Barbir , et al. Expires January 31, 2003 [Page = 5] Internet-Draft OPES Architecture August = 2002 = --------------------------------------------------------------------- consumer administrative domain provider administrative domain +------------------------------+ = +------------------------------+ | | | = | | data OPES | | OPES data = | | consumer processor | | processor provider = | | | | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | data | | OPES | | | | OPES | | data | = | | | consumer | |service | | | |service | | provider | = | | | appl | | appl | | | | appl | | appl | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | | | | | | | | | | = | | | HTTP | | HTTP | | | | HTTP | | HTTP | = | | | | | | | | | | | | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | = | | +----------+ +--------+ | | +--------+ +----------+ = | | || || || | | || || || = | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | = | +------------------------------+ = +------------------------------+ | <----------------- OPES flow -----------------> | Figure 2: An OPES flow = --------------------------------------------------------------------- Figure 2 depicts two data dispatchers that are present in the OPES flow. However, the architecture allows for zero 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. The communication of data stream elements to an application is performed by data dispatchers. In this model, all data filters are invoked for all flows. In order to ensure predictable behavior, the OPES architecture Barbir , et al. Expires January 31, 2003 [Page = 6] Internet-Draft OPES Architecture August = 2002 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 is treated as a local matter for each implementation (e.g., through the use of a text editor, secure upload protocol, and so on). = Future revisions of the architecture may introduce such a requirement. 2.4 Callout Servers The evaluation of 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 evaluation 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 [7]. The OCP is application- agnostic, being unaware of the semantics of the encapsulated application protocol (e.g., HTTP). However, the OCP must incorporate a service aware vectoring capability that parses the = data flow according to the ruleset and delivers the data to the OPES service application that can be local or remote. In this model, OPES applications may be executed either on the same processor (or even in the same application environment) with the dispatcher or on a different OPES processor through OCP. The = general interaction situation is depicted in Figure 3, which illustrates the positions and interaction of different components of OPES architecture. Barbir , et al. Expires January 31, 2003 [Page = 7] Internet-Draft OPES Architecture August = 2002 = --------------------------------------------------------------------- +--------------------------+ | +----------+ | | | OPES | | | | service | | +---------------+ = +-----------+ | | appl | | |Callout Server | | Callout = | | +----------+ | | A | | Server = | | || | | +--------+ | | X = | | +----------------------+ | | | OPES | | | = | | | data dispatcher | | | | Service| | | = +--------+| | +----------------------+ | | | App2 | | | | OPES = || | || | | +--------+ | | = |Service || | +-------+ | | || | | | AppX = || | +---------+ | | | | +--------+ | ... | = +--------|| | | HTTP | | OCP |=3D=3D=3D=3D=3D=3D=3D=3D=3D| | OCP | = | | || | | +---------| +-------+ | | +--------+ | | = +------+ | | +---------+ || | +---------------+ | | OCP = | | | | | = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | | = +------+ | | | TCP/IP | | | = | =3D=3D=3D=3D=3D| | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OPES =3D=3D=3D=3D=3D=3D | = | | +---------+ | Data Flow = +-----------+ +--------------------------+ Figure 3: Interaction of OPES Entities = --------------------------------------------------------------------- 2.5 Tracing Facility The OPES architecture requires that each data dispatcher to provide 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 transformation that occurred to the data on 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/ Barbir , et al. Expires January 31, 2003 [Page = 8] Internet-Draft OPES Architecture August = 2002 response flow SHALL NOT interfere with the operations of non-OPES aware clients and servers. The support of these extensions to the base protocol HTTP is not required by non-OPES clients and servers. OPES processors must obey tracing, reporting and notification requirements set by the center of authority in the trust domain to which OPES processor belongs. As part of these requirements OPES processor may be instructed to reject or ignore such requirements that originate from other trust domains. Barbir , et al. Expires January 31, 2003 [Page = 9] Internet-Draft OPES Architecture August = 2002 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 that are 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, that may be different from the end points in the data flow. 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 which delegated = each Barbir , et al. Expires January 31, 2003 [Page = 10] Internet-Draft OPES Architecture August = 2002 privilege to it. 3.2 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. If the OPES processors are in a single administrative domain with = strong confidentiality guarantees, then encryption may be optional. However, it is recommended that for all cases that encryption and strong authentication be used. 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. 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.3 Privacy Some data from data consumers is considered "private" or = "sensitive", and OPES processors must both advise the primary parties of the = their privacy policy and respect the policies of the primary parties. The privacy information must be conveyed on a per-flow basis. The callout servers must also participate in handling of private data, and they must be prepared to announce their own capabilities and to enforce the policy required by the primary parties. 3.4 Establishing trust The OPES processor will have configuration policy specifying what privileges the callout servers have and how they are to be identified. This is especially critical for third-party (fourth- party, etc.) callout servers. OPES uses standard protocols for authenticating and otherwise security communication with callout servers. Barbir , et al. Expires January 31, 2003 [Page = 11] Internet-Draft OPES Architecture August = 2002 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. 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 manner of specifying policy and its binding to data, a trace of changes and the party making the changes, and strong identities and authentication methods. Strong end-to-end integrity can fulfill some of the functions required by "tracing". Barbir , et al. Expires January 31, 2003 [Page = 12] Internet-Draft OPES Architecture August = 2002 4. 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 [6] which defines the syntax and = semantics of the rules interpreted by a data dispatcher; and, o the OPES callout protocol (OCP) [7] which defines the = requirements for the protocol between a data dispatcher and a callout server. Barbir , et al. Expires January 31, 2003 [Page = 13] Internet-Draft OPES Architecture August = 2002 References [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet- Draft TBD, May 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC = 3198, November 2001. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [5] OPES working group, "OPES Service Authorization and Enforcement Requirements", Internet-Draft TBD, May 2002. [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, May 2002. [7] A. Beck et al., "Requirements for OPES Callout Protocols", Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf- opes-protocol-reqs-00.txt, May 2002. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir , et al. Expires January 31, 2003 [Page = 14] Internet-Draft OPES Architecture August = 2002 Robin Chen AT&T Labs Room E219, 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 4555 Great America Parkway Santa Clara, CA 95054 US EMail: rpenno@nortelnetworks.com Gary Tomlinson The Tomlinson Group EMail: gary@tomlinsongroup.net Barbir , et al. Expires January 31, 2003 [Page = 15] Internet-Draft OPES Architecture August = 2002 Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Marshall T. Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper. Barbir , et al. Expires January 31, 2003 [Page = 16] Internet-Draft OPES Architecture August = 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Barbir , et al. Expires January 31, 2003 [Page = 17] ------_=_NextPart_000_01C23A5E.41B332B8-- From owner-ietf-openproxy@mail.imc.org Fri Aug 2 19:04:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10572 for ; Fri, 2 Aug 2002 19:04:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72McoB11726 for ietf-openproxy-bks; Fri, 2 Aug 2002 15:38:50 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72Mcnw11721 for ; Fri, 2 Aug 2002 15:38:49 -0700 (PDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g72MamuB033193; Fri, 2 Aug 2002 18:36:48 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g72McYo52531; Fri, 2 Aug 2002 18:38:34 -0400 (EDT) Received: from bell-labs.com (granka-pcho [135.180.161.126]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA15635; Fri, 2 Aug 2002 18:38:33 -0400 (EDT) Message-ID: <3D4B0855.8090803@bell-labs.com> Date: Fri, 02 Aug 2002 18:31:49 -0400 From: Andre Beck Organization: Bell Labs Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,de,es MIME-Version: 1.0 To: Internet-Drafts CC: Markus Hofmann , Marshall Rose , ietf-openproxy Subject: draft-ietf-opes-protocol-reqs-02 Content-Type: multipart/mixed; boundary="------------090303010204030202020200" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------090303010204030202020200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached OPES WG draft as "draft-ietf-opes-protocol-reqs-02". --------------090303010204030202020200 Content-Type: text/plain; name="draft-ietf-opes-protocol-reqs-02.txt" Content-Disposition: inline; filename="draft-ietf-opes-protocol-reqs-02.txt" Content-Transfer-Encoding: 7bit Open Pluggable Edge Services A. Beck Internet-Draft M. Hofmann Expires: January 31, 2003 Lucent Technologies H. Orman Purple Streak Development R. Penno Nortel Networks A. Terzis Individual Consultant August 2, 2002 Requirements for OPES Callout Protocols draft-ietf-opes-protocol-reqs-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 31, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services [1]. The requirements are intended to help evaluating possible protocol candidates and to guide the development of such protocols. Beck, et al. Expires January 31, 2003 [Page 1] Internet-Draft Requirements for OPES Callout Protocols August 2002 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Functional Requirements . . . . . . . . . . . . . . . . . . 5 3.1 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5 3.2 Callout Channels . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Congestion and Flow Control . . . . . . . . . . . . . . . . 6 3.5 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 6 3.6 Operation in NAT Environments . . . . . . . . . . . . . . . 7 3.7 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 7 3.8 Multiple OPES Processors . . . . . . . . . . . . . . . . . . 7 3.9 Support for Different Application Protocols . . . . . . . . 7 3.10 Capability and Parameter Negotiations . . . . . . . . . . . 7 3.11 Meta Data and Instructions . . . . . . . . . . . . . . . . . 8 3.12 Asynchronous Message Exchange . . . . . . . . . . . . . . . 9 3.13 Message Segmentation . . . . . . . . . . . . . . . . . . . . 9 4. Performance Requirements . . . . . . . . . . . . . . . . . . 11 4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11 5. Security Requirements . . . . . . . . . . . . . . . . . . . 12 5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12 5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12 5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12 5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 Beck, et al. Expires January 31, 2003 [Page 2] Internet-Draft Requirements for OPES Callout Protocols August 2002 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Beck, et al. Expires January 31, 2003 [Page 3] Internet-Draft Requirements for OPES Callout Protocols August 2002 2. Introduction The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The execution of such services is governed by a set of rules installed on the OPES processor. The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [1], an OPES processor communicates with and invokes services on a callout server by using a callout protocol. This document presents the requirements for such a protocol. The requirements in this document are divided into three categories - functional requirements, performance requirements, and security requirements. Each requirement is presented as one or more statements, followed by brief explanatory material as appropriate. Beck, et al. Expires January 31, 2003 [Page 4] Internet-Draft Requirements for OPES Callout Protocols August 2002 3. Functional Requirements 3.1 Callout Transactions The OPES callout protocol MUST enable an OPES processor and a callout server to perform callout transactions with the purpose of exchanging partial or complete application-level protocol messages (or modifications thereof). More specifically, the callout protocol MUST enable an OPES processor to forward a partial or complete application message to a callout server so that one or more OPES services can process the forwarded application message (or parts thereof). The result of the service operation may be a modified application message. The callout protocol MUST therefore enable the callout server to return a modified application message or the modified parts of an application message to the OPES processor. A callout transaction is defined as a message exchange between an OPES processor and a callout server consisting of a callout request and a callout response. Both, the callout request as well as the callout response, MAY each consist of one or more callout protocol messages, i.e. a series of protocol messages. Callout transactions are always initiated by a callout request from an OPES processor and typically terminated by a callout response from a callout server. The OPES callout protocol MUST, however, also allow either endpoint of a callout transaction to terminate a callout transaction prematurely, i.e. before a callout request or response has been completely received by the corresponding endpoint. The callout protocol MAY provide an explicit (e.g. through a termination message) or implicit (e.g. through a connection tear-down) mechanism to terminate a callout transaction prematurely. Such a mechanism MUST ensure, however, that a premature termination of a callout transaction does not result in the loss of application message data. A premature termination of a callout transaction is required to support OPES services which may terminate even before they have processed the entire application message. Content analysis services, for example, may be able to classify a Web object after having processed just the first few bytes of a Web object. The callout protocol MUST further enable a callout server to report back to the OPES processor the result of a callout transaction, e.g. in the form of a status code. 3.2 Callout Channels The OPES callout protocol MUST enable an OPES processor and a callout server to perform multiple callout transactions over a callout Beck, et al. Expires January 31, 2003 [Page 5] Internet-Draft Requirements for OPES Callout Protocols August 2002 channel. A callout channel is defined as a logical connection at the application-layer between an OPES processor and a callout server. Callout channels MUST always be established by an OPES processor. A callout channel MAY be closed by either endpoint of the callout channel provided that all callout transactions associated with the channel have terminated. A callout channel MAY have certain parameters associated with it, for example parameters that control the fail-over behavior of channel endpoints. Callout channel parameters MAY be negotiated between OPES processors and callout servers (see Section 3.10). 3.3 Reliability The OPES callout protocol MUST be able to provide ordered reliability for the communication between OPES processor and callout server. Additionally, the callout protocol SHOULD be able to provide unordered reliability. In order to satisfy the reliability requirements, the callout protocol MAY specify that it must be used with a lower-level transport protocol which provides ordered reliability at the transport-layer. 3.4 Congestion and Flow Control The OPES callout protocol MUST ensure that congestion and flow control mechanisms are applied on all callout transactions. For this purpose, the callout protocol MAY specify callout protocol-specific mechanisms or refer to a lower-level transport protocol and discuss how its mechanisms provide for congestion and flow control. 3.5 Support for Keep-Alive Mechanism The OPES callout protocol MUST provide an optional keep-alive mechanism which, if used, would allow both endpoints of a callout channel to detect a failure of the other endpoint even in the absence of callout transactions. The callout protocol MAY specify that keep- alive messages be exchanged over existing callout channel connections or a separate connection between OPES processor and callout server. The detection of a callout server failure may enable an OPES processor to establish a channel connection with a stand-by callout server so that future callout transactions do not result in the loss of application message data. The detection of the failure of an OPES processor may enable a callout server to release resources which would otherwise not be available for callout transactions with other Beck, et al. Expires January 31, 2003 [Page 6] Internet-Draft Requirements for OPES Callout Protocols August 2002 OPES processors. 3.6 Operation in NAT Environments The OPES protocol SHOULD be NAT-friendly, i.e. its operation should not be compromised by the presence of one or more NAT devices in the path between an OPES processor and a callout server. 3.7 Multiple Callout Servers The OPES callout protocol MUST allow an OPES processor to simultaneously communicate with more than one callout server. In larger networks, OPES services are likely to be hosted by different callout servers. Therefore, an OPES processor will likely have to communicate with multiple callout servers. The protocol design MUST enable an OPES processor to do so. 3.8 Multiple OPES Processors The OPES callout protocol MUST allow a callout server to simultaneously communicate with more than one OPES processor. The protocol design MUST support a scenario in which multiple OPES processors use the services of a single callout server. 3.9 Support for Different Application Protocols The OPES callout protocol MUST be application protocol-agnostic, i.e. it MUST not make any assumptions about the characteristics of the application-layer protocol used on the data path between data provider and data consumer. The OPES entities on the data path may use different application- layer protocols, including, but not limited to, HTTP [3] and RTP [4]. It would be desirable to be able to use the same OPES callout protocol for any such application-layer protocol. 3.10 Capability and Parameter Negotiations The OPES callout protocol MUST support the negotiation of capabilities and callout channel parameters between an OPES processor and a callout server. This implies that the OPES processor and the callout server MUST be able to exchange their capabilities and preferences and engage into a deterministic negotiation process at the end of which the two endpoints have either agreed on the capabilities and parameters to be used for future callout channel transactions or determined that their capabilities are incompatible. Beck, et al. Expires January 31, 2003 [Page 7] Internet-Draft Requirements for OPES Callout Protocols August 2002 Capabilities and parameters that could be negotiated between an OPES processor and a callout server include (but are not limited to): callout protocol version, transport-layer protocol, fail-over behavior, heartbeat rate for keep-alive messages, security-related parameters etc. Channel parameters may also pertain to the characteristics of OPES callout services if, for example, callout channels are associated with one or more specific OPES services. An OPES service-specific parameter may, for example, specify which parts of an application message an OPES service requires for its operation. Callout channel parameters MUST be negotiated on a per-callout channel basis and before any callout transactions are performed over the corresponding channel. Other parameters and capabilities, such as the fail-over behavior, MAY be negotiated between the two endpoints independently of callout channels. The parties to a callout protocol MAY use callout channels to negotiate all or some of their capabilities and parameters. Alternatively, a separate control connection MAY be used for this purpose. 3.11 Meta Data and Instructions The OPES callout protocol MUST provide a mechanism for the endpoints of a particular callout transaction to include in callout requests and responses meta data and instructions for the OPES processor or callout server. Specifically, the callout protocol MUST enable an OPES processor to include information about the forwarded application message in a callout request, e.g. in order to specify the type of the forwarded application message or to specify what part(s) of the application message are forwarded to the callout server. Likewise, the callout server MUST be able to include information about the returned application message. The OPES processor MUST further be able to include an ordered list of one or more uniquely specified OPES services which are to be performed on the forwarded application message in the specified order. However, as the callout protocol MAY also choose to associate callout channels with specific OPES services, there may not be a need to identify OPES service on a per-callout transaction basis. Additionally, the OPES callout protocol MUST allow the callout server to indicate to the OPES processor the cacheability of callout responses. This implies that callout responses may have to carry Beck, et al. Expires January 31, 2003 [Page 8] Internet-Draft Requirements for OPES Callout Protocols August 2002 cache-control instructions for the OPES processor. The OPES callout protocol MUST further enable the OPES processor to indicate to the callout server if it has kept a local copy of the forwarded application message (or parts thereof). This information enables the callout server to determine whether the forwarded application message must be returned to the OPES processor even it has not been modified by an OPES service. The OPES callout protocol MUST also allow OPES processors to comply with the tracing requirements of the OPES architecture as laid out in [1] and [5]. This implies that the callout protocol MUST enable a callout server to convey to the OPES processor information about the OPES service operations performed on the forwarded application message. 3.12 Asynchronous Message Exchange The OPES callout protocol MUST support an asynchronous message exchange between an OPES processor and a callout server. In order to allow asynchronous processing on the OPES processor and callout server, it MUST be possible to separate request issuance from response processing. The protocol MUST therefore allow multiple outstanding requests and provide a method to correlate responses to requests. Additionally, the callout protocol MUST enable a callout server to respond to a callout request before it has received the entire request. 3.13 Message Segmentation The OPES callout protocol MUST allow an OPES processor to forward an application message to a callout server in a series of smaller message fragments. The callout protocol MUST further enable the receiving callout server to assemble the fragmented application message. Likewise, the callout protocol MUST enable a callout server to return an application message to an OPES processor in a series of smaller message fragments. The callout protocol MUST enable the receiving OPES processor to assemble the fragmented application message. Depending on the application-layer protocol used on the data path, application messages may be very large in size (for example in the case of audio/video streams) or of unknown size. In both cases, the OPES processor has to initiate a callout transaction before it has Beck, et al. Expires January 31, 2003 [Page 9] Internet-Draft Requirements for OPES Callout Protocols August 2002 received the entire application message to avoid long delays for the data consumer. The OPES processor MUST therefore be able to forward fragments or chunks of an application message to a callout server as it receives them from the data provider or consumer. Likewise, the callout server MUST be able to process and return application message fragments as it receives them from the OPES processor. Beck, et al. Expires January 31, 2003 [Page 10] Internet-Draft Requirements for OPES Callout Protocols August 2002 4. Performance Requirements 4.1 Protocol Efficiency The OPES callout protocol SHOULD be efficient in that it minimizes the additionally introduced latency, for example by minimizing the protocol overhead. As OPES callout transactions introduce additional latency to application protocol transactions on the data path, callout protocol efficiency is crucial. Beck, et al. Expires January 31, 2003 [Page 11] Internet-Draft Requirements for OPES Callout Protocols August 2002 5. Security Requirements In the absence of any security mechanisms, sensitive information might be communicated between the OPES processor and the callout server in violation of either endpoint's security and privacy policy through misconfiguration or a deliberate insider attack. By using strong authentication, message encryption, and integrity checks, this threat can be minimized to a smaller set of insiders and/or operator configuration errors. The OPES processor and the callout servers SHOULD have enforceable policies that limit the parties they communicate with, that determine the protections to use based on identities of the endpoints and other data (such as enduser policies). In order to enforce the policies, they MUST be able to authenticate the callout protocol endpoints using cryptographic methods. 5.1 Authentication, Confidentiality, and Integrity The parties to the callout protocol MUST have a sound basis for binding authenticated identities to the protocol endpoints, and they MUST verify that these identities are consistent with their security policies. The OPES callout protocol MUST provide for message authentication, confidentiality, and integrity between the OPES processor and the callout server. It MUST provide mutual authentication. For this purpose, the callout protocol SHOULD use existing security mechanisms. The callout protocol specification is not required to specify the security mechanisms, but it MAY instead refer to a lower- level security protocol and discuss how its mechanisms are to be used with the callout protocol. 5.2 Hop-by-Hop Confidentiality If end-to-end encryption is a requirement for the content path, then this confidentiality MUST be extended to the communication between the callout servers and the OPES processor. In order to minimize data exposure, the callout protocol MUST use a different encryption key for each encrypted content stream. 5.3 Operation Across Un-trusted Domains The OPES callout protocol MUST operate securely across un-trusted domains between the OPES processor and the callout server. If the communication channels between the OPES processor and callout server cross outside of the organization taking responsibility for Beck, et al. Expires January 31, 2003 [Page 12] Internet-Draft Requirements for OPES Callout Protocols August 2002 the OPES services, then endpoint authentication and message protection (confidentiality and integrity) MUST be used. 5.4 Privacy Any communication carrying information relevant to privacy policies MUST protect the data using encryption. Beck, et al. Expires January 31, 2003 [Page 13] Internet-Draft Requirements for OPES Callout Protocols August 2002 6. Security Considerations The security requirements for the OPES callout protocol are discussed in Section 5. Beck, et al. Expires January 31, 2003 [Page 14] Internet-Draft Requirements for OPES Callout Protocols August 2002 References [1] Barbir, A., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opes-architecture-03 (work in progress), August 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [5] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. Authors' Addresses Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 US EMail: abeck@bell-labs.com Markus Hofmann Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com Beck, et al. Expires January 31, 2003 [Page 15] Internet-Draft Requirements for OPES Callout Protocols August 2002 Hilarie Orman Purple Streak Development EMail: ho@alum.mit.edu URI: http://www.purplestreak.com Reinaldo Penno Nortel Networks 2305 Mission College Boulevard San Jose, CA 95134 US EMail: rpenno@nortelnetworks.com Andreas Terzis Individual Consultant 150 Golf Course Dr. Rohnert Park, CA 94928 US Phone: +1 707 586 8864 EMail: aterzis@sbcglobal.net Beck, et al. Expires January 31, 2003 [Page 16] Internet-Draft Requirements for OPES Callout Protocols August 2002 Appendix A. Acknowledgments This document is based in parts on previous work by Anca Dracinschi Sailer, Volker Hilt, and Rama R. Menon. The authors would like to thank the participants of the OPES WG for their comments on this draft. Beck, et al. Expires January 31, 2003 [Page 17] Internet-Draft Requirements for OPES Callout Protocols August 2002 Appendix B. Change Log Changes from draft-ietf-opes-protocol-reqs-01.txt o Reworded and clarified several statements of the draft Changes from draft-ietf-opes-protocol-reqs-00.txt o Aligned terminology with [1] o Clarified in Section 3.11 that OCP requests not only have to identify one or more OPES services, but also the order in which the services are to be executed o Removed requirement from Section 4.1 that OCP must satisfy performance requirements of the application-layer protocol used between data consumer and provider Beck, et al. Expires January 31, 2003 [Page 18] Internet-Draft Requirements for OPES Callout Protocols August 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beck, et al. Expires January 31, 2003 [Page 19] --------------090303010204030202020200-- From owner-ietf-openproxy@mail.imc.org Tue Aug 6 01:45:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16890 for ; Tue, 6 Aug 2002 01:45:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7654ab00580 for ietf-openproxy-bks; Mon, 5 Aug 2002 22:04:36 -0700 (PDT) Received: from bachelor.softi.com ([65.206.206.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7654Rw00576 for ; Mon, 5 Aug 2002 22:04:35 -0700 (PDT) Received: from solitude.mchenry.net ([65.206.206.22]) by bachelor.softi.com (8.9.3/8.9.1) with ESMTP id WAA07534; Mon, 5 Aug 2002 22:03:54 -0700 Message-Id: <5.1.1.6.2.20020805220051.03f0ceb8@pop3.norton.antivirus> X-Sender: stephen/mail.mchenry.net@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 05 Aug 2002 22:02:57 -0700 To: "'internet-drafts@ietf.org'" From: Stephen McHenry Subject: Publish Draft: draft-ietf-opes-scenarios-01 Cc: markus@mhof.com, Marshall Rose , "'ietf-openproxy@imc.org'" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_269300533==_" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=====================_269300533==_ Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_269300533==.REL" --=====================_269300533==.REL Content-Type: multipart/alternative; boundary="=====================_269300543==.ALT" --=====================_269300543==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Please publish the following as Publish Draft: draft-ietf-opes-scenarios-01 thanks Stephen stephen@mchenry.net us-flag-small.jpg --=====================_269300543==.ALT Content-Type: text/html; charset="us-ascii" Please publish the following as
Publish Draft: draft-ietf-opes-scenarios-01

thanks

Stephen

stephen@mchenry.net
us-flag-small.jpg
--=====================_269300543==.ALT-- --=====================_269300533==.REL Content-Type: image/jpeg; name="us-flag-small.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <5.1.1.6.2.20020805220051.03f0ceb8@pop3.norton.antivirus.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="us-flag-small.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QgKUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAABOEJJTQQKAAAAAAAB AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9m ZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4 AAAAAABwAAD/////////////////////////////A+gAAAAA//////////////////////////// /wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////////// A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAABOEJJTQQMAAAA AAZ5AAAAAQAAAEgAAAAoAAAA2AAAIcAAAAZdABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA/+4ADkFk b2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwM DBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAKABIAwEiAAIRAQMRAf/dAAQABf/E AT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcI CQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMH JZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaG lqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEU obFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A5Vm42MHsNhDd tZfFbgWu3Ptt9Zvp2/R9ijLPTJDz6ctl5j1A/Y47G1er/M+p/hf/AFUpVtd7a/SJL9jvsvuiz2P/ AE+4O9v/AJmnLyWiz1HOADWfaodLf0bm/Zdu76H+D3Lvr1+g/l/L/wAccjTstruI9vq7CfT3/o9v p7vUFvrf0j8/0v8ATf8AbKvdBpw8jqNVWXlHFw3+oHZMxZowODH177Nte/6HtVLa6PS9I6NL/svu gfog77Vu3fS2/pf/AFGr3Qr8arqlWRmYruo0fpA4QZsPptAZsdub+g+mqvxA/wBC5i9vZyb7fJL+ X/fs/JX975fhvi93Hw8HDx37kPk4/wBXxf3nqP2J9T//AJ4LPvH/AJFL9ifU/wD+eCz7x/5FT/bP 1a/+dp/+b/sS/bP1a/8Anaf/AJv+xefej+p/4491fNd+a+3k2H7E+p//AM8Fn3j/AMil+xPqf/8A PBZ94/8AIqf7Z+rX/wA7T/8AN/2Jftn6tf8AztP/AM3/AGJej+p/44q+a7819vJof+b31J/8vXfc P/IJI37Z+rX/AM7T/wDN/wBiSXo/qf8AjieLm+/N/wCNyb//0Kjf8X/1pEMPT5qO0vb69G4uALdz LdfTbud/Npf8wvrcfccFnqgBod6lG3YGmrb6U+6z/hf/AEYt79i9J/8Ans/8EH/pdL9i9J/+ez/w Qf8ApdaX/KTnP8zh+0/+rW3/AKB5b/xVl/8AabN/3jhf8wPrTHp/s/8AQxIb69G7fs2b/V+l6fqe /wBH/wBWq50f6p/XTpnUGdQow62ZNYeN7rKiwhzfSDRTW4e76XuWj+xek/8Az2f+CD/0ul+xek// AD2f+CD/ANLqPN/xg5vLinilixRGSMsZlGXrqY4ZV+s+Zfi+CctjyQyfeJz4JRnwz5bNKEuA8XDP 0fK6Xrf4yv8AQY33s/8ASiXrf4yv9Bjfez/0os39i9J/+ez/AMEH/pdL9i9J/wDns/8ABB/6XWP6 u8v/AAyDqcOD93B/7Q8z/wB86Xrf4yv9Bjfez/0ol63+Mr/QY33s/wDSizf2L0n/AOez/wAEH/pd L9i9J/8Ans/8EH/pdL1d5f8AhkFcOD93B/7Q8z/3zpet/jK/0GN97P8A0oks39i9J/8Ans/8EH/p dJL1d5f+GQVw4P3cH/tDzP8A3z//0bf7W+of/lLf+P8A6XS/a31D/wDKW/8AH/0uvH0lT9X+r/5j 1n6j/wAr/wD26fYP2t9Q/wDylv8Ax/8AS6X7W+of/lLf+P8A6XXj6SXq/wBX/wAxX6j/AMr/AP26 fYP2t9Q//KW/8f8A0ul+1vqH/wCUt/4/+l14+kl6v9X/AMxX6j/yv/8Abp9g/a31D/8AKW/8f/S6 X7W+of8A5S3/AI/+l14+kl6v9X/zFfqP/K//ANun2D9rfUP/AMpb/wAf/S6S8fSS9X+r/wCYr9R/ 5X/+3T//2QA4QklNBAYAAAAAAAcAAgAAAAEBAP/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAA AG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAAA AAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJY WVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAA iHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQw AAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0 IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYx OTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAA AAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAA AAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAA AAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3Vy IHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3Vy IHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2Ug Vmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZp ZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA dmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dt ZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAA BAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEA hgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZ AR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB 6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1 AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgE VQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2 BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH +AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9 ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM 8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/s EAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MT YxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcd F0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsb YxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/q IBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNol CSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpo KpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUw bDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjau Nuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9 oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTO RRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJM uk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1Tb VShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhd yV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmbo Zz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw 4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsE e2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauG DoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/ kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPed ZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mp qhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm2 8Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRR xM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/S wdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE 4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw 5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////u AA5BZG9iZQBkgAAAAAH/2wCEAAgGBgYGBggGBggMCAcIDA4KCAgKDhANDQ4NDRARDAwMDAwMEQwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBCQgICQoJCwkJCw4LDQsOEQ4ODg4REQwMDAwMEREM DAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACgASAMBIgACEQEDEQH/3QAE AAX/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgME BQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMW YvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1 hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp +So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB 0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SU pLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlp eYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AOewy3DT2wLRm5aOMxwGY/VpEMbl pLib119OfZf3dU+L+X7LJ+sv1XkLmU23JedwW/0oS+kzemkPrfFbep/u3j/1TxS3iY+haC0YmZYZ RpIZ+N1+6kP1szBv3ZX7Xp5fq1jS7+tOQgSH9McX5R/6Ow+oiHl8S/sernrxO5odBy+z+d/vv+S3 0YsBxln9VhyT62IiTb+t/ooi+rhvVWb16/Wq/H6X+/f+RWG/lGKwvdUS31HUns9KdZq6g78bjkqR tweL1JFWPn/dtw+Ll9vCgxHi1n9VaoUz/obk/FR9VDfX/W5fap+89HDnyrdWUOuLqGo2D69alZke fiwaciOICP0WLBfq9eXLNf2wQey9ZYFflcnPl9Eq5H7pS/oeL9WLK0HF+c0/DxcXiwrg4eO+IfTx +ji/rM6/w5+X/wD1OU3/AAQ/5pzf4c/L/wD6nKb/AIIf804p/iHyZ/1Isv8AyLH9M3+IfJn/AFIs v/Isf0zx793/ALV8sj3t63v1v+m0an/hz8v/APqcpv8Agh/zTm/w5+X/AP1OU3/BD/mnFP8AEPkz /qRZf+RY/pm/xD5M/wCpFl/5Fj+mP7v/AGr5ZFvW9+t/02jUP8Lfl1/1N8n3r/zTmxf/ABD5M/6k WX/kWP6Zsf3f+1fLIni13frv9NpH/9ArT8o/Oq8ITpCGzIRriL65b+o8qKy80mKlokLPy9L4sv8A 5VV+YRAmOmQG9QCJJvWtfTEIjMXAwceLSb/3xPP/AGfx5Lv8NaF/5cNv+Ry/9V83+GtC/wDLht/y OX/qvm7/ANGnaXM6fTH3kn5/vev8X852v8g6X/lLy/8AXLm/4liJ/KXzsVNt+iE+pbusP1y39QTm L0/U9fjzMfMep6P2f2f+LMN/LfkP8xtB1Ua3Dp9uupKkieqZoPSKsqRqggj4BWAVvj5Yb/4a0L/y 4bf8jl/6r5v8NaF/5cNv+Ry/9V8p1Ptb2hqMGXTzwYIxywljMoyImBMVIgnJL1M8XYulx5IZPzM5 8EhLhnpc5hKv4ZCvpTv6x+cv/LJY/fH/ANVM31j85f8Alksfvj/6qYSf4a0L/wAuG3/I5f8Aqvm/ w1oX/lw2/wCRy/8AVfObuffP/lbB23Dpv5mm/wCuDUf8Unf1j85f+WSx++P/AKqZvrH5y/8ALJY/ fH/1Uwk/w1oX/lw2/wCRy/8AVfN/hrQv/Lht/wAjl/6r43Pvn/ytgvDpv5mm/wCuDUf8Unf1j85f +WSx++P/AKqZsJP8NaF/5cNv+Ry/9V82Nz75/wDK2C8Om/mab/rg1H/FP//RMP07+V3/AFK139x/ 6r5v07+V3/UrXf3H/qvnm/Nms9f+0/7B7r/Bf+1n/wBfL6Q/Tv5Xf9Std/cf+q+b9O/ld/1K139x /wCq+eb82Pr/ANp/2C/4L/2s/wDr5fSH6d/K7/qVrv7j/wBV836d/K7/AKla7+4/9V8835sfX/tP +wX/AAX/ALWf/Xy+kP07+V3/AFK139x/6r5v07+V3/UrXf3H/qvnm/Nj6/8Aaf8AYL/gv/az/wCv l9Ifp38rv+pWu/uP/VfNnm/Nj6/9p/2C/wCC/wDaz/6+X//Z --=====================_269300533==.REL-- --=====================_269300533==_ Content-Type: text/plain; charset="us-ascii" Network Working Group A. Barbir Internet-Draft Nortel Networks Expires: February 5, 2002 E. Burger SnowShore Networks, Inc. R. Chen AT&T Labs S. McHenry Individual Contributor H. Orman Purple Streak Development R. Penno Nortel Networks Aug 5, 2002 OPES Use Cases and Deployment Scenarios draft-ietf-opes-scenarios-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 5, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services Barbir , et al. Expires February 5, 2003 [Page 1] Internet-Draft OPES Scenarios Aug 2002 that could be performed to requests and/or responses. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Types of OPES services . . . . . . . . . . . . . . . . . . . 4 2.1 Services performed on requests . . . . . . . . . . . . . . . 4 2.1.1 Services intending to modify requests . . . . . . . . . . . 4 2.1.2 Services *not* intending to modify requests . . . . . . . . 5 2.2 Services performed on responses . . . . . . . . . . . . . . 5 2.2.1 Services intending to modify responses . . . . . . . . . . . 6 2.2.2 Services *not* intending to modify responses . . . . . . . . 6 2.3 Services creating responses . . . . . . . . . . . . . . . . 6 3. OPES deployment scenarios . . . . . . . . . . . . . . . . . 7 3.1 Surrogate Overlays . . . . . . . . . . . . . . . . . . . . . 7 3.2 Delegate Overlays . . . . . . . . . . . . . . . . . . . . . 8 3.3 Enterprise environment . . . . . . . . . . . . . . . . . . . 9 3.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 10 3.5 Chaining of OPES data filters and callout servers . . . . . 10 3.5.1 Chaining along the content path . . . . . . . . . . . . . . 10 3.5.2 Chaining along the callout path . . . . . . . . . . . . . . 10 4. Failure cases and service notification . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 Barbir , et al. Expires February 5, 2003 [Page 2] Internet-Draft OPES Scenarios Aug 2002 1. Introduction The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The execution of such services is governed by a set of filtering rules installed on the OPES processor. The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout [7] servers. The document presents examples of services in which Open Pluggable Edge Services (OPES) would be useful. There are different types of OPES services: services that modify requests, services that modify responses, and a special case of the latter, services that create responses. The work also examines various deployment scenarios of OPES services. The two main deployment scenarios, as described by the OPES architecture [1], are surrogate overlays and delegate overlays. Surrogate overlays act on behalf of data provider applications, while delegate overlays act on behalf of data consumer applications. The document also describes combined surrogate and delegate overlays, as one might find within an enterprise deployment. The document is organized as follows: Section 2 discusses the various types of OPES services. Section 3 introduces OPES deployment scenarios. Section 4 discusses failure cases and service notification. Section 5 discusses security considerations. Barbir , et al. Expires February 5, 2003 [Page 3] Internet-Draft OPES Scenarios Aug 2002 2. Types of OPES services OPES scenarios involve services that can be performed on requests for data and/or responses. OPES services can be classified into three categories: services performed on requests, services performed on responses, and services creating responses. In Figure 1, the four service activation points for an OPES processor are depicted. The data dispatcher examines OPES rules, enforces policies, and invokes service applications (if applicable) at each service activation point. --------------------------------------------------------------------- +------------------------------------------------+ | +-------------+-------------+ | | | Service Application | | | +---------------------------+ | Responses | Data Dispatcher | Responses <============4== +---------------------------+ <=3=========== Requests | HTTP | Requests =============1=> +---------------------------+ ==2==========> | OPES Processor | +------------------------------------------------+ Figure 1: Service Activation Points --------------------------------------------------------------------- 2.1 Services performed on requests An OPES service performed on HTTP requests may occur when a request arrives at an OPES processor (point 1) or when it is about to leave the OPES processor (point 2). The services performed on requests can further be divided into two cases: those that intend to modify requests and those that do not. 2.1.1 Services intending to modify requests An OPES processor may modify a service request on behalf of the data consumer for various reasons, such as: Barbir , et al. Expires February 5, 2003 [Page 4] Internet-Draft OPES Scenarios Aug 2002 o Owner of a Web access device might need control over what kind of Web content can be accessed with the device, parental control for example. o Organization may restrict or redirect access to certain web services based on various criteria such as time of the day or the employee access privileges. o Hiding the data consumer's identity, user agent, or referrer. o Adding user preferences or device profile to the service request to get personalized or adapted services. o Blocking or redirecting a service request due to a corporate policy. An OPES processor may also modify a service request on behalf of the data provider in several ways, such as: o Redirecting the request to a different server to reduce the server work load. o Redirecting image requests to improve access time. 2.1.2 Services *not* intending to modify requests An OPES processor may invoke useful service applications that do not modify the user requests. Examples include: o Administrative functions for the data provider, such as service monitoring or usage tracking for billing purposes. o Useful services for the data consumer, such as user profiling (with the user's consent) for service adaptation later on. 2.2 Services performed on responses An OPES service performed on HTTP responses may occur when a response arrives at an OPES processor (point 3) or when it is about to leave the OPES processor (point 4). In the case of a caching proxy, the former service may be an encoding operation before the content is stored in the cache, while the latter may be a decoding operation before the content is returned to the data consumer. The services performed on responses can further be divided into two cases: those that intend to modify responses and those that do not. Barbir , et al. Expires February 5, 2003 [Page 5] Internet-Draft OPES Scenarios Aug 2002 2.2.1 Services intending to modify responses There are several reasons why responses from the data providers might be modified before delivery to the data consumer: o Content adaptation: the data provider may not have all the device profiles and templates necessary to transcode the original content into a format appropriate for mobile devices of limited screen size and display capabilities. o Language translation: the data provider may not have all the translation capabilities needed to deliver the same content in multiple languages to various areas around the world. An OPES processor may perform the language translation or it may invoke different callout servers to perform different language translation tasks. 2.2.2 Services *not* intending to modify responses An OPES service may be performed on the responses without modifying them. Examples include: o Logging/Monitoring: Each response may be examined and recorded for monitoring or debugging purposes. o Accounting: An OPES processor may record the usage data (time and space) of each service request for billing purposes. 2.3 Services creating responses Services creating responses may include OPES services that dynamically assemble web pages based on the context of the data consumer application. Consider a content provider offering web pages that include a local weather forecast based on the requestor's preferences. The OPES service could analyze received requests, identify associated user preferences, select appropriate templates, insert the corresponding local weather forecasts, and would then deliver the content to the requestor. Note that the OPES processor may perform the tasks with or without direct access to the weather data. For example, the service could use locally cached weather data or it could simply embed a URL pointing to another server that holds the latest local weather forecast information. Barbir , et al. Expires February 5, 2003 [Page 6] Internet-Draft OPES Scenarios Aug 2002 3. OPES deployment scenarios OPES entities can be deployed over an overlay network that supports the provisioning of data services in a distributed manner. Overlay networks are an abstraction that creates a virtual network of connected devices layered on an existing underlying IP networks in order to perform application level services. The use of overlay networks creates virtual networks that via OPES entities enables the necessary network infrastructure to provide better services for data consumer and provider applications. At the application level, the resulting overlay networks are termed OPES Services Networks. There are two parties that are interested in the services that are offered by OPES entities, the delegate and the surrogate. Delegates are authorized agents that act on behalf of data consumers. Surrogates are authorized agents that act on behalf of data providers. 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 Surrogate Overlays A surrogate overlay is a specific type of OPES service network, which is delegated the authority to provide data services on behalf of one or more origin servers. Such services include, but are not limited to, dynamic assembling of web pages, watermarking, and content adaptation. The elements of surrogate overlays act on behalf of origin severs and logically belong to the authoritative domain of the respective origin servers. The scenario is depicted in Figure 2. Barbir , et al. Expires February 5, 2003 [Page 7] Internet-Draft OPES Scenarios Aug 2002 --------------------------------------------------------------------- ********************************************* * * * +--------+ Authoritative * * | Origin | Domain * * | Server | * * +--------+ +------------+ * * | | OPES Admin | * * | | Server | * * | +------------+ * * | / * * | / * * +--------------+ +-----------------+ * * | OPES |----- | Remote Call-out | * * | Processor | | Server | * * +--------------+ +-----------------+ * * | * ********************************************* | | | +---------------------------+ | Data consumer application | +---------------------------+ Figure 2: Authoritative Domains for Surrogate Overlays --------------------------------------------------------------------- 3.2 Delegate Overlays A delegate overlay is a specific type of OPES service network, which is delegated the authority to provide data services on behalf of one or more data consumer applications. Delegate overlays provide services that would otherwise be performed by the data consumer applications. Such services include, but are not limited to, virus scanning and content filtering. The elements of delegate overlays logically belong to the Barbir , et al. Expires February 5, 2003 [Page 8] Internet-Draft OPES Scenarios Aug 2002 authoritative domain of the respective data consumer application. The situation is illustrated in Figure 3. --------------------------------------------------------------------- +--------+ | Origin | | Server | +--------+ | | | ********************************************* * | * * +--------------+ +-----------------+ * * | OPES |----- | Remote Call-out | * * | Processor | | Server | * * +--------------+ +-----------------+ * * | \ * * | +------------+ * * | | OPES Admin | * * | | Server | * * | +------------+ * * +---------------------+ * * | Data consumer Appl. | Authoritative * * +---------------------+ Domain * * * ********************************************* Figure 3: Authoritative Domains for Delegate Overlays --------------------------------------------------------------------- 3.3 Enterprise environment Deployment of OPES services in an enterprise environment is unique in several ways: o Both data providers and data consumers are in the same administrative domain and trust domain. This implies that the logical OPES administrator has the authority to enforce corporate policies on all data providers, data consumers, and OPES entities. Barbir , et al. Expires February 5, 2003 [Page 9] Internet-Draft OPES Scenarios Aug 2002 o In the case when a callout server outside the corporate firewall is invoked for services (such as language translation) that cannot be performed inside the corporation, care must be taken to guarantee a secure communication channel between the callout server and corporate OPES entities. The callout server must also adhere to all corporate security policies for the services authorized. 3.4 Callout Servers In some cases the deployment of OPES services can benefit from the use of callout servers that could distribute the workload of OPES processors or to contract specialized services from other OPES providers. In general, operations such as virus scanning that operate on large objects are better handled through the use of a dedicated callout server that is better designed to perform the memory intensive task than what an OPES processor could handle. 3.5 Chaining of OPES data filters and callout servers OPES data processors can be "chained" in two dimensions: along the content path or along the callout path. In the latter case, the callout servers can themselves be organized in series for handling requests. Any content that is touched by more than one data processor or more than one callout server has been handled by a "chain". NOTE: Chaining of callout servers is deferred from version 1 of the Protocol. The discussion of chaining is included here for completeness. 3.5.1 Chaining along the content path An OPES provider may have assigned OPES services to a set of processors arranged in series. All content might move through the series, and if the content matches the rules for a processor, it is subjected to the service. In this way, the content can be enhanced by several services. This kind of chaining can be successful if the services are relatively independent. For example, the content might be assembled by a service early in the chain and then further decorated by a later service. 3.5.2 Chaining along the callout path Alternatively, an OPES data processor might act as a content-level switch in a cluster of other data processors and callout servers. Barbir , et al. Expires February 5, 2003 [Page 10] Internet-Draft OPES Scenarios Aug 2002 The first stage might develop a processing schedule for the content and direct it to other OPES data processors and/or callout servers. For example, OPES processor A might handle all services assembling content, OPES processor B might handle all services involving URL translation, and OPES processor C might handle all content security services. The first processor would determine that processors A and C were needed for a particular content object, and it would direct the content to those processors. In turn, the processors might use several callout servers to accomplish the task. Barbir , et al. Expires February 5, 2003 [Page 11] Internet-Draft OPES Scenarios Aug 2002 4. Failure cases and service notification These are illustrative cases where information about OPES processing can help endpoint users determine where and why content modifications are being performed. o Content provider uses an OPES data processor to enhance content based only on context local to the provider. The local context might be time of day, local URL, or available advertising, for example. The content provider might find OPES logging to be sufficient for debugging any problems in this case. However, the content provider might also try direct probing by issuing a request for the content and examining headers related to tracing. If unexpected parameters show up in the trace headers, the content provider's administrator can use these to correct the OPES rules or detect the presence of an unexpected OPES processor in the content path. o Content provider uses an OPES data processor to enhance content based on context related to the requestor. The requestor may notice that his requests do not elicit the same response as another requestor. He may, for example, get an error message. If he believes there is a configuration error on the OPES data processor, he will need to provide information to the administrator of it. If the information includes "OPES service access control, action: blocked", for example, he can inquire about the circumstances that will allow him to be added to the access control list. In another example, if he sees a picture unrelated to the surrounding text, and if the tracing shows "OPES service choose picture, action: insert 640x480 weather.gif", he might complain that the OPES service does not properly recognize his geographic location and inserts the wrong weather map. In any case, if the information is forwarded to the content provider, the problem may be fixed. o End user has OPES processor available as part of his network access environment. The end user may have selected "translate English to Spanish" as an OPES service. If he sees "OPES service language translation, action: destination language not supported, no action", then he may inquire of the OPES service provider about what languages are supported by the package. If the end user feels that the source language is not properly represented by the provider, resulting in inability for the service to operate, he (or the language service provider) can contact the content provider. o If the content provider gets complaints from users of the translation service and feels that the problem is not in the Barbir , et al. Expires February 5, 2003 [Page 12] Internet-Draft OPES Scenarios Aug 2002 content but in the content but in the service, he may recommend that the service not be applied to his pages. He can do that through content headers, for example, with the notation "No OPES service #8D3298EB" or "No OPES class language translation". o End user's ISP or enterprise uses OPES to control user access based on user profiles. The end user can see that the OPES services are being applied by his ISP, but he cannot control them. If he feels that the transformations bowdlerize the content he can complain to the provider organization. o The content provider or end user relies on a content distribution network and OPES is used within that network. OPES may be authorized by either the content provider, end user, or both. The content provider may suspect that his access control rules are not being applied properly, for example. He may ask for notification on all accesses to his content through a log. This request and the logfile are outside the OPES architecture; there are security implications for the request, the response, and the resources used by the logfile. Barbir , et al. Expires February 5, 2003 [Page 13] Internet-Draft OPES Scenarios Aug 2002 5. Security Considerations The document presents usage scenarios and deployment cases. Issues related to the overall security of OPES entities are given in [1]. Barbir , et al. Expires February 5, 2003 [Page 14] Internet-Draft OPES Scenarios Aug 2002 References [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft: http://www.ietf.org/internet- drafts/draft-ietf-opes-architecture-02.txt, Jul 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [5] OPES working group, "OPES Service Authorization and Enforcement Requirements", Internet-Draft TBD, May 2002. [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, May 2002. [7] A. Beck et al., "Requirements for OPES Callout Protocols", Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf- opes-protocol-reqs-02.txt, Jul 2002. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir , et al. Expires February 5, 2003 [Page 15] Internet-Draft OPES Scenarios Aug 2002 Eric W. Burger SnowShore Networks, Inc. 285 Billerica Rd Chelmsford, MA 01820-4120 USA Phone: EMail: eburger@snowshore.com Robin Chen AT&T Labs Room E219, 180 Park Avenue Florham Park, NJ 07932 US Phone: +1 973 360 8653 EMail: chen@research.att.com Stephen McHenry 305 Vineyard Town Center, #251 Morgan Hill, CA 95037 US Phone: (408) 683-2500 EMail: smchenry@mchenry.net Hilarie Orman Purple Streak Development Phone: EMail: ho@alum.mit.edu Reinaldo Penno Nortel Networks 4555 Great America Parkway Santa Clara, CA 95054 US EMail: rpenno@nortelnetworks.com Barbir , et al. Expires February 5, 2003 [Page 16] Internet-Draft OPES Scenarios Aug 2002 Appendix A. Acknowledgements The authors would like to thank the participants of the OPES WG for their comments on this draft. Barbir , et al. Expires February 5, 2003 [Page 17] Internet-Draft OPES Scenarios Aug 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Barbir , et al. Expires February 5, 2003 [Page 18] --=====================_269300533==_-- From owner-ietf-openproxy@mail.imc.org Tue Aug 6 07:36:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05759 for ; Tue, 6 Aug 2002 07:36:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76BFm018376 for ietf-openproxy-bks; Tue, 6 Aug 2002 04:15:48 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76BFlw18371 for ; Tue, 6 Aug 2002 04:15:47 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04104; Tue, 6 Aug 2002 07:14:35 -0400 (EDT) Message-Id: <200208061114.HAA04104@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-architecture-03.txt Date: Tue, 06 Aug 2002 07:14:35 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : An Architecture for Open Pluggable Edge Services (OPES) Author(s) : A. Barbir et al. Filename : draft-ietf-opes-architecture-03.txt Pages : 17 Date : 05-Aug-02 This memo defines an architecture for a cooperative application service in which a data provider, a data consumer, and zero or more application entities cooperatively realize a data stream service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-architecture-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-architecture-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-architecture-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-architecture-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Tue Aug 6 07:37:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05861 for ; Tue, 6 Aug 2002 07:37:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76BFrB18386 for ietf-openproxy-bks; Tue, 6 Aug 2002 04:15:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76BFqw18382 for ; Tue, 6 Aug 2002 04:15:52 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04130; Tue, 6 Aug 2002 07:14:40 -0400 (EDT) Message-Id: <200208061114.HAA04130@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-protocol-reqs-02.txt Date: Tue, 06 Aug 2002 07:14:40 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : Requirements for OPES Callout Protocols Author(s) : A. Beck et al. Filename : draft-ietf-opes-protocol-reqs-02.txt Pages : 19 Date : 05-Aug-02 This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services [1]. The requirements are intended to help evaluating possible protocol candidates and to guide the development of such protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-protocol-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-protocol-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-protocol-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-protocol-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132724.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Wed Aug 7 07:58:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13895 for ; Wed, 7 Aug 2002 07:58:50 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g77BMha03986 for ietf-openproxy-bks; Wed, 7 Aug 2002 04:22:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g77BMgw03982 for ; Wed, 7 Aug 2002 04:22:42 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12853; Wed, 7 Aug 2002 07:21:29 -0400 (EDT) Message-Id: <200208071121.HAA12853@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-scenarios-01.txt Date: Wed, 07 Aug 2002 07:21:28 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Use Cases and Deployment Scenarios Author(s) : A. Barbir et al. Filename : draft-ietf-opes-scenarios-01.txt Pages : 18 Date : 06-Aug-02 This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-scenarios-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-scenarios-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-scenarios-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020806114850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-scenarios-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-scenarios-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020806114850.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Mon Aug 12 08:44:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19466 for ; Mon, 12 Aug 2002 08:44:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CCMWZ00126 for ietf-openproxy-bks; Mon, 12 Aug 2002 05:22:32 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CCMUw00116 for ; Mon, 12 Aug 2002 05:22:30 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7CCN2x18827 for ; Mon, 12 Aug 2002 07:23:02 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 12 Aug 2002 07:22:29 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 12 Aug 2002 07:22:29 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: Issues raised in opes-enforcement and opes-threat conference call X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 12 Aug 2002 08:22:28 -0400 Message-ID: Thread-Topic: Issues raised in opes-enforcement and opes-threat conference call Thread-Index: AcI/0V7RRcK+A5chROyOwmrQejdezgCKTfzA From: To: X-OriginalArrivalTime: 12 Aug 2002 12:22:29.0266 (UTC) FILETIME=[ECF14720:01C241FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7CCMUw00119 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Chan Tat (NRC/Boston) > Sent: August 09, 2002 02:22 PM > To: 'opes-threat@dnrc.bell-labs.com'; > 'opes-enforcement@dnrc.bell-labs.com' > Subject: Issues raised in opes-enforcement and > opes-threat conference call > > Hi all, > > This is my attempt to summarize some of the issues raised > during the opes-enforcement and opes-threat conference call > this morning, with the hope to get a discussion going in the > mailing lists. So, please provide your comments. > > Basically, the team agreed to go for the enforcement draft > first. In the meeting, there are at least these four issues > discussed, which should all be included in the enforcement draft. > > 1. There is a proposal that we have encryption at all points > in the OPES architecture. The supporting view is that for > environment such as in a VPN, they already have network layer > security, for instance, using IPSec. But there is also fear > that making this a requirement would scare implementors away. > Then again, there is also a view saying that IPSec is kind of > gaining momentum. > > 2. Regarding authorization of OPES devices, do we need to > define a separate protocol, or do we just specify the > requirements and let the implementors decide on what they want to use. > > 3. Granularity of authorization. How fine-grained should the > authorization be? On one end of the spectrum, we can > authorize individual OPES devices. Once authorized, the OPES > device can perform any kind of transformation. On the other > end, we can have service by service authorization, or even > per-request authorization. > > 4. Should end-user only authorization be supported? For > instance, if a data consumer wants to perform language > translation to the web page he/she requests, should he/she be > the one who would authorize the OPES device which performs > the transformation. Should the content provider be notified > that the content they provide is being modified? There are > some copyright issues in there, since the transformation may > have already infringed the copyright of the content owner. > > If I left out anything, I hope the team would add to it. > Again, we would like to get a discussion going regarding > these issues, so please don't hestitate to provide your > valuable comments. > > Best Regards, > > Tat Chan > Senior Reserach Engineer > Nokia Research Center > NOKIA INC > 5 Wayside Road, Burlington, MA 01803 > Phone (781) 993-5776, Fax (781) 993-1907 > tat.chan@nokia.com > From owner-ietf-openproxy@mail.imc.org Tue Aug 13 00:44:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21670 for ; Tue, 13 Aug 2002 00:44:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7D4I6r15347 for ietf-openproxy-bks; Mon, 12 Aug 2002 21:18:06 -0700 (PDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7D4I4w15343 for ; Mon, 12 Aug 2002 21:18:05 -0700 (PDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QJR556Z9; Tue, 13 Aug 2002 09:47:47 +0530 Received: from npd.hcltech.com (akolappa-pc.hclt-ntl.co.in [192.168.19.91]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g7D49WM29786; Tue, 13 Aug 2002 09:39:34 +0530 Message-ID: <3D5887BA.F4D3FD38@npd.hcltech.com> Date: Tue, 13 Aug 2002 09:44:50 +0530 From: Arumugam K X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tat.Chan@nokia.com CC: ietf-openproxy@imc.org Subject: Re: FW: Issues raised in opes-enforcement and opes-threat conference call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Chan Tat, > > -----Original Message----- > > From: Chan Tat (NRC/Boston) > > Sent: August 09, 2002 02:22 PM > > To: 'opes-threat@dnrc.bell-labs.com'; > > 'opes-enforcement@dnrc.bell-labs.com' > > Subject: Issues raised in opes-enforcement and > > opes-threat conference call > > > > 4. Should end-user only authorization be supported? For > > instance, if a data consumer wants to perform language > > translation to the web page he/she requests, should he/she be > > the one who would authorize the OPES device which performs > > the transformation. Should the content provider be notified > > that the content they provide is being modified? There are > > some copyright issues in there, since the transformation may > > have already infringed the copyright of the content owner. > > There is an advantage in notifying the content provider when the data is modified by opes device. The provider will come to know which lang. the content is transformed the most. So that the provider could keep a copy of the content in the same language. Thus he could contribute on avoiding that many opes transformations. Thanks Arumugham -- Want to know CDN? http://cdn.hcltech.com From owner-ietf-openproxy@mail.imc.org Tue Aug 13 11:36:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16704 for ; Tue, 13 Aug 2002 11:36:46 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7DFC8u14728 for ietf-openproxy-bks; Tue, 13 Aug 2002 08:12:08 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7DFC5w14722 for ; Tue, 13 Aug 2002 08:12:06 -0700 (PDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g7DFBuuB045005 for ; Tue, 13 Aug 2002 11:11:56 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g7DFBoo70086 for ; Tue, 13 Aug 2002 11:11:50 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA10605 for ; Tue, 13 Aug 2002 11:11:50 -0400 (EDT) Message-ID: <3D5921B5.2040507@mhof.com> Date: Tue, 13 Aug 2002 11:11:49 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: FW: Issues raised in opes-enforcement and opes-threat conference call References: <3D5887BA.F4D3FD38@npd.hcltech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Arumugam, > There is an advantage in notifying the content provider when the > data is modified by opes device. The provider will come to know > which lang. the content is transformed the most. So that the > provider could keep a copy of the content in the same language. > Thus he could contribute on avoiding that many opes > transformations. While there are clearly advantages in notifying the content provider about certain services being performed, there are also services the content provider does not really need to be notified about. Furthermore, default notification to content providers raises privacy issues - I might not want to let every content provider know what exact services I requested... Notification is one thing, authorization another. Just as with notification, there are services for which it would make sense to require authorization from both endpoints (i.e. consumer and provider), but there are also services for which we cannot require authorization from the provider. A stupid simple example is logging, or a charging service - why would a consumer need the consesus of a content provider to use a logging service? On the other hand, of course, legal issues might require provider authorization for certain services (e.g. content transformation). But maybe such authorization will happen in form of SLAs? In general... In Section 2.2.2 of the scenarios draft, we talk about "Services *not* intending to modify responses". Are these the services that do *not* require authorization from content providers, while "Services intending to modify responses" (as described in Section 2.2.1) would require such authorization? And what about the services operating on requests? -Markus From owner-ietf-openproxy@mail.imc.org Wed Aug 14 06:45:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03439 for ; Wed, 14 Aug 2002 06:45:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EANlG00604 for ietf-openproxy-bks; Wed, 14 Aug 2002 03:23:47 -0700 (PDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7EANjw00600 for ; Wed, 14 Aug 2002 03:23:45 -0700 (PDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QJR56N6M; Wed, 14 Aug 2002 15:53:25 +0530 Received: from npd.hcltech.com (akolappa-pc.hclt-ntl.co.in [192.168.19.91]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g7EAF2M10973; Wed, 14 Aug 2002 15:45:02 +0530 Message-ID: <3D5A2EE9.C9B543ED@npd.hcltech.com> Date: Wed, 14 Aug 2002 15:50:25 +0530 From: Arumugam K X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann CC: ietf-openproxy@imc.org Subject: Re: FW: Issues raised in opes-enforcement and opes-threat conferencecall References: <3D5887BA.F4D3FD38@npd.hcltech.com> <3D5921B5.2040507@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, see inline Markus Hofmann wrote: > > Arumugam, > > > There is an advantage in notifying the content provider when the > > data is modified by opes device. The provider will come to know > > which lang. the content is transformed the most. So that the > > provider could keep a copy of the content in the same language. > > Thus he could contribute on avoiding that many opes > > transformations. > > While there are clearly advantages in notifying the content provider > about certain services being performed, there are also services the > content provider does not really need to be notified about. > Furthermore, default notification to content providers raises privacy > issues - I might not want to let every content provider know what > exact services I requested... Yes. Default notification to content provider could be avoided considering the privacy issues. Instead of sending notification to content provider on every transformation, the cumulative report of the transformations may be send to the content provider. Especially in language translation service ,this will help on getting the advantage mentioned in my previous mail. > > Notification is one thing, authorization another. Just as with > notification, there are services for which it would make sense to > require authorization from both endpoints (i.e. consumer and > provider), but there are also services for which we cannot require > authorization from the provider. A stupid simple example is logging, > or a charging service - why would a consumer need the consesus of a > content provider to use a logging service? On the other hand, of > course, legal issues might require provider authorization for certain > services (e.g. content transformation). But maybe such authorization > will happen in form of SLAs? > When the content provider wants to have authorization for few services, that has to be honoured. The SLAs could be used for this purpose. I would like to mention one of the service given in the ICAP draft. The ICAP protocol supports the advertisement insertion service. This service replaces the original ad with local ad. Definitely , without the approval of the content provider, this service could not be offered. SLAs could be used for this purpose. > In general... In Section 2.2.2 of the scenarios draft, we talk about > "Services *not* intending to modify responses". Are these the services > that do *not* require authorization from content providers, while > "Services intending to modify responses" (as described in Section > 2.2.1) would require such authorization? And what about the services > operating on requests? > Sometimes it would make sense to provide a service to requests also. An example could be given from the ICAP protocol. Using ICAP ,we can provide a decompression service. The OS would keep the content in the compressed format. When the user makes a request to the original data, the ICAP server will convert this request to a request for compressed data. On receiving the compressed data, the ICAP server will decompress it and sends the data in the original format to the end-user thro' the ICAP client. This service helps on saving the network bandwidth. In this service both request and response undergoes some modification. This may be considered as a service where request also needs modification PS: I would like to know the view of the ICAP team on adding the decompression service to the current ICAP draft Thanks Arumugam -- Want to know CDN? http://cdn.hcltech.com From owner-ietf-openproxy@mail.imc.org Tue Aug 27 20:32:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18684 for ; Tue, 27 Aug 2002 20:32:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S05rt06817 for ietf-openproxy-bks; Tue, 27 Aug 2002 17:05:53 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNcH205470; Tue, 27 Aug 2002 16:38:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 27 Aug 2002 16:38:17 -0700 To: (many IETF mailing lists) From: Paul Hoffman / IMC Subject: Nomcom call for volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forwarded for Phil Roberts : The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From owner-ietf-openproxy@mail.imc.org Wed Aug 28 08:27:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26980 for ; Wed, 28 Aug 2002 08:27:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SBxAC26237 for ietf-openproxy-bks; Wed, 28 Aug 2002 04:59:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SBx9226233 for ; Wed, 28 Aug 2002 04:59:09 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25022; Wed, 28 Aug 2002 07:57:40 -0400 (EDT) Message-Id: <200208281157.HAA25022@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ops-rfc2786std-00.txt Date: Wed, 28 Aug 2002 07:57:39 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : Diffie-Hellman USM Key MIB Author(s) : M. StJohns Filename : draft-ietf-ops-rfc2786std-00.txt Pages : 28 Date : 2002-8-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a textual convention for doing Diffie- Hellman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of a DH key exchange in addition to the key change method described in [14]. In other words, this MIB adds the possibility of forward secrecy to the USM model. It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential. The author is submitting this draft at the request of the O&M area director. This memo revises and updates RFC 2786 [19] with the goal of moving the described protocol and MIB from Experimental to Standards Track. The one minor substantive change from the Experimental RFC is a restatement of the conditions on the selection of the DH public number (see DHKeyChange and usmDHKickstartMyPublic in the body of the MIB as well as the MIBs revision history). The spelling of 'Hellman' was corrected throughout. Author contact information was updated. Slight structural modifications were made to more cleanly seperate boilerplate from substantive text. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ops-rfc2786std-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ops-rfc2786std-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ops-rfc2786std-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-27144836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ops-rfc2786std-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ops-rfc2786std-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144836.I-D@ietf.org> --OtherAccess-- --NextPart-- From subs-reminder@imc.org Sat Aug 31 18:33:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14325 for ; Sat, 31 Aug 2002 18:33:46 -0400 (EDT) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g7VMZEH24769; Sat, 31 Aug 2002 15:35:14 -0700 (PDT) Date: Sat, 31 Aug 2002 15:35:14 -0700 (PDT) Message-Id: <200208312235.g7VMZEH24769@above.proper.com> To: opes-archive@ietf.org Subject: [[858289600]] Subscription to ietf-openproxy for opes-archive@ietf.org Greetings. This message is a periodic reminder that opes-archive@ietf.org is subscribed to the ietf-openproxy mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openproxy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openproxy-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "opes-archive@ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator