OPES 50th IETF
Tuesday 9:00am
Minneapolis, MN
Co-chairs: Michael Condry, Hilarie Orman
Overview
OPES BOF met at the 50th IETF in Minneapolis on Tuesday March 20th, 2001.
There was a lot of interest in the BOF with more than 125 participants
attending the BOF. There were discussions on:
- Charter
- Rules
- Rule Engine
- Taxonomy
- Policy framework
- Callout services
- BCDF requirements
Charter definition
The discussion on charter was very lively covering a variety of topics from
protocols to the scope of charter. The forum approved the modified charter.
Discussion:
It was discussed that the OPES Working Group should specify a "wide range"
of services rather than "arbitrary services". It was agreed to remove
"arbitrary" from the opening paragraph of the charter.
Hilarie expressed concerns about limiting the scope of OPES to HTTP only.
Larry Masinter agreed that the charter could be broadened to RTP and RTSP.
Larry also recommended not going toward SMTP and/or FTP. The charter would
be too broad as these protocols have different characteristics and
requirements.
The question came up how rules & policies in the OPES framework collaborate
with related work going on in the IETF.
Hilarie mentioned that ICAP is not the sole protocol to be considered for
callout, others will be considered as well.
Presentations
There were several presentations on OPES related components. The summary of
these presentations is captured below.
Rules
Markus Hofmann presented the Rule related material. There was very active
discussion related to several areas related to the requirements and framework.
Discussion:
Q: [Larry Masinter] - He suggests keeping things separate: (1) the Service
itself, (2) the mechanism to describe the service, and (3) the protocols
running rule language communicating to the transform service (thought that
this would be what the callout protocol would focus on).
A: [Markus] - This is similar to the approach currently discussed in some
Internet Drafts IRML separates rule description, OMML separates service
description, protocol for callout services (e.g. iCAP) is also separate
from protocol for rule distribution (e.g. secure file transfer) etc.
Q: OPES should NOT leave the rule conflict resolution out of scope.
A: [Hilarie] Need to find out where rule conflict resolution does fit in
the requirements document.
A: [Markus] Rule conflict resolution is NOT considered out of scope for
the OPES work, but he considers it separate from the specification language
for rules. Mentions that rule conflict resolution also depends on business
arrangements.
Q: Rule conflict resolution has to be considered in order to meet the
expectations. Experience has shown that this requires adding support within
the rule specification language.
A: [Markus] - Acknowledges that it might be necessary to build hooks into
the rule specification language to allow conflict resolution, but the
conflict resolution itself should NOT be part of the language and should be
handled separately.
Q: [Larry Masinter] - mentions that we are approaching the problem
backward. We should instead start with the callout protocols and then we
would understand what format the description would take.
Rule Engine Requirements
Lily Yang made the presentation on Rule Engine Requirements. The
presentation covered several aspects of the Rule Engine illustrated with a
sample use case.
Discussion:
Q: [Lee] - What are the requirements for passing state either out of the
box or in-between boxes? What are the requirements to keep state from the
request to the response?
Network Taxonomy
Rob Erickson presented the network taxonomy. There were no specific
questions on OPES taxonomy.
Policy Framework
Lee Raffalow presented the OPES policy framework. There were some detailed
discussions around rules, meta rules and system behavior and associated
policy issues. The discussions concluded with remarks on how the work in
this area by other IETF WGs should be considered.
Discussions:
Q: Meta-rules should be out of scope as in the policy framework but should
not be ignored. Hilarie mentions they should be within scope. Need to
carefully consider where they might be needed and consider their implications.
Q: Given a set of rules we need to know the behavior. This becomes very
complex very quickly.
A: This issue was raised at the Policy working group & shot down at last
call. The RFC still went forward not having this property).
Q: Policy tree should be able to be set dynamically as end-user rules might
not be known in advance.
A: [Lee] - answered that in the policy framework policies are fairly static.
Q: Priorities can change dynamically
A: [Lee] - Not addressed in the policy framework.
Q: Need to consider frequent addition or changes to rule base (user logs
in, takes actions that draw in new rules, rules that get modified, etc)
Q: [Markus] - Where are the rules matched in the data flow?
A: [Lee] - answered that the framework removed the processing point from
the architecture allowing the rule writer to specify as many processing
point as he wants (using a separate mechanism).
Q: [Hilarie] - Mentioned that there are known cases where rules priorities
failed.
A: [Lee] - has not seen any such cases with the usage example so far.
Q: Charter mentioned integrity, need to know that the conflict resolution
works to preserve data integrity.
A: [Hilarie] - Concerned that only a subset of the rules is taken into
account for integrity. Need to add to requirements that all rules are being
taken into account.
Callout
Hilarie Orman (Volera) presented on Callout services.
Discussions:
ICAP hasn't addressed all the processing point that occurs into a proxy.
Callout service takes data into another protocol dimension and there is a
need to track intermediate state. We can have a new protocol or
encapsulate the original one. Handling the notion of related connection,
their identifiers and the state of related connection is difficult to do.
BEEP is suited for proxying and to carrying related connection information.
The BEEP framework seems to be the best fitted for callout services.
Q: [Hilarie] - Has anyone looked at carrying encapsulated protocols over BEEP?
OPES will have to carry a fair amount of connection state to the callout
services.
Q: Speaker agrees w/ Hilarie. Is this the time to consider also the session
layer above TCP, which will handle the session state for different
protocols (RTP...)?
BCDF
Michael Vernick presented on BCDF requirements. The presentation was handed
out to the attendees and they have been asked by Michael V. to send
comments on the BCDF end-to-end requirements document to vernick(_at_)lucent(_dot_)com
Discussions:
Q: [Hilarie] - asked if the BCDF defined a protocol for some of their
functions such as content pre-positioning?
A: [Michael] - mentioned that the BCDF issues requirements which would be
like: "Need a protocol to support pre-positioning of content"
Conclusion
The OPES BOF was a widely attended meeting and the key results were
ratification of charter and very good discussions based on presentations on
some of the key components in the OPES framework.
Michael W. Condry
Director, Network Edge Technology