ietf-openproxy
[Top] [All Lists]

Charter updates, changes, etc.

2001-03-23 08:23:47
It is clear from OPES BOF and other discussions at IETF that complexity surrounding
the intermediary service boxes is large. So we have decide to modify our
chair structure to give us more strength to cover the technical and political complexities
most effectively. It will certainly be a challenge for all of us.

The new proposed roles are:

Co-chairs:
   Michael Condry <condry(_at_)intel(_dot_)com>
   Markus Hofmann <hofmann(_at_)bell-labs(_dot_)com>

Technical Team Lead:
   Hilarie Orman <HORMAN(_at_)novell(_dot_)com>

Three roles will help us address the difficulties in all the spaces we are expecting
to arise. Consequently, based on the consensus of the BOF and the above change
the charter to be submitted to the IESG will be:


Open Pluggable Edge Services(opes)

Co-chairs:
   Michael Condry <condry(_at_)intel(_dot_)com>
   Markus Hofmann <hofmann(_at_)bell-labs(_dot_)com>

Technical Team Lead:
   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
   Web: http://www.ietf-opes.org
   Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes

Description of Working Group:

The Open Pluggable Edge Service (OPES) working group primary
task is to define a protocol to be used to extend
participating transit intermediaries to incorporate services
executed on application data transported by HTTP and
possibly RTP protocol suite.  The protocol provides a framework for
integrating a wide range of services into arbitrary
intermediaries. 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.

Intermediary services provided in this way are not
transparent: Either the content requestor or provider will
be aware that a transformation has been performed.

As part of the development of this protocol the working
group will produce an analysis of the security implications
of this architecture.

A secondary task for this working group is to enumerate the
requirements for management policies and associated
administrative protocols that allow these services to be
specified and deployed. This includes requirements on the
rule systems used the define these policies and protocols.

The advantage of standardizing a protocol for this is that
services can be re-used across vendor products without
modifying the transit intermediaries or services.

The iCAP protocol already provides similar functionality and
this working group may elect to use iCAP as a starting point
for its work. However, the working group is not obliged to
retain any level of compatibility with iCAP.

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-irml-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:

Apr 01: Consensus on the charter.
Jul 01:  iCAP Protocol document last call.
Aug 01: Working group review of policy requirements document(s).
Nov 01: Alternative callout protocol review.
Dec 01: Policy requirements document last call




Michael W. Condry
Director, Network Edge Technology


<Prev in Thread] Current Thread [Next in Thread>