On whether or not to rename (network) transparent proxy I'd point to
the abstract of the taxonomy:
Abstract
This memo specifies standard terminology and the current taxonomy
of web replication and caching infrastructure deployed today. It
which is basically to say we set out a series of X = Y
statements.. The set of X's are not up to us to define beyond a
diligent review of current practice.. they are the terms of the
"current taxonomy of web replication and caching infrastructure
deployed today".. The terms people use are not always those that we'd
like for them to use.. but not documenting them makes this document
essentially a censored dictionary.. put your head in the sand and
pretend it doesn't exist. as for the Y's we have a lot of discretion
and should use it wisely.
transparent proxy is definitely a well known X. not "interception
proxy".. heck, not even '(network) transparent proxy' but in the Y we try
and tell people that would be a better thing to say! (and I
concur.. but we can only really get away with this because of the
overloading of the term against HTTP..)
The wrec archives will show that I've gone to great lengths of tomato
dodging to make sure that nowhere in this document do we say that
this proxy provides some sort of lossless and undetectable
service. There was one last change I offered that removed
language that said this type of proxy was transparent to the user to
be "the use of this type of proxy requires no configuration of the
client"..
the fact that they break some things is undeniable. The fact that
they are heavily deployed is also undeniable. We've simply defined
what they are ("a device that receives network traffic
redirection".. we also define that latter term as
interception.. doesn't leave a lot to the imagination) for better or
for worse.. it's not for a taxonomy to judge.
What I'd like from the IAB is some support in finishing up the
book-keeping of the taxonomy and an endorsement of work on some
*protocols* to address these problems of resource discovery so that we
don't have to deploy switches that can read packets at optical line
speeds just so caches can be effectively utilized. There are lots
of deployments that don't want the enforcement nature of these
devices, they simply have a configuration problem on the clients and
the switches solve that problem by default. under an auto-discovery
protocol the client can be made aware of any resources made to it and
use (or not) of it is an application/political decision. Sites that
need enforcement of course have firewalls available to them.
It would seem to be a lot more productive to write down what currently
is (rather than wishing it weren't that way), and then proceed to
address the problem. I like to think that the IETF addresses protocol
problems that require interoperability.. and that that provides a much
greater value to the community than taxonomy or known problem
documents.
-P
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST