-----Original Message-----
From: jfcm [mailto:info(_at_)utel(_dot_)net]
Sent: Thursday, January 30, 2003 8:04 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: 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