Subject: OPES architecture - tracing and diagnostics

From: Graham Klyne <[email-masked]>
Date: Wed, 22 May 2002 13:02:39 +0100

I've received several responses about my comments regarding OPES tracing 
and access to diagnostics.  Rather than get drawn into a repetitious series 
of overlapping emails, I'm going to try and deal with them all together.

First a summary of my position:  I think an endpoint-user needs to be able 
to access OPES diagnostic information using commonly-used legacy 
software.  Requiring the endpoint-user to upgrade their software to access 
diagnostic information does not, in my view, adequately address the intent 
of the IAB requirements.

I have no problem with protocol extensions being available to facilitate 
access to the information.

I would also like to maintain some focus on the particular example I 
raised:  I think it represents a common use-case that well illustrates the 
need for diagnostic information.  It is the case of an intermediate cache 
that returns the wrong data in response to a web page request.  Using a 
standard browser, how am I to use the OPES trace/log information to 
diagnose the problem?  (I'm not claiming this is the *only* case that OPES 
should deal with, just that it's illustrative of an important case.)

Objections to my position that I have noted are:

- End users can't understand this diagnostic stuff
- Only administrators need to access the traces

Maybe many end-users won't understand it, but I see that as no reason to 
deny access to the information by those who can use it.  My experience of 
over-stretched ISPs and corporate IT departments suggests that 
administrators won't bother - I feel strongly that Internet technology 
should not operate to deny self help to users at the network edge.  I also 
think this principle informs the IAB requirements on OPES.

- Inband signalling means the user will have a locally stored copy
- Email system as model

For email, I can see a case that in-band signalling could provide the 
needed information, but even there I'm not totally convinced.  It is in the 
nature of email that messages are stored, complete with their headers, 
which are used for such purposes as constructing replies.  I don't know if 
all email clients provide access to arbitrary header information, but I 
acknowledge that some (many?) do.

But OPES is not just about email.  Someone on this list mentioned that HTTP 
is the target of any initial protocol-specific design work.  I claim that 
HTTP content is inherently transient.  It is designed as a stateless 
protocol so servers don't have to hold on to request information, and in 
typical default use the results are displayed transiently at the 
client.  (Yes, I know there's usually a browser cache, but that too is 
transient and as far as I have been aware it's only the HTTP response 
bodies and essential identifying information that are cached.)

So, I remain unconvinced that in-band signalling is the way to persist 
diagnostic information.

- In-band is needed for information from other administrative domains

This is a fair point.  Ad-hoc out-of-band mechanisms cannot really be 
expected to be effective across administrative domains.  Thus it seems to 
me that accessing information about behaviours in other domains is going to 
be a tricky problem to solve well.  In-band information may help, and I'm 
not opposed to using it (just not depending on it).

The OPES architecture requires that each intermediary is operating under 
the authority of one or other endpoint (the colouring 
discussion).  Further, even when the infrastructure providers may have 
little interest in resolving problems, the endpoints will often have reason 
to cooperate.  So, it seems to me that always having out of band access 
from one endpoint or the other is a far better outcome than having none.

- OPES operations are determined per-message
- Keeping a log at an intermediary is insufficient

Actually, I imagine that keeping a log could be quite sufficient, if 
sufficient information is logged.

I understand that one of the OPES requirements is that any intermediary 
operates with the authorization of one of the endpoints, which implies that 
at least one endpoint should know about any OPES intermediary that 
manipulates some data in transit.

Knowing the time, source and target of a request, it should be reasonably 
easy to identify a particular HTTP request and response from logging data 
kept at an intermediary.

#g

-------------------
Graham Klyne
<[email-masked]>