My comments in brackets.
Hilarie
Ian Cooper <icooper(_at_)equinix(_dot_)com> 03/23/01 09:13AM >>>
At 07:21 3/23/2001 -0800, Michael W. Condry wrote:
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.
The value of the "remote" or "callout" server is that it can be provisioned
elsewhere on the network, not in the transit pathway.
I may be projecting my own thoughts, but in the meeting we said that SMTP
should be out of scope, since services such as virus checking are typically
provided by the introduction of another SMTP relay (and this notion in SMTP
is well established).
[Yes, we did say that SMTP was out of scope, but the charter
seems to be fairly clear on that point, does it not?]
Service introduction in HTTP could also be
provisioned within a proxy on the transit path. The use of a callout
server "only" seems to gain you some control over possible loops and the
avoidance of complication of transit pathways.
[ I think that its agreed that the services could be provisioned
on a proxy in the path, but our charter does not allow us
consider this case. ?]
Intermediary services provided in this way are not
transparent: Either the content requestor or provider will
be aware that a transformation has been performed.
Did we remove the case where the access provider is the one controlling the
transformation?
[The security model will have to clarify this. "Controlling" the
transformation might be a different role than "authorizing" or
"delegating" the transformation. So the access provider may
simply be carrying out the intent of the requestor or provider.]
Also "..the content requestor.. will be aware that a transformation has
been performed". Would this be similar to the notional Warning headers
that I've never seen used in HTTP/1.1? The content consumer may have
requested that services be provided, but when do they know if the trigger
has fired and the transformation has been carried out?
[Again, the security work needs to clarify this; "awareness" might be
as little as "authorization", or as intrusive as "click here for element
transformation 'Language Translation English to Chinese' action".
As part of the development of this protocol the working
group will produce an analysis of the security implications
of this architecture.
I'm not too sure how I see this as being different to the security
considerations part of any protocol documents.
[The WG needs to discuss this; my understanding of the
charter is that the 'integrity' of the content and authorization
of services based on roles and identities and signatures is
all part and parcel of the 'security considerations' in this case.
Also, the assurance of the 'awareness' of the authorizing
parties for each (?) service action.]
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.
This paragraph seems redundant. It seems to make more sense to have iCAP
as a draft for consideration within the group, but I'm not sure it belongs
within the charter description text.
[I agree]
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
Is this section necessary in the charter?
Goals and Milestones:
Apr 01: Consensus on the charter.
Seems an odd milestone to have in a charter proposed for the formation of a
WG...
[Ummph]
Jul 01: iCAP Protocol document last call.
But you said you wouldn't be obliged to maintain compatibility with iCAP.
So either you're using the name to mean "something that doesn't look like
iCAP does at the moment" or you mean "we may recharter to change this goal".
[I read this as "being as you've got to start from ICAP, you might as well
ratify it as an existence proof of there being at least one acceptable
protocol. You can later decide that you've got requirements that
supercede ICAP, but ICAP will still be useful for some solutions."]
Aug 01: Working group review of policy requirements document(s).
Nov 01: Alternative callout protocol review.
This one has me confused too. Why is iCAP being taken to last call if you
also have a review of alternative callout protocols?
I must be missing something?!
Dec 01: Policy requirements document last call