[Top] [All Lists]

RE: Need to look at tracing and debuggig

2003-04-02 08:10:52

-----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 
Sent: Wednesday, April 02, 2003 1:53 AM
To: OPES Group
Subject: RE: Need to look at tracing and debuggig

More thoughts on tracing and debugging.

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.

3. There are two distinct purposes/uses of traces. First, is to
   enable the "end (content producer or consumer) to detect OPES
   processor presence within end's trust domain. Such "end" should be
   able to see a trace entry, but does not need to be able to
   interpret it beyond identification of the trust domain(s).

   Second, is the domain administrator. The administrator should be
   able to take a trace entry (possibly supplied by an "end"  as an
   opaque string) and interpret it. The administrator must be able to
   identify OPES processor(s) involved and may be able to identify
   applied adaptation services along with other message-specific
   information. That information should help to explain what OPES
   agent(s) were involved and what they did, but it is impractical to
   provide all the required information in all cases. A trace record
   is a hint, not an exhaustive audit.

   Moreover, since trust domains and their administration vary a lot,
   I would argue that we must give implementors a lot of freedom in
   what to put in trace records and how to format them. Trace records
   should be easy to extend beyond basic OPES requirements. Trace
   management algorithms should treat trace records as opaque data to
   the extent possible.

   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.

In fact you are describing two roles. We should use this approach - roles,
not topology based description - end vs. intermediate.

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.

4. We know that traces must be in-band. This [very reasonable]
   requirement limits both the number of application protocols that
   OPES can adapt and the amount of details a trace record can carry.

   The former limitation must be clearly documented somewhere so that
   folks do not try to apply OPES to unsupported applications only to
   find out months later that they cannot trace them.

   Some of us may want to supply additional information out-of-band to
   address the second limitation. Since architecture and protocol
   requirements drafts do not require support for out-of-band tracing
   details, I suggest that the WG should not spend much time on them
   and treat them as possible extensions to the tracing facility.
   Let's concentrate on in-band tracing for now.

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.

See detailed discussion in my previous message - posted exactly at the
same time as yours :). Well, yours is fifteen minutes earlier.

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.
   Here are my reasons:

      a) Exclusive assignment simplifies the protocol.

      b) There are use cases where callout services adapt payload
      regardless of the application protocol in use and leave header
      adjustment to OPES processor or other services. For example,
      think of a generic text translation or image modification
      service; such services require payload encoding knowledge but
      can be application-independent if OPES processor can supply
      them with just the payload.

      c) OPES processor is always _able_ to trace its own invocation
      and service(s) execution because OPES processor must understand
      the application protocol. Assigning these tracing tasks to
      callout servers is just an optimization in cases where callout
      servers manipulate application message headers.

      d) We are not required to trace services, just processors,

      e) It makes OPES compliance checks easier when remote 3rd
      party callout servers are used.

      f) Servers or services MAY add their own OPES trace records,
      of course.

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 and might want to
control insertion of tracing information into application messages.
This has to be supported by the OCP :-(

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