Re: WG Last Call: draft-ietf-opes-architecture-00

Graham Klyne wrote:

> In which case, I don't think that's an adequate level of tracing 
> capability.  That is, I don't think it fully addresses the spirit of the 
> IAB requirements.
> I refer you to the example I mentioned, of a problem with an ISP's 
> transparent caching.  I don't think it's acceptable that only the ISP's 
> administrator can find out what happened, because in practice the ISP 
> won't bother and will spin some lie about it being (say) a browser problem.
> I think it's crucial to put diagnostic capability in the hands of the 
> endpoint on whose behalf (authority) the service is being performed.  
> (Even if the endpoint isn't given any choice about having the service.)
I agree with your statement that OPES must give the enduser the 
capability to figure out what's going on and what might have gone 
wrong - it is *not* the intent to block this information from the 
enduser and to provide it only to an administrator.
However, it might be ok to present this information in a form that 
might require a little bit more knowledge to interpret correctly, and 
it might not be shown to the enduser per default. I've the email 
system in mind - the email headers provide the information I need in 
order to determine which servers where involved. However, this 
information is not really intendend to be seen by every beginner or 
every home user. However, if there's a problem, you can look at the 
details and maybe ask somenone (your administrator?) to help you 
understand. I had something similar in mind when talking about OPES 
tracing.
-Markus