At 16:45 3/29/2001 -0500, Oskar Batuner wrote:
>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.
I don't think there's a suggestion we should remove iCAP from our minds
(though the group has to be careful to work on requirements "first"); it's
an issue of how iCAP is referenced within the charter.
If there's no assumption iCAP is going to be used as "the" protocol (with
the group just fixing a few broken things) then I still think it's better
to have no mention of it, other than to appear as a group work item in the
automatically created list of Internet Drafts.
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.
Agreed 100%. That doesn't mean it has to be referenced in the charter,
other than (perhaps) as an early goal to publish it as
Informational/Experimental.
The problem with the current wording is that the proposed group *may* do
something; if it *will* do something definite, with a proposed
goal/milestone then put it in there as such; if we're not sure, don't even
mention it until we're sure (at which point forget about it or, more
likely, revise the charter).
Michael (and others) is obviously trying to get his charter before IESG as
soon as possible. All I'm trying to do is to make sure it doesn't get
bounced back for revisions. Apologies if it looks like I'm trying to do
something else.
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
>