Subject: RE: [midcom] Framework comments & suggestions

From: [email-masked]
Date: Wed, 1 Aug 2001 08:53:46 +0100

So if I read this discussion correctly, it it appears that from the point of
view of the MIDCOM approach that the differences between these two cases is
very slight?

regards

Richard

> -----Original Message-----
> From: Mark Duffy [mailto:[email-masked]]
> Sent: 01 August 2001 04:53
> To: Andrew Molitor; [email-masked]
> Subject: Re: [midcom] Framework comments & suggestions
> 
> 
> At 10:40 AM 7/31/01 -0500, Andrew Molitor wrote:
> ...
> >	In the second place, the distinction is, as I understand it,
> >this:
> >
> >	In-path agents use information from IP packets IP
> >		addressed to the agent host.
> >	Out-of-path agents use information from IP packets
> >		IP addressed to some other host.
> 
> This was not my understanding.  I am surprised in fact not to see any
> responses to the above post (so far).  Does the silence mean everyone
> agrees with the above statement?  I guess we can at least 
> conclude that the
> definition of in-path agent "...devices that are naturally within the
> message path of the application" is too vague!
> 
> Andrew's definition strikes me as unnecessarily restrictive 
> of what can be
> an in-path agent (and therefore an in-scope agent :-)  
> 
> Consider the pre-midcom case where a middlebox, say a firewall, embeds
> application intelligence in order to do its job.  None of the 
> application
> packets would be IP-addressed to the firewall.  Now consider the
> midcom-ized evolution of that picture.  We can shift the application
> intelligence out of that firewall and into a midcom agent 
> that is within
> the path traversed by the packets.  Why should it be a precondition to
> doing so that the application now address its packets to the 
> agent?  All
> this serves to do is to prevent (as a side effect) the use of 
> midcom for
> any application that is not using some sort of proxy.
> 
> -Mark
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom
> 

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

---

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 1 Aug 2001 11:00:01 +0100

I think we can summarize with:
In path agents receives the application signaling because the messages are
addressed to them (the agent might be a peer or a proxy/MGC etc..)
On the other hand OOPs are not the destination of application signaling and
that's why the Middle Box has to divert the signaling messages to the OOP.
That's what Andrew meant.

That is in line with was Richard mentioned, these 2 types of Midcom agents
exist because the Midcom Agent and the application servers are co-hosted
(they might not be, but this will require a new protocol between them, and
this is COMPLETELY OO scope in the WG).

The Midcom agent is not necessarily co-hosted with a proxy, it could be
co-hosted with any "application agent" 

Having said that let's refocus on the mailing list on what is in scope.
Thanks
Cedric

-----Original Message-----
From: Mark Duffy [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 5:53 AM
To: Andrew Molitor; [email-masked]
Subject: Re: [midcom] Framework comments & suggestions

agrees with the above statement?  I guess we can at least conclude that the

Andrew's definition strikes me as unnecessarily restrictive of what can be
an in-path agent (and therefore an in-scope agent :-)  

Consider the pre-midcom case where a middlebox, say a firewall, embeds
application intelligence in order to do its job.  None of the application
packets would be IP-addressed to the firewall.  Now consider the
midcom-ized evolution of that picture.  We can shift the application
intelligence out of that firewall and into a midcom agent that is within
the path traversed by the packets.  Why should it be a precondition to
doing so that the application now address its packets to the agent?  All
this serves to do is to prevent (as a side effect) the use of midcom for
any application that is not using some sort of proxy.

-Mark

---

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

At 09:02 AM 8/1/01 +0100, [email-masked] wrote:
>Hi,
>
>> > >   "In the context of the MIDCOM Framework, the policy 
>> > >    server does not assist a middlebox in the implementation 
>> > >    of the services it provides or with resource authorization 
>> > >    on the middlebox."
>> > > 
>
>This reads that the policy server does not assist a middlebox with resource
>authorisation on the middlebox. 
>
>1. I think this is incorrect, surely one of the very functions of the policy
>server is to assist the middlebox in determining  which MIDCOM Agent can do
>what? If not what precisely does it do?

I think the text is ambiguous.  It seems to me to be quite unlikely
that a policy server would be in a position to, say, authorize the
allocation of a particular NAT table entry.  On the other hand it
would be in a position to determine whether or not the creation of
a particular NAT table entry of the NAT's devising is authorized.  I
think it would be helpful if the text were clarified.

Melinda

---

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

>view of the MIDCOM approach that the differences between these two cases is

I'd actually disagree with that, personally.  I think the
difference is substantial, in the sense that midcom is trying
to restore end-to-end application functionality by doing a bunch
of front-end work to set things up to allow it.  Out-of-path
packet processing is inconsistent with that model.

Melinda