[Top] [All Lists]

Re: Revised Charter - can we close and get going?

2001-03-29 13:49:24
I have mixed opinions on this. Most prefer the iCAP paragraph because
it is one example. The charter only deals with it that way.

If you believe it is a protocol worth looking at, and the paragraph basically
says that, why is there such a concern?
At 02:32 PM 3/29/2001 -0600, Jayanth Mysore wrote:
I am not yet fully convinced that we need the paragraph on ICAP in
the charter.
I do believe it is a protocol worth looking at closely for our
purposes.  However it
seems unecessary to state out intentions to do so in the charter.

- Jayanth

Hilarie Orman wrote:

> I strongly advise simplification by taking the two
> paragraphs re transparency and security and combining
> them thusly:
> Intermediary services will not be transparent.
> A security model with modes of authorization will
> be part of the architecture and protocol elements.
> Hilarie
> >>> "Michael W. Condry" <condry(_at_)intel(_dot_)com> 03/29/01 11:36AM >>>
> Open Pluggable Edge Services (opes)
> Co-chairs:
>     Michael Condry <condry(_at_)intel(_dot_)com>
>     Markus Hofmann <hofmann(_at_)lucent(_dot_)com>
> Technical Team Lead:
>     Hilarie Orman <horman(_at_)volera(_dot_)com>
> Mailing Lists:
>     General Discussion: ietf-openproxy(_at_)imc(_dot_)org
>     To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org
>     Web:
>     Archive:
> Description of Working Group:
> The Open Pluggable Edge Services (OPES) working group
> primary task is to define protocols enabling
> participating transit intermediaries to incorporate
> services that operate on application-level data
> transported by HTTP and possibly RTP/RTSP. The protocol
> to be defined provides a framework for integrating a
> wide range of services into arbitrary intermediaries.
> Intermediaries may employ services executed either
> locally or on a remote ("callout") server. As a result,
> the data may be diverted temporarily over a closed loop
> pathway different from the transit pathway.
> The advantage of standardizing such a protocol is that
> services can be re-used across vendor products without
> modifying the transit intermediaries or services.
> The iCAP protocol already provides similar functionality
> for services operating on HTTP-encapsulated application
> data. The working group will evaluate the iCAP protocol
> as one candidate for HTTP-encapsulated application data.
> It may decide to extend the iCAP protocol without being
> obliged to retain any level of compatibility with
> the current iCAP proposal.
> Intermediary services provided in this way are not
> transparent: They have to be authorized by either the
> content requestor or the provider, corresponding to
> who the service being provided for.
> 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 to specify conditions under which
> services are executed.
> Related Internet-Drafts
> Early Requirements document (expired but available on
> the web site):
>          draft-tomlinson-epsfw-00.txt
> Updated iCAP Callout Protocol:
>          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:
> Jun 01: Working Group review of OPES Deployment Scenarios
>          document.
> Jul 01: Working Group review of callout protocol
>          requirements.
> Aug 01: iCAP Protocol document last call.
> Aug 01: Working group review of policy requirements
>          document(s).
> Nov 01: Working group review of alternative callout
>          protocol.
> Dec 01: Policy requirements document last call.
> Michael W. Condry
> Director, Network Edge Technology

Michael W. Condry
Director, Network Edge Technology