Subject: RE: Draft Agenda for IETF 56

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 12 Mar 2003 06:39:51 -0500

Hi all,

This discussions are really getting interesting.

However, it seems to be that we should fundemantely agree on the deployment
(where, what and for what) of OPES in the services area.

The discussions give me the feeling that we are trying to design a (very
flexible) system that is looking for a place in the field.

I could see the benefits to have various bindings for the callout protocol.
It gives felexibility. But at what expense? I really have problems
developing an architecture/protocols that can go all over the field.

The architecture document states that the example protocol is HTTP. I know
that we should be open minded in the design of the callout protocol.

However, I would like to start with HTTP and then come up with a callout
protocol that can work with it. After that, I would like to see how we
address all of the IAB issues regarding OPES. We can then move the excerise
to RTP (SRTP etc..), and use that knowledge to ensure that we have a
flexible protocol.

At this point, the issues of notification/tracing have not been brought up
(yet?). 

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Wednesday, March 12, 2003 12:24 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
> 
> 
> 
> 
> On Tue, 11 Mar 2003, Markus Hofmann wrote:
> 
> > General question now is whethr we feel that coupling the transport 
> > protocol for the callout to the application message protocol is 
> > flexible enough, or whether we need more flexibility?
> >
> > For example, is it OK to assume that whenever the 
> application message 
> > protocol is A, that the transport protocol for the callout 
> is B. Or is 
> > there a case to make that for the same message protocol A, we 
> > sometimes need to use transport protocol B for the callout, and 
> > sometimes transport protocol C (substitute A, B, and C with your 
> > favorite protocols :) If so, how is this achieved without protocol 
> > negotiation?
> 
> I was not on that conference call so I may be missing some 
> important caveats. Said that, it seems to me that we should 
> not care about the ways transport protocols are selected as 
> long as we do not have to support true negotiations. In most 
> cases, protocol selection can be handled by static 
> configurations (with rules if needed), and should be out of 
> our current scope.
> 
> No need to limit the selection/matching rules; just prohibit 
> in-protocol negotiations. Let implementations decide what is 
> the right protocol selection method is.
> 
> $0.02,
> 
> Alex.
>

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 12 Mar 2003 08:28:24 -0500

> At this point, the issues of notification/tracing have not been brought up

Absolutley correct and an important point!! Is there anything me must 
consider in the callout protocl design for tracing and notification? I 
would assume so... Any thoughts?

While probably separate from the callout protocol design, we also need 
to discuss possible impact on the application message protocol, for 
example for an "OPES bypass" mechanism. This refers to the requirement 
that a user must be able to signal an OPES processor that (s)he wants 
to bypass any OPES service (one of the IAB requirements)  - as briefly 
discussed some time earlier, using (user-defined?) HTTP headers might 
be an option.... So we also need to consider possible 
impact/extensions on the application message protocol. Anyone some 
thoughts on this one?

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 09:10:46 -0700 (MST)

On Wed, 12 Mar 2003, Abbie Barbir wrote:

> The discussions give me the feeling that we are trying to design a
> (very flexible) system that is looking for a place in the field.

I do not think the situation is that bad. We are trying to design a
flexible system with a few _known_ places in the field. We have a use
cases draft. We have every existing ICAP system as a "place". We have
a few other very specific examples discussed on the mailing list.

There were some very vague discussions/examples as well. Perhaps they
create an impression that we are designing a general-purpose no-place
system. The primary reason vague examples and requirements should be
discussed is to make them specific; at that point they can be included
in or excluded from OPES scope.

> I could see the benefits to have various bindings for the callout
> protocol. It gives felexibility. But at what expense? I really have
> problems developing an architecture/protocols that can go all over
> the field.

I agree that it is easier to design with one binding in mind. However,
I am in favor of a slightly different "lazy binding" approach: design
without specific bindings until specific bindings become necessary to
proceed. Most of the issues that have been discussed and solved so far
are binding-independent. I would suggest to postpone any binding
decision until it actually becomes necessary.

There is some overhead in this approach, but I think it is small. On the
other hand, it is much more expensive (and often nearly impossible) to
add bindings to a single-binding protocol.

> The architecture document states that the example protocol is HTTP.
> I know that we should be open minded in the design of the callout
> protocol.

I try to keep the following list of protocols in mind:
	Application protocols it would be nice to support:
	- HTTP
	- SMTP
	- RTSP
	- instant messaging protocols

	Transport protocols we may want to support:
	- raw TCP
	- BEEP over TCP
	- HTTP over TCP
	- SOAP over the above

I still need to learn more about SCTP, but it should be added to the
above transport list.

With application protocols, we want to support as many as possible.
With transport protocols, we want to have just the necessary binding(s).
But, again, I prefer to make decisions when they become necessary.

