RE: Need to look at tracing and debuggig

["Oskar Batuner" <batuner@xxxxxxxxx>]

> -----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
> 
> 
> 
> 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