On Wed, 2 Apr 2003, Oskar Batuner wrote:
1. I could not find any reference to "debugging" in architecture
and OCP requirements drafts. Shouldn't we talk just about
tracing/reporting? I am not sure what exactly others mean by
debugging, but since it is not required, we do not have to
worry about it. Tracing helps with debugging, of course,
but let's concentrate on immediate goals. Please correct me
if I missed debugging requirements.
2. It is very important to keep in mind that tracing is limited
to the trust domain. Anybody outside of that domain may or may not
see any traces, depending on domain policies/configuration. In
other words, we are not talking about mandatory end-to-end tracing
facility here. For example, if an OPES system is on the content
provider "side", end-users are not guaranteed any traces. If an
OPES system is working inside end-user domain, the origin server is
not guaranteed any traces related to user requests.
I'm afraid the situation is more complicated. While ability to
control tracing facility and level of details available inside and
outside of the trust domain may be different there are some
requirements (e.g. privacy) that are not limited to the trust
domain. Both IAB requirements and the architecture mandate some
end-to-end disclosures.
Let's be more specific. I did not find any IAB considerations that
mandate automated end-to-end disclosures. There is some discussion
that content providers may benefit from knowing client-side OPES
actions, but the only consideration is that "The overall OPES
framework needs to assist content providers in detecting and
responding to client-centric actions by OPES intermediaries". This
consideration is too vague; it can be satisfied by, for example,
asking the user to manually supply OPES-specific headers to the
content provider if the provider suspects inappropriate OPES behavior
by observing HTTP Via headers or equivalent.
As IAB notes, implementing this assistance goes against implementors
objectives (client-side OPES system does not care about server-side
desires). Thus, it would be a waste of time in implementing any
sophisticated/detailed (hence expensive) notification facility that
spans trust domains. Moreover, requiring such facility on a MUST level
clearly violates client-side privacy considerations.
I agree that we should require (at a SHOULD level) some minimal form
of cross-trust-domain tracing similar to current HTTP Via headers, but
I would not go far beyond that.
Markus asked for tracing use cases. If we start collecting those, I
would suggest to clearly document "end" and "admin" role in each
use case.
There are more participants interested in tracing information.
Independent OPES processors in the same OPES flow might want to know
about each other existence and might need to cooperate. For example
virus checker may be satisfied by the signature of another virus
checker, ad insertion/localization servers may avoid stepping on
each other toes, etc.
Sure.
In fact you are describing two roles. We should use this approach -
roles, not topology based description - end vs. intermediate.
I have no problems with that. Both approaches may co-exist actually.
4. (This is a consequence of #2 and #3 above) We should not expect
entities in one trust domain to be able to get any OPES-related
feedback from entities in other trust domains. For example, if I am
an end-user, and I think that the page I am getting is corrupted by
a callout service, I should not expect to be able to identify
that service, contact its owner, or debug it _unless_ the
service is within my trust domain. This is no different from
the current situation where it is impossible, in general, to know
the contact person for an application on an origin server that
generates broken HTML; and even if the person is known, one should
not expect that person to respond to end-user queries (in general).
Yes, but... For example you expect to be able to access content
provider's privacy policy and security credentials. Same is true for
OPES processors. Again, the amount of information and level of
control may be different but still some information should be
provided.
Provider != OPES intermediary.
The mechanism for end users to determine the privacy policy of a
server-centric intermediary is to visit the corresponding web page on
provider's web site. For end users, there can be no clear distinction
between server-side OPES intermediary and the "server-side" as a
whole. For starters, a particular server-side [OPES] intermediary may
not be directly addressable by the end-user. IAB RFC clearly states
that only the first intermediary in the chain must be addressable.
That first intermediary may be a L7 load balancer, for example. L7
load balancers do not have a privacy policy.
There are certain things that should be provided as references, e.g.
privacy policy. Extending combined approach with some persistent
information replaced by references give much greater flexibility and
makes application protocol more efficient.
Sure. I have no problems with allowing additional information to be
provided via references. We can discuss whether it would make sense to
require any specific references.
5. There is a question on whether OPES processor (OCP client) or
callout server (OCP server) must be responsible for adding trace
records to application messages. I am not 100% sure, but I would
suggest that we try to assign this task OPES processor exclusively.
Yes, can not agree more! See my previous post.
6. #5 suggestion implies that tracing is out of OCP scope! :-)
I'm afraid - not. For example OPES processor should be able to get
information about callout server privacy policy
Why should it?
The architecture draft says "Protocol(s) for policy/rule distribution
are out of scope for this document, but the OPES architecture assumes
the existence of such a mechanism". You do not really expect OPES
processors to care about every callout server privacy policy, do you?
Content providers have privacy policies. Server-side callout servers
do not have to (because they are operating under the content provider
policy).
and might want to control insertion of tracing information into
application messages. This has to be supported by the OCP :-(
Depends on what tracing information we want to support. For example,
if we want OPES processor to insert service identifier into an
application message, the processor can do it without OCP-level
support.
7. How tracing is added is application protocol-specific and may be
documented in separate RFCs/drafts. We can only document what tracing
information is required and, perhaps, some common tracing elements.
We can delay specification details while we are describing high level
architecture. But the ultimate goal is an implementable specification,
and to support application interoperation we have to specify all essential
formats and protocols. This may span multiple RFCs/draft but the final
result should be the same - implementable specification with guaranteed
interoperability.
Yes, of course.
Thanks,
Alex.