to share OPES operations experience

Dear Hilarie,
thank you for your comments. I respond on the list, but I am not sure it is 
appropriate as it seems more an interaction over a project than a debate 
over a document preparation.
On 19:33 30/01/03, The Purple Streak, Hilarie Orman said:
> First, this is a public mailing list, see the ietf.org website about
> policies governing working group mailing lists.  Don't post anything
> here that you want "protected" or "respected" by competitors.
I understand this. This is why I asked about other places. I only follow on 
Abbie's suggestion. When I say "respected", I mean "please do not flame me 
because I do not tell you everything you may ask". I will try however to 
detail what I can. If this is felt appropriate by the members of the list.
> OPES works with HTTP messages.  We may address RTP in the future.
I said that I have a wider vision, documented for a long, of the "network 
extended services", where OPES fit in. As explained I do not want to 
dispute semantics, I just work on some architecture which may help as an 
example and benefit from your inputs. I am not limited by the protocol.
> Your "overlay" looks very much like an ordinary operating system's
I suppose what I name "underlay"? "Overlay" is the word used for the 
callout system as far as I understand?
> API to network protocols, so I'm unsure what its point is.  Your comment
> about "not necessarily under IP" is confusing because it's more common
> to speak of these protocols as running "over" IP (or do you you mean
> "intellectual property"? :-)  ).
Accepted. Frenglish, sorry. But it also wants to render "not under the 
limitations imposed by IP". I understand that the same rationale applies to 
the callout protocol considerations?
Now, you may see on my draft that entries into the dispatcher may come from 
an external I/O, from OPES one, from the callout interface relating with a 
remote OPES. And the same for outbound traffic, from the dispatcher into 
any of those interface and through the callout protocol into other systems.
I feel this is conform to the OPES scheme, however not draft the same way. 
This shows the way the dispatcher is used. There may be non documented 
presentation functions to convert from a protocol to the dispatcher and 
from the dispatcher level to another protocol level. Right now, I keep them 
into the I/O blocks (they might be or not by-passed if the "in" and the 
"out" protocol were the same?). So they are not just APIs.
> Trying to continue guessing, I'll ask
> if you mean that the "dispatcher" is remotely controlled, using something
> like OPES rules?
No. This why I use the word "underlay". The dispatchers may relate together 
to stay mutually informed, for example about some thresholds they have 
reached which might affect rules.
They might also exchange meta-data over the callout protocol to speed up 
some exchanges in a more specific manner, for example?
> Are you suggesting that this function be implemented as a "web service"?
It depends on what you name a web service. I suppose it could use a service 
- like a shared repository. But I doubt it could use a controller: this 
could conflict with the dispatcher rules. Obviously the rules could be 
remotely controlled. But it seems too rigid a concept. This is not 
automatism, but telematism. There are delays, risks of failures etc. Each 
system should be standalone. Related, not tied.
> A few years ago I saw a system called "Delegate" that provided a
> fairly general API so that people could write filters that could take
> in data from one (protocol, port) pair and forward that data (possibly
> altered) to another pair or deliver it locally.  It might be closer to
> what you are describing than OPES is.
Really interesting. Do you recall where I could find details.

> OPES is more specific, and it concentrates on some details of HTTP (and 
> possibly RTP) semantics, the callout protocol, and issues about 
> configuration and tracing.
I am ready to accept that. This is why I asked and said that what we have 
in mind might not fit. Yet, are not protocol verification and conversion 
services as any other one? I miss the reason why the callout protocol would 
be HTTP/RTP specific?
> It might help the discussion if you could give some examples of what you'd 
> like to see systems like this do.
As I said, right now we are investigating what we are involved in. To 
understand the architecture, find the most appropriate design, development 
tools, network system to use to switch information between related systems, 
where to place them. It may take time. OPES examples have been given in a 
specific IETF-draft. We are OK with them as test examples.
Let say for discussion sake that we have three OPES, one, two, three. OPES 
one is on the main machine, OPES two on another machine with the same 
technology, connected through the underlay network and using callout 
protocol. OPES three is on a third party machine connected through the 
callout protocol alone.
From then I try to understand how it works. I feel that considerations 
quoted about the callout protocol might have to be addressed between the 
I/O block and the dispatcher? Also I am not certain where the loops in the 
dispatcher are checked and blocked in the OPES scheme? But may be I just 
not fully understood the things.
jfc