Subject: RE: WG Last Call: draft-ietf-opes-architecture-00

From: Graham Klyne <[email-masked]>
Date: Tue, 21 May 2002 20:20:38 +0100

At 02:03 PM 5/21/02 -0400, Abbie Barbir wrote:
> > Section 2.6
> > -----------
> > I think this section is very weak.  It manages to impose questionable
> > implementation decisions without providing any real guidance
> > about how
> > tracing is to be provided.
> >
> > Specifically, it calls for "in-band annotation through header
> > extensions on
> > the application protocol".  I believe that this approach will
> > mean that the
> > tracing facility is effectively unusable at Internet scale,
> > because it
> > depends on protocol extensions that will be largely
> > unimplemented by the
> > end systems who need access to the diagnostic information.
> >
>
>disagree, if you have followed the discussion and debate on these issues 
>you would have noted that traceability is intended for the qualified user 
>and not the general purpose user.
>
>The objective here is to allow a qualified administrator to trace what 
>happended to the data when the end user gets errors.

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

#g

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

---

From: "The Purple Streak (Hilarie Orman)" <[email-masked]>
Date: Tue, 21 May 2002 13:51:09 -0600

Tracing is meant for the end system user as well as qualified
administrators.  Just like email headers.  I run a mailing
list that uses three separate methods of including "unsubscribe"
information in every message.  Still, for some combinations of
mail agent and message, the enduser cannot see the information.
They send haughty email to the list administrator complaining
about how defective the list is.  OPES tracing will have similar
benefits and deficiencies in practice.  The inband method means
that the user will always have information stored locally and
will always be able to show it to someone else, but there is no
way to guarantee that all users will always have enough clues to
use it.  Just like anything else having to do with the Internet,
computers, or motorcycles (don't ask).

Hilarie

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 21 May 2002 16:21:42 -0400

Graham Klyne wrote:

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