Subject: definitions and use of "transparency" in the taxonomy

From: John Martin <[email-masked]>
Date: Wed, 05 Jan 2000 10:34:51 +0100

WREC,

There has been a recent discussion among various members of the IESG and 
IAB with regards elements within the taxonomy document, specifically the 
usage and definition of the word "transparency". I have asked those who 
feel strongly to consult the WREC archives and to continue their discussion 
here. Rather than attempt to summarize their conflicting opinions, I will 
paste a few comments below, without attribution. If you reach the end, you 
will notice that a compromise suggestion "interception proxies" was at 
least partially accepted but I would like to see it discussed here also.

Rgds,
John
--

I have tried to keep them in order, separated by ***:

 >p.s.  "Transparent proxy" is indeed common usage.   It is also a
 >barefaced lie.  I have strongly objected to the NAT proponents' attempts
 >to characterize NATs as transparent (since they break things right and
 >left) and I will also strongly object to any attempt to legitimize
 >the term "transparent web proxy".

***

 >As for the terminology battle, the use of the term "transparent" for proxies
 >of one type or another was, I thought, covered in the taxonomy doc in our WG.

***

 >the biggest problem with the use of the term "transparent proxy" as defined
 >in the terminology document is that it's too likely to be confused with 
other
 >uses of "transparent proxy".  even "network transparent proxy" is still a
 >misnomer.
 >
 >I think it would be more appropriate to avoid use of the term "transparent"
 >for a proxy that doesn't modify the request, since "transparent" is so
 >widely used to mean a proxy that surreptiously intercepts traffic which is
 >intended for the origin server.  were it not for the widespread misuse,
 >"transparent" would be a good word for this case.

***

 >And one shouldn't use "transparent" at all to refer to the kind of proxy
 >that intercepts traffic not intended for it, except to the limited extent
 >necessary to acknowledge the widespread misuse of the term.  Words like
 >"fradulent", "misdirecting", "plagiarizing", and "hijacking"
 >all seem more appropriate.

***

 >I understand that the WG spent a lot of time on the document.  I still
 >feel that its use of the term "transparent proxy" is inappropriate because
 >the term is so widely misused elsewhere that it has an accepted meaning
 >which is different than the one that WREC wants to use.

***

 >I disagree with X on this - "transparent proxy" is a well known term
 >of the art - one may disagree with the level of transparency but
 >just about anyone in the networking business knows what you are talking
 >about when you use that term - I think the use of any other term
 >would be confusing to most if not many readers - you could put it
 >in quotes when it is used and have a parententhetical comment
 >when the term is 1st used that notes the quite real issues that Keith
 >refers to but I find it hard to see that it would be a good idea
 >to use a different name for something when a well known name already
 >exists

***

 >The problem is that the phrase is a marketing lie and an abuse of language.
 >The fact that it is in widsepread use makes it worse. I think the minimum
 >that's acceptable is text stating that so-called transparent proxies are
 >not transparent, because they change the packets that pass through them,
 >and all our documents should consistently use the phrase "so-called
 >transparent proxies".

***

 >Agreed.  Trying to change the accepted meaning of the term "transparent
 >proxy" is like trying to change back the meaning of "hacker".  It would
 >have been nice if some other word were used in both cases, but language
 >is defined by usage, not purists.

***

 >I'm not suggesting that we try to change the meaning of this term, but to
 >use another term which is less misleading and more accurately describes
 >the function of such devices.

***

 >I can not see that it would be a good idea to use another term
 >"transparent proxy" is the term in use even if it is not what
 >we would like the term to be - to use anything else to name
 >the devices that network managers call "transparent proxies"
 >would not help the community understand what was being talked about

***

 >I would like to find a better term than "so-called transparent proxies".
 >however, if no better term can be identified (and I haven't come up
 >with one yet), then "so-called transparent proxies" would be an improvement.

***

 >Hidden proxies?  Intermediary proxies?  Interception proxies?

***

 >Interception proxies seems to carry the spirit of what is going
 >on......nomination seconded by some people around here.

***

 >"interception proxies" would be fine w/me.

***

 >The whole term "transparent proxies" has been the most debated in WREC,
 >maybe we'll finally put it to rest.  I suggest we keep the also known as
 >"transparent proxies" in the definition so that the general cache community
 >will know the definition change.

***

 >I've found that adding a trailer like
 >
 >"Note: froobnitz is also known as bumblebar, but the term bumblebar is often
 >associated with the property of bumbleness, and also used about bumblebees.
 >The term "bumblebar" is therefore not used in this document"
 >
 >kinda works the way I want it.

--end
---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Kruisweg 799                               Fax: +31 23 567 9699
NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------

---

From: Patrick McManus <[email-masked]>
Date: Wed, 5 Jan 2000 15:21:20 -0500 (EST)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Jan 2000 15:41:57 -0600

Patrick McManus wrote:
...
> book-keeping of the taxonomy 

I've made some direct suggestions to [some of] the taxonomy authors and
I hope anyone with issues will do the same.

> ...and an endorsement of work on some
> *protocols* to address these problems of resource discovery 

I can't speak for everybody but I think that this is an absolutely
key area. However, IAB/IESG don't endorse generalities; there would
have to be a fairly concrete work plan.

BTW an idea that came up a while back - don't recall from who -
was this:
   A possible conclusion is that even for
   non-store-and-forward protocols, a generic diversion mechanism
   analagous to the MX record would be of benefit.

