see remarks inline
abbie
-----Original Message-----
From: Graham Klyne [mailto:GK-lists(_at_)ninebynine(_dot_)org]
Sent: Monday, May 20, 2002 5:47 AM
To: Markus Hofmann
Cc: OPES Group; Allison Mankin; Ned Freed
Subject: Re: WG Last Call: draft-ietf-opes-architecture-00
SNIP
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.
here, i agree with Markus comments, basically, it is sufficient for OPES to
provide trace
information that identifies the performed OPES service.
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".
No, this will be clarified in the text.
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".
the data dispatcher is responsible for invoking (for the lack of a better
work) the opes application service. if this is not clear in the text, then
we should revisit it.
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..."
zero means regular data flow, so we will revisit this one.
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?
no
Section 2.3
-----------
It seems to me that the OPES rules are a cornerstone of the
architecture,
but very little is said about them.
and i see no problem with that. this document is not a rule specification
document.
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?
yes, we will address it.
You also discuss using "the OPES callout protocol", which
seems to say
there is a single such protocol.
yes,
SNIP
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.
disagree, if you have followed the discussion and debate on these issues you
would have noted that traceability is intended for the qualified user and
not the general purpose user.
The objective here is to allow a qualified administrator to trace what
happended to the data when the end user gets errors.
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
...
SNIP
see previous remark.
SNIP
abbie