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

There's nothing like a last-call to raise a reviewer's priorities, right?-)

I approach this document on the assumption that (based on its title) it is 
to be a basis for designing and understanding OPES protocol elements.  I 
think it starts off quite well, but then descends into a morass of vague 
hand-waving whose design intent is hard to fathom.  Much of the later parts 
of the document seem to be a catalogue of requirements rather than the 
design elements that I would expect in an "architecture".  For example, I 
would expect an "architecture" document to enumerate the various components 
that must be specified to make up the OPES specification.
Also, I think that there are some serious problems with tracing facilities 
sketched in section 2.6.
And I think that, as a starting point for other aspects of OPES design, it 
would be appropriate to include a collected glossary in this document.

And so to detail:

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.

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

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

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

Section 2.3
-----------
It seems to me that the OPES rules are a cornerstone of the architecture, 
but very little is said about them.
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?
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.
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.
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.
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.

Section 3
---------
I think this whole section needs more work -- I found this had a kind of 
motherhood-and-apple-pie flavour, without providing much in the way of real 
information about how the security issues are to be handled.  Or at least 
determining what OPES component is responsible for what aspects of the 
security issues raised.

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?
In terms of OPES architecture (as I understand it), I think the employee is 
the end system here, and the corporate network may contain OPES 
intermediaries that prohibit the data flows that OPES is hereby prohibited 
from interfering with.  That is how content filtering systems with which I 
am familiar are deployed.  I think the requirements need to be refined.
#g
--

At 10:01 PM 5/18/02 -0400, Markus Hofmann wrote:

> Since there haven't been any comments on the published OPES Architecture 
> draft so far, we're issuing a Working Group last call on this draft:
> This is an OPES Working Group Last Call for comments on
> draft-ietf-opes-architecture-00. This last call closes Sunday, June 2, 
> 2002. Please post any final comments you have on the draft to this list by 
> that date. If there are no substantive technical issues raised by June 2, 
> we will forward this document to the IESG for publication as Informational.
> The draft is available at
>
> http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-00.txt
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>