> ...so that we
> speeds just so caches can be effectively utilized.

Absolutely

   Brian

---

From: Rob Austein <[email-masked]>
Date: Wed, 5 Jan 2000 17:12:47 -0500

Date: Wed, 5 Jan 2000 17:06:13 -0500
   From: Brian E Carpenter <[email-masked]>

We have one.  It's called the SRV RR.  Your mileage may vary :).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jan 2000 08:59:23 -0600

It was pointed out by Erik Nordmark that SRV doesn't allow arbitrary
wild cards:

> I think there is one "bug": In section 3.6 you are saying that
> SRV records can achieve a diversion mechanism similar to MX records.
> I don't think that is the case since it would require non-terminal wildcards as
> in
>         _ftp._tcp.*.example.com
> to do a diversion akin to MX records - such things are not allowed in the DNS.
> 

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 06 Jan 2000 18:23:24 +0100

--On 2000-01-06 08.59 -0600, Brian E Carpenter <[email-masked]> 
wrote:

>> I don't think that is the case since it would require non-terminal
>> wildcards as in
>>         _ftp._tcp.*.example.com

The MX wildcard doesn't work the way people think. It only matches if there 
is no other record with the same name, for example an A record or CNAME. It 
is also the case that the wildcard only works when the wildcard itself is 
the first label in the name, and not third like the example above for what 
one wants in SRVs.

For operations with DNS in Sweden, I have only seen one place where MX 
wildcards really work, and that is when you have a domain which is not at 
all connected to the Internet, and mail is going for that domain (and 
sub-domains) via UUCP or such non-internet protocols. THEN one can create 
the wildcard MX. In all other cases, you can get so confused by the 
matching rules between wildcard in MX and other RR types that I always 
recommend people to if nothing else generate the resource records they need.

I.e. what one wants (normally) is to have all mail to all subdomains to a 
parent domain go to the same host. You don't want arbitrary tokens (also 
non-existing subdomains) to go to the mail host, because the error to the 
sender of the email might be confusing, and not reflect the existence of 
the subdomain or not.

So, yes, wildcards are somewhat useful, but MX wildcards doesn't work well, 
and no, we don't have wildcards for SRV records, BUT one can quite easilly 
generate all RR one need in the scripts one have anyways(?) to keep the 
zones together. I.e. this doesn't need to be a function of DNS, but the 
tool one uses to keep the zone up to date.

   paf

---

From: <[email-masked]>
Date: Thu, 06 Jan 2000 10:09:23 -0800 (PST)

> the first label in the name, and not third like the example above for what

The way I've dealt with this for MX records is to use a preprocessor to
generate the database for the domain. The preprocessor has rules that tell it
when *.foo.com is specified and a.foo.com appears as an A or CNAME without its
own MX to add an explicit MX entry for a.foo.com that duplicates the wildcard
entry's value. It is a reasonably straightforward thing to do. And besides, you
want to run your tables through a preprocessor to make sure there are PTR
records for all the A records and similar boring stuff.

I see no reason why a similar preprocessor could not be used to generate
the necessary SRV records so that wildcard SRV records appear to work.

> recommend people to if nothing else generate the resource records they need.

FWIW, one place where we've found simple wildcard MX entries to be quite useful
is to map the subdomains of a given system's name back onto itself. We
routinely use such subdomains to provide various special email services
(gateways to other mail systems, for example), and since this segment of the
namespace never has A records in it that correspond to these service names we
don't have a problem with the limited scope of MX wildcards. And perhaps more
to the point, it saves us having to mess with the DNS every time one of these
services gets defined. This can be a big win, especially when dealing with a
site where the DNS stuff is managed by different people than the mail systems
and the DNS people are, shall we say, less than responsive to change requests.

> tool one uses to keep the zone up to date.

Exactly. And not only is generating explicit entries of this sort fairly
simple, it keeps a bunch of wildcard handling complexity out of the DNS server
itself. And that I view as a Good Thing -- we're well past the point where all
the extra entries you end up with as a result of this are significant, whereas
the deployment costs of bug fixes for broken wildcard handling code grow
more significant every day.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jan 2000 16:08:22 -0600

So, for an ignoramus such as me, does that mean that an SRV record
starting with _http. could be used to redirect HTTP in a clean way?

Presumably, however, the WREC community needs finer granularity than that.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 06 Jan 2000 17:59:02 -0500

> starting with _http. could be used to redirect HTTP in a clean way?

yes.

> Presumably, however, the WREC community needs finer granularity than that.

the NAPTR record was designed with this in mind, and to dovetail
with SRV.  So you can use SRV if just coarse granularity is needed
and you can use SRV+NAPTR if you need fine granularity.

fleshing out the details of how to find information about URLs -
including perhaps the location of replicas - is arguably within 
the scope of the rescap group.  though rescap is just supposed
to develop the mechanism, not the schemas. so the development of 
a schema for describing replicated web sites/pages should be done in WREC.

Keith

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 07 Jan 2000 08:08:41 +0100

> starting with _http. could be used to redirect HTTP in a clean way?

Yes, but not with wildcards, and only after someone have written a paper on 
how it really should work. I.e. HTTP usage is quite complicated already if 
you start with a URI.

The paper can be quite short though...is my guess.

   paf