> At 01:39 PM 4/9/00 -0800, [EMAIL PROTECTED] 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
