[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Need to look at tracing and debuggig
> -----Original Message-----
> From: owner-ietf-openproxy@xxxxxxxxxxxx
> [mailto:owner-ietf-openproxy@xxxxxxxxxxxx]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
> 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
> 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
"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.
> 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.