--On Monday, May 20, 2002 13:28 -0400 Oskar Batuner <batuner(_at_)attbi(_dot_)com>
wrote:
Some notes on the OPES Architecture draft..
1. Introduction
In some cases it may be impossible to offer the customization service
at either the provider or the consumer applications. In this case,
one or more additional application entities may participate in the
data stream service.
This term - "impossible" - may leave an impression that this is the
only, or at least main justification to use OPES. This does not look
right. The only scenario (from existing draft-beck-opes-esfnep) where
OPES is the only way to implement the service is request filtering
for hand-held devices, in all other cases service can be implemented
either at the server side or at the client side, or both.
In fairness I think it's fair to say that there are cases where it's
impossible to insert localised advertisements without something like an
OPES intermediary.
Still use of OPES may be beneficial, so I'd suggest ether to use
a different wording, like:
"In some cases in may be beneficial to provide a customization service
at network location instead of deploying it at either the provider or
the consumer host. For certain services performed on end-user behalf
this may be the only option of service deployment".
That seems limiting and doesn't seem (to me) to convey the aspect that some
content can only be produced with the cooperation of (possibly
non-exportable) information available to the ISP/IAP. The problem is that
without concrete examples (which are frequently limiting in themselves) it
becomes very difficult to write introductory text like this. The existing
text (plus the introductory paragraph you omitted) seems, to me, a better
approach to articulate the problem.
2.1 OPES Entities
The usage of terms "OPES service application" and "data dispatcher"
is not always consistent and sometimes even confusing. According to
the definition in 2.1 service application is invoked by data dispatcher.
If this is always a case (an according to the definition it is so)
Figure 1 should look like this:
+----------------+
| OPES service |
| application |
+----------------+
|data dispatcher |
+----------------+
| |
| HTTP |
| |
+----------------+
| TCP/IP |
+----------------+
| ... |
+----------------+
Figure 1: An OPES protocol stack
It also may have sense to point out explicitly that OPES application
may be executed either on the same box (or even in the same application
environment) with the dispatcher or on different box through OCP.
This was on of important features in initially discussed architecture,
there were even terms like "proxylet" flying in the air.
Agree
I thing it has sense to emphasize this possibility and to provide a
figure like this:
+--------------------------+
| +----------+ |
| | OPES | |
| | service | |
| | appl | |
| +----------+ | +----------------+
| || | | |
| +----------------------+ | | +--------+ |
| | data dispatcher | | | | Service| |
| +----------------------+ | | | App2 | |
| | HTTP | OCP | | | +--------+ |
| +------------| |===(2)====| OCP | |
| | TCP/IP | | | | +--------+ |
| +------------+---------+ | | |
+-------||-----------------+ | callout server |
|| +----------------+
...........(1)
This is a kind of combination of figures 1, 3 and 4.
I like this diagram
2.5 Policy Enforcement
compiled ruleset
I'd suggest using the word "combined" - the word "compiled" may be
applied to the same ruleset in efficiency considerations (as opposed
to direct interpretation), and this may create some ambiguity.
..............
dispatcher constitutes an enhanced Policy Enforcement Point (PEP),
Use of PEP abbreviation may be a little confusing: this document
references RFC 3238, which uses this abbreviation in a different
sense - performance-enhancing proxies, originating in RFC 3135
(see RFC 3238, p.4).
Thanks for bringing that one up; I'd had similar thoughts on the source of
potential confusion.
3. Security and Privacy Considerations
It looks like we are looking at one general scenario: there is a data
provider, there is a data consumer and there is an OPES server that
just happened to be in between - and now we are prescribing the
rules for legitimate coexistence.
While this is a valid general scenario I'd suggest to look at
two more:
- CDN scenario: OPES architecture is used to build a content
distribution network and OPES servers in fact constitute an
integral part of data provider. In this case such servers have
an absolute trust of data provider and the end user has no more
right or reason to question/interfere with there functionality
than it has now in relation to the architecture of the
provider's site web servers farm.
Agree, though I'm not sure I see anything that suggests otherwise.
(Apologies if I'm missing something in my jetlag induced haze.)