Subject: RE: [midcom] defining in-path and out-of-path agents

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 1 Aug 2001 17:36:46 +0100

In case b, packets go through the box without being diverted to it (where in
c packets are diverted to the device), this makes this box a Middle box with
application intelligence. and this is the opposite of the Midcom philosophy
to take out the application intelligence from the MB.
Cedric

-----Original Message-----
From: Mark Duffy [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 4:49 PM
To: Andrew Molitor; [email-masked]; Aoun, Cedric [QPD:MA01:EXCH];
Bob Penfield; [email-masked]
Subject: [midcom] defining in-path and out-of-path agents

I think a lot of the confusion here is because we have coined two terms
(in-path and out-of-path agents) but in fact there are at least three cases:

a.) agents in boxes to whom the packets to be inspected/modified by the
agent are specifically addressed at the IP layer.  Perhaps called
"logically and physically in-path".

b.) agents in boxes through which the packets in question are flowing, but
to which the packets are not specifically IP-addressed.  Perhaps called
"physically in-path".

c.) agents in boxes through which the packets in question do not flow
(unless diverted for that specific purpose)

I think we would probably all agree that a. are "in-path" agents and
therefore in-scope.
I think we would probably all agree that c. are "out-of-path" agents and
therefore out of scope.

I had understood b. to be in-path and in-scope, because I interpret this as
falling within the definition "... within the message path of the
application...".

I do not see why b. should be out of scope.  What does it matter to midcom
how the agent gets hold of the relevant application packets (as long as
midcom does not have to do anything about it such as diversion)?  I think
the difference between a. and b. would be transparent to midcom.

Regardless, we should improve our terminology.  I suggest some terms above
to differentiate a. and b.

Regards, Mark

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 1 Aug 2001 15:32:30 -0400

> to take out the application intelligence from the MB.

In the framework, section 2.8, we find: "In-Path Midcom agents are
entities in which the MIDCOM agent function is co-resident on devices
that are naturally within the message path of the application they are
associated with."   There is no explicit signaling required.  A middle
box, in our terminology, does not have application intelligence, while
an agent does and the agent manages the middlebox's behavior (for
certain sessions going through it).  If you require the end system to be
aware of the agent, then you're essentially elevating all agents to be
proxies.  If you're requiring a midcom scenario in which all the
applications we're trying to use it for have to change (to use agents),
we might as well stop now.

Granted I expect a lot of agents to be bundled with applications, some
just can't be.

I admit that from the midtax perspective I would call such an agent a
middlebox too.  That's pretty amusing.  However, right here we're just
talking about the midcom protocol, a protocol by which middleboxes can
be controlled (so that they can be relieved of application
intelligence).  The fact that another "middlebox", in the midtax sense,
is doing the controlling is interesting but not relevant right now.

IMHO...Scott