Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Tue, 19 Jun 2001 11:57:10 -0600

It seems that we've been debating the meaning of transparency for some
time now. Perhaps we are talking about different shades of transparency,
and if that really does matter than we need to elaborate.

- Transparency at an application layer so that client and server both
have a rational conversation is probably what we're aiming for when we
talk about OOP agent transparency. Some OOP agents still manage to
mangle things here, but the aim is still transparency.

- Transparency at the transport layer is something else. Many OOP agents
will have to interact with the underlying transport infrastructure to
deal with packet forwarding, route information, address and port
assignment details, etc. So transparency is a harder sell here.

Is it possible we can find enough middle ground in this decomposition of
the word "transparent" that we can move on?

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 11:44 AM
To: Pyda Srisuresh; Fleischman, Eric W; 'Andrew Molitor';
[email-masked]
Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02

> OOP agent are not visible to end-hosts. So, an OOP agent is
transparent.   

I wouldn't agree that one follows from the other.
If the out-of-path agent effects a change in the behavior
of the data/application/what-have-you, it's not transparent.

Melinda

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2001 13:59:24 -0500

I think the word "transparent" has too many interpretations
and too much history of abuse (as in "transparent proxy") to be a
useful word in this context. I think we should simply not use
the words "transparent" or "transparency" at all.

  Brian

> "Zmolek, Andrew (Andrew)" wrote:
> 
> It seems that we've been debating the meaning of transparency for some time now. Perhaps we are talking about different shades
> of transparency, and if that really does matter than we need to elaborate.
> 
> - Transparency at an application layer so that client and server both have a rational conversation is probably what we're
> aiming for when we talk about OOP agent transparency. Some OOP agents still manage to mangle things here, but the aim is still
> transparency.
> 
> - Transparency at the transport layer is something else. Many OOP agents will have to interact with the underlying transport
> infrastructure to deal with packet forwarding, route information, address and port assignment details, etc. So transparency is
> a harder sell here.
> 
> Is it possible we can find enough middle ground in this decomposition of the word "transparent" that we can move on?
> 
> --Andy Zmolek
> > OOP agent are not visible to end-hosts. So, an OOP agent is transparent.
>

---

From: "Scott Brim" <[email-masked]>
Date: Tue, 19 Jun 2001 15:25:14 -0400

> the words "transparent" or "transparency" at all.

Except we'll need to say something about transparency -- or the
equivalent concept.

WREC spent a lot of time on the word "transparent".  Can anyone
summarize what they came up with?  (If not I'll make time to dig
around over there (sigh).)

..Scott

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2001 12:41:10 -0700

by 'transparent," i hope we mean
  o does not modify data passing through or near it, and
  o does not change the detectable state of any network element based on
    data passing near or through it?

if so, we should say so in no uncertain terms.  if not, then best we be
really specific and not use words which rely on simile.

randy

---

From: [email-masked]
Date: Tue, 19 Jun 2001 12:55:00 -0700 (PDT)

Many members of WREC would have dearly loved to take the term
"transparent" and shoot it several times in order to watch it expire,
slowly, in a pool of its own misuse.  Sadly, it was a semi-protected
species due to its use in RFC2616.  This is the language in RFC3040
(the WREC taxonomy document) that dealt with the problem:

interception proxy (a.k.a. "transparent proxy", "transparent cache")
      The term "transparent proxy" has been used within the caching
      community to describe proxies used with zero configuration within
      the user agent.  Such use is somewhat transparent to user agents.
      Due to discrepancies with [1] (see definition of "proxy" above),
      and objections to the use of the word "transparent", we introduce
      the term "interception proxy" to describe proxies that receive
      redirected traffic flows from network elements performing traffic
      interception.

      Interception proxies receive inbound traffic flows through the
      process of traffic redirection.  (Such proxies are deployed by
      network administrators to facilitate or require the use of
      appropriate services offered by the proxy).  Problems associated
      with the deployment of interception proxies are described in the

[1] is RFC2616.  WREC also suggested that "network transparent proxy"
be used where the author meant a proxy that did nothing to the request
or response except what was required for proxy auth and identificaiton.

				regards,
					Ted Hardie

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 19 Jun 2001 13:11:30 -0700 (PDT)

