more comments...
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Monday, May 20, 2002 10:24 PM
To: Ian Cooper
Cc: OPES Group
Subject: Re: WG Last Call: draft-ietf-opes-architecture-00
Ian Cooper wrote:
Speaking of Figure 3, it's not immediately clear what's
going on, making
the appearance of the data dispatcher box different to the callout
servers might help.
Hm, when looking at Figure 3 i nthe draft... I would assume the term
"callout server" refers to the box itself, thus being the
correspondence to "data processor", rather than being part of the
protocol stack as shown in Figure 3. It seems to me that something
like that would be more accurate.
data callout callout callout
processor server server server
+----------+ +---------+ +---------+ +---------+
| data | | service | | servive | | service |
|dispatcher| | applic. | | applic. | | applic. |
+----------+ +---------+ +---------+ +---------+
| | | | | | | |
| OCP | | OCP | | OCP | ... | OCP |
| | | | | | | |
+----------+ +---------+ +---------+ +---------+
| TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP |
+----------+ +---------+ +---------+ +---------+
|| || || ||
||================ || ... ||
|| || ||
||============================== ||
|| ||
================================================
yep, the same we did for the picture. The "upper entities" are not part of
the stack per se
The sort of design I might suggest would be that an OPES
intermediary
maintains an audit of services that are applied, possibly
for a limited
time. This audit should be accessible to affected clients
using standard
features of the protocol whose flow is being OPES-serviced.
Seems reasonable, though would only work for a subset of the
protocols
that might benefit from modifications these systems might
offer. E.g.
if video stream is modified I'm not sure that it would be
possible to
use the streaming delivery protocol to get acccess to the
audit trail.
It does work for HTTP which was the primary target of this
body of work
though.
I agree with that. Keeping up state in the OPES intermidiary it might sound
good on paper but I'm not sure it will scale. It would be the same thing to
ask a web server to be able to read through recent log files in order to
provide this information to any user real time.
Why restrict it to the standard features of the data flow protocol? I
would assume it's possible to indicate within the OPES trace HOW an
endpoint could access such audits, potentially allowing/using other
standard protocols (e.g. HTTP, FTP, or whatever). Architectural wise,
this should be covered by the current draft...
So, I kind of agree on what was proposed of conveying this info through
alrady avalable means, but keeping state is touchy. Just like email, you get
all the headers, now if the SMTP servers on the way, keep ot not that
information is up to the administrator.
-Reinaldo