ietf-openproxy
[Top] [All Lists]

Re: WG Last Call: draft-ietf-opes-architecture-00

2002-05-20 11:08:24

--On Monday, May 20, 2002 10:47 +0100 Graham Klyne <GK-lists(_at_)ninebynine(_dot_)org> wrote:

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.

Agree with that last part, and I think that first paragraph needs some clarification (or more accurate examples). Geographic location and the prevailing language are related, but linking them as in the example is perhaps a bad idea (which is I think what you're suggesting also Graham). Customisation based on language is more likely to be useful where the requesting system doesn't want the material presented in the prevailing language, surely?

"resource availability" doesn't work for me on first parsing since I took the resource to be the requested entity, not the entity on which it was being displayed (but it might only be me that has that problem).

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".

Agree that it's not clear. My initial reaction would be that by the definition given neither the provider nor consumer are *in* the network (they are at opposite edges of the network). Of course, this is a simplification since the protocol specific output from an OPES intermediary could be a "provider" to things downstream of it :-)

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".

My reading is that the data dispatcher case is an OPES processor that provides the OPES entity by callout/vectoring, while an OPES service application is the system that can do the transformations (either within a single system or on the servicing end of the callout/vectoring system). Seeing Section 2.4 I'm not sure if that's the desired reading or not.

A diagram might help here? (On which note, I'm not sure Figure 1 really serves any useful purpose, and appears to force an HTTP over TCP/IP implementation.)

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..."

Agree.

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 don't see any particular need for that second sentence.

I'm not particularly keen with the way the 3rd paragraph is worded. One fix it to just not refer to a "data flow" at all. My attempts at re-writing the first paragraph to introduce the term "OPES flow" with respect to being a specific type of data flow seemed to be rather cumbersome.

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?

I'd prefer "evaluating" too.

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.

Maybe there are reasons for defining a single protocol here:  if so, I
think they should be explained.

I imagine that the lack of explanation might simply be due to historical reasons. That said, simple re-wording in the text following Figure 3 would allow for multiple OCPs. Unfortunately [7] is referenced (certainly later in the document) in a way that suggests there's one protocol while it actually refers to a requirements document.

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.

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..."?

And a typo in the final para:  "detremine".


Section 2.6
-----------
I think this section is very weak.  It manages to impose questionable
implementation decisions without providing any real guidance about how
tracing is to be provided.

Specifically, it calls for "in-band annotation through header extensions
on the application protocol".  I believe that this approach will mean
that the tracing facility is effectively unusable at Internet scale,
because it depends on protocol extensions that will be largely
unimplemented by the end systems who need access to the diagnostic
information.

True. This may also limit the number of protocols for which the architecture may be useful, though that might not necessarily be a bad thing.

I recently encountered a real problem that will illustrate my concern
here:  my wife works from home as editorial manager for a website.
Recently, she was reviewing website content and was getting old data when
all the other parties involved were getting new data.  This occurred with
different browsers, after cache-flushing, etc., so was almost certainly
not a local problem.  It most likely was a fault in an intermediate
transparent cache.  Now, I think this is exactly the kind of problem that
OPES tracing should be able to diagnose.  For this to be useful, I'd say
it must be possible to access the traces without any extensions to the
protocol whose flow is being serviced by OPES.

Well... this is a demonstration of why you need that out-of-band access to the audit trail rather than a reliance on headers that are defined in the protocol spec. but are rarely used :-)

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'm also a little confused as to the apparent urgency to take this document WG (and presumably wider) Last Call when many of the supporting documents appear expired/non-existent in the I-D directory (perhaps it's just the titles that have changed? I thought I had an up-to-date mirror of the directory) making it impossible for the reader to fully understand this document. (I.E. surely this document is just going to sit in RFC-Editor's queue anyway.)