At 01:39 PM 4/9/00 -0800, ned(_dot_)freed(_at_)innosoft(_dot_)com wrote:
> > However, I am
> > fully in agreement that interception proxies imposed anyplace other
> > than either endpoint of the connection is a Bad Idea, because a third
>
>Exactly. And after having read this specification, I also think these issues
>are glossed over.
>
> > I'd have to vote against progressing it without language making this
> > distinction as clear as possible.
>
>Agreed. I think the right thing to do at this point is to revise the
>specification. One possible approach, and the one I'd prefer, is to simply
>call
>for NECP to only be used on the server side. Alternately, the distinction of
Let's remember that a major goal of these facilities is to get a user to a
server that is 'close' to the user. Having interception done only at
distant, localized server farm facilities will not achieve that goal.
You are confusing topological locality with administrative locality. I was
talking about the latter, and so, I believe, was Valdis.
Indeed, the only reason I raised the security issues I did was to accomodate
the case where the proxies aren't topologically local to the servers. And
one of the things I see as missing from performance metric set is a means
of factoring in network QOS.
Further, I'm unclear about the architectural difference between (and
apologies if things don't quite line up):
client --> Internet -> ISP -> Intercept -> subnet1 -> Server1
-> subnet2 -> Server2
-> subnet3 -> Server3
versus
client --> Internet -> ISP -> Intercept -> Internet -> Server1
-> Internet -> Server2
-> Internet -> Server3
>the location of the service could be made clearer and the perils of arbitrary
>intermediate use spelled out.
Perhaps the issue is not location, but coherent administration?
In the case of proxies being "close" to the server, absolutely.
>I also see some technical issues in the protocol itself. For example, the
>performance metric set seems inadequate, at least based on my past experience
>with other load balancing systems. OTOH, the set is extensible, so this
>could be corrected fairly easily.
This would seem to walk down the path of considering this spec as a BASIS
for pursuing a standard?
I would not have a problem with pursuing standards work on protocols for load
balancing within a single administrative area. (This is not to say that
defining a protocol that can span administrations would be useless. It would be
very useful indeed, but I see so many potential ratholes it isn't funny.)
I suspect a case could be made for working on client-administered proxies, but
it seems fairly clear to me that this isn't what the present protocol
is about.
Ned