ietf-openproxy
[Top] [All Lists]

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

2001-03-29 14:50:50
From draft-elson-opes-icap-01.txt:

"ICAP discussion currently takes place on the IETF Open Proxies mailing
list at ietf-openproxy(_at_)imc(_dot_)org(_dot_)"

If this means that:

- draft authors think that OPES is a good path to move ICAP 
  to RFC/standard track;
- they have some reason to believe that OPES was going to 
  work on this draft;
- the group agrees that this protocol should get IETF 
  consideration and maybe approval,

we should keep this reference. 

As far as I understand ICAP already has some level of 
industry recognition and definitely is within this group 
area of responsibility. This means we should not ignore it. 
Even if this is not an ideal solution it has to be 
part of the picture.

Oskar 

-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of 
Michael W. Condry
Sent: Thursday, March 29, 2001 3:47 PM
To: Jayanth Mysore; Hilarie Orman
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Revised Charter - can we close and get going?


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

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