Subject: OPES BOF, IETF 50.

From: "Michael W. Condry" <[email-masked]> (by way of "Michael W. Condry" <[email-masked]>)
Date: Fri, 13 Apr 2001 10:26:44 -0700

OPES  50th IETF
Tuesday 9am
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 
ranging from the scope of charter to the protocols that should form part of 
the charter. The forum approved the key concepts in the 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 Rafalow 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: [David] - Given a set of rules we need to know the behavior. RFC 3060 
has some non-deterministic behavior that it permits in that it doesn't 
require that priority values be unique and therefore doesn't have a 
deterministic order of action execution or even rule selection when 2 rules 
have the same priority.

A: [Lee]- This issue was raised at the Policy working group & shot down at 
last call. The extensions draft currently being developed as an update to 
3060 does require unique priorities and is therefore deterministic in the 
selection of rules and the order of action execution.

Q: Policy tree should be able to be set dynamically as end-user rules might 
not be known in advance.

A: [Lee] The network states are dynamic. Policy adaptation is different 
from policy specification and is a composition of policy and network state 
analysis, but the policy is unchanged.

Q: Priorities can change dynamically?

A: [Lee] Priority is part of the policy and therefore relatively static.

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)

A. [Lee] Login operation does not cause rules to be created, it causes 
network state to change and the rules guide behavior based on examining 
states (usually expressed in packet fields but not always).

Q: [Markus] - Where are the rules matched in the data flow?

A: [Lee] The list of processing points is not set by the architecture. The 
architecture has a capability to specify roles that resources can assume 
(e.g., client request handler) and then rules can be written for those 
roles. It delays the decision of what the roles are to a product 
implementation and network deployment.

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 [email-masked]

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

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 14 Apr 2001 00:04:25 +0100 (BST)

> OPES BOF met at the 50th IETF in Minneapolis on Tuesday March 20th, 2001. 

Great. Now, if you could just tell us what OPES and BCDF are...

imo it's generally helpful if such BOF minutes have some introductory
descriptive material and spell out abbreviations to provide some
context.

L.

> "arbitrary" from the opening paragraph of the charter.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>