-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex
Rousskov
Sent: Thursday, April 03, 2003 12:33 AM
To: OPES Group
Subject: RE: Need to look at tracing and debuggig
Oskar,
It looks like our disagreements are not as deep as I
originally thought. I agree with most of your latest comments.
Indeed, we should be careful about distinguishing a content
provider system and a 3rd party system operating under content
provider permission. I was pushing for treating any system as a single
entity once the message leaves that system. You are saying that there
are at least three kinds of systems: content providers, end users with
their proxies, and 3rd party services like CDNs. I agree, as long as
we can treat a 3rd party service as a single entity once the message
leaves that service.
How about starting with the following simple set of
unpolished rules:
1. An OPES processor SHOULD add its identification
to the trace.
The OPES processor is the only entity that is always present,
so if there is a MUST - it is here. On another hand if OPES
processor belongs to the content producer trust domain (and in fact
is an integral part of the origin) - why should it be exposed?
I'd say MUST unless it belongs to the content producer trust domain
and is covered by the appropriate privacy policies and other
regulations (TBD).
2. An OPES processor SHOULD add to the trace
identification of every callout service that received
the application message.
Unless those callout processors belong to the same trust domain
and covered by the same policies.
3. An OPES processor MUST add to the trace identification
of the "system/entity" it belongs to. "System"
ID MUST make it possible to access "system" privacy
policy.
"system/entity" is not well defined, it is absent in the
architecture. I'd put more stress on OPES processor as a
traceable entity. We may introduce "system" (TBD), but it is
a MAY. The second sentence belongs to paragraph 1.
4. An OPES processor MAY group the above information
(items 1-3) for sequential trace entries having
the same "system/entity" ID. In other words, trace
entries produced within the same "system/entity"
MAY be merged/aggregated into a single less detailed
trace entry.
Agreed.
5. An OPES processor MAY delegate trace management to
a callout service within the same "system/entity".
I'm not sure what do you mean by delegate here. If this means
that tracing information is inserted by callout processors
according to the OPES processor instructions and under its
supervision - OK, but in this case the exact point of trace
info insertion is not essential.
If you mean delegation of authority - this does not look right.
I'd set two types of requirements. First one is requirement to
identify the OPES flow participant. It will be covered by rules
1-3 (or whatever they will be transformed to). Second set of
requirements should state what kind of tracing information
MUST/SHOULD/MAY be inserted.
We need to agree on what an "identifier" in items 1-3 represents and
how trace entries are encoded (the latter is application-specific).
Overall, do the above 5 items sound reasonable at all? Are there any
huge gaps they do not cover? (I think I know of one hole, but would
prefer to hear others' comments before diving any deeper)
In general your practical approach to building a tracing framework
is very reasonable. Items may look a little different.
Oskar