RE: Need to look at tracing and debuggig


See inline.

-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex 
Rousskov
Sent: Wednesday, April 02, 2003 1:11 PM
To: OPES Group
Subject: RE: Need to look at tracing and debuggig



On Wed, 2 Apr 2003, Oskar Batuner wrote:

1. I could not find any reference to "debugging" in architecture
   and OCP requirements drafts. Shouldn't we talk just about
   tracing/reporting? I am not sure what exactly others mean by
   debugging, but since it is not required, we do not have to
   worry about it. Tracing helps with debugging, of course,
   but let's concentrate on immediate goals. Please correct me
   if I missed debugging requirements.

2. It is very important to keep in mind that tracing is limited
   to the trust domain. Anybody outside of that domain may or may not
   see any traces, depending on domain policies/configuration. In
   other words, we are not talking about mandatory end-to-end tracing
   facility here. For example, if an OPES system is on the content
   provider "side", end-users are not guaranteed any traces. If an
   OPES system is working inside end-user domain, the origin server is
   not guaranteed any traces related to user requests.


I'm afraid the situation is more complicated. While ability to
control tracing facility and level of details available inside and
outside of the trust domain may be different there are some
requirements (e.g. privacy) that are not limited to the trust
domain. Both IAB requirements and the architecture mandate some
end-to-end disclosures.


Let's be more specific. I did not find any IAB considerations that
mandate automated end-to-end disclosures. There is some discussion
that content providers may benefit from knowing client-side OPES
actions, but the only consideration is that "The overall OPES
framework needs to assist content providers in detecting and
responding to client-centric actions by OPES intermediaries". This
consideration is too vague; it can be satisfied by, for example,
asking the user to manually supply OPES-specific headers to the
content provider if the provider suspects inappropriate OPES behavior
by observing HTTP Via headers or equivalent.

As IAB notes, implementing this assistance goes against implementors
objectives (client-side OPES system does not care about server-side
desires). Thus, it would be a waste of time in implementing any
sophisticated/detailed (hence expensive) notification facility that
spans trust domains. Moreover, requiring such facility on a MUST level
clearly violates client-side privacy considerations.

I agree that we should require (at a SHOULD level) some minimal form
of cross-trust-domain tracing similar to current HTTP Via headers, but
I would not go far beyond that.


Yes,  for cross-domain I was looking at Via-type notification. I think
final protocol binding should define vendor-independent format suitable
for automated analysis.

As for MUST/SHOULD - I was always trying to prevent mandatory disclosure
of information outside of trust domain boundaries. Sometimes disclosure
of filter information may create a security threats facilitating attacks
on knows vulnerabilities and attempts to bypass protection.

But for some optional services well defined notification and control
mechanism may help to adjust services to the requirements of participants
even beyond trust domain, so I would not consider such mechanism a complete
waist of time.

   Markus asked for tracing use cases. If we start collecting those, I
   would suggest to clearly document "end" and "admin" role in each
   use case.


There are more participants interested in tracing information.
Independent OPES processors in the same OPES flow might want to know
about each other existence and might need to cooperate. For example
virus checker may be satisfied by the signature of another virus
checker, ad insertion/localization servers may avoid stepping on
each other toes, etc.


Sure.

In fact you are describing two roles. We should use this approach -
roles, not topology based description - end vs. intermediate.


I have no problems with that. Both approaches may co-exist actually.

