Graham,
> There's nothing like a last-call to raise a reviewer's priorities,
> right?-)
It can even overcome dead silence... :) Thanks for your feedback and
for breaking the ice. While trying to catch up with emails, let me
pursue some of your comments... I would expect some of the ID authors
to jump in as well.
> Section 1 ---------
>
> The first paragraph mentions customization based on geographical
> locality. Taking this as an example, I didn't notice anything
> later in the document about the source of information that an OPES
> processor might use as the basis for customization services. I
> think some discussion might be appropriate; e.g. is any such
> customization to be based on information provided by the party with
> respect of whom the customization is being performed? Or
> conversely, If I connect via an ISP in a foreign country, might I
> expect to get information customized for that country? I think
> such sources of information should at least be clearly identified
> in any trace information.
Should this kind of service-specific information (e.g. the source of
customization information) really be part of the general OPES trace
information? Wouldn't it be sufficient for OPES to provide trace
information that identifies the performed OPES service, and provide a
pointer from where an interested endpoint could obtain more detailed
information (e.g. the source of customization information for that
specific service)? This would be more flexible and scale better, since
it seems challenging for general OPES traces to provide all possible
aplication-specific trace information. OPES could just supply a "trace
pointer" that would allow the endpoints to obtain the more
(application-specific) information if desired.
> Section 2.0 ----------- Do OPES entiries include the provider and
> consumer? It's not clear to me. The second bullet here suggests
> "yes", but elsewhere suggests "no".
From an OPES perspective, I would assume "no", so we need some
re-wording here. Maybe something like
"OPES flows: data flows that are cooperatively realized by
a data provider, a data consumer, and zero or more OPES entities."
This would also need some re-wording in the last paragraph of section
2.1, maybe something like
"The OPES architecture is largely independent of the protocol that
is used by the DATA CONSUMER AND THE DATA PROVIDER to exchange
data."
> Section 2.1 ----------- The distinctive roles of OPES service
> application and data dispatchers aren't entirely clear. I would
> expect what you describe as an "Opes service application" that sits
> on the provider-consumer flow to contain the architectural elements
> you describe under "data dispatcher".
The "data dispatcher" is meant to be sort of a filter that determines
which messages have to passed on to which "OPES service application(s)".
The "data dispatcher" always sits on a data processor box, while an
"OPES service application" can reside on either a data processor box
or a callout server.
Messages always pass through a "data dispatcher" before possibly being
hand over to an "OPES service application", which can reside locally
on the same data processor box as the "data dispatcher", or remotely
on a separate "callout server".
Not sure whether the above might help, but I agree that we need some
cleanup here.
> Section 2.2 ----------- Where you say "one or more OPES service
> applications" and "one or more data dispatchers" I think you mean
> "zero or more". Later you mention "zero or more..."
Yup, also one might say that if there are zero OPES service
applications and zero data dispatchers, this is just a regular data
flow, no OPES at all.
Maybe it should read "one or more data dispatchers" and "zero or more
OPES service applications", since an OPES system is charaterized
through the existence of a data dispatcher (i.e. all messages go
through this data dispatcher), but it is not necessary that an OPES
service appliation always gets executed.
> 2nd para: I found this description rather woolly. Would any
> significant meaning be lost if the second sentence of this
> paragraph were to be deleted?
I'd assume no, although one interesting aspect might be that data
processors and callout servers can reside in different admin domains...
> 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.
> Section 2.4 ----------- Maybe this is just a personal preference,
> but talking about "executing" a ruleset seems to be very
> implementation-choice-oriented; would "evaluating" not be closer
> to what you mean here?
Agreed.
> You also discuss using "the OPES callout protocol", which seems to
> say there is a single such protocol. It is not clear to me why
> there needs to be a single such protocol, as different
> dispatcher/server combinations might use different protocols
> according to the needs of the application. For example, I'd
> imagine a session-oriented protocol appropriate for an HTTP callout
> service, but for processing email flows a callout protocol based on
> email style messaging, or file sharing, might be more appropriate.
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.
> Maybe there are reasons for defining a single protocol here: if
> so, I think they should be explained.
Yes, agreed, but this should be the outcome of some discussion in the WG.
> The final sentence of the final paragraph is impenetrable to me.
> What's this "...service aware vectoring capability that parses the
> data flow according to the ruleset..."?
Yup, wording is somehow confusing. I believe it means to say that
although the OCP itelf is application agnostic, the data dispatcher
must very well be aware of the syntax and the sematics of the data
flow protocol (see previous discussion on this list on "no-transform &
warning").
> 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? I could
imagine that the general OPES tracing simply provides pointers and
information to the endpoints on (a) which OPES services had been
executed on the message, and (b) how the endpoints could retrieve more
information about these services, possibly including an audit. I don't
see the current draft would exclude something like that.
> Section 3.2 ----------- This touches on an area where I take issue
> with the IAB requirements on OPES (and have posted my comments
> elsewhere).
>
> [[ The primary data flow occurs between the data provider and the
> data consumer. OPES must not interfere with the capability of
> these parties to use end-to-end authentication and confidentiality.
> ]]
>
> Consider the case of an employee working for a corporation. I is
> the employee or the corporation considered to be the "data
> provider" or "data consumer" here. I particular, is OPES required
> to allow an employee to send encrypted data out of the organization
> without examination by an intermediary system?
Hm, one view expressed earlier is that the employee is the enduser and
the corporation runs the OPES system. Per employment agreement, the
enduser gives the corporation (i.e. the OPES provider) the right to
filter the data, i.e. the employee allows the corporation to install
the corresponding OPES rules. That might be controversial, but one
possible view. An alternative would be to rule out the possibility to
use OPES for these kinds of services...
-Markus