I'd appreciate receiving your feedback/corrections, if any, by
end-of-business Monday, 08/20/01, so the final minutes can be published on
the OPES web site.
Thanks!
- Rama
*******
-----Original Message-----
From: Menon, Rama R [mailto:rama(_dot_)r(_dot_)menon(_at_)intel(_dot_)com]
Sent: Friday, August 17, 2001 10:29 AM
To: 'ietf-openproxy(_at_)imc(_dot_)org'
Subject: Minutes of the OPES session at the 51st IETF, London
The minutes of the OPES BOF in last week's IETF meeting in London are
reported below. For those interested, I've also attached the MS WORD
document that captures the same information.
Cheers,
- Rama
**********
OPES BOF Minutes
IETF 51, Tuesday 7 August, 0900
Co-chairs:
Michael Condry <condry(_at_)intel(_dot_)com
<mailto:condry(_at_)intel(_dot_)com>>
Markus Hofmann <hofmann(_at_)lucent(_dot_)com
<mailto:hofmann(_at_)lucent(_dot_)com>>
Technical Team Lead:
Hilarie Orman <horman(_at_)volera(_dot_)com
<mailto:horman(_at_)volera(_dot_)com>>
Applications Area Directors:
Patrik Faltstrom <paf(_at_)cisco(_dot_)com <mailto:paf(_at_)cisco(_dot_)com>>
Ned Freed < ned(_dot_)freed(_at_)mrochek(_dot_)com
<mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com>>
Notes taken by Paul Knight < paknight(_at_)nortelnetworks(_dot_)com
<mailto:paknight(_at_)nortelnetworks(_dot_)com> > and Rama Menon
<rama(_dot_)r(_dot_)menon(_at_)intel(_dot_)com
<mailto:rama(_dot_)r(_dot_)menon(_at_)intel(_dot_)com> >
Briefing on OPES charter
Michael Condry presented the changes in the OPES charter. He proposed a
name change to Open Pluggable Endpoint Services. He displayed the
"Description of Working Group" document, and will send the document to the
mailing list.
A discussion followed with several participants raising concerns on the name
change - from "edge" to "endpoint". Michael agreed with the suggestion that
the scenarios document for OPES to be updated to reflect changes in the
charter statement.
Discussion:
(Lee Rafalow): Changing "edge" to "endpoint" will not make any difference;
it loses much of the context by not using "edge".
(Ian Cooper): Endpoint implies services are on a laptop or client system.
It's not useful.
(Jim Kempf?): Are we only looking at words beginning with "E"?
(Michael C.) We are trying to keep from misinterpretation.
(Elliot Lear): Does the current draft on "scenarios" reflect the charter?
My concern is that some scenarios in the draft require changing end-to-end
model, or changing data in the connection.
(Michael): Two connections are involved, from client to OPES box, and from
OPES box to server.
(Elliot): What if either the client or the server may not want this?
(Linda Schup?): Privacy, source authentication services may be affected by
this.
(Larry Masinter): The scenarios document should be edited to match the new
charter statement.
(Michael) Agree.
Relation to Midcom WG: Cooperation, not Competition
Melinda Shore (MIDCOM WG chair) talked about the relationship between OPES
and MIDCOM. She touched up on the charter for MIDCOM, described the MIDCOM
work, and explained the boundaries between OPES and MIDCOM. A few questions
on the MIDCOM/OPES overlap were answered and a suggestion on getting common
terminology defined was agreed to (with reluctance). In response to a
question on potential overlap in Authentication, Authorization and
Accounting (AAA) between MIDCOM and OPES, Melinda agreed to investigate
common schema to address the AAA requirements for MIDCOM and OPES.
Discussion:
(Anwar Siddiq?): Isn't MIDCOM in the transport layer, while OPES is
operating at the application layer?
(Melinda): yes.
(Michael): We are trying to coordinate the callout framework with midcom.
(Melinda): Customers expect to see and influence the boundaries of
services, whether they are boxes in transport layer or in application layer.
(Larry M): Common Terminology framework document would help.
(Melinda): This may help, but there are some differences in boundaries.
(Michael): It would be advantageous to do this, some common terminology.
(Dan Rothman): This looks like there could be some overlap with
Authorization proposals between two groups? For example, with a firewall,
look at an authorized host or authorized client. It looks like some
opportunity for overlap.
(Melinda): The middle box uses the site security policy.
(Michael): We are trying to avoid multiple levels of authorization.
Summary of OPES Workshop, June 7:
Michael Condry presented a summary of activity in the OPES workshop, June 7,
2001 in Santa Clara, California. The workshop report is on the OPES web
site. (<http://www.ietf-opes.org>)
OPES Scenarios draft:
Hilarie Orman was not present to discuss the scenarios draft.
OPES Models (draft-tomlinson-opes-model-00.txt)
Gary Tomlinson presented a report on the OPES Models draft. Beyond the
slides, he mentioned that work is planned on a callout protocol requirements
draft.
Discussion:
(Elliott): There should be a signature or proxy profile, to indicate change
of some kind. Is there a way for the client to determine where a change was
made?
Answer (Gary): Not yet.
(Elliott): What prevents anyone from using this technology to change a web
page?
(Gary T): Nothing
(Elliott): We (IETF) are good at enabling things, not blocking things.
(Ted Clark?): The overlay networks model requires a kind of source routing
which does not scale, because the path must follow a known route, since the
conversation depends on the intermediaries. It only works if the services
are at the edge, near the end points, so the traffic is forced into one
path.
(Gary T): It depends on the path, yes.
(Ted): The service needs a narrowing of scope, to require a constrained
transport path where this occurs.
(Michael): The overlay model uses a connected framework underneath. The
underlying connections are defined, and the paths are linked at lower
layers. The path is not really limited, as long as it has reachability to
each element on the overlay path. It is not in the OPES charter to address
the path at lower layers.
(Anwar): Real-time service translation will be an issue.
(Larry M): A content delivery network is a well-described subset of this
OPES model, not a different overlay (referring to slide presented by Gary).
We understand a CDN's failure modes but the failure modes of OPES are not
well understood. It will be useful to spend some time on failure modes, how
to prevent troubles, problems. This is a key to answering the concerns of
the "OPES is evil" camp.
(Unknown) Routing needs to be addressed. The applets - proxylets ...
[missed by note taker] ... rapid notification ... active content. There are
some solutions, papers addressing these issues. (Michael): Can you send
pointers to the mailing list?
(Unknown 2) If you have an OPES box inserting advertisements, I want them
marked so we can do 100% junk busting on it.
(Dan Rothman): In the case where you have an overlap of many content domains
on one OPES server, how do you handle that? The slide showing Authoritative
Domain does not consider this kind of overlap.
(Gary): Yes, one OPES box can be supporting many content domains. I'll add
that to the diagrams.
Policy Requirements (draft-rafalow-opes-policy-requirements-00.txt)
Lee Rafalow presented a discussion on the "Policy Requirements" draft. The
presentation was based on highlighted sections of the draft. Conflicting
descriptions of the requirements for OPES rule engines exist: first, that
performance is vital, and the language must not require procedural
execution, it must use declarative rules with no side effects; second that
actions or messages MAY change the behavior of subsequent services (i.e., it
allows procedural execution).
Discussion:
(Michael): Efficiency is desirable, but we need to be flexible.
(Lee): We need to ensure a fast path.
(Markus Hoffman): There are cases where we need to have one rule influencing
another rule, as when there is parental control, then some delivery of
content which may have some other processing.
(Lee): I have no problem with action chaining.
(Larry M): There seems to be some implicit understanding in the model of the
structure of messages. My concern is that the model is too rigid, or too
complicated. Computational models for rule execution need to be specified
and failure modes are to be documented.
(Lee): Yes, there is a model; we try to be explicit.
(Larry M): It needs to be made simpler.
(Lee): The message properties exist outside of the messages themselves.
(Larry M): We need to be more explicit about the state.
(Lee): see the discussion of environment variables in the draft.
(Lee continuing presentation) ... Discussion of draft language concerning
relative importance of performance....
(Question -) What are the implications of multiple rules firing on
performance? Ordering of parallel execution of rules...
(Lee): The requirements documents try to address this; one approach is
applying priority to rules to determining execution sequence, but there are
some issues.
(Larry M): It is like prolog programming... It may be too early to address
ordering the priority of rules. First we need to do what is necessary to
make it reliable.
(Lee continuing presentation) ... Rule processing points... Administratively
defined names may be used for policy... Environment variables... string
operations vs. arithmetic operations... What is the feeling about
restricting arithmetic operations on environment variables? This is
suggested as a way to improve efficiency and performance. However,
arithmetic operations are often quicker than string operations.
(Dan Rothman): Scope of environment variables needs to be addressed. What
about rule sets from different arithmetic domains... collisions, conflicts?
(Jim Kempf?): Maybe the restriction was intended to restrict floating-point
arithmetic operations.
(Larry): "Performance efficiency" was used to derive requirements for types
of operations. It would be better to specify a performance goal, not get
into the details of how to achieve it. Be explicit about the performance
requirements. Speculate on performance in the document, don't bake-in these
at this stage. The relative value of performance vs. expressiveness should
be determined in the design documents, not in the requirements document.
(Lee continuing presentation) ... environment variables should support
groups of conditions to define rules. Rule management...language to
authenticate rule providers... What is the definition of the content
provider's rule domain? What about the client's rule domain?
(Elliott): Can't this be allowed to float in the requirements draft. May be
defined at run time. Define meta-rules.
(Lee): Sounds like a good approach.
Rule Language (draft-beck-opes-irml-01.txt)
Markus Hoffman gave a report on IRML. One change was to remove the access
provider from the list of possible rule owners.
Discussion:
(Elliott): Are there other solutions available for rule language? Not sure
OPES or even IETF can solve these issues. May be in the domain of W3C. For
example, doing virus/filtering checking. Maybe an extension to HTML may be
a better way to do this?
(Michael): We would appreciate some clarification; let's discuss on the
mailing list.
(Question): Scenarios draft should describe what other approaches are being
used now... the existing technology, and why it's not sufficient.
(Michael, Markus): Agree.
Rule Language Extensions (draft-ng-opes-irmlsubsys-00.txt &
draft-ng-opes-irmlqos-00.txt)
Chan-Wah Ng presented a report on the Rule Language Extension drafts. There
were no questions.
Technical Update on ICAP Specification (draft-elson-opes-icap-01.txt)
John Martin presented a report on the status of iCAP 1.0. The plan is to
pursue publications of iCAP 1.0 as an Informational RFC. We are doing
interoperability testing. The OPES WG will be used (for publication assuming
the WG is chartered).
Discussion
(Steve Kelly?): Extended (?) headers are a big mistake based on my
experience with RFC 843[?]; I recommend avoiding them. They never go away.
Thoughts on iCAP and SOAP (C. Maciocco, R. Menon)
Christian Maciocco presented a report on iCAP and SOAP Remote Callouts. The
presentation was focused on bringing out potential suitability of SOAP and
iCAP for different callout scenarios and highlighted some key strengths and
weaknesses of SOAP and iCAP when considered for OPES callout.
Discussion:
(Larry M): On asynchronous notifications: iCAP over BEEP may overcome this.
SOAP doesn't clearly buy much. This is like choosing which hammer to drive
the screw with. Layering other protocols on top of HTTP seems to ignore the
problem of intermediaries or edge services or endpoint services operating on
the messages, which contain the control traffic. We need to have some way
to ensure that intermediaries get out of the way of control traffic.
(Question): I don't see a good application of SOAP here. It's not built for
performance. Maybe it could be used out of the control channel... It's
useful for extensibility.
(John Martin): iCAP has no support for streaming. I want to caution against
using it for this. ICAP is defined to be simple; it may be possible to use
it as transport. Point-to-point between closely coupled systems, in a
single administrative domain. Son-of-iCAP may address streaming.
(Question): SOAP is appropriate for much of what is needed.
(Lee): We don't just have a limited set of services. We need to support any
service currently on the Internet. The SOAP community will be large; it
looks like iCAP may be small. We should use SOAP.
Edge Side Includes
Mark Nottingham presented a report on Edge side Includes (ESI). ESI is
being published as a note in W3C, not in IETF. There is a W3C workshop
planned. More than ten vendors are involved. Will put info on ESI on OPES
mailing list. As a summary comparison, OPES is modeled around
intermediaries and callout servers, while ESI can do it on the edge.
Depending on the trust model, it may carry instructions in the content to
assemble it on the edge.
Discussion:
(Fred ?): Why is a trust relationship needed?
(Mark): Out-of-band relationship may determine this.
(Gary T.): OPES has rules, can establish a trust relationship.
(Elliott): Date/Time as well as geography sensitive content is defined in
OPES. How do you handle this type of content in ESI?
(Mark): There are several methods. One is to use metadata selectors.
PCI Callout Server
Abbie Barbir presented a report on an example of an OPES callout server, a
personalization service based on the Personalization Content Framework.
This will be developed as an OPES draft.
Discussion:
(Question): Will a client be aware of intermediaries?
(Abbie): The OPES devices including the callout servers will be transparent.
ECMA update
There was not sufficient time for Rama Menon to present a planned report on
the ECMA meeting where iCAP was considered for standardization with in ECMA.