4. (This is a consequence of #2 and #3 above) We should not expect
   entities in one trust domain to be able to get any OPES-related
   feedback from entities in other trust domains. For example, if I am
   an end-user, and I think that the page I am getting is corrupted by
   a callout service, I should not expect to be able to identify
   that service, contact its owner, or debug it _unless_ the
   service is within my trust domain. This is no different from
   the current situation where it is impossible, in general, to know
   the contact person for an application on an origin server that
   generates broken HTML; and even if the person is known, one should
   not expect that person to respond to end-user queries (in general).


Yes, but... For example you expect to be able to access content
provider's privacy policy and security credentials. Same is true for
OPES processors. Again, the amount of information and level of
control may be different but still some information should be
provided.


Provider != OPES intermediary.

The mechanism for end users to determine the privacy policy of a
server-centric intermediary is to visit the corresponding web page on
provider's web site. For end users, there can be no clear distinction
between server-side OPES intermediary and the "server-side" as a
whole. For starters, a particular server-side [OPES] intermediary may
not be directly addressable by the end-user. IAB RFC clearly states
that only the first intermediary in the chain must be addressable.
That first intermediary may be a L7 load balancer, for example. L7
load balancers do not have a privacy policy.


As it was stated in IAB RFC additional entities introduce additional risks.
Your approach is absolutely valid if server-centric OPES servers are
deployed as a part of data provider application and are completely under
his control. Situation becomes more complicated if OPES service is provided
by a third party - with the content provider consent. In this situation
OPES server may have a privacy policy different from the content
provider's one and it should be accessible separately. OPES framework should
provide appropriate mechanisms and rules of deployment. Sure there is no need
to expose a separate privacy policy for each server in a server farm, but
there should be a clear rule that describes how privacy policy is propagated
and that ensures that any OPES entity is covered by one of declared policies.

As for a L7 load balancer: if this balancer represents an OPES PEP (controls a
group of callout servers) it should obey all OPES rules, including privacy
notification.

There are certain things that should be provided as references, e.g.
privacy policy. Extending combined approach with some persistent
information replaced by references give much greater flexibility and
makes application protocol more efficient.


Sure. I have no problems with allowing additional information to be
provided via references. We can discuss whether it would make sense to
require any specific references.

5. There is a question on whether OPES processor (OCP client) or
   callout server (OCP server) must be responsible for adding trace
   records to application messages. I am not 100% sure, but I would
   suggest that we try to assign this task OPES processor exclusively.


Yes, can not agree more! See my previous post.


6. #5 suggestion implies that tracing is out of OCP scope! :-)


I'm afraid - not. For example OPES processor should be able to get
information about callout server privacy policy


Why should it?

The architecture draft says "Protocol(s) for policy/rule distribution
are out of scope for this document, but the OPES architecture assumes
the existence of such a mechanism". You do not really expect OPES
processors to care about every callout server privacy policy, do you?
Content providers have privacy policies. Server-side callout servers
do not have to (because they are operating under the content provider
policy).


1. Yes, I do care about callout server privacy policy. The fact that a
specific server obeys a policy declared by the OPES processor completely
satisfies my concerns, but this fact should be stated and verified by
the OPES processor.

2. Privacy policy is just an example. Tracing information may cover
other functional aspects, for example content filtering abilities and
policies, types of ads injected, personalization effects, etc. OCP
should provide a generic mechanism that can be used to satisfy a wide
variety of application specific needs.

3. Absence of tracing and adaptation support from OCP makes it
incomplete - tracing directives go out-of-band and results are not
verifiable. This may defeat one of the main reasons for creating a
standard for such protocol - to permit creation of plug-and-play
(the word "appliance" is more in fashion today) application
servers that can interoperate with any caller understanding the
protocol.

4. Server-side (content provider side) may have a different meaning.
It may mean an integral part of content provider application - in
which case your model is correct - but it may also mean a third-party
service operating with consent of service provider, the case that
was causing most concerns in discussions about privacy and
information distortion.

5. If we adopt a model were OPES server represents all applications that
it controls - and looks like we are looking favorably at such model - this
OPES server should be able to control all relevant aspects of callout servers'
behavior, including tracing information insertion. OCP is very natural place
for this extended control mechanism. It already controls most aspects of
OPES server - callout server interaction, deploying additional/different
mechanism may result in multiple complications (out-of-band control of
per-message information).

and might want to control insertion of tracing information into
application messages. This has to be supported by the OCP :-(


Depends on what tracing information we want to support. For example,
if we want OPES processor to insert service identifier into an
application message, the processor can do it without OCP-level
support.

7. How tracing is added is application protocol-specific and may be
   documented in separate RFCs/drafts. We can only document what tracing
   information is required and, perhaps, some common tracing elements.


We can delay specification details while we are describing high level
architecture. But the ultimate goal is an implementable specification,
and to support application interoperation we have to specify all essential
formats and protocols. This may span multiple RFCs/draft but the final
result should be the same - implementable specification with guaranteed
interoperability.


Yes, of course.

Thanks,

Alex.


Oskar