OPES BOF Minutes
IETF 51, Tuesday 7 August, 0900
Co-chairs:
Michael Condry (condry@intel.com (mailto:condry@intel.com))
Markus Hofmann (hofmann@lucent.com (mailto:hofmann@lucent.com))
Technical Team Lead:
Hilarie Orman (horman@volera.com (mailto:horman@volera.com))
Applications Area Directors:
Patrik Faltstrom (paf@cisco.com (mailto:paf@cisco.com))
Ned Freed ( ned.freed@mrochek.com (mailto:ned.freed@mrochek.com))
Notes taken by Paul Knight ( paknight@nortelnetworks.com
(mailto:paknight@nortelnetworks.com) ) and Rama Menon
(rama.r.menon@intel.com (mailto:rama.r.menon@intel.com) )
NOTE: The presentations are now available at the OPES website www.ietf-opes.org (http://www.ietf-opes.org), under the "Calendar of Events" tag, "IETF51".
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 Siddiqui): 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 Hardie): 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 Hardie): 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 Douglis): 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 insufficient time for Rama Menon to present a planned report on the ECMA meeting where iCAP was considered for standardization with in ECMA.
None received.