Cross Post of OPES Charter Update

["Michael W. Condry" <condry@intel.com>]

All-
We have an charter update for the proposed OPES working group.
I would prefer any comments to made to the mailing list at
ietf-openproxy@imc.org however any comments to me
will be passed on to the list by me.
For those who read the list, please excuse the cross posting.
Here is the new OPES charter proposal.


Open Pluggable Edge Services(opes)

Co-chairs:
    Michael Condry <condry@intel.com>
    Hilarie Orman <HORMAN@novell.com>

Mailing Lists:
    General Discussion: ietf-openproxy@imc.org
    To Subscribe: ietf-openproxy-request@imc.org
    Web: http://www.ietf-opes.org
    Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes

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):
         draft-tomlinson-epsfw-00.txt
Updated iCAP Callout Server:
         draft-elson-opes-icap-01.txt
A Rule Specification Language for Proxy Services:
         draft-beck-opes-imrl-00.txt
OPES Network Taxonomy:
         draft-erikson-opes-net-taxonomy-00.txt
OPES Architecture for Rule Processing and Service Execution:
draft-yang-opes-rule-processing-service-execution-00.txt
OMML: OPES Meta-data Markup Language:
draft-maciocco-opes-omml-00.txt
General Use Cases:
         draft-beck-opes-esfnep-01.txt


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