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

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Aug 2001 12:49:07 -0400

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

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

---

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 1 Aug 2001 18:28:02 +0100

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

Melinda

---

From: "Fernando Cuervo" <[email-masked]>
Date: Wed, 1 Aug 2001 15:25:38 -0400

once you decide that the function of the agent is inside the firewall then
the thing is neither an in-path nor an out-of-path agent, further, it has
nothing to do with the protocol. 

> From:	Melinda Shore [SMTP:[email-masked]]
> Sent:	Wednesday, August 01, 2001 12:49 PM

---

From: Melinda Shore <[email-masked]>
Date: Thu, 02 Aug 2001 07:10:58 -0400

At 05:41 PM 8/1/01 -0600, Zmolek, Andrew (Andrew) wrote:
>I'm concerned that so much effort is being placed on defining what is "in-path" verses what is not. 

Me too, actually.

>Suppose we leave this completely out of the conversation for now and allow that:
>
>1. Diversion may happen outside of midcom (since it's clearly not happening inside our charter and it's not technically difficult), and 
>
>2. While many of us may hold opinions about diversion, midcom as a protocol ought to be silent on the issue, particularly with respect to whether an agent is "in-path" or not.
>
>Would this be sufficient to move the current holy war to a new venue and away from midcom? 

I hope!  Good suggestion.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Thu, 02 Aug 2001 19:04:57 -0400

Sorry if this is a repeat.  It looks like it didn't get out of the list
server.

At 12:12 PM 8/2/01 -0400, Scott Brim wrote:
>On Thu, Aug 02, 2001 at 11:20:37AM -0400, Bob Penfield apparently wrote:
>> Absolutely not. The SIP examples in the doc work this way. That is why I
>> suggested that definition of a midcom agent explicitly state that it only
>> needs to be on the natural path of the signalling/control messages.
>
>This might actually work :-).  

From an architectural purity point of view, I would suggest that the agent
needs to be in the path of whatever packets it needs to examine/modify, be
they control/data/foobar/whatever.  The midcom framework, the midcom
protocol, and the middlebox should not state nor care whether they are
control/data/foobar/whatever.  However, I will concede that in practice it
is highly likely they will be control packets, and I don't feel a need to
press the issue.

Therefore Bob's definition seems fine to me except I think we need to be
more specific about what it means to be "on the natural path", as we have
already seen varied interpretations.  Which is addressed by Bob's next point:

>> I am sensing that there is general consesus that if at least the
>> control/signalling packets are explicity addressed to an application agent
>> (end-point, proxy, or whatever) co-resident with the midcom agent, or they
>> flow to the box containing the midcom agent by normal IP routing (i.e. the
>> box is on the path), then it qualifies as a valid MIDCOM agent within the
>> framework defined by the document. Thus case (a) and (b) in Mark Duffy's
>> original post qualify.
>
>Agreed.

Agreed here also.