ietf-openproxy
[Top] [All Lists]

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

2002-05-21 12:21:53

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
<GK(_at_)NineByNine(_dot_)org>


<Prev in Thread] Current Thread [Next in Thread>