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 PROTECTED] 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
