Subject: RE: to share OPES operations experience

From: jfcm <[email-masked]>
Date: Thu, 30 Jan 2003 16:15:38 +0100

On 16:24 29/01/03, Abbie Barbir said:
>Hi,
>In my opinion, u can start on this list.
>if it gets too wild, we can move it to somewhaere else.

Thank you. May be not too wild, but I may ask things already discussed (I 
had not time to read the whole archives I cannot FTP) and I may be 
confusing because I includes OPES into a broader architecture, I sold as 
"Network Extended Services", a long ago. My target is not to discuss that 
aspect before I have fully understood what has already been done and 
discussed in here.

Since this is public list I will also try to keep general and I thank you 
to respect whatever could be IP worth.

Basically I am trying to develop a test simple yet operational system and 
to gain technical, commercial, legal, operational experience from it. I 
will name the project "smart pipe". The idea is to get data flows and to 
forward them to the final host (at least for us). To see how it works and 
then to build from it. This is very basic: i suppose some already done it?.

First point is that we may get data in through several protocols and data 
out though several other protocols. Has someone developed something already 
in that area or a doctrine?

Next is what type of system should we develop? Web services are supposed to 
be http related. Has someone developed an experience? or comments?

I understand OPC is to relate with other OPES through an "overlay" (I am 
not sure the meaning is good). I feel there is also a need for another 
relation (I would name "underlay" what may carry a good image) interworking 
dispatchers.

So the design I think about is as follow ;

(fixed character set)

              +------------------------+
underlay <===| open services internal |===>
              [ remote internet switch |
              +------------------------+
           ---|    HTTP I/O      |  D  |
              +------------------+  i  +
           ---|    FTP I/O       |  s  |
              +------------------+  p  +
           ---|    MAIL I/O      |  a  |
              +------------------+  t  +
overlay   ---|    OPC           |  c  |
              +------------------+  h  +
              |    Statistics    |  e  |
              +------------------+  r  +
              |    local OPES    |     |
              +------------------+-----+

I note that the OPC protocol would be embedded in the underlay network 
protocol when the remote OPES is under our own same architecture. Also, if 
we have this architecture managing the whole telemate (tele-automate) the 
underlay network system would form some kind of network operating system 
not necessarily under IP.

I would be interested in every comment. Thank you.
jfc

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 30 Jan 2003 11:33:54 -0700

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.

OPES works with HTTP messages.  We may address RTP in the future.

Your "overlay" looks very much like an ordinary operating system's
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"? :-)  ).  Trying to continue guessing, I'll ask
if you mean that the "dispatcher" is remotely controlled, using something
like OPES rules?  Are you suggesting that this function be implemented
as a "web service"?

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.  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.

It might help the discussion if you could give some examples of what
you'd like to see systems like this do.

Hilarie