Subject: Re: draft-ietf-wrec-taxonomy-03a.txt

From: Joe Touch <[email-masked]>
Date: Mon, 22 Nov 1999 14:23:57 -0800 (PST)

> From [email-masked]  Mon Nov 22 10:32:40 1999
> Delivery-Date: Mon, 22 Nov 1999 10:32:41 -0800
> Return-Path: [email-masked]
> From: Patrick McManus <[email-masked]>
> Subject: Re: draft-ietf-wrec-taxonomy-03a.txt
> To: [email-masked] (Ian Cooper)
> Date: Mon, 22 Nov 1999 13:32:00 -0500 (EST)
> Cc: [email-masked]
> List-Unsubscribe: <mailto:[email-masked]?Subject=unsubscribe>
> 
> wrec: 3 (hopefully) minor nits to taxonomy.. my comments are
> prepended by >>>.
> 
> -P
> 
> 
> [..]
>                     draft-ietf-wrec-taxonomy-03.txt
> [..]
> 
> 2.2 First order derivative terms
> 
>    The following terms are constructed taking the above base terms as
>    foundation. 
> 
>    origin server (as given in [1])
>       The server on which a given resource resides or is to be created.
> 
> >>> The singular usage "The server" is confusing as 2.3 allows for a
>     master and N replica origin servers.. how about "a server on which
>     an authoritative copy of a given resource resides or will be created"
> 
> ---------
> 
> [..]
> 
> 2.5 Automatic use of proxies
> 
>    Network administrators may wish to force or facilitate the use of
>    proxies (typically caching proxies) by clients, enabling such
> 
> >>> I'm uncomfortable with the parenthetical that describes
>     motivations for including proxies.. the reasons for doing so are
>     growing quickly.. including caching, you've got tracking,
>     ad-filtering, QoS games, performance enhanching proxies,
>     authentication, etc... Enumerating such things seems like a
>     rathole: I think the paragraph works well without the
>     parenthetical at all.
> 
> --------
> 
> [..]
> 
>    (network) transparent proxy 
> [..]
>       The use of this type of proxy
>       is transparent to both user and client.
> 
> >>> Using 'transparent' in the definition of 'transparent proxy' seems
>     to be asking for trouble.. even I am not sure if this statement is
>     meant to mean
>        a] not detectable
>        b] not relevant/not a factor operationally
>        c] transparent in the non-transforming HTTP sense
>     or d] does not require cooperation from client

Transparent means "not detectable at some layer" - in this case,
it is the application that cannot detect it.

>       A and B are clearly not true.. C is probably true, but I don't
>     think it's the motivation for the statement.. so I think it must
>     mean D.. so how about: "The use of this type of proxy requires no
>     configuration either by the user or the client."

"No configuration", "user", and "client" do not necessarily apply.

No _application_ configuration might. But that's not the only intent
of transparent. Not only is it not configurable, it isn't even detectable
at the layers above it.

Joe

---

From: Patrick McManus <[email-masked]>
Date: Mon, 22 Nov 1999 18:55:51 -0500 (EST)

In a previous episode Joe Touch said...
:: > 
:: > [..]
:: > 
:: >    (network) transparent proxy 
:: > [..]
:: >       The use of this type of proxy
:: >       is transparent to both user and client.
:: > 
:: > >>> Using 'transparent' in the definition of 'transparent proxy' seems
:: >     to be asking for trouble.. even I am not sure if this statement is
:: >     meant to mean
:: >        a] not detectable
:: >        b] not relevant/not a factor operationally
:: >        c] transparent in the non-transforming HTTP sense
:: >     or d] does not require cooperation from client
:: 
:: Transparent means "not detectable at some layer" - in this case,
:: it is the application that cannot detect it.

Finding their presence really is not particularly hard [*].. but
that's a rathole that I think will just distract the group into a
debate we've already had and prevent us from creating some solutions
to existing issues.

we don't need to have this fight again though.. I'm in no way trying
to get the taxonomy to rag on ntp's more.. I just want this definition
to match the one for traffic redirection which says that it is "used
to deploy (caching) proxies without the need to manually reconfigure
individual user agents, or to force the use of a proxy where such use
would not otherwise occur." the document already says that.

I was pretty sure that the definition included in this paragraph was
meant to mean (casually) "they give you a semantically similar
response as the one a client would have received to the exact same
request made not in their presence".. which is to say that to use
them, the client need not take specific action... which is fine by
me. Giving me an old coke when I ask for a soda from a store that used
to serve coke but now serves pepsi is close.. it's probably even
acceptable for a short period of time; but it's not "not detectable"
at the application layer.

:: 
:: >       A and B are clearly not true.. C is probably true, but I don't
:: >     think it's the motivation for the statement.. so I think it must
:: >     mean D.. so how about: "The use of this type of proxy requires no
:: >     configuration either by the user or the client."
:: 
:: "No configuration", "user", and "client" do not necessarily apply.

I think you're just being contrary, but I'll bite. Why not?
(understanding that user means 'operator of the user agent' not
'operator of the proxy')

:: 
:: No _application_ configuration might. But that's not the only intent
:: of transparent. Not only is it not configurable, it isn't even detectable
:: at the layers above it.
:: 

again: very detectable.. and problematic. also, application isn't
a useful word without a definition in the taxonomy.. client is already
there; we know exactly what it means (a client initiates a request and
recevies a response, a server receives a request and sends a
response)..

network transparent proxies provide a means by which the client need
not be configured either on the client level (via something like wpad,
dhcp, etc..) or explicitly by the user and the client still gets some
benefit from the proxy. That's all that they do that we can agree on
100% so we should say that.

-P

---

[*] the application certainly can detect it.. at least after getting
 back a response! These things cause real operational problems. I hope
 we all know that. But ignore the problems for a minute: anything
 remotely bordering on 2616 compliant has to add a Via header (a
 MUST).. this is doubly impt for something intercepting traffic as the
 Via header is for tracking paths and sorting out interoperability
 bugs. and then there is the squid setup I keep around for diagnosing
 these things.. it adds a X-Cache and Age headers to it's
 'transparent' responses! They're not the same as direct
 responses.. that's how a client can tell the difference.

plus the operability problems: we all know the interaction problems in
between requests directed to origin servers that are handled by
'network transparent proxies' and the problems with the absence of
associated proxy directives that otherwise would have been there.. not
to mention the problems with IP restrictions.. and migrations of new
HTTP methods, etc.. 

ISPs will tell you that users do notice when you put in 'transparent
proxies'.. and they call the help desk. It's not like replacing token
ring with 802.3 (a lower level change that would be transparent to the
application layer) exactly because the scheme 'level surfs' into the
application domain. (rewriting requests and so on..)