thanks for the responces,
see remarks inline
abbie
-----Original Message-----
From: Graham Klyne [mailto:GK-lists(_at_)ninebynine(_dot_)org]
Sent: Tuesday, May 21, 2002 6:37 AM
To: Markus Hofmann
Cc: OPES Group
Subject: Re: WG Last Call: draft-ietf-opes-architecture-00
SNIP
Section 2.3 ----------- It seems to me that the OPES rules are a
cornerstone of the architecture, but very little is said about
them.
For the architecture we just need to describe their existence and
where/how they fit in, but not their (internal) details.
I agree, not their internal details.
But some kind of indication of the scope of possible "conditions" and
"related actions" would be useful; e.g. for the conditions,
presumably
there are expected to be mechanisms for testing the protocol
parameters and
data content? And if examining data content, what sort of level of
analysis is expected to be supported?
I guess this boils down to identifying some (broad)
requirements on the
standardized rule schema. At least to the extent of giving some
understanding of how much is expected to be handled by the
filtering rules,
and how much is left to a callout processor.
The purpose of the architecture document is just to mention the rules. The
details need not be part of it. If there is enough interest, the need for an
example document may arise, and then some examples of the rules may be
presented. Here keep in mind, the architecture documnet needed to be focused
and to the point.
SNIP
The goal is to have a single callout protocol independent from the
protocol being used in the data flow. Whether this is
possible or not,
we'll see. Also, our current charter is restricted to HTTP
and RTP/RTSP in
the data flow.
yes, the goal is to have a single OCP that is seperate from the one that is
used in the data flow.
I thought about this a little more - is it a goal to have
multi-vendor
interoperability between data dispatchers and callout
servers? If so, the
role of OCP is clearer.
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.
Would you say that the current draft rules out such a design?
My my reading, yes, since it seems to depend on protocol extensions.
agreed.
SNIP
Yes, I see you responded too. Maybe I misread the intent here.
The sentence that disturbs me is this:
[[
The OPES architecture **requires** that tracing be feasible
on the OPES flow per OPES processor **using in-band
annotation** through
header **extensions** on the application protocol that is used (e.g.,
HTTP).
]]
I think the requirement here should be that tracing is
feasible *without*
using extensions on the application protocol. (Not saying
that extensions
MAY NOT be used, just not required to get at tracing information.)
The problem here is that tracing can be in-band or out of band.
in band will require header extensions. Out of band will not, but the
question will be where and by whom it is supported.
The IAB requires the architeture to provide tracing.
SNIP
abbie