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(_at_)measurement-factory(_dot_)com]
Sent: Tuesday, April 08, 2003 10:57 AM
To: ietf-openproxy(_at_)imc(_dot_)org
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.