I did a grep on the terms "Transparent" and "transparency" to see 
where and how they are used in the FW document. Below is a list of 
my findings and sugegsted remedies.

I believe, it is OK to use terms like "end-to-end transparency" (item 1
below) and "Transparent routing" (item 3 below). They have a specific 
meaning that goes with them.

But, as Brian pointed out, it is tricky to use these temrs in the 
context of proxies, ALGs, agents and the like.

1. Paragraph 1 of section 1 - Introduction

   "Application Level gateways (ALGs) are used in conjunction with NAT
    to provide end-to-end transparency for many of the applications."

   I think, it should be OK to leave this unchanged.

2. Paragraph 3 of Section 1 - Introduction

   "The communication between a MIDCOM agent and a middlebox will be
    transparent to the end-hosts that take part in the application,
    unless one of the end-hosts assumes the role of a MIDCOM agent."
 
   I could reword this as follows:

   "The communication between a MIDCOM agent and a middlebox will
    not be noticeable to the end-hosts that take part in the application,
    unless one of the end-hosts assumes the role of a MIDCOM agent."

3. Sectin 2.4. - NAT

   "Network Address Translation is a method by which IP addresses are
    mapped from one address realm to another, providing transparent
    routing to end-hosts."

   This definition is settled after a long series of discussion 
   prior to advancing RFC 2663. The definition is carried as is 
   from RFC 2663. I donot recommend changing this.
 
4. Paragraph 3 of section 2.6 - ALG

   "ALGs are different from proxies. ALGs are transparent to 
   end-hosts, unlike the proxies which are relay agents terminating
   sessions with both end-hosts."

   I could rephrase the above as follows:

   "ALGs are different from proxies. ALGs are not visible to 
   end-hosts, unlike the proxies which are relay agents terminating
   sessions with both end-hosts."

5. Paragraph 3 of section 5.2. - OOP MIDCOM agents

   "In essence, a middlebox provides to an Out-of-Path MIDCOM agent
    the ability to transparently "snoop" and modify the control
    traffic."

   I can reword the above as follows.

   "In essence, a middlebox provides to an Out-of-Path MIDCOM agent
    the same priveleges as that of an In-Path agent, to application
    control traffic, to "snoop" and modify as deemed appropriate."

6. The legend in figure 5 for "Ctrl" is described as follows.
   "Ctrl - indicates the FTP control traffic, which
           is transparently diverted to the OOP agent (2 and 3)"

   I can remove the word, and yet not change the semantics here. 

Thanks. 

regards,
suresh

--- Brian E Carpenter <[email-masked]> wrote:
> > It seems that we've been debating the meaning of transparency for some time
> now. Perhaps we are talking about different shades
> > - Transparency at an application layer so that client and server both have
> a rational conversation is probably what we're
> > aiming for when we talk about OOP agent transparency. Some OOP agents still
> manage to mangle things here, but the aim is still
> > transparency.
> > 
> will have to interact with the underlying transport
> > infrastructure to deal with packet forwarding, route information, address
> and port assignment details, etc. So transparency is
> > a harder sell here.
> > 

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 17:27:05 -0400

>     data passing near or through it?

that seems like a reasonable definition of the word for this discussion. 

and we already have better words (interception, hijacking) to describe 
network elements that do exactly the opposite, and for which the endpoints
are not aware.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 17:31:28 -0400

> meaning that goes with them.
 
I assert that it would be far less confusing overall all forms of the
word "transparent" were reserved for data transparency as defined by Randy.

If our goal is to produce readable documents, we should avoid conflicting
uses of this term.

Keith

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 19 Jun 2001 16:51:39 -0500 (CDT)

>     data passing near or through it?

	No offense, but this sounds sort of like the networking
equivalent of a neutrino. What earthly use would a device with these
properties have? I can see the marketing materials now:

	"Buy our Xj13-Z Transparent Widget! It has NO DETECTABLE EFFECTS!"

	Presumably you mean that it has no effects detectable to
some class of user or traffic? Say, it has no effects detectable by
authorized personnel using the network in authorized ways?

	As a former mathematician, I am surprisingly comfortable
