Alex,
In general I have no problem(s) with your remarks.
We need to have good justification on what "assiatance means" and how at least one end "content provider" can detect malfunction (inappropriate behaior)
Can we say that we expect them to do periodic sanity check?
This is a quick responce for now
Abbie
> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, April 08, 2003 10:57 AM
> To: ietf-openproxy@xxxxxxx
> Subject: RE: Notification
>
>
>
> On Tue, 8 Apr 2003, Abbie Barbir wrote:
>
> > Yes, this should be the case. In this case, is Notification
> > application Protocol dependent? Or is it done out of band,
> (this also
> > addresses next paragraph too).
>
> Does not matter at this point. Application dependency is a
> secondary problem, IMO. First, we need to decide whether we
> should support notification (on a protocol level) at all.
>
> > Here are the IAB requirements:
> > (3.1) Notification: The overall OPES framework needs to assist
> > content providers in detecting and responding to client-centric
> > actions by OPES intermediaries that are deemed
> inappropriate by the
> > content provider.
> >
> > (3.2) Notification: The overall OPES framework should assist end
> > users in detecting the behavior of OPES intermediaries,
> potentially
> > allowing them to identify imperfect or compromised
> intermediaries.
>
> I believe tracing satisfies 3.2. The only problem is with 3.1
> because most client-centric actions happen _after_ the
> application message left the content provider(s) and, thus,
> notifications cannot be piggy-backed to application messages
> and have to travel in the opposite direction of traces. Let's
> concentrate on satisfying 3.1 as the subject of this thread.
>
> The 3.1 requirement is quite vague and it is not clear how
> normative are the comments that accompany/justify it. My vote
> is to interpret "assist" above as "assistance on non-protocol
> level". That is, we provide always-on tracing and claim that
> traces are sufficient to satisfy 3.1 above as long as both
> ends cooperate. We can also assert that if the ends do not
> cooperate, then no protocol-level solution will work either.
> Specifically, we suggest that content providers that suspect
> or experience difficulties do the following:
>
> 1. Check whether requests they receive pass through
> OPES intermediaries. Presence of OPES tracing info
> will determine that. This check is only possible for
> request/response protocols. For other protocols (e.g.,
> broadcast or push), the provider would have to assume
> that OPES intermediaries are involved until proven
> otherwise.
>
> 2. If OPES intermediaries are suspected,
> request OPES traces from potentially affected user(s).
> The trace will be a part of the application message
> received by the user software. If users cooperate,
> the provider(s) have all the information they need.
> If users do not cooperate, the provider(s) cannot
> do much about it (they might be able to deny service
> to uncooperative users in some cases).
>
> 3. Some traces may indicate that more information
> is available by accessing certain resources on the
> specified OPES intermediary or elsewhere. Content
> providers may query for more information in that
> case.
>
> 4. If everything else fails, providers can enforce
> no-adaptation policy using appropriate OPES
> bypass mechanisms and/or end-to-end mechanisms.
>
> Alex.
>