To pursue a few comments...
At 04:55 AM 5/20/02 -0700, Marshall Rose wrote:
i'm not sure i agree with your characterizations. the job of an
architectural document is to enumerate components and their
relationships.
Actually, I agree with that. And this is what I felt the document didn't
adequately address (though, as I said before, it did start out quite
well.) Mainly, in this area, I think it needs more work to clarify the
components and their interactions, and in particular their role in
addressing the security and diagnostic concerns.
> 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...
If this document were the end of a process, I might agree. But (I presume)
it's laying some groundwork for ongoing cooperative design work, and for
that I think some common, easily referenced vocabulary is particularly
useful, in a FAQ kind of way.
> 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 think diagnosis after-the-fact is fine.
> 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...
Well... does it need to be "transparent"?
When I wrote my comments, I was thinking that there might be HTTP access to
the audit trail (with appropriate authentication) from the client system in
whose admin domain the OPES intermediary was operating. That presumes the
client knows what URL to use to query the audit, so its not transparent (in
the sense of being automatically available), but I think that is
information that could easily be made available.
(That was assuming an OPES intermediary on an HTTP flow; for (say) an
email flow, some variant of the mechanisms suggested by multipart/external
might be used. The key issue here is that an end user with standard
off-the-shelf client software can access the diagnostic information,
without dependence on protocol extensions.)
> 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...
Well, yes... I was trying to point out that I thought there was an
important case here that the design should allow for, and acknowledging
that it wasn't strictly (to my reading) aligned with the IAB requirements.
#g
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>