[ 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