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.
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".
2. The Architecture
- OPES rules: these determine how a given data flow is modified by
an OPES entity.
This definition looks too restrictive. From the rest of the document
and previous discussions rules are used to determine when the
transformation has to be involved. The definition above suggests that
the only OPES applications permitted by this architecture are "rules
interpreters". I don't think this is what really was intended.
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.
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.
It also emphasizes some questions that remain unclear from the use
of different terms in different places:
- What is "OPES flow" - (1), (2) of both? Figure 2 suggests (1),
Figure 3 suggests (2), Figure 4 suggests (1). Maybe we need several
terms to distinguish between different data flows?
- What is "OPES processor"? Figures 2 and 4 suggest different
interpretations: is this a "processing point" in the data flow
that functionally combines both boxes above (as in Figure 2) or
just an infusion point, as in Figure 4? I'd suggest former, otherwise
we are putting too much emphasis on application execution point,
but again we may need more developed terminology.
2.3 OPES rules.
In this model, all data filters are
invoked for all data.
This is very ambiguous. Again, depends on what is
a "data filter". If this is an OPES application this just does not
look right. If this is a specific rule this makes more sense but
looks too restrictive - unambiguous rule resolution may be checked
at the compilation time and then there is no need to go though all
rules after one of them has fired. At least I'd not include this
as an architecture requirement.
2.4 Callout Servers
The OPES ruleset is executed within a data dispatcher, which triggers
the execution of local OPES service applications. How the ruleset is
executed is not the subject of the architecture. ...
The word "executed" here is used three times. First and second uses
have a different meaning, the meaning of the third one is unclear.
I'd suggest "interpreted" for the first use. For the third one - do
you mean "implemented"? How does this come along with
"the OPES ruleset schema [6] which defines the syntax and semantics
of the rules interpreted by a data dispatcher"
proposed in Summary?
Figure 3.
Why do we prescribe the use of TCP/IP for OCP in all cases? I agree
this may be the most practical way to implement OCP but I would not
carve it into the RFC.
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).
2. The Architecture
- general composition.
The introduction lists three bullets, then we have 2.1, 2.2 and 2.3
explaining each of them in turn, very good documentation practice.
But then we have also 2.4, 2.5 and 2.6 - these breaks the composition.
I'd suggest moving 2.4 (callout servers) within 2.1 (maybe as 2.1.1)
and the rest (2.5 and 2.6) to part 3.
Ruleset definition.
In fact ruleset is defined in several places - 2.3, 2.4 and 2.5, each one
adds some more to the definition. It may have sense to combine all of them
in complete definition and place it in 2.3.
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.
- Incoming/outging data filter (company/library/school, etc.).
In this case OPES server has an absolute trust of data consumer
(which in this case is an entity different from the end user's
browser), and as such it may block all attempts of the end user
application (be it browser or other) to interfere with OPES
functionality and trace changes.
Rules of engagement in these three scenarios are very different,
and it is very important to include them into the consideration
from the very beginning. It was (and still is) one of main
problems in web caching world: all protocols are build for the
case of "indpendent facilitator" scenario", and when web caches
are used as part of web site or CDN people start building
the architecture to circumvent protocol limitations. In the
web caches case historically these use cases emerged long
after protocols were developed, but for OPES these use scenarios
should be built into the architecture from the very beginning.
I believe this may save us a lot of pain and heated IETF
discussions.
4. Summary.
- the OPES callout protocol (OCP)
I think we are in fact talking about family of protocols. OPES
may be used with different application protocols and this may
require different OCPs. This should be stated explicitly and
for each proposed OCP applicability description should be
included.
Oskar Batuner