[Top] [All Lists]

Woops, wrong charter draft

2001-03-06 15:24:00
Sorry I made an error. Please replace the draft with this:

Open Pluggable Edge Services(opes)

   Michael Condry <condry(_at_)intel(_dot_)com>
   Hilarie Orman <HORMAN(_at_)novell(_dot_)com>

Mailing Lists:
   General Discussion: ietf-openproxy(_at_)imc(_dot_)org
   To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org

Description of Working Group:

The Open Plugable Edge Services architecture (OPES) is defines how participating transit intermediaries can be extended to incorporate services executed on application data. The services are written to an open standard for use with the intermediaries.

Caching is a basic intermediary service, one that requires an understanding of at least a subset of application semantics by the cache server. Intermediaries may employ either local or remote ("callout") servers to perform a service, and as a result, the data may be diverted temporarily over a closed loop pathway different from the transit pathway. The purpose of this working group is to define the protocols for a broad set of services that facilitate efficient delivery of complex content or services related to application data. The advantage of standardizing these protocols is that the services can be re-used across vendor products without modifying the transit intermediaries or services.

The architecture supports services that are either located on the transit intermediary or on callout servers. Protocols that connect the OPES servicedevice and callout services must be defined. The ICAP protocol is one option for carrying HTTP headers and data to cooperating servers; the OPES framework will support other protocols to cooperating servers as they exist or become available.

There are protocols and policies to define the applications that are plugged into the OPES server. The working group must define all the requirements that expose these as well.

The security model for intermediary services involves defining the administrator roles and privileges for the application client, application server, intermediary, and auxiliary server. The data integrity model defines what operations are permitted by the content owner(s) and guarantees of content correctness can be made to the owner(s) and viewers when content-related services are performed.

The first objective of the working group is to deliver the requirements of the overall system and, where possible, mandate protocol solutions where there is consensus. Target areas where requirements and proposed solutions are:

1. Callout services protocols (e.g., ICAP) for use with HTTP and other content protocols. 2. "Service delivery" protocols for delivering the services or service descriptions to be preformed by the OPES facility or/and its cooperating servers.
3.      A configuration and definition model for service extensions
a. To include representation of conditions leading to invocation of intermediary-based services, common data items (identities, authentication state, etc.), postprocessing directives, and the access method for the service or a representation of a loadable service (URL or encoded executable or interpretable code, for example). b. Other policy recommendations observed by having an intermediary be the central point of service extensions. 4. A trust model and security configuration policy definitions, i.e. roles, privileges, and enforcement point responsibilities.

With consensus on the requirements, the working group can examine the progress in this area and, if appropriate, re-charter to with more general work items in the OPES framework.

Existing Internet-Drafts
Early Requirements document (expired but available on the web site):
Updated iCAP Callout Server:
A Rule Specification Language for Proxy Services:
OPES Network Taxonomy:
OPES Architecture for Rule Processing and Service Execution:
OMML: OPES Meta-data Markup Language:
General Use Cases:

Goals and Milestones:
Feb 01: Workshop to discuss OPES issues
Mar 01: Consensus on the charter.
Mar 01: Meet at Minneapolis IETF
Apr 01: Additional requirements gathering and document update plans.
Jun 01: Proposed requirements for policy information model
Jul 01: Requirements for security model and configuration policy to IETF
Aug 01: Requirements of service dispatch rules, enforcement semantics, standard data items, and post processing
Aug 01: Draft revised consensus requirements document.
Aug 01: Meet at London IETF
Nov 01: Review proposals for service dispatch rules and delivery protocols.
Dec 01: Update of requirements document.
Dec 01: Salt Lake City IETF.
Mar 02: Review charter and plan for protocol specifications.

Michael W. Condry
Director, Network Edge Technology

<Prev in Thread] Current Thread [Next in Thread>
  • Woops, wrong charter draft, Michael W. Condry <=