Subject: [Fwd: Need to look at tracing and debuggig]

From: Markus Hofmann <[email-masked]>
Date: Mon, 31 Mar 2003 20:08:23 -0500

Folks,

please take attached matter *very* seriously - lack of appropriate 
tracing/debugging will be a roadblock for the protocol!

Abbie agreed to summarize the thoughts and issues around tracing and 
debugging some time next week. So, please, make sure that Abbie will 
have plenty of material to talk about and post your thoughts to the 
mailing list (hard to believe that no one has any opinion about what 
to do here and how...).

Thanks,
   Markus

Subject: Need to look at tracing and debuggig
From: Markus Hofmann <[email-masked]>
To: OPES Group <[email-masked]>
Date: Sat, 29 Mar 2003 14:04:21 -0500
List-Id: <ietf-openproxy.imc.org>

Hi,

with a first draft on the fundamental design of the OPES callout 
protocol being distributed, allow me to remind the WG of the 
importance of the tracing and debugging functionality (also given by 
the IAB considerations for OPES). We've to take this very seriously!

We have to look at tracing and debugging *now* and must not assume 
that it can easily be tagged onto the protocol at some later point. I 
would like to see some discussion on how we actually do the tracing 
and debugging, based on which the (possible) impact on the callout 
protocol can be determined. Only than, we can advance with the callout 
protocol!

In particular, one might ask

  - what has to be identified by the tracing capabilities? The
    OPES processors, the callout servers, the services themselves?
    All entities/services on the path between content consumer and
    content provider, or only the those in the direct trust domain?
  - how are the entities identified, what's the name space? In
    particular, we need to keep in mind that the IP address of an
    entitiy might not work out, since it might be a non-routable one
    (e.g. a callout server behind a NAT/firewall)
  - how exactly is thetracing information conveyed to the end points?
    In-band in the application message protocol (e.h. in HTTP
    extensions?)
  - what does the endpoint do with the tracing information, i.e. how
    can it contact possible faulty OPES service providers etc.
  - can the tracing and debugging feature be enforced? How?
  - are there implications on the callout protocol with respect to
    tracing and debugging? If no, are we suree about this? If yes,
    what do we have to build into the callout protocol to make it work
    (and possibly to enforce it?

These are just a few questions to start with. I'm sure more will pop 
up and will have to be answered.

Would anyone be interested in taking a lead on the discussion of 
tracing and debugging, possibly by putting together some thoughts in 
text form (maybe giving a specific example on how tracing/debugging 
will work)? This is *very* important for advancing our protocol work.

Thanks,
   Markus