with terms meaning all manner of conflicting things, provided context
makes clear which meaning is intended. In my limited experience,
"transparent" is usually a modifier: "transparent firewall" is a
fairly well defined widget, for example. Anyone planning to
introduce a new usage should, of course, be required to provide
a clear (ho ho ho) definition of the usage.

		Andrew

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jun 2001 02:51:06 -0700

> time now[...]

<BAR-ROOM-USELESS-DISCUSSION>

Indeed this is where the term FOGLAMPS came from.  It appears I should
probably have submitted that document as an informational RFC, since
people are spinning on history.  If you have an opinion on me doing so,
please direct it to me, AND NOT TO THIS LIST.

</BAR-ROOM-USELESS-DISCUSSION>
--
Eliot Lear
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2001 14:55:17 -0700

> that seems like a reasonable definition of the word for this discussion. 

glad you like it.

> network elements that do exactly the opposite, and for which the endpoints

no.  those terms suck even worse than transparent.  they are emotionally
loaded and convey little technical detail.  this was the point of my
message.  do not use similes.  do not use idioms.  ...

we need to very carefully say exactly what is done and in clear simple
technical terms, or we will keep wrapping around the axle of emotionally
loaded but content free gigo-speak.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2001 15:20:10 -0700

> No offense, but this sounds sort of like the networking equivalent of a
> neutrino. What earthly use would a device with these properties have?

oh, network measurement a la vern, sally, jrex, bala, et al.  lots of stuff
like that.

but my point was not to apply my restrictive terms to the work here.  my
point was, please do not use the term if you don't mean it in a very clear
and absolute sense.  'transparent' is a simile and marketspeak.  please say
precisely what is done, and clearly, not in marketspeak.

e.g. if you mean that a particular middle-box detects a flow passing through
it and, based on observation of that flow, signals another box to allow the
flow through, then say so.

i am not in denial about middle-boxen, nats, or even atm <g>.  some of my
best friends use them.  i just want it all clearly labeled, as i get easily
confused by marketspeak such as 'transparent,' and it is pretty clear that
others do as well.

randy

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 18:20:42 -0400

> message.  do not use similes.  do not use idioms.  ...

it's a laudable goal.  but it's difficult for a term to give some clue as 
to its meaning and at the same time be free of all bias.  and once terms 
are in use they tend to acquire some bias anyway, through association with 
their technologies.  "nat" started out to be value-neutral, but has picked 
up some bias along the way.

I'll note that 'transparent' also has emotional loading - it just tends
to be favorable loading.  which is after all part of the reason why
both sides have used it.

IIRC, 'interception' was picked by proponents of interception proxies, 
so I figure it's close to optimal. (if you are watching American football
and are a fan of the team currently playing defense, an interception is 
a good thing...)

admittedly, 'interception' is less loaded than 'hijacking'.

mainly I was saying that we need to be consistent about the use of 
terms - e.g. we should not use 'transparent' to mean one thing in one
case and something that is almost completely the opposite in another.

> loaded but content free gigo-speak.

agree entirely.

Keith

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 19 Jun 2001 17:41:29 -0500 (CDT)

> oh, network measurement a la vern, sally, jrex, bala, et al.  lots of stuff

	Ouch, you got me ;)

	I agree entirely with your remarks, clarity is always important.
I am comfortable with saying, though:

	- an In-Path agent is, by definition, one in which traffic
	  is IP addressed to the agent device by some other network
	  element, and the content of that traffic is used to make
	  policy decisions which are then implemented by the Agent
	  using the MIDCOM protocol.

	- an Out-Of-Path agent is, by definition, one in which traffic
	  NOT IP addressed to the agent is, by some mechanism, directed to
	  the agent. The content of that traffic is used to make policy
	  decisions which are then implemented by the Agent using the
	  MIDCOM protocol. For brevity, we will describe such an Agent
	  as 'transparent' to the end systems or applications on behalf
	  of which policy is implemented.

	In this case, 'transparent' means 'looks at some traffic that's
not addressed to it and does some kind of undefined stuff (perhaps
modify the traffic, or dance and sing, or install policy in a NAT)
which doesn't break the application.'

	I gather 'transparent' is a loaded word to some of us, with a
history of unclear and conflicting usage. If the consensus is that
its baggage makes is unusable, I am happy to agree with its suppression
and will try hard to not use it.

		Andrew

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2001 16:09:16 -0700

