ietf-openproxy
[Top] [All Lists]

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

2002-05-20 04:57:01

[ i've trimed the cc list, because those markus, ned, and allison should be on 
the mailing list... ]

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

my interests in this is primarily process, but since i was on the
subteam that produced the document, i'd figure i'd answer what
questions that i could...


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.

i'm not sure i agree with your characterizations. the job of an
architectural document is to enumerate components and their
relationships. sometimes, as a part of that, the document has to
discuss mechanism. in general, i think that the existing document
adheres to those principles. however, it's only a draft (and one
that was written from scratch), so some tuning might be needed.


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.

my position, in all working groups, has been that putting glossaries
in documents is the signature of poor writing. at best, they're
redundant, at worst, they're contradictory. if the document can't
define terms in context as they are used, then there is a more
fundamental problem in the 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".

from an architectural perspective, i think the answer is no...hence
the "zero, or more" text appearing througout with respect to opes
service applications. of course, you can't have an opes flow without
the provider or consumer, and perhaps this is why it's
counter-intuitive?


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

i personally think the names are confusing as the diagrams later on
try to make clear that the "data dispatcher" is the fundamental
thing. so, yes, this needs to get cleaned up.


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?

agree.


Section 2.3
-----------
It seems to me that the OPES rules are a cornerstone of the architecture, 
but very little is said about them.

because *architecturally*, very little need to be said, the rest of
the document defines the boundaries that the rules operate in...

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?

agree, poor wording.

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.

hmmm. i thought that the architecture was saying that there was only
one kind of OCP, regardless of the protocol being used in the data
flow.  in other words, there is no "seems to say" about it, it
"says" there's only one.


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

so, what you are really asking, and what the working group should
discuss is this issue.

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

agree, poor wording.


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

agree.

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.

hmmm. again, i think it sets some architectural boundaries, but
doesn't make any implementation choices (questionable or not).


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 think that "Internet scale" means different things. there's also a
counter-balancing set of concerns dealing on the impact on the opes
entities.

my interpretation, which could be wrong, of the iab concerns, was
that the working group could get away with diagnosis after the
fact. and if you believe that (it's certainly open to discussion),
then i think that the logic of simplicity inevitably takes you to
what the document says now... (albeit with perhaps more simple
wording!)


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.

i agree that problems like this should be subject to diagnosis. i
don't think it's


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.

i'm with you right up to the "using standard features of the
protocol" ... because your own argument argues against that.

maintaining an audit of what's going on is fine (and real systems
will do that regardless of what the architecture document
says). figuring out how to transparently tap into the audit
information is problematic...


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.

i more or less agree.


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.

i agree that one can interpret the IAB concerns as saying that
corporations can not address this security issue using OPES.

my reading of the document is that the architecture allows OPES to
be realized to address this security issue.

my understanding of the IESG's perspective on the IAB concerns is
that if a cogent argument is made as to why OPES isn't consistent
with certain aspects of the IAB concerns, then that's okay...


#g
--

thanks! i look forward to seeing a lively discussion in the working group.

speaking of which: as a co-chair, my words on technical matters
don't have any more weight than anyone else's. i just happen to have
the phone bills from sitting in on the conference calls that
produced the architectural document, so i thought i'd reply...

/mtr