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

From: Mark Duffy <[email-masked]>
Date: Wed, 01 Aug 2001 17:28:05 -0400

I think the case where the agent is in the same "box" as the firewall is
just a degenerate example of case b.  So while it is potentially useful,
it is not the only available justification for case b.  There is also
case b where the agent, not explicitly IP-addressed, is in a different
box in the packet path.  Granted, such a scenario requires an agent
placed there solely for the purpose of being an agent.   But it also
realizes the midcom objective of removing the tight coupling of
application intelligence and the middlebox (*exactly* what is  described
in the 2nd paragraph of section 1 of framework-03).

-Mark

At 06:28 PM 8/1/01 +0100, Cedric Aoun wrote: 

<excerpt>

OK probably some implementations might support that and we need to be
democratic. 

I still think that this is a weird usage of the Midcom protocol. 

Cedric 

-----Original Message----- 

From: Melinda Shore [<<mailto:[email-masked]>mailto:[email-masked]] 

Sent: Wednesday, August 01, 2001 6:49 PM 

To: Aoun, Cedric [QPD:MA01:EXCH]; [email-masked] 

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

At 05:36 PM 8/1/01 +0100, Cedric Aoun wrote: 

>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.

I don't think so.  As Scott Brim keeps reminding us, we're talking 

about functions, not boxes.  We've been saying all along that an 

agent could be placed inside a firewall.  I would tend to regard those 

as in-path agents, myself. 

Melinda 

</excerpt><<<<<<<<

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

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 09 Aug 2001 14:51:50 +0200

Agreed. We have a running code in our lab and the agent (midcom-enabled SIP proxy)
happens to run on the same device (a Linux host serving as a firewall). 
It still grants us the demanded modularity without the need to buy an 
additional box.

I think we should clarify this in the framework document.

-Jiri

At 11:28 PM 8/1/2001, Mark Duffy wrote:
>I think the case where the agent is in the same "box" as the firewall is just a degenerate example of case b.  So while it is potentially useful, it is not the only available justification for case b.  There is also case b where the agent, not explicitly IP-addressed, is in a different box in the packet path.  Granted, such a scenario requires an agent placed there solely for the purpose of being an agent.   But it also realizes the midcom objective of removing the tight coupling of application intelligence and the middlebox (*exactly* what is  described in the 2nd paragraph of section 1 of framework-03). 
>
>-Mark 
>
>
>>OK probably some implementations might support that and we need to be democratic. 
>>From: Melinda Shore [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]] 
>>>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. 
>>
><<<< 
>_______________________________________________ midcom mailing list [email-masked] <http://www.ietf.org/mailman/listinfo/midcom>http://www.ietf.org/mailman/listinfo/midcom </blockquote></x-html> 

--
Jiri Kuthan            http://iptel.org/~jiri

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