> which doesn't break the application.'

a transparent piece of glass does not alter the light passing through it
or cause a door to open or close.  i.e. the simile conflicts with the
well-known use of the term.

so what you seem to have meant is a box in the middle of the path which
may modify the traffic or cause other devices to alter their behavior
based on the traffic the mid-path box observerd.  [ and i can see uses
for such a box ]

you could use a keithism, like "mid-path mangler" <g> but "transparent"
would seem a bit disingenuous.  [ and yes, i have used a dictionary ]

randy

---

"Then you should say what you mean," the March Hare went on.

"I do," Alice hastily replied; "At least at least I mean what I say that's
the same thing, you know."

"Not the same thing a bit!" said the Hatter. "Why, you might just as well
say that `I see what I eat' is the same thing as `I eat what I see'!" 

-- Lewis Carroll

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 19 Jun 2001 18:19:01 -0500 (CDT)

> based on the traffic the mid-path box observerd.  [ and i can see uses

	This usage closely matches the common usage 'transparent
firewall' which uses it to mean, roughly, 'a user who isn't specifically
looking can't see it.' I don't know why 'invisible' wasn't used, but
I didn't invent the usage.

> say that `I see what I eat' is the same thing as `I eat what I see'!" 

  "'When I use a word,' Humpty Dumpty said in rather a scornful tone,
   `it means just what I choose it to mean -- neither more nor less.'"

 -- Lewis Carroll

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 19:30:27 -0400

> "transparent firewall" is a fairly well defined widget, for example

sounds like an oxymoron to me.

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2001 16:41:43 -0700

> `it means just what I choose it to mean -- neither more nor less.'"

and remember his fate

randy

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 19:48:08 -0400

> looking can't see it.' I don't know why 'invisible' wasn't used

probably because the term was chosen by a marketing person,
precisely because it does have favorable associations.

Keith

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 19 Jun 2001 17:37:51 -0700 (PDT)

I do agree with Randy about using simple unambiguous words.

But, we cannot always go by the dictionary definition for terms. When 
technology defines a term or has used the term in a certain way, we
ought to be using the technology definition, not the dictionary defn.
Contrasting with the dictionary defn and redefining it to match the
dictionary definition simply creates confusion. Expressly prohibiting
the use in a proper context tantamounts to censoring it.

Perhaps the terms "transparent" and "opaque" fall under this category. 

The term "transparent" has been, I believe, used for the longest time
to mean "not noticeable" to the end-hosts that take part in an 
application. And, the opposite for the term "opaque". Even if you think,
this is oxymorinish, the meanings have been used consitently in many 
previously published work from IETF and other standards bodies as 
Andrew points out. If we create a new defn now, all the previous 
work become inconsitent.  

Oh, well, thats all from me on this thread for today.
Thanks. Have a nice day.

regards,
suresh

> sounds like an oxymoron to me.

=====

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 21:51:15 -0400

> application. 

the more precise meaning of "doesn't corrupt the data" is far more common.

"not noticable" doesn't apply to so-called transparent proxies, for instance.
nor does it apply to so-called "transparent firewalls".

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2001 22:11:58 -0700

> to mean "not noticeable" to the end-hosts that take part in an 

i think that's the problem.  it seems to have been also used to mean "we
wish it was not noticeable but it really was and the marketing folk told
us to use the term anyway."

i can see uses for in-path boxen that do modify data or behavior.  and
that is, i believe, the very charter of this group.  but, as this is the
ietf, not the imtf, it would behoove us to be as accurate as possible.

randy

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 20 Jun 2001 00:27:11 -0500 (CDT)

> ietf, not the imtf, it would behoove us to be as accurate as possible.

	We could invent some new terms, without any baggage, and
define them carefully. For example, we could use the word 'Agent' to
mean some entity which examines network data and makes policy
decisions which it implements via MIDCOM on behalf of other network
entities.

	We can assume, reasonably I think, that the network data examined
by the Agents to be some sort of protocol data passing between
Applications, and that the policy to be implemented in the middleboxes is
to be implemented on behalf of these Applications.

	If it becomes useful to distinguish between those Agents which
get a chance to look at this protocol data by explicitly taking part in
the protocol (with whatever Application configuration that implies) and
those which get the chance by other means, we would need terms to
distinguish between these two types of Agents.

	Rather than the loaded terms 'non-transparent' and 'transparent' I
propose we use the terms 'In-Path' and 'Out-of-Path' respectively.

	More seriously, perhaps we should suppress this distinction, but
raise the notion of Packet Diversion up to a core thing that MIDCOM needs
to deal with, in parallel with NAT and Firewalling?

		Andrew

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 11:14:45 -0400

> propose we use the terms 'In-Path' and 'Out-of-Path' respectively.

Nice try, but OPES (for example) is working with out-of-path
non-transparent functions.  Also, the way we use 'transparent' should be
generally applicable throughout the IETF.  Again I like Randy's
approach, along with awareness that transparency is a per-layer issue.

...Scott

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 11:35:46 -0400

>    I think, it should be OK to leave this unchanged.

OK, we're talking about application-layer transparency.  As long as you
mean that the application data and the application behavior are
unchanged, since that would fit the strict definition.  I think I agree.

>     unless one of the end-hosts assumes the role of a MIDCOM agent."

Yes.

>    from RFC 2663. I donot recommend changing this.

The best you can claim for NAT is application-layer transparency.  I
assume that by routing you mean forwarding of packets from one interface
to another.  That is an IP layer function, and it is certainly is not
transparent, in that NAT modifies at least the headers of those packets.

Perhaps you could change "transparent routing" to "application-layer
transparency", but even that's debatable.

I suggest you just claim something like application data transparency. 

>    sessions with both end-hosts."

OK

>     control traffic, to "snoop" and modify as deemed appropriate."

Hm, this now says that OOPAs have privileges (note spelling) for
application CONTROL traffic.  I thought you wanted OOPAs to be able to
see all application traffic, not just signaling.  If you eliminate "to
application control traffic" it makes sense to me.

>    I can remove the word, and yet not change the semantics here. 

OK.

...Scott

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 12:49:42 -0400

> The best you can claim for NAT is application-layer transparency. 

even that claim is dubious, since the IP address is available to applications 
and is often used by applications (for quite a few justifiable reasons).

Keith

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 25 Jun 2001 14:57:19 -0700 (PDT)

> unchanged, since that would fit the strict definition.  I think I agree.

ALG does not guarantee that application data is not changed, even though
its intention is to keep the application behaviour unchanged.
It may in fact change the data in control payloads. So, the term 
"application level transparency" above doesnt meet the dictionary 
definition. 

Would the following rewording work for you?

   Application Level gateways (ALGs) are used in conjunction with NAT
   to examine and optionally modify application payload so the 
   end-to-end application behaviour remains unchanged for many
   of the applications traversing NAT middleboxes.

> The best you can claim for NAT is application-layer transparency.  I

Yes, but only per the dictionary definition.

> I suggest you just claim something like application data transparency. 
"Application layer transparency" may be OK per the semantics you ascribe
to the term. But, that will most certainly confuse a different set of
audience. I would rather avoid that can entirely.

However, I do agree that precise meaning of the terms used must be 
understood by all readers alike. So, I could include text describing
the term "transparent routing" as follows.

    Network Address Translation is a method by which IP addresses are
    mapped from one address realm to another, providing transparent
    routing to end-hosts. Definition for the term "Transparent routing"
    may be found in [NAT-TERM]. Transparent routing refers to routing
    a datagram between disparate address realms, by translating 
    addresses in IP headers so that when the packet leaves one realm
    and enters another, it can be routed properly.

The reason the IESG agreed to the term "transparent routing" as opposed
to "transparent forwarding" is the following. If the goal
was simply to forward a datagram from private realm to public realm,
there was no need to change the source IP address (from private address
to an external assigned address). By changing the source address 
(i.e., the act of transparent routing), the NAT device is able to ensure
that the external host would send the reply back to itself and NAT
in turn could forward the reply datagram to the right end-host in 
private realm. Without the act of transparent routing, it would not
have been possible for the reply datagram to be routed to the right
end-host.

This is a rehash of the discussion that transpired way back. Hope you 
understand. Thanks.

OK.

cheers,
suresh