Hi,
Even if this is all done in the same admin domain, the reason to support
chaining is to save on performence, i.e. mesages.
But if we look at a simple example when there is server A, and B as callout
servers. and the OPES rule is to have services 1 on A and 2 on B.
Which chaining:
OPES (req) -> A
A (rep) -> OPES
A (req) -> B
B (rep) -> A
A (rep 2) -> OPES
all together 5 messages.
whitout chaining:
OPES (req) -> A
A (rep) -> OPES
OPES (req) -> B
B (rep -> OPES
all together 4 messages.
when there are more the two callout servers, it will be even worse.
You may improve it if the OPES will also be a "server"(i.e. listen for
replys) but that will still not make it better! and add its own problems.
yours
haim.
-----Original Message-----
From: John Morris [mailto:jmorris(_at_)cdt(_dot_)org]
Sent: Thursday, July 25, 2002 5:11 PM
To: Markus Hofmann
Cc: Hilarie Orman, Purple Streak Development; ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Chaining of Callout Servers
At 8:25 AM -0400 7/25/02, Markus Hofmann wrote:
Hilarie Orman, Purple Streak Development wrote:
<snip>
privacy, security,
if machines are in the same admin domain, no change; would recommend
strongly that machines be restricted from communicating outside the
admin domain, but there's no way to enforce this
Hm, yup, agreed.
To the extent that the machines in the same administrative domain are
operated by the same corporate entity and are covered by the same
privacy policy, then perhaps chaining of callout servers would not
add to complexity. The end user would need to have access to Server
A's privacy policy and that policy would need to take full
responsibility for privacy-affecting actions of Server B, C, etc.
But if Servers B, C, etc. were operated by different entities, then
the end user would need to have access to the privacy policies of B,
C....
Ultimately I have no position on the chaining of callout servers so
long as the potential impacts on privacy, etc. can be addressed.
John Morris
--------------------------------------------------
John Morris // CDT // http://www.cdt.org/standards
--------------------------------------------------