At 14:19 3/29/2001 -0700, Hilarie Orman wrote:
I agree with the previous comments
that it looks strange to have this in
a charter. It's normal to develop
requirements and evaluate solutions
against the requirements. It just
looks odd to propose the solution
before the requirements.
Right. Surely the way to show that the group is looking actively involved
in a protocol is to bring it in as a group Draft (draft-ietf-opes-) - it
would then show up automatically.
If we hold up iCAP as an example here, surely that would require charter
revisions to add similar texts if other protocol examples are provided.
On that note, I'd still suggest removing the "Related Internet Drafts"
section. (I think I understand the intent of the section, but that would
be better handled by references to drafts/URLs on the mailing list and
re-publication of drafts, under new names, on WG formation.)
We don't
want OPES to look odd.
And on that front, I don't think I've ever seen "Technical Team Lead" as a
header part to a charter, and from memory don't recall anything about a
"special" position when reading the process RFCs (I could be wrong though).
Hilarie
>>> "Michael W. Condry" <condry(_at_)intel(_dot_)com> 03/29/01 01:47PM >>>
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