> However, I would like to start with HTTP and then come up with a
> callout protocol that can work with it. After that, I would like to
> see how we address all of the IAB issues regarding OPES. We can then
> move the excerise to RTP (SRTP etc..), and use that knowledge to
> ensure that we have a flexible protocol.

I disagree with the ordering, but I think we can still work together
while preserving the differences in approaches: you can assume HTTP in
all future discussions (while keeping the end goal in mind), and I
will assume a group of protocols. There should be no significant
design conflicts until we actually have to make the decision of what
application protocols to support.

I think adding support for very different application protocols on top
of a nearly finished OPES design will lead to kludges and inferior
results.

> At this point, the issues of notification/tracing have not been
> brought up (yet?).

I am finishing up the next version of the predraft protocol. The
biggest new additions are cleaner message hierarchy and connection
management functions, based on the discussions on this list. I plan to
address tracing and user preferences next, unless somebody beats me to
it.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 09:20:45 -0700 (MST)

On Wed, 12 Mar 2003, Markus Hofmann wrote:

> While probably separate from the callout protocol design, we also
> need to discuss possible impact on the application message protocol,
> for example for an "OPES bypass" mechanism. This refers to the
> requirement that a user must be able to signal an OPES processor
> that (s)he wants to bypass any OPES service (one of the IAB
> requirements)  - as briefly discussed some time earlier, using
> (user-defined?) HTTP headers might be an option.... So we also need
> to consider possible impact/extensions on the application message
> protocol. Anyone some thoughts on this one?

You are right that this is pretty much unrelated to the callout
protocol: calls should no go out if OPES is being bypassed. The only
related aspect is that the callout protocol may have to pass user
bypass instructions/preferences _if_ we want to support selective
bypass (e.g., "bypass only this OPES/service"). I am not sure we need
that kind of selectivity at this point.

For each supported application protocol, we would need to define ways
to pass OPES preferences and tracing information. It should be fairly
easy for any application protocol that supports extensions (e.g., HTTP
and SMTP).

The first thing to decide is probably OPES identification/addressing
system that will be shared by both tracing and bypass OPES features.
What do we want to identify and/or address?
	- just OPES processors
	- OPES processors and callout servers
	- OPES processors, callout servers, and services
	- other?

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 12 Mar 2003 11:52:27 -0500

Alex Rousskov wrote:

> I agree that it is easier to design with one binding in mind.
> However, I am in favor of a slightly different "lazy binding"
> approach: design without specific bindings until specific bindings
> become necessary to proceed. Most of the issues that have been
> discussed and solved so far are binding-independent. I would
> suggest to postpone any binding decision until it actually becomes
> necessary.

This is the approach we had in mind with the "SHOULD be protocol
agnostic" requirement. We start the design without assuming a specific
application protocol, and only when it turns out that we need to the 
bind it to a specific application protocol, we'll do so - and we'll 
bind to HTTP in that case.

Now, the need for such binding may arise if the "protocol-agnostic" 
approach should turn out to add too much complexity  - meaning we need 
to strive for a good balance between generality and complexity of the 
callout protocol.

> I think adding support for very different application protocols on
> top of a nearly finished OPES design will lead to kludges and
> inferior results.

Yes!

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 12 Mar 2003 12:15:06 -0500

> that kind of selectivity at this point.

Isn't this kind of selectivity provided by the OPES rules? If a user 
wants to use OPES services, in general, but wants to bypass specific 
services, this should be reflected in the user's rules rather than 
"in-band" in application messages...

With respect to the callout protocol possibly having to pass user 
bypass instructions/preferences... I assume the OPES processor 
includes explicite instructions on which services to execute in the 
callout protocol messages. As such, not including a specific service 
implies that it won't be executed, implicitely implementing a "bypass".

Think we're in agreement...

> 	- OPES processors, callout servers, and services

For tracing it seems we need to identify all three, meaning OPES 
processors, callout servers, and the services, implying we need an 
identification/adressing cheme for all three of them. This should also 
cover the bypass and debugging feature.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 11:15:28 -0700 (MST)

> implies that it won't be executed, implicitely implementing a "bypass".

What I am worried about is the ability of a callout server to delegate
processing to other servers (I think processing delegation is allowed
in the architecture draft). Depending on how selective our rules are,
it is possible that the bypass rules did not match on the original
OPES dispatcher but would have matched on some remote callout server
two OPES hops away. Will that server have enough information to
activate bypass mode?

Another way to look at this is the services granularity. Here is an
example:

	User (or rules) say: bypass any opes:filtering/porn service
	for responses

	OPES dispatcher is configured to forward all responses
	to an opes:filtering/cisco-defaults service. The names
	do not match, so the response is forwarded to the callout
	server.

	The opes:filtering/cisco-defaults service forwards the
	response to opes:filtering/virus and opes:filtering/porn
	callout servers/services.

	Will the opes:filtering/porn service know to bypass?

Can the answer be derived from current drafts?  If not, future OPES
identification/addressing work should answer this question.

Alex.