From midcom-admin@ietf.org  Wed Aug  1 03:56:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21226
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 03:56:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12750;
	Wed, 1 Aug 2001 03:56:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12720
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 03:56:28 -0400 (EDT)
Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21192
	for <midcom@ietf.org>; Wed, 1 Aug 2001 03:55:25 -0400 (EDT)
From: richard.swale@bt.com
Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP;
          Wed, 1 Aug 2001 08:55:02 +0100
Received: by cbtlipnt01.btlabs.bt.co.uk 
          with Internet Mail Service (5.5.2652.35) id <P0YZ3SN9>;
          Wed, 1 Aug 2001 08:54:55 +0100
Message-ID: <B76B75D34ACFD31180A600606DDFE79B09841D73@mbtlipnt04.btlabs.bt.co.uk>
To: mduffy@quarrytech.com, amolitor@visi.com, midcom@ietf.org
Subject: RE: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 08:53:46 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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:mduffy@quarrytech.com]
> Sent: 01 August 2001 04:53
> To: Andrew Molitor; midcom@ietf.org
> 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
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 04:04:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21629
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 04:04:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13187;
	Wed, 1 Aug 2001 04:04:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13154
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 04:04:50 -0400 (EDT)
Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21580
	for <midcom@ietf.org>; Wed, 1 Aug 2001 04:03:48 -0400 (EDT)
From: richard.swale@bt.com
Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP;
          Wed, 1 Aug 2001 09:04:03 +0100
Received: by cbtlipnt01.btlabs.bt.co.uk 
          with Internet Mail Service (5.5.2652.35) id <P0YZ3SYC>;
          Wed, 1 Aug 2001 09:03:36 +0100
Message-ID: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk>
To: srisuresh@yahoo.com, bpenfield@acmepacket.com, ar_rayhan@yahoo.ca,
        midcom@ietf.org
Subject: RE: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 09:02:33 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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?
2. I think this is well into the area of defining requirements (I recall a
lengthy discussion concerning the fact and broad agreement that the
requirements document was the place where the "what was required" issues
were documented).
3. I prefer the first sentence of section 2.9 in the 03 draft. I do not
think we should be embelishing this point further in this document - the
requirements need to be discussed and documented in the requirements
document and not here!

regards

Richard

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 04:10:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21790
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 04:10:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13315;
	Wed, 1 Aug 2001 04:10:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13284
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 04:10:13 -0400 (EDT)
Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21759
	for <midcom@ietf.org>; Wed, 1 Aug 2001 04:09:10 -0400 (EDT)
From: richard.swale@bt.com
Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP;
          Wed, 1 Aug 2001 09:09:12 +0100
Received: by cbtlipnt02.btlabs.bt.co.uk 
          with Internet Mail Service (5.5.2652.35) id <K5BRTM4S>;
          Wed, 1 Aug 2001 09:08:13 +0100
Message-ID: <B76B75D34ACFD31180A600606DDFE79B09841D75@mbtlipnt04.btlabs.bt.co.uk>
To: midcom@ietf.org
Date: Wed, 1 Aug 2001 09:07:49 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Subject: [midcom] Framework section 4
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi,

I have been looking at some of the text in section 4 of the 03 framework
draft. The Third paragraph seems to embed quit a few assumptions as a
requirement. 

1. I don't think this actually adds any value to the framework as it relates
to pure protocol behaviour and should be deleted from this document.
2. Debate the requirements and document them in the requirements document
(actually these are kind of already there but we have not debated the
concensus on them I don't believe).

regards

Richard


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 05:18:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23624
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 05:18:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15044;
	Wed, 1 Aug 2001 05:18:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14959
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 05:18:05 -0400 (EDT)
Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23580;
	Wed, 1 Aug 2001 05:16:57 -0400 (EDT)
Received: from [213.122.168.213] (helo=tkw)
	by gadolinium.btinternet.com with smtp (Exim 3.22 #9)
	id 15Rs8b-00069E-00; Wed, 01 Aug 2001 10:17:58 +0100
Message-ID: <005b01c11a6a$e96d6240$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: <midcom@ietf.org>, "'sip-ietf (E-mail)'" <sip@ietf.org>,
        <sipping@ietf.org>, "SG16" <ITU-SG16@mailbag.cps.INTEL.COM>,
        <TIPHON@LIST.ETSI.FR>
Cc: "Steve Davies" <SDavies@Ridgeway-Sys.com>
Date: Wed, 1 Aug 2001 10:03:15 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit
Subject: [midcom] VoIP Traversal of Non-upgraded Firewall & NATs @ IETF
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Dear All,

I would like to have a meeting at the IETF (informal BOF?) discussing
methods for VoIP and Multimedia over IP traversing non-upgraded firewalls
and NATs.  These methods are intended to supplement the firewall
architecture, and not require upgrade to existing firewall/NAT components,
or clients (and other infrastructure such as proxies).

There is a draft discussing one proposal at:

http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt

If others have ideas in this area, then please contact me and we can arrange
some sort of agenda.  (Although note that I will be out of contact until the
Sunday before the IETF - i.e. this Sunday! - so we might have to organise
this at the IETF.)

I hope the format will be something like:

- Overview presentation of method
- How this is secure and maintains administrator control
- (Repeat for each proposal)
- Collect issues that need to be addressed before going to a formal BOF.

(The modified agenda involves the final item being changed to 'chaos'!)

At this stage I would like to avoid discussion about how this compares to
MidCom and other approaches - such as Rosenberg's - as I think it will
quickly turn into a blood bath.  - We should save that for the formal BOF!

I'm hoping to hold the meeting in:

    The King's Suite/Sandringham 1 on
    Thursday 17:45 -> 18:45,

but I obviously haven't had a chance to check this with the organisers.
Therefore, please look out for final details on the noticeboard, and
probably the door of the King's Suite.

I look forward to seeing you all,

Pete.

(P.S.  Sorry for putting this on the SG16 and TIPHON lists, but I'm well
aware that many of you attend the IETF and I wanted to make sure you had the
opportunity to come along.)

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 06:40:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26163
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 06:40:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17067;
	Wed, 1 Aug 2001 06:40:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17000
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 06:39:59 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26102
	for <midcom@ietf.org>; Wed, 1 Aug 2001 06:38:57 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f71A0Og20369
	for <midcom@ietf.org>; Wed, 1 Aug 2001 11:00:24 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 1 Aug 2001 11:00:03 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <QBDG9SRT>;
          Wed, 1 Aug 2001 11:00:01 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445125@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>, Andrew Molitor <amolitor@visi.com>,
        midcom@ietf.org
Subject: RE: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 11:00:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11A70.BAA1A6A0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11A70.BAA1A6A0
Content-Type: text/plain;
	charset="iso-8859-1"

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:mduffy@quarrytech.com]
Sent: Wednesday, August 01, 2001 5:53 AM
To: Andrew Molitor; midcom@ietf.org
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
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11A70.BAA1A6A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Framework comments &amp; suggestions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think we can summarize with:</FONT>
<BR><FONT SIZE=3D2>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..)</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>That's what Andrew meant.</FONT>
</P>

<P><FONT SIZE=3D2>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).</FONT></P>

<P><FONT SIZE=3D2>The Midcom agent is not necessarily co-hosted with a =
proxy, it could be co-hosted with any &quot;application agent&quot; =
</FONT>
</P>

<P><FONT SIZE=3D2>Having said that let's refocus on the mailing list on =
what is in scope.</FONT>
<BR><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 01, 2001 5:53 AM</FONT>
<BR><FONT SIZE=3D2>To: Andrew Molitor; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [midcom] Framework comments &amp; =
suggestions</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 10:40 AM 7/31/01 -0500, Andrew Molitor =
wrote:</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the =
second place, the distinction is, as I understand it,</FONT>
<BR><FONT SIZE=3D2>&gt;this:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In-path =
agents use information from IP packets IP</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; addressed to the agent =
host.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Out-of-path =
agents use information from IP packets</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP addressed to some other =
host.</FONT>
</P>

<P><FONT SIZE=3D2>This was not my understanding.&nbsp; I am surprised =
in fact not to see any</FONT>
<BR><FONT SIZE=3D2>responses to the above post (so far).&nbsp; Does the =
silence mean everyone</FONT>
<BR><FONT SIZE=3D2>agrees with the above statement?&nbsp; I guess we =
can at least conclude that the</FONT>
<BR><FONT SIZE=3D2>definition of in-path agent &quot;...devices that =
are naturally within the</FONT>
<BR><FONT SIZE=3D2>message path of the application&quot; is too =
vague!</FONT>
</P>

<P><FONT SIZE=3D2>Andrew's definition strikes me as unnecessarily =
restrictive of what can be</FONT>
<BR><FONT SIZE=3D2>an in-path agent (and therefore an in-scope agent =
:-)&nbsp; </FONT>
</P>

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

<P><FONT SIZE=3D2>-Mark</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/midcom</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11A70.BAA1A6A0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 07:19:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27188
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 07:18:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18023;
	Wed, 1 Aug 2001 07:19:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17992
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 07:19:03 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27092
	for <midcom@ietf.org>; Wed, 1 Aug 2001 07:18:01 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f71BGhJ24462;
	Wed, 1 Aug 2001 04:16:43 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATK29578;
	Wed, 1 Aug 2001 04:18:22 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801071616.00a17080@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 07:19:42 -0400
To: richard.swale@bt.com, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Framework comments & suggestions
In-Reply-To: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs
 .bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 09:02 AM 8/1/01 +0100, richard.swale@bt.com 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


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 07:24:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27603
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 07:24:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18121;
	Wed, 1 Aug 2001 07:24:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18094
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 07:24:28 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27556
	for <midcom@ietf.org>; Wed, 1 Aug 2001 07:23:26 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f71BO6322999;
	Wed, 1 Aug 2001 04:24:06 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATK29599;
	Wed, 1 Aug 2001 04:23:54 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801072249.00a10480@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 07:25:14 -0400
To: richard.swale@bt.com, mduffy@quarrytech.com, amolitor@visi.com,
        midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Framework comments & suggestions
In-Reply-To: <B76B75D34ACFD31180A600606DDFE79B09841D73@mbtlipnt04.btlabs
 .bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 08:53 AM 8/1/01 +0100, richard.swale@bt.com wrote:
>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?

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



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 07:26:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27652
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 07:26:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18228;
	Wed, 1 Aug 2001 07:27:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18199
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 07:27:10 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27647
	for <midcom@ietf.org>; Wed, 1 Aug 2001 07:26:08 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A6F4138020A; Wed, 01 Aug 2001 07:24:36 -0400
Message-ID: <008d01c11a7c$9c50ea60$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <richard.swale@bt.com>, <srisuresh@yahoo.com>, <ar_rayhan@yahoo.ca>,
        <midcom@ietf.org>
References: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk>
Subject: Re: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 07:24:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



----- Original Message -----
From: <richard.swale@bt.com>
To: <srisuresh@yahoo.com>; <bpenfield@acmepacket.com>; <ar_rayhan@yahoo.ca>;
<midcom@ietf.org>
Sent: Wednesday, August 01, 2001 4:02 AM
Subject: RE: [midcom] Framework comments & suggestions


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

That is exactly what the original sentence said.

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

Within the context of MIDCOM, the policy server is used to determine which
MIDCOM agents can do what. What is out-of-scope of MIDCOM is authorization
of specific flows or functions. The problem with the original sentence was
that it made resource authorization via the policy server out-of-scope for
middleboxes period, which is what I felt over stepped the bounds of what
MIDCOM should be specifying. Specifically, I was thinking that the policy
server could define pre-configured pin-holes for the middlebox (certainly
out-of-scope of MIDCOM).

However, I do see your point that this language might be interpreted to
restrict the level to which the policy server can control MIDCOM requests.
For example, I might want to say agent X is allowed to open pin-holes for a
narrow set of addresses. I originally wanted the sentence removed as you do
(that is still my preference), but was willing to compromise on language
that did not restrict what the middlebox used the policy server outside the
context of MIDCOM.

> 2. I think this is well into the area of defining requirements (I recall a
> lengthy discussion concerning the fact and broad agreement that the
> requirements document was the place where the "what was required" issues
> were documented).

Possibly, but certainly the framework document is the place to define what
is in scope and out of scope of MIDCOM.

> 3. I prefer the first sentence of section 2.9 in the 03 draft. I do not
> think we should be embelishing this point further in this document - the
> requirements need to be discussed and documented in the requirements
> document and not here!
>
> regards
>
> Richard
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 07:34:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27957
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 07:34:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18715;
	Wed, 1 Aug 2001 07:35:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18687
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 07:35:07 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27902
	for <midcom@ietf.org>; Wed, 1 Aug 2001 07:34:04 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f71BYeg17070
	for <midcom@ietf.org>; Wed, 1 Aug 2001 04:34:40 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATK29658;
	Wed, 1 Aug 2001 04:34:16 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801073256.00a17410@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 07:35:36 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Relationship to work being done in OPES
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

The IESG has asked us to consider the relationship between
the work being done in this working group and the work being
proposed in OPES.  I think it would be particularly interesting
to discuss this in the context of out-of-path agents.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 07:36:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27994
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 07:36:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18586;
	Wed, 1 Aug 2001 07:32:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18555
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 07:31:58 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27784
	for <midcom@ietf.org>; Wed, 1 Aug 2001 07:30:56 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f71BTdJ27327;
	Wed, 1 Aug 2001 04:29:39 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATK29645;
	Wed, 1 Aug 2001 04:31:26 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801073206.00a073c0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 07:32:46 -0400
To: "Bob Penfield" <bpenfield@acmepacket.com>, <midcom@ietf.org>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Framework comments & suggestions
In-Reply-To: <008d01c11a7c$9c50ea60$2300000a@acmepacket.com>
References: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 07:24 AM 8/1/01 -0400, Bob Penfield wrote:
>What is out-of-scope of MIDCOM is authorization
>of specific flows or functions. 

???  Why do you say that?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 08:00:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28757
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 08:00:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19294;
	Wed, 1 Aug 2001 08:00:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19259
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 08:00:15 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28725
	for <midcom@ietf.org>; Wed, 1 Aug 2001 07:59:12 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f71Bxr305595;
	Wed, 1 Aug 2001 04:59:53 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATL00149;
	Wed, 1 Aug 2001 04:59:38 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801075708.00a1a7a0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 08:00:58 -0400
To: lear@cisco.com, Pyda Srisuresh <srisuresh@yahoo.com>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] framework comments
Cc: midcom@ietf.org
In-Reply-To: <3B673414.21D5E1CB@cisco.com>
References: <20010731033924.3097.qmail@web13803.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 03:41 PM 7/31/01 -0700, Eliot Lear wrote:
>There are two reasons I would like to find a better definition.  One is
>simply on the faith that someone else has done the work.  The second is
>that I have a specific example in mind: application firewalls are NOT
>packet filtering firewalls.  Perhaps just dropping the words "packet
>filtering" might do fine.

Check out section 2 of RFC 2979 - do you think that something useful
could be distilled from that?


>There was a discussion on the IETF list about layering, which I what I'm
>referring to.

I'm not sure that we want to get too deeply involved in layering
discussions, but the fact that we are violating layers does have
some specific implications with regard to service location/
topology, scaling, error recovery, etc., and perhaps it's those 
implications that do need to be explored more thoroughly.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 08:02:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28798
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 08:02:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19491;
	Wed, 1 Aug 2001 08:01:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19454
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 08:01:52 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28770
	for <midcom@ietf.org>; Wed, 1 Aug 2001 08:00:49 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id AAC9146020A; Wed, 01 Aug 2001 07:40:57 -0400
Message-ID: <00a101c11a7e$e1f955a0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Andrew Molitor" <amolitor@visi.com>, <midcom@ietf.org>,
        "Mark Duffy" <mduffy@quarrytech.com>
References: <005001c119bf$adfd6f80$2300000a@acmepacket.com> <3.0.5.32.20010731235321.007db550@email.quarrytech.com>
Subject: Re: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 07:41:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Mark Duffy" <mduffy@quarrytech.com>
To: "Andrew Molitor" <amolitor@visi.com>; <midcom@ietf.org>
Sent: Tuesday, July 31, 2001 11:53 PM
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.

An "invisible" agent that was in-path would have to be another middlebox on
the path/pipe as the firewal/NAT middlebox. I suppose that is not illegal,
but then you would have all the packets traversing (data & control) two
middleboxes introducing potential latency and performance problems. With the
midcom agent co-resident with an application agent, only the
signalling/control messages must traverse the box with the midcom agent. The
data/media flows only go through one middlebox.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 08:18:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29147
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 08:18:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19858;
	Wed, 1 Aug 2001 08:19:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19829
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 08:19:10 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29127
	for <midcom@ietf.org>; Wed, 1 Aug 2001 08:18:07 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A32752029C; Wed, 01 Aug 2001 08:16:39 -0400
Message-ID: <010901c11a83$d69aed40$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <midcom@ietf.org>, "Melinda Shore" <mshore@cisco.com>
References: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk> <5.1.0.14.0.20010801073206.00a073c0@mira-sjc5-4.cisco.com>
Subject: Re: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 08:16:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I guess that just reinforces your point that the text is ambiguous. I was
attempting to clarify what it said and obviously failed. So that leaves us
with the question of what was originally intended by "The Policy server does
not assist a middlebox in the implementation of the services it provides or
with resource authorization on the middlebox"

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "Melinda Shore" <mshore@cisco.com>
To: "Bob Penfield" <bpenfield@acmepacket.com>; <midcom@ietf.org>
Sent: Wednesday, August 01, 2001 7:32 AM
Subject: Re: [midcom] Framework comments & suggestions


> At 07:24 AM 8/1/01 -0400, Bob Penfield wrote:
> >What is out-of-scope of MIDCOM is authorization
> >of specific flows or functions.
>
> ???  Why do you say that?
>
> Melinda
>
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 08:26:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29358
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 08:26:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19974;
	Wed, 1 Aug 2001 08:26:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19951
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 08:26:19 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29334
	for <midcom@ietf.org>; Wed, 1 Aug 2001 08:25:15 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f71CPpg05948;
	Wed, 1 Aug 2001 05:25:51 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATL00355;
	Wed, 1 Aug 2001 05:25:45 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801082553.00a17be0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 08:27:05 -0400
To: "Bob Penfield" <bpenfield@acmepacket.com>, <midcom@ietf.org>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Framework comments & suggestions
In-Reply-To: <010901c11a83$d69aed40$2300000a@acmepacket.com>
References: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk>
 <5.1.0.14.0.20010801073206.00a073c0@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 08:16 AM 8/1/01 -0400, Bob Penfield wrote:
>I guess that just reinforces your point that the text is ambiguous. I was
>attempting to clarify what it said and obviously failed. So that leaves us
>with the question of what was originally intended by "The Policy server does
>not assist a middlebox in the implementation of the services it provides or
>with resource authorization on the middlebox"

Right, that absolutely does need to be clarified.  But I don't
think it's correct to say that there's no policy involvement in
responses to requests.  Consider the lowly ACL.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 08:36:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29697
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 08:36:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20471;
	Wed, 1 Aug 2001 08:36:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20442
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 08:36:40 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29632
	for <midcom@ietf.org>; Wed, 1 Aug 2001 08:35:36 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f71CaCg09983
	for <midcom@ietf.org>; Wed, 1 Aug 2001 05:36:12 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-128.cisco.com [10.21.96.128])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIH14990;
	Wed, 1 Aug 2001 05:36:06 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 1 Aug 2001 08:36:07 -0400
Date: Wed, 1 Aug 2001 08:36:07 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] framework comments
Message-ID: <20010801083606.B1400@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010731033924.3097.qmail@web13803.mail.yahoo.com> <3B673414.21D5E1CB@cisco.com> <5.1.0.14.0.20010801075708.00a1a7a0@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010801075708.00a1a7a0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Wed, Aug 01, 2001 at 08:00:58AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 01, 2001 at 08:00:58AM -0400, Melinda Shore wrote:
> At 03:41 PM 7/31/01 -0700, Eliot Lear wrote:
> >There are two reasons I would like to find a better definition.  One is
> >simply on the faith that someone else has done the work.  The second is
> >that I have a specific example in mind: application firewalls are NOT
> >packet filtering firewalls.  Perhaps just dropping the words "packet
> >filtering" might do fine.
> 
> Check out section 2 of RFC 2979 - do you think that something useful
> could be distilled from that?

I'm having trouble getting excited about this nit.  If forced to choose,
though, I think Suresh's is at least as good.  In the end, regardless of
how much application context goes into the *why*, a firewall filters
packets.

Ned (2979): A "firewall" is an agent which screens network traffic in
some way, blocking traffic it believes to be inappropriate, dangerous,
or both.

Suresh (framework): Firewall is a policy based packet filtering
Middlebox function, typically used for restricting access to/from
specific devices and applications.

6 of one, 6.002 of the other (imho).


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 09:13:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01397
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 09:13:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21335;
	Wed, 1 Aug 2001 09:13:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21300
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 09:13:48 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01370
	for <midcom@ietf.org>; Wed, 1 Aug 2001 09:12:44 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f71DDP328952
	for <midcom@ietf.org>; Wed, 1 Aug 2001 06:13:25 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-159.cisco.com [10.21.112.159])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIH15187;
	Wed, 1 Aug 2001 06:13:13 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 1 Aug 2001 09:13:14 -0400
Date: Wed, 1 Aug 2001 09:13:13 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Relationship to work being done in OPES
Message-ID: <20010801091313.D1400@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <5.1.0.14.0.20010801073256.00a17410@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010801073256.00a17410@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Wed, Aug 01, 2001 at 07:35:36AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 01, 2001 at 07:35:36AM -0400, Melinda Shore wrote:
> The IESG has asked us to consider the relationship between
> the work being done in this working group and the work being
> proposed in OPES.  I think it would be particularly interesting
> to discuss this in the context of out-of-path agents.
> 
> Melinda

The Midcom protocol could be the same as the OPES protocol.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 09:14:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01436
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 09:14:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21251;
	Wed, 1 Aug 2001 09:11:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21221
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 09:11:24 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01275
	for <midcom@ietf.org>; Wed, 1 Aug 2001 09:10:19 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f71DAsg24868
	for <midcom@ietf.org>; Wed, 1 Aug 2001 06:10:54 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-159.cisco.com [10.21.112.159])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIH15174;
	Wed, 1 Aug 2001 06:10:49 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 1 Aug 2001 09:10:49 -0400
Date: Wed, 1 Aug 2001 09:10:49 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Framework section 4
Message-ID: <20010801090955.C1400@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <B76B75D34ACFD31180A600606DDFE79B09841D75@mbtlipnt04.btlabs.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B76B75D34ACFD31180A600606DDFE79B09841D75@mbtlipnt04.btlabs.bt.co.uk>; from richard.swale@bt.com on Wed, Aug 01, 2001 at 09:07:49AM +0100
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 01, 2001 at 09:07:49AM +0100, richard.swale@bt.com wrote:
> Hi,
> 
> I have been looking at some of the text in section 4 of the 03 framework
> draft. The Third paragraph seems to embed quit a few assumptions as a
> requirement. 
> 
> 1. I don't think this actually adds any value to the framework as it relates
> to pure protocol behaviour and should be deleted from this document.
> 2. Debate the requirements and document them in the requirements document
> (actually these are kind of already there but we have not debated the
> concensus on them I don't believe).
> 
> regards
> 
> Richard

Richard, could you be more specific?  I think it's reasonable to
describe use of the midcom protocol in the framework.  Let's see, the
implicit requirements I can find which might be contentious are:

- "The MIDCOM protocol will consist of a connection setup phase,
  run-time connection phase and a connection termination phase." There's
  an assumption of "connectedness" underlying all of this which I
  believe we have moved away from.  I don't know what "connection" is
  intended to mean here.  The requirement to be debated would be
  something like: "While an agent is registered with a middlebox, both
  will maintain a 'connected' state by periodically ensuring the other's
  well-being."  No?

- "Midcom is a peer-to-peer protocol. As such, either the agent or the
  middlebox may choose to initiate the connection."  I don't think this
  is really contentious but it would be nice to list it in the
  requirements and get explicit agreement on it.


Assumptions which are NOT contentious (imho):

- Functions in the same device don't have to communicate by IP.  That's
  true (they can also play pennywhistles), and it doesn't matter, it's
  completely out of our scope (which is okay when setting context).

- "Connection setup must be preceded by registration of the MIDCOM agent
  with either the middlebox or the Policy Server."  I suspect
  "registration" has two different meanings here, since "registration"
  with a policy server produces different results from "registration"
  with a middlebox.  However I think this is reasonable.  If a policy
  server is involved at all, then there may be some means -- out of
  scope for midcom -- by which an agent makes itself known to the policy
  server, and the policy server tells the middlebox about it.  I think
  it's reasonable to let the middlebox initiate communication with an
  agent.

- "A MIDCOM session may be terminated by either of the parties.  A
  MIDCOM session termination may also be triggered by one of (a) the
  middlebox or the agent going out of service and not being available
  for further MIDCOM operations, or (b) policy server notifying the
  middlebox that a particular MIDCOM agent is no longer authorized."

- "The MIDCOM framework is designed to be extensible to support
  deployment of other services as well."

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 09:29:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02082
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 09:28:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21545;
	Wed, 1 Aug 2001 09:29:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21516
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 09:29:00 -0400 (EDT)
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02024
	for <midcom@ietf.org>; Wed, 1 Aug 2001 09:27:56 -0400 (EDT)
Received: from dgismtp03.wcomnet.com ([166.38.58.143])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GHE00DBE5F8GA@firewall.mcit.com> for midcom@ietf.org; Wed,
 1 Aug 2001 13:28:20 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GHE00I015EVS7@dgismtp03.wcomnet.com>;
 Wed, 01 Aug 2001 13:28:20 +0000 (GMT)
Received: from rccc6131 ([166.35.225.191])
 by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0GHE00EPF5EJBX@dgismtp03.wcomnet.com>; Wed,
 01 Aug 2001 13:27:55 +0000 (GMT)
Date: Wed, 01 Aug 2001 08:27:51 -0500
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [midcom] framework comments
In-reply-to: <3B673414.21D5E1CB@cisco.com>
To: lear@cisco.com, "'Pyda Srisuresh'" <srisuresh@yahoo.com>
Cc: midcom@ietf.org
Reply-to: christopher.a.martin@wcom.com
Message-id: <000901c11a8d$c414e860$bfe123a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

RFC 2647 defines firewalls among other things for the purpose of
benchmarking firewall performance, by the Benchmarking Workgroup.

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Eliot Lear
Sent: Tuesday, July 31, 2001 5:41 PM
To: Pyda Srisuresh
Cc: midcom@ietf.org
Subject: Re: [midcom] framework comments


Hi,

Comments in line.

Pyda Srisuresh wrote:

> > "packet filtering" is but one type of firewall.  We should borrow a
> > better definition from elsewhere.
> >
>
> Eliot - There may be many variations to the theme, all eventually
> boiling down to packet permitting/filtering. The purpose was merely
> to expose this aspect of the firewall from middlebox function
> perspective.
>
> As I recall, there were multiple semantics associated with the term,
> at the time the discussion got started on the list. Some implying
> NAT function and IPsec Gateway function and so forth - all included
> in the same term.
>
> I believe, the current definition will suffie for the purposes of
> MIDCOM FW.

There are two reasons I would like to find a better definition.  One is
simply on the faith that someone else has done the work.  The second is
that I have a specific example in mind: application firewalls are NOT
packet filtering firewalls.  Perhaps just dropping the words "packet
filtering" might do fine.

>
> > Figure 3 - you skipped or removed step "5".
> >
>
> OK.
>
> > I'm also interested in changing some wording to the protocol
> > requirements, and a more general statement about protocol layering.  Bob
> > Braden's recent post to the IETF I think is most concerning.
> >
>
> Not sure what you are talkig about. I didnt see the e-mail from Bob
Braden.
> Were you going to suggest somethign specific to framework draft?

There was a discussion on the IETF list about layering, which I what I'm
referring to.


> We discussed this before on ths list. We agreed that the only policy
> server this WG will look into is the policy server authorizng the
> agents. Any application or user specific policy decisions are considered
> out of bounds for this WG.
> (Refer last paragraph in section 2.9).

I largely agree with the caveat that we need a method to pass opaque
information to the policy server in order to make its decision.  I seem to
recall in earlier discussion that I wouldn't want that becoming a huge
chatty conversation, but more of an EHLO-like exchange some of which could
be cached.

--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 10:11:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04326
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 10:11:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22686;
	Wed, 1 Aug 2001 10:11:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22657
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 10:11:11 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04268
	for <midcom@ietf.org>; Wed, 1 Aug 2001 10:10:02 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f71E7wJ19684
	for <midcom@ietf.org>; Wed, 1 Aug 2001 07:08:40 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-159.cisco.com [10.21.112.159])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIH15566;
	Wed, 1 Aug 2001 07:09:43 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 1 Aug 2001 10:09:43 -0400
Date: Wed, 1 Aug 2001 10:09:43 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Framework comments & suggestions
Message-ID: <20010801100943.E1400@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk> <5.1.0.14.0.20010801073206.00a073c0@mira-sjc5-4.cisco.com> <010901c11a83$d69aed40$2300000a@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <010901c11a83$d69aed40$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Wed, Aug 01, 2001 at 08:16:45AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 01, 2001 at 08:16:45AM -0400, Bob Penfield wrote:
> I guess that just reinforces your point that the text is ambiguous. I was
> attempting to clarify what it said and obviously failed. So that leaves us
> with the question of what was originally intended by "The Policy server does
> not assist a middlebox in the implementation of the services it provides or
> with resource authorization on the middlebox"

There are two separate issues.  

The text about implementation of services means that the
middlebox-policyserver relationship is orthogonal to the middlebox-agent
relationship.  The policy server provides information to the middlebox,
but does not get involved in the services middleboxes provide to agents
(unlike, say, an OPES device, which would be in a similar position in a
diagram but would be very involved in services).  I don't think there's
any disagreement here.

The statement that policy servers don't get involved in resource
authorization is the contentious one, and as you know I think it's
not appropriate.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 10:50:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06674
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 10:50:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23622;
	Wed, 1 Aug 2001 10:49:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23594
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 10:49:48 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06597
	for <midcom@ietf.org>; Wed, 1 Aug 2001 10:48:46 -0400 (EDT)
Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PDZ56MHA; Wed, 1 Aug 2001 10:49:17 -0400
Message-Id: <3.0.5.32.20010801104836.009065f0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 01 Aug 2001 10:48:36 -0400
To: Andrew Molitor <amolitor@visi.com>, richard.swale@bt.com,
        "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "Bob Penfield" <bpenfield@acmepacket.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
In-Reply-To: <3.0.5.32.20010731235321.007db550@email.quarrytech.com>
References: <Pine.GSO.4.21.0107311035040.15988-100000@isis.visi.com>
 <005001c119bf$adfd6f80$2300000a@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] defining in-path and out-of-path agents
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 12:45:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21341
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:45:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27838;
	Wed, 1 Aug 2001 12:44:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27810
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 12:44:54 -0400 (EDT)
Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21162
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:43:52 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f435551ba27cc5@cvis21.Marconicomms.com> for <midcom@ietf.org>;
 Wed, 1 Aug 2001 17:44:13 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id RAA14624; Wed, 1 Aug 2001 17:44:21 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A9B.005BE935 ; Wed, 1 Aug 2001 17:43:54 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Philip Mart" <Philip.Mart@marconi.com>
To: midcom@ietf.org
Message-ID: <80256A9B.005BE8A5.00@marconicomms.com>
Date: Wed, 1 Aug 2001 17:38:05 +0100
Subject: Re: [midcom] framework comments
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



Suresh,

Some nits I'm afraid:

Page 3 paragraph 1. Please change the words "Section 4 describes the nature of
MIDCOM protocol." to " Section 4 decsribes the nature of the task to performed
by a MIDCOM protocol."

We cannot describe the protocol or its nature because it has not been specified.
However describing the task it is expected to perform is , of course,
appropriate.

In the same paragraph, in the text referring to Section 7, change "in which the
MIDCOM agent is co-resident on a SIP proxy server" to "for the case where the
MIDCOM agent is co-resident on a SIP proxy server".

This removes any assumption, which could otherwise have been inferred,  that the
framework mandates the location of the agent on the same computing platform as a
SIP proxy.

I note that this has the same effect as a change requested by Richard Swale
which has received no response.

Section 2.1 First sentence. This is an extension of the definition of middlebox
but it implies that the middlebox and it's operations require application
intelligence. This is contrary to the purpose as described in the introduction.
"Middlebox functions behave in ways which vary according to the application
involved." may be text which conveys the same meaning as you originally
intended, is it? I recollect seeing  a similar request on this point in an
earlier post.

In the last line on page  3 change "of a middlebox function" to "of middlebox
functionality".  It would be helpful at this point to explain to the reader why
the examples you list are indeed middlebox functions, that is define the
charisteristics that single them out as middlebox functions by reference to
other documents or otherwise. The reason is that in the future applications will
arise which were not included in your list and the user can then determine with
confidence whether MIDCOM applies on a case by case basis.

Phil






_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 12:46:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21398
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:46:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27963;
	Wed, 1 Aug 2001 12:46:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27931
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 12:46:33 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21325
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:45:31 -0400 (EDT)
Received: from cisco.com (elear-dsl4.cisco.com [10.19.144.53]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA21869; Wed, 1 Aug 2001 09:46:01 -0700 (PDT)
Message-ID: <3B68324A.1020607@cisco.com>
Date: Wed, 01 Aug 2001 09:46:02 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628
X-Accept-Language: en-us
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] Relationship to work being done in OPES
References: <5.1.0.14.0.20010801073256.00a17410@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Could we put this on the end of the agenda at London?  And can the people 
leading the OPES effort be invited to participate in that discussion?
-- 
--
Eliot Lear
lear@cisco.com



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 12:46:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21422
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:46:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27725;
	Wed, 1 Aug 2001 12:37:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27698
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 12:37:54 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20851
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:36:52 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f71GbKg24783
	for <midcom@ietf.org>; Wed, 1 Aug 2001 17:37:20 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 1 Aug 2001 17:36:54 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PSC08CDK>; Wed, 1 Aug 2001 17:36:52 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C3044512A@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>, Andrew Molitor <amolitor@visi.com>,
        richard.swale@bt.com, Bob Penfield <bpenfield@acmepacket.com>,
        midcom@ietf.org
Subject: RE: [midcom] defining in-path and out-of-path agents
Date: Wed, 1 Aug 2001 17:36:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11AA8.27B1B4B0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11AA8.27B1B4B0
Content-Type: text/plain;
	charset="iso-8859-1"

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:mduffy@quarrytech.com]
Sent: Wednesday, August 01, 2001 4:49 PM
To: Andrew Molitor; richard.swale@bt.com; Aoun, Cedric [QPD:MA01:EXCH];
Bob Penfield; midcom@ietf.org
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
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11AA8.27B1B4B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] defining in-path and out-of-path agents</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 01, 2001 4:49 PM</FONT>
<BR><FONT SIZE=3D2>To: Andrew Molitor; richard.swale@bt.com; Aoun, =
Cedric [QPD:MA01:EXCH];</FONT>
<BR><FONT SIZE=3D2>Bob Penfield; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [midcom] defining in-path and out-of-path =
agents</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think a lot of the confusion here is because we =
have coined two terms</FONT>
<BR><FONT SIZE=3D2>(in-path and out-of-path agents) but in fact there =
are at least three cases:</FONT>
</P>

<P><FONT SIZE=3D2>a.) agents in boxes to whom the packets to be =
inspected/modified by the</FONT>
<BR><FONT SIZE=3D2>agent are specifically addressed at the IP =
layer.&nbsp; Perhaps called</FONT>
<BR><FONT SIZE=3D2>&quot;logically and physically in-path&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>b.) agents in boxes through which the packets in =
question are flowing, but</FONT>
<BR><FONT SIZE=3D2>to which the packets are not specifically =
IP-addressed.&nbsp; Perhaps called</FONT>
<BR><FONT SIZE=3D2>&quot;physically in-path&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>c.) agents in boxes through which the packets in =
question do not flow</FONT>
<BR><FONT SIZE=3D2>(unless diverted for that specific purpose)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think we would probably all agree that a. are =
&quot;in-path&quot; agents and</FONT>
<BR><FONT SIZE=3D2>therefore in-scope.</FONT>
<BR><FONT SIZE=3D2>I think we would probably all agree that c. are =
&quot;out-of-path&quot; agents and</FONT>
<BR><FONT SIZE=3D2>therefore out of scope.</FONT>
</P>

<P><FONT SIZE=3D2>I had understood b. to be in-path and in-scope, =
because I interpret this as</FONT>
<BR><FONT SIZE=3D2>falling within the definition &quot;... within the =
message path of the</FONT>
<BR><FONT SIZE=3D2>application...&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>I do not see why b. should be out of scope.&nbsp; =
What does it matter to midcom</FONT>
<BR><FONT SIZE=3D2>how the agent gets hold of the relevant application =
packets (as long as</FONT>
<BR><FONT SIZE=3D2>midcom does not have to do anything about it such as =
diversion)?&nbsp; I think</FONT>
<BR><FONT SIZE=3D2>the difference between a. and b. would be =
transparent to midcom.</FONT>
</P>

<P><FONT SIZE=3D2>Regardless, we should improve our terminology.&nbsp; =
I suggest some terms above</FONT>
<BR><FONT SIZE=3D2>to differentiate a. and b.</FONT>
</P>

<P><FONT SIZE=3D2>Regards, Mark</FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/midcom</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11AA8.27B1B4B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 12:48:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21498
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:48:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27925;
	Wed, 1 Aug 2001 12:46:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27882
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 12:46:30 -0400 (EDT)
Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21322
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:45:28 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T01010101551ba29dfa@cvis28.marconicomms.com> for <midcom@ietf.org>;
 Wed, 1 Aug 2001 17:44:22 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id RAA14627; Wed, 1 Aug 2001 17:44:21 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A9B.005BE8D6 ; Wed, 1 Aug 2001 17:43:53 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Philip Mart" <Philip.Mart@marconi.com>
To: midcom@ietf.org
Message-ID: <80256A9B.005BE8A5.00@marconicomms.com>
Date: Wed, 1 Aug 2001 17:45:10 +0100
Subject: Re: [Midcom] Framework comments
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



Suresh,

Looking again at 2.2 on page 4 what is the point of all but the first sentence
in this subsection. Are we to deduce from its omission that a Load Balancing
middlebox is NOT a middlebox implementing Load balancing services. I suspect
that we are meant to assume that the principle of the two example is extended to
all middleboxes. The draft doesn't say so though!  I guess the best answer is to
delete all but the first sentence. Please prepend "A " to the first sentence.

2.3  I agree with Eliot that a definition from elsewhere is needed. In general
if we use our own words please write as little as possible to minimise the
detail which others disagree with! I fail to see how we can drop the "packet
filtering" words though. It is the immediate link by the reader between what
MIDCOM controlled middleboxes do and an applications level firewall that we
should avoid. The current wording fails to do this becasue the general
description of a MIDCOM controlled function was not spelt out earlier. Having
suggested that we drop all but the first(amended) sentence in 2.2 why not ditch
2.3 and 2.4 as redundant?

The NAT references could be reintroduced around Fig 1 if they are really
necessary to explain the framework.

2.5 last sentence change "can intercept" to "may be used in a configuration
where it intercepts", change "intercept only" to "only intercept". The last
sentence is not helpful please delete it.


2.6  I have much difficulty with the first paragraph because it implies that an
ALG looks at the traffic but Midcom agents are later defined as being ALG's
without the traffic!  Why not drop the second sentence in the first paragraph?

The third paragraph starts out by descibing that an ALG is not a proxy. This is
not necessary here. Delete the first sentence and then delete "the" from the
second sentence.

In the second paragraph the ALG is defined in terms of its location! If it were
not for the location why would the ALG be any different from the MIDCOM Agent in
the description of its functions.  Since I am not convinced that we can remove
ALG from the document because of its use in later tutorial text I suspect that
it may be wise to accept the suggestions that Richard Swale made on July 23 and
clarify the difference in a robust way.

I notice that ALG does not appear in the document in a sustantive way until page
15 and then 32 where it could be eliminated altogether with limited editing.
This sub-section needs to be re-written to clarify the difference between ALG
and MIDCOM agent.

2.8  At this point ALGs had all the application intelligence and MIDCOM agents
are external to the the middlebox. In the second paragraph we only deal with
in-path agents. BUT MIDCOM agents are external to the middlebox so they MUST be
OUT OF PATH! The notion that in-path means located on devices that are naturally
in the message path is rather hard to take. I have in mind an agent commanding a
middlebox which is principally a packet forwarder of some description which does
not pass traffic packets through the stack that it uses for receiving commands
from the MIDCOM agent. This sub-section declares that such configurations are
out of scope. In essence this is an implied requirement that the middlebox be
implemented on the same IP stack as a midcom agent. Such a requirement has not
been agreed as far I  remember , and if it has it shouldn't have been!

What I believe needs to be said is that "In-path means that a middlebox,  under
the control of a competent MIDCOM Agent,  is present in the message path
normally used by the application".

Didn't Richard urge you to drop all the in-path, out-of path stuff by defining
ALG differently?

2.9

I suspect that you did not mean the requirement implied by the first sentence
that the Policy server need not be taken as authoritative by a middlebox. What
did you mean to say?

I note that the second sentence is also in the requirements document in section
6.7.1. As regards the framework the existance of a different protocol, that is a
matter of protocol requirement and should not be stated here. I suggest you
delete the second paragraph.

The third paragraph starts out by saying that a policy interface which is
specifica to an application is out of scope for this document. Then in the third
sentence it describes a policy interface using SIP... but that is out of scope
for this document so why put it in? What also comes out of this is that the
policy about which flows to allow is the concern of a policy server but is then
disallowed only because it is found using an application specific protocol.

I suggest that you replace the whole of sub-section 2.9 with the word in
sub-section 4.3 of the current requirements draft, sorry about the overlap.


Phil


As mignt be expected this stems from the definitional confusion about ALG  in
2.6 and should be cleared up.






_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 12:52:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21720
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:52:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28069;
	Wed, 1 Aug 2001 12:48:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28040
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 12:48:24 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21465
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:47:22 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f71Gm6Y07054;
	Wed, 1 Aug 2001 09:48:06 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATM03965;
	Wed, 1 Aug 2001 09:47:51 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801124431.00a25ae0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 12:49:07 -0400
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] defining in-path and out-of-path agents
In-Reply-To: <9154CB41F208D5118DD200508BE39C3044512A@zjguc006.europe.nor
 tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 12:55:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21836
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:55:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28187;
	Wed, 1 Aug 2001 12:53:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28153
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 12:53:53 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21717
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:52:51 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f71Gr7312061;
	Wed, 1 Aug 2001 09:53:07 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATM04126;
	Wed, 1 Aug 2001 09:51:33 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801125130.00a28bd0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 12:52:48 -0400
To: lear@cisco.com
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Relationship to work being done in OPES
Cc: midcom@ietf.org
In-Reply-To: <3B68324A.1020607@cisco.com>
References: <5.1.0.14.0.20010801073256.00a17410@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 09:46 AM 8/1/01 -0700, Eliot Lear wrote:
>Could we put this on the end of the agenda at London?  And can the people leading the OPES effort be invited to participate in that discussion?

Forgot to mention that it *will* be discussed at the OPES BOF on
Tuesday morning. 

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 12:59:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22041
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:59:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28339;
	Wed, 1 Aug 2001 12:59:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28309
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 12:59:33 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22001
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:58:31 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A4DE1B6020A; Wed, 01 Aug 2001 12:57:02 -0400
Message-ID: <002901c11aab$3f52b800$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Scott Brim" <sbrim@cisco.com>, <midcom@ietf.org>
References: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk> <5.1.0.14.0.20010801073206.00a073c0@mira-sjc5-4.cisco.com> <010901c11a83$d69aed40$2300000a@acmepacket.com> <20010801100943.E1400@SBRIM-W2K>
Subject: Re: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 12:58:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Scott Brim" <sbrim@cisco.com>
To: <midcom@ietf.org>
Sent: Wednesday, August 01, 2001 10:09 AM
Subject: Re: [midcom] Framework comments & suggestions


> On Wed, Aug 01, 2001 at 08:16:45AM -0400, Bob Penfield wrote:
> > I guess that just reinforces your point that the text is ambiguous. I
was
> > attempting to clarify what it said and obviously failed. So that leaves
us
> > with the question of what was originally intended by "The Policy server
does
> > not assist a middlebox in the implementation of the services it provides
or
> > with resource authorization on the middlebox"
>
> There are two separate issues.
>
> The text about implementation of services means that the
> middlebox-policyserver relationship is orthogonal to the middlebox-agent
> relationship.  The policy server provides information to the middlebox,
> but does not get involved in the services middleboxes provide to agents
> (unlike, say, an OPES device, which would be in a similar position in a
> diagram but would be very involved in services).  I don't think there's
> any disagreement here.

I still don't understand. Are you saying the policy server cannot tell the
middlebox which services a particular agent is allowed to use?

>
> The statement that policy servers don't get involved in resource
> authorization is the contentious one, and as you know I think it's
> not appropriate.

What does "resource authorization" mean?

My belief is that the information the policy server gives to the middlebox
will tell it which agents are allowed to talk to it, and which specific
functions a given agent is allowed to perform. This could even extend to the
middlebox consulting the policy server on a flow-by-flow or
request-by-request basis to determine if it should perform the operation
requested by the agent.

The only thing I have thought of so far in a policy server which might be
"out-of-scope" of MIDCOM would be information about statically configured
pin-holes or NATs.

Can you give some examples of the kinds of things you don't want the policy
server to do?

(-:bob



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 13:30:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23491
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 13:30:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29144;
	Wed, 1 Aug 2001 13:28:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29115
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 13:28:52 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23409
	for <midcom@ietf.org>; Wed, 1 Aug 2001 13:27:50 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f71HSIg29641
	for <midcom@ietf.org>; Wed, 1 Aug 2001 18:28:19 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 1 Aug 2001 18:28:02 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <QB9DTZDF>;
          Wed, 1 Aug 2001 18:28:01 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C3044512D@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] defining in-path and out-of-path agents
Date: Wed, 1 Aug 2001 18:28:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11AAF.51352180"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11AAF.51352180
Content-Type: text/plain;
	charset="iso-8859-1"

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:mshore@cisco.com]
Sent: Wednesday, August 01, 2001 6:49 PM
To: Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org
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


------_=_NextPart_001_01C11AAF.51352180
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] defining in-path and out-of-path agents</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>OK probably some implementations might support that =
and we need to be democratic.</FONT>
<BR><FONT SIZE=3D2>I still think that this is a weird usage of the =
Midcom protocol.</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 01, 2001 6:49 PM</FONT>
<BR><FONT SIZE=3D2>To: Aoun, Cedric [QPD:MA01:EXCH]; =
midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [midcom] defining in-path and =
out-of-path agents</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 05:36 PM 8/1/01 +0100, Cedric Aoun wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;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.</FONT></P>

<P><FONT SIZE=3D2>I don't think so.&nbsp; As Scott Brim keeps reminding =
us, we're talking</FONT>
<BR><FONT SIZE=3D2>about functions, not boxes.&nbsp; We've been saying =
all along that an</FONT>
<BR><FONT SIZE=3D2>agent could be placed inside a firewall.&nbsp; I =
would tend to regard those</FONT>
<BR><FONT SIZE=3D2>as in-path agents, myself.</FONT>
</P>

<P><FONT SIZE=3D2>Melinda</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11AAF.51352180--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 15:32:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29676
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 15:32:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02539;
	Wed, 1 Aug 2001 15:31:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02468
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 15:31:39 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29599
	for <midcom@ietf.org>; Wed, 1 Aug 2001 15:30:30 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f71JUW905041
	for <midcom@ietf.org>; Wed, 1 Aug 2001 15:30:32 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 1 Aug 2001 15:30:43 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSFTQT>; Wed, 1 Aug 2001 15:30:45 -0400
Message-ID: <D38D073716F2D411BEE400508BCF6296133598@zcard04k.ca.nortel.com>
From: "Fernando Cuervo" <cuervo@nortelnetworks.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>, Scott Brim <sbrim@cisco.com>,
        midcom <midcom@ietf.org>
Subject: RE: [midcom] Framework comments & suggestions
Date: Wed, 1 Aug 2001 15:30:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11AC0.74FBB320"
X-Orig: <cuervo@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11AC0.74FBB320
Content-Type: text/plain

Why do we care how static pin-holes are configured in the MB?
Why would support of the Midcom protocol dictate how the services the MB
provides
can be configured or implemented? 

Fernando Cuervo

> -----Original Message-----
> From:	Bob Penfield [SMTP:bpenfield@acmepacket.com]
> Sent:	Wednesday, August 01, 2001 12:59 PM
> To:	Scott Brim; midcom
> Subject:	Re: [midcom] Framework comments & suggestions
> 
> 
> ----- Original Message -----
> From: "Scott Brim" <sbrim@cisco.com>
> To: <midcom@ietf.org>
> Sent: Wednesday, August 01, 2001 10:09 AM
> Subject: Re: [midcom] Framework comments & suggestions
> 
> 
> > On Wed, Aug 01, 2001 at 08:16:45AM -0400, Bob Penfield wrote:
> > > I guess that just reinforces your point that the text is ambiguous. I
> was
> > > attempting to clarify what it said and obviously failed. So that
> leaves
> us
> > > with the question of what was originally intended by "The Policy
> server
> does
> > > not assist a middlebox in the implementation of the services it
> provides
> or
> > > with resource authorization on the middlebox"
> >
> > There are two separate issues.
> >
> > The text about implementation of services means that the
> > middlebox-policyserver relationship is orthogonal to the middlebox-agent
> > relationship.  The policy server provides information to the middlebox,
> > but does not get involved in the services middleboxes provide to agents
> > (unlike, say, an OPES device, which would be in a similar position in a
> > diagram but would be very involved in services).  I don't think there's
> > any disagreement here.
> 
> I still don't understand. Are you saying the policy server cannot tell the
> middlebox which services a particular agent is allowed to use?
> 
> >
> > The statement that policy servers don't get involved in resource
> > authorization is the contentious one, and as you know I think it's
> > not appropriate.
> 
> What does "resource authorization" mean?
> 
> My belief is that the information the policy server gives to the middlebox
> will tell it which agents are allowed to talk to it, and which specific
> functions a given agent is allowed to perform. This could even extend to
> the
> middlebox consulting the policy server on a flow-by-flow or
> request-by-request basis to determine if it should perform the operation
> requested by the agent.
> 
> The only thing I have thought of so far in a policy server which might be
> "out-of-scope" of MIDCOM would be information about statically configured
> pin-holes or NATs.
> 
> Can you give some examples of the kinds of things you don't want the
> policy
> server to do?
> 
> (-:bob
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11AC0.74FBB320
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Framework comments &amp; suggestions</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Why do we care how =
static pin-holes are configured in the MB?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Why would support =
of the Midcom protocol dictate how the services the MB provides</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">can be configured =
or implemented? </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Fernando =
Cuervo</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Bob Penfield =
[SMTP:bpenfield@acmepacket.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, August 01, 2001 12:59 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Scott Brim; midcom</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: [midcom] Framework comments =
&amp; suggestions</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">----- Original Message -----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: &quot;Scott Brim&quot; =
&lt;sbrim@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: &lt;midcom@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Wednesday, August 01, 2001 =
10:09 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: [midcom] Framework =
comments &amp; suggestions</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; On Wed, Aug 01, 2001 at =
08:16:45AM -0400, Bob Penfield wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I guess that just =
reinforces your point that the text is ambiguous. I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">was</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; attempting to clarify what =
it said and obviously failed. So that leaves</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">us</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; with the question of what =
was originally intended by &quot;The Policy server</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; not assist a middlebox in =
the implementation of the services it provides</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; with resource authorization =
on the middlebox&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; There are two separate =
issues.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The text about implementation of =
services means that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; middlebox-policyserver =
relationship is orthogonal to the middlebox-agent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; relationship.&nbsp; The policy =
server provides information to the middlebox,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; but does not get involved in the =
services middleboxes provide to agents</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; (unlike, say, an OPES device, =
which would be in a similar position in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; diagram but would be very =
involved in services).&nbsp; I don't think there's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; any disagreement here.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I still don't understand. Are you =
saying the policy server cannot tell the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">middlebox which services a particular =
agent is allowed to use?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The statement that policy =
servers don't get involved in resource</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; authorization is the contentious =
one, and as you know I think it's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; not appropriate.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What does &quot;resource =
authorization&quot; mean?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">My belief is that the information the =
policy server gives to the middlebox</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will tell it which agents are allowed =
to talk to it, and which specific</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">functions a given agent is allowed to =
perform. This could even extend to the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">middlebox consulting the policy =
server on a flow-by-flow or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">request-by-request basis to determine =
if it should perform the operation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requested by the agent.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The only thing I have thought of so =
far in a policy server which might be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;out-of-scope&quot; of MIDCOM =
would be information about statically configured</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pin-holes or NATs.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can you give some examples of the =
kinds of things you don't want the policy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">server to do?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(-:bob</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">midcom mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">midcom@ietf.org</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/midcom</A></FONT>=
</U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C11AC0.74FBB320--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 15:33:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29756
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 15:33:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02601;
	Wed, 1 Aug 2001 15:33:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02572
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 15:33:08 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29661
	for <midcom@ietf.org>; Wed, 1 Aug 2001 15:32:04 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f71JUkJ19878
	for <midcom@ietf.org>; Wed, 1 Aug 2001 12:30:47 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-159.cisco.com [10.21.112.159])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIH21387;
	Wed, 1 Aug 2001 12:32:31 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 1 Aug 2001 15:32:31 -0400
Date: Wed, 1 Aug 2001 15:32:30 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] defining in-path and out-of-path agents
Message-ID: <20010801153230.A1340@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <9154CB41F208D5118DD200508BE39C3044512A@zjguc006.europe.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9154CB41F208D5118DD200508BE39C3044512A@zjguc006.europe.nortel.com>; from CEDRIC.AOUN@nortelnetworks.com on Wed, Aug 01, 2001 at 05:36:46PM +0100
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 01, 2001 at 05:36:46PM +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.

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

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 15:41:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00376
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 15:41:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02758;
	Wed, 1 Aug 2001 15:39:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02717
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 15:39:05 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00049
	for <midcom@ietf.org>; Wed, 1 Aug 2001 15:37:57 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f71JcfY09065;
	Wed, 1 Aug 2001 12:38:41 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp61.cisco.com [10.21.64.61])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATO04933;
	Wed, 1 Aug 2001 12:37:57 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010801153716.00a26030@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 15:39:06 -0400
To: "Fernando Cuervo" <cuervo@nortelnetworks.com>,
        "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] defining in-path and out-of-path agents
In-Reply-To: <D38D073716F2D411BEE400508BCF6296133597@zcard04k.ca.nortel.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 03:25 PM 8/1/01 -0400, Fernando Cuervo wrote:

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

It is possible, if unlikely, that someone might want to run a midcom protocol between
an agent and a firewall on the same box.  

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 15:49:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01103
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 15:49:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02123;
	Wed, 1 Aug 2001 15:26:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02092
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 15:26:37 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29409
	for <midcom@ietf.org>; Wed, 1 Aug 2001 15:25:33 -0400 (EDT)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f71JPS903824
	for <midcom@ietf.org>; Wed, 1 Aug 2001 15:25:28 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 1 Aug 2001 15:25:39 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSFTM3>; Wed, 1 Aug 2001 15:25:40 -0400
Message-ID: <D38D073716F2D411BEE400508BCF6296133597@zcard04k.ca.nortel.com>
From: "Fernando Cuervo" <cuervo@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>,
        "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>, midcom@ietf.org
Subject: RE: [midcom] defining in-path and out-of-path agents
Date: Wed, 1 Aug 2001 15:25:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11ABF.BEA86FF0"
X-Orig: <cuervo@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11ABF.BEA86FF0
Content-Type: text/plain

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. 

> -----Original Message-----
> From:	Melinda Shore [SMTP:mshore@cisco.com]
> Sent:	Wednesday, August 01, 2001 12:49 PM
> To:	Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org
> 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
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11ABF.BEA86FF0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] defining in-path and out-of-path agents</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">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. </FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Melinda Shore [SMTP:mshore@cisco.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, August 01, 2001 12:49 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: [midcom] defining in-path and =
out-of-path agents</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">At 05:36 PM 8/1/01 +0100, Cedric Aoun =
wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't think so.&nbsp; As Scott Brim =
keeps reminding us, we're talking</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about functions, not boxes.&nbsp; =
We've been saying all along that an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">agent could be placed inside a =
firewall.&nbsp; I would tend to regard those</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">as in-path agents, myself.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Melinda</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">midcom mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">midcom@ietf.org</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/midcom</A></FONT>=
</U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C11ABF.BEA86FF0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 15:55:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01460
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 15:55:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03006;
	Wed, 1 Aug 2001 15:54:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02977
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 15:54:32 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01280
	for <midcom@ietf.org>; Wed, 1 Aug 2001 15:53:28 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id A3E018229
	for <midcom@ietf.org>; Wed,  1 Aug 2001 14:54:30 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id OAA07761
	for <midcom@ietf.org>; Wed, 1 Aug 2001 14:54:30 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 1 Aug 2001 14:54:30 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: RE: [midcom] defining in-path and out-of-path agents
In-Reply-To: <5.1.0.14.0.20010801153716.00a26030@mira-sjc5-4.cisco.com>
Message-ID: <Pine.GSO.4.21.0108011451040.7283-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Wed, 1 Aug 2001, Melinda Shore wrote:

> At 03:25 PM 8/1/01 -0400, Fernando Cuervo wrote:
> 
> >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. 
> 
> It is possible, if unlikely, that someone might want to run a midcom protocol between
> an agent and a firewall on the same box.  

	This is the land of networking. If it is possible, the probability
is nearly 1 that someone somewhere will want to do it.

	If you have middlebox technology and agent technology, which
technologies communicate via MIDCOM, it makes perfect sense to package
the two together, talking MIDCOM over sockets connected to localhost,
to implement a lower end solution.

	I agree that things become much clearer if you think in
terms of functions, not boxes. My experience suggests that drawing
a "box" around any particular set of functions tends to yield a
more or less well-defined device, which someone will surely desire
some day.


		Andrew


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 16:15:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02659
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 16:15:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03742;
	Wed, 1 Aug 2001 16:15:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03711
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 16:15:07 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02594
	for <midcom@ietf.org>; Wed, 1 Aug 2001 16:14:03 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f71KEdg24124
	for <midcom@ietf.org>; Wed, 1 Aug 2001 13:14:39 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-159.cisco.com [10.21.112.159])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIH22184;
	Wed, 1 Aug 2001 13:14:33 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 1 Aug 2001 16:14:32 -0400
Date: Wed, 1 Aug 2001 16:14:32 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom <midcom@ietf.org>
Subject: Re: [midcom] Framework comments & suggestions
Message-ID: <20010801161431.C1408@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom <midcom@ietf.org>
References: <D38D073716F2D411BEE400508BCF6296133598@zcard04k.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <D38D073716F2D411BEE400508BCF6296133598@zcard04k.ca.nortel.com>; from cuervo@nortelnetworks.com on Wed, Aug 01, 2001 at 03:30:44PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 01, 2001 at 03:30:44PM -0400, Fernando Cuervo wrote:
> Why do we care how static pin-holes are configured in the MB?  Why
> would support of the Midcom protocol dictate how the services the MB
> provides can be configured or implemented? 
> 
> Fernando Cuervo

Right.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 16:16:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02672
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 16:16:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03629;
	Wed, 1 Aug 2001 16:14:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03599
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 16:14:06 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02531
	for <midcom@ietf.org>; Wed, 1 Aug 2001 16:13:02 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f71KDcg23536
	for <midcom@ietf.org>; Wed, 1 Aug 2001 13:13:38 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-159.cisco.com [10.21.112.159])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIH22171;
	Wed, 1 Aug 2001 13:13:33 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 1 Aug 2001 16:13:32 -0400
Date: Wed, 1 Aug 2001 16:13:32 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Framework comments & suggestions
Message-ID: <20010801161331.B1408@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <B76B75D34ACFD31180A600606DDFE79B09841D74@mbtlipnt04.btlabs.bt.co.uk> <5.1.0.14.0.20010801073206.00a073c0@mira-sjc5-4.cisco.com> <010901c11a83$d69aed40$2300000a@acmepacket.com> <20010801100943.E1400@SBRIM-W2K> <002901c11aab$3f52b800$2300000a@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002901c11aab$3f52b800$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Wed, Aug 01, 2001 at 12:58:52PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

See inline ...

On Wed, Aug 01, 2001 at 12:58:52PM -0400, Bob Penfield wrote:
> 
> ----- Original Message -----
> From: "Scott Brim" <sbrim@cisco.com>
> To: <midcom@ietf.org>
> Sent: Wednesday, August 01, 2001 10:09 AM
> Subject: Re: [midcom] Framework comments & suggestions
> 
> 
> > On Wed, Aug 01, 2001 at 08:16:45AM -0400, Bob Penfield wrote:
> > > I guess that just reinforces your point that the text is ambiguous. I
> was
> > > attempting to clarify what it said and obviously failed. So that leaves
> us
> > > with the question of what was originally intended by "The Policy server
> does
> > > not assist a middlebox in the implementation of the services it provides
> or
> > > with resource authorization on the middlebox"
> >
> > There are two separate issues.
> >
> > The text about implementation of services means that the
> > middlebox-policyserver relationship is orthogonal to the middlebox-agent
> > relationship.  The policy server provides information to the middlebox,
> > but does not get involved in the services middleboxes provide to agents
> > (unlike, say, an OPES device, which would be in a similar position in a
> > diagram but would be very involved in services).  I don't think there's
> > any disagreement here.
> 
> I still don't understand. Are you saying the policy server cannot tell the
> middlebox which services a particular agent is allowed to use?

Not at all.  Don't you love English?  The policy server can tell the
middlebox what a particular agent is allowed to do (both at registration
time and at transaction time, I believe).  However, the policy server,
in its specific role as a policy server, does not provide the services
or participate in the midcom protocol.  The middlebox does all of that.

AI suspect we're agreeing.  lternate text for this sentence was already
proposed, wasn't it?

> >
> > The statement that policy servers don't get involved in resource
> > authorization is the contentious one, and as you know I think it's
> > not appropriate.
> 
> What does 'resource authorization' mean?

It means I'm reading too fast.  What it meant originally was the policy
server saying an agent is allowed to do.  I confounded that with the
policy server saying which particular requests are allowed.

> My belief is that the information the policy server gives to the middlebox
> will tell it which agents are allowed to talk to it, and which specific
> functions a given agent is allowed to perform. This could even extend to the
> middlebox consulting the policy server on a flow-by-flow or
> request-by-request basis to determine if it should perform the operation
> requested by the agent.

Right.

> The only thing I have thought of so far in a policy server which might be
> "out-of-scope" of MIDCOM would be information about statically configured
> pin-holes or NATs.

Well, the entire policy server protocol is out of scope -- the framework
draft is context, stating the expected existence of a policy server.

> Can you give some examples of the kinds of things you don't want the policy
> server to do?

Something which does NAT is not a policy server -- although it might be
in the same device.  The policy server does not deliver the services of
a middlebox.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 17:42:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06117
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 17:42:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05585;
	Wed, 1 Aug 2001 17:29:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05554
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 17:29:18 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05732
	for <midcom@ietf.org>; Wed, 1 Aug 2001 17:28:14 -0400 (EDT)
Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PDZ56NF7; Wed, 1 Aug 2001 17:28:45 -0400
Message-Id: <3.0.5.32.20010801172805.00901a00@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 01 Aug 2001 17:28:05 -0400
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: RE: [midcom] defining in-path and out-of-path agents
In-Reply-To: <9154CB41F208D5118DD200508BE39C3044512D@zjguc006.europe.nor
 tel.com>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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:mshore@cisco.com>mailto:mshore@cisco.com] 

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

To: Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org 

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
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 18:15:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07274
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 18:15:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06822;
	Wed, 1 Aug 2001 18:12:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06793
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 18:12:48 -0400 (EDT)
Received: from web13806.mail.yahoo.com (web13806.mail.yahoo.com [216.136.175.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07162
	for <midcom@ietf.org>; Wed, 1 Aug 2001 18:11:45 -0400 (EDT)
Message-ID: <20010801221244.22379.qmail@web13806.mail.yahoo.com>
Received: from [66.89.112.150] by web13806.mail.yahoo.com; Wed, 01 Aug 2001 15:12:44 PDT
Date: Wed, 1 Aug 2001 15:12:44 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
To: midcom@ietf.org
In-Reply-To: <20010731160300.78972.qmail@web13806.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [midcom] Framework draft - editorial meeting
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


Folks,

Let us meet on Thursday (08/09) evening @ 19:30 hrs at the lobby 
to discuss editorial nits to the framework draft. Thanks.

cheers,
suresh

--- Pyda Srisuresh <srisuresh@yahoo.com> wrote:
> I am there the whole week. Most likely, any time in the evening
> will work for me. Any thoughts on alternate time? Thanks.
> 
> cheers,
> suresh 
> --- Bob Penfield <bpenfield@acmepacket.com> wrote:
> > 
> > 
> > 
> > ----- Original Message ----- 
> > From: "Melinda Shore" <mshore@cisco.com>
> > To: "Pyda Srisuresh" <srisuresh@yahoo.com>; <midcom@ietf.org>
> > Sent: Tuesday, July 31, 2001 11:42 AM
> > Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft)
> > 
> > 
> > > At 08:33 AM 7/31/01 -0700, Pyda Srisuresh wrote:
> > > >Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in the
> > > >main lobby. 
> > > 
> > > Please try to keep some flexibility in your choice of time slot -
> > > that falls during the social event, which may be an issue for a
> > > number of people.
> > 
> > I agree. All work and no play makes Johnny a dull boy.
> > 
> > Can we find a different time.
> > 
> 
> 
> =====
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom


=====


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 19:20:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09747
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 19:20:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08285;
	Wed, 1 Aug 2001 19:15:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08254
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 19:15:34 -0400 (EDT)
Received: from dal-mail2.ricochet.net (dal-mail1.ricochet.net [204.179.143.30])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09492
	for <midcom@ietf.org>; Wed, 1 Aug 2001 19:14:32 -0400 (EDT)
From: shh@ricochet.net
Received: from shiv-mcet (mg-631126-200.sfc1-mg2.ricochet.net [63.112.6.200])
	by dal-mail2.ricochet.net (8.9.3/8.9.3) with SMTP id SAA23565;
	Wed, 1 Aug 2001 18:12:30 -0500 (CDT)
Message-Id: <3.0.1.32.20010801162143.00fb0270@pop.ricochet.net>
X-Sender: shh@pop.ricochet.net
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 01 Aug 2001 16:21:43 -0700
To: Andrew Molitor <amolitor@visi.com>, midcom@ietf.org
Subject: RE: [midcom] defining in-path and out-of-path agents
In-Reply-To: <Pine.GSO.4.21.0108011451040.7283-100000@isis.visi.com>
References: <5.1.0.14.0.20010801153716.00a26030@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 02:54 PM 8/1/2001 -0500, Andrew Molitor wrote:
>
>	This is the land of networking. If it is possible, the probability
>is nearly 1 that someone somewhere will want to do it.
>
>	If you have middlebox technology and agent technology, which
>technologies communicate via MIDCOM, it makes perfect sense to package
>the two together, talking MIDCOM over sockets connected to localhost,
>to implement a lower end solution.
>

I have been eagerly hunting for a word describing this approach. It
is a true midcom (OOP) SIP FCP however colocated in the same physical
device with its pin-hole management mechanism.

Shiv
shh@microappliances.com



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 20:21:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12578
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 20:21:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08820;
	Wed, 1 Aug 2001 19:41:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08792
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 19:41:38 -0400 (EDT)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10482
	for <midcom@ietf.org>; Wed, 1 Aug 2001 19:40:36 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f71NeuX28071
	for <midcom@ietf.org>; Wed, 1 Aug 2001 19:40:56 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f71Neur28065
	for <midcom@ietf.org>; Wed, 1 Aug 2001 19:40:56 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C11AE3.87CDFB2A"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Subject: RE: [midcom] Relationship to work being done in OPES
Date: Wed, 1 Aug 2001 17:41:48 -0600
Message-ID: <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B1@cof110avexu1.global.avaya.com>
Thread-Topic: [midcom] Relationship to work being done in OPES
Thread-Index: AcEaqqWGm5L3sn0ZQBeidIO+gd1BOgAJ8Qmw
From: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>
To: "Melinda Shore" <mshore@cisco.com>
Cc: <midcom@ietf.org>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C11AE3.87CDFB2A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A readout would be nice, particularly since many of those participating
in SIP-related efforts won't be able to attend the OPES BOF now that
it's been rescheduled.

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

            zmolek@avaya.com
              +1 720 444 4001


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, August 01, 2001 10:53 AM
To: lear@cisco.com
Cc: midcom@ietf.org
Subject: Re: [midcom] Relationship to work being done in OPES


At 09:46 AM 8/1/01 -0700, Eliot Lear wrote:
>Could we put this on the end of the agenda at London?  And can the
people leading the OPES effort be invited to participate in that
discussion?

Forgot to mention that it *will* be discussed at the OPES BOF on
Tuesday morning.=20

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11AE3.87CDFB2A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [midcom] Relationship to work being done in OPES</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>A readout would be nice, particularly since many of =
those participating in SIP-related efforts won't be able to attend the =
OPES BOF now that it's been rescheduled.</FONT></P>

<P><FONT SIZE=3D2>--Andy Zmolek</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Technology &amp; Standards =
Engineer</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CTO Standards</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Avaya =
Inc.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; zmolek@avaya.com</FONT>

<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; +1 720 444 4001</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>

<BR><FONT SIZE=3D2>Sent: Wednesday, August 01, 2001 10:53 AM</FONT>

<BR><FONT SIZE=3D2>To: lear@cisco.com</FONT>

<BR><FONT SIZE=3D2>Cc: midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>Subject: Re: [midcom] Relationship to work being done =
in OPES</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 09:46 AM 8/1/01 -0700, Eliot Lear wrote:</FONT>

<BR><FONT SIZE=3D2>&gt;Could we put this on the end of the agenda at =
London?&nbsp; And can the people leading the OPES effort be invited to =
participate in that discussion?</FONT></P>

<P><FONT SIZE=3D2>Forgot to mention that it *will* be discussed at the =
OPES BOF on</FONT>

<BR><FONT SIZE=3D2>Tuesday morning. </FONT>
</P>

<P><FONT SIZE=3D2>Melinda</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>_______________________________________________</FONT>

<BR><FONT SIZE=3D2>midcom mailing list</FONT>

<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom">http://www.ietf.org/=
mailman/listinfo/midcom</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11AE3.87CDFB2A--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  1 21:45:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16444
	for <midcom-archive@odin.ietf.org>; Wed, 1 Aug 2001 21:45:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08866;
	Wed, 1 Aug 2001 19:41:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08827
	for <midcom@ns.ietf.org>; Wed, 1 Aug 2001 19:41:41 -0400 (EDT)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10485
	for <midcom@ietf.org>; Wed, 1 Aug 2001 19:40:39 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f71NexX28107
	for <midcom@ietf.org>; Wed, 1 Aug 2001 19:40:59 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f71Nexr28091
	for <midcom@ietf.org>; Wed, 1 Aug 2001 19:40:59 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C11AE3.8954FCD2"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Subject: RE: [midcom] defining in-path and out-of-path agents
Date: Wed, 1 Aug 2001 17:41:50 -0600
Message-ID: <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B2@cof110avexu1.global.avaya.com>
Thread-Topic: [midcom] defining in-path and out-of-path agents
Thread-Index: AcEamVN1FSdEI3neSTmibyoXEUIRhgAObqbw
From: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>
To: "Mark Duffy" <mduffy@quarrytech.com>, "Andrew Molitor" <amolitor@visi.com>,
        <richard.swale@bt.com>, "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "Bob Penfield" <bpenfield@acmepacket.com>, <midcom@ietf.org>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C11AE3.8954FCD2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

What about the SIP Proxy/ALG case where you have agent in a box that may
be in the signaling path (physically and/or logically) for SIP but needs
to use midcom to inform a middlebox of RTP traffic that not in path
physically (and not logically unless you count the signaling)?  Would
this type of agent be considered out of path and therefore out of scope?

I'm concerned that so much effort is being placed on defining what is
"in-path" verses what is not. 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=20

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?

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

            zmolek@avaya.com
              +1 720 444 4001


-----Original Message-----
From: Mark Duffy [mailto:mduffy@quarrytech.com]
Sent: Wednesday, August 01, 2001 8:49 AM
To: Andrew Molitor; richard.swale@bt.com; Cedric Aoun; Bob Penfield;
midcom@ietf.org
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
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11AE3.8954FCD2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [midcom] defining in-path and out-of-path agents</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>What about the SIP Proxy/ALG case where you have agent =
in a box that may be in the signaling path (physically and/or logically) =
for SIP but needs to use midcom to inform a middlebox of RTP traffic =
that not in path physically (and not logically unless you count the =
signaling)?&nbsp; Would this type of agent be considered out of path and =
therefore out of scope?</FONT></P>

<P><FONT SIZE=3D2>I'm concerned that so much effort is being placed on =
defining what is &quot;in-path&quot; verses what is not. Suppose we =
leave this completely out of the conversation for now and allow =
that:</FONT></P>

<P><FONT SIZE=3D2>1. Diversion may happen outside of midcom (since it's =
clearly not happening inside our charter and it's not technically =
difficult), and </FONT></P>

<P><FONT SIZE=3D2>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 &quot;in-path&quot; or not.</FONT></P>

<P><FONT SIZE=3D2>Would this be sufficient to move the current holy war =
to a new venue and away from midcom?</FONT>
</P>

<P><FONT SIZE=3D2>--Andy Zmolek</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Technology &amp; Standards =
Engineer</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CTO Standards</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Avaya =
Inc.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; zmolek@avaya.com</FONT>

<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; +1 720 444 4001</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]</=
FONT>

<BR><FONT SIZE=3D2>Sent: Wednesday, August 01, 2001 8:49 AM</FONT>

<BR><FONT SIZE=3D2>To: Andrew Molitor; richard.swale@bt.com; Cedric =
Aoun; Bob Penfield;</FONT>

<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>Subject: [midcom] defining in-path and out-of-path =
agents</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think a lot of the confusion here is because we have =
coined two terms</FONT>

<BR><FONT SIZE=3D2>(in-path and out-of-path agents) but in fact there =
are at least three cases:</FONT>
</P>

<P><FONT SIZE=3D2>a.) agents in boxes to whom the packets to be =
inspected/modified by the</FONT>

<BR><FONT SIZE=3D2>agent are specifically addressed at the IP =
layer.&nbsp; Perhaps called</FONT>

<BR><FONT SIZE=3D2>&quot;logically and physically in-path&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>b.) agents in boxes through which the packets in =
question are flowing, but</FONT>

<BR><FONT SIZE=3D2>to which the packets are not specifically =
IP-addressed.&nbsp; Perhaps called</FONT>

<BR><FONT SIZE=3D2>&quot;physically in-path&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>c.) agents in boxes through which the packets in =
question do not flow</FONT>

<BR><FONT SIZE=3D2>(unless diverted for that specific purpose)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think we would probably all agree that a. are =
&quot;in-path&quot; agents and</FONT>

<BR><FONT SIZE=3D2>therefore in-scope.</FONT>

<BR><FONT SIZE=3D2>I think we would probably all agree that c. are =
&quot;out-of-path&quot; agents and</FONT>

<BR><FONT SIZE=3D2>therefore out of scope.</FONT>
</P>

<P><FONT SIZE=3D2>I had understood b. to be in-path and in-scope, =
because I interpret this as</FONT>

<BR><FONT SIZE=3D2>falling within the definition &quot;... within the =
message path of the</FONT>

<BR><FONT SIZE=3D2>application...&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>I do not see why b. should be out of scope.&nbsp; What =
does it matter to midcom</FONT>

<BR><FONT SIZE=3D2>how the agent gets hold of the relevant application =
packets (as long as</FONT>

<BR><FONT SIZE=3D2>midcom does not have to do anything about it such as =
diversion)?&nbsp; I think</FONT>

<BR><FONT SIZE=3D2>the difference between a. and b. would be transparent =
to midcom.</FONT>
</P>

<P><FONT SIZE=3D2>Regardless, we should improve our terminology.&nbsp; I =
suggest some terms above</FONT>

<BR><FONT SIZE=3D2>to differentiate a. and b.</FONT>
</P>

<P><FONT SIZE=3D2>Regards, Mark</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>_______________________________________________</FONT>

<BR><FONT SIZE=3D2>midcom mailing list</FONT>

<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom">http://www.ietf.org/=
mailman/listinfo/midcom</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11AE3.8954FCD2--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 06:07:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19509
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 06:07:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00830;
	Thu, 2 Aug 2001 05:39:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00761
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 05:39:34 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18602
	for <midcom@ietf.org>; Thu, 2 Aug 2001 05:38:30 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f729dWO12151
	for <midcom@ietf.org>; Thu, 2 Aug 2001 05:39:32 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA13173; Thu, 2 Aug 2001 11:39:30 +0200 (MET DST)
Cc: midcom@ietf.org
Received: from hzsgg01.nl.lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA13146; Thu, 2 Aug 2001 11:39:29 +0200 (MET DST)
Received: from lucent.com by hzsgg01.nl.lucent.com (8.8.8+Sun/EMS-1.4.1 client sol2)
	id LAA22163; Thu, 2 Aug 2001 11:39:29 +0200 (MET DST)
Message-ID: <3B691FF9.F3C1448F@lucent.com>
Date: Thu, 02 Aug 2001 11:40:09 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pyda Srisuresh <srisuresh@yahoo.com>
Original-CC: midcom@ietf.org
Subject: Re: [midcom] Framework draft - editorial meeting
References: <20010801221244.22379.qmail@web13806.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Srisuresh,

If you see the issues that have been raised on the list over the past
weeks as editoral nits. That is OK with me and a session on thursday would
be fine. 

My main problem with the framework document as it stands is that is nails
our feet to the floor regarding the requirements document and subsequent
implementation choices. Also there are some internal consitency issues.
When these have been resolved I see no problem in letting the document go
through. 

I believe we can remove those problems from the document with some well
chosen replacements and removals. However there are many of these so we
will need quite some time to address them. 

People have been making suggestions along these lines on the list, can I
assume they will be taken on board so I can focus on identifying others?

Paul

Pyda Srisuresh wrote:
> 
> Folks,
> 
> Let us meet on Thursday (08/09) evening @ 19:30 hrs at the lobby
> to discuss editorial nits to the framework draft. Thanks.
> 
> cheers,
> suresh
> 
> --- Pyda Srisuresh <srisuresh@yahoo.com> wrote:
> > I am there the whole week. Most likely, any time in the evening
> > will work for me. Any thoughts on alternate time? Thanks.
> >
> > cheers,
> > suresh
> > --- Bob Penfield <bpenfield@acmepacket.com> wrote:
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Melinda Shore" <mshore@cisco.com>
> > > To: "Pyda Srisuresh" <srisuresh@yahoo.com>; <midcom@ietf.org>
> > > Sent: Tuesday, July 31, 2001 11:42 AM
> > > Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft)
> > >
> > >
> > > > At 08:33 AM 7/31/01 -0700, Pyda Srisuresh wrote:
> > > > >Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in the
> > > > >main lobby.
> > > >
> > > > Please try to keep some flexibility in your choice of time slot -
> > > > that falls during the social event, which may be an issue for a
> > > > number of people.
> > >
> > > I agree. All work and no play makes Johnny a dull boy.
> > >
> > > Can we find a different time.
> > >
> >
> >
> > =====
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute with Yahoo! Messenger
> > http://phonecard.yahoo.com/
> >
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www.ietf.org/mailman/listinfo/midcom
> 
> =====
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 11:50:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02891
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 11:50:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08255;
	Thu, 2 Aug 2001 11:21:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08227
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 11:21:43 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01616
	for <midcom@ietf.org>; Thu, 2 Aug 2001 11:20:40 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id AF7014AE023A; Thu, 02 Aug 2001 11:19:12 -0400
Message-ID: <008a01c11b66$af2a8ca0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Zmolek, Andrew \(Andrew\)" <zmolek@avaya.com>,
        "Mark Duffy" <mduffy@quarrytech.com>,
        "Andrew Molitor" <amolitor@visi.com>, <richard.swale@bt.com>,
        "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>, <midcom@ietf.org>
References: <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B2@cof110avexu1.global.avaya.com>
Subject: Re: [midcom] defining in-path and out-of-path agents
Date: Thu, 2 Aug 2001 11:20:37 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Zmolek, Andrew (Andrew) <zmolek@avaya.com> wrote:
>
>What about the SIP Proxy/ALG case where you have agent in a box that may
>be in the signaling path (physically and/or logically) for SIP but needs
>to use midcom to inform a middlebox of RTP traffic that not in path
>physically (and not logically unless you count the signaling)?  Would
>this type of agent be considered out of path and therefore out of scope?

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.

>I'm concerned that so much effort is being placed on defining what is
>"in-path" verses what is not. 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.

I don't think that it is possible to remain silent on how the agent fits
into the framework, because then you would have holes in the framework with
respect to OOP agents. Since OOP agents require that the middlebox divert
the control packets to the agent, diversion becomes another service provided
by the middlebox. It would natually follow that the agent would want to use
midcom to tell the middlebox to divert the packets to itself. However, the
only services we're allowed to address are firewall and NAT.

>Would this be sufficient to move the current holy war to a new venue and
>away from midcom?

I think the best we can do now is have an accurate definition of an
"in-scope" agent within the framework we are being restricted to. We have to
leave OOP agent/diversion aside for another holy war later.

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.

(-:bob




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 12:16:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04442
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:16:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07821;
	Thu, 2 Aug 2001 11:05:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07795
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 11:05:42 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00793
	for <midcom@ietf.org>; Thu, 2 Aug 2001 11:04:38 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f72F58g20523;
	Thu, 2 Aug 2001 08:05:08 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp97.cisco.com [10.21.64.97])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATR06474;
	Thu, 2 Aug 2001 04:09:37 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010802070904.00a34a50@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 02 Aug 2001 07:10:58 -0400
To: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>, <midcom@ietf.org>
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] defining in-path and out-of-path agents
In-Reply-To: <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B2@cof110avexu1.global
 .avaya.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 12:25:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05052
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:25:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10529;
	Thu, 2 Aug 2001 12:13:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10488
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 12:13:31 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04238
	for <midcom@ietf.org>; Thu, 2 Aug 2001 12:12:27 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f72GDFY16562
	for <midcom@ietf.org>; Thu, 2 Aug 2001 09:13:15 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-49.cisco.com [10.21.96.49])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIL00015;
	Thu, 2 Aug 2001 09:12:58 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Thu, 2 Aug 2001 12:13:00 -0400
Date: Thu, 2 Aug 2001 12:12:59 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] defining in-path and out-of-path agents
Message-ID: <20010802121259.A1740@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B2@cof110avexu1.global.avaya.com> <008a01c11b66$af2a8ca0$2300000a@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <008a01c11b66$af2a8ca0$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Thu, Aug 02, 2001 at 11:20:37AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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

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

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 12:52:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06487
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:52:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10351;
	Thu, 2 Aug 2001 12:08:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10320
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 12:08:26 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03872
	for <midcom@ietf.org>; Thu, 2 Aug 2001 12:07:22 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f72G8AY12487;
	Thu, 2 Aug 2001 09:08:10 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp97.cisco.com [10.21.64.97])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ATX00207;
	Thu, 2 Aug 2001 08:38:56 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010802113634.00a42950@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 02 Aug 2001 11:40:09 -0400
To: "Bob Penfield" <bpenfield@acmepacket.com>, <midcom@ietf.org>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] defining in-path and out-of-path agents
In-Reply-To: <008a01c11b66$af2a8ca0$2300000a@acmepacket.com>
References: <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B2@cof110avexu1.global.avaya.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:20 AM 8/2/01 -0400, Bob Penfield wrote:
>I don't think that it is possible to remain silent on how the agent fits
>into the framework, because then you would have holes in the framework with
>respect to OOP agents.

Yes and no.  If you think about how the inclusion of out-of-path
agents would affect an actual midcom protocol, you might conclude 
"not at all."  Our difficulty is around packet diversion, which in 
addition to being at odds with the spirit of what we're trying to do 
here would additionally require a mechanism for transporting diverted 
packets.  That last bit is deeply, profoundly, and undeniably out-of-
scope.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 13:52:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09593
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 13:52:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12494;
	Thu, 2 Aug 2001 13:28:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12466
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 13:28:16 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08347
	for <midcom@ietf.org>; Thu, 2 Aug 2001 13:27:13 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f72HRjg21331
	for <midcom@ietf.org>; Thu, 2 Aug 2001 10:27:45 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp97.cisco.com [10.21.64.97])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id AAF00567;
	Thu, 2 Aug 2001 10:17:24 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010802131755.00a3db30@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 02 Aug 2001 13:18:33 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Monday's Bar BOF
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

The location will be posted on the IETF message board.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 16:19:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17371
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 16:19:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12386;
	Thu, 2 Aug 2001 13:23:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12350
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 13:23:32 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08131
	for <midcom@ietf.org>; Thu, 2 Aug 2001 13:22:28 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f72GK1g25350
	for <midcom@ietf.org>; Thu, 2 Aug 2001 17:20:01 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Thu, 2 Aug 2001 17:19:33 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PSC08W3L>; Thu, 2 Aug 2001 17:19:31 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445142@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Richard Swale (E-mail)'" <richard.swale@bt.com>
Cc: "'midcom@ietf.org'" <midcom@ietf.org>
Date: Thu, 2 Aug 2001 17:19:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11B6E.EC2BA3C0"
Subject: [midcom] RE: Comments on requirements draft v2
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11B6E.EC2BA3C0
Content-Type: text/plain;
	charset="iso-8859-1"

Hopefully the email will go through ...

-----Original Message-----
From: Aoun, Cedric [QPD:MA01:EXCH] 
Sent: Thursday, August 02, 2001 5:41 PM
To: Richard Swale (E-mail)
Cc: Midcom IETF (E-mail)
Subject: Comments on requirements draft v2


Richard,
Here are my comments (as well from others sent back on draft v1) on
requirements draftv2:
I hope I didn't overlap with comments already sent, if so sorry for the
spam.

1.1.   Background 
Session *orientated* applications - Typo 
4.1, page 5
"A Middlebox may establish whether the association with a specific
   MIDCOM Agent should be allowed via a Policy Server"
I think this should be reworded as:
A Middle Box may establish an association with a specific MIDCOM agent,
following a
query with the policy server to check the rights and authorization of the
Midcom agent.

4.4.    Distribution of MIDCOM elements
"The Middlebox therefore needs to support multiple simultaneous
   MIDCOM Agents"
We should also state:
Similarly a Midcom agent should support multiple simultaneous Middle Boxes. 


5. page 6
Pinhole opening are not the only things the Midcom protocol should allow the

Midcom agent to request the Middle box to do.
Address and ports binds need to be added, a statement should say that other 
middle box functions will be handled as well but not in the initial version
of the protocol.

5.1, page 6
I think we should also mention the lifetime of the aggregated flows related
descriptor 
(what is called session descriptor in the framework draft).
The descriptor can be by default taken out explicitly. Lifetime could be an
idle timer 
(periodic after each packet traversal) or absolute.
5.1.1
"The MIDCOM Protocol must allow a MIDCOM Agent to specify a Pin-Hole
   in terms of the address and port mappings required."
It seems that you are mixing BINDs with pinholes, this provide a lot
confusion. 
I suggest that we modify the entire section 5 by doing a distinction between

address/port binds and pinholes.

5.3.3 
"A Pin-Hole may be closed such that ICMP reporting for subsequently
   discarded packets is either enabled or disabled."
Should we understand that when the pinhole is closed the Middle Box will
send an ICMP 
error message (type 3) with code 10 or 13.
I think it is best to reword it as:

When the pinhole is closed, ICMP may either be enabled or disable to send
error messages 
to the originator when packets are not allowed path through (doesn't this
look easier to digest).

5.3.6
Error handling includes also :
-Messages that did not arrive in the required protocol sequence
-Cases where an agent request things that are not allowed (try to get
control on other session descriptor)
-Misunderstood messages or unknown messages
- ...

6.6.1
"The MIDCOM Agent may report its status to a Middlebox with which it
   is associated.

   A Middlebox may report its status to a MIDCOM Agent with which it is
   associated."

How is do we define status?
Is it the load of the device, if it is still working properly etc...
Or does it include a self audit report on booked resources by the peer?
I think we need to be a little bit more specific.


6.6.3.  Protocol Failure

 "  To enable management systems to interact with the MIDCOM
   environment, the protocol needs to include failure reasons that
   allow the MIDCOM Agent behavior to be modified as a result of the
   information contained in the reason. Failure reasons need to be
   chosen such that they do not make an attack on security easier."

I would see this paragraph merging with the error handling section. no?

"MIDCOM session disconnection may be prompted by a successful de-
   registration request or a failure of some sort, such asa
   communications failure between the Middlebox and MIDCOM Agent.

   At the end of a MIDCOM session between a Middlebox and MIDCOM Agent,
   it should be possible for either the Middlebox or the MIDCOM Agent
   to initiate the disconnection of the relationship."

This is assuming that the MIDCOM protocol is a connection oriented protocol,
in which 
the peers have established a connection, and then the peers started to send
allocation 
of application session related things( pinhole opening, BINDs request,
bandwidth 
allocation requests ..). This is not currently the case since we have not
decided that 
MIDCOM is a connection oriented protocol.

What you mention might be achieved by using a root type of descriptor that
includes all
 the descriptors currently defined between the Middle Box and the Midcom
agent. 
When the MIDCOM agent has no longer authorization, the Middle box sends a
message
 saying that it is taking out the root descriptor and says the reason for
the decision.

Thanks

Cedric



------_=_NextPart_001_01C11B6E.EC2BA3C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Comments on requirements draft v2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hopefully the email will go through ...</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Aoun, Cedric [QPD:MA01:EXCH] </FONT>
<BR><FONT SIZE=2>Sent: Thursday, August 02, 2001 5:41 PM</FONT>
<BR><FONT SIZE=2>To: Richard Swale (E-mail)</FONT>
<BR><FONT SIZE=2>Cc: Midcom IETF (E-mail)</FONT>
<BR><FONT SIZE=2>Subject: Comments on requirements draft v2</FONT>
</P>
<BR>

<P><FONT SIZE=2>Richard,</FONT>
<BR><FONT SIZE=2>Here are my comments (as well from others sent back on draft v1) on requirements draftv2:</FONT>
<BR><FONT SIZE=2>I hope I didn't overlap with comments already sent, if so sorry for the spam.</FONT>
</P>

<P><FONT SIZE=2>1.1.&nbsp;&nbsp; Background </FONT>
<BR><FONT SIZE=2>Session *orientated* applications - Typo </FONT>
<BR><FONT SIZE=2>4.1, page 5</FONT>
<BR><FONT SIZE=2>&quot;A Middlebox may establish whether the association with a specific</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; MIDCOM Agent should be allowed via a Policy Server&quot;</FONT>
<BR><FONT SIZE=2>I think this should be reworded as:</FONT>
<BR><FONT SIZE=2>A Middle Box may establish an association with a specific MIDCOM agent, following a</FONT>
<BR><FONT SIZE=2>query with the policy server to check the rights and authorization of the Midcom agent.</FONT>
</P>

<P><FONT SIZE=2>4.4.&nbsp;&nbsp;&nbsp; Distribution of MIDCOM elements</FONT>
<BR><FONT SIZE=2>&quot;The Middlebox therefore needs to support multiple simultaneous</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; MIDCOM Agents&quot;</FONT>
<BR><FONT SIZE=2>We should also state:</FONT>
<BR><FONT SIZE=2>Similarly a Midcom agent should support multiple simultaneous Middle Boxes. </FONT>
</P>
<BR>

<P><FONT SIZE=2>5. page 6</FONT>
<BR><FONT SIZE=2>Pinhole opening are not the only things the Midcom protocol should allow the </FONT>
<BR><FONT SIZE=2>Midcom agent to request the Middle box to do.</FONT>
<BR><FONT SIZE=2>Address and ports binds need to be added, a statement should say that other </FONT>
<BR><FONT SIZE=2>middle box functions will be handled as well but not in the initial version of the protocol.</FONT>
</P>

<P><FONT SIZE=2>5.1, page 6</FONT>
<BR><FONT SIZE=2>I think we should also mention the lifetime of the aggregated flows related descriptor </FONT>
<BR><FONT SIZE=2>(what is called session descriptor in the framework draft).</FONT>
<BR><FONT SIZE=2>The descriptor can be by default taken out explicitly. Lifetime could be an idle timer </FONT>
<BR><FONT SIZE=2>(periodic after each packet traversal) or absolute.</FONT>
<BR><FONT SIZE=2>5.1.1</FONT>
<BR><FONT SIZE=2>&quot;The MIDCOM Protocol must allow a MIDCOM Agent to specify a Pin-Hole</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; in terms of the address and port mappings required.&quot;</FONT>
<BR><FONT SIZE=2>It seems that you are mixing BINDs with pinholes, this provide a lot confusion. </FONT>
<BR><FONT SIZE=2>I suggest that we modify the entire section 5 by doing a distinction between </FONT>
<BR><FONT SIZE=2>address/port binds and pinholes.</FONT>
</P>

<P><FONT SIZE=2>5.3.3 </FONT>
<BR><FONT SIZE=2>&quot;A Pin-Hole may be closed such that ICMP reporting for subsequently</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; discarded packets is either enabled or disabled.&quot;</FONT>
<BR><FONT SIZE=2>Should we understand that when the pinhole is closed the Middle Box will send an ICMP </FONT>
<BR><FONT SIZE=2>error message (type 3) with code 10 or 13.</FONT>
<BR><FONT SIZE=2>I think it is best to reword it as:</FONT>
</P>

<P><FONT SIZE=2>When the pinhole is closed, ICMP may either be enabled or disable to send error messages </FONT>
<BR><FONT SIZE=2>to the originator when packets are not allowed path through (doesn't this look easier to digest).</FONT>
</P>

<P><FONT SIZE=2>5.3.6</FONT>
<BR><FONT SIZE=2>Error handling includes also :</FONT>
<BR><FONT SIZE=2>-Messages that did not arrive in the required protocol sequence</FONT>
<BR><FONT SIZE=2>-Cases where an agent request things that are not allowed (try to get control on other session descriptor)</FONT>
<BR><FONT SIZE=2>-Misunderstood messages or unknown messages</FONT>
<BR><FONT SIZE=2>- ...</FONT>
</P>

<P><FONT SIZE=2>6.6.1</FONT>
<BR><FONT SIZE=2>&quot;The MIDCOM Agent may report its status to a Middlebox with which it</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; is associated.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; A Middlebox may report its status to a MIDCOM Agent with which it is</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; associated.&quot;</FONT>
</P>

<P><FONT SIZE=2>How is do we define status?</FONT>
<BR><FONT SIZE=2>Is it the load of the device, if it is still working properly etc...</FONT>
<BR><FONT SIZE=2>Or does it include a self audit report on booked resources by the peer?</FONT>
<BR><FONT SIZE=2>I think we need to be a little bit more specific.</FONT>
</P>
<BR>

<P><FONT SIZE=2>6.6.3.&nbsp; Protocol Failure</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&quot;&nbsp; To enable management systems to interact with the MIDCOM</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; environment, the protocol needs to include failure reasons that</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; allow the MIDCOM Agent behavior to be modified as a result of the</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; information contained in the reason. Failure reasons need to be</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; chosen such that they do not make an attack on security easier.&quot;</FONT>
</P>

<P><FONT SIZE=2>I would see this paragraph merging with the error handling section. no?</FONT>
</P>

<P><FONT SIZE=2>&quot;MIDCOM session disconnection may be prompted by a successful de-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; registration request or a failure of some sort, such asa</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; communications failure between the Middlebox and MIDCOM Agent.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; At the end of a MIDCOM session between a Middlebox and MIDCOM Agent,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; it should be possible for either the Middlebox or the MIDCOM Agent</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; to initiate the disconnection of the relationship.&quot;</FONT>
</P>

<P><FONT SIZE=2>This is assuming that the MIDCOM protocol is a connection oriented protocol, in which </FONT>
<BR><FONT SIZE=2>the peers have established a connection, and then the peers started to send allocation </FONT>
<BR><FONT SIZE=2>of application session related things( pinhole opening, BINDs request, bandwidth </FONT>
<BR><FONT SIZE=2>allocation requests ..). This is not currently the case since we have not decided that </FONT>
<BR><FONT SIZE=2>MIDCOM is a connection oriented protocol.</FONT>
</P>

<P><FONT SIZE=2>What you mention might be achieved by using a root type of descriptor that includes all</FONT>
<BR><FONT SIZE=2>&nbsp;the descriptors currently defined between the Middle Box and the Midcom agent. </FONT>
<BR><FONT SIZE=2>When the MIDCOM agent has no longer authorization, the Middle box sends a message</FONT>
<BR><FONT SIZE=2>&nbsp;saying that it is taking out the root descriptor and says the reason for the decision.</FONT>
</P>

<P><FONT SIZE=2>Thanks</FONT>
</P>

<P><FONT SIZE=2>Cedric</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C11B6E.EC2BA3C0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 16:50:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18719
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 16:50:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12080;
	Thu, 2 Aug 2001 13:05:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12048
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 13:05:55 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07179
	for <midcom@ietf.org>; Thu, 2 Aug 2001 13:04:52 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f72FfWg15580
	for <midcom@ietf.org>; Thu, 2 Aug 2001 16:41:32 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Thu, 2 Aug 2001 16:40:59 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PSC08VQ6>; Thu, 2 Aug 2001 16:40:56 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C3044513F@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "Richard Swale (E-mail)" <richard.swale@bt.com>
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
Date: Thu, 2 Aug 2001 16:40:58 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11B69.868B32B0"
Subject: [midcom] Comments on requirements draft v2
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11B69.868B32B0
Content-Type: text/plain;
	charset="iso-8859-1"

Richard,
Here are my comments (as well from others sent back on draft v1) on
requirements draftv2:
I hope I didn't overlap with comments already sent, if so sorry for the
spam.

1.1.   Background 
Session *orientated* applications - Typo 
4.1, page 5
"A Middlebox may establish whether the association with a specific
   MIDCOM Agent should be allowed via a Policy Server"
I think this should be reworded as:
A Middle Box may establish an association with a specific MIDCOM agent,
following a
query with the policy server to check the rights and authorization of the
Midcom agent.

4.4.    Distribution of MIDCOM elements
"The Middlebox therefore needs to support multiple simultaneous
   MIDCOM Agents"
We should also state:
Similarly a Midcom agent should support multiple simultaneous Middle Boxes. 


5. page 6
Pinhole opening are not the only things the Midcom protocol should allow the

Midcom agent to request the Middle box to do.
Address and ports binds need to be added, a statement should say that other 
middle box functions will be handled as well but not in the initial version
of the protocol.

5.1, page 6
I think we should also mention the lifetime of the aggregated flows related
descriptor 
(what is called session descriptor in the framework draft).
The descriptor can be by default taken out explicitly. Lifetime could be an
idle timer 
(periodic after each packet traversal) or absolute.
5.1.1
"The MIDCOM Protocol must allow a MIDCOM Agent to specify a Pin-Hole
   in terms of the address and port mappings required."
It seems that you are mixing BINDs with pinholes, this provide a lot
confusion. 
I suggest that we modify the entire section 5 by doing a distinction between

address/port binds and pinholes.

5.3.3 
"A Pin-Hole may be closed such that ICMP reporting for subsequently
   discarded packets is either enabled or disabled."
Should we understand that when the pinhole is closed the Middle Box will
send an ICMP 
error message (type 3) with code 10 or 13.
I think it is best to reword it as:

When the pinhole is closed, ICMP may either be enabled or disable to send
error messages 
to the originator when packets are not allowed path through (doesn't this
look easier to digest).

5.3.6
Error handling includes also :
-Messages that did not arrive in the required protocol sequence
-Cases where an agent request things that are not allowed (try to get
control on other session descriptor)
-Misunderstood messages or unknown messages
- ...

6.6.1
"The MIDCOM Agent may report its status to a Middlebox with which it
   is associated.

   A Middlebox may report its status to a MIDCOM Agent with which it is
   associated."

How is do we define status?
Is it the load of the device, if it is still working properly etc...
Or does it include a self audit report on booked resources by the peer?
I think we need to be a little bit more specific.


6.6.3.  Protocol Failure

 "  To enable management systems to interact with the MIDCOM
   environment, the protocol needs to include failure reasons that
   allow the MIDCOM Agent behavior to be modified as a result of the
   information contained in the reason. Failure reasons need to be
   chosen such that they do not make an attack on security easier."

I would see this paragraph merging with the error handling section. no?

"MIDCOM session disconnection may be prompted by a successful de-
   registration request or a failure of some sort, such asa
   communications failure between the Middlebox and MIDCOM Agent.

   At the end of a MIDCOM session between a Middlebox and MIDCOM Agent,
   it should be possible for either the Middlebox or the MIDCOM Agent
   to initiate the disconnection of the relationship."

This is assuming that the MIDCOM protocol is a connection oriented protocol,
in which 
the peers have established a connection, and then the peers started to send
allocation 
of application session related things( pinhole opening, BINDs request,
bandwidth 
allocation requests ..). This is not currently the case since we have not
decided that 
MIDCOM is a connection oriented protocol.

What you mention might be achieved by using a root type of descriptor that
includes all
 the descriptors currently defined between the Middle Box and the Midcom
agent. 
When the MIDCOM agent has no longer authorization, the Middle box sends a
message
 saying that it is taking out the root descriptor and says the reason for
the decision.

Thanks

Cedric



------_=_NextPart_001_01C11B69.868B32B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>Comments on requirements draft v2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Richard,</FONT>
<BR><FONT SIZE=2>Here are my comments (as well from others sent back on draft v1) on requirements draftv2:</FONT>
<BR><FONT SIZE=2>I hope I didn't overlap with comments already sent, if so sorry for the spam.</FONT>
</P>

<P><FONT SIZE=2>1.1.&nbsp;&nbsp; Background </FONT>
<BR><FONT SIZE=2>Session *orientated* applications - Typo </FONT>
<BR><FONT SIZE=2>4.1, page 5</FONT>
<BR><FONT SIZE=2>&quot;A Middlebox may establish whether the association with a specific</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; MIDCOM Agent should be allowed via a Policy Server&quot;</FONT>
<BR><FONT SIZE=2>I think this should be reworded as:</FONT>
<BR><FONT SIZE=2>A Middle Box may establish an association with a specific MIDCOM agent, following a</FONT>
<BR><FONT SIZE=2>query with the policy server to check the rights and authorization of the Midcom agent.</FONT>
</P>

<P><FONT SIZE=2>4.4.&nbsp;&nbsp;&nbsp; Distribution of MIDCOM elements</FONT>
<BR><FONT SIZE=2>&quot;The Middlebox therefore needs to support multiple simultaneous</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; MIDCOM Agents&quot;</FONT>
<BR><FONT SIZE=2>We should also state:</FONT>
<BR><FONT SIZE=2>Similarly a Midcom agent should support multiple simultaneous Middle Boxes. </FONT>
</P>
<BR>

<P><FONT SIZE=2>5. page 6</FONT>
<BR><FONT SIZE=2>Pinhole opening are not the only things the Midcom protocol should allow the </FONT>
<BR><FONT SIZE=2>Midcom agent to request the Middle box to do.</FONT>
<BR><FONT SIZE=2>Address and ports binds need to be added, a statement should say that other </FONT>
<BR><FONT SIZE=2>middle box functions will be handled as well but not in the initial version of the protocol.</FONT>
</P>

<P><FONT SIZE=2>5.1, page 6</FONT>
<BR><FONT SIZE=2>I think we should also mention the lifetime of the aggregated flows related descriptor </FONT>
<BR><FONT SIZE=2>(what is called session descriptor in the framework draft).</FONT>
<BR><FONT SIZE=2>The descriptor can be by default taken out explicitly. Lifetime could be an idle timer </FONT>
<BR><FONT SIZE=2>(periodic after each packet traversal) or absolute.</FONT>
<BR><FONT SIZE=2>5.1.1</FONT>
<BR><FONT SIZE=2>&quot;The MIDCOM Protocol must allow a MIDCOM Agent to specify a Pin-Hole</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; in terms of the address and port mappings required.&quot;</FONT>
<BR><FONT SIZE=2>It seems that you are mixing BINDs with pinholes, this provide a lot confusion. </FONT>
<BR><FONT SIZE=2>I suggest that we modify the entire section 5 by doing a distinction between </FONT>
<BR><FONT SIZE=2>address/port binds and pinholes.</FONT>
</P>

<P><FONT SIZE=2>5.3.3 </FONT>
<BR><FONT SIZE=2>&quot;A Pin-Hole may be closed such that ICMP reporting for subsequently</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; discarded packets is either enabled or disabled.&quot;</FONT>
<BR><FONT SIZE=2>Should we understand that when the pinhole is closed the Middle Box will send an ICMP </FONT>
<BR><FONT SIZE=2>error message (type 3) with code 10 or 13.</FONT>
<BR><FONT SIZE=2>I think it is best to reword it as:</FONT>
</P>

<P><FONT SIZE=2>When the pinhole is closed, ICMP may either be enabled or disable to send error messages </FONT>
<BR><FONT SIZE=2>to the originator when packets are not allowed path through (doesn't this look easier to digest).</FONT>
</P>

<P><FONT SIZE=2>5.3.6</FONT>
<BR><FONT SIZE=2>Error handling includes also :</FONT>
<BR><FONT SIZE=2>-Messages that did not arrive in the required protocol sequence</FONT>
<BR><FONT SIZE=2>-Cases where an agent request things that are not allowed (try to get control on other session descriptor)</FONT>
<BR><FONT SIZE=2>-Misunderstood messages or unknown messages</FONT>
<BR><FONT SIZE=2>- ...</FONT>
</P>

<P><FONT SIZE=2>6.6.1</FONT>
<BR><FONT SIZE=2>&quot;The MIDCOM Agent may report its status to a Middlebox with which it</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; is associated.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; A Middlebox may report its status to a MIDCOM Agent with which it is</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; associated.&quot;</FONT>
</P>

<P><FONT SIZE=2>How is do we define status?</FONT>
<BR><FONT SIZE=2>Is it the load of the device, if it is still working properly etc...</FONT>
<BR><FONT SIZE=2>Or does it include a self audit report on booked resources by the peer?</FONT>
<BR><FONT SIZE=2>I think we need to be a little bit more specific.</FONT>
</P>
<BR>

<P><FONT SIZE=2>6.6.3.&nbsp; Protocol Failure</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&quot;&nbsp; To enable management systems to interact with the MIDCOM</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; environment, the protocol needs to include failure reasons that</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; allow the MIDCOM Agent behavior to be modified as a result of the</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; information contained in the reason. Failure reasons need to be</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; chosen such that they do not make an attack on security easier.&quot;</FONT>
</P>

<P><FONT SIZE=2>I would see this paragraph merging with the error handling section. no?</FONT>
</P>

<P><FONT SIZE=2>&quot;MIDCOM session disconnection may be prompted by a successful de-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; registration request or a failure of some sort, such asa</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; communications failure between the Middlebox and MIDCOM Agent.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; At the end of a MIDCOM session between a Middlebox and MIDCOM Agent,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; it should be possible for either the Middlebox or the MIDCOM Agent</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; to initiate the disconnection of the relationship.&quot;</FONT>
</P>

<P><FONT SIZE=2>This is assuming that the MIDCOM protocol is a connection oriented protocol, in which </FONT>
<BR><FONT SIZE=2>the peers have established a connection, and then the peers started to send allocation </FONT>
<BR><FONT SIZE=2>of application session related things( pinhole opening, BINDs request, bandwidth </FONT>
<BR><FONT SIZE=2>allocation requests ..). This is not currently the case since we have not decided that </FONT>
<BR><FONT SIZE=2>MIDCOM is a connection oriented protocol.</FONT>
</P>

<P><FONT SIZE=2>What you mention might be achieved by using a root type of descriptor that includes all</FONT>
<BR><FONT SIZE=2>&nbsp;the descriptors currently defined between the Middle Box and the Midcom agent. </FONT>
<BR><FONT SIZE=2>When the MIDCOM agent has no longer authorization, the Middle box sends a message</FONT>
<BR><FONT SIZE=2>&nbsp;saying that it is taking out the root descriptor and says the reason for the decision.</FONT>
</P>

<P><FONT SIZE=2>Thanks</FONT>
</P>

<P><FONT SIZE=2>Cedric</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C11B69.868B32B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 17:23:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20577
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 17:22:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17282;
	Thu, 2 Aug 2001 16:58:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17251
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 16:58:22 -0400 (EDT)
Received: from web14302.mail.yahoo.com (web14302.mail.yahoo.com [216.136.173.78])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19032
	for <midcom@ietf.org>; Thu, 2 Aug 2001 16:57:16 -0400 (EDT)
Message-ID: <20010802205419.40811.qmail@web14302.mail.yahoo.com>
Received: from [207.164.4.53] by web14302.mail.yahoo.com; Thu, 02 Aug 2001 16:54:19 EDT
Date: Thu, 2 Aug 2001 16:54:19 -0400 (EDT)
From: Abdallah Rayhan <ar_rayhan@yahoo.ca>
To: midcom@ietf.org
In-Reply-To: <3B691FF9.F3C1448F@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [midcom] Editorial changes and mailing list discussion
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Folks,

There has been too much traffic going around regarding some 
issues presented in the framework and the requirements
drafts and seen as contentious. Some of these issues are 
very well valid and contribute to completing the task we
(WG) have taken to accomplish. However, if someone is to read 
the archives, he/she will probably have difficulty trying 
to figure out what consensus has been achieved.

Here is what I propose. If someone has suggestions to make 
regarding the text, propose it with: OLD, PROPOSED, REASONING. 
Once a decision or a resolution is achieved, we need "FINAL" 
in the subject to indicate that the thread is closed. 
How calls for FINAL is another matter.

Similarly, if there are comments regarding general concepts,
use a clear subject and final one to know where things are.
How productive would be if someone needs to read all archives
to find out later that the issue has not been closed.

regards
Abdallah

--- Paul Sijben <sijben@lucent.com> wrote:
> Srisuresh,
> 
> If you see the issues that have been raised on the list over the past
> weeks as editoral nits. That is OK with me and a session on thursday
> would
> be fine. 
> 
> My main problem with the framework document as it stands is that is
> nails
> our feet to the floor regarding the requirements document and
> subsequent
> implementation choices. Also there are some internal consitency
> issues.
> When these have been resolved I see no problem in letting the
> document go
> through. 
> 
> I believe we can remove those problems from the document with some
> well
> chosen replacements and removals. However there are many of these so
> we
> will need quite some time to address them. 
> 
> People have been making suggestions along these lines on the list,
> can I
> assume they will be taken on board so I can focus on identifying
> others?
> 
> Paul

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 18:49:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28473
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 18:49:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19866;
	Thu, 2 Aug 2001 18:41:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19798
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 18:41:28 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27816
	for <midcom@ietf.org>; Thu, 2 Aug 2001 18:40:23 -0400 (EDT)
Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D9N01; Thu, 2 Aug 2001 18:40:36 -0400
Message-Id: <3.0.5.32.20010802183520.0091c100@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Aug 2001 18:35:20 -0400
To: midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] defining in-path and out-of-path agents
In-Reply-To: <20010802121259.A1740@SBRIM-W2K>
References: <008a01c11b66$af2a8ca0$2300000a@acmepacket.com>
 <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B2@cof110avexu1.global.avaya.com>
 <008a01c11b66$af2a8ca0$2300000a@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 19:06:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29511
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 19:06:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20543;
	Thu, 2 Aug 2001 19:02:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20514
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 19:02:37 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29265
	for <midcom@ietf.org>; Thu, 2 Aug 2001 19:01:34 -0400 (EDT)
Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D9N0S; Thu, 2 Aug 2001 19:02:05 -0400
Message-Id: <3.0.5.32.20010802190118.00917710@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Aug 2001 19:01:18 -0400
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "Richard Swale (E-mail)" <richard.swale@bt.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] Comments on requirements draft v2
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
In-Reply-To: <9154CB41F208D5118DD200508BE39C3044513F@zjguc006.europe.nor
 tel.com>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 04:40 PM 8/2/01 +0100, Cedric Aoun wrote: 

>>>>

<excerpt>4.4.    Distribution of MIDCOM elements 

"The Middlebox therefore needs to support multiple simultaneous 

   MIDCOM Agents" 

We should also state: 

Similarly a Midcom agent should support multiple simultaneous Middle
Boxes.  


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

MD:

I believe it is out of place to state these kind of requirements here on
agent and middlebox -- those are for the market to impose (or not). 
Rather, this protocol requirement should state that the midcom protocol
must provide the support necessary for multiple agents per middlebox and
multiple middleboxes per agent.


>>>>

<excerpt>


5. page 6 

Pinhole opening are not the only things the Midcom protocol should allow
the  

Midcom agent to request the Middle box to do. 

Address and ports binds need to be added, a statement should say that
other  

middle box functions will be handled as well but not in the initial
version of the protocol. 


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

MD:

It was my understanding that address/port (i.e. NAT/NAPT) binds would be
allocated and assigned by the middlebox, and that the agent could use the
midcom protocol to *learn* these bindings.  Certainly, that makes support
of multiple agents per NAT middlebox much simpler.   The timeline
diagrams in the framework doc do show it working this way, at least as I
interpret them.


I did raise a question recently about whether the agent needs to be able
to influence the address/port bindings in such a way as to ensure e.g.
that related flows were assigned bindings with the same IP address.  I do
not understand the relevant applications well enough to know if this is a
requirement.


>>>>

<excerpt>

</excerpt>

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 19:07:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29574
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 19:07:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20626;
	Thu, 2 Aug 2001 19:06:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20600
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 19:06:11 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29427
	for <midcom@ietf.org>; Thu, 2 Aug 2001 19:05:08 -0400 (EDT)
Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D9N0X; Thu, 2 Aug 2001 19:05:39 -0400
Message-Id: <3.0.5.32.20010802190457.007cee30@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Aug 2001 19:04:57 -0400
To: midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] defining in-path and out-of-path agents
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 19:23:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00640
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 19:23:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20840;
	Thu, 2 Aug 2001 19:15:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20809
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 19:15:46 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00133
	for <midcom@ietf.org>; Thu, 2 Aug 2001 19:14:43 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f72NFTY22346;
	Thu, 2 Aug 2001 16:15:30 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp97.cisco.com [10.21.64.97])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id AAJ08413;
	Thu, 2 Aug 2001 16:15:12 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010802191220.00a0f310@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 02 Aug 2001 19:16:04 -0400
To: Mark Duffy <mduffy@quarrytech.com>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Comments on requirements draft v2
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
In-Reply-To: <3.0.5.32.20010802190118.00917710@email.quarrytech.com>
References: <9154CB41F208D5118DD200508BE39C3044513F@zjguc006.europe.nor tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 07:01 PM 8/2/01 -0400, Mark Duffy wrote:
>I did raise a question recently about whether the agent needs to be able to influence the address/port bindings in such a way as to ensure e.g. that related flows were assigned bindings with the same IP address.  I do not understand the relevant applications well enough to know if this is a requirement. 

This should be fairly simple to put in the protocol.  A NAT mapping
request can potentially include a requested NATted-to address and/or
port, along with a flag that could say "if it's not available don't
install the mapping" or "if it's not available give me something else
and tell me what it is."

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  2 22:24:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11947
	for <midcom-archive@odin.ietf.org>; Thu, 2 Aug 2001 22:23:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25735;
	Thu, 2 Aug 2001 22:22:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25684
	for <midcom@ns.ietf.org>; Thu, 2 Aug 2001 22:22:54 -0400 (EDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11743
	for <midcom@ietf.org>; Thu, 2 Aug 2001 22:21:48 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYZ300.TDM for <midcom@ietf.org>; Thu, 2 Aug 2001
          22:01:51 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5NZQ00.59M; Fri, 27 Jul 2001 19:31:02 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA08684;
	Wed, 25 Jul 2001 13:38:56 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA01274
	for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 13:05:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25669
	for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:35:40 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07922;
	Wed, 25 Jul 2001 06:35:39 -0400 (EDT)
Message-Id: <200107251035.GAA07922@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: midcom@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jul 2001 06:35:39 -0400
Subject: [midcom] I-D ACTION:draft-ietf-midcom-requirements-02.txt,.ps
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Middlebox Communication Working Group of the IETF.

	Title		: Middlebox Control (MIDCOM) Protocol Architecture and 
                          Requirements
	Author(s)	: R. Swale, P. Mart, P. Sijben
	Filename	: draft-ietf-midcom-requirements-02.txt,.ps
	Pages		: 15
	Date		: 24-Jul-01
	
Networks connecting to and forming part of the Internet are 
increasingly deploying specialised network functions to address 
security, quality of service and other administrative policy 
requirements. These devices are a subset of what can be referred to 
as 'Middleboxes'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-midcom-requirements-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-midcom-requirements-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010724132635.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-midcom-requirements-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-midcom-requirements-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010724132635.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 01:26:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21486
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 01:26:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10010;
	Fri, 3 Aug 2001 01:26:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09977
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 01:26:02 -0400 (EDT)
Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21279
	for <midcom@ietf.org>; Fri, 3 Aug 2001 01:25:00 -0400 (EDT)
Message-ID: <20010803052556.4801.qmail@web13807.mail.yahoo.com>
Received: from [65.12.33.187] by web13807.mail.yahoo.com; Thu, 02 Aug 2001 22:25:56 PDT
Date: Thu, 2 Aug 2001 22:25:56 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] Framework draft - editorial meeting
To: midcom@ietf.org
In-Reply-To: <20010801221244.22379.qmail@web13806.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Folks,

Due to unforeseen circumstances, I have had to cancel my
travel plans to the London IETF. My apologies for the last
minute cancellation. As for the editorial meeting itself - 
it will be great, if those of you with specific comments 
gather together  and pass on the consensus :-)
Clearly, that is your choice. Thanks.

regards,
suresh

--- Pyda Srisuresh <srisuresh@yahoo.com> wrote:
> 
> Folks,
> 
> Let us meet on Thursday (08/09) evening @ 19:30 hrs at the lobby 
> to discuss editorial nits to the framework draft. Thanks.
> 
> cheers,
> suresh
> 
> --- Pyda Srisuresh <srisuresh@yahoo.com> wrote:
> > I am there the whole week. Most likely, any time in the evening
> > will work for me. Any thoughts on alternate time? Thanks.
> > 
> > cheers,
> > suresh 
> > --- Bob Penfield <bpenfield@acmepacket.com> wrote:
> > > 
> > > 
> > > 
> > > ----- Original Message ----- 
> > > From: "Melinda Shore" <mshore@cisco.com>
> > > To: "Pyda Srisuresh" <srisuresh@yahoo.com>; <midcom@ietf.org>
> > > Sent: Tuesday, July 31, 2001 11:42 AM
> > > Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft)
> > > 
> > > 
> > > > At 08:33 AM 7/31/01 -0700, Pyda Srisuresh wrote:
> > > > >Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in
> the
> > > > >main lobby. 
> > > > 
> > > > Please try to keep some flexibility in your choice of time slot -
> > > > that falls during the social event, which may be an issue for a
> > > > number of people.
> > > 
> > > I agree. All work and no play makes Johnny a dull boy.
> > > 
> > > Can we find a different time.
> > > 
> > 
> > 
> > =====
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute with Yahoo! Messenger
> > http://phonecard.yahoo.com/
> > 
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www.ietf.org/mailman/listinfo/midcom
> 
> 
> =====
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom


=====


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 05:05:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10106
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 05:05:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15727;
	Fri, 3 Aug 2001 04:54:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15414
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 04:54:25 -0400 (EDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09259
	for <midcom@ietf.org>; Fri, 3 Aug 2001 04:53:22 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF7400.AQM for <midcom@ietf.org>; Fri, 3 Aug 2001
          03:52:16 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5NZQ00.59M; Fri, 27 Jul 2001 19:31:02 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA08684;
	Wed, 25 Jul 2001 13:38:56 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA01274
	for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 13:05:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25669
	for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:35:40 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07922;
	Wed, 25 Jul 2001 06:35:39 -0400 (EDT)
Message-Id: <200107251035.GAA07922@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: midcom@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jul 2001 06:35:39 -0400
Subject: [midcom] I-D ACTION:draft-ietf-midcom-requirements-02.txt,.ps
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Middlebox Communication Working Group of the IETF.

	Title		: Middlebox Control (MIDCOM) Protocol Architecture and 
                          Requirements
	Author(s)	: R. Swale, P. Mart, P. Sijben
	Filename	: draft-ietf-midcom-requirements-02.txt,.ps
	Pages		: 15
	Date		: 24-Jul-01
	
Networks connecting to and forming part of the Internet are 
increasingly deploying specialised network functions to address 
security, quality of service and other administrative policy 
requirements. These devices are a subset of what can be referred to 
as 'Middleboxes'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-midcom-requirements-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-midcom-requirements-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010724132635.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-midcom-requirements-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-midcom-requirements-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010724132635.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 09:15:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15300
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 09:15:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23468;
	Fri, 3 Aug 2001 09:12:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23435
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 09:12:34 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15232
	for <midcom@ietf.org>; Fri, 3 Aug 2001 09:11:31 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A2A8CA65014E; Fri, 03 Aug 2001 09:10:00 -0400
Message-ID: <030a01c11c1d$dc6f5e40$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "Richard Swale \(E-mail\)" <richard.swale@bt.com>,
        "Mark Duffy" <mduffy@quarrytech.com>
Cc: "Midcom IETF \(E-mail\)" <midcom@ietf.org>
References: <3.0.5.32.20010802190118.00917710@email.quarrytech.com>
Subject: Re: [midcom] Comments on requirements draft v2
Date: Fri, 3 Aug 2001 09:11:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Mark Duffy" <mduffy@quarrytech.com>
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>; "Richard Swale (E-mail)"
<richard.swale@bt.com>
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
Sent: Thursday, August 02, 2001 7:01 PM
Subject: Re: [midcom] Comments on requirements draft v2


> At 04:40 PM 8/2/01 +0100, Cedric Aoun wrote:
> >>>>
>
>   4.4. Distribution of MIDCOM elements
>   "The Middlebox therefore needs to support multiple simultaneous
>   MIDCOM Agents"
>   We should also state:
>   Similarly a Midcom agent should support multiple simultaneous Middle
Boxes.
>
>
> <<<<
> MD:
> I believe it is out of place to state these kind of requirements here on
agent and middlebox -- those are for the market to impose (or not). Rather,
this protocol requirement should state that the midcom protocol must provide
the support necessary for multiple agents per middlebox and multiple
middleboxes per agent.

<BP>
I like Mark's language here. The original text reads like it is imposing
requirements on the middlebox itself which we should not do.
</BP>

>
> >>>>
>
>
>
>   5. page 6
>   Pinhole opening are not the only things the Midcom protocol should allow
the
>   Midcom agent to request the Middle box to do.
>   Address and ports binds need to be added, a statement should say that
other
>   middle box functions will be handled as well but not in the initial
version of the protocol.
>
>
> <<<<
> MD:
> It was my understanding that address/port (i.e. NAT/NAPT) binds would be
allocated and assigned by the middlebox, and that the agent could use the
midcom protocol to *learn* these bindings. Certainly, that makes support of
multiple agents per NAT middlebox much simpler. The timeline diagrams in the
framework doc do show it working this way, at least as I interpret them.
>
> I did raise a question recently about whether the agent needs to be able
to influence the address/port bindings in such a way as to ensure e.g. that
related flows were assigned bindings with the same IP address. I do not
understand the relevant applications well enough to know if this is a
requirement.
>
<BP>
There are at least two cases I can think of where the agent wants to tell
the middlebox what the binding is: 1) when establishing the NAT to allow SIP
signalling through the middlebox (It will likely want to make the port be
5060); and 2) for when there are redundant peering points and the agent
wants to same binding in both NAT middleboxes. It might "learn" the binding
from one middlebox and "tell" the other middlebox that binding.
</BP>




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 09:42:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15905
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 09:42:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24141;
	Fri, 3 Aug 2001 09:41:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24108
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 09:41:32 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15876
	for <midcom@ietf.org>; Fri, 3 Aug 2001 09:40:27 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f73DfEY06789
	for <midcom@ietf.org>; Fri, 3 Aug 2001 06:41:14 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp71.cisco.com [10.21.64.71])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id AAN09570;
	Fri, 3 Aug 2001 06:40:57 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010803093743.00a16a30@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 03 Aug 2001 09:42:17 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Framework draft last call
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I think that enough issues were raised over the past two weeks
that need resolution that we need to put a hold on last call
and work these through.  Alas, Suresh will not be able to make
it to London, but let's go ahead with the proposed editing 
session (is the Thursday at 19:30 proposal agreeable?) and take
very, very good notes.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 10:12:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16537
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 10:12:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24898;
	Fri, 3 Aug 2001 10:12:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24867
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 10:12:32 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16486
	for <midcom@ietf.org>; Fri, 3 Aug 2001 10:11:28 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f73EBmg13157
	for <midcom@ietf.org>; Fri, 3 Aug 2001 15:11:48 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 3 Aug 2001 15:11:34 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PSC09GNF>; Fri, 3 Aug 2001 15:11:26 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445154@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Framework draft last call
Date: Fri, 3 Aug 2001 15:11:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11C26.33C380B0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11C26.33C380B0
Content-Type: text/plain;
	charset="iso-8859-1"

1930 is OK I think everybody agreed on the timing
What could be nice is that we put all comments in one document and use the
kind of "comment format" that Abdallah proposed: comment, proposed text, and
reasoning.
I started a document like that, I'll try to send it to the list by Monday
night
Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Friday, August 03, 2001 3:42 PM
To: midcom@ietf.org
Subject: [midcom] Framework draft last call


I think that enough issues were raised over the past two weeks
that need resolution that we need to put a hold on last call
and work these through.  Alas, Suresh will not be able to make
it to London, but let's go ahead with the proposed editing 
session (is the Thursday at 19:30 proposal agreeable?) and take
very, very good notes.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11C26.33C380B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Framework draft last call</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>1930 is OK I think everybody agreed on the =
timing</FONT>
<BR><FONT SIZE=3D2>What could be nice is that we put all comments in =
one document and use the kind of &quot;comment format&quot; that =
Abdallah proposed: comment, proposed text, and reasoning.</FONT></P>

<P><FONT SIZE=3D2>I started a document like that, I'll try to send it =
to the list by Monday night</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, August 03, 2001 3:42 PM</FONT>
<BR><FONT SIZE=3D2>To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [midcom] Framework draft last call</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think that enough issues were raised over the past =
two weeks</FONT>
<BR><FONT SIZE=3D2>that need resolution that we need to put a hold on =
last call</FONT>
<BR><FONT SIZE=3D2>and work these through.&nbsp; Alas, Suresh will not =
be able to make</FONT>
<BR><FONT SIZE=3D2>it to London, but let's go ahead with the proposed =
editing </FONT>
<BR><FONT SIZE=3D2>session (is the Thursday at 19:30 proposal =
agreeable?) and take</FONT>
<BR><FONT SIZE=3D2>very, very good notes.</FONT>
</P>

<P><FONT SIZE=3D2>Melinda</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/midcom</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11C26.33C380B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 10:33:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16883
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 10:33:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25395;
	Fri, 3 Aug 2001 10:33:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25366
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 10:33:46 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16860
	for <midcom@ietf.org>; Fri, 3 Aug 2001 10:32:41 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f73EX1g17247
	for <midcom@ietf.org>; Fri, 3 Aug 2001 15:33:01 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 3 Aug 2001 15:32:39 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <QB9DVGGZ>;
          Fri, 3 Aug 2001 15:31:27 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445155@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "Richard Swale (E-mail)" <richard.swale@bt.com>,
        Mark Duffy <mduffy@quarrytech.com>
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
Subject: RE: [midcom] Comments on requirements draft v2
Date: Fri, 3 Aug 2001 15:31:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11C28.FC07BE40"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11C28.FC07BE40
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,
What I originally meant was the support of the following type of request:
give me a * address and * port for the flow being sent to 10.1.2.3 at port
30000.

Also some application might require that we require explicitly specific
values instead
 of taking whatever address and port the Middle box will provide, as you
already stated below.
This is not complicated to do, at most the Middle box replies with other
parms or could send an error.
The middle box reply behavior could be based on a parm in the request
message :
in case the bind is already allocated, give me what you have or forget it an
send an error message, or 
give me the ranges you could provide. 
Many things could be done here, but we also need it to be simple.

> MD:
> I believe it is out of place to state these kind of requirements here on
agent and middlebox -- those are for the market to impose (or not). Rather,
this protocol requirement should state that the midcom protocol must provide
the support necessary for multiple agents per middlebox and multiple
middleboxes per agent.

<BP>
I like Mark's language here. The original text reads like it is imposing
requirements on the middlebox itself which we should not do.
</BP>
CA: Agreed. Good point 
Cedric

------_=_NextPart_001_01C11C28.FC07BE40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [midcom] Comments on requirements draft v2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Bob,</FONT>
<BR><FONT SIZE=2>What I originally meant was the support of the following type of request:</FONT>
<BR><FONT SIZE=2>give me a * address and * port for the flow being sent to 10.1.2.3 at port 30000.</FONT>
</P>

<P><FONT SIZE=2>Also some application might require that we require explicitly specific values instead</FONT>
<BR><FONT SIZE=2>&nbsp;of taking whatever address and port the Middle box will provide, as you already stated below.</FONT>
<BR><FONT SIZE=2>This is not complicated to do, at most the Middle box replies with other parms or could send an error.</FONT>
<BR><FONT SIZE=2>The middle box reply behavior could be based on a parm in the request message :</FONT>
<BR><FONT SIZE=2>in case the bind is already allocated, give me what you have or forget it an send an error message, or </FONT>
<BR><FONT SIZE=2>give me the ranges you could provide. </FONT>
<BR><FONT SIZE=2>Many things could be done here, but we also need it to be simple.</FONT>
</P>

<P><FONT SIZE=2>&gt; MD:</FONT>
<BR><FONT SIZE=2>&gt; I believe it is out of place to state these kind of requirements here on</FONT>
<BR><FONT SIZE=2>agent and middlebox -- those are for the market to impose (or not). Rather,</FONT>
<BR><FONT SIZE=2>this protocol requirement should state that the midcom protocol must provide</FONT>
<BR><FONT SIZE=2>the support necessary for multiple agents per middlebox and multiple</FONT>
<BR><FONT SIZE=2>middleboxes per agent.</FONT>
</P>

<P><FONT SIZE=2>&lt;BP&gt;</FONT>
<BR><FONT SIZE=2>I like Mark's language here. The original text reads like it is imposing</FONT>
<BR><FONT SIZE=2>requirements on the middlebox itself which we should not do.</FONT>
<BR><FONT SIZE=2>&lt;/BP&gt;</FONT>
<BR><FONT SIZE=2>CA: Agreed. Good point </FONT>
<BR><FONT SIZE=2>Cedric</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11C28.FC07BE40--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 11:32:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18207
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 11:32:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26579;
	Fri, 3 Aug 2001 11:31:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26511
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 11:31:04 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18106
	for <midcom@ietf.org>; Fri, 3 Aug 2001 11:29:57 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f73FTs910834
	for <midcom@ietf.org>; Fri, 3 Aug 2001 11:29:54 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 3 Aug 2001 11:30:04 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSGN9D>; Fri, 3 Aug 2001 11:30:07 -0400
Message-ID: <D38D073716F2D411BEE400508BCF629613359E@zcard04k.ca.nortel.com>
From: "Fernando Cuervo" <cuervo@nortelnetworks.com>
To: "'Andrew Molitor'" <amolitor@visi.com>, midcom@ietf.org
Cc: "'mshore@cisco.com'" <mshore@cisco.com>
Subject: RE: [midcom] defining in-path and out-of-path agents
Date: Fri, 3 Aug 2001 11:30:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11C31.2F502000"
X-Orig: <cuervo@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11C31.2F502000
Content-Type: text/plain

If you have agent and MB technology that use Midcom then your packaging
scenario is fine. I understood Cedric's comment in a different light:
application intelligence for a particular MB implementation is clearly not
always removable using Midcom given that the scope of midcom is for
functionality that is "in-path". 

Fernando Cuervo

> -----Original Message-----
> From:	Andrew Molitor [SMTP:amolitor@visi.com]
> Sent:	Wednesday, August 01, 2001 3:55 PM
> To:	midcom@ietf.org
> Subject:	RE: [midcom] defining in-path and out-of-path agents
> 
> 
> 
> On Wed, 1 Aug 2001, Melinda Shore wrote:
> 
> > At 03:25 PM 8/1/01 -0400, Fernando Cuervo wrote:
> > 
> > >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. 
> > 
> > It is possible, if unlikely, that someone might want to run a midcom
> protocol between
> > an agent and a firewall on the same box.  
> 
> 	This is the land of networking. If it is possible, the probability
> is nearly 1 that someone somewhere will want to do it.
> 
> 	If you have middlebox technology and agent technology, which
> technologies communicate via MIDCOM, it makes perfect sense to package
> the two together, talking MIDCOM over sockets connected to localhost,
> to implement a lower end solution.
> 
> 	I agree that things become much clearer if you think in
> terms of functions, not boxes. My experience suggests that drawing
> a "box" around any particular set of functions tends to yield a
> more or less well-defined device, which someone will surely desire
> some day.
> 
> 
> 		Andrew
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11C31.2F502000
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] defining in-path and out-of-path agents</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If you have agent =
and MB technology that use Midcom then your packaging scenario is fine. =
I understood Cedric's comment in a different light: application =
intelligence for a particular MB implementation is clearly not always =
removable using Midcom given that the scope of midcom is for =
functionality that is &quot;in-path&quot;. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Fernando =
Cuervo</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Andrew Molitor [SMTP:amolitor@visi.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, August 01, 2001 3:55 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">midcom@ietf.org</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: [midcom] defining in-path and =
out-of-path agents</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Wed, 1 Aug 2001, Melinda Shore =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; At 03:25 PM 8/1/01 -0400, =
Fernando Cuervo wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;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. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; It is possible, if unlikely, =
that someone might want to run a midcom protocol between</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; an agent and a firewall on the =
same box.&nbsp; </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">This is the land of networking. If it is possible, the =
probability</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is nearly 1 that someone somewhere =
will want to do it.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">If you have middlebox technology and agent technology, =
which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">technologies communicate via MIDCOM, =
it makes perfect sense to package</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the two together, talking MIDCOM over =
sockets connected to localhost,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to implement a lower end =
solution.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I agree that things become much clearer if you think =
in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">terms of functions, not boxes. My =
experience suggests that drawing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a &quot;box&quot; around any =
particular set of functions tends to yield a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">more or less well-defined device, =
which someone will surely desire</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some day.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Andrew</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">midcom mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">midcom@ietf.org</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/midcom</A></FONT>=
</U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C11C31.2F502000--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 12:29:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20006
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 12:29:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26961;
	Fri, 3 Aug 2001 11:51:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26933
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 11:51:37 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19079
	for <midcom@ietf.org>; Fri, 3 Aug 2001 11:50:33 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f73FpLY15952
	for <midcom@ietf.org>; Fri, 3 Aug 2001 08:51:21 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-136.cisco.com [10.21.96.136])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIN06175;
	Fri, 3 Aug 2001 08:51:05 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 3 Aug 2001 11:51:09 -0400
Date: Fri, 3 Aug 2001 11:51:09 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Message-ID: <20010803115109.K1524@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] Requirements in the framework draft
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Going through the framework draft, I find the following requirements
(implicit or explicit) which have not yet been agreed on by the working
group.  I'm not suggesting any changes to concepts or wording or
anything else in the framework draft here (see other mail), just
summarizing requirements.  

We've decided not to push for last call on the framework draft, which is
a relief.  Progress in each of the framework and requirements drafts
requires progress in the other.  I think the pendulum has swung and we
need to make a lot of progress on requirements before going back to
focus on the framework.  

Specifically, I would like the chair to select just two, maybe three,
requirements each week and push them as far toward resolution as
possible, strictly controlling other discussion.  

I'll try to put together a list of known requirements -- I suspect
others are as well :-) -- but here are the ones in the framework draft
to start with.

> 3.0 Architectural framework for Middleboxes

>    Firewall ACLs, NAT-BINDs, NAT address-maps and 
>    Session-descriptors are a few of the middlebox managed
>    resources. Session-Descriptor above refers to a session denoted
>    by the tuple of (SessionDirection, SourceAddress,
>    DestinationAddress, Protocol, SourcePort, DestinationPort).

Assumed requirement: a "session descriptor" MUST be uniquely identified
by this tuple.  We don't yet know if that's true -- in fact for
extensibility we cannot assume it's true.  We cannot assume how agents
will refer to state information they want to control ... until we finish
the requirements.

> 4. MIDCOM Protocol

>    The MIDCOM protocol between a MIDCOM agent and a middlebox allows
>    the MIDCOM agent to gain access to middlebox resources and
>    allows the middlebox to delegate application specific processing
>    to MIDCOM agent. The protocol will allow MIDCOM agents to signal
>    the middleboxes to let complex applications using dynamic port 
>    based sessions through them (i.e., middleboxes) seamlessly. 

"delegate" assumes a particular control relationship between middlebox
and agent.  So would "relinquish".  Assumed requirement: An agent MUST
accept responsibility for application-specific processing under
direction of a middlebox which is performing a related service for that
agent.

>    The MIDCOM protocol will consist of a connection setup phase, 
>    run-time connection phase and a connection termination phase. 

Assumed requirement: there MUST be some activity between agent and
middlebox which maintains a "connected" state.  It may be that some kind
of probe to see if the other function is still there is all that is
intended -- the question still remains.  What kind of interaction do we
*require* between agent and middlebox, beyond registration and
deregistration?

>    MIDCOM is a
>    peer-to-peer protocol. As such, either the agent or the
>    middlebox may choose to initiate the connection.

Assumed requirement: either the agent or the middlebox may initiate the
connection.  Do we require that of the protocol?  If not, what do we
require?  Why?

> 5.0. MIDCOM Agents

>    A 
>    MIDCOM agent may communicate with one or more middleboxes.

Assumed requirement: The midcom protocol MUST allow for agents to
communicate with one or more middleboxes, and for middleboxes to
communicate with one or more agents.  (I think this is a fine
requirement, but let's get explicit consensus.)

>    In-Path MIDCOM agents are entities that have a native role in the 
>    path of the application traversal (with prior knowledge to one of
>    the application end-hosts), independent of their MIDCOM function.

What does "with prior knowledge" mean?  If it means what I think it does
.. assumed requirement: agents MUST be known to end system
applications.

> 6.1. Authentication, Integrity and Confidentiality

>    Security shall be
>    specified to minimize the impact on connections that do not use the
>    security option.

The above text is a requirement for the midcom protocol.

>    Security should be designed to avoid introducing
>    and to minimize the impact of denial of service attacks.

Another.

> 6.2. Registration and deregistration with a middlebox

>    Profile of a MIDCOM agent includes agent authorization policy (i.e, 
>    session tuples for which the agent is authorized to act as ALG),
>    agent-hosting-entity (e.g., Proxy, Gateway or end-host which hosts
>    the agent),

What does this mean?  An expected IP address?  Assumed requirement:
Agent hosting entity (whatever that is) MUST be identified in the midcom
protocol. 

>    Coupling MIDCOM agents with the middlebox resources requires
>    a means of reflecting that into the resource description table
>    of the middlebox. 

Requirement: a middlebox MUST couple middlebox resources with midcom
agents.

>    Once a connection is established between a middlebox
>    and a MIDCOM agent, that connection should be usable with multiple
>    instances of the application(s), as appropriate.

That's a requirement.

> 8.1. Multiple MIDCOM connections between agents and middlebox 
> 
>    A middlebox cannot be assumed to be a simple device
>    implementing just one middlebox function and no more than a 
>    couple of interfaces. Middleboxes often combine multiple 
>    intermediate functions into the same device and have the 
>    ability to provision individual interfaces of the same device
>    with different sets of functions and varied provisioning for
>    the same function across the interfaces. 
> 
>    As such, a MIDCOM agent ought to be able to have a single 
>    MIDCOM connection with a middlebox and use the MIDCOM
>    interface on the middlebox to interface with different
>    services on the same middlebox interface.

It sounds good but what is a "connection"?  If you are assuming some
kind of reliable transport, this is an assumed requirement.

> 8.3. Asynchronous notification to MIDCOM agents
> 
>    Asynchronous notification by the middlebox to a MIDCOM agent
>    can be useful for events such as Session creation, Session 
>    termination, MIDCOM protocol failure, Middlebox function 
>    failure or any other significant event. Independently, ICMP
>    error codes can also be useful to notify transport layer
>    failures to the agents. 

Assumed requirement: a middlebox MUST be able to notify one or more
agents of all these events.

>    In addition, periodic notification of various forms of data 
>    such as statistics update would also be a useful function
>    that would be beneficial to certain types of agents.

Is this a requirement or not?

> 8.4. Timers on Middlebox considered useful

>    However, the middlebox should be able to recover the dynamically
>    allocated resources even as the agent that was responsible for
>    the allocation is not alive. Associating a lifetime for these
>    dynamic resources and using a timer to track the lifetime can
>    be a good way to accomplish this.

Requirement: A middlebox MUST be able to associate a timer with session
elements.  

> 9. Applicability Statement
> 
>    Middleboxes may be stationed in a number of topologies. However,
>    the
>    signaling framework outlined in this document may be limited to
>    only
>    those middleboxes that are located in a DMZ (De-Militarized Zone)
>    at 
>    the edge of a private domain, connecting to the Internet. 
>    Specifically, the assumption is that you have a single middlebox 
>    (running NAT or firewall) along the application route. Discovery of
>    middlebox along application route is outside the scope of this 
>    document. It is conceivable to have middleboxes located between
>    departments within the same domain or inside service provider's
>    domain and so forth. However, care must be taken to review each
>    individual scenario and determine the applicability on a
>    case-by-case basis.

I think there's a requirement in here but I'm not sure what it is.


..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 13:26:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22178
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 13:26:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29672;
	Fri, 3 Aug 2001 13:16:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29604
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 13:16:52 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21972
	for <midcom@ietf.org>; Fri, 3 Aug 2001 13:15:49 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f73HGKg15143
	for <midcom@ietf.org>; Fri, 3 Aug 2001 10:16:20 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-136.cisco.com [10.21.96.136])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIN07709;
	Fri, 3 Aug 2001 10:15:52 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 3 Aug 2001 13:15:56 -0400
Date: Fri, 3 Aug 2001 13:15:56 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Message-ID: <20010803131556.A1448@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="FzqucMF4q3XwO0h0"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] Requirements summary: all requirements
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--FzqucMF4q3XwO0h0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

I went through the requirements draft, the framework draft, and some
(but not all) mail that's been exchanged recently and produced the
enclosed.  

Yes, I really think we should work on very focused requirements in order
to make progress.  This is supposed to be a tool to help.  I propose
that someone (me by default, although I hope to find a volunteer) keep
this up and produce a new version every week.  If I'm doing it I will
not be sending it out to the list after this, but making it FTPable
instead.

Does a weekly update of a "living document" sound good?

I did not ask the Requirements authors before putting their names on
this, but they wrote 95% of the material.

By the way, this is a product of emacs and xml2rfc
<http://xml.resource.org>.

..Scott


--FzqucMF4q3XwO0h0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="draft-brim-midcom-reqs-00_010803.txt"


Network Working Group                                           R. Swale
Internet-Draft                                      BTexact Technologies
Expires: February 1, 2002                                      P. Sijben
                                             Lucent Technologies EMEA BV
                                                                 P. Mart
                                            Marconi Communications, Ltd.
                                                                 S. Brim
                                                     Cisco Systems, Inc.
                                                          August 3, 2001


                          Midcom Requirements
                       draft-brim-midcom-reqs-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 1, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document summarizes requirements for a signaling protocol
   between a "middlebox" and a midcom "agent".







Swale, et al.           Expires February 1, 2002                [Page 1]

Internet-Draft             Midcom Requirements               August 2001


Table of Contents

   1.  Introduction and Goals . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements agreed upon by the working group  . . . . . . . .  3
   2.1 Relationship Between Agent and Middlebox . . . . . . . . . . .  3
   2.2 Relationship Between Agent and Endpoint  . . . . . . . . . . .  3
   2.3 Middlebox Responsibilities . . . . . . . . . . . . . . . . . .  3
   2.4 Agent Responsibilities . . . . . . . . . . . . . . . . . . . .  3
   2.5 Midcom Protocol Machinery  . . . . . . . . . . . . . . . . . .  3
   2.6 Midcom Protocol Semantics  . . . . . . . . . . . . . . . . . .  4
   2.7 General Security Requirements  . . . . . . . . . . . . . . . .  4
   3.  Requirements under discussion  . . . . . . . . . . . . . . . .  4
   3.1 Relationship Between Agent and Middlebox . . . . . . . . . . .  4
   3.2 Relationship Between Agent and Endpoint  . . . . . . . . . . .  4
   3.3 Middlebox Responsibilities . . . . . . . . . . . . . . . . . .  4
   3.4 Agent Responsibilities . . . . . . . . . . . . . . . . . . . .  5
   3.5 Midcom Protocol Machinery  . . . . . . . . . . . . . . . . . .  5
   3.6 Midcom Protocol Semantics  . . . . . . . . . . . . . . . . . .  5
   3.7 General Security Requirements  . . . . . . . . . . . . . . . .  6
   4.  Requirements not yet discussed . . . . . . . . . . . . . . . .  6
   4.1 Relationship Between Agent and Middlebox . . . . . . . . . . .  7
   4.2 Relationship Between Agent and Endpoint  . . . . . . . . . . .  7
   4.3 Middlebox Responsibilities . . . . . . . . . . . . . . . . . .  7
   4.4 Agent Responsibilities . . . . . . . . . . . . . . . . . . . .  7
   4.5 Midcom Protocol Machinery  . . . . . . . . . . . . . . . . . .  7
   4.6 Midcom Protocol Semantics  . . . . . . . . . . . . . . . . . .  9
   4.7 General Security Requirements  . . . . . . . . . . . . . . . . 12
   5.  Requirements already rejected  . . . . . . . . . . . . . . . . 13
   5.1 Relationship Between Agent and Middlebox . . . . . . . . . . . 13
   5.2 Relationship Between Agent and Endpoint  . . . . . . . . . . . 13
   5.3 Middlebox Responsibilities . . . . . . . . . . . . . . . . . . 13
   5.4 Agent Responsibilities . . . . . . . . . . . . . . . . . . . . 13
   5.5 Midcom Protocol Machinery  . . . . . . . . . . . . . . . . . . 13
   5.6 Midcom Protocol Semantics  . . . . . . . . . . . . . . . . . . 13
   5.7 General Security Requirements  . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15












Swale, et al.           Expires February 1, 2002                [Page 2]

Internet-Draft             Midcom Requirements               August 2001


1. Introduction and Goals

   This document lists all agreements made by the IETF Midcom Working
   Group regarding requirements for a protocol between a Midcom agent
   and a middlebox.  Requirements are divided into four sections: those
   requirements which have been discussed and for which consensus has
   been reached; those requirements which are currently under
   discussion; those requirements which have been suggested by working
   group participants but which have not yet been discussed; and
   finally, those requirements which have been discussed and rejected.

   Nothing should be moved into the "agreed on" section without security
   considerations being explicitly addressed.

   For terminology and background information see the Midcom Framework
   document [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

2. Requirements agreed upon by the working group

2.1 Relationship Between Agent and Middlebox


2.2 Relationship Between Agent and Endpoint


2.3 Middlebox Responsibilities


2.4 Agent Responsibilities


2.5 Midcom Protocol Machinery

   R1: The MIDCOM protocol MUST enable a MIDCOM Agent requiring the
       services of a Middlebox to establish an association between
       itself and the Middlebox for the purposes of requesting pin-hole
       services from the Middlebox and obtaining statistics and other
       reporting information.

          Security considerations:







Swale, et al.           Expires February 1, 2002                [Page 3]

Internet-Draft             Midcom Requirements               August 2001


2.6 Midcom Protocol Semantics

   R2: The syntax and semantics of the Midcom Protocol MUST be
       extensible to allow the requirements of future applications to be
       adopted.

          Security considerations:

   R3: The Middlebox MUST support multiple simultaneous MIDCOM Agents.
       A specific Middlebox MUST NOT assume any relationship between
       MIDCOM Agents.

          Security considerations:


2.7 General Security Requirements


3. Requirements under discussion

3.1 Relationship Between Agent and Middlebox


3.2 Relationship Between Agent and Endpoint

   R4: Agents MUST be known to end system applications.

          This comes from the following text in the framework draft,
          version -03: "In-Path MIDCOM agents are entities that have a
          native role in the path of the application traversal (with
          prior knowledge to one of the application end-hosts),
          independent of their MIDCOM function."


3.3 Middlebox Responsibilities

   R5: a middlebox MUST couple middlebox resources with midcom agents.

          This is from the framework draft, version -03: "Coupling
          MIDCOM agents with the middlebox resources requires a means of
          reflecting that into the resource description table of the
          middlebox."

   R6: A middlebox must be able to associate a timer with session
       elements.

          From the framework draft, version -03.




Swale, et al.           Expires February 1, 2002                [Page 4]

Internet-Draft             Midcom Requirements               August 2001


3.4 Agent Responsibilities

   R7: An agent MUST accept responsibility for application-specific
       processing under direction of a middlebox which is performing a
       related service for that agent.

          This comes from the following text in the framework draft
          version -03: "The MIDCOM protocol between a MIDCOM agent and a
          middlebox allows the MIDCOM agent to gain access to middlebox
          resources and allows the middlebox to delegate application
          specific processing to MIDCOM agent.  The protocol will allow
          MIDCOM agents to signal the middleboxes to let complex
          applications using dynamic port based sessions through them
          (i.e., middleboxes) seamlessly."

          "Delegate" assumes a particular control relationship between
          middlebox and agent.


3.5 Midcom Protocol Machinery

   R8: There MUST be some activity between agent and middlebox which
        maintains a "connected" state.

           This is from the framework document, version -03.

           What kind of interaction do we *require* between agent and
           middlebox, beyond registration and deregistration?

   R9: Either the agent or the middlebox may initiate a registration.

           This is from the framework document, version -03.

   R10: A middlebox MUST be able to notify a midcom agent of the
        following events: Session creation, Session termination, MIDCOM
        protocol failure, Middlebox function failure or any other
        significant event.  Independently, ICMP error codes can also be
        useful to notify transport layer failures to the agents.

           From the framework draft, version -03.


3.6 Midcom Protocol Semantics

   R11: A "session descriptor" MUST be uniquely identified by the tuple
        {SessionDirection, SourceAddress, DestinationAddress, Protocol,
        SourcePort, DestinationPort}.




Swale, et al.           Expires February 1, 2002                [Page 5]

Internet-Draft             Midcom Requirements               August 2001


           From the framework draft version -03.

           We don't yet know if that's true -- in fact for extensibility
           we cannot assume it's true.  We cannot assume how agents will
           refer to state information they want to control ...  until we
           finish the requirements.

   R12: The midcom protocol MUST allow for agents to communicate with
        one or more middleboxes, and for middleboxes to communicate with
        one or more agents.

           This is from the framework document, version -03.

   R13: Agent hosting entity (whatever that is) MUST be identified in
        the midcom protocol.

           This is from the framework document, version -03.

   R14: Once a connection is established between a middlebox and a
        MIDCOM agent, that connection should be usable with multiple
        instances of the application(s), as appropriate.

           From the framework draft, version -03.

   R15: A Midcom agent ought to be able to have a single MIDCOM
        connection with a middlebox and use the MIDCOM interface on the
        middlebox to interface with different services on the same
        middlebox interface.

           From the framework draft, version -03.


3.7 General Security Requirements

   R16: Security shall be specified to minimize the impact on
        connections that do not use the security option.

           This is from the framework document, version -03.

   R17: Security should be designed to avoid introducing and to minimize
        the impact of denial of service attacks.

           This is from the framework document, version -03.








Swale, et al.           Expires February 1, 2002                [Page 6]

Internet-Draft             Midcom Requirements               August 2001


4. Requirements not yet discussed

4.1 Relationship Between Agent and Middlebox


4.2 Relationship Between Agent and Endpoint


4.3 Middlebox Responsibilities

   R18: The Middlebox MUST NOT alter packet information unless it
        appears in the packet header.

           This is to ensure that there is an appropriate separation of
           concerns between the Midcom Agent and the Middlebox.

           There is disagreement over whether this requirement is needed
           or even useful, since it's essentially none of midcom's
           business what a particular middlebox does.


4.4 Agent Responsibilities


4.5 Midcom Protocol Machinery

   R19: A pin-hole may be closed such that ICMP reporting for
        subsequently discarded packets is either enabled or disabled.

   R20: As Pin-Holes may be shared across Middlebox functions, it MUST
        be possible for a Pinhole-Descriptor to be created by one
        function, and terminated by a different one.

   R21: Where the communication relationship between a Middlebox and a
        MIDCOM Agent becomes invalid, all existing Pin-Holes owned by
        the MIDCOM Agent concerned MUST be closed.

   R22: Where a multiplicity of MIDCOM Agents are interacting with a
        given Middlebox, the Midcom Protocol MUST provide mechanisms
        ensuring that the overall behaviour is deterministic.

   R23: The Midcom Protocol MUST enable the Middlebox and any associated
        Midcom Agents to establish known and stable state.  This must
        include the case of power failure, or other failure, where the
        protocol must ensure that any resources used by a failed element
        can be released.

   R24: The protocol MUST provide per message acknowledgements, in order



Swale, et al.           Expires February 1, 2002                [Page 7]

Internet-Draft             Midcom Requirements               August 2001


        to achieve reliable communication.

   R25: The Midcom Protocol MUST be able to operate in an extended
        network environment between the Midcom Agent and the Middlebox
        that may be susceptible to the loss of packets.

   R26: The Midcom Protocol SHOULD allow a multiplicity of MIDCOM Agents
        to concurrently interact with a given Middlebox.

   R27: The Midcom Protocol MUST NOT inhibit the deployment of real-time
        communication applications in a Middlebox environment.  It
        therefore MUST exhibit low latency characteristics commensurate
        with the control of such applications.

   R28: The protocol MUST support time-constrained operation to enable
        scalability of the complete solution.  This may include, amongst
        other things, the use of short messages and minimal messages per
        operation.

   R29: The protocol MUST NOT assume 0 (zero) delay in communication
        paths to enable realistic deployment scenarios.  The protocol
        MUST be capable of being used over low speed links.

   R30: The Midcom Agent MUST be able to report its status to a
        Middlebox with which it is associated.

   R31: The Middlebox MUST be able to report its status to a Midcom
        Agent with which it is associated.

   R32: The protocol MUST support unsolicited messages, for event
        reporting and propagation of alarms.

   R33: The relationship between a Midcom Agent and a given Middlebox
        may be pre-configured through a manual configuration process or
        may be established dynamically through a registration process.
        In either case, depending upon the policy applied to the
        Middlebox, the Middlebox MUST appropriately authenticate the
        identity and credentials of the Midcom Agent seeking to make use
        of its services prior to servicing any other requests from the
        Midcom Agent.

   R34: The Midcom Protocol MUST allow either the Midcom Agent or the
        Middlebox to terminate the communications relationship between a
        Midcom Agent and a Middlebox.  This allows either entity to
        close the session for maintenance, security or other reasons.

   R35: Once the need for the relationship between a Midcom Agent and a
        Middlebox established during the registration process has



Swale, et al.           Expires February 1, 2002                [Page 8]

Internet-Draft             Midcom Requirements               August 2001


        lapsed, a deregistration process will be required.  This will
        break the trust relationship between the specific Middlebox and
        Midcom Agent.  Once this has been done, a Middlebox MUST NOT
        service any further requests from a given Midcom Agent without
        the Midcom Agent first re-establishing the appropriate trust
        relationship with the Middlebox.

   R36: At the end of a Midcom session between a Middlebox and Midcom
        Agent, it MUST be possible for either the Middlebox or the
        Midcom Agent to initiate the disconnection of the relationship.

   R37: As part of the de-registration process, any Pin-Holes or other
        Middlebox resources requested by the Midcom Agent MUST be
        immediately released by the Middlebox.

   R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom
        Agent to determine when a registration session is no longer
        valid.  This is to address cases such as when either a Middlebox
        or MIDCOM Agent restarts.

   R39: A Midcom Agenet MUST be able to determine whether a request was
        successful or not.  (Huitema)


4.6 Midcom Protocol Semantics

   R40: A Pin-Hole MUST be identified by a suitable Pinhole-Descriptor
        which uniquely identifies a flow denoted by the tuple of
        FlowDirection, SourceAddress, DestinationAddress, Protocol,
        SourcePort and DestinationPort.

           Should we be this specific?

           Does this statement unduly constrain what the midcom protocol
           may communicate?

           What's the point of having a "MAY" here?

   R41: The MIDCOM Protocol MUST contain version inter-working
        capabilities to enable subsequent extensions to support
        different types of Middlebox and future requirements of
        applications not considered at this stage.

   R42: The syntax and semantics of the Midcom Protocol MUST be
        independent of the application(s) requesting Middlebox services.

   R43: The Midcom Protocol SHOULD allow the aggregation of commands,
        requests and responses.



Swale, et al.           Expires February 1, 2002                [Page 9]

Internet-Draft             Midcom Requirements               August 2001


   R44: The protocol MUST permit the expression of direction to be
        associated with a pin-hole.  The direction MUST be specified in
        terms that apply to external view of the Middlebox.  This
        directionality shall be expressed as 'in', 'out' or 'loopback'
        (meaning both 'in' and 'out' of the same side of the same
        Middlebox realm).

   R45: It MUST be possible for the attributes associated with a
        Pinhole-Descriptor to be specific to a given Middlebox or MIDCOM
        Agent.

   R46: The Midcom Protocol SHOULD support the concept of an aggregated
        Pinhole-Descriptor comprising a multiple of individual flows to
        be treated as an aggregate.

   R47: When accepting a request for a pin-hole, the Middlebox MUST be
        able to provide the MIDCOM Agent with information that may be
        used to identify the flow in subsequent operations.

   R48: The Midcom Protocol MUST allow the MIDCOM Agent to describe the
        desired behaviour of the Middlebox for the purposes of a
        requested flow(s).

           What does this mean in concrete terms?

   R49: To enable real-time streamed media to be supported, the Midcom
        Protocol MUST allow a MIDCOM Agent to specify a Pin-Hole in
        terms of the packet size and flow rate which is required.

   R50: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of IPv4 source
        and destination IP address, protocol number, and diffserv field.

   R51: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of packet size
        (maximum and minimum length, inter-packet arrival time.

   R52: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of IPv4 source
        and destination IP address or group of them determined by a
        netmask, protocol number, diffserv field.

   R53: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of IPv6 source
        and destination IP address or group of them determined by a
        netmask, next header fields (Note: multiple fields may need to
        be traversed until a match is found) and traffic class field.




Swale, et al.           Expires February 1, 2002               [Page 10]

Internet-Draft             Midcom Requirements               August 2001


   R54: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of UDP source and
        destination port numbers or group of them.

   R55: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of TCP source and
        destination port numbers or group of them, 'SYN packets'
        permission.

   R56: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of ICMP type
        and code.

   R57: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of IGMP type.

   R58: The Midcom Protocol MUST enable a MIDCOM Agent to tear-down an
        active pin-hole.

   R59: The MIDCOM Protocol must allow the ownership of a requested flow
        to be transferred from one MIDCOM Agent to another.  In doing so
        the Middlebox may need to act as a mediation point for affecting
        the transfer of ownership.  This is necessary for a variety of
        reasons including scalability of the solution.

   R60: An operation is needed to enable a MIDCOM Agent to request that
        a Middlebox maintain (refresh) an established Pin-Hole over
        which the Agent has ownership.

   R61: If a peer does not understand an option it MUST be clear whether
        the action required is to proceed without the unknown attribute
        being taken into account or the request is to be rejected.
        Where attributes may be ignored if not understood, a means MAY
        be provided to inform the client about what has been ignored.

           This may be provided as a version and capability exchange
           mechanism.

   R62: The Midcom Protocol SHOULD allow the aggregation of commands,
        requests and responses.

   R63: To enable management systems to interact with the Midcom
        environment, the protocol MUST include failure reasons that
        allow the Midcom Agent behaviour to be modified as a result of
        the information contained in the reason.  Failure reasons need
        to be chosen such that they do not make an attack on security
        easier.




Swale, et al.           Expires February 1, 2002               [Page 11]

Internet-Draft             Midcom Requirements               August 2001


4.7 General Security Requirements

   R64: The Midcom Protocol MUST allow communications between
        Middleboxes and MIDCOM Agents to be authenticated.

   R65: Individual message authentication MUST be used in addition to
        host authentication.  Further message confidentiality MAY be
        administered by employing techniques appropriate to Midcom
        messages.  Simple Source-address based security is the least
        form of security and MAY be permitted only to the most trusted
        hosts.

   R66: Communications between a MIDCOM Agent and a Middlebox constitute
        a flow of requests for services and associated responses.  The
        transport of this information may present a security concern and
        SHOULD be appropriately protected.

   R67: The Midcom Protocol MUST allow for mutual authentication at the
        start of an MIDCOM Agent-Middlebox association.

   R68: The Midcom Protocol MUST allow for preservation of the control
        messages once the association has been established.

   R69: The Midcom Protocol MUST allow for optional confidentiality
        protection of control messages.  (If provided the mechanism
        should allow a choice in the algorithm to be used.).

   R70: The Midcom Protocol MUST operate across un-trusted domains
        between the MIDCOM Agent and Middlebox in a secure fashion.

   R71: The Midcom Protocol MUST support non-repudiation for a customer-
        located Middlebox communicating with a network operator's MIDCOM
        Agent.

   R72: The Midcom Protocol MUST define mechanisms to mitigate denial of
        service attacks.

   R73: The Midcom Protocol MUST define mechanisms to mitigate replay
        attacks on the control messages.

   R74: A Midcom Agent MUST be able to discover what resources are
        available on a middlebox.

   R75: The Midcom Protocol must produce robust operation even when
        routing changes such that traffic from a particular end system
        passes through a different middlebox.  (Huitema)





Swale, et al.           Expires February 1, 2002               [Page 12]

Internet-Draft             Midcom Requirements               August 2001


5. Requirements already rejected

5.1 Relationship Between Agent and Middlebox


5.2 Relationship Between Agent and Endpoint


5.3 Middlebox Responsibilities

   R76: To enable the MIDCOM Agent to implement the desired application
        level functionality, it may be necessary for the Middlebox to
        forward IP packets received on specific IP addresses and/or
        ports directly to the MIDCOM Agent.

           Diversion has been ruled out of scope.  Future working groups
           may address diversion.

   R77: The Middlebox MUST support the explicit forwarding of
        application control session information received on one, or
        more, destination address/port combinations to an appropriate
        MIDCOM Agent.


5.4 Agent Responsibilities


5.5 Midcom Protocol Machinery


5.6 Midcom Protocol Semantics


5.7 General Security Requirements


6. Security Considerations

   This document lists individual requirements.  Any security
   considerations are listed under the discussion notes for each
   requirements.

References

   [1]  Srisuresh, P., Kuthan, J., Rosenberg, J. and A. Rayhan,
        "Middlebox Communication Architecture and framework", Internet
        Draft draft-ietf-midcom-framework-03.txt, July 2001.




Swale, et al.           Expires February 1, 2002               [Page 13]

Internet-Draft             Midcom Requirements               August 2001


   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


Authors' Addresses

   Richard Swale
   BTexact Technologies
   Callisto House
   Adastral Park
   Ipswich
   United Kingdom

   EMail: richard.swale@bt.com


   Paul Sijben
   Lucent Technologies EMEA BV
   Huizen
   Netherlands

   EMail: sijben@lucent.com


   Philip Mart
   Marconi Communications, Ltd.
   Edge Lane
   Liverpool
   United Kingdom

   EMail: philip.mart@marconi.com


   Scott Brim
   Cisco Systems, Inc.
   146 Honness Lane
   Ithaca, NY  14850
   US

   EMail: sbrim@cisco.com











Swale, et al.           Expires February 1, 2002               [Page 14]

Internet-Draft             Midcom Requirements               August 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Swale, et al.           Expires February 1, 2002               [Page 15]




--FzqucMF4q3XwO0h0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 15:25:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24881
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 15:25:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03252;
	Fri, 3 Aug 2001 15:21:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03222
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 15:21:07 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24777
	for <midcom@ietf.org>; Fri, 3 Aug 2001 15:20:04 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f73JIhJ20952
	for <midcom@ietf.org>; Fri, 3 Aug 2001 12:18:46 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-136.cisco.com [10.21.96.136])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIN10536;
	Fri, 3 Aug 2001 12:20:14 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 3 Aug 2001 15:20:17 -0400
Date: Fri, 3 Aug 2001 15:20:17 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] defining in-path and out-of-path agents
Message-ID: <20010803152016.E1448@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <D38D073716F2D411BEE400508BCF629613359E@zcard04k.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <D38D073716F2D411BEE400508BCF629613359E@zcard04k.ca.nortel.com>; from cuervo@nortelnetworks.com on Fri, Aug 03, 2001 at 11:30:11AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Fri, Aug 03, 2001 at 11:30:11AM -0400, Fernando Cuervo apparently wrote:
> If you have agent and MB technology that use Midcom then your packaging
> scenario is fine. I understood Cedric's comment in a different light:
> application intelligence for a particular MB implementation is clearly not
> always removable using Midcom given that the scope of midcom is for
> functionality that is "in-path". 

Fernando, specifically what application intelligence is not removable?

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug  3 15:45:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25431
	for <midcom-archive@odin.ietf.org>; Fri, 3 Aug 2001 15:45:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03750;
	Fri, 3 Aug 2001 15:37:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03719
	for <midcom@ns.ietf.org>; Fri, 3 Aug 2001 15:37:02 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25033
	for <midcom@ietf.org>; Fri, 3 Aug 2001 15:35:59 -0400 (EDT)
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA23439;
	Fri, 3 Aug 2001 14:37:12 -0500 (CDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA29629;
	Fri, 3 Aug 2001 14:36:57 -0500 (CDT)
Received: from xch-pssbh-01.nw.nos.boeing.com (xch-pssbh-01.nw.nos.boeing.com [192.42.227.32])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id f73JauT07309;
	Fri, 3 Aug 2001 12:36:56 -0700 (PDT)
Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <P0FAXV7H>; Fri, 3 Aug 2001 10:26:35 -0700
Message-ID: <8006AC6A777F3F4F8B2A6383C19C5B7A05502EDE@XCH-NW-01.nw.nos.boeing.com>
From: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>
To: "'Scott Brim'" <sbrim@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Requirements summary: all requirements
Date: Fri, 3 Aug 2001 10:26:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

What would help me is to have working drafts which clearly identifies the changes since the last version.

-----Original Message-----
From: Scott Brim [mailto:sbrim@cisco.com]
Sent: Friday, August 03, 2001 10:16 AM
To: midcom@ietf.org
Subject: [midcom] Requirements summary: all requirements


I went through the requirements draft, the framework draft, and some
(but not all) mail that's been exchanged recently and produced the
enclosed.  

Yes, I really think we should work on very focused requirements in order
to make progress.  This is supposed to be a tool to help.  I propose
that someone (me by default, although I hope to find a volunteer) keep
this up and produce a new version every week.  If I'm doing it I will
not be sending it out to the list after this, but making it FTPable
instead.

Does a weekly update of a "living document" sound good?

I did not ask the Requirements authors before putting their names on
this, but they wrote 95% of the material.

By the way, this is a product of emacs and xml2rfc
<http://xml.resource.org>.

..Scott


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sun Aug  5 15:35:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19238
	for <midcom-archive@odin.ietf.org>; Sun, 5 Aug 2001 15:35:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10919;
	Sun, 5 Aug 2001 15:33:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01820
	for <midcom@ns.ietf.org>; Sun, 5 Aug 2001 06:58:10 -0400 (EDT)
Received: from web13803.mail.yahoo.com (web13803.mail.yahoo.com [216.136.175.13])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12191
	for <midcom@ietf.org>; Sun, 5 Aug 2001 06:57:02 -0400 (EDT)
Message-ID: <20010805105807.20239.qmail@web13803.mail.yahoo.com>
Received: from [65.12.33.187] by web13803.mail.yahoo.com; Sun, 05 Aug 2001 03:58:07 PDT
Date: Sun, 5 Aug 2001 03:58:07 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
To: midcom@ietf.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1897794873-997009087=:19217"
Subject: [midcom] Interim rev. of the famework draft
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

--0-1897794873-997009087=:19217
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Folks,

Please find attached the interim rev. framework draft.
You may use this as reference during the editorial meeting. 
Thanks.

regards,
suresh


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--0-1897794873-997009087=:19217
Content-Type: text/plain; name="rfc_out.txt"
Content-Description: rfc_out.txt
Content-Disposition: inline; filename="rfc_out.txt"






Network Working Group                                       P. Srisuresh
INTERNET-DRAFT                              	         Kuokoa Networks
Expires as of February 9, 2002                                 J. Kuthan
                                                               GMD Fokus
                                                            J. Rosenberg
                                                             Dynamicsoft
                                                              A. Molitor
                                                     Aravox Technologies
                                                               A. Rayhan
                                                              Consultant
                                                            August, 2001


          Middlebox Communication Architecture and framework
                <draft-ietf-midcom-framework-04-interim.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet- Drafts as 
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   There are a variety of intermediate devices in the Internet today
   that require application intelligence for their operation. 
   Datagrams pertaining to real-time streaming applications such
   as SIP and H.323 and peer-to-peer applications such as Napster 
   and NetMeeting cannot be identified by merely examining packet
   headers. Middleboxes implementing Firewall and Network Address 
   Translator services typically embed application intelligence 



Srisuresh et al.                                                [Page 1]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   within the device for their operation. The document specifies an 
   architecture and framework in which trusted third parties can 
   be delegated to assist the middleboxes to perform their operation
   without resorting to embedding application intelligence. Doing 
   this will allow a middlebox to continue to provide the services,
   while keeping the middlebox application agnostic. A principal 
   objective of this document is to decribe the underlying framework
   of middlebox communication to enable complex applications 
   through the middleboxes seamlessly using a trusted third party.


1. Introduction

   Intermediate devices requiring application intelligence are the
   subject of this document. These devices are referred as 
   middleboxes throughout the document. Many of these devices enforce
   application specific policy based functions such as packet 
   filtering, VPN (Virtual Private Network) tunneling, Intrusion
   detection, security and so forth. Network Address Translator
   service, on the other hand, provides routing transparency across
   address realms (within IPv4 routing network or across V4 and V6
   routing realms), independent of applications. 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. There may be other types of services requiring
   embedding application intelligence in middleboxes for their
   operation. The discussion scope of this document is however limited
   to Firewall and NAT services. Nonetheless, the middlebox framework
   is designed to be extensible to support the deployment of new
   services.

   Tight coupling of application intelligence with middleboxes makes 
   maintenance of middleboxes hard with the advent of new applications.
   Built-in application awareness typically requires updates of 
   operating systems with new applications or newer versions of 
   existing applications. Operators requiring support for newer 
   applications will not be able to use third party software/hardware
   specific to the application and are at the mercy of their
   middlebox vendor to make the necessary upgrade. Further, embedding
   intelligence for a large number of application protocols within 
   the same middlebox increases complexity of the middlebox and is
   likely to be error prone and degrade in performance.

   This document describes a framework in which application 
   intelligence can be moved from middleboxes into external MIDCOM
   agents. The premise of the framework is to devise a MIDCOM
   protocol that is application independent, so the middleboxes 



Srisuresh et al.                                                [Page 2]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   can stay focused on services such as firewall, NAT and other 
   functions, as required. MIDCOM agents with application intelligence
   can, in turn, assist the middleboxes through the MIDCOM protocol in
   permitting applications such as FTP, SIP and H.323. 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.
   Discovery of middleboxes or MIDCOM agents in the path of an
   application instance is outside the scope of this document. Further,
   any communication amongst middleboxes is also outside the scope of
   this document.
  
   This document describes the framework in which middlebox 
   communication takes place and the various elements that constitute
   the framework. Section 2 describes the terms used in the document.
   Section 3 defines the architectural framework of a middlebox for
   communication with MIDCOM agents. The remaining sections cover the
   components of the framework, illustration using sample flows and
   operational considerations with the MIDCOM architecture. Section 4
   describes the nature of MIDCOM protocol. Section 5 identifies
   entities that could potentially host the MIDCOM agent function. 
   Section 6 considers the role of Policy server and its function
   with regard to communicating MIDCOM agent authorization policies.
   Sections 7 is an illustration of SIP flows using MIDCOM framework
   in which the MIDCOM agent is co-resident on a SIP proxy server. 
   Section 8 addresses operational considerations in deploying a 
   protocol adhering to the framework described here. Section 9 is
   an applicability statement, scoping the location of middleboxes. 
   Section 11 outlines security considerations for the middlebox
   in view of the MIDCOM framework. 


2. Terminology
   
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119.
   Below are the definitions for the terms used throughout the 
   document.
   
2.1. MiddleBox function/service

   A middlebox function or a middlebox service is an operation or
   method performed by a network intermediary that may require
   application specific intelligence for its operation. Policy based
   packet filtering (a.k.a. firewall), Network address translation
   (NAT), Intrusion detection, Load balancing, Policy based tunneling
   and IPsec security are all examples of a middlebox function (or 



Srisuresh et al.                                                [Page 3]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   service).
     
2.2. MiddleBox 

   Middlebox is a network intermediate device that implements one or
   more of the middlebox services. A NAT middlebox is a middlebox 
   implementing NAT service. A firewall middlebox is a middlebox
   implementing firewall service.
     
2.3. Firewall
     
   Firewall is a policy based packet filtering Middlebox function, 
   typically used for restricting access to/from specific devices and 
   applications. The policies are often termed Access Control 
   Lists (ACLs).
     
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. Transparent routing here refers to modifying
   end-node addresses en-route and maintaining state for these updates
   so that when a datagram leaves one realm and enters another,
   datagrams pertaining to a session are forwarded to the right 
   end-host in either realm. Refer [NAT-TERM] for the definition of
   Transparent routing, various NAT types and the associated terms
   in use. Two types of NAT are most common. Basic-NAT, where only an
   IP address (and the related IP, TCP/UDP checksums) of packets is
   altered and NAPT (Network Address Port Translation), where both an
   IP address and a transport layer identifier such as a TCP/UDP port 
   (and the related IP, TCP/UDP checksums) are  altered. 
   
   The term NAT in this document is very similar to the IPv4 NAT
   described in [NAT-TERM], but is extended beyond IPv4 networks
   to include the IPv4-v6 NAT-PT described in [NAT-PT]. While the
   IPv4 NAT [NAT-TERM] translates one IPv4 address into another IPv4 
   address to  provide routing between private V4 and external V4 
   address realms, IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address 
   into an IPv6 address and vice versa to provide routing between a 
   V6 address realm and an external V4 address realm.

   Unless specified otherwise, NAT in this document is a middlebox 
   function referring to both IPv4 NAT as well as IPv4-v6 NAT-PT.

2.5. Proxy

   A proxy is an intermediate relay agent between clients and servers 
   of an application, relaying application messages between the two. 



Srisuresh et al.                                                [Page 4]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   Proxies use special protocol mechanisms to communicate with proxy 
   clients and relay client data to servers and vice versa. A Proxy 
   terminates sessions with both the client and the server, acting as
   server to the end-host client and as client to the end-host server. 

   Applications such as FTP, SIP and RTSP use a control connection to
   establish data sessions. These control and data sessions can take
   divergent paths. While a proxy can intercept both the control and
   data connections, it might intercept only the control connection.
   This is often the case with real-time streaming applications such
   as SIP and RTSP. 

2.6. ALG

   Application Level Gateways (ALGs) are agents that possess the 
   application specific intelligence and knowledge of an associated
   middlebox function. An ALG examines application traffic in transit 
   and assists middlebox in carrying out its function.
 
   An ALG may be co-resident with a middlebox or reside externally, 
   communicating through a middlebox communication protocol. It 
   interacts with a middlebox to set up state, access control 
   filters, use middlebox state information, modify application 
   specific payload or perform whatever else is necessary to enable
   the application to run through the middlebox.

   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. ALGs do not terminate session with
   either end-host. Instead, ALGs examine and optionally modify
   application payload content to facilitate the flow of application
   traffic through a middlebox. ALGs are middlebox centric, in that
   they assist the middleboxes in carrying out their function. 
   Whereas, the proxies act as focal point for application servers, 
   relaying traffic between application clients and servers.

   ALGs are similar to Proxies, in that, both ALGs and proxies 
   facilitate Application specific communication between clients
   and servers. 

2.7. End-Hosts

   End-hosts are entities that are party to a networked application
   instance. End-hosts referred in this document are specifically 
   those terminating Real-time streaming Voice-over-IP 
   applications such as SIP and H.323 and peer-to-peer applications 
   such as Napster and NetMeeting. 




Srisuresh et al.                                                [Page 5]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


2.8. MIDCOM Agents

   MIDCOM agents are entities performing ALG function, logically 
   external to a middlebox. MIDCOM agents possess a combination of 
   application awareness and knowledge of the middlebox function.
   A MIDCOM agent may communicate with one or more middleboxes.
   
   Only the MIDCOM agents, located in-Path of an application 
   instance will be considered in this document. These are also
   refered as "In-Path MIDCOM agents". 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. This may be an application
   proxy, gateway, or in the extreme case, one of the end-hosts, 
   that is party to the application. 

   Agents not resident on entities that are natively in the path of
   application flows, refered as Out-of-Path (OOP) agents, will be 
   considered out of scope for this document. As such, there will
   be no further discussion on OOP agents in the reminder of this 
   document.

2.9. Policy Server

   Policy Server is a management entity that acts in advisory
   capacity and interfaces with a middlebox to communicate policies
   concerning authorization of MIDCOM agents gaining access to
   middlebox resources. A MIDCOM agent may be pre-configured on a
   middlebox. In case a MIDCOM agent is not pre-configured, the
   middlebox will consult the Policy Server and obtain the agent
   profile to validate connection setup and authorization of the
   agent to gain access to middlebox resources. A middlebox and
   a policy server may communicate further if the policy server's
   policy  changes or if a middlebox needs further information.
   The policy server may at anytime notify the middlebox to
   terminate authorization for an agent.

   The protocol facilitating the communication between a middlebox
   and Policy Server need not be part of MIDCOM protocol. Section 6
   in the document addresses the Policy server interface and protocol
   framework independent of the MIDCOM framework.

   Application specific policy data and policy interface between an
   agent or application endpoint and a policy server is out of bounds
   for this document. The Policy server issues addressed in the
   document are focused at an aggregate domain level as befitting
   the middlebox. For example, a SIP midcom agent may choose to query
   a policy server for the administrative (or corporate) domain to



Srisuresh et al.                                                [Page 6]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   find whether a certain user is allowed to make an outgoing call.
   This type of application specific policy data, as befitting an end
   user is out of bounds for the Policy server considered in this
   document. It is within bounds however for the middlebox policy
   server to specify the specific end-user applications (or tuples)
   for which an agent is permitted to be an ALG.

2.10. Middlebox Communication (MIDCOM) protocol

   The protocol between a MIDCOM agent and a middlebox that allows
   the MIDCOM agent to gain access to middlebox resources and
   allows the middlebox to delegate application specific processing
   to MIDCOM agent. The MIDCOM protocol allows the middlebox to
   perform its operation with the aid of MIDCOM agents, without 
   resorting to embedding application intelligence. The principal 
   motivation behind architecting this protocol is to enable complex
   applications through middleboxes seamlessly using a trusted third
   party, i.e., a MIDCOM agent.

   This is a protocol yet to be devised. 


3.0 Architectural framework for Middleboxes

   A middlebox may implement one or more of the middlebox functions   
   selectively on multiple interfaces of the device. There can be a 
   variety of MIDCOM agents interfacing with the middlebox to
   communicate with one or more of the middlebox functions on an 
   interface. As such, the Middlebox communication protocol MUST 
   allow for selective communication between a specific MIDCOM agent
   and one or more middlebox functions on the interface. The following 
   diagram identifies a possible layering of the service supported
   by a middlebox and a list of MIDCOM agents that might interact
   with it. 

















Srisuresh et al.                                                [Page 7]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


             +---------------+  +--------------+  
             | MIDCOM agent  |  | MIDCOM agent | 
             | co-resident on|  | co-resident  |  
             | Proxy Server  |  | on Appl. GW  | 
             +---------------+  +--------------+  
                        ^           ^             
                        |           |                     +--------+
               MIDCOM   |           |                     | Policy |
               Protocol |           |                   +-| Server |
                        |           |                  /  +--------+
   +-------------+      |           |                 /  
   | MIDCOM agent|      |           |                /    
   | co-resident |      |           |               /  
   | on End-hosts|<-+   |           |              / 
   +-------------+  |   |           |              |  
                    v   v           v              v 
              +-------------------------------------------+
              |  Middlebox Communication      |Policy     |
              |  Protocol (MIDCOM) Interface  |Interface  |
              +----------+--------+-----------+-----------+
   Middlebox  |          |        |           |           |
   Functions  | Firewall |  NAT   |   VPN     | Intrusion |
              |          |        | tunneling | Detection |
              +----------+--------+-----------+-----------+
   Middlebox  | Firewall ACLs, Session-descriptors,       |
   Managed    | NAT-BINDs, NAT Address-Maps and other     | 
   Resources  | Middlebox function specific attributes    |
              +-------------------------------------------+

     Figure 1: MIDCOM agents interfacing with a middlebox       
       

   Firewall ACLs, NAT-BINDs, NAT address-maps and Session-state
   are a few of the middlebox managed resources. A session may
   be uniquely described by the tuple of (SessionDirection,
   SourceAddress, DestinationAddress, Protocol, SourcePort,
   DestinationPort). All parameters of the tuple, including
   SessionDirection, are with reference to an interface on the
   middlebox. An aggregated Session-state may have one or
   more of the tuple elements denoted by a regular expression
   (ex: Any source port). A session state will include attributes
   specific to the individual middlebox function, in addition to 
   the session identifying tuple. The service specific attributes
   include a variety of timers, NAT translation parameters and 
   so forth. As Session-state may be shared across middlebox
   functions, a Session-state may be created by a function, and
   terminated by a different function. For example, a
   session-state may be created by the firewall function, but



Srisuresh et al.                                                [Page 8]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   terminated by the NAT function, when a session timer expires. 
      
   A middlebox may also have function specific resources such as 
   Address maps and Address binds to enforce NAT function and 
   application based policies to enforce firewall function.
   Application specific MIDCOM agents (co-resident on the middlebox
   or external to the middlebox) would examine the IP datagrams and
   help identify the application the datagram belongs to and assist
   the middlebox in performing functions unique to the application
   and the middlebox service. For example, a MIDCOM agent assisting
   a NAT middlebox might perform payload translations; whereas a 
   MIDCOM agent assisting a firewall middlebox might request the
   firewall to permit access to application specific dynamically
   generated session traffic. 


4. MIDCOM Protocol

   The MIDCOM protocol between a MIDCOM agent and a middlebox allows
   the MIDCOM agent to gain access to middlebox resources and
   allows the middlebox to delegate application specific processing
   to MIDCOM agent. The protocol will allow MIDCOM agents to signal
   the middleboxes to let complex applications using dynamic port 
   based sessions through them (i.e., middleboxes) seamlessly. 
   
   It is important to note that an agent and a middlebox can be on
   the same physical device. In such a case, they may communicate
   using a MIDCOM protocol message formats, but using a non-IP based
   transport such as IPC messaging (or) they may communicate using a 
   well-defined API/DLL (or) the application intelligence is fully
   embedded into the middlebox service (as it is done today in many
   stateful inspection firewall devices and NAT devices). 

   The MIDCOM protocol will consist of a connection setup phase, 
   run-time connection phase and a connection termination phase. 

   Connection setup must be preceded by registration of the
   MIDCOM agent with either the middlebox or the Policy Server.
   The MIDCOM agent access and authorization profile may either
   be pre-configured on the middlebox (or) listed on a Policy
   Server the middlebox is configured to consult. MIDCOM is a
   peer-to-peer protocol. As such, either the agent or the
   middlebox may choose to initiate the connection.  

   A MIDCOM session may be terminated by either of the parties.
   A MIDCOM session termination may also be triggered by one of 
   (a) the middlebox or the agent going out of service and not
   being available for further MIDCOM operations, or (b) policy



Srisuresh et al.                                                [Page 9]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   server notifying the middlebox that a particular MIDCOM agent
   is no longer authorized.

   The MIDCOM protocol data exchanged during run-time is governed 
   principally by the middlebox services the protocol supports.
   Firewall and NAT middlebox services are considered in this
   document. Nonetheless, the MIDCOM framework is designed to
   be extensible to support deployment of other services as well.
 

5.0. MIDCOM Agents

   MIDCOM agents are logical entities which may reside physically
   on nodes external to a middlebox, possessing a combination of 
   application awareness and knowledge of middlebox function. A 
   MIDCOM agent may communicate with one or more middleboxes. The
   issues of middleboxes discovering agents or vice versa are
   outside the scope of this document. The focus of the document
   is the framework in which a MIDCOM agent communicates with a
   middlebox using MIDCOM protocol, which is yet to be devised.
   Specifically, the focus is restricted to just the In-Path agents.

   In-Path MIDCOM agents are MIDCOM agents that are located naturally
   within the message path of the application(s) they are associated
   with. Bundled session applications such as H.323, SIP and RTSP
   which have separate control and data sessions may have their 
   sessions take divergent paths. In those scenarios, In-Path MIDCOM
   agents are those that find themselves in the control path. 
   In majority of cases, a middlebox will likely require the 
   assistance of a single agent for an application in the control 
   path alone. However, it is possible that a middlebox function
   or a specific application traversing the middlebox might require
   the intervention of more than a single MIDCOM agent for the same
   application, one for each sub-session of the application.

   Application Proxies and gateways are a good choice for In-Path 
   MIDCOM agents, as these entities, by definition, are in the path
   of an application between a client and server. In addition to
   hosting the MIDCOM agent function, these natively in-path 
   application specific entities may also enforce 
   application-specific choices locally, such as dropping messages
   infected with known viruses, or lacking user authentication.
   These entities can be interjecting both the control and data
   connections. For example, FTP control and Data sessions are
   interjected by an FTP proxy server. However, proxies may also be
   interjecting just the control connection and not the data
   connections, as is the case with real-time streaming applications
   such as SIP and RTSP. Note, applications may not always traverse



Srisuresh et al.                                               [Page 10]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   a proxy and some applications may not have a proxy server
   available. 

   SIP proxies and H.323 gatekeepers may be used to host MIDCOM
   agent function to control middleboxes implementing firewall and
   NAT functions. The advantage of using in-path entities as opposed
   to creating an entirely new agent is that the in-path entities
   already possess application intelligence. You will need to merely
   enable the use of MIDCOM protocol to be an effective MIDCOM
   agent. Figure 2 below illustrates a scenario where the in-path 
   MIDCOM agents interface with the middlebox. Let us say, the 
   policy Server has pre-configured the in-path proxies as trusted
   MIDCOM agents on the middlebox and the packet filter 
   implements 'default-deny' packet filtering policy. Proxies use 
   their application-awareness knowledge to control the firewall 
   function and selectively permit a certain number of voice stream
   sessions dynamically using MIDCOM protocol. 

   In the illustration below, the proxies and the policy server are
   shown inside a private domain. The intent however is not to imply
   that they be inside the private boundary alone. The proxies may
   also reside external to the domain. The only requirement is that
   there be a trust relationship with the middlebox.




























Srisuresh et al.                                               [Page 11]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


                           +-----------+
                           | Middlebox |
                           | Policy    |
                           | Server    |~~~~~~~~~~~~~|
                           +-----------+              \
                                                       \
                    +--------+                          \        
                    | SIP    |___                        \    
            ________| Proxy  |   \            Middlebox   \
           /        +--------+..  |        +--------------------+
          |                    :  | MIDCOM |           |        |
          |  RTSP +---------+  :..|........| MIDCOM    | POLICY |
      SIP |   ____|  RTSP   |.....|........| PROTOCOL  | INTER- |
          |  /    |  Proxy  |___  |        | INTERFACE | FACE   |
          | |     +---------+   \  \       |--------------------|
          | |                     \  \-----|                    |
          | |                      \-------|                    |
          | |                           ---|     FIREWALL       |-->--
         +-----------+                 /---|                    |--<--
        +-----------+|  Data streams  //   +--------------------+
       +-----------+||---------->----//            |
       |end-hosts  ||-----------<-----             .
       +-----------+   (RTP, RTSP data, etc.)      |  
                                                   .  Outside the
              Within a private domain              |  private domain
                                                   
       Legend: ---- Application data path datagrams
               ____ Application control path datagrams
               .... Middlebox Communication Protocol (MIDCOM)
               ~~~~ MIDCOM Policy Server Interface
                 |
                 .  private domain Boundary
                 |
             

       Figure 2: In-Path MIDCOM Agents for Middlebox Communication



5.1. End-hosts as In-Path MIDCOM agents

   End-hosts are another variation of In-Path MIDCOM agents. Unlike 
   Proxies, End-hosts are direct party to the application and 
   possess all the end-to-end application intelligence there is to
   it. End-hosts presumably terminate both the control and data
   paths of an application. Unlike other entities hosting MIDCOM
   agents, end-host is able to process secure datagrams. However,
   the problem would be one of manageability - upgrading all the



Srisuresh et al.                                               [Page 12]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   end-hosts running a specific application.


6.0. Policy Server functions

   The functional decomposition of the MIDCOM architecture assumes
   the existence of a logical entity known as Policy Server, 
   responsible for performing authorization and related provisioning
   services for the middlebox as depicted in figure 1. The Policy
   server is a logical entity which may reside physically on a
   middlebox or on a node external to the middlebox. The protocol
   employed for communication between the middlebox and the policy
   server is unrelated to the MIDCOM protocol.

   Agents are registered with a Policy Server for authorization to
   gain access to a middlebox. The policy server maintains a list of
   agents that are authorized to connect to each of the middleboxes the
   policy server supports. The Policy server is not intended to assist
   middlebox in the implementation of the services it provides or
   with resource authorization on the middlebox.

   The policy server acts in an advisory capacity to a middlebox to
   authorize or terminate authorization for an agent to gain 
   connectivity to the middlebox. The primary objective of a policy
   server is to communicate agent authorization information so as to
   ensure that the security and integrity of a middlebox is not
   jeopardized. Specifically, the policy server should associate a
   trust level with each agent attempting to connect to a middlebox
   and provide a security profile. The policy server should be capable
   of addressing cases when end-hosts are agents to the middlebox.

6.1. Authentication, Integrity and Confidentiality

   Host authenticity and individual message security are two distinct
   types of security considerations. Host authentication refers to
   credentials required of a MIDCOM agent to authenticate itself to
   the middlebox and vice versa. When authentication fails, the
   middlebox MUST not process signaling requests received from the
   agent that failed authentication. Two-way authentication should be
   supported. In some cases, the 2-way authentication may be tightly
   linked to the establishment of keys to protect subsequent traffic. 
   Two-way authentication is often required to prevent various active
   attacks on the MIDCOM protocol and secure establishment of keying
   material.

   Security services such as authentication, data integrity,
   confidentiality and replay protection may be adapted to secure
   MIDCOM messages in an untrusted domain. Message authentication is



Srisuresh et al.                                               [Page 13]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   same as data origin authentication and is an affirmation that the
   sender of the message is who it claims to be. Data integrity
   refers to the ability to ensure that a message has not been
   accidentally, maliciously or otherwise altered or destroyed.
   Confidentiality is encryption of message with a key so that only
   those in possession of the key can decipher the message content.
   Lastly, replay protection is a form of sequence integrity so when
   an intruder plays back a previously recorded sequence of messages,
   the receiver of the replay messages will simply drop the replay
   messages into bit-bucket. Certain applications of the MIDCOM
   protocol might require support for non-repudiation as an option of
   the data integrity service. Typically, support for non-repudiation
   is required for billing, service level agreements, payment orders,
   and receipts for delivery of service. 
   
   IPsec AH ([IPSEC-AH]) offers data-origin authentication, data 
   integrity and protection from message replay. IPsec ESP 
   ([IPSEC-ESP]) provides data-origin authentication to a lesser
   degree (same as IPsec AH if the MIDCOM transport protocol turns out
   to be TCP or UDP), message confidentiality, data integrity and
   protection from replay. Besides the IPsec based protocols, there
   are other security options as well. TLS based transport layer
   security is one option. There are also many application-layer 
   security mechanisms available. Simple Source-address based
   security is a minimal form of security and should be relied on only
   in the most trusted environments where those hosts will not be
   spoofed.

   MIDCOM message security shall use existing standards, whenever the
   existing standards satisfy the requirements. Security shall be
   specified to minimize the impact on connections that do not use the
   security option. Security should be designed to avoid introducing
   and to minimize the impact of denial of service attacks. Some
   security mechanisms and algorithms require substantial processing
   or storage, in which case the security protocols should protect
   themselves as well as against possible flooding attacks that
   overwhelm the endpoint (i.e., the middlebox or the agent) with
   such processing. For connection oriented protocols (such as TCP)
   using security services, the security protocol should detect
   premature closure or truncation attacks.


6.2. Registration and deregistration of MIDCOM agents

   Prior to giving MIDCOM agents access to the middlebox resources,
   a registration process MUST take place. Registration is a
   different process than establishing a transport connection.
   The former requires exchanging agent profile information with



Srisuresh et al.                                               [Page 14]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   the middlebox or a policy server(s). Agent registration is often
   a manual operation performed by an opertor rather than the agent
   itself. The latter refers to establishing a MIDCOM transport
   connection and exchanging security credentials between an agent
   and a middlebox. The latter uses the information from the former
   for connection establishment.

   Profile of a MIDCOM agent includes agent authorization policy (i.e, 
   session tuples for which the agent is authorized to act as ALG),
   agent-hosting-entity (e.g., Proxy, Gateway or end-host which hosts
   the agent), agent accessibility profile (including any host level
   authentication information) and security profile (i.e., security
   requirements for messages exchanged between the middlebox and the
   agent). 

   MIDCOM agent profile may be pre-configured on the middlebox while
   provisioning the middlebox function. Either the agent or the
   middlebox can choose to initiate a connection prior to any data
   traffic. Alternately, either party (middlebox or the MIDCOM agent)
   may choose to initiate a connection only upon noticing the
   application specific traffic. 

   Coupling MIDCOM agents with the middlebox resources requires
   a means of reflecting that into the resource description table
   of the middlebox. In the case of a firewall, for example, the 
   ACL tuple may be altered to reflect the optional ALG presence.
   The revised ACL may look something like the following.   

   (<Session-Direction>, <Source-Address>, <Destination-Address>, 
   <IP-Protocol>, <Source-Port>, <Destination-Port>, <ALG>)
    
   The reader should note that this is an illustrative example and
   not necessarily the actual definition of an ACL tuple. The formal
   description of the ACL is yet to be devised. Agent accessibility
   information should also be provisioned. For a  MIDCOM agent,
   accessibility information includes the IP address, trust level,
   host authentication parameters and message authentication
   parameters. Once a connection is established between a middlebox
   and a MIDCOM agent, that connection should be usable with multiple
   instances of the application(s), as appropriate. Note, all of this
   could be captured in an agent profile for ease of management.

   The technique described above is necessary for the pre-registration
   of MIDCOM agents with the middlebox. However, it is possible to
   retain the provisioning on middlebox unchanged, by requiring MIDCOM
   agents to initiate the connection to middlebox. In such a case, the
   agent should initiate the connection prior to the start of the
   application.  If the agent connection is delayed until after the



Srisuresh et al.                                               [Page 15]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   application has started, the agent might be unable to process the
   control stream to permit the data connections. When Middlebox notices
   an incoming MIDCOM connection, and the middlebox has no prior profile
   of the MIDCOM agent, the middlebox will consult its Policy Server for
   authenticity, authorization and trust guidelines for the connection.
  
   At the end of the MIDCOM session, it should be possible for either
   the middlebox or the agent to disconnect. MIDCOM session 
   disconnection may be prompted by a successful termination or 
   failure of some sort.
 
   It should be possible for the agent to disconnect itself from the 
   middlebox, which means that the agent is going out of service and 
   will not be available for further MIDCOM operations. Alternately,
   a policy server may notify a middlebox that a particular MIDCOM 
   agent is no longer authorized for a particular set of sessions 
   any longer. Note, Policy Server notifying the middlebox is one of 
   many ways by which a middlebox could disconnect an agent.


7.0. MIDCOM Framework Illustration using an In-Path agent

   In figure 3 below, we consider SIP application (Refer [SIP]) to 
   illustrate the operation of MIDCOM protocol. Specifically, the 
   application assumes a caller, external to a private domain,
   initiates the call. Middlebox is assumed to be located at the 
   edge of the private domain. A SIP phone (SIP User Agent 
   Client/Server) inside the private domain is capable of receiving
   calls from external SIP phones. The caller uses a SIP Proxy
   node, located external to the private domain, as its outbound 
   proxy. No interior proxy is assumed for the callee. Lastly, the 
   external SIP proxy node is designated to host the MIDCOM agent 
   function. 

   Arrows 1 and 4 in the figure below refer to SIP call setup
   exchange between the external SIP phone and the SIP proxy.
   Arrows 6 and 7 refer to SIP call setup exchange between the SIP
   proxy and the interior SIP phone and are assumed to be 
   traversing the middlebox. Arrows 2 and 3 below between the SIP
   proxy and the middlebox refer to MIDCOM communication. Na and Nb
   represent RTP/RTCP media traffic (Refer [RTP]) path in the
   external network. Nc and Nd represent media traffic inside the
   private domain. 








Srisuresh et al.                                               [Page 16]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


                          _________
                     --->|   SIP   |<-----\
                    /    |  Proxy  |       \
                   |     |_________|       |
                  1|       |     |        6|
                   |       |     |         |
                   |4      |2    |3        |7
   ______________  |       |     |         |    _____________
   |            |<-/      _v_____^___       \->|            |
   | External   |    Na   |           |   Nc   | SIP Phone  |
   | SIP phone  |>------->| MiddleBox |>------>| within     |
   |            |<-------<|___________|<------<| Pvt. domain|
   |____________|    Nb                   Nd   |____________|

   Figure 3: MIDCOM framework illustration with In-Path SIP Proxy


   As for the SIP application, we make the assumption that the 
   middlebox is pre-configured to accept SIP calls into the 
   private SIP phone. Specifically, this would imply that the 
   middlebox implementing firewall service is pre-configured to 
   permit SIP calls (destination TCP or UDP port number set to 
   5060) into the private phone. Likewise, middlebox implementing
   NAPT service would have been pre-configured to provide a port
   binding to permit incoming SIP calls to be redirected to the 
   specific private SIP phone. I.e., the INVITE from the external
   caller is not made to the private IP address, but to the NAPT 
   external address. 

   The objective of the MIDCOM agent in the following illustration
   is to merely permit the RTP/RTCP media stream (Refer [RTP])
   through the middlebox, when using the MIDCOM protocol architecture
   outlined in the document. RTP/RTCP media stream, When used in
   conjunction with SIP will typically result in two independent
   media sessions - one from the callee to the caller and another
   from the caller to the callee. These media sessions are UDP based
   and will use dynamic ports. The dynamic ports used for the media
   stream are specified in the SDP section (Refer [SDP]) of SIP
   payload message. The MIDCOM agent will parse the SDP section and
   use the MIDCOM protocol to (a) open pinholes (i.e., permit RTP/RTCP
   session tuples) in a middlebox implementing firewall service, or 
   (b) create PORT bindings and appropriately modify the SDP content to
   permit the RTP/RTCP streams through a middlebox implementing NAT 
   service. The MIDCOM protocol should be sufficiently rich and 
   expressive to support the operations described under the timelines.
   The examples do not show the timers maintained by the agent to 
   keep the firewall pinholes and NAT session descriptors and BINDs
   from timing out.



Srisuresh et al.                                               [Page 17]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001



   Midcom agent Registration and connectivity between the Midcom
   agent and the middlebox are not shown in the interest of
   restricting the focus of the MIDCOM transactions to enabling the
   middlebox to let the media stream through. Policy server is also
   not shown in the diagram below or on the timelines for the same
   reason. 

   The following subsections illustrate a typical timeline sequence
   of operations that transpire with the various elements involved
   in a SIP telephony application path. Each subsection is devoted
   to a specific instantiation of a middlebox service - NAPT 
   (refer [NAT-TERM], [NAT-TRAD]), firewall and a combination of 
   both NAPT and firewall are considered. 

7.1. Timeline flow - Middlebox implementing firewall service

   In the following example, we will assume a middlebox implementing
   a firewall service. We further assume that the middlebox is
   pre-configured to permit SIP calls (destination TCP or UDP port
   number set to 5060) into the private phone. The following timeline
   illustrates the operations performed by the MIDCOM agent to permit
   RTP/RTCP media stream through the middlebox. 

   The INVITE from the caller (external) is assumed to include the
   SDP payload. You will note that the In-Path agent requests
   the middlebox to permit the Private-to-external RTP/RTCP flows
   before the INVITE is relayed to the callee. This is because,
   in SIP, the calling party must be ready to receive the media when
   it sends the INVITE with a session description. If the called
   party (private phone) assumes this and sends "early media" before
   sending the 200 OK response, the firewall will have blocked these
   packets without this initial MIDCOM signaling from the agent.


   SIP Phone      SIP Proxy              Middlebox      SIP Phone
   (External)     (In-Path               (FIREWALL      (private)
                  MIDCOM agent)          Service)          |     
   |                 |                      |              |
   |----INVITE------>|                      |              |
   |                 |                      |              |
   |              Identify end-2-end        |              |
   |              parameters (from Caller's |              |
   |              SDP) for the pri-to-Ext   |              |
   |              RTP & RTCP sessions.      |              |
   |              (RTP1, RTCP1)             |              |
   |                 |                      |              |
   |                 |+Permit RTP1, RTCP1 +>|              |



Srisuresh et al.                                               [Page 18]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   |                 |<+RTP1, RTCP1 OKed++++|              |
   |                 |                      |              |
   |                 |--------INVITE---------------------->|
   |<---100Trying----|                      |              |
   |                 |                      |              |
   |                 |<-----180 Ringing--------------------|
   |<--180Ringing----|                      |              |
   |                 |<-------200 OK-----------------------|
   |                 |                      |              |
   |              Identify end-2-end        |              |
   |              parameters (from callee's  |              |
   |              SDP) for the Ext-to-Pri   |              |
   |              RTP and RTCP sessions.    |              |
   |              (RTP2, RTCP2)             |              |
   |                 |                      |              |
   |                 |+Permit RTP2, RTCP2 +>|              |
   |                 |<+RTP2, RTCP2 OKed++++|              |
   |                 |                      |              |
   |<---200 OK ------|                      |              |
   |-------ACK------>|                      |              |
   |                 |-----------ACK---------------------->|
   |                 |                      |              |
   |<===================RTP/RTCP==========================>|
   |                 |                      |              |
   |-------BYE------>|                      |              |
   |                 |--------------------------BYE------->|
   |                 |                      |              |
   |                 |<----------200 OK--------------------|
   |                 |                      |              |
   |                 |++Cancel permits to   |              |
   |                 |  RTP1, RTCP1, RTP2,  |              |
   |                 |  and RTCP2 +++++++++>|              |
   |                 |<+RTP1, RTP2, RTCP1 & |              |
   |                 |  RTCP2 cancelled ++++|              |
   |                 |                      |              |
   |<---200 OK-------|                      |              |
   |                 |                      |              |

      Legend:      ++++    MIDCOM control traffic
                   ----    SIP control traffic
                   ====    RTP/RTCP media traffic


7.2. Timeline flow - Middlebox implementing NAPT service

   In the following example, we will assume a middlebox implementing
   NAPT service. We make the assumption that the middlebox is
   pre-configured to redirect SIP calls to the specific private SIP



Srisuresh et al.                                               [Page 19]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   phone application. I.e., the INVITE from the external caller is
   not made to the private IP address, but to the NAPT external
   address. Let us say, the external phone's IP address is Ea, NAPT
   middlebox external Address is Ma and the internal SIP phone's
   private address is Pa. SIP calls to the private SIP phone will
   arrive as TCP/UDP sessions with destination address and port set
   to Ma and 5060 respectively. The middlebox will redirect these
   datagrams to the internal SIP phone. The following  timeline
   will illustrate the operations necessary to be performed by the
   MIDCOM agent to permit the RTP/RTCP media stream through the
   middlebox. 

   As with the previous example (section 7.1), INVITE from the
   caller (external) is assumed to include the SDP payload.
   You will note that the In-Path agent requests middlebox to create
   NAT session descriptors for the private-to-external RTP/RTCP flows
   before the INVITE is relayed to the private SIP phone (for the
   same reasons as described in section 7.1). If the called party
   (private phone) sends "early media" before sending the 200 OK
   response, the NAPT middlebox will have blocked these packets
   without the initial MIDCOM signaling from the agent. Also, note
   that after the 200 OK is received by the proxy from the private
   phone, the agent requests the middlebox to allocate NAT session
   descriptors for the external-to-private RTP2 and RTCP2 flows, such
   that the ports assigned on the Ma for RTP2 and RTCP2 are
   contiguous. RTCP stream does not happen with a non-contiguous
   port. Lastly, you will note that even though each media stream
   (RTP1, RTCP1, RTP2 and RTCP2) is independent, they are all tied to
   the single SIP control session while theit NAT session descriptors
   were being created. Finally, when the agent issues a terminate
   session bundle command for the SIP session, the middlebox is
   assumed to delete all associated media stream sessions
   automagically. 


















Srisuresh et al.                                               [Page 20]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   SIP Phone      SIP Proxy              Middlebox     SIP Phone
   (External)     (In-Path               (NAPT         (Private)
   IP Addr:Ea     MIDCOM agent)          Service)      IP addr:Pa
   |                 |                   IP addr:Ma        |
   |                 |                      |              |
   |----INVITE------>|                      |              |
   |                 |++ Query Port-BIND    |              |
   |                 |   for (Ma, 5060) +++>|              |
   |                 |<+ Port-BIND reply    |              |
   |                 |   for (Ma, 5060) ++++|              |
   |                 |                      |              |
   |                 |++ Query NAT Session  |              |
   |                 |   Descriptor for     |              |
   |                 |   Ea-to-Pa SIP flow+>|              |
   |                 |<+ Ea-to-Pa SIP flow  |              |
   |                 |   Session Descriptor+|              |
   |                 |                      |              |
   |              Determine the Internal    |              |
   |              IP address (Pa)           |              |
   |              of the callee.            |              |
   |                 |                      |              |
   |              Identify UDP port numbers |              |
   |              on Ea (Eport1, Eport1+1)  |              |
   |              for pri-to-ext RTP & RTCP |              |
   |              sessions (RTP1, RTCP1)    |              |
   |                 |                      |              |
   |                 |++Create NAT Session  |              |
   |                 |  descriptors for     |              |
   |                 |  RTP1, RTCP1; Set    |              |
   |                 |  parent session to   |              |
   |                 |  SIP-ctrl session ++>|              |
   |                 |<+RTP1, RTCP1 session |              |
   |                 |  descriptors created+|              |
   |                 |                      |              |
   |                 |                      |..redirected..|
   |                 |--------INVITE--------|------------->|
   |<---100Trying----|                      |              |
   |                 |                      |              |
   |                 |<-----180Ringing---------------------|
   |                 |                      |              |
   |<--180Ringing----|                      |              |
   |                 |<-------200 OK-----------------------|
   |                 |                      |              |
   |              Identify UDP port numbers |              |
   |              on Pa (Pport2, Pport2+1)  |              |
   |              for ext-to-pri RTP & RTCP |              |
   |              sessions (RTP2, RTCP2)    |              |
   |                 |                      |              |



Srisuresh et al.                                               [Page 21]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   |                 |++Create consecutive  |              |
   |                 |  port BINDs on Ma    |              |
   |                 |  for (Pa, Pport2),   |              |
   |                 |  (Pa, Pport2+1) ++++>|              |
   |                 |<+Port BINDs created++|              |
   |                 |                      |              |
   |                 |++Create NAT Session  |              |
   |                 |  descriptors for     |              |
   |                 |  RTP2, RTCP2; Set    |              |
   |                 |  parent session to   |              |
   |                 |  SIP-ctrl session ++>|              |
   |                 |<+RTP2, RTCP2 session |              |
   |                 |  descriptors created+|              |
   |                 |                      |              |
   |              Modify the SDP            |              |
   |              parameters in "200 OK"    |              |
   |              with NAPT PORT-BIND       |              |
   |              for the RTP2 port on Ma.  |              |
   |                 |                      |              |
   |<---200 OK ------|                      |              |
   |                 |                      |              |
   |-------ACK------>|                      |              |
   |                 |                      |              |
   |              Modify IP addresses       |              |
   |              appropriately in the SIP  |              |
   |              header (e.g., To, from,   |              |
   |              Via, contact fields)      |              |
   |                 |                      |..redirected..|
   |                 |-----------ACK--------|------------->|
   |                 |                      |              |
   |                 |                      |              |
   |<===================RTP/RTCP============|=============>|
   |                 |                      |              |
   |-------BYE------>|                      |              |
   |                 |                      |              |
   |              Modify IP addresses       |              |
   |              appropriately in the      |              |
   |              SIP header.               |              |
   |                 |                      |              |
   |                 |----------------------|-----BYE----->|
   |                 |                      |              |
   |                 |<----------200 OK--------------------|
   |                 |                      |              |
   |                 |+++Terminate the SIP  |              |
   |                 |   Session bundle +++>|              |
   |                 |<++SIP Session bundle |              |
   |                 |   terminated ++++++++|              |
   |                 |                      |              |



Srisuresh et al.                                               [Page 22]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   |              Modify SDP                |              |
   |              parameters in "200 OK"    |              |
   |                 |                      |              |
   |<---200 OK-------|                      |              |
   |                 |                      |              |


      Legend:      ++++    MIDCOM control traffic
                   ----    SIP control traffic
                   ====    RTP/RTCP media traffic


7.3. Timeline flow - Middlebox implementing NAPT and firewall


   In the following example, we will assume a middlebox 
   implementing a combination of a firewall and a stateful NAPT
   service. We make the assumption that the NAPT function is
   configured to translate the IP and TCP headers of the initial
   SIP session into the private SIP phone and the firewall 
   function is configured to permit the initial SIP session. 

   In the following time line, it may be noted that the firewall
   description is based on packet fields on the wire (ex: as seen
   on the external interface of the middlebox).  In order to 
   ensure correct behavior of the individual services, you will 
   notice that NAT specific MIDCOM operations precede firewall 
   specific operations on the MIDCOM agent. This is noticeable in
   the time line below when the MIDCOM agent processes the 
   "200 OK" from the private SIP phone. The MIDCOM agent initially
   requests the NAT service on the middlebox to set up port-BIND
   and session-descriptors for the media stream in both directions.
   Subsequent to that, the MIDCOM agent determines the session 
   parameters (i.e, the dynamic UDP ports) for the media stream, 
   as viewed by the external interface and requests the firewall
   service on the middlebox to permit those sessions through.
   
 

   SIP Phone      SIP Proxy              Middlebox     SIP Phone
   (External)     (In-Path               (NAPT &       (Private)
   IP Addr:Ea     MIDCOM agent)          firewall      IP addr:Pa
   |                 |                   Services)         |
   |                 |                   IP addr:Ma        |
   |                 |                      |              |
   |----INVITE------>|                      |              |
   |                 |++ Query Port-BIND    |              |
   |                 |   for (Ma, 5060) +++>|              |



Srisuresh et al.                                               [Page 23]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   |                 |<+ Port-BIND reply    |              |
   |                 |   for (Ma, 5060) ++++|              |
   |                 |                      |              |
   |                 |++ Query NAT Session  |              |
   |                 |   Descriptor for     |              |
   |                 |   Ea-to-Pa SIP flow+>|              |
   |                 |<+ Ea-to-Pa SIP flow  |              |
   |                 |   Session Descriptor+|              |
   |                 |                      |              |
   |              Determine the Internal    |              |
   |              IP address (Pa)           |              |
   |              of the callee.            |              |
   |                 |                      |              |
   |              Identify UDP port numbers |              |
   |              on Ea (Eport1, Eport1+1)  |              |
   |              for pri-to-ext RTP & RTCP |              |
   |              sessions (RTP1, RTCP1)    |              |
   |                 |                      |              |
   |                 |++Create NAT Session  |              |
   |                 |  descriptors for     |              |
   |                 |  RTP1, RTCP1; Set the|              |
   |                 |  parent session to   |              |
   |                 |  point to SIP flow++>|              |
   |                 |<+RTP1, RTCP1 session |              |
   |                 |  descriptors created+|              |
   |                 |                      |              |
   |                 |++Permit RTP1 & RTCP1 |              |
   |                 |  sessions External to|              |
   |                 |  middlebox, namely   |              |
   |                 |  Ma to Ea:Eport1,    |              |
   |                 |  Ma to Ea:Eport1+1   |              |
   |                 |  sessions ++++++++++>|              |
   |                 |<+Ma to Ea:Eport1,    |              |
   |                 |  Ma to Ea:Eport1+1   |              |
   |                 |  sessions OKed ++++++|              |
   |                 |                      |              |
   |                 |                      |..redirected..|
   |                 |--------INVITE--------|------------->|
   |<---100Trying----|                      |              |
   |                 |                      |              |
   |                 |<-----180Ringing---------------------|
   |                 |                      |              |
   |                 |                      |              |
   |<--180Ringing----|                      |              |
   |                 |<-------200 OK-----------------------|
   |                 |                      |              |
   |              Identify UDP port numbers |              |
   |              on Pa (Pport2, Pport2+1)  |              |



Srisuresh et al.                                               [Page 24]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   |              for ext-to-pri RTP & RTCP |              |
   |              sessions (RTP2, RTCP2)    |              |
   |                 |                      |              |
   |                 |++Create consecutive  |              |
   |                 |  port BINDs on Ma    |              |
   |                 |  for (Pa, Pport2),   |              |
   |                 |  (Pa, Pport2+1) ++++>|              |
   |                 |<+Port BINDs created  |              |
   |                 |  on Ma as (Mport2,   |              |
   |                 |  Mport2+1) ++++++++++|              |
   |                 |                      |              |
   |                 |++Create NAT Session  |              |
   |                 |  descriptors for     |              |
   |                 |  RTP2, RTCP2; Set the|              |
   |                 |  parent session to   |              |
   |                 |  point to SIP flow++>|              |
   |                 |<+RTP2, RTCP2 session |              |
   |                 |  descriptors created+|              |
   |                 |                      |              |
   |              Modify the SDP            |              |
   |              parameters in "200 OK"    |              |
   |              with NAPT PORT-BIND       |              |
   |              for RTP2 port on Ma.      |              |
   |                 |                      |              |
   |                 |++Permit RTP2 & RTCP2 |              |
   |                 |  sessions External   |              |
   |                 |  middlebox, namely   |              |
   |                 |  Ea to Ma:Mport2,    |              |
   |                 |  Ea to Ma:Mport2+1   |              |
   |                 |  sessions ++++++++++>|              |
   |                 |<+Ea to Ma:Mport2,    |              |
   |                 |  Ea to Ma:Mport2     |              |
   |                 |  sessions OKed ++++++|              |
   |                 |                      |              |
   |<---200 OK ------|                      |              |
   |                 |                      |              |
   |-------ACK------>|                      |              |
   |                 |                      |..redirected..|
   |                 |-----------ACK--------|------------->|
   |                 |                      |              |
   |                 |                      |              |
   |<===================RTP/RTCP============|=============>|
   |                 |                      |              |
   |-------BYE------>|                      |              |
   |                 |                      |              |
   |              Modify SDP payload        |              |
   |              parameters in BYE         |              |
   |                 |                      |              |



Srisuresh et al.                                               [Page 25]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   |                 |----------------------|-----BYE----->|
   |                 |                      |              |
   |                 |<----------200 OK--------------------|
   |                 |                      |              |
   |                 |+++Terminate the SIP  |              |
   |                 |   Session bundle +++>|              |
   |                 |<++SIP Session bundle |              |
   |                 |   terminated ++++++++|              |
   |                 |                      |              |
   |                 |++Cancel permits to   |              |
   |                 |  sessions External   |              |
   |                 |  middlebox, namely   |              |
   |                 |  Ma to Ea:Eport1,    |              |
   |                 |  Ma to Ea:Eport1+1   |              |
   |                 |  Ea to Ma:Mport2,    |              |
   |                 |  Ea to Ma:Mport2+1   |              |
   |                 |  sessions ++++++++++>|              |
   |                 |<+Removed permits to  |              |
   |                 |  sessions listed ++++|              |
   |                 |                      |              |
   |              Modify SDP                |              |
   |              parameters in "200 OK"    |              |
   |                 |                      |              |
   |<---200 OK-------|                      |              |
   |                 |                      |              |

      Legend:      ++++    MIDCOM control traffic
                   ----    SIP control traffic
                   ====    RTP/RTCP media traffic


8.0. Operational considerations 
   
8.1. Multiple MIDCOM connections between agents and middlebox 

   A middlebox cannot be assumed to be a simple device
   implementing just one middlebox function and no more than a 
   couple of interfaces. Middleboxes often combine multiple 
   intermediate functions into the same device and have the 
   ability to provision individual interfaces of the same device
   with different sets of functions and varied provisioning for
   the same function across the interfaces. 

   As such, a MIDCOM agent ought to be able to have a single 
   MIDCOM connection with a middlebox and use the MIDCOM
   interface on the middlebox to interface with different
   services on the same middlebox interface.




Srisuresh et al.                                               [Page 26]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


8.2. Asynchronous notification to MIDCOM agents

   Asynchronous notification by the middlebox to a MIDCOM agent
   can be useful for events such as Session creation, Session 
   termination, MIDCOM protocol failure, Middlebox function 
   failure or any other significant event. Independently, ICMP
   error codes can also be useful to notify transport layer
   failures to the agents. 

   In addition, periodic notification of various forms of data 
   such as statistics update would also be a useful function
   that would be beneficial to certain types of agents.

8.3. Timers on Middlebox considered useful

   When supporting MIDCOM protocol, the middlebox is required to 
   allocate dynamic resources such as pin-holes, upon request from
   agents. Explicit release of dynamically allocated resources
   happens when the application session is ended or when a Midcom
   agent requests the middlebox to release the resource. 

   However, the middlebox should be able to recover the dynamically
   allocated resources even as the agent that was responsible for
   the allocation is not alive. Associating a lifetime for these
   dynamic resources and using a timer to track the lifetime can
   be a good way to accomplish this.

8.4. Middleboxes supporting multiple services

   A middlebox could be implementing a variety of services (e.g. NAT
   and firewall) in the same box. Some of these services might have
   inter-dependency on shared resources and sequence of operation.
   Others may be independent of each other. Generally speaking,
   the sequence in which these function operations may be performed
   on datagrams is not within the scope of this document.

   In the case of a middlebox implementing NAT and firewall
   services, it is safe to state that the NAT operation on an
   interface will precede firewall on the egress and will follow
   firewall on the ingress.  Further, firewall access control
   lists used by a firewall are assumed to be based on session
   parameters as seen on the interface supporting firewall service. 

8.5. Signaling and Data traffic

   The class of applications the MIDCOM architecture is addressing
   focus around applications that have a combination of one or more
   signaling and data traffic sessions. The signaling may be done



Srisuresh et al.                                               [Page 27]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   out-of-band using a dedicated stand-alone session or may be done
   in-band within data session. Alternately, signaling may also be
   done as a combination of both stand-alone and in-band sessions. 

   SIP is an example of an application based on distinct signaling
   and data sessions. SIP signaling session is used for call setup
   between a caller and a callee. MIDCOM agent may be required to 
   examine/modify SIP payload content to administer the middlebox
   so as to let the media streams (RTP/RTCP based) through. MIDCOM
   agent is not required to intervene in the data traffic.

   Signaling and context specific Header information is sent in-band
   within the same data stream for applications such as HTTP embedded 
   applications, sun-RPC (embedding a variety of NFS apps), Oracle 
   transactions (embedding oracle SQL+, MS ODBC, Peoplesoft) etc. 
   
   H.323 is an example of application that sends signaling in both
   dedicated stand-alone session as well as in conjunction with data.
   Q.931 traffic traverses middleboxes by virtue of static policy, 
   no MIDCOM control needed. Q.931 also negotiates ports for an 
   H.245 TCP stream. A MIDCOM agent is required to examine/modify 
   the contents of the H.245 so that H.245 can traverse it.

   H.245 traverses the middlebox and also carries Open Logical 
   Channel information for media data. So the MIDCOM agent is once 
   again required to examine/modify the payload content needs to
   let the media traffic flow.

   The MIDCOM architecture takes into consideration, supporting 
   applications with independent signaling and data sessions as 
   well as applications that have signaling and data communicated
   over the same session. 

   In the cases where signaling is done on a single stand-alone 
   session, it is desirable to have a MIDCOM agent interpret the 
   signaling stream and program the middlebox (that transits the
   data stream) so as to let the data traffic through uninterrupted.
 

9. Applicability Statement

   Middleboxes may be stationed in a number of topologies. However, the
   signaling framework outlined in this document may be limited to only
   those middleboxes that are located in a DMZ (De-Militarized Zone) at 
   the edge of a private domain, connecting to the Internet. 
   Specifically, the assumption is that you have a single middlebox 
   (running NAT or firewall) along the application route. Discovery of
   middlebox along application route is outside the scope of this 



Srisuresh et al.                                               [Page 28]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   document. It is conceivable to have middleboxes located between
   departments within the same domain or inside service provider's
   domain and so forth. However, care must be taken to review each
   individual scenario and determine the applicability on a
   case-by-case basis.

   The applicability may also be illustrated as follows. Real-time and 
   streaming applications such as Voice-Over-IP and peer-to-peer
   applications such as Napster and Netmeeting require administering
   firewall and NAT middleboxes to let their media streams reach hosts
   inside a private domain. The requirements are in the form of
   establishing a "pin-hole" to permit a TCP/UDP session (the port
   parameters of which are dynamically determined) through a firewall
   or retain an address/port bind in the NAT device to permit
   connections to a port. These requirements are met by current
   generation middleboxes using adhoc methods, such as embedding
   application intelligence within a middlebox to identify the dynamic
   session parameters and administering the middlebox internally as
   appropriate. The objective of the MIDCOM architecture is to create
   a unified, standard way to exercise this functionality, currently
   existing in an ad-hoc fashion in some of the middleboxes.

   By adopting MIDCOM architecture, middleboxes will be able to
   support newer applications they have not been able to support thus
   far. MIDCOM architecture does not and MUST not, in anyway, change
   the fundamental characteristic of the services supported on the
   middlebox.
 
   Typically, organizations shield a majority of their corporate 
   resources (such as end-hosts) from visibility to the external
   network by the use of a De-Militarized Zone (DMZ) at the domain
   edge. Only a portion of these hosts are allowed to be accessed by
   the external world. The remaining hosts and their names are unique
   to the private domain. Hosts visible to the external world and the 
   authoritative name server that maps their names to network 
   addresses are often configured within a DMZ (De-Militarized Zone) 
   in front of a firewall. Hosts and middleboxes within DMZ are 
   referred to as DMZ nodes.

   Figure 4 below illustrates configuration of a private domain with
   a DMZ at its edge. Actual configurations may vary. Internal hosts
   are accessed only by users inside the domain. Middleboxes, 
   located in the DMZ may be accessed by agents inside or outside 
   the domain.







Srisuresh et al.                                               [Page 29]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001



                                   \ | /
                           +-----------------------+
                           |Service Provider Router|
                           +-----------------------+
                            WAN  |
               Stub A .........|\|....
                               |
                     +---------------+
                     | NAT Middlebox |
                     +---------------+
                         |
                         |   DMZ - Network
   ------------------------------------------------------------
      |         |              |            |             |
     +--+      +--+           +--+         +--+      +-----------+
     |__|      |__|           |__|         |__|      | Firewall  |
    /____\    /____\         /____\       /____\     | Middlebox |
   DMZ-Host1  DMZ-Host2 ...  DMZ-Name     DMZ-Web    +-----------+
                             Server       Server etc.   |
                                                        |
     Internal Hosts (inside the private domain)         |
   ------------------------------------------------------------
       |             |                 |           |
      +--+         +--+               +--+       +--+
      |__|         |__|               |__|       |__|
     /____\       /____\             /____\     /____\
    Int-Host1    Int-Host2  .....   Int-Hostn   Int-Name Server

    Figure 4: DMZ network configuration of a private domain.


10. Acknowledgements

   The authors wish to thank Christian Huitema, Joon Maeng, Jon 
   Peterson, Mike Fisk, Matt Holdrege, Melinda Shore, Paul Sijben,
   Philip Mart, Scott Brim and Richard Swale for their valuable
   critique, advice and input on an earlier rough version of this
   document. The authors owe special thanks to Eliot Lear for
   kick-starting the e-mail discussion on use-case scenarios with a
   SIP application flow diagram through a middlebox. Much thanks to
   Bob Penfield, Cedric Aoun, Christopher Martin, Eric Fleischman,
   George Michaelson, Wanqun Bao and others in the MIDCOM work group
   for their very detailed feedback on a variety of topics and
   adding clarity to the discussion. Last, but not the least, the
   authors owe much thanks to Melinda Shore for her continued
   support, critique and feedback throughout in bringing out fine
   subtleties and helping to make the document a better read. 



Srisuresh et al.                                               [Page 30]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001




11. Security Considerations

   Discussed below are security consideration in accessing a
   middlebox. Without MIDCOM protocol support, the premise of a 
   middlebox operation fundamentally requires the data to be in the
   clear as the middlebox needs the ability to inspect and/or modify
   packet headers and payload. This compromises the confidentiality
   requirement in some environments. Further, Updating transport
   headers and rewriting application payload data in some cases by
   NAT prevents the use of integrity protection on some data streams
   traversing NAT middleboxes. Clearly, this can pose a significant
   security threat to the application in an untrusted transport
   domain.

   However, the MIDCOM protocol removes the need for a middlebox
   to inspect or manipulate data. This in turn allows applications
   to better protect themselves end-to-end with the aid of a trusted
   MIDCOM agent. This is especially the case when the agent is
   resident on the end-host. When an agent has the same end-to-end
   ability as the end-host to interpret encrypted and integrity
   protected data, data transiting a middlebox can be encrypted and
   integrity protected. The MIDCOM agent will still be able to
   interpret the data and simply notify the middlebox to open holes,
   install NAT table entries, etc.

   Security between a MIDCOM agent and a middlebox has a number of
   components. Authorization, authentication, integrity and
   confidentiality. Authorization refers to whether a particular
   agent is authorized to signal middlebox with requests for one or
   more applications adhering to a certain policy profile. Failing the
   authorization process might indicate resource theft attempt or
   failure due to administrative and/or credential deficiencies. In
   either case, the middlebox should take the proper measures to
   audit/log such attempts and consult its designated policy server
   for the required action if the middlebox is configured with one.
   Alternatively, the middlebox may resort to a default service deny
   policy when a midcom agent fails to prompt the required
   credentials. Section 6 discusses the middlebox-policy server
   interactions in view of policy decisions.

   Authentication refers to confirming the identity of originator 
   for all datagrams received from the originator. Lack of strong
   credentials for authentication of MIDCOM messages between an agent
   and a middlebox can seriously jeopardize the fundamental service
   rendered by the middlebox. A consequence of not authenticating an
   agent would be that an attacker could spoof the identity of a 



Srisuresh et al.                                               [Page 31]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


   "legitimate" agent and open holes in the firewall.  Another would
   be that it could otherwise manipulate state on a middlebox,
   creating a denial-of-service attack by closing needed pinholes or
   filling up a NAT table.  A consequence of not authenticating the
   middlebox to an agent is that an attacker could pose as a
   middlebox and respond to NAT requests in a manner that would divert
   data to the attacker. Failing to submit the required/valid 
   credentials once challenged may indicate a replay attack and in 
   which case a proper action is required by the middlebox such as 
   auditing, logging, consulting its designated policy server to
   reflect such failure. A consequence of not protecting the 
   middlebox against replay attacks would be that a specific 
   pinhole may be reopened or closed by an attacker at will, thereby
   bombarding end hosts with unwarranted data or causing denial of 
   service.  

   Integrity is required to ensure that a MIDCOM message has not been
   accidentally or maliciously altered or destroyed. Result of a lack
   of data integrity enforcement in an untrusted environment could be
   that an imposter will alter the messages sent by an agent and
   bring the middlebox to a halt or cause a denial of service for the
   application the agent is attempting to enable.

   Confidentiality of MIDCOM messages ensure that the signaling data 
   is accessible only to the authorized entities. When a middlebox
   agent is deployed in an untrusted environment, lack of 
   confidentiality will allow an intruder to perform traffic flow
   analysis and snoop the middlebox resources. The intruder could
   cannibalize a lesser secure MIDCOM connection and destroy or 
   compromise the middlebox resources he uncovered on other 
   connections. Needless to say, the least secure MIDCOM connection
   will become the achilles heel and make the middlebox vulnerable
   to security attacks. 

   Lastly, there can be security vulnerability to the applications
   traversing a middlebox when a resource on a middlebox is controlled
   by multiple external agents.  A middlebox service may be disrupted
   due to conflicting directives from multiple agents associated with
   different middlebox functions but applied to the same application
   session. Care must be taken in the protocol design to ensure that
   agents for one function do not abruptly step over resources impacting
   a different function. Alternately, the severity of such
   manifestations could be lessened when a single MIDCOM agent is
   responsible for supporting all the middlebox services for an
   application due to the reduced complexity and synchronization effort
   in managing the middlebox resources.





Srisuresh et al.                                               [Page 32]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001


REFERENCES

   [IETF-STD] Bradner, S., " The Internet Standards Process -- 
              Revision 3", RFC 1602, IETF, October 1996.

   [SIP]      Handley, M., H. Schulzrinne, E. Schooler, and 
              J. Rosenberg, "SIP: Session Initiation Protocol", 
              RFC 2543, IETF, March 1999. 

   [SDP]      Handley, M., and Jacobson, V., "SDP: session 
              description protocol", RFC 2327, IETF, April 1998.

   [H.323]    ITU-T Recommendation H.323. "Packet-based Multimedia
              Communications Systems," 1998.

   [RTP]      Schulzrinne, H., S. Casner, R. Frederick, and V. Jacobson,
              "RTP: A Transport Protocol for Real-Time Applications",
              RFC 1889, IETF, January 1996. 

   [RTSP]     Schulzrinne, H., A. Rao, R. Lanphier: "Real Time 
              Streaming Protocol", RFC 2326, IETF, April 1998.

   [FTP]      J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)",  
              RFC 959

   [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 
              Translator (NAT) Terminology and Considerations", 
              RFC 2663, August 1999.

   [NAT-TRAD] Srisuresh, P. and Egevang, K., "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022, 
              January 2001.

   [NAT-COMP] Holdrege, M. and Srisuresh, P., "Protocol Complications
              with the IP Network Address Translator", RFC 3027, 
              January 2001.

   [NAT-PT]   Tsirtsis, G. and Srisuresh, P., "Network Address 
              Translation - Protocol Translation (NAT-PT)", 
              RFC 2766, February 2000.

   [APPL-ID]  Bernet, Y. and Pabbati, R., "Application and Sub 
              Application Identity Policy Element for Use with
              RSVP", RFC 2872, June 2000.

   [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., 
              de Groot, G. and E. Lear, "Address Allocation for 
              Private Internets", BCP 5, RFC 1918, February 1996.



Srisuresh et al.                                               [Page 33]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001



   [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 
              RFC 1700

   [IPsec-AH] Kent, S., and R. Atkinson, "IP Authentication 
              Header", RFC 2402, November 1998.

   [IPsec-ESP] Kent, S., and R. Atkinson, "IP Encapsulating 
              Security Payload (ESP)", RFC 2406, November 1998.

   [TLS]      Dierks, T., and Allen, C., "The TLS Protocol
              Version 1.0", RFC 2246, January 1999.



Authors' Addresses

   Pyda Srisuresh
   Kuokoa Networks, Inc.
   2901 Tasman Dr., Suite 202
   Santa Clara, CA 95054
   U.S.A.
   EMail: srisuresh@yahoo.com


   Jiri Kuthan
   GMD Fokus
   Kaiserin-Augusta-Allee 31
   D-10589 Berlin, Germany
   E-mail: kuthan@fokus.gmd.de


   Jonathan Rosenberg
   dynamicsoft
   200 Executive Drive
   Suite 120
   West Orange, NJ 07052
   U.S.A.
   email: jdrosen@dynamicsoft.com

   Andrew Molitor
   Aravox technologies
   4201 Lexington Avenue North, Suite 1105
   Arden Hills, MN 55126
   U.S.A.
   voice: (651) 256-2700
   email: amolitor@visi.com




Srisuresh et al.                                               [Page 34]

Internet-Draft      MIDCOM Architecture  & Framework         August 2001



   Abdallah Rayhan
   P.O. Box 3511 Stn C
   Ottawa, ON, Canada K1Y 4H7
   eMail: ar_rayhan@yahoo.ca













































Srisuresh et al.                                               [Page 35]

--0-1897794873-997009087=:19217--


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sun Aug  5 15:39:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19372
	for <midcom-archive@odin.ietf.org>; Sun, 5 Aug 2001 15:38:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11015;
	Sun, 5 Aug 2001 15:39:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10980
	for <midcom@ns.ietf.org>; Sun, 5 Aug 2001 15:39:20 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19366
	for <midcom@ietf.org>; Sun, 5 Aug 2001 15:38:15 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f75Jd4Y02222
	for <midcom@ietf.org>; Sun, 5 Aug 2001 12:39:04 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f75JcmQ07424
	for <midcom@ietf.org>; Sun, 5 Aug 2001 12:38:49 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id MAA24781 for <midcom@ietf.org>; Sun, 5 Aug 2001 12:38:48 -0700 (PDT)
Message-ID: <048c01c11de6$20c6d630$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <midcom@ietf.org>
Date: Sun, 5 Aug 2001 15:37:54 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] Two things
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

1) The Monday evening BOF will be held in the bar directly across 
from reception in the Hilton Metropole.  Meet there at 19:30 - if
there's no space we'll relocate.

2) I have both the requirements and framework drafts in Palm DOC
format on my Visor, but, alas, not available for download elsewhere.
Track me down and I'll beam you a copy.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sun Aug  5 15:41:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19535
	for <midcom-archive@odin.ietf.org>; Sun, 5 Aug 2001 15:41:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11092;
	Sun, 5 Aug 2001 15:42:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11059
	for <midcom@ns.ietf.org>; Sun, 5 Aug 2001 15:42:14 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19496
	for <midcom@ietf.org>; Sun, 5 Aug 2001 15:41:08 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f75Jfq326601;
	Sun, 5 Aug 2001 12:41:52 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f75Jfqj16628;
	Sun, 5 Aug 2001 12:41:52 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id MAA24949; Sun, 5 Aug 2001 12:41:40 -0700 (PDT)
Message-ID: <049b01c11de6$87bb30c0$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Scott Brim" <sbrim@cisco.com>, <midcom@ietf.org>
References: <20010803131556.A1448@SBRIM-W2K>
Subject: Re: [midcom] Requirements summary: all requirements
Date: Sun, 5 Aug 2001 15:40:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> Does a weekly update of a "living document" sound good?

I think this is an outstanding idea.  Let's borrow a page from 
AAA and use numbered "issues" along with brief text describing 
where we currently stand, if it's not too onerous (just a suggestion, 
not a mandate).  It's most important for the purpose of making
progress to track the unresolved issues.

Thanks!

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug  6 08:13:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21876
	for <midcom-archive@odin.ietf.org>; Mon, 6 Aug 2001 08:13:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08332;
	Mon, 6 Aug 2001 08:12:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08304
	for <midcom@ns.ietf.org>; Mon, 6 Aug 2001 08:12:30 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21841
	for <midcom@ietf.org>; Mon, 6 Aug 2001 08:11:25 -0400 (EDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f76CCA310846
	for <midcom@ietf.org>; Mon, 6 Aug 2001 05:12:10 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f76CBxq13962
	for <midcom@ietf.org>; Mon, 6 Aug 2001 05:11:59 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id FAA27020 for <midcom@ietf.org>; Mon, 6 Aug 2001 05:11:58 -0700 (PDT)
Message-ID: <002101c11e70$e05a4fb0$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <midcom@ietf.org>
Date: Mon, 6 Aug 2001 08:11:06 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] BOF reminder
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

We're having two informal get-togethers in London this week
prior to Friday's meeting.  I've been reminded to remind you
that 1) these meetings have no standing, and 2) no decisions can
be made at these meetings.  The plan is to use the BOFs to
identify the issues which need resolution as well as identifying 
material currently missing from both documents.  Anything 
identified at the BOFs will be brought to the mailing list and
to the meeting.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug  6 09:59:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23524
	for <midcom-archive@odin.ietf.org>; Mon, 6 Aug 2001 09:59:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10891;
	Mon, 6 Aug 2001 09:50:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10862
	for <midcom@ns.ietf.org>; Mon, 6 Aug 2001 09:50:44 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23357
	for <midcom@ietf.org>; Mon, 6 Aug 2001 09:49:39 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f76DlxJ16065
	for <midcom@ietf.org>; Mon, 6 Aug 2001 06:47:59 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-123.cisco.com [10.21.112.123])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIP07310;
	Mon, 6 Aug 2001 06:49:39 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 6 Aug 2001 14:49:39 +0100
Date: Mon, 6 Aug 2001 14:49:38 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Interim rev. of the famework draft
Message-ID: <20010806144938.G1140@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010805105807.20239.qmail@web13803.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010805105807.20239.qmail@web13803.mail.yahoo.com>; from srisuresh@yahoo.com on Sun, Aug 05, 2001 at 03:58:07AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

There's only one change I don't understand.  "Deregister" is now
"disconnect".  Why?  

Thanks ... Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 05:51:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28900
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 05:51:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21654;
	Tue, 7 Aug 2001 05:40:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21624
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 05:40:14 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28765
	for <midcom@ietf.org>; Tue, 7 Aug 2001 05:39:07 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f779dig25038
	for <midcom@ietf.org>; Tue, 7 Aug 2001 02:39:44 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f779dsV05267
	for <midcom@ietf.org>; Tue, 7 Aug 2001 02:39:54 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id CAA15424 for <midcom@ietf.org>; Tue, 7 Aug 2001 02:39:42 -0700 (PDT)
Message-ID: <013501c11f24$c5ce9b60$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <midcom@ietf.org>
Date: Tue, 7 Aug 2001 05:38:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] Framework document
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

As I mentioned earlier, enough major issues have been
raised during last call that we need to hold last call and
move towards resolving all outstanding issues.  

We will be developing an open issues list.  For an item to
remain on the list there must be at least four people who
agree that there's a problem.  Please be specific when you
raise an issue.

Also, we continue to suffer from a deficit of material covering
policy issues and interfaces.  This is a key component of our
work and it must be addressed.  We'll be spending some time
on this during the framework discussions on Friday.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 07:42:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01338
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 07:42:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25119;
	Tue, 7 Aug 2001 07:41:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25090
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 07:41:49 -0400 (EDT)
Received: from hnssysa.hns.com (hnssysa.hns.com [139.85.76.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01300
	for <midcom@ietf.org>; Tue, 7 Aug 2001 07:40:43 -0400 (EDT)
Received: from hns.com ([139.85.221.171])
	by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id HAA16412;
	Tue, 7 Aug 2001 07:41:17 -0400 (EDT)
Message-ID: <3B6FD0A9.6634A267@hns.com>
Date: Tue, 07 Aug 2001 07:27:37 -0400
From: borderlt <border@hns.com>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: midcom@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [midcom] Re draft-ietf-midcom-framework-04-interim.txt
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


    Would it be useful to add a Section 7.4 which shows a NAPT and a Firewall
which are not in the same box?  Even if the flow is the same as that showed in
Section 7.3 (which I think it is), this fact would be emphasized.  At a
minimum, if the flow is the same an explicit statement to this effect in
Section 7.3 would be good...

    Is the statement in Section 9 (re applicability) about a single middlebox
supposed to exclude the case where the NAPT and Firewall are in separate
boxes?  I think we should at least support one of each type and they should
not be constrained to be in the same box.  Of course, I think that the
intention is that one of each type is supported (despite the statement about a
single middlebox) because they are shown as separate in the Figure 4 example.


John



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 07:42:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01354
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 07:42:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25162;
	Tue, 7 Aug 2001 07:41:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25126
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 07:41:52 -0400 (EDT)
Received: from hnssysa.hns.com (hnssysa.hns.com [139.85.76.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01302
	for <midcom@ietf.org>; Tue, 7 Aug 2001 07:40:46 -0400 (EDT)
Received: from hns.com ([139.85.221.171])
	by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id HAA16419;
	Tue, 7 Aug 2001 07:41:20 -0400 (EDT)
Message-ID: <3B6FD0BF.A2276624@hns.com>
Date: Tue, 07 Aug 2001 07:27:59 -0400
From: borderlt <border@hns.com>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: midcom@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [midcom] Re draft-ietf-midcom-requirements-02.txt
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


    Re the flow profile specifications in Section 5.1.2...  Should SCTP be
explicitly listed?  I am not sure because I am not sure how this list has been
scoped.  Is the intention to only include stuff really being used right now?


John


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 08:41:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02391
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 08:41:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26626;
	Tue, 7 Aug 2001 08:40:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26601
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 08:40:45 -0400 (EDT)
Received: from relay1.bt.net (relay1.bt.net [194.72.6.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02345
	for <midcom@ietf.org>; Tue, 7 Aug 2001 08:39:38 -0400 (EDT)
Received: from [217.33.146.184] (helo=BobP)
	by relay1.bt.net with smtp (Exim 3.15 #1)
	id 15U6A4-0000tA-00
	for midcom@ietf.org; Tue, 07 Aug 2001 13:40:40 +0100
Message-ID: <002b01c11f3e$12a32640$b89221d9@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "midcom mail-list" <midcom@ietf.org>
Date: Tue, 7 Aug 2001 08:39:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] pin-holes, sessions and flows, oh my!
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,

During some informal discussions between several individuals interested in
midcom who happened to be in the bar (although no one had any feathers), it
was noticed that there are variety of inconsistent terms used in the
framework and requirements to describe the thing in the middlebox that we
wish to manage with a midcom protocol.

Our illustrious leader has asked me to take a crack at defining one set of
terms for these things.

There are two things we need to represent: 1) an individual NAT/pin-hole to
enable a stream of packets to traverse the middlebox; and 2) an aggregation
or grouping of NATs/pin-holes that represent a session from the
application's point of view.

Currently, the framework calls an individual thing a session-descriptor, and
the requirements call it a pin-hole. It was felt by a number of those
present that pin-hole implied a firewall function to the exclusion NAT
(Although we realize that is not what was intended). It was also felt by
some people that "session" was overloaded in that it has been used to
describe an individual pin-hole/NAT, a group of pin-holes/NATs and the
communication/connection between a midcom agent and a middlebox.

I personally liked the term "flow" for an individual thing, and the term
"session" for a group of things. However, a many of those present felt that
the term "resource" was best to describe an individual pin hole/NAT. A
"bundle" was suggested for a group of related "resources".

So here goes.

Resource:
A resource is a single instance of a middlebox service for a specific flow
or stream of packets (e.g. a NAT session or a firewall pin-hole). It defines
the information necessary to identify incoming packets that are associated
with the resource and the actions required to dispose of the packets
(forward them on or drop them). Note that a service may consist of multiple
functions. For example, a single resource could include both the NAT and
firewall functions.

Resource Bundle:
A resource bundle is a group of resources that have been associated together
by the application via the midcom agent, which uses the midcom protocol to
establish the grouping in the middlebox.

How's that?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com





_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 09:05:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02869
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 09:05:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26972;
	Tue, 7 Aug 2001 08:59:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26943
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 08:59:43 -0400 (EDT)
Received: from relay1.bt.net (relay1.bt.net [194.72.6.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02726
	for <midcom@ietf.org>; Tue, 7 Aug 2001 08:58:36 -0400 (EDT)
Received: from [217.33.146.184] (helo=BobP)
	by relay1.bt.net with smtp (Exim 3.15 #1)
	id 15U6ST-0003PX-00
	for midcom@ietf.org; Tue, 07 Aug 2001 13:59:41 +0100
Message-ID: <003501c11f40$ba8aa160$b89221d9@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "midcom mail-list" <midcom@ietf.org>
Date: Tue, 7 Aug 2001 08:59:00 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] requirements - resource (p.k.a. pin-hole) operations
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,

Section 5.3 mentions 3 operations to be performed on a resource (pin-hole)
in a middlebox. I believe that we need at least 2 more. Namely "create" (or
"allocate") and "delete" (or "free").

The create operation would allocate the resource in the middlebox, but
packets would not be allowed through until an "open" operation is performed.
An open operation for an unallocated resource could imply a create & open
operation to minimize the number and size of messages between the agent and
the middlebox

The delete operation would be used to free the resource. Close would only
stop packets from flowing. The resource would not be freed for a close
operation. The resource could subsequently re-opened by the agent.
A delete operation on an open resource would imply close & delete.

A concrete example of an application that needs this capability is SIP. When
a session is initiated in SIP with an INVITE, the session description may
define multiple media streams that the client is willing to accept. The
response from the server may include only a subset of these media streams.
The resource in the middlebox needs to be allocated/reserved before the
INVITE is forwarded to the client. However, we do not want to enable packet
flow until the response is received from the client.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 10:03:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04277
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:03:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28698;
	Tue, 7 Aug 2001 09:55:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28667
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 09:55:22 -0400 (EDT)
Received: from relay1.bt.net (relay1.bt.net [194.72.6.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03970
	for <midcom@ietf.org>; Tue, 7 Aug 2001 09:54:16 -0400 (EDT)
Received: from [217.33.146.184] (helo=BobP)
	by relay1.bt.net with smtp (Exim 3.15 #1)
	id 15U7KM-0001so-00
	for midcom@ietf.org; Tue, 07 Aug 2001 14:55:22 +0100
Message-ID: <005601c11f48$820a3d20$b89221d9@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "midcom mail-list" <midcom@ietf.org>
Date: Tue, 7 Aug 2001 09:54:41 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] peer-to-peer or client-server
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hello again,

I have noticed that there seems to be a disconnect between the way many
people view the relationship between the midcom agent and the middlebox in
the many informal discussion going on and the text in the framework and
requirements drafts. Both drafts state that it is a peer-to-peer protocol
where either the midcom agent or the middlebox can initiate the
communication between them. However, I and some other people see it more as
a client-server relationship where the midcom agent initiates the
communication. The midcom agent requests the services of the middlebox, and
the middlebox responds with yes or no (hopefully with a reason). The
middlebox may send asynchronous notifications for certain events (such as
timeout), but it does not request any services from the midcom agent.

Also, I have a related specific issue with the requirements. In section 5.4
it states:

   Either the agent or the Middlebox can choose to initiate a
   connection prior to any data traffic. Alternately, either party
   (Middlebox or the MIDCOM Agent) may choose to initiate a connection
   only upon noticing application specific traffic.

I find the second sentence troubling. I thought the main idea was to take
application intelligence (which would be required to "notice application
specific traffic") out of the middlebox and put it in the agent.

Hopefully we can discuss this at the meeting on Friday. Although please
don't wait till then to voice your professional reasoned opinions.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 10:21:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04685
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:21:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29520;
	Tue, 7 Aug 2001 10:10:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29493
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 10:10:27 -0400 (EDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04424
	for <midcom@ietf.org>; Tue, 7 Aug 2001 10:09:21 -0400 (EDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id OAA08453
	for <midcom@ietf.org>; Tue, 7 Aug 2001 14:10:27 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001080707085514527
 ; Tue, 07 Aug 2001 07:08:55 -0700
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by fmsmsx19.fm.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id QCL2MYSY; Tue, 7 Aug 2001 07:10:26 -0700
Received: from condryvaio-mobl.intel.com ([10.7.248.65]) by 132.233.42.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 07 Aug 2001 14:10:25 0000 (GMT)
Message-Id: <5.1.0.14.2.20010807070833.0244ccd8@FMSMSX63.intel.com>
X-Sender: mwcondry@FMSMSX63.intel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 07 Aug 2001 07:09:13 -0700
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "midcom mail-list" <midcom@ietf.org>
From: "Michael W. Condry" <condry@intel.com>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
In-Reply-To: <002b01c11f3e$12a32640$b89221d9@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

We need to align several groups here including WEBI, OPES and
possibly CDI. Can you send out this to all?
At 05:39 AM 8/7/2001, Bob Penfield wrote:
>Hi all,
>
>During some informal discussions between several individuals interested in
>midcom who happened to be in the bar (although no one had any feathers), it
>was noticed that there are variety of inconsistent terms used in the
>framework and requirements to describe the thing in the middlebox that we
>wish to manage with a midcom protocol.
>
>Our illustrious leader has asked me to take a crack at defining one set of
>terms for these things.
>
>There are two things we need to represent: 1) an individual NAT/pin-hole to
>enable a stream of packets to traverse the middlebox; and 2) an aggregation
>or grouping of NATs/pin-holes that represent a session from the
>application's point of view.
>
>Currently, the framework calls an individual thing a session-descriptor, and
>the requirements call it a pin-hole. It was felt by a number of those
>present that pin-hole implied a firewall function to the exclusion NAT
>(Although we realize that is not what was intended). It was also felt by
>some people that "session" was overloaded in that it has been used to
>describe an individual pin-hole/NAT, a group of pin-holes/NATs and the
>communication/connection between a midcom agent and a middlebox.
>
>I personally liked the term "flow" for an individual thing, and the term
>"session" for a group of things. However, a many of those present felt that
>the term "resource" was best to describe an individual pin hole/NAT. A
>"bundle" was suggested for a group of related "resources".
>
>So here goes.
>
>Resource:
>A resource is a single instance of a middlebox service for a specific flow
>or stream of packets (e.g. a NAT session or a firewall pin-hole). It defines
>the information necessary to identify incoming packets that are associated
>with the resource and the actions required to dispose of the packets
>(forward them on or drop them). Note that a service may consist of multiple
>functions. For example, a single resource could include both the NAT and
>firewall functions.
>
>Resource Bundle:
>A resource bundle is a group of resources that have been associated together
>by the application via the midcom agent, which uses the midcom protocol to
>establish the grouping in the middlebox.
>
>How's that?
>
>cheers,
>(-:bob
>
>Robert F. Penfield
>Chief Software Architect
>Acme Packet, Inc.
>130 New Boston Street
>Woburn, MA 01801
>bpenfield@acmepacket.com
>
>
>
>
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>http://www1.ietf.org/mailman/listinfo/midcom

Michael W. Condry
Director,  Network Edge Technology



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 11:04:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05740
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 11:04:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01272;
	Tue, 7 Aug 2001 10:53:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01239
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 10:53:50 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05516
	for <midcom@ietf.org>; Tue, 7 Aug 2001 10:52:43 -0400 (EDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f77ErU310053
	for <midcom@ietf.org>; Tue, 7 Aug 2001 07:53:30 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f77ErJe00827
	for <midcom@ietf.org>; Tue, 7 Aug 2001 07:53:19 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id HAA28440 for <midcom@ietf.org>; Tue, 7 Aug 2001 07:53:18 -0700 (PDT)
Message-ID: <00ad01c11f50$9563e080$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <midcom@ietf.org>
Date: Tue, 7 Aug 2001 10:52:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] Framework confabulation
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Reminder: get-together on Thursday at 19:30 to discuss what
issues need resolution to get the framework document through 
last call.  Meet in lounge across from reception.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 11:44:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06664
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 11:44:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02906;
	Tue, 7 Aug 2001 11:43:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02881
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 11:43:11 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06598
	for <midcom@ietf.org>; Tue, 7 Aug 2001 11:42:04 -0400 (EDT)
Received: from cisco.com (sjc-vpn1-243.cisco.com [10.21.96.243]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA24779 for <midcom@ietf.org>; Tue, 7 Aug 2001 08:42:40 -0700 (PDT)
Message-ID: <3B700C72.35EC5BD8@cisco.com>
Date: Tue, 07 Aug 2001 08:42:42 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: midcom@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [midcom] policy & duration
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


In our bar-fob we had a number of issues with policy.  i have promised to
provide some words to help improve the situation.  I hope this does. 
Please note that there is a trivial case hidden in these requirements,
obviating the need for a policy server in many instances.  Thus the
wording allows for a fairly flexible architecture.  Don't understand the
policy conditions?  Go ask the policy server.

This information supersedes section 4.3 of the requirements document and
augments (and will need to be reconciled with) sections 2.9 and 6 of the
framework document.  The wording here will need to be further reconciled
with the policy documents.

Please note that I have not addressed what information is returned to the
midcom agent.  That is an important topic and it needs to be better
understood.

I've also taken a stab at rewriting the duration discussion.  There may be
lots of text we can borrow from the policy people on this subject.

--

4.3  Policy

Each middlebox decision is made based on either configured policy or by
querying a policy server.  While it is not within the midcom rubric to
specify policy configuration methods, the actual policy configuration
itself is important to discuss.

A policy statement consists of one or more policy conditions and a policy
action.[policy]

4.3.1 Policy conditions

Some policy decisions, such as those based on 5-tuple simple access lists
are likely to be made by a middle box.  Other decisions, however, are
likely to be more complex.  Hence we propose a nuanced approach that
allows the policy function to be split.

The midcom agent MUST be able to satisfy informational requirements of the
policy conditions in a policy statement in order for the policy server to
make a decision.  Therefore, a structured exchange that contains those
components MUST occur between the midcom agent and the middlebox, both
query and response.  In as much as a policy server is required to resolve
the policy conditions, a structured exchange MUST also occur between the
middle box and the policy server.

If a middle box acts as its own policy server, it MUST understand any
policy information needed to execute a policy statement.  Put another way,
it MAY discard any policy information that it doesn't understand so long
as that information is not required to make a policy decision.

If the middle box does not understand all of the policy conditions, it
MUST refer the request to a policy server.  It is a configuration error to
have a policy condition that neither the middle box nor the policy agent
can evaluate.

A middle box SHOULD understand, at a minimum, policy conditions that
contain the interfaces involved, protocol, source address and port,
destination address and port, all of which with the exception of protocol
and interfaces MUST be capable of being expressed as a range of values. 
This is the trivial case, necessary to deploy a middlebox without the
assistance of a policy server.

One should expect a middle box that understands a given policy condition
to police it.  However, we do not require it.

4.3.2 Policy actions

Policy actions are those actions associated with a set of policy
conditions in a policy statement.  Examples might be "open a pinhole" or
"return NAT bindings for a given system".

The middle box MUST understand the policy action it is to take.  The
semantics and syntax of each of those policy actions MUST be documented in
a standard.

Hence, policy information SHOULD be encoded in a standard form that is
possible for a middle box to decode, even if it cannot evaluate each
policy condition.

Examples of policy statements can be found in [POLICY].

X Duration

Decisions made by middle boxes MUST have a specific duration.  That
duration MUST include a time interval or a set of actual dates and times,
and MAY include additional termination conditions.  Examples of
termination conditions include an exchange of TCP FINs, the excessive use
of bandwidth, or the exchange of unauthorized content.  A midcom agent MAY
request a change in duration, but the decision of the middle box, like
every other decision will be bound by policy.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 12:22:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07603
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 12:22:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04232;
	Tue, 7 Aug 2001 12:11:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04185
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 12:11:28 -0400 (EDT)
Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07248;
	Tue, 7 Aug 2001 12:10:13 -0400 (EDT)
Received: from [213.122.126.85] (helo=tkw)
	by tungsten.btinternet.com with smtp (Exim 3.22 #9)
	id 15U9Rr-0003FO-00; Tue, 07 Aug 2001 17:11:15 +0100
Message-ID: <001501c11f5b$a9784100$0200000a@tkw>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: <midcom@ietf.org>, "'sip-ietf (E-mail)'" <sip@ietf.org>,
        <sipping@ietf.org>, "SG16" <ITU-SG16@mailbag.cps.INTEL.COM>,
        <TIPHON@LIST.ETSI.FR>
Cc: "Steve Davies" <SDavies@Ridgeway-Sys.com>,
        "Greg Meyer" <greg.w.meyer@intel.com>
Date: Tue, 7 Aug 2001 17:10:33 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit
Subject: [midcom] Re: VoIP Traversal of Non-upgraded Firewall & NATs @ IETF
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Just to confirm the announcement I made at the SIP meeting this morning....

This meeting is now on...  It will be held in:

Hilton Rooms 10, 11, & 12
Thursday 17:45 -> 19:00  (although we'll make it shorter if we can)

Hope to see you there.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Pete Cordell <pete@tech-know-ware.com>
To: <midcom@ietf.org>; 'sip-ietf (E-mail)' <sip@ietf.org>;
<sipping@ietf.org>; SG16 <ITU-SG16@MAILBAG.INTEL.COM>; <TIPHON@LIST.ETSI.FR>
Cc: Steve Davies <SDavies@Ridgeway-Sys.com>
Sent: 01 August 2001 10:03
Subject: VoIP Traversal of Non-upgraded Firewall & NATs @ IETF


> Dear All,
>
> I would like to have a meeting at the IETF (informal BOF?) discussing
> methods for VoIP and Multimedia over IP traversing non-upgraded firewalls
> and NATs.  These methods are intended to supplement the firewall
> architecture, and not require upgrade to existing firewall/NAT components,
> or clients (and other infrastructure such as proxies).
>
> There is a draft discussing one proposal at:
>
> http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt
>
> If others have ideas in this area, then please contact me and we can
arrange
> some sort of agenda.  (Although note that I will be out of contact until
the
> Sunday before the IETF - i.e. this Sunday! - so we might have to organise
> this at the IETF.)
>
> I hope the format will be something like:
>
> - Overview presentation of method
> - How this is secure and maintains administrator control
> - (Repeat for each proposal)
> - Collect issues that need to be addressed before going to a formal BOF.
>
> (The modified agenda involves the final item being changed to 'chaos'!)
>
> At this stage I would like to avoid discussion about how this compares to
> MidCom and other approaches - such as Rosenberg's - as I think it will
> quickly turn into a blood bath.  - We should save that for the formal BOF!
>
> I'm hoping to hold the meeting in:
>
>     The King's Suite/Sandringham 1 on
>     Thursday 17:45 -> 18:45,
>
> but I obviously haven't had a chance to check this with the organisers.
> Therefore, please look out for final details on the noticeboard, and
> probably the door of the King's Suite.
>
> I look forward to seeing you all,
>
> Pete.
>
> (P.S.  Sorry for putting this on the SG16 and TIPHON lists, but I'm well
> aware that many of you attend the IETF and I wanted to make sure you had
the
> opportunity to come along.)
>
> =============================================
> Pete Cordell
> Tech-Know-Ware
> pete@tech-know-ware.com
> +44 1473 635863
> =============================================
>
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 18:43:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13717
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 18:43:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13905;
	Tue, 7 Aug 2001 18:43:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13876
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 18:42:58 -0400 (EDT)
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13706
	for <midcom@ietf.org>; Tue, 7 Aug 2001 18:41:51 -0400 (EDT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GHP00H2NZ2OTG@firewall.mcit.com> for midcom@ietf.org; Tue,
 7 Aug 2001 22:42:24 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0GHP00901Z2L3U@pmismtp02.wcomnet.com>;
 Tue, 07 Aug 2001 22:42:24 +0000 (GMT)
Received: from rccc6131 ([166.35.225.191])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0GHP003CXZ29EM@pmismtp02.wcomnet.com>; Tue,
 07 Aug 2001 22:42:09 +0000 (GMT)
Date: Tue, 07 Aug 2001 16:57:54 -0500
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [midcom] peer-to-peer or client-server
In-reply-to: <005601c11f48$820a3d20$b89221d9@acmepacket.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'midcom mail-list'" <midcom@ietf.org>
Reply-to: christopher.a.martin@wcom.com
Message-id: <000401c11f92$1cbfc260$bfe123a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

comments inline between ">>" tags

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Bob Penfield
Sent: Tuesday, August 07, 2001 8:55 AM
To: midcom mail-list
Subject: [midcom] peer-to-peer or client-server


Hello again,

I have noticed that there seems to be a disconnect between the way many
people view the relationship between the midcom agent and the middlebox in
the many informal discussion going on and the text in the framework and
requirements drafts. Both drafts state that it is a peer-to-peer protocol
where either the midcom agent or the middlebox can initiate the
communication between them. However, I and some other people see it more as
a client-server relationship where the midcom agent initiates the
>>
>>
Totally agree, relationship acts more in client server fashion, and if it
did act as a peer to peer could introduce a security vulnerability.
>>
>>
communication. The midcom agent requests the services of the middlebox, and
the middlebox responds with yes or no (hopefully with a reason). The
middlebox may send asynchronous notifications for certain events (such as
timeout), but it does not request any services from the midcom agent.
>>
>> Right. In terms of service requests, the Policy server is the element
that would orchestrate services at the middlebox level in my mind, before
any MIDCOM Agent involvment. Services such as local access policy, trustedd
MIDCOM agents etc..isnt that right?
>>
>>
Also, I have a related specific issue with the requirements. In section 5.4
it states:

   Either the agent or the Middlebox can choose to initiate a
   connection prior to any data traffic. Alternately, either party
   (Middlebox or the MIDCOM Agent) may choose to initiate a connection
   only upon noticing application specific traffic.

I find the second sentence troubling. I thought the main idea was to take
application intelligence (which would be required to "notice application
specific traffic") out of the middlebox and put it in the agent.
>>
>> I think to clarify why Bobs statement makes sense to me, in this
reference, using the example of a SIP invite, the middlebox is not
performing the initiation, rather the initiating SIP client (through the
predefined policy, setup by the policy server, to allow SIP traffic through
to the Network Server(NS) and associated MIDCOM Agent)is performing this
task of requesting the action by sending the SIP INVITE to the NS which in
turn begins the MIDCOM AGENT process of middlebox control.  All this time
the middlebox does nothing until the MIDCOM AGENT requests the actions of
the middlebox (such as the NAT translation and/or related dynamic packet
filter definition, in the case of a firewall/NAT middlebox,).

The middlebox is not acting with intelligence at this level at all, merely
following policy dictated by the policy server. Because of this I do not
believe that either sentence of 5.4 is accurate statement as it implies
application intelligence of the middlebox, which would be required to
initiate a connection.

At least this is what I get from this paragraph.
>>
>>


Hopefully we can discuss this at the meeting on Friday. Although please
don't wait till then to voice your professional reasoned opinions.
>>
>>
Have a drink for me since I couldnt make it this time...as a Chris proxy if
you will   :^)
>>
>>
cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug  7 21:15:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15310
	for <midcom-archive@odin.ietf.org>; Tue, 7 Aug 2001 21:15:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16878;
	Tue, 7 Aug 2001 21:14:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16851
	for <midcom@ns.ietf.org>; Tue, 7 Aug 2001 21:14:32 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15296
	for <midcom@ietf.org>; Tue, 7 Aug 2001 21:13:25 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f781Dog05298
	for <midcom@ietf.org>; Wed, 8 Aug 2001 02:13:50 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 8 Aug 2001 02:13:47 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PSC00YM8>; Wed, 8 Aug 2001 02:13:46 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445171@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!
Date: Wed, 8 Aug 2001 02:13:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11FA7.5D296D00"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11FA7.5D296D00
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,
thanks for your efforts.

"Resource:
A resource is a single instance of a middlebox service for a specific flow
or stream of packets (e.g. a NAT session or a firewall pin-hole). It defines
the information necessary to identify incoming packets that are associated
with the resource and the actions required to dispose of the packets
(forward them on or drop them). Note that a service may consist of multiple
functions. For example, a single resource could include both the NAT and
firewall functions."

CA: 
Instead of NAT session, I suggest to use NAT Bind. We also need to  add "or
other middle box functions"
i.e the proposed text  is :  (e.g. a NAT BIND, a firewall pin-hole or other
middle box functions).
I prefer to modify the end of the sentence to "and packet filtering
functions"
Cedric

------_=_NextPart_001_01C11FA7.5D296D00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] pin-holes, sessions and flows, oh my!</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob,</FONT>
<BR><FONT SIZE=3D2>thanks for your efforts.</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Resource:</FONT>
<BR><FONT SIZE=3D2>A resource is a single instance of a middlebox =
service for a specific flow</FONT>
<BR><FONT SIZE=3D2>or stream of packets (e.g. a NAT session or a =
firewall pin-hole). It defines</FONT>
<BR><FONT SIZE=3D2>the information necessary to identify incoming =
packets that are associated</FONT>
<BR><FONT SIZE=3D2>with the resource and the actions required to =
dispose of the packets</FONT>
<BR><FONT SIZE=3D2>(forward them on or drop them). Note that a service =
may consist of multiple</FONT>
<BR><FONT SIZE=3D2>functions. For example, a single resource could =
include both the NAT and</FONT>
<BR><FONT SIZE=3D2>firewall functions.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>CA: </FONT>
<BR><FONT SIZE=3D2>Instead of NAT session, I suggest to use NAT Bind. =
We also need to&nbsp; add &quot;or other middle box =
functions&quot;</FONT>
<BR><FONT SIZE=3D2>i.e the proposed text&nbsp; is :&nbsp; (e.g. a NAT =
BIND, a firewall pin-hole or other middle box functions).</FONT>
<BR><FONT SIZE=3D2>I prefer to modify the end of the sentence to =
&quot;and packet filtering functions&quot;</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11FA7.5D296D00--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 00:24:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19249
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 00:24:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20354;
	Wed, 8 Aug 2001 00:23:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20325
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 00:23:37 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com ([47.234.0.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19223
	for <midcom@ietf.org>; Wed, 8 Aug 2001 00:22:32 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k [47.113.64.104])
	by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f784Mp429787
	for <midcom@ietf.org>; Wed, 8 Aug 2001 00:22:53 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 7 Aug 2001 23:16:47 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PLQCP8QC>; Tue, 7 Aug 2001 23:22:51 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Pyda Srisuresh'" <srisuresh@yahoo.com>, midcom@ietf.org
Subject: RE: [midcom] Interim rev. of the famework draft
Date: Tue, 7 Aug 2001 23:22:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11FC1.C8BF6460"
X-Orig: <sanjoy@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11FC1.C8BF6460
Content-Type: text/plain;
	charset="iso-8859-1"

I've the following questions/comments on the Interim draft:


1) In Section 4 - Midcom Protocol - it has been stated that the Midcom
protocol will consist of a connection set-up phase, run-time phase and a
connection termination phase. The meaning of "connection" is not clear.   

2) In timeline flow in Section 7.1, how would the SIP proxy identify the
end-to-end RTP, RTCP sessions from the private SIP UA to the external UA on
receiving the INVITE from external SIP UA? The INVITE SDP does not contain
any information of the RTP port of the media source.

3) In Section 7.2, what does creating "NAT session descriptors" mean? In
this context, the authors implied that this allows the early media flow
through the NAT. From the prior definition of session state, I would tend to
think that the flow will be allowed (or disallowed) only after a session
state (i.e., session descriptor + attributes) is created & a function
specific resource (e.g., NAT bind) is associated with the session state. Is
this correct? Please clarify.

Thanks,
Sanjoy
   

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
> Sent: Sunday, August 05, 2001 5:58 AM
> To: midcom@ietf.org
> Subject: [midcom] Interim rev. of the famework draft
> 
> 
> Folks,
> 
> Please find attached the interim rev. framework draft.
> You may use this as reference during the editorial meeting. 
> Thanks.
> 
> regards,
> suresh
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with 
> Yahoo! Messenger
> http://phonecard.yahoo.com/
> 

------_=_NextPart_001_01C11FC1.C8BF6460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Interim rev. of the famework draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I've the following questions/comments on the Interim =
draft:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>1) In Section 4 - Midcom Protocol - it has been =
stated that the Midcom protocol will consist of a connection set-up =
phase, run-time phase and a connection termination phase. The meaning =
of &quot;connection&quot; is not clear.&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=3D2>2) In timeline flow in Section 7.1, how would the SIP =
proxy identify the end-to-end RTP, RTCP sessions from the private SIP =
UA to the external UA on receiving the INVITE from external SIP UA? The =
INVITE SDP does not contain any information of the RTP port of the =
media source.</FONT></P>

<P><FONT SIZE=3D2>3) In Section 7.2, what does creating &quot;NAT =
session descriptors&quot; mean? In this context, the authors implied =
that this allows the early media flow through the NAT. From the prior =
definition of session state, I would tend to think that the flow will =
be allowed (or disallowed) only after a session state (i.e., session =
descriptor + attributes) is created &amp; a function specific resource =
(e.g., NAT bind) is associated with the session state. Is this correct? =
Please clarify.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Sanjoy</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Pyda Srisuresh [<A =
HREF=3D"mailto:srisuresh@yahoo.com">mailto:srisuresh@yahoo.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Sunday, August 05, 2001 5:58 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Interim rev. of the famework =
draft</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Folks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please find attached the interim rev. framework =
draft.</FONT>
<BR><FONT SIZE=3D2>&gt; You may use this as reference during the =
editorial meeting. </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; regards,</FONT>
<BR><FONT SIZE=3D2>&gt; suresh</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
__________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>&gt; Make international calls for as low as =
$.04/minute with </FONT>
<BR><FONT SIZE=3D2>&gt; Yahoo! Messenger</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://phonecard.yahoo.com/" =
TARGET=3D"_blank">http://phonecard.yahoo.com/</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11FC1.C8BF6460--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 02:45:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06935
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 02:45:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02301;
	Wed, 8 Aug 2001 02:44:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02270
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 02:44:10 -0400 (EDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06926
	for <midcom@ietf.org>; Wed, 8 Aug 2001 02:43:03 -0400 (EDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id GAA07220;
	Wed, 8 Aug 2001 06:43:35 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 08 Aug 2001 06:43:35 0000 (GMT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by fmsmsx28.fm.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id QGJCG1Q1; Tue, 7 Aug 2001 23:43:33 -0700
Received: from condryvaio-mobl.intel.com ([10.7.248.116]) by 132.233.42.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 08 Aug 2001 06:43:32 0000 (GMT)
Message-Id: <5.1.0.14.2.20010807081943.03734778@FMSMSX63.intel.com>
X-Sender: mwcondry@FMSMSX63.intel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 07 Aug 2001 08:20:05 -0700
To: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>,
        "Melinda Shore" <mshore@cisco.com>
From: "Michael W. Condry" <condry@intel.com>
Subject: RE: [midcom] Relationship to work being done in OPES
Cc: <midcom@ietf.org>
In-Reply-To: <EF4C65F18BE6464B8E9DF3C212B6B293ADA3B1@cof110avexu1.global
 .avaya.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_264870==_.ALT"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

--=====================_264870==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

And I, OPES Chair, will be at MidCom on Friday.

At 04:41 PM 8/1/2001, Zmolek, Andrew (Andrew) wrote:

>A readout would be nice, particularly since many of those participating in 
>SIP-related efforts won't be able to attend the OPES BOF now that it's 
>been rescheduled.
>
>--Andy Zmolek
>     Technology & Standards Engineer
>       CTO Standards
>         Avaya Inc.
>
>             zmolek@avaya.com
>               +1 720 444 4001
>
>-----Original Message-----
>From: Melinda Shore [<mailto:mshore@cisco.com>mailto:mshore@cisco.com]
>Sent: Wednesday, August 01, 2001 10:53 AM
>To: lear@cisco.com
>Cc: midcom@ietf.org
>Subject: Re: [midcom] Relationship to work being done in OPES
>
>At 09:46 AM 8/1/01 -0700, Eliot Lear wrote:
> >Could we put this on the end of the agenda at London?  And can the 
> people leading the OPES effort be invited to participate in that discussion?
>
>Forgot to mention that it *will* be discussed at the OPES BOF on
>Tuesday morning.
>
>Melinda
>
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
><http://www.ietf.org/mailman/listinfo/midcom>http://www.ietf.org/mailman/listinfo/midcom 
>

Michael W. Condry
Director,  Network Edge Technology
--=====================_264870==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
And I, OPES Chair, will be at MidCom on Friday.<br><br>
At 04:41 PM 8/1/2001, Zmolek, Andrew (Andrew) wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>A readout would be
nice, particularly since many of those participating in SIP-related
efforts won't be able to attend the OPES BOF now that it's been
rescheduled.<br>
</font><br>
<font size=2>--Andy Zmolek</font> <br>
<font size=2>&nbsp;&nbsp;&nbsp; Technology &amp; Standards
Engineer</font> <br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CTO Standards</font> <br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Avaya Inc.</font>
<br><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; zmolek@avaya.com</font> <br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1 720 444 4001</font> <br><br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Melinda Shore [<a href="mailto:mshore@cisco.com">mailto:mshore@cisco.com</a>]</font> <br>
<font size=2>Sent: Wednesday, August 01, 2001 10:53 AM</font> <br>
<font size=2>To: lear@cisco.com</font> <br>
<font size=2>Cc: midcom@ietf.org</font> <br>
<font size=2>Subject: Re: [midcom] Relationship to work being done in OPES</font> <br><br>
<font size=2>At 09:46 AM 8/1/01 -0700, Eliot Lear wrote:</font> <br>
<font size=2>&gt;Could we put this on the end of the agenda at London?&nbsp; And can the people leading the OPES effort be invited to participate in that discussion?<br>
</font><br>
<font size=2>Forgot to mention that it *will* be discussed at the OPES BOF on</font> <br>
<font size=2>Tuesday morning. <br>
</font><br>
<font size=2>Melinda</font> <br><br>
<br>
<font size=2>_______________________________________________</font> <br>
<font size=2>midcom mailing list</font> <br>
<font size=2>midcom@ietf.org</font> <br>
<font size=2><a href="http://www.ietf.org/mailman/listinfo/midcom">http://www.ietf.org/mailman/listinfo/midcom</a></font> </blockquote>
<x-sigsep><p></x-sigsep>
Michael W. Condry<br>
Director,&nbsp; Network Edge Technology</html>

--=====================_264870==_.ALT--




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 03:13:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07329
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 03:13:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03266;
	Wed, 8 Aug 2001 03:13:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03237
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 03:13:19 -0400 (EDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07275
	for <midcom@ietf.org>; Wed, 8 Aug 2001 03:12:09 -0400 (EDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id HAA13254;
	Wed, 8 Aug 2001 07:13:15 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 08 Aug 2001 07:13:15 0000 (GMT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by fmsmsx28.fm.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id QGJCGHF1; Wed, 8 Aug 2001 00:13:13 -0700
Received: from condryvaio-mobl.intel.com ([10.7.248.116]) by 132.233.42.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 08 Aug 2001 07:13:12 0000 (GMT)
Message-Id: <5.1.0.14.2.20010808001011.01af7308@FMSMSX63.intel.com>
X-Sender: mwcondry@FMSMSX63.intel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 Aug 2001 00:12:02 -0700
To: lear@cisco.com, midcom@ietf.org
From: "Michael W. Condry" <condry@intel.com>
Subject: Re: [midcom] policy & duration
Cc: Ietf-openproxy@imc.org
In-Reply-To: <3B700C72.35EC5BD8@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Do you think that alignment between OPES policy and MidCom policy
concepts should be applied where appropriate?  If so, should the document
not reflect this?
At 08:42 AM 8/7/2001, Eliot Lear wrote:

>In our bar-fob we had a number of issues with policy.  i have promised to
>provide some words to help improve the situation.  I hope this does.
>Please note that there is a trivial case hidden in these requirements,
>obviating the need for a policy server in many instances.  Thus the
>wording allows for a fairly flexible architecture.  Don't understand the
>policy conditions?  Go ask the policy server.
>
>This information supersedes section 4.3 of the requirements document and
>augments (and will need to be reconciled with) sections 2.9 and 6 of the
>framework document.  The wording here will need to be further reconciled
>with the policy documents.
>
>Please note that I have not addressed what information is returned to the
>midcom agent.  That is an important topic and it needs to be better
>understood.
>
>I've also taken a stab at rewriting the duration discussion.  There may be
>lots of text we can borrow from the policy people on this subject.
>
>--
>
>4.3  Policy
>
>Each middlebox decision is made based on either configured policy or by
>querying a policy server.  While it is not within the midcom rubric to
>specify policy configuration methods, the actual policy configuration
>itself is important to discuss.
>
>A policy statement consists of one or more policy conditions and a policy
>action.[policy]
>
>4.3.1 Policy conditions
>
>Some policy decisions, such as those based on 5-tuple simple access lists
>are likely to be made by a middle box.  Other decisions, however, are
>likely to be more complex.  Hence we propose a nuanced approach that
>allows the policy function to be split.
>
>The midcom agent MUST be able to satisfy informational requirements of the
>policy conditions in a policy statement in order for the policy server to
>make a decision.  Therefore, a structured exchange that contains those
>components MUST occur between the midcom agent and the middlebox, both
>query and response.  In as much as a policy server is required to resolve
>the policy conditions, a structured exchange MUST also occur between the
>middle box and the policy server.
>
>If a middle box acts as its own policy server, it MUST understand any
>policy information needed to execute a policy statement.  Put another way,
>it MAY discard any policy information that it doesn't understand so long
>as that information is not required to make a policy decision.
>
>If the middle box does not understand all of the policy conditions, it
>MUST refer the request to a policy server.  It is a configuration error to
>have a policy condition that neither the middle box nor the policy agent
>can evaluate.
>
>A middle box SHOULD understand, at a minimum, policy conditions that
>contain the interfaces involved, protocol, source address and port,
>destination address and port, all of which with the exception of protocol
>and interfaces MUST be capable of being expressed as a range of values.
>This is the trivial case, necessary to deploy a middlebox without the
>assistance of a policy server.
>
>One should expect a middle box that understands a given policy condition
>to police it.  However, we do not require it.
>
>4.3.2 Policy actions
>
>Policy actions are those actions associated with a set of policy
>conditions in a policy statement.  Examples might be "open a pinhole" or
>"return NAT bindings for a given system".
>
>The middle box MUST understand the policy action it is to take.  The
>semantics and syntax of each of those policy actions MUST be documented in
>a standard.
>
>Hence, policy information SHOULD be encoded in a standard form that is
>possible for a middle box to decode, even if it cannot evaluate each
>policy condition.
>
>Examples of policy statements can be found in [POLICY].
>
>X Duration
>
>Decisions made by middle boxes MUST have a specific duration.  That
>duration MUST include a time interval or a set of actual dates and times,
>and MAY include additional termination conditions.  Examples of
>termination conditions include an exchange of TCP FINs, the excessive use
>of bandwidth, or the exchange of unauthorized content.  A midcom agent MAY
>request a change in duration, but the decision of the middle box, like
>every other decision will be bound by policy.
>--
>Eliot Lear
>lear@cisco.com
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>http://www1.ietf.org/mailman/listinfo/midcom

Michael W. Condry
Director,  Network Edge Technology




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 04:05:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07772
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 04:05:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04585;
	Wed, 8 Aug 2001 04:05:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04556
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 04:05:51 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07767
	for <midcom@ietf.org>; Wed, 8 Aug 2001 04:04:43 -0400 (EDT)
Received: from cisco.com (sjc-vpn1-32.cisco.com [10.21.96.32]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id BAA09120; Wed, 8 Aug 2001 01:05:18 -0700 (PDT)
Message-ID: <3B70F2C2.4845CCD@cisco.com>
Date: Wed, 08 Aug 2001 01:05:22 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Michael W. Condry" <condry@intel.com>
CC: midcom@ietf.org, Ietf-openproxy@imc.org
Subject: Re: [midcom] policy & duration
References: <5.1.0.14.2.20010808001011.01af7308@FMSMSX63.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



"Michael W. Condry" wrote:
> 
> Do you think that alignment between OPES policy and MidCom policy
> concepts should be applied where appropriate?  If so, should the document
> not reflect this?

In as much as it doesn't could you be more specific?  I don't  understand
the OPES space as well as the middle box space.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 04:21:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08002
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 04:21:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04903;
	Wed, 8 Aug 2001 04:21:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04871
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 04:21:52 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07984
	for <midcom@ietf.org>; Wed, 8 Aug 2001 04:20:43 -0400 (EDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f788LV306843;
	Wed, 8 Aug 2001 01:21:31 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f788LKm21290;
	Wed, 8 Aug 2001 01:21:21 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id BAA22532; Wed, 8 Aug 2001 01:21:19 -0700 (PDT)
Message-ID: <02d001c11fe2$fd15aa50$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <lear@cisco.com>, <midcom@ietf.org>
References: <3B700C72.35EC5BD8@cisco.com>
Subject: Re: [midcom] policy & duration
Date: Wed, 8 Aug 2001 04:20:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> In our bar-fob we had a number of issues with policy.  i have promised to
> provide some words to help improve the situation.  I hope this does. 

It does, but on ething that concerns me is that you're
now describing "open a pinhole" as a policy action, which
is a major change in how we've been talking about the
middlebox and middlebox commands.  

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 04:26:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08038
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 04:26:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05017;
	Wed, 8 Aug 2001 04:26:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04994
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 04:26:16 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08031
	for <midcom@ietf.org>; Wed, 8 Aug 2001 04:25:08 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f788NuJ28083;
	Wed, 8 Aug 2001 01:23:56 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f788PsU00814;
	Wed, 8 Aug 2001 01:25:54 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id BAA22927; Wed, 8 Aug 2001 01:25:41 -0700 (PDT)
Message-ID: <02d101c11fe3$99a10b30$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <lear@cisco.com>, <midcom@ietf.org>,
        "Michael W. Condry" <condry@intel.com>
Cc: <Ietf-openproxy@imc.org>
References: <5.1.0.14.2.20010808001011.01af7308@FMSMSX63.intel.com>
Subject: Re: [midcom] policy & duration
Date: Wed, 8 Aug 2001 04:24:51 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> From: "Michael W. Condry" <condry@intel.com>
> To: <lear@cisco.com>; <midcom@ietf.org>
> Cc: <Ietf-openproxy@imc.org>
> Sent: Wednesday, August 08, 2001 3:12 AM
> Subject: Re: [midcom] policy & duration


> Do you think that alignment between OPES policy and MidCom policy
> concepts should be applied where appropriate?  If so, should the document
> not reflect this?

I do think that there's value in trying to keep these aligned,
and it would probably be useful to get some feedback on our 
documents from OPES.  In the interests of keeping our work
moving forward, it would probably be best to regard midcom
and OPES as dating rather than married.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 05:12:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08643
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:12:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06655;
	Wed, 8 Aug 2001 05:12:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06580
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 05:11:58 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08633
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:10:49 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f789Bb322406
	for <midcom@ietf.org>; Wed, 8 Aug 2001 02:11:37 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-41.cisco.com [10.21.96.41])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIS12547;
	Wed, 8 Aug 2001 02:11:15 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 8 Aug 2001 10:11:15 +0100
Date: Wed, 8 Aug 2001 10:11:14 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom mail-list <midcom@ietf.org>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Message-ID: <20010808101114.E1592@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	midcom mail-list <midcom@ietf.org>
References: <002b01c11f3e$12a32640$b89221d9@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002b01c11f3e$12a32640$b89221d9@acmepacket.com>; from bpenfield@acmepacket.com on Tue, Aug 07, 2001 at 08:39:59AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Tue, Aug 07, 2001 at 08:39:59AM -0400, Bob Penfield apparently wrote:
> I personally liked the term "flow" for an individual thing, and the term
> "session" for a group of things. However, a many of those present felt that
> the term "resource" was best to describe an individual pin hole/NAT. A
> "bundle" was suggested for a group of related "resources".
> 
> So here goes.
> 
> Resource:
> A resource is a single instance of a middlebox service for a specific flow
> or stream of packets (e.g. a NAT session or a firewall pin-hole). It defines
> the information necessary to identify incoming packets that are associated
> with the resource and the actions required to dispose of the packets
> (forward them on or drop them). Note that a service may consist of multiple
> functions. For example, a single resource could include both the NAT and
> firewall functions.

Thanks for getting this started.  Naturally I don't like your choices
:-).  If you want to get serious about defining terms, which can quickly
become a rathole ...

A resource is an instance of a service?  I would think the service is
the act of translation, or of forwarding, and a resource is something
which makes it possible to provide the service.  The resource is the
ruleset.  Which makes me think the word "resource" isn't going to help
with clarity.  How about "ruleset"?

A "flow" *is* a stream of packets.  We have talked about microflows,
macroflows, and aggregated flows for years.  No need for the redundancy.  

A "session" usually refers to something with endpoints.  The NAT thing,
the ruleset we're talking about is a bit of state at a single point in
support of communications through it, not the communications itself.
How about a NATting or a NAT ruleset or a NAT translation bundle or ...?

So modifying what you have above: "A ruleset is an embodiment of a
single instance of a middlebox service for a specific flow (e.g. a
firewall pinhole).  It defines the information necessary to identify
incoming packets as associated with the resource and the actions
required to dispose of the packets (forward them on, with or without
translation, or drop them).  Note that a ruleset may consist of multiple
functions.  For example, a single ruleset could include both the NAT and
firewall functions."

> Resource Bundle:
> A resource bundle is a group of resources that have been associated together
> by the application via the midcom agent, which uses the midcom protocol to
> establish the grouping in the middlebox.

Ruleset would cover this too.  We could have a single "rule" but I doubt
we'd ever use it.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 05:23:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08764
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:23:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06956;
	Wed, 8 Aug 2001 05:23:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06924
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 05:23:05 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08759
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:21:56 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f789KkJ12654
	for <midcom@ietf.org>; Wed, 8 Aug 2001 02:20:46 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-41.cisco.com [10.21.96.41])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIS12622;
	Wed, 8 Aug 2001 02:22:32 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 8 Aug 2001 10:22:31 +0100
Date: Wed, 8 Aug 2001 10:22:31 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Interim rev. of the famework draft
Message-ID: <20010808102231.F1592@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com>; from sanjoy@nortelnetworks.com on Tue, Aug 07, 2001 at 11:22:50PM -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Tue, Aug 07, 2001 at 11:22:50PM -0500, Sanjoy Sen apparently wrote:
> 1) In Section 4 - Midcom Protocol - it has been stated that the Midcom
> protocol will consist of a connection set-up phase, run-time phase and a
> connection termination phase. The meaning of "connection" is not clear.   

The concept of a "connection" is dubious and should be discussed.  Agent
and middlebox need to authenticate/authorize and then ensure that their
state is synchronized.  That's about it.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 05:25:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08795
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:25:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06741;
	Wed, 8 Aug 2001 05:15:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06712
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 05:15:21 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08668
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:14:12 -0400 (EDT)
Received: from cisco.com (sjc-vpn2-65.cisco.com [10.21.112.65]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA01397; Wed, 8 Aug 2001 02:14:49 -0700 (PDT)
Message-ID: <3B71030D.5217480A@cisco.com>
Date: Wed, 08 Aug 2001 02:14:53 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <02d001c11fe2$fd15aa50$7c8921d9@NAUGA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Melinda,

A firewall is all about policy actions.  A NAT is similar. 
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 05:51:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09179
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:51:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07959;
	Wed, 8 Aug 2001 05:48:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07928
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 05:48:19 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09138
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:47:10 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f789mH328003
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:48:17 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA05494; Wed, 8 Aug 2001 11:48:16 +0200 (MET DST)
Cc: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA05483; Wed, 8 Aug 2001 11:48:13 +0200 (MET DST)
Message-ID: <3B710AAF.8610B61D@lucent.com>
Date: Wed, 08 Aug 2001 11:47:27 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: lear@cisco.com
Original-CC: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <02d001c11fe2$fd15aa50$7c8921d9@NAUGA> <3B71030D.5217480A@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I agree with Melinda on this one.

The way I see it:
- Policies should be the genric rules of engagement.
- The pinholes are *on demand* things requested by the MIDCOM agents
subject to the policies.

Paul

Eliot Lear wrote:
> 
> Melinda,
> 
> A firewall is all about policy actions.  A NAT is similar.
> --
> Eliot Lear
> lear@cisco.com
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 05:57:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09253
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:57:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08263;
	Wed, 8 Aug 2001 05:57:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08232
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 05:57:36 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09229
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:56:27 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f789vY329989
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:57:34 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA07681; Wed, 8 Aug 2001 11:57:33 +0200 (MET DST)
Cc: midcom mail-list <midcom@ietf.org>
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA07665; Wed, 8 Aug 2001 11:57:29 +0200 (MET DST)
Message-ID: <3B710CE7.E1CC46EC@lucent.com>
Date: Wed, 08 Aug 2001 11:56:55 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Brim <sbrim@cisco.com>
Original-CC: midcom mail-list <midcom@ietf.org>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
References: <002b01c11f3e$12a32640$b89221d9@acmepacket.com> <20010808101114.E1592@SBRIM-W2K>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I had the feeling that in some MIDCOM writings SESSION was used as a
shorthand for REGISTRATION SESSION. Which is fine as long as we all agree.
Since we don't a synonym is needed for this.

In my mind: 
- a flow is the thing you open the pinhole for
- an aggregate is a bunch of flows.


Paul

Scott Brim wrote:
> 
> On Tue, Aug 07, 2001 at 08:39:59AM -0400, Bob Penfield apparently wrote:
> > I personally liked the term "flow" for an individual thing, and the term
> > "session" for a group of things. However, a many of those present felt that
> > the term "resource" was best to describe an individual pin hole/NAT. A
> > "bundle" was suggested for a group of related "resources".
> >
> > So here goes.
> >
> > Resource:
> > A resource is a single instance of a middlebox service for a specific flow
> > or stream of packets (e.g. a NAT session or a firewall pin-hole). It defines
> > the information necessary to identify incoming packets that are associated
> > with the resource and the actions required to dispose of the packets
> > (forward them on or drop them). Note that a service may consist of multiple
> > functions. For example, a single resource could include both the NAT and
> > firewall functions.
> 
> Thanks for getting this started.  Naturally I don't like your choices
> :-).  If you want to get serious about defining terms, which can quickly
> become a rathole ...
> 
> A resource is an instance of a service?  I would think the service is
> the act of translation, or of forwarding, and a resource is something
> which makes it possible to provide the service.  The resource is the
> ruleset.  Which makes me think the word "resource" isn't going to help
> with clarity.  How about "ruleset"?
> 
> A "flow" *is* a stream of packets.  We have talked about microflows,
> macroflows, and aggregated flows for years.  No need for the redundancy.
> 
> A "session" usually refers to something with endpoints.  The NAT thing,
> the ruleset we're talking about is a bit of state at a single point in
> support of communications through it, not the communications itself.
> How about a NATting or a NAT ruleset or a NAT translation bundle or ...?
> 
> So modifying what you have above: "A ruleset is an embodiment of a
> single instance of a middlebox service for a specific flow (e.g. a
> firewall pinhole).  It defines the information necessary to identify
> incoming packets as associated with the resource and the actions
> required to dispose of the packets (forward them on, with or without
> translation, or drop them).  Note that a ruleset may consist of multiple
> functions.  For example, a single ruleset could include both the NAT and
> firewall functions."
> 
> > Resource Bundle:
> > A resource bundle is a group of resources that have been associated together
> > by the application via the midcom agent, which uses the midcom protocol to
> > establish the grouping in the middlebox.
> 
> Ruleset would cover this too.  We could have a single "rule" but I doubt
> we'd ever use it.
> 
> ..Scott
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 05:58:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09280
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:58:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08320;
	Wed, 8 Aug 2001 05:58:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08290
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 05:58:34 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09248
	for <midcom@ietf.org>; Wed, 8 Aug 2001 05:57:25 -0400 (EDT)
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id CAA00289;
	Wed, 8 Aug 2001 02:57:56 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id CAA09445;
	Wed, 8 Aug 2001 02:58:30 -0700 (PDT)
Received: from xch-pssbh-03.nw.nos.boeing.com (xch-pssbh-03.nw.nos.boeing.com [134.52.3.95])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id f789wUX04600;
	Wed, 8 Aug 2001 02:58:30 -0700 (PDT)
Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <QHA5SBM2>; Wed, 8 Aug 2001 02:58:30 -0700
Message-ID: <8006AC6A777F3F4F8B2A6383C19C5B7A05502EF0@XCH-NW-01.nw.nos.boeing.com>
From: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>
To: lear@cisco.com, midcom@ietf.org, "Michael W. Condry"
	 <condry@intel.com>,
        "'Melinda Shore'" <mshore@cisco.com>
Cc: Ietf-openproxy@imc.org
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 02:58:29 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I see OPES and midcom addressing very dissimilar problems. I do not view the problems of enhancing web services (OPES) as directly related to the problems of opening pinholes through perimeter devices in a manner consistent with enterprise policies (midcom). I therefore do not think that OPES has a role in providing feedback to midcom documents that is any more relevant than the insights coming from other IETF WGs. Thus, even a "dating relationship" is unnecessary.

> ----------
> From: 	Melinda Shore[SMTP:mshore@cisco.com]
> Sent: 	Wednesday, August 08, 2001 1:24 AM
> To: 	lear@cisco.com; midcom@ietf.org; Michael W. Condry
> Cc: 	Ietf-openproxy@imc.org
> Subject: 	Re: [midcom] policy & duration
> 
> > From: "Michael W. Condry" <condry@intel.com>
> > To: <lear@cisco.com>; <midcom@ietf.org>
> > Cc: <Ietf-openproxy@imc.org>
> > Sent: Wednesday, August 08, 2001 3:12 AM
> > Subject: Re: [midcom] policy & duration
> 
> 
> > Do you think that alignment between OPES policy and MidCom policy
> > concepts should be applied where appropriate?  If so, should the document
> > not reflect this?
> 
> I do think that there's value in trying to keep these aligned,
> and it would probably be useful to get some feedback on our 
> documents from OPES.  In the interests of keeping our work
> moving forward, it would probably be best to regard midcom
> and OPES as dating rather than married.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 06:10:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09450
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:10:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08831;
	Wed, 8 Aug 2001 06:10:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08806
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 06:10:32 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com ([47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09414
	for <midcom@ietf.org>; Wed, 8 Aug 2001 06:09:18 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f78A9fg04409
	for <midcom@ietf.org>; Wed, 8 Aug 2001 11:09:41 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 8 Aug 2001 11:09:12 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PSC000AX>; Wed, 8 Aug 2001 11:09:10 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445177@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom <midcom@ietf.org>
Subject: RE: [midcom] Framework confabulation
Date: Wed, 8 Aug 2001 11:09:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11FF2.2C1D9F10"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11FF2.2C1D9F10
Content-Type: text/plain;
	charset="iso-8859-1"

I propose to meet at the Thames suite I booked the room from 19h30 to
midnight, and Suresh could dial in in it and we could do whiteboarding with
netmeeting.
Thames suite is on first floor above the Hilton main reception, Suresh you
could call us at +44 207402 4141 ext number 8742
See you there
Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, August 07, 2001 4:52 PM
To: midcom
Subject: [midcom] Framework confabulation


Reminder: get-together on Thursday at 19:30 to discuss what
issues need resolution to get the framework document through 
last call.  Meet in lounge across from reception.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C11FF2.2C1D9F10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Framework confabulation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I propose to meet at the Thames suite I booked the =
room from 19h30 to midnight, and Suresh could dial in in it and we =
could do whiteboarding with netmeeting.</FONT></P>

<P><FONT SIZE=3D2>Thames suite is on first floor above the Hilton main =
reception, Suresh you could call us at +44 207402 4141 ext number =
8742</FONT></P>

<P><FONT SIZE=3D2>See you there</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, August 07, 2001 4:52 PM</FONT>
<BR><FONT SIZE=3D2>To: midcom</FONT>
<BR><FONT SIZE=3D2>Subject: [midcom] Framework confabulation</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Reminder: get-together on Thursday at 19:30 to =
discuss what</FONT>
<BR><FONT SIZE=3D2>issues need resolution to get the framework document =
through </FONT>
<BR><FONT SIZE=3D2>last call.&nbsp; Meet in lounge across from =
reception.</FONT>
</P>

<P><FONT SIZE=3D2>Melinda</FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11FF2.2C1D9F10--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 06:17:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09547
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:17:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08968;
	Wed, 8 Aug 2001 06:17:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08937
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 06:17:23 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09500
	for <midcom@ietf.org>; Wed, 8 Aug 2001 06:16:16 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f78AH4Y00591
	for <midcom@ietf.org>; Wed, 8 Aug 2001 03:17:04 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-41.cisco.com [10.21.96.41])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIS12793;
	Wed, 8 Aug 2001 02:57:14 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 8 Aug 2001 10:57:13 +0100
Date: Wed, 8 Aug 2001 10:57:12 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
Message-ID: <20010808105712.I1592@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3B700C72.35EC5BD8@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B700C72.35EC5BD8@cisco.com>; from lear@cisco.com on Tue, Aug 07, 2001 at 08:42:42AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Nice.  Naturally I have comments.

On Tue, Aug 07, 2001 at 08:42:42AM -0700, Eliot Lear apparently wrote:
> 4.3  Policy
> 
> Each middlebox decision is made based on either configured policy or by
> querying a policy server.  While it is not within the midcom rubric to

By implication this leaves out the possibility of a middlebox receiving
all policy regarding a particular agent at the time that agent is
authenticated.  That is, the possibility that the middlebox does not
need to refer to the policy server for decisions on individual
transactions at the times of the transactions.  I suggest simply
changing "querying" to "policy received from".

Also change rubric to scope?  Never use a correct word when a
well-understood word will do? :-)

> specify policy configuration methods, the actual policy configuration
> itself is important to discuss.
> 
> A policy statement consists of one or more policy conditions and a policy
> action.[policy]

Is this a new document?

> 4.3.1 Policy conditions
> 
> Some policy decisions, such as those based on 5-tuple simple access lists
> are likely to be made by a middle box.  Other decisions, however, are
> likely to be more complex.  Hence we propose a nuanced approach that
> allows the policy function to be split.
> 
> The midcom agent MUST be able to satisfy informational requirements of the
> policy conditions in a policy statement in order for the policy server to
> make a decision.  Therefore, a structured exchange that contains those
> components MUST occur between the midcom agent and the middlebox, both
> query and response.  In as much as a policy server is required to resolve
> the policy conditions, a structured exchange MUST also occur between the
> middle box and the policy server.
> 
> If a middle box acts as its own policy server, it MUST understand any
> policy information needed to execute a policy statement.  Put another way,
> it MAY discard any policy information that it doesn't understand so long
> as that information is not required to make a policy decision.
> 
> If the middle box does not understand all of the policy conditions, it
> MUST refer the request to a policy server.  It is a configuration error to
> have a policy condition that neither the middle box nor the policy agent
> can evaluate.
> 
> A middle box SHOULD understand, at a minimum, policy conditions that
> contain the interfaces involved, protocol, source address and port,
> destination address and port, all of which with the exception of protocol
> and interfaces MUST be capable of being expressed as a range of values. 
> This is the trivial case, necessary to deploy a middlebox without the
> assistance of a policy server.

There's a hint of directionality in here, which we're still debating.

> One should expect a middle box that understands a given policy condition
> to police it.  However, we do not require it.

I don't know what it means, to police it.

> 4.3.2 Policy actions
> 
> Policy actions are those actions associated with a set of policy
> conditions in a policy statement.  Examples might be "open a pinhole" or
> "return NAT bindings for a given system".

Wouldn't the policy action be to *install* such a rule(set), not the
rule(set) itself?

> The middle box MUST understand the policy action it is to take.  The
> semantics and syntax of each of those policy actions MUST be documented in
> a standard.
> 
> Hence, policy information SHOULD be encoded in a standard form that is
> possible for a middle box to decode, even if it cannot evaluate each
> policy condition.
> 
> Examples of policy statements can be found in [POLICY].
> 
> X Duration
> 
> Decisions made by middle boxes MUST have a specific duration.  That
> duration MUST include a time interval or a set of actual dates and times,

Time intervals are under debate (and I hope they lose).

> and MAY include additional termination conditions.  Examples of
> termination conditions include an exchange of TCP FINs, the excessive use
> of bandwidth, or the exchange of unauthorized content.  A midcom agent MAY
> request a change in duration, but the decision of the middle box, like
> every other decision will be bound by policy.

Thanks for doing this!

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 06:21:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09606
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:21:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09180;
	Wed, 8 Aug 2001 06:21:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09149
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 06:21:00 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09594
	for <midcom@ietf.org>; Wed, 8 Aug 2001 06:19:53 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f78AKe313456
	for <midcom@ietf.org>; Wed, 8 Aug 2001 03:20:40 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-41.cisco.com [10.21.96.41])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIS12876;
	Wed, 8 Aug 2001 03:20:25 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 8 Aug 2001 11:20:22 +0100
Date: Wed, 8 Aug 2001 11:20:21 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
Message-ID: <20010808112021.L1592@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3B700C72.35EC5BD8@cisco.com> <02d001c11fe2$fd15aa50$7c8921d9@NAUGA> <3B71030D.5217480A@cisco.com> <3B710AAF.8610B61D@lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B710AAF.8610B61D@lucent.com>; from sijben@lucent.com on Wed, Aug 08, 2001 at 11:47:27AM +0200
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 08, 2001 at 11:47:27AM +0200, Paul Sijben apparently wrote:
> I agree with Melinda on this one.
> 
> The way I see it:
> - Policies should be the genric rules of engagement.
> - The pinholes are *on demand* things requested by the MIDCOM agents
> subject to the policies.

Pinholes are rulesets functionally.  Rulesets are the reification of
policy.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 06:31:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09769
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:31:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09695;
	Wed, 8 Aug 2001 06:31:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09661
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 06:31:22 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09753
	for <midcom@ietf.org>; Wed, 8 Aug 2001 06:30:15 -0400 (EDT)
Received: from BobP [217.33.146.184] by acmepacket.com
  (SMTPD32-6.05) id A4617F81011E; Wed, 08 Aug 2001 06:28:49 -0400
Message-ID: <002701c11ff5$2acb4e20$b89221d9@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "midcom mail-list" <midcom@ietf.org>
Cc: "Dr. Carsten Bormann" <cabo@tzi.org>
Subject: Fw: [midcom] pin-holes, sessions and flows, oh my!
Date: Wed, 8 Aug 2001 06:30:37 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: "Bob Penfield" <bpenfield@acmepacket.com>
Sent: Tuesday, August 07, 2001 10:45 AM
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!


> > Resource:
> > A resource is a single instance of a middlebox service for a specific
flow
> > or stream of packets (e.g. a NAT session or a firewall pin-hole).
>
> No.  A resource is something you get from a Web-Server.  Or the
Web-Server.
> Or the thing you can reserve.  Or the reservation.  Or the human in front
of
> the box :-)
>
> Please use a term that does not already have 1E6 other meanings.  Pin-hole
> at least meant something.
>
> Gruesse, Carsten
>
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 06:41:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09849
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:41:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09834;
	Wed, 8 Aug 2001 06:36:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09801
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 06:36:41 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09812
	for <midcom@ietf.org>; Wed, 8 Aug 2001 06:35:34 -0400 (EDT)
Received: from BobP [217.33.146.184] by acmepacket.com
  (SMTPD32-6.05) id A5A17F86011E; Wed, 08 Aug 2001 06:34:09 -0400
Message-ID: <003401c11ff5$e9213240$b89221d9@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Sanjoy Sen" <sanjoy@nortelnetworks.com>,
        "'Pyda Srisuresh'" <srisuresh@yahoo.com>, <midcom@ietf.org>
References: <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com>
Subject: Re: [midcom] Interim rev. of the famework draft
Date: Wed, 8 Aug 2001 06:35:56 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Pyda Srisuresh'" <srisuresh@yahoo.com>; <midcom@ietf.org>
Sent: Wednesday, August 08, 2001 12:22 AM
Subject: RE: [midcom] Interim rev. of the famework draft


> I've the following questions/comments on the Interim draft:
>
>
> 1) In Section 4 - Midcom Protocol - it has been stated that the Midcom
> protocol will consist of a connection set-up phase, run-time phase and a
> connection termination phase. The meaning of "connection" is not clear.
>
> 2) In timeline flow in Section 7.1, how would the SIP proxy identify the
> end-to-end RTP, RTCP sessions from the private SIP UA to the external UA
on
> receiving the INVITE from external SIP UA? The INVITE SDP does not contain
> any information of the RTP port of the media source.

End-2-end may not necessarily be a good choice of words, but at this point
all the information that the proxy is going to get on the RTP stream from
private phone to the external phone is know. Information of the RTP port of
the media source is not included either the INVITE's SDP or the 200-OK's
SDP. The RTP destination that the private phone provides in the 200-OK is
not necessarily the source of the media flowing from the private phone to
the external phone.

>
> 3) In Section 7.2, what does creating "NAT session descriptors" mean? In
> this context, the authors implied that this allows the early media flow
> through the NAT. From the prior definition of session state, I would tend
to
> think that the flow will be allowed (or disallowed) only after a session
> state (i.e., session descriptor + attributes) is created & a function
> specific resource (e.g., NAT bind) is associated with the session state.
Is
> this correct? Please clarify.
>
> Thanks,
> Sanjoy
>
>
> > -----Original Message-----
> > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
> > Sent: Sunday, August 05, 2001 5:58 AM
> > To: midcom@ietf.org
> > Subject: [midcom] Interim rev. of the famework draft
> >
> >
> > Folks,
> >
> > Please find attached the interim rev. framework draft.
> > You may use this as reference during the editorial meeting.
> > Thanks.
> >
> > regards,
> > suresh
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute with
> > Yahoo! Messenger
> > http://phonecard.yahoo.com/
> >
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 07:15:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10179
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 07:15:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10620;
	Wed, 8 Aug 2001 07:11:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10593
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 07:11:03 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10151
	for <midcom@ietf.org>; Wed, 8 Aug 2001 07:09:55 -0400 (EDT)
Received: from BobP [217.33.146.184] by acmepacket.com
  (SMTPD32-6.05) id ADAC7F8C011E; Wed, 08 Aug 2001 07:08:28 -0400
Message-ID: <005501c11ffa$b46b4ae0$b89221d9@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Scott Brim" <sbrim@cisco.com>, "midcom mail-list" <midcom@ietf.org>
References: <002b01c11f3e$12a32640$b89221d9@acmepacket.com> <20010808101114.E1592@SBRIM-W2K>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Date: Wed, 8 Aug 2001 07:10:15 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Scott Brim <sbrim@cisco.com> wrote:
> A resource is an instance of a service?  I would think the service is
> the act of translation, or of forwarding, and a resource is something
> which makes it possible to provide the service.  The resource is the
> ruleset.  Which makes me think the word "resource" isn't going to help
> with clarity.  How about "ruleset"?

I too do not really like the term "resource". I think ruleset is better. In
our development, we have been calling this thing in the middlebox a "flow
specification".

>
> A "flow" *is* a stream of packets.  We have talked about microflows,
> macroflows, and aggregated flows for years.  No need for the redundancy.
>
> A "session" usually refers to something with endpoints.  The NAT thing,
> the ruleset we're talking about is a bit of state at a single point in
> support of communications through it, not the communications itself.
> How about a NATting or a NAT ruleset or a NAT translation bundle or ...?

Actually, I got the term "NAT session" from RFC 2663.

>
> So modifying what you have above: "A ruleset is an embodiment of a
> single instance of a middlebox service for a specific flow (e.g. a
> firewall pinhole).  It defines the information necessary to identify
> incoming packets as associated with the resource and the actions
> required to dispose of the packets (forward them on, with or without
> translation, or drop them).  Note that a ruleset may consist of multiple
> functions.  For example, a single ruleset could include both the NAT and
> firewall functions."

The phrase "as associated with a resource" in the second sentence should be
removed OR the word "resource" changed to "ruleset".

>
> > Resource Bundle:
> > A resource bundle is a group of resources that have been associated
together
> > by the application via the midcom agent, which uses the midcom protocol
to
> > establish the grouping in the middlebox.
>
> Ruleset would cover this too.  We could have a single "rule" but I doubt
> we'd ever use it.

I still think we need a separate term for this because it is not a ruleset
itself, but a set of rulesets. The rulesets for the individual flows might
be associated together as the midcom agent establishes them, or as a
separate action after the individual rulesets were created. From that point
on, the midcom agent may make requests for a specific ruleset or for the
bundle as a whole. With SIP there are lots of cases where the application
needs to add, remove, or modify individual rulesets within a group. In SIP
words: add, remove, or modify RTP streams within a SIP session.

We could call it a ruleset group or ruleset bundle. I envision that a
middlebox would instantiate a bundle as just a set of pointers to the
rulesets it contains. I realize that is a middlebox implementation choice,
but I'm using it as an example of how it might be implemented.

The protocol needs to support an identify for a ruleset and an identifier
for the group too so that the midcom agent can request actions on a given
ruleset or on the whole group. These identifiers may be given out by the
middlebox or defined by the midcom agent.

(-:bob


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 07:15:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10193
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 07:15:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10703;
	Wed, 8 Aug 2001 07:15:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10669
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 07:15:27 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10174
	for <midcom@ietf.org>; Wed, 8 Aug 2001 07:14:19 -0400 (EDT)
Received: from BobP [217.33.146.184] by acmepacket.com
  (SMTPD32-6.05) id AEB27F92011E; Wed, 08 Aug 2001 07:12:50 -0400
Message-ID: <006901c11ffb$51127120$b89221d9@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Paul Sijben" <sijben@lucent.com>, <lear@cisco.com>
Cc: "Melinda Shore" <mshore@cisco.com>, <midcom@ietf.org>
References: <3B700C72.35EC5BD8@cisco.com> <02d001c11fe2$fd15aa50$7c8921d9@NAUGA> <3B71030D.5217480A@cisco.com> <3B710AAF.8610B61D@lucent.com>
Subject: Re: [midcom] policy & duration
Date: Wed, 8 Aug 2001 07:14:38 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Paul Sijben" <sijben@lucent.com>
To: <lear@cisco.com>
Cc: "Melinda Shore" <mshore@cisco.com>; <midcom@ietf.org>
Sent: Wednesday, August 08, 2001 5:47 AM
Subject: Re: [midcom] policy & duration


> I agree with Melinda on this one.
>
> The way I see it:
> - Policies should be the genric rules of engagement.
> - The pinholes are *on demand* things requested by the MIDCOM agents
> subject to the policies.

However, we should not exclude the possiblity that the middlebox may want to
consult the policy server when the "demand" occurs.

>
> Paul
>
> Eliot Lear wrote:
> >
> > Melinda,
> >
> > A firewall is all about policy actions.  A NAT is similar.
> > --
> > Eliot Lear
> > lear@cisco.com
> >
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www1.ietf.org/mailman/listinfo/midcom
>
> --
> Paul Sijben              Tel:+31 356874774
> Lucent Technologies      Fax:+31 356875954
> Forward Looking Work
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 08:10:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10796
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:10:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12072;
	Wed, 8 Aug 2001 08:07:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12040
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 08:07:11 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10719
	for <midcom@ietf.org>; Wed, 8 Aug 2001 08:06:02 -0400 (EDT)
Received: from cisco.com (sjc-vpn1-16.cisco.com [10.21.96.16]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA23700; Wed, 8 Aug 2001 05:06:36 -0700 (PDT)
Message-ID: <3B712B50.72F90C77@cisco.com>
Date: Wed, 08 Aug 2001 05:06:40 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Sijben <sijben@lucent.com>
CC: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <02d001c11fe2$fd15aa50$7c8921d9@NAUGA> <3B71030D.5217480A@cisco.com> <3B710AAF.8610B61D@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Paul,

I seem to have introduced some confusion.  The MIDCOM protocol ought not
require the exchange of policy.  It MUST facilitate the exchange of that
information needed to satisfy policy conditions.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 08:19:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10935
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:19:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12297;
	Wed, 8 Aug 2001 08:19:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12269
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 08:19:17 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10912
	for <midcom@ietf.org>; Wed, 8 Aug 2001 08:18:08 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f78CIfg09797;
	Wed, 8 Aug 2001 05:18:41 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f78CIqZ23958;
	Wed, 8 Aug 2001 05:18:52 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id FAA14178; Wed, 8 Aug 2001 05:18:40 -0700 (PDT)
Message-ID: <013901c12004$250d9650$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>, "midcom" <midcom@ietf.org>
References: <9154CB41F208D5118DD200508BE39C30445177@zjguc006.europe.nortel.com>
Subject: Re: [midcom] Framework confabulation
Date: Wed, 8 Aug 2001 08:17:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Okay, let's do this rather than meet in the lounge.
See you all in the Thames suite.

Melinda

----- Original Message -----
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>; "midcom" <midcom@ietf.org>
Sent: Wednesday, August 08, 2001 6:09 AM
Subject: RE: [midcom] Framework confabulation


> I propose to meet at the Thames suite I booked the room from 19h30 to
> midnight, and Suresh could dial in in it and we could do whiteboarding
with
> netmeeting.
> Thames suite is on first floor above the Hilton main reception, Suresh you
> could call us at +44 207402 4141 ext number 8742
> See you there
> Cedric
>
> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, August 07, 2001 4:52 PM
> To: midcom
> Subject: [midcom] Framework confabulation
>
>
> Reminder: get-together on Thursday at 19:30 to discuss what
> issues need resolution to get the framework document through
> last call.  Meet in lounge across from reception.
>
> Melinda
>
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 08:40:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11326
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:40:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13151;
	Wed, 8 Aug 2001 08:36:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13084
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 08:36:01 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11182
	for <midcom@ietf.org>; Wed, 8 Aug 2001 08:34:52 -0400 (EDT)
Received: from cisco.com (sjc-vpn1-16.cisco.com [10.21.96.16]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA03952; Wed, 8 Aug 2001 05:35:29 -0700 (PDT)
Message-ID: <3B713214.11AE0A1@cisco.com>
Date: Wed, 08 Aug 2001 05:35:32 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Brim <sbrim@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Scott Brim wrote:
> 
> Nice.  Naturally I have comments.
> 
> On Tue, Aug 07, 2001 at 08:42:42AM -0700, Eliot Lear apparently wrote:
> > 4.3  Policy
> >
> > Each middlebox decision is made based on either configured policy or by
> > querying a policy server.  While it is not within the midcom rubric to
> 
> By implication this leaves out the possibility of a middlebox receiving
> all policy regarding a particular agent at the time that agent is
> authenticated.  That is, the possibility that the middlebox does not
> need to refer to the policy server for decisions on individual
> transactions at the times of the transactions.  I suggest simply
> changing "querying" to "policy received from".

That's fine.

> > specify policy configuration methods, the actual policy configuration
> > itself is important to discuss.
> >
> > A policy statement consists of one or more policy conditions and a policy
> > action.[policy]
> 
> Is this a new document?

No, I'll send some pointers.

> 
> > 4.3.1 Policy conditions
> [...]
> There's a hint of directionality in here, which we're still debating.

First, very basic packet firewalls understand packets and not connections
or conversations.  I don't know that we want to require much more than
that.

Also, I think we remove directionality at our peril.  In an
internal/external communication, the reversing of directional rules on
interfaces would lead to a weakening of enterprise security.

> 
> > One should expect a middle box that understands a given policy condition
> > to police it.  However, we do not require it.
> 
> I don't know what it means, to police it.

as in, ensure the communication proceeds as specified in the request.

> > 4.3.2 Policy actions
> >
> > Policy actions are those actions associated with a set of policy
> > conditions in a policy statement.  Examples might be "open a pinhole" or
> > "return NAT bindings for a given system".
> 
> Wouldn't the policy action be to *install* such a rule(set), not the
> rule(set) itself?

IMHO Policy is declarative.
 
> > The middle box MUST understand the policy action it is to take.  The
> > semantics and syntax of each of those policy actions MUST be documented in
> > a standard.
> >
> > Hence, policy information SHOULD be encoded in a standard form that is
> > possible for a middle box to decode, even if it cannot evaluate each
> > policy condition.
> >
> > Examples of policy statements can be found in [POLICY].
> >
> > X Duration
> >
> > Decisions made by middle boxes MUST have a specific duration.  That
> > duration MUST include a time interval or a set of actual dates and times,
> 
> Time intervals are under debate (and I hope they lose).
> 
> > and MAY include additional termination conditions.  Examples of
> > termination conditions include an exchange of TCP FINs, the excessive use
> > of bandwidth, or the exchange of unauthorized content.  A midcom agent MAY
> > request a change in duration, but the decision of the middle box, like
> > every other decision will be bound by policy.
> 
> Thanks for doing this!
> 
> ..Scott
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 08:46:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11468
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:46:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13487;
	Wed, 8 Aug 2001 08:41:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13453
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 08:41:51 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11340
	for <midcom@ietf.org>; Wed, 8 Aug 2001 08:40:42 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f78CflI27027
	for <midcom@ietf.org>; Wed, 8 Aug 2001 08:41:48 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA18873; Wed, 8 Aug 2001 14:41:46 +0200 (MET DST)
Cc: midcom@ietf.org
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA18850; Wed, 8 Aug 2001 14:41:44 +0200 (MET DST)
Message-ID: <3B7133B7.CAEFAC4E@lucent.com>
Date: Wed, 08 Aug 2001 14:42:31 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Brim <sbrim@cisco.com>
Original-CC: midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <02d001c11fe2$fd15aa50$7c8921d9@NAUGA> <3B71030D.5217480A@cisco.com> <3B710AAF.8610B61D@lucent.com> <20010808112021.L1592@SBRIM-W2K>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I beg to differ. Pinholes MAY be *described* by rulesets. Policies MAY
ALSO be *described* by rulesets. 

Functionally they are different things.

Paul

Scott Brim wrote:
> 
> On Wed, Aug 08, 2001 at 11:47:27AM +0200, Paul Sijben apparently wrote:
> > I agree with Melinda on this one.
> >
> > The way I see it:
> > - Policies should be the genric rules of engagement.
> > - The pinholes are *on demand* things requested by the MIDCOM agents
> > subject to the policies.
> 
> Pinholes are rulesets functionally.  Rulesets are the reification of
> policy.
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 10:16:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13168
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 10:16:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16768;
	Wed, 8 Aug 2001 10:14:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16741
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 10:14:11 -0400 (EDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13078
	for <midcom@ietf.org>; Wed, 8 Aug 2001 10:13:01 -0400 (EDT)
Received: from [217.33.147.176] (helo=mduffy)
	by relay3.bt.net with smtp (Exim 3.22 #1)
	id 15UU5Y-0004Ha-00; Wed, 08 Aug 2001 15:13:36 +0100
Message-Id: <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 08 Aug 2001 09:16:41 -0400
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "midcom mail-list" <midcom@ietf.org>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
In-Reply-To: <002b01c11f3e$12a32640$b89221d9@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi,

I think by bundling so much into one conceptual item (resourse aka ruleset)
we will make our job harder.  I would view this thing as being composed of
several important subcomponents that also need to be named:

1.  a specification for what packets the rule is to match (the
5/6/7/whatever-tuple of source/dest address, etc.)
2.  a list of middlebox service actions to be applied (e.g.
pass/drop/nat/etc).
(Each of the above 1 and 2 might also contain other auxiliary attributes
such as expiration time, and/or such attributes might belong to the
resource/ruleset as a whole.) 

In fact, Bob calls out those components but does not name them.  I suggest
we need some terminology for those, perhaps resource-descriptor and
resource-action (or ruleset-descriptor, ruleset-action).


Relative to Bob's 7 Aug msg re "resource (p.k.a. pin-hole) operations"
which proposes additional operations such as create and delete, I would
suggest there should be operations to add/delete ruleset-descriptors and
ruleset-actions to rulesets.


I do agree we also need the concept resource-bundle (or ruleset-bundle or
foobar-bundle).

--Mark



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 10:22:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13343
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 10:22:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17151;
	Wed, 8 Aug 2001 10:23:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17122
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 10:23:06 -0400 (EDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13311
	for <midcom@ietf.org>; Wed, 8 Aug 2001 10:21:58 -0400 (EDT)
Received: from [217.33.147.176] (helo=mduffy)
	by relay3.bt.net with smtp (Exim 3.22 #1)
	id 15UUE7-0004kI-00; Wed, 08 Aug 2001 15:22:27 +0100
Message-Id: <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 08 Aug 2001 10:21:42 -0400
To: lear@cisco.com, Scott Brim <sbrim@cisco.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <3B713214.11AE0A1@cisco.com>
References: <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 05:35 AM 8/8/01 -0700, Eliot Lear wrote:
>Scott Brim wrote:
...
>> There's a hint of directionality in here, which we're still debating.
>
>First, very basic packet firewalls understand packets and not connections
>or conversations.  I don't know that we want to require much more than
>that.
>
>Also, I think we remove directionality at our peril.  In an
>internal/external communication, the reversing of directional rules on
>interfaces would lead to a weakening of enterprise security.

Not only that, but the directionality is already an aspect of the existing
firewall functionality we are providing control over.  I too believe
directionality should be included.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 11:10:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14581
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 11:10:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19737;
	Wed, 8 Aug 2001 11:05:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19706
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 11:05:45 -0400 (EDT)
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14370
	for <midcom@ietf.org>; Wed, 8 Aug 2001 11:04:37 -0400 (EDT)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id PAA21368;
	Wed, 8 Aug 2001 15:04:20 GMT
Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 08 Aug 2001 15:04:20 0000 (GMT)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by orsmsx28.jf.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id QPB2YVJG; Wed, 8 Aug 2001 06:57:05 -0700
Received: from condryvaio-mobl.intel.com ([10.7.248.81]) by 192.168.65.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 08 Aug 2001 13:57:02 0000 (GMT)
Message-Id: <5.1.0.14.2.20010808065010.01bd5450@FMSMSX63.intel.com>
X-Sender: mwcondry@FMSMSX63.intel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 Aug 2001 06:53:21 -0700
To: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>, lear@cisco.com,
        midcom@ietf.org, "'Melinda Shore'" <mshore@cisco.com>
From: "Michael W. Condry" <condry@intel.com>
Subject: RE: [midcom] policy & duration
Cc: Ietf-openproxy@imc.org
In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A05502EF0@XCH-NW-01.nw.nos.
 boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I agree about the dissimilar problem space.
However, I still stand by the position that IF there areas of problem overlap,
such as some policy matters, that ignoring each others requirements
is a beneficial strategy (or "Dating Relationship").

At 02:58 AM 8/8/2001, Fleischman, Eric W wrote:
>I see OPES and midcom addressing very dissimilar problems. I do not view 
>the problems of enhancing web services (OPES) as directly related to the 
>problems of opening pinholes through perimeter devices in a manner 
>consistent with enterprise policies (midcom). I therefore do not think 
>that OPES has a role in providing feedback to midcom documents that is any 
>more relevant than the insights coming from other IETF WGs. Thus, even a 
>"dating relationship" is unnecessary.
>
> > ----------
> > From:         Melinda Shore[SMTP:mshore@cisco.com]
> > Sent:         Wednesday, August 08, 2001 1:24 AM
> > To:   lear@cisco.com; midcom@ietf.org; Michael W. Condry
> > Cc:   Ietf-openproxy@imc.org
> > Subject:      Re: [midcom] policy & duration
> >
> > > From: "Michael W. Condry" <condry@intel.com>
> > > To: <lear@cisco.com>; <midcom@ietf.org>
> > > Cc: <Ietf-openproxy@imc.org>
> > > Sent: Wednesday, August 08, 2001 3:12 AM
> > > Subject: Re: [midcom] policy & duration
> >
> >
> > > Do you think that alignment between OPES policy and MidCom policy
> > > concepts should be applied where appropriate?  If so, should the document
> > > not reflect this?
> >
> > I do think that there's value in trying to keep these aligned,
> > and it would probably be useful to get some feedback on our
> > documents from OPES.  In the interests of keeping our work
> > moving forward, it would probably be best to regard midcom
> > and OPES as dating rather than married.
> >
> > Melinda
> >
> >
> >
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www1.ietf.org/mailman/listinfo/midcom
> >

Michael W. Condry
Director,  Network Edge Technology




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 11:23:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14927
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 11:23:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20204;
	Wed, 8 Aug 2001 11:16:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20175
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 11:16:08 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14681
	for <midcom@ietf.org>; Wed, 8 Aug 2001 11:14:59 -0400 (EDT)
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA19393;
	Wed, 8 Aug 2001 08:13:59 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA24885;
	Wed, 8 Aug 2001 08:16:02 -0700 (PDT)
Received: from xch-pssbh-03.nw.nos.boeing.com (xch-pssbh-03.nw.nos.boeing.com [134.52.3.95])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id f78FG1X19097;
	Wed, 8 Aug 2001 08:16:01 -0700 (PDT)
Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <QHA5SL1D>; Wed, 8 Aug 2001 08:16:01 -0700
Message-ID: <8006AC6A777F3F4F8B2A6383C19C5B7A05502EFE@XCH-NW-01.nw.nos.boeing.com>
From: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>
To: lear@cisco.com, midcom@ietf.org, "'Melinda Shore'" <mshore@cisco.com>,
        "'Michael W. Condry'" <condry@intel.com>
Cc: Ietf-openproxy@imc.org
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 08:15:57 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Michael,

You and I are in harmony on this. I'm sure that we all can agree that there are a large number of other WGs which have relevant insight into elements of the Midcom problem domain, which makes OPES far from unique, and therefore inappropriate as a target for a special WG-to-WG relationship. Take, for example, the many other groups addressing elements of policy including the Policy WG, AAA WG, AFT WG, CDI WG, the IRTF's AAAA WG, and many, many others.

--Eric

> ----------
> From: 	Michael W. Condry[SMTP:condry@intel.com]
> Sent: 	Wednesday, August 08, 2001 6:53 AM
> To: 	Fleischman, Eric W; lear@cisco.com; midcom@ietf.org; 'Melinda Shore'
> Cc: 	Ietf-openproxy@imc.org
> Subject: 	RE: [midcom] policy & duration
> 
> I agree about the dissimilar problem space.
> However, I still stand by the position that IF there areas of problem overlap,
> such as some policy matters, that ignoring each others requirements
> is a beneficial strategy (or "Dating Relationship").
> 
> At 02:58 AM 8/8/2001, Fleischman, Eric W wrote:
> >I see OPES and midcom addressing very dissimilar problems. I do not view 
> >the problems of enhancing web services (OPES) as directly related to the 
> >problems of opening pinholes through perimeter devices in a manner 
> >consistent with enterprise policies (midcom). I therefore do not think 
> >that OPES has a role in providing feedback to midcom documents that is any 
> >more relevant than the insights coming from other IETF WGs. Thus, even a 
> >"dating relationship" is unnecessary.
> >
> > > ----------
> > > From:         Melinda Shore[SMTP:mshore@cisco.com]
> > > Sent:         Wednesday, August 08, 2001 1:24 AM
> > > To:   lear@cisco.com; midcom@ietf.org; Michael W. Condry
> > > Cc:   Ietf-openproxy@imc.org
> > > Subject:      Re: [midcom] policy & duration
> > >
> > > > From: "Michael W. Condry" <condry@intel.com>
> > > > To: <lear@cisco.com>; <midcom@ietf.org>
> > > > Cc: <Ietf-openproxy@imc.org>
> > > > Sent: Wednesday, August 08, 2001 3:12 AM
> > > > Subject: Re: [midcom] policy & duration
> > >
> > >
> > > > Do you think that alignment between OPES policy and MidCom policy
> > > > concepts should be applied where appropriate?  If so, should the document
> > > > not reflect this?
> > >
> > > I do think that there's value in trying to keep these aligned,
> > > and it would probably be useful to get some feedback on our
> > > documents from OPES.  In the interests of keeping our work
> > > moving forward, it would probably be best to regard midcom
> > > and OPES as dating rather than married.
> > >
> > > Melinda
> > >
> > >
> > >
> > > _______________________________________________
> > > midcom mailing list
> > > midcom@ietf.org
> > > http://www1.ietf.org/mailman/listinfo/midcom
> > >
> 
> Michael W. Condry
> Director,  Network Edge Technology
> 
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 11:50:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15500
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 11:50:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21510;
	Wed, 8 Aug 2001 11:48:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21481
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 11:48:03 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15418
	for <midcom@ietf.org>; Wed, 8 Aug 2001 11:46:54 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f78FllY29941
	for <midcom@ietf.org>; Wed, 8 Aug 2001 08:47:47 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-63.cisco.com [10.21.96.63])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIS14784;
	Wed, 8 Aug 2001 08:21:50 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 8 Aug 2001 16:21:51 +0100
Date: Wed, 8 Aug 2001 16:21:50 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom mail-list <midcom@ietf.org>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Message-ID: <20010808162150.F1544@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	midcom mail-list <midcom@ietf.org>
References: <002b01c11f3e$12a32640$b89221d9@acmepacket.com> <20010808101114.E1592@SBRIM-W2K> <005501c11ffa$b46b4ae0$b89221d9@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <005501c11ffa$b46b4ae0$b89221d9@acmepacket.com>; from bpenfield@acmepacket.com on Wed, Aug 08, 2001 at 07:10:15AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 08, 2001 at 07:10:15AM -0400, Bob Penfield apparently wrote:
> Scott Brim <sbrim@cisco.com> wrote:
> > A "session" usually refers to something with endpoints.  The NAT thing,
> > the ruleset we're talking about is a bit of state at a single point in
> > support of communications through it, not the communications itself.
> > How about a NATting or a NAT ruleset or a NAT translation bundle or ...?
> 
> Actually, I got the term "NAT session" from RFC 2663.

I can't find it there.  A session in 2663 still has endpoints, etc.  Is
this a moot point now?

> > So modifying what you have above: "A ruleset is an embodiment of a
> > single instance of a middlebox service for a specific flow (e.g. a
> > firewall pinhole).  It defines the information necessary to identify
> > incoming packets as associated with the resource and the actions
> > required to dispose of the packets (forward them on, with or without
> > translation, or drop them).  Note that a ruleset may consist of multiple
> > functions.  For example, a single ruleset could include both the NAT and
> > firewall functions."
> 
> The phrase "as associated with a resource" in the second sentence should be
> removed OR the word "resource" changed to "ruleset".

I like taking it out entirely.

> > > Resource Bundle:
> > > A resource bundle is a group of resources that have been associated
> together
> > > by the application via the midcom agent, which uses the midcom protocol
> to
> > > establish the grouping in the middlebox.
> >
> > Ruleset would cover this too.  We could have a single "rule" but I doubt
> > we'd ever use it.
> 
> I still think we need a separate term for this because it is not a ruleset
> itself, but a set of rulesets. The rulesets for the individual flows might
> be associated together as the midcom agent establishes them, or as a
> separate action after the individual rulesets were created. From that point
> on, the midcom agent may make requests for a specific ruleset or for the
> bundle as a whole. With SIP there are lots of cases where the application
> needs to add, remove, or modify individual rulesets within a group. In SIP
> words: add, remove, or modify RTP streams within a SIP session.
> 
> We could call it a ruleset group or ruleset bundle. I envision that a
> middlebox would instantiate a bundle as just a set of pointers to the
> rulesets it contains. I realize that is a middlebox implementation choice,
> but I'm using it as an example of how it might be implemented.
> 
> The protocol needs to support an identify for a ruleset and an identifier
> for the group too so that the midcom agent can request actions on a given
> ruleset or on the whole group. These identifiers may be given out by the
> middlebox or defined by the midcom agent.

OK, any of this is fine with me.  I was mainly concerned with "resource"
in the previous version.  

Thanks ... Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 11:52:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15643
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 11:52:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21798;
	Wed, 8 Aug 2001 11:52:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21770
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 11:52:09 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15554
	for <midcom@ietf.org>; Wed, 8 Aug 2001 11:50:56 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f78Fos909126
	for <midcom@ietf.org>; Wed, 8 Aug 2001 11:50:54 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 8 Aug 2001 10:51:12 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PLQCQ1Y4>; Wed, 8 Aug 2001 10:50:46 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BC0FE@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'lear@cisco.com'" <lear@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 10:50:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12021.E3054EB0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12021.E3054EB0
Content-Type: text/plain;
	charset="iso-8859-1"


There seems to be deviation here from the original purpose of the policy
function in the MIDCOM context, which was only to help the Middlebox
authorize the resource request from a Midcom Agent. It seems to me that
"Open pinholes" is not a valid example of policy function in the Midcom
context, but "Is this Midcom Agent allowed to open pinholes?" is a valid
policy function. This will require the Midcom Agent present some form of id
to the Middlebox along with the type of resources requested (which the
Middlebox may send to the Policy server for verification). 

Comments?  


> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Tuesday, August 07, 2001 10:43 AM
> To: midcom@ietf.org
> Subject: [midcom] policy & duration
> 
> 
> 
> In our bar-fob we had a number of issues with policy.  i have 
> promised to
> provide some words to help improve the situation.  I hope this does. 
> Please note that there is a trivial case hidden in these requirements,
> obviating the need for a policy server in many instances.  Thus the
> wording allows for a fairly flexible architecture.  Don't 
> understand the
> policy conditions?  Go ask the policy server.
> 
> This information supersedes section 4.3 of the requirements 
> document and
> augments (and will need to be reconciled with) sections 2.9 
> and 6 of the
> framework document.  The wording here will need to be further 
> reconciled
> with the policy documents.
> 
> Please note that I have not addressed what information is 
> returned to the
> midcom agent.  That is an important topic and it needs to be better
> understood.
> 
> I've also taken a stab at rewriting the duration discussion.  
> There may be
> lots of text we can borrow from the policy people on this subject.
> 
> --
> 
> 4.3  Policy
> 
> Each middlebox decision is made based on either configured 
> policy or by
> querying a policy server.  While it is not within the midcom rubric to
> specify policy configuration methods, the actual policy configuration
> itself is important to discuss.
> 
> A policy statement consists of one or more policy conditions 
> and a policy
> action.[policy]
> 
> 4.3.1 Policy conditions
> 
> Some policy decisions, such as those based on 5-tuple simple 
> access lists
> are likely to be made by a middle box.  Other decisions, however, are
> likely to be more complex.  Hence we propose a nuanced approach that
> allows the policy function to be split.
> 
> The midcom agent MUST be able to satisfy informational 
> requirements of the
> policy conditions in a policy statement in order for the 
> policy server to
> make a decision.  Therefore, a structured exchange that contains those
> components MUST occur between the midcom agent and the middlebox, both
> query and response.  In as much as a policy server is 
> required to resolve
> the policy conditions, a structured exchange MUST also occur 
> between the
> middle box and the policy server.
> 
> If a middle box acts as its own policy server, it MUST understand any
> policy information needed to execute a policy statement.  Put 
> another way,
> it MAY discard any policy information that it doesn't 
> understand so long
> as that information is not required to make a policy decision.
> 
> If the middle box does not understand all of the policy conditions, it
> MUST refer the request to a policy server.  It is a 
> configuration error to
> have a policy condition that neither the middle box nor the 
> policy agent
> can evaluate.
> 
> A middle box SHOULD understand, at a minimum, policy conditions that
> contain the interfaces involved, protocol, source address and port,
> destination address and port, all of which with the exception 
> of protocol
> and interfaces MUST be capable of being expressed as a range 
> of values. 
> This is the trivial case, necessary to deploy a middlebox without the
> assistance of a policy server.
> 
> One should expect a middle box that understands a given 
> policy condition
> to police it.  However, we do not require it.
> 
> 4.3.2 Policy actions
> 
> Policy actions are those actions associated with a set of policy
> conditions in a policy statement.  Examples might be "open a 
> pinhole" or
> "return NAT bindings for a given system".
> 
> The middle box MUST understand the policy action it is to take.  The
> semantics and syntax of each of those policy actions MUST be 
> documented in
> a standard.
> 
> Hence, policy information SHOULD be encoded in a standard form that is
> possible for a middle box to decode, even if it cannot evaluate each
> policy condition.
> 
> Examples of policy statements can be found in [POLICY].
> 
> X Duration
> 
> Decisions made by middle boxes MUST have a specific duration.  That
> duration MUST include a time interval or a set of actual 
> dates and times,
> and MAY include additional termination conditions.  Examples of
> termination conditions include an exchange of TCP FINs, the 
> excessive use
> of bandwidth, or the exchange of unauthorized content.  A 
> midcom agent MAY
> request a change in duration, but the decision of the middle box, like
> every other decision will be bound by policy.
> --
> Eliot Lear
> lear@cisco.com
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12021.E3054EB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>There seems to be deviation here from the original =
purpose of the policy function in the MIDCOM context, which was only to =
help the Middlebox authorize the resource request from a Midcom Agent. =
It seems to me that &quot;Open pinholes&quot; is not a valid example of =
policy function in the Midcom context, but &quot;Is this Midcom Agent =
allowed to open pinholes?&quot; is a valid policy function. This will =
require the Midcom Agent present some form of id to the Middlebox along =
with the type of resources requested (which the Middlebox may send to =
the Policy server for verification). </FONT></P>

<P><FONT SIZE=3D2>Comments?&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Eliot Lear [<A =
HREF=3D"mailto:lear@cisco.com">mailto:lear@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 07, 2001 10:43 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] policy &amp; duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In our bar-fob we had a number of issues with =
policy.&nbsp; i have </FONT>
<BR><FONT SIZE=3D2>&gt; promised to</FONT>
<BR><FONT SIZE=3D2>&gt; provide some words to help improve the =
situation.&nbsp; I hope this does. </FONT>
<BR><FONT SIZE=3D2>&gt; Please note that there is a trivial case hidden =
in these requirements,</FONT>
<BR><FONT SIZE=3D2>&gt; obviating the need for a policy server in many =
instances.&nbsp; Thus the</FONT>
<BR><FONT SIZE=3D2>&gt; wording allows for a fairly flexible =
architecture.&nbsp; Don't </FONT>
<BR><FONT SIZE=3D2>&gt; understand the</FONT>
<BR><FONT SIZE=3D2>&gt; policy conditions?&nbsp; Go ask the policy =
server.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This information supersedes section 4.3 of the =
requirements </FONT>
<BR><FONT SIZE=3D2>&gt; document and</FONT>
<BR><FONT SIZE=3D2>&gt; augments (and will need to be reconciled with) =
sections 2.9 </FONT>
<BR><FONT SIZE=3D2>&gt; and 6 of the</FONT>
<BR><FONT SIZE=3D2>&gt; framework document.&nbsp; The wording here will =
need to be further </FONT>
<BR><FONT SIZE=3D2>&gt; reconciled</FONT>
<BR><FONT SIZE=3D2>&gt; with the policy documents.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please note that I have not addressed what =
information is </FONT>
<BR><FONT SIZE=3D2>&gt; returned to the</FONT>
<BR><FONT SIZE=3D2>&gt; midcom agent.&nbsp; That is an important topic =
and it needs to be better</FONT>
<BR><FONT SIZE=3D2>&gt; understood.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I've also taken a stab at rewriting the =
duration discussion.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; There may be</FONT>
<BR><FONT SIZE=3D2>&gt; lots of text we can borrow from the policy =
people on this subject.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4.3&nbsp; Policy</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Each middlebox decision is made based on either =
configured </FONT>
<BR><FONT SIZE=3D2>&gt; policy or by</FONT>
<BR><FONT SIZE=3D2>&gt; querying a policy server.&nbsp; While it is not =
within the midcom rubric to</FONT>
<BR><FONT SIZE=3D2>&gt; specify policy configuration methods, the =
actual policy configuration</FONT>
<BR><FONT SIZE=3D2>&gt; itself is important to discuss.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A policy statement consists of one or more =
policy conditions </FONT>
<BR><FONT SIZE=3D2>&gt; and a policy</FONT>
<BR><FONT SIZE=3D2>&gt; action.[policy]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4.3.1 Policy conditions</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Some policy decisions, such as those based on =
5-tuple simple </FONT>
<BR><FONT SIZE=3D2>&gt; access lists</FONT>
<BR><FONT SIZE=3D2>&gt; are likely to be made by a middle box.&nbsp; =
Other decisions, however, are</FONT>
<BR><FONT SIZE=3D2>&gt; likely to be more complex.&nbsp; Hence we =
propose a nuanced approach that</FONT>
<BR><FONT SIZE=3D2>&gt; allows the policy function to be split.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The midcom agent MUST be able to satisfy =
informational </FONT>
<BR><FONT SIZE=3D2>&gt; requirements of the</FONT>
<BR><FONT SIZE=3D2>&gt; policy conditions in a policy statement in =
order for the </FONT>
<BR><FONT SIZE=3D2>&gt; policy server to</FONT>
<BR><FONT SIZE=3D2>&gt; make a decision.&nbsp; Therefore, a structured =
exchange that contains those</FONT>
<BR><FONT SIZE=3D2>&gt; components MUST occur between the midcom agent =
and the middlebox, both</FONT>
<BR><FONT SIZE=3D2>&gt; query and response.&nbsp; In as much as a =
policy server is </FONT>
<BR><FONT SIZE=3D2>&gt; required to resolve</FONT>
<BR><FONT SIZE=3D2>&gt; the policy conditions, a structured exchange =
MUST also occur </FONT>
<BR><FONT SIZE=3D2>&gt; between the</FONT>
<BR><FONT SIZE=3D2>&gt; middle box and the policy server.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If a middle box acts as its own policy server, =
it MUST understand any</FONT>
<BR><FONT SIZE=3D2>&gt; policy information needed to execute a policy =
statement.&nbsp; Put </FONT>
<BR><FONT SIZE=3D2>&gt; another way,</FONT>
<BR><FONT SIZE=3D2>&gt; it MAY discard any policy information that it =
doesn't </FONT>
<BR><FONT SIZE=3D2>&gt; understand so long</FONT>
<BR><FONT SIZE=3D2>&gt; as that information is not required to make a =
policy decision.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the middle box does not understand all of =
the policy conditions, it</FONT>
<BR><FONT SIZE=3D2>&gt; MUST refer the request to a policy =
server.&nbsp; It is a </FONT>
<BR><FONT SIZE=3D2>&gt; configuration error to</FONT>
<BR><FONT SIZE=3D2>&gt; have a policy condition that neither the middle =
box nor the </FONT>
<BR><FONT SIZE=3D2>&gt; policy agent</FONT>
<BR><FONT SIZE=3D2>&gt; can evaluate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A middle box SHOULD understand, at a minimum, =
policy conditions that</FONT>
<BR><FONT SIZE=3D2>&gt; contain the interfaces involved, protocol, =
source address and port,</FONT>
<BR><FONT SIZE=3D2>&gt; destination address and port, all of which with =
the exception </FONT>
<BR><FONT SIZE=3D2>&gt; of protocol</FONT>
<BR><FONT SIZE=3D2>&gt; and interfaces MUST be capable of being =
expressed as a range </FONT>
<BR><FONT SIZE=3D2>&gt; of values. </FONT>
<BR><FONT SIZE=3D2>&gt; This is the trivial case, necessary to deploy a =
middlebox without the</FONT>
<BR><FONT SIZE=3D2>&gt; assistance of a policy server.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; One should expect a middle box that understands =
a given </FONT>
<BR><FONT SIZE=3D2>&gt; policy condition</FONT>
<BR><FONT SIZE=3D2>&gt; to police it.&nbsp; However, we do not require =
it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4.3.2 Policy actions</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Policy actions are those actions associated =
with a set of policy</FONT>
<BR><FONT SIZE=3D2>&gt; conditions in a policy statement.&nbsp; =
Examples might be &quot;open a </FONT>
<BR><FONT SIZE=3D2>&gt; pinhole&quot; or</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;return NAT bindings for a given =
system&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The middle box MUST understand the policy =
action it is to take.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; semantics and syntax of each of those policy =
actions MUST be </FONT>
<BR><FONT SIZE=3D2>&gt; documented in</FONT>
<BR><FONT SIZE=3D2>&gt; a standard.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hence, policy information SHOULD be encoded in =
a standard form that is</FONT>
<BR><FONT SIZE=3D2>&gt; possible for a middle box to decode, even if it =
cannot evaluate each</FONT>
<BR><FONT SIZE=3D2>&gt; policy condition.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Examples of policy statements can be found in =
[POLICY].</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; X Duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Decisions made by middle boxes MUST have a =
specific duration.&nbsp; That</FONT>
<BR><FONT SIZE=3D2>&gt; duration MUST include a time interval or a set =
of actual </FONT>
<BR><FONT SIZE=3D2>&gt; dates and times,</FONT>
<BR><FONT SIZE=3D2>&gt; and MAY include additional termination =
conditions.&nbsp; Examples of</FONT>
<BR><FONT SIZE=3D2>&gt; termination conditions include an exchange of =
TCP FINs, the </FONT>
<BR><FONT SIZE=3D2>&gt; excessive use</FONT>
<BR><FONT SIZE=3D2>&gt; of bandwidth, or the exchange of unauthorized =
content.&nbsp; A </FONT>
<BR><FONT SIZE=3D2>&gt; midcom agent MAY</FONT>
<BR><FONT SIZE=3D2>&gt; request a change in duration, but the decision =
of the middle box, like</FONT>
<BR><FONT SIZE=3D2>&gt; every other decision will be bound by =
policy.</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Eliot Lear</FONT>
<BR><FONT SIZE=3D2>&gt; lear@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12021.E3054EB0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 12:16:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16114
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 12:16:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23104;
	Wed, 8 Aug 2001 12:10:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23080
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 12:10:03 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16022
	for <midcom@ietf.org>; Wed, 8 Aug 2001 12:08:54 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f78G7gJ01008
	for <midcom@ietf.org>; Wed, 8 Aug 2001 09:07:42 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-63.cisco.com [10.21.96.63])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIT00641;
	Wed, 8 Aug 2001 09:09:27 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 8 Aug 2001 17:09:26 +0100
Date: Wed, 8 Aug 2001 17:09:26 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
Message-ID: <20010808170926.G1544@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3B700C72.35EC5BD8@cisco.com> <02d001c11fe2$fd15aa50$7c8921d9@NAUGA> <3B71030D.5217480A@cisco.com> <3B710AAF.8610B61D@lucent.com> <20010808112021.L1592@SBRIM-W2K> <3B7133B7.CAEFAC4E@lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B7133B7.CAEFAC4E@lucent.com>; from sijben@lucent.com on Wed, Aug 08, 2001 at 02:42:31PM +0200
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 08, 2001 at 02:42:31PM +0200, Paul Sijben apparently wrote:
> I beg to differ. Pinholes MAY be *described* by rulesets. 

What is a pinhole?  How do you differentiate one pinhole from another,
functionally?  What thing of substance do you deal with to create a
pinhole?  I'm looking for your word for that thing.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 12:34:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16530
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 12:34:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23628;
	Wed, 8 Aug 2001 12:28:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23598
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 12:28:02 -0400 (EDT)
Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16364
	for <midcom@ietf.org>; Wed, 8 Aug 2001 12:26:54 -0400 (EDT)
Received: by EMAIL5 with Internet Mail Service (5.5.2653.19)
	id <QF7Y0009>; Wed, 8 Aug 2001 18:26:54 +0200
Message-ID: <337FC70FD51CD411A3500008C70D56F188CE38@EMAIL1>
From: Scott Cadzow <Scott.Cadzow@etsi.fr>
To: "'Sanjoy Sen'" <sanjoy@nortelnetworks.com>,
        "'lear@cisco.com'"
	 <lear@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 18:26:47 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12026.EB62C790"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12026.EB62C790
Content-Type: text/plain;
	charset="iso-8859-1"

In order to build an appropriate function it is essential to ensure that it
meets the context it is built for. The requirements work has to be allowed
to question the entire context and to refine a set of requirements for
MIDCOM that are unique to it. It is also fair to determine therefore what
policy functions are managed in this framework and thence in the resulting
protocols. In other words lets discuss the impact without narrowing our
scope too quickly.
 
Scott

-----Original Message-----
From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]
Sent: 08 August 2001 17:51
To: 'lear@cisco.com'; midcom@ietf.org
Subject: RE: [midcom] policy & duration




There seems to be deviation here from the original purpose of the policy
function in the MIDCOM context, which was only to help the Middlebox
authorize the resource request from a Midcom Agent. It seems to me that
"Open pinholes" is not a valid example of policy function in the Midcom
context, but "Is this Midcom Agent allowed to open pinholes?" is a valid
policy function. This will require the Midcom Agent present some form of id
to the Middlebox along with the type of resources requested (which the
Middlebox may send to the Policy server for verification). 

Comments?  


> -----Original Message----- 
> From: Eliot Lear [ mailto:lear@cisco.com <mailto:lear@cisco.com> ] 
> Sent: Tuesday, August 07, 2001 10:43 AM 
> To: midcom@ietf.org 
> Subject: [midcom] policy & duration 
> 
> 
> 
> In our bar-fob we had a number of issues with policy.  i have 
> promised to 
> provide some words to help improve the situation.  I hope this does. 
> Please note that there is a trivial case hidden in these requirements, 
> obviating the need for a policy server in many instances.  Thus the 
> wording allows for a fairly flexible architecture.  Don't 
> understand the 
> policy conditions?  Go ask the policy server. 
> 
> This information supersedes section 4.3 of the requirements 
> document and 
> augments (and will need to be reconciled with) sections 2.9 
> and 6 of the 
> framework document.  The wording here will need to be further 
> reconciled 
> with the policy documents. 
> 
> Please note that I have not addressed what information is 
> returned to the 
> midcom agent.  That is an important topic and it needs to be better 
> understood. 
> 
> I've also taken a stab at rewriting the duration discussion.  
> There may be 
> lots of text we can borrow from the policy people on this subject. 
> 
> -- 
> 
> 4.3  Policy 
> 
> Each middlebox decision is made based on either configured 
> policy or by 
> querying a policy server.  While it is not within the midcom rubric to 
> specify policy configuration methods, the actual policy configuration 
> itself is important to discuss. 
> 
> A policy statement consists of one or more policy conditions 
> and a policy 
> action.[policy] 
> 
> 4.3.1 Policy conditions 
> 
> Some policy decisions, such as those based on 5-tuple simple 
> access lists 
> are likely to be made by a middle box.  Other decisions, however, are 
> likely to be more complex.  Hence we propose a nuanced approach that 
> allows the policy function to be split. 
> 
> The midcom agent MUST be able to satisfy informational 
> requirements of the 
> policy conditions in a policy statement in order for the 
> policy server to 
> make a decision.  Therefore, a structured exchange that contains those 
> components MUST occur between the midcom agent and the middlebox, both 
> query and response.  In as much as a policy server is 
> required to resolve 
> the policy conditions, a structured exchange MUST also occur 
> between the 
> middle box and the policy server. 
> 
> If a middle box acts as its own policy server, it MUST understand any 
> policy information needed to execute a policy statement.  Put 
> another way, 
> it MAY discard any policy information that it doesn't 
> understand so long 
> as that information is not required to make a policy decision. 
> 
> If the middle box does not understand all of the policy conditions, it 
> MUST refer the request to a policy server.  It is a 
> configuration error to 
> have a policy condition that neither the middle box nor the 
> policy agent 
> can evaluate. 
> 
> A middle box SHOULD understand, at a minimum, policy conditions that 
> contain the interfaces involved, protocol, source address and port, 
> destination address and port, all of which with the exception 
> of protocol 
> and interfaces MUST be capable of being expressed as a range 
> of values. 
> This is the trivial case, necessary to deploy a middlebox without the 
> assistance of a policy server. 
> 
> One should expect a middle box that understands a given 
> policy condition 
> to police it.  However, we do not require it. 
> 
> 4.3.2 Policy actions 
> 
> Policy actions are those actions associated with a set of policy 
> conditions in a policy statement.  Examples might be "open a 
> pinhole" or 
> "return NAT bindings for a given system". 
> 
> The middle box MUST understand the policy action it is to take.  The 
> semantics and syntax of each of those policy actions MUST be 
> documented in 
> a standard. 
> 
> Hence, policy information SHOULD be encoded in a standard form that is 
> possible for a middle box to decode, even if it cannot evaluate each 
> policy condition. 
> 
> Examples of policy statements can be found in [POLICY]. 
> 
> X Duration 
> 
> Decisions made by middle boxes MUST have a specific duration.  That 
> duration MUST include a time interval or a set of actual 
> dates and times, 
> and MAY include additional termination conditions.  Examples of 
> termination conditions include an exchange of TCP FINs, the 
> excessive use 
> of bandwidth, or the exchange of unauthorized content.  A 
> midcom agent MAY 
> request a change in duration, but the decision of the middle box, like 
> every other decision will be bound by policy. 
> -- 
> Eliot Lear 
> lear@cisco.com 
> 
> _______________________________________________ 
> midcom mailing list 
> midcom@ietf.org 
> http://www1.ietf.org/mailman/listinfo/midcom
<http://www1.ietf.org/mailman/listinfo/midcom>  
> 


------_=_NextPart_001_01C12026.EB62C790
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8VElUTEU+UkU6IFttaWRjb21d
IHBvbGljeSAmIGR1cmF0aW9uPC9USVRMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDUuNTAu
NDYxMy4xNzAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+PFNQQU4gY2xh
c3M9Nzg3MTkyNDE2LTA4MDgyMDAxPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl
PTI+SW4gDQpvcmRlciB0byBidWlsZCBhbiBhcHByb3ByaWF0ZSBmdW5jdGlvbiBpdCBpcyBlc3Nl
bnRpYWwgdG8gZW5zdXJlIHRoYXQgaXQgbWVldHMgDQp0aGUgY29udGV4dCBpdCBpcyBidWlsdCBm
b3IuIFRoZSByZXF1aXJlbWVudHMgd29yayBoYXMgdG8gYmUgYWxsb3dlZCB0byBxdWVzdGlvbiAN
CnRoZSBlbnRpcmUgY29udGV4dCBhbmQgdG8gcmVmaW5lIGEgc2V0IG9mIHJlcXVpcmVtZW50cyBm
b3IgTUlEQ09NIHRoYXQgYXJlIA0KdW5pcXVlIHRvIGl0LiBJdCBpcyBhbHNvIGZhaXIgdG8gZGV0
ZXJtaW5lIHRoZXJlZm9yZSB3aGF0IHBvbGljeSBmdW5jdGlvbnMgYXJlIA0KbWFuYWdlZCBpbiB0
aGlzIGZyYW1ld29yayBhbmQgdGhlbmNlIGluIHRoZSByZXN1bHRpbmcgcHJvdG9jb2xzLiBJbiBv
dGhlciB3b3JkcyANCmxldHMgZGlzY3VzcyB0aGUgaW1wYWN0IHdpdGhvdXQgbmFycm93aW5nIG91
ciBzY29wZSB0b28gDQpxdWlja2x5LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNs
YXNzPTc4NzE5MjQxNi0wODA4MjAwMT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpz
aXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Nzg3MTky
NDE2LTA4MDgyMDAxPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5TY290
dDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4t
UklHSFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBh
bGlnbj1sZWZ0PjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IFNhbmpveSBTZW4gDQogIFttYWlsdG86c2Fuam95QG5v
cnRlbG5ldHdvcmtzLmNvbV08QlI+PEI+U2VudDo8L0I+IDA4IEF1Z3VzdCAyMDAxIA0KICAxNzo1
MTxCUj48Qj5Ubzo8L0I+ICdsZWFyQGNpc2NvLmNvbSc7IG1pZGNvbUBpZXRmLm9yZzxCUj48Qj5T
dWJqZWN0OjwvQj4gUkU6IA0KICBbbWlkY29tXSBwb2xpY3kgJmFtcDsgZHVyYXRpb248QlI+PEJS
PjwvRk9OVD48L0RJVj48QlI+DQogIDxQPjxGT05UIHNpemU9Mj5UaGVyZSBzZWVtcyB0byBiZSBk
ZXZpYXRpb24gaGVyZSBmcm9tIHRoZSBvcmlnaW5hbCBwdXJwb3NlIG9mIA0KICB0aGUgcG9saWN5
IGZ1bmN0aW9uIGluIHRoZSBNSURDT00gY29udGV4dCwgd2hpY2ggd2FzIG9ubHkgdG8gaGVscCB0
aGUgDQogIE1pZGRsZWJveCBhdXRob3JpemUgdGhlIHJlc291cmNlIHJlcXVlc3QgZnJvbSBhIE1p
ZGNvbSBBZ2VudC4gSXQgc2VlbXMgdG8gbWUgDQogIHRoYXQgIk9wZW4gcGluaG9sZXMiIGlzIG5v
dCBhIHZhbGlkIGV4YW1wbGUgb2YgcG9saWN5IGZ1bmN0aW9uIGluIHRoZSBNaWRjb20gDQogIGNv
bnRleHQsIGJ1dCAiSXMgdGhpcyBNaWRjb20gQWdlbnQgYWxsb3dlZCB0byBvcGVuIHBpbmhvbGVz
PyIgaXMgYSB2YWxpZCANCiAgcG9saWN5IGZ1bmN0aW9uLiBUaGlzIHdpbGwgcmVxdWlyZSB0aGUg
TWlkY29tIEFnZW50IHByZXNlbnQgc29tZSBmb3JtIG9mIGlkIHRvIA0KICB0aGUgTWlkZGxlYm94
IGFsb25nIHdpdGggdGhlIHR5cGUgb2YgcmVzb3VyY2VzIHJlcXVlc3RlZCAod2hpY2ggdGhlIE1p
ZGRsZWJveCANCiAgbWF5IHNlbmQgdG8gdGhlIFBvbGljeSBzZXJ2ZXIgZm9yIHZlcmlmaWNhdGlv
bikuIDwvRk9OVD48L1A+DQogIDxQPjxGT05UIHNpemU9Mj5Db21tZW50cz8mbmJzcDsgPC9GT05U
PjwvUD48QlI+DQogIDxQPjxGT05UIHNpemU9Mj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIEZyb206IEVsaW90IExlYXIgWzxB
IA0KICBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20iPm1haWx0bzpsZWFyQGNpc2NvLmNvbTwv
QT5dPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IFNlbnQ6IFR1ZXNkYXksIEF1Z3Vz
dCAwNywgMjAwMSAxMDo0MyBBTTwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyBUbzog
bWlkY29tQGlldGYub3JnPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgU3ViamVjdDogW21p
ZGNvbV0gDQogIHBvbGljeSAmYW1wOyBkdXJhdGlvbjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4m
Z3Q7IDwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6
ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBJbiBvdXIgDQogIGJhci1mb2Ig
d2UgaGFkIGEgbnVtYmVyIG9mIGlzc3VlcyB3aXRoIHBvbGljeS4mbmJzcDsgaSBoYXZlIDwvRk9O
VD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IHByb21pc2VkIHRvPC9GT05UPiA8QlI+PEZPTlQg
c2l6ZT0yPiZndDsgcHJvdmlkZSBzb21lIHdvcmRzIHRvIA0KICBoZWxwIGltcHJvdmUgdGhlIHNp
dHVhdGlvbi4mbmJzcDsgSSBob3BlIHRoaXMgZG9lcy4gPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6
ZT0yPiZndDsgUGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBpcyBhIHRyaXZpYWwgY2FzZSBoaWRkZW4g
aW4gdGhlc2UgDQogIHJlcXVpcmVtZW50cyw8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBv
YnZpYXRpbmcgdGhlIG5lZWQgZm9yIGEgcG9saWN5IA0KICBzZXJ2ZXIgaW4gbWFueSBpbnN0YW5j
ZXMuJm5ic3A7IFRodXMgdGhlPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgd29yZGluZyAN
CiAgYWxsb3dzIGZvciBhIGZhaXJseSBmbGV4aWJsZSBhcmNoaXRlY3R1cmUuJm5ic3A7IERvbid0
IDwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IHVuZGVyc3RhbmQgdGhlPC9GT05UPiA8
QlI+PEZPTlQgc2l6ZT0yPiZndDsgcG9saWN5IA0KICBjb25kaXRpb25zPyZuYnNwOyBHbyBhc2sg
dGhlIHBvbGljeSBzZXJ2ZXIuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIDwvRk9O
VD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgVGhpcyBpbmZvcm1hdGlvbiBzdXBlcnNlZGVzIHNlY3Rp
b24gNC4zIG9mIHRoZSANCiAgcmVxdWlyZW1lbnRzIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZn
dDsgZG9jdW1lbnQgYW5kPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IGF1Z21lbnRz
IChhbmQgd2lsbCBuZWVkIHRvIGJlIHJlY29uY2lsZWQgd2l0aCkgc2VjdGlvbnMgMi45IA0KICA8
L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGFuZCA2IG9mIHRoZTwvRk9OVD4gPEJSPjxGT05U
IHNpemU9Mj4mZ3Q7IA0KICBmcmFtZXdvcmsgZG9jdW1lbnQuJm5ic3A7IFRoZSB3b3JkaW5nIGhl
cmUgd2lsbCBuZWVkIHRvIGJlIGZ1cnRoZXIgDQogIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZn
dDsgcmVjb25jaWxlZDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHdpdGggdGhlIA0KICBw
b2xpY3kgZG9jdW1lbnRzLjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+
PEZPTlQgc2l6ZT0yPiZndDsgDQogIFBsZWFzZSBub3RlIHRoYXQgSSBoYXZlIG5vdCBhZGRyZXNz
ZWQgd2hhdCBpbmZvcm1hdGlvbiBpcyA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyBy
ZXR1cm5lZCB0byB0aGU8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBtaWRjb20gYWdlbnQu
Jm5ic3A7IA0KICBUaGF0IGlzIGFuIGltcG9ydGFudCB0b3BpYyBhbmQgaXQgbmVlZHMgdG8gYmUg
YmV0dGVyPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IHVuZGVyc3Rvb2QuPC9GT05U
PiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsg
SSd2ZSBhbHNvIHRha2VuIGEgc3RhYiBhdCByZXdyaXRpbmcgdGhlIGR1cmF0aW9uIGRpc2N1c3Np
b24uJm5ic3A7IA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IFRoZXJlIG1heSBiZTwv
Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGxvdHMgb2YgDQogIHRleHQgd2UgY2FuIGJvcnJv
dyBmcm9tIHRoZSBwb2xpY3kgcGVvcGxlIG9uIHRoaXMgc3ViamVjdC48L0ZPTlQ+IDxCUj48Rk9O
VCANCiAgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyAtLTwvRk9OVD4g
PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDQu
MyZuYnNwOyBQb2xpY3k8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgPC9GT05UPjxC
Uj48Rk9OVCBzaXplPTI+Jmd0OyBFYWNoIG1pZGRsZWJveCBkZWNpc2lvbiBpcyBtYWRlIGJhc2Vk
IG9uIGVpdGhlciANCiAgY29uZmlndXJlZCA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHBv
bGljeSBvciBieTwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyBxdWVyeWluZyBhIHBv
bGljeSBzZXJ2ZXIuJm5ic3A7IFdoaWxlIGl0IGlzIG5vdCB3aXRoaW4gdGhlIG1pZGNvbSANCiAg
cnVicmljIHRvPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgc3BlY2lmeSBwb2xpY3kgY29u
ZmlndXJhdGlvbiBtZXRob2RzLCANCiAgdGhlIGFjdHVhbCBwb2xpY3kgY29uZmlndXJhdGlvbjwv
Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGl0c2VsZiBpcyANCiAgaW1wb3J0YW50IHRvIGRp
c2N1c3MuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCANCiAg
c2l6ZT0yPiZndDsgQSBwb2xpY3kgc3RhdGVtZW50IGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIHBv
bGljeSBjb25kaXRpb25zIA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGFuZCBhIHBv
bGljeTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICBhY3Rpb24uW3BvbGljeV08L0ZP
TlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0K
ICA0LjMuMSBQb2xpY3kgY29uZGl0aW9uczwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDwv
Rk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IFNvbWUgcG9saWN5IGRlY2lzaW9ucywgc3Vj
aCBhcyB0aG9zZSBiYXNlZCBvbiA1LXR1cGxlIHNpbXBsZSANCiAgPC9GT05UPjxCUj48Rk9OVCBz
aXplPTI+Jmd0OyBhY2Nlc3MgbGlzdHM8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBhcmUg
DQogIGxpa2VseSB0byBiZSBtYWRlIGJ5IGEgbWlkZGxlIGJveC4mbmJzcDsgT3RoZXIgZGVjaXNp
b25zLCBob3dldmVyLCBhcmU8L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgbGlrZWx5
IHRvIGJlIG1vcmUgY29tcGxleC4mbmJzcDsgSGVuY2Ugd2UgcHJvcG9zZSBhIA0KICBudWFuY2Vk
IGFwcHJvYWNoIHRoYXQ8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBhbGxvd3MgdGhlIHBv
bGljeSBmdW5jdGlvbiANCiAgdG8gYmUgc3BsaXQuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZn
dDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBUaGUgDQogIG1pZGNvbSBhZ2VudCBNVVNU
IGJlIGFibGUgdG8gc2F0aXNmeSBpbmZvcm1hdGlvbmFsIDwvRk9OVD48QlI+PEZPTlQgDQogIHNp
emU9Mj4mZ3Q7IHJlcXVpcmVtZW50cyBvZiB0aGU8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0
OyBwb2xpY3kgY29uZGl0aW9ucyANCiAgaW4gYSBwb2xpY3kgc3RhdGVtZW50IGluIG9yZGVyIGZv
ciB0aGUgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBwb2xpY3kgDQogIHNlcnZlciB0bzwv
Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IG1ha2UgYSBkZWNpc2lvbi4mbmJzcDsgVGhlcmVm
b3JlLCBhIA0KICBzdHJ1Y3R1cmVkIGV4Y2hhbmdlIHRoYXQgY29udGFpbnMgdGhvc2U8L0ZPTlQ+
IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgY29tcG9uZW50cyBNVVNUIG9jY3VyIGJldHdlZW4g
dGhlIG1pZGNvbSBhZ2VudCBhbmQgdGhlIG1pZGRsZWJveCwgYm90aDwvRk9OVD4gDQogIDxCUj48
Rk9OVCBzaXplPTI+Jmd0OyBxdWVyeSBhbmQgcmVzcG9uc2UuJm5ic3A7IEluIGFzIG11Y2ggYXMg
YSBwb2xpY3kgc2VydmVyIA0KICBpcyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHJlcXVp
cmVkIHRvIHJlc29sdmU8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsgdGhlIHBvbGlj
eSBjb25kaXRpb25zLCBhIHN0cnVjdHVyZWQgZXhjaGFuZ2UgTVVTVCBhbHNvIG9jY3VyIA0KICA8
L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGJldHdlZW4gdGhlPC9GT05UPiA8QlI+PEZPTlQg
c2l6ZT0yPiZndDsgbWlkZGxlIA0KICBib3ggYW5kIHRoZSBwb2xpY3kgc2VydmVyLjwvRk9OVD4g
PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IElm
IGEgbWlkZGxlIGJveCBhY3RzIGFzIGl0cyBvd24gcG9saWN5IHNlcnZlciwgaXQgTVVTVCB1bmRl
cnN0YW5kIA0KICBhbnk8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBwb2xpY3kgaW5mb3Jt
YXRpb24gbmVlZGVkIHRvIGV4ZWN1dGUgYSBwb2xpY3kgDQogIHN0YXRlbWVudC4mbmJzcDsgUHV0
IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgYW5vdGhlciB3YXksPC9GT05UPiANCiAgPEJS
PjxGT05UIHNpemU9Mj4mZ3Q7IGl0IE1BWSBkaXNjYXJkIGFueSBwb2xpY3kgaW5mb3JtYXRpb24g
dGhhdCBpdCBkb2Vzbid0IA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHVuZGVyc3Rh
bmQgc28gbG9uZzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICBhcyB0aGF0IGluZm9y
bWF0aW9uIGlzIG5vdCByZXF1aXJlZCB0byBtYWtlIGEgcG9saWN5IGRlY2lzaW9uLjwvRk9OVD4g
DQogIDxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IElm
IHRoZSBtaWRkbGUgYm94IGRvZXMgbm90IA0KICB1bmRlcnN0YW5kIGFsbCBvZiB0aGUgcG9saWN5
IGNvbmRpdGlvbnMsIGl0PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgTVVTVCANCiAgcmVm
ZXIgdGhlIHJlcXVlc3QgdG8gYSBwb2xpY3kgc2VydmVyLiZuYnNwOyBJdCBpcyBhIDwvRk9OVD48
QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IGNvbmZpZ3VyYXRpb24gZXJyb3IgdG88L0ZPTlQ+IDxC
Uj48Rk9OVCBzaXplPTI+Jmd0OyBoYXZlIGEgcG9saWN5IA0KICBjb25kaXRpb24gdGhhdCBuZWl0
aGVyIHRoZSBtaWRkbGUgYm94IG5vciB0aGUgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyAN
CiAgcG9saWN5IGFnZW50PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgY2FuIGV2YWx1YXRl
LjwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9
Mj4mZ3Q7IEEgbWlkZGxlIGJveCBTSE9VTEQgdW5kZXJzdGFuZCwgYXQgYSANCiAgbWluaW11bSwg
cG9saWN5IGNvbmRpdGlvbnMgdGhhdDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGNvbnRh
aW4gdGhlIA0KICBpbnRlcmZhY2VzIGludm9sdmVkLCBwcm90b2NvbCwgc291cmNlIGFkZHJlc3Mg
YW5kIHBvcnQsPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IGRlc3RpbmF0aW9uIGFk
ZHJlc3MgYW5kIHBvcnQsIGFsbCBvZiB3aGljaCB3aXRoIHRoZSBleGNlcHRpb24gDQogIDwvRk9O
VD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgb2YgcHJvdG9jb2w8L0ZPTlQ+IDxCUj48Rk9OVCBzaXpl
PTI+Jmd0OyBhbmQgDQogIGludGVyZmFjZXMgTVVTVCBiZSBjYXBhYmxlIG9mIGJlaW5nIGV4cHJl
c3NlZCBhcyBhIHJhbmdlIDwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IG9mIHZhbHVl
cy4gPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBUaGlzIGlzIHRoZSB0cml2aWFsIGNhc2Us
IA0KICBuZWNlc3NhcnkgdG8gZGVwbG95IGEgbWlkZGxlYm94IHdpdGhvdXQgdGhlPC9GT05UPiA8
QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIGFzc2lzdGFuY2Ugb2YgYSBwb2xpY3kgc2VydmVyLjwv
Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4m
Z3Q7IE9uZSBzaG91bGQgZXhwZWN0IGEgbWlkZGxlIGJveCB0aGF0IHVuZGVyc3RhbmRzIGEgZ2l2
ZW4gDQogIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgcG9saWN5IGNvbmRpdGlvbjwvRk9O
VD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHRvIA0KICBwb2xpY2UgaXQuJm5ic3A7IEhvd2V2ZXIs
IHdlIGRvIG5vdCByZXF1aXJlIGl0LjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICA8
L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDQuMy4yIFBvbGljeSBhY3Rpb25zPC9GT05UPiA8
QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgUG9s
aWN5IGFjdGlvbnMgYXJlIHRob3NlIGFjdGlvbnMgYXNzb2NpYXRlZCB3aXRoIA0KICBhIHNldCBv
ZiBwb2xpY3k8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBjb25kaXRpb25zIGluIGEgcG9s
aWN5IA0KICBzdGF0ZW1lbnQuJm5ic3A7IEV4YW1wbGVzIG1pZ2h0IGJlICJvcGVuIGEgPC9GT05U
PjxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgcGluaG9sZSIgb3I8L0ZPTlQ+IDxCUj48Rk9OVCBz
aXplPTI+Jmd0OyAicmV0dXJuIE5BVCBiaW5kaW5ncyBmb3IgYSBnaXZlbiANCiAgc3lzdGVtIi48
L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7
IFRoZSBtaWRkbGUgDQogIGJveCBNVVNUIHVuZGVyc3RhbmQgdGhlIHBvbGljeSBhY3Rpb24gaXQg
aXMgdG8gdGFrZS4mbmJzcDsgVGhlPC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHNl
bWFudGljcyBhbmQgc3ludGF4IG9mIGVhY2ggb2YgdGhvc2UgcG9saWN5IGFjdGlvbnMgDQogIE1V
U1QgYmUgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBkb2N1bWVudGVkIGluPC9GT05UPiA8
QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7IGEgc3RhbmRhcmQuPC9GT05UPiA8QlI+PEZPTlQgc2l6
ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsgSGVuY2UsIHBvbGljeSBp
bmZvcm1hdGlvbiBTSE9VTEQgYmUgZW5jb2RlZCBpbiBhIHN0YW5kYXJkIGZvcm0gDQogIHRoYXQg
aXM8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBwb3NzaWJsZSBmb3IgYSBtaWRkbGUgYm94
IHRvIGRlY29kZSwgZXZlbiANCiAgaWYgaXQgY2Fubm90IGV2YWx1YXRlIGVhY2g8L0ZPTlQ+IDxC
Uj48Rk9OVCBzaXplPTI+Jmd0OyBwb2xpY3kgDQogIGNvbmRpdGlvbi48L0ZPTlQ+IDxCUj48Rk9O
VCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IEV4YW1wbGVzIA0KICBv
ZiBwb2xpY3kgc3RhdGVtZW50cyBjYW4gYmUgZm91bmQgaW4gW1BPTElDWV0uPC9GT05UPiA8QlI+
PEZPTlQgc2l6ZT0yPiZndDsgDQogIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgWCBEdXJh
dGlvbjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICA8L0ZPTlQ+PEJSPjxGT05UIHNp
emU9Mj4mZ3Q7IERlY2lzaW9ucyBtYWRlIGJ5IG1pZGRsZSBib3hlcyBNVVNUIGhhdmUgYSANCiAg
c3BlY2lmaWMgZHVyYXRpb24uJm5ic3A7IFRoYXQ8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0
OyBkdXJhdGlvbiBNVVNUIA0KICBpbmNsdWRlIGEgdGltZSBpbnRlcnZhbCBvciBhIHNldCBvZiBh
Y3R1YWwgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBkYXRlcyANCiAgYW5kIHRpbWVzLDwv
Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGFuZCBNQVkgaW5jbHVkZSBhZGRpdGlvbmFsIHRl
cm1pbmF0aW9uIA0KICBjb25kaXRpb25zLiZuYnNwOyBFeGFtcGxlcyBvZjwvRk9OVD4gPEJSPjxG
T05UIHNpemU9Mj4mZ3Q7IHRlcm1pbmF0aW9uIA0KICBjb25kaXRpb25zIGluY2x1ZGUgYW4gZXhj
aGFuZ2Ugb2YgVENQIEZJTnMsIHRoZSA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICBl
eGNlc3NpdmUgdXNlPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgb2YgYmFuZHdpZHRoLCBv
ciB0aGUgZXhjaGFuZ2Ugb2YgDQogIHVuYXV0aG9yaXplZCBjb250ZW50LiZuYnNwOyBBIDwvRk9O
VD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgbWlkY29tIGFnZW50IA0KICBNQVk8L0ZPTlQ+IDxCUj48
Rk9OVCBzaXplPTI+Jmd0OyByZXF1ZXN0IGEgY2hhbmdlIGluIGR1cmF0aW9uLCBidXQgdGhlIA0K
ICBkZWNpc2lvbiBvZiB0aGUgbWlkZGxlIGJveCwgbGlrZTwvRk9OVD4gPEJSPjxGT05UIHNpemU9
Mj4mZ3Q7IGV2ZXJ5IG90aGVyIA0KICBkZWNpc2lvbiB3aWxsIGJlIGJvdW5kIGJ5IHBvbGljeS48
L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAtLTwvRk9OVD4gDQogIDxCUj48Rk9OVCBzaXpl
PTI+Jmd0OyBFbGlvdCBMZWFyPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIGxlYXJA
Y2lzY28uY29tPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9OVCBz
aXplPTI+Jmd0OyANCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgbWlkY29tIG1haWxpbmcgbGlz
dDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IG1pZGNvbUBpZXRmLm9yZzwvRk9OVD4gDQog
IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8QSB0YXJnZXQ9X2JsYW5rIA0KICBocmVmPSJodHRwOi8v
d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZGNvbSI+aHR0cDovL3d3dzEuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9taWRjb208L0E+PC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9
Mj4mZ3Q7IDwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo=

------_=_NextPart_001_01C12026.EB62C790--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 12:35:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16569
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 12:35:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23584;
	Wed, 8 Aug 2001 12:27:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23555
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 12:27:43 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16340
	for <midcom@ietf.org>; Wed, 8 Aug 2001 12:26:28 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f78GQV918081
	for <midcom@ietf.org>; Wed, 8 Aug 2001 12:26:31 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 8 Aug 2001 11:27:12 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PLQCQF7W>; Wed, 8 Aug 2001 11:26:46 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BC101@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        midcom mail-list <midcom@ietf.org>
Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations
Date: Wed, 8 Aug 2001 11:26:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12026.E67A10D0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12026.E67A10D0
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,
Why can't we wait till the offer/answer exchange (both for regular & Early
media) is completed, before "opening" pinholes? What is the purpose of the
interim "Create" phase? 

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Tuesday, August 07, 2001 7:59 AM
> To: midcom mail-list
> Subject: [midcom] requirements - resource (p.k.a. pin-hole) operations
> 
> 
> Hi all,
> 
> Section 5.3 mentions 3 operations to be performed on a 
> resource (pin-hole)
> in a middlebox. I believe that we need at least 2 more. 
> Namely "create" (or
> "allocate") and "delete" (or "free").
> 
> The create operation would allocate the resource in the middlebox, but
> packets would not be allowed through until an "open" 
> operation is performed.
> An open operation for an unallocated resource could imply a 
> create & open
> operation to minimize the number and size of messages between 
> the agent and
> the middlebox
> 
> The delete operation would be used to free the resource. 
> Close would only
> stop packets from flowing. The resource would not be freed for a close
> operation. The resource could subsequently re-opened by the agent.
> A delete operation on an open resource would imply close & delete.
> 
> A concrete example of an application that needs this 
> capability is SIP. When
> a session is initiated in SIP with an INVITE, the session 
> description may
> define multiple media streams that the client is willing to 
> accept. The
> response from the server may include only a subset of these 
> media streams.
> The resource in the middlebox needs to be allocated/reserved 
> before the
> INVITE is forwarded to the client. However, we do not want to 
> enable packet
> flow until the response is received from the client.
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12026.E67A10D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] requirements - resource (p.k.a. pin-hole) =
operations</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob,</FONT>
<BR><FONT SIZE=3D2>Why can't we wait till the offer/answer exchange =
(both for regular &amp; Early media) is completed, before =
&quot;opening&quot; pinholes? What is the purpose of the interim =
&quot;Create&quot; phase? </FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Bob Penfield [<A =
HREF=3D"mailto:bpenfield@acmepacket.com">mailto:bpenfield@acmepacket.com=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 07, 2001 7:59 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom mail-list</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] requirements - resource =
(p.k.a. pin-hole) operations</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi all,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Section 5.3 mentions 3 operations to be =
performed on a </FONT>
<BR><FONT SIZE=3D2>&gt; resource (pin-hole)</FONT>
<BR><FONT SIZE=3D2>&gt; in a middlebox. I believe that we need at least =
2 more. </FONT>
<BR><FONT SIZE=3D2>&gt; Namely &quot;create&quot; (or</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;allocate&quot;) and &quot;delete&quot; =
(or &quot;free&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The create operation would allocate the =
resource in the middlebox, but</FONT>
<BR><FONT SIZE=3D2>&gt; packets would not be allowed through until an =
&quot;open&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; operation is performed.</FONT>
<BR><FONT SIZE=3D2>&gt; An open operation for an unallocated resource =
could imply a </FONT>
<BR><FONT SIZE=3D2>&gt; create &amp; open</FONT>
<BR><FONT SIZE=3D2>&gt; operation to minimize the number and size of =
messages between </FONT>
<BR><FONT SIZE=3D2>&gt; the agent and</FONT>
<BR><FONT SIZE=3D2>&gt; the middlebox</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The delete operation would be used to free the =
resource. </FONT>
<BR><FONT SIZE=3D2>&gt; Close would only</FONT>
<BR><FONT SIZE=3D2>&gt; stop packets from flowing. The resource would =
not be freed for a close</FONT>
<BR><FONT SIZE=3D2>&gt; operation. The resource could subsequently =
re-opened by the agent.</FONT>
<BR><FONT SIZE=3D2>&gt; A delete operation on an open resource would =
imply close &amp; delete.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A concrete example of an application that needs =
this </FONT>
<BR><FONT SIZE=3D2>&gt; capability is SIP. When</FONT>
<BR><FONT SIZE=3D2>&gt; a session is initiated in SIP with an INVITE, =
the session </FONT>
<BR><FONT SIZE=3D2>&gt; description may</FONT>
<BR><FONT SIZE=3D2>&gt; define multiple media streams that the client =
is willing to </FONT>
<BR><FONT SIZE=3D2>&gt; accept. The</FONT>
<BR><FONT SIZE=3D2>&gt; response from the server may include only a =
subset of these </FONT>
<BR><FONT SIZE=3D2>&gt; media streams.</FONT>
<BR><FONT SIZE=3D2>&gt; The resource in the middlebox needs to be =
allocated/reserved </FONT>
<BR><FONT SIZE=3D2>&gt; before the</FONT>
<BR><FONT SIZE=3D2>&gt; INVITE is forwarded to the client. However, we =
do not want to </FONT>
<BR><FONT SIZE=3D2>&gt; enable packet</FONT>
<BR><FONT SIZE=3D2>&gt; flow until the response is received from the =
client.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; (-:bob</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Robert F. Penfield</FONT>
<BR><FONT SIZE=3D2>&gt; Chief Software Architect</FONT>
<BR><FONT SIZE=3D2>&gt; Acme Packet, Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; 130 New Boston Street</FONT>
<BR><FONT SIZE=3D2>&gt; Woburn, MA 01801</FONT>
<BR><FONT SIZE=3D2>&gt; bpenfield@acmepacket.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12026.E67A10D0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 13:07:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17321
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 13:07:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24989;
	Wed, 8 Aug 2001 13:05:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24926
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 13:05:07 -0400 (EDT)
Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17255
	for <midcom@ietf.org>; Wed, 8 Aug 2001 13:03:59 -0400 (EDT)
Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21])
	by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f78GIrW25144;
	Wed, 8 Aug 2001 09:18:53 -0700
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <P05WQBBL>; Wed, 8 Aug 2001 10:03:39 -0700
Message-ID: <9D048F4A422CD411A56500B0D0209C5B021EDFE1@NS-CA>
From: Wanqun Bao <wbao@netscreen.com>
To: "'Sanjoy Sen'" <sanjoy@nortelnetworks.com>,
        "'Bob Penfield'"
	 <bpenfield@acmepacket.com>,
        midcom mail-list <midcom@ietf.org>
Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations
Date: Wed, 8 Aug 2001 10:03:29 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1202C.0BFF11C0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1202C.0BFF11C0
Content-Type: text/plain;
	charset="iso-8859-1"

Having "Create" w/o open can give the caller more flexibility and the
ability to store
partial attributes of a pinhole on the middlebox if the caller chooses too
(Bob gave
an example w/ SIP in his email).
I'd like to include a flag in the "Create" to indicate whether the pinhole
needs to
be opened after it's created.
 
 
Wanqun

-----Original Message-----
From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]
Sent: Wednesday, August 08, 2001 9:27 AM
To: 'Bob Penfield'; midcom mail-list
Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations



Bob, 
Why can't we wait till the offer/answer exchange (both for regular & Early
media) is completed, before "opening" pinholes? What is the purpose of the
interim "Create" phase? 

> -----Original Message----- 
> From: Bob Penfield [ mailto:bpenfield@acmepacket.com
<mailto:bpenfield@acmepacket.com> ] 
> Sent: Tuesday, August 07, 2001 7:59 AM 
> To: midcom mail-list 
> Subject: [midcom] requirements - resource (p.k.a. pin-hole) operations 
> 
> 
> Hi all, 
> 
> Section 5.3 mentions 3 operations to be performed on a 
> resource (pin-hole) 
> in a middlebox. I believe that we need at least 2 more. 
> Namely "create" (or 
> "allocate") and "delete" (or "free"). 
> 
> The create operation would allocate the resource in the middlebox, but 
> packets would not be allowed through until an "open" 
> operation is performed. 
> An open operation for an unallocated resource could imply a 
> create & open 
> operation to minimize the number and size of messages between 
> the agent and 
> the middlebox 
> 
> The delete operation would be used to free the resource. 
> Close would only 
> stop packets from flowing. The resource would not be freed for a close 
> operation. The resource could subsequently re-opened by the agent. 
> A delete operation on an open resource would imply close & delete. 
> 
> A concrete example of an application that needs this 
> capability is SIP. When 
> a session is initiated in SIP with an INVITE, the session 
> description may 
> define multiple media streams that the client is willing to 
> accept. The 
> response from the server may include only a subset of these 
> media streams. 
> The resource in the middlebox needs to be allocated/reserved 
> before the 
> INVITE is forwarded to the client. However, we do not want to 
> enable packet 
> flow until the response is received from the client. 
> 
> cheers, 
> (-:bob 
> 
> Robert F. Penfield 
> Chief Software Architect 
> Acme Packet, Inc. 
> 130 New Boston Street 
> Woburn, MA 01801 
> bpenfield@acmepacket.com 
> 
> 
> 
> _______________________________________________ 
> midcom mailing list 
> midcom@ietf.org 
> http://www1.ietf.org/mailman/listinfo/midcom
<http://www1.ietf.org/mailman/listinfo/midcom>  
> 


------_=_NextPart_001_01C1202C.0BFF11C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [midcom] requirements - resource (p.k.a. pin-hole) operations</TITLE>

<META content="MSHTML 5.50.4207.2601" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff size=2>Having 
"Create" w/o open can give the caller more flexibility and the ability to 
store</FONT></SPAN></DIV>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff 
size=2>partial attributes of a pinhole on the middlebox if the caller chooses 
too (Bob gave</FONT></SPAN></DIV>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff size=2>an 
example w/ SIP in his email).</FONT></SPAN></DIV>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff size=2>I'd 
like to include a flag in the "Create" to indicate whether the pinhole needs 
to</FONT></SPAN></DIV>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff size=2>be 
opened after it's created.</FONT></SPAN></DIV>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=030225616-08082001><FONT face=Arial color=#0000ff 
size=2>Wanqun</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Sanjoy Sen 
  [mailto:sanjoy@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, August 08, 2001 
  9:27 AM<BR><B>To:</B> 'Bob Penfield'; midcom mail-list<BR><B>Subject:</B> RE: 
  [midcom] requirements - resource (p.k.a. pin-hole) 
  operations<BR><BR></FONT></DIV>
  <P><FONT size=2>Bob,</FONT> <BR><FONT size=2>Why can't we wait till the 
  offer/answer exchange (both for regular &amp; Early media) is completed, 
  before "opening" pinholes? What is the purpose of the interim "Create" phase? 
  </FONT></P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Bob Penfield [<A 
  href="mailto:bpenfield@acmepacket.com">mailto:bpenfield@acmepacket.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Tuesday, August 07, 2001 7:59 AM</FONT> <BR><FONT 
  size=2>&gt; To: midcom mail-list</FONT> <BR><FONT size=2>&gt; Subject: 
  [midcom] requirements - resource (p.k.a. pin-hole) operations</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi 
  all,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Section 5.3 
  mentions 3 operations to be performed on a </FONT><BR><FONT size=2>&gt; 
  resource (pin-hole)</FONT> <BR><FONT size=2>&gt; in a middlebox. I believe 
  that we need at least 2 more. </FONT><BR><FONT size=2>&gt; Namely "create" 
  (or</FONT> <BR><FONT size=2>&gt; "allocate") and "delete" (or "free").</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The create operation would 
  allocate the resource in the middlebox, but</FONT> <BR><FONT size=2>&gt; 
  packets would not be allowed through until an "open" </FONT><BR><FONT 
  size=2>&gt; operation is performed.</FONT> <BR><FONT size=2>&gt; An open 
  operation for an unallocated resource could imply a </FONT><BR><FONT 
  size=2>&gt; create &amp; open</FONT> <BR><FONT size=2>&gt; operation to 
  minimize the number and size of messages between </FONT><BR><FONT size=2>&gt; 
  the agent and</FONT> <BR><FONT size=2>&gt; the middlebox</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; The delete operation would be used to 
  free the resource. </FONT><BR><FONT size=2>&gt; Close would only</FONT> 
  <BR><FONT size=2>&gt; stop packets from flowing. The resource would not be 
  freed for a close</FONT> <BR><FONT size=2>&gt; operation. The resource could 
  subsequently re-opened by the agent.</FONT> <BR><FONT size=2>&gt; A delete 
  operation on an open resource would imply close &amp; delete.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; A concrete example of an application 
  that needs this </FONT><BR><FONT size=2>&gt; capability is SIP. When</FONT> 
  <BR><FONT size=2>&gt; a session is initiated in SIP with an INVITE, the 
  session </FONT><BR><FONT size=2>&gt; description may</FONT> <BR><FONT 
  size=2>&gt; define multiple media streams that the client is willing to 
  </FONT><BR><FONT size=2>&gt; accept. The</FONT> <BR><FONT size=2>&gt; response 
  from the server may include only a subset of these </FONT><BR><FONT 
  size=2>&gt; media streams.</FONT> <BR><FONT size=2>&gt; The resource in the 
  middlebox needs to be allocated/reserved </FONT><BR><FONT size=2>&gt; before 
  the</FONT> <BR><FONT size=2>&gt; INVITE is forwarded to the client. However, 
  we do not want to </FONT><BR><FONT size=2>&gt; enable packet</FONT> <BR><FONT 
  size=2>&gt; flow until the response is received from the client.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; cheers,</FONT> <BR><FONT 
  size=2>&gt; (-:bob</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  Robert F. Penfield</FONT> <BR><FONT size=2>&gt; Chief Software 
  Architect</FONT> <BR><FONT size=2>&gt; Acme Packet, Inc.</FONT> <BR><FONT 
  size=2>&gt; 130 New Boston Street</FONT> <BR><FONT size=2>&gt; Woburn, MA 
  01801</FONT> <BR><FONT size=2>&gt; bpenfield@acmepacket.com</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  midcom mailing list</FONT> <BR><FONT size=2>&gt; midcom@ietf.org</FONT> 
  <BR><FONT size=2>&gt; <A target=_blank 
  href="http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1202C.0BFF11C0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 14:42:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19015
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 14:42:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27778;
	Wed, 8 Aug 2001 14:40:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27747
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 14:40:09 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18957
	for <midcom@ietf.org>; Wed, 8 Aug 2001 14:39:01 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f78IXVF26494;
	Wed, 8 Aug 2001 11:36:48 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f78IZTO22717;
	Wed, 8 Aug 2001 11:35:29 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id LAA06985; Wed, 8 Aug 2001 11:35:16 -0700 (PDT)
Message-ID: <016b01c12038$c1aea470$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>, <midcom@ietf.org>,
        "'Michael W. Condry'" <condry@intel.com>
Cc: <Ietf-openproxy@imc.org>
References: <8006AC6A777F3F4F8B2A6383C19C5B7A05502EFE@XCH-NW-01.nw.nos.boeing.com>
Subject: Re: [midcom] policy & duration
Date: Wed, 8 Aug 2001 14:34:26 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Once we go into IETF review we can expect to hear from
people involved with a number of different working groups,
and I have little doubt that we'll be hearing from people
involved with policy work in a number of different WGs.
Our relationship with OPES is unique in that while our
architecture is different and our goals are very different,
the details overlap considerably.  However, just because
we're keeping a particular eye on OPES and vice-versa doesn't
preclude any participant calling attention to what we're
up to in any other working group.

Melinda

----- Original Message -----
From: "Fleischman, Eric W" <Eric.Fleischman@PSS.Boeing.com>
To: <lear@cisco.com>; <midcom@ietf.org>; "'Melinda Shore'"
<mshore@cisco.com>; "'Michael W. Condry'" <condry@intel.com>
Cc: <Ietf-openproxy@imc.org>
Sent: Wednesday, August 08, 2001 11:15 AM
Subject: RE: [midcom] policy & duration


> Michael,
>
> You and I are in harmony on this. I'm sure that we all can agree that
there are a large number of other WGs which have relevant insight into
elements of the Midcom problem domain, which makes OPES far from unique, and
therefore inappropriate as a target for a special WG-to-WG relationship.
Take, for example, the many other groups addressing elements of policy
including the Policy WG, AAA WG, AFT WG, CDI WG, the IRTF's AAAA WG, and
many, many others.
>
> --Eric
>
> > ----------
> > From: Michael W. Condry[SMTP:condry@intel.com]
> > Sent: Wednesday, August 08, 2001 6:53 AM
> > To: Fleischman, Eric W; lear@cisco.com; midcom@ietf.org; 'Melinda Shore'
> > Cc: Ietf-openproxy@imc.org
> > Subject: RE: [midcom] policy & duration
> >
> > I agree about the dissimilar problem space.
> > However, I still stand by the position that IF there areas of problem
overlap,
> > such as some policy matters, that ignoring each others requirements
> > is a beneficial strategy (or "Dating Relationship").
> >
> > At 02:58 AM 8/8/2001, Fleischman, Eric W wrote:
> > >I see OPES and midcom addressing very dissimilar problems. I do not
view
> > >the problems of enhancing web services (OPES) as directly related to
the
> > >problems of opening pinholes through perimeter devices in a manner
> > >consistent with enterprise policies (midcom). I therefore do not think
> > >that OPES has a role in providing feedback to midcom documents that is
any
> > >more relevant than the insights coming from other IETF WGs. Thus, even
a
> > >"dating relationship" is unnecessary.
> > >
> > > > ----------
> > > > From:         Melinda Shore[SMTP:mshore@cisco.com]
> > > > Sent:         Wednesday, August 08, 2001 1:24 AM
> > > > To:   lear@cisco.com; midcom@ietf.org; Michael W. Condry
> > > > Cc:   Ietf-openproxy@imc.org
> > > > Subject:      Re: [midcom] policy & duration
> > > >
> > > > > From: "Michael W. Condry" <condry@intel.com>
> > > > > To: <lear@cisco.com>; <midcom@ietf.org>
> > > > > Cc: <Ietf-openproxy@imc.org>
> > > > > Sent: Wednesday, August 08, 2001 3:12 AM
> > > > > Subject: Re: [midcom] policy & duration
> > > >
> > > >
> > > > > Do you think that alignment between OPES policy and MidCom policy
> > > > > concepts should be applied where appropriate?  If so, should the
document
> > > > > not reflect this?
> > > >
> > > > I do think that there's value in trying to keep these aligned,
> > > > and it would probably be useful to get some feedback on our
> > > > documents from OPES.  In the interests of keeping our work
> > > > moving forward, it would probably be best to regard midcom
> > > > and OPES as dating rather than married.
> > > >
> > > > Melinda
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > midcom mailing list
> > > > midcom@ietf.org
> > > > http://www1.ietf.org/mailman/listinfo/midcom
> > > >
> >
> > Michael W. Condry
> > Director,  Network Edge Technology
> >
> >
> >
> >
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www1.ietf.org/mailman/listinfo/midcom
> >


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 15:16:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19667
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 15:16:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28906;
	Wed, 8 Aug 2001 15:15:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28875
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 15:15:40 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19633
	for <midcom@ietf.org>; Wed, 8 Aug 2001 15:14:26 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 00DBE8111
	for <midcom@ietf.org>; Wed,  8 Aug 2001 14:15:33 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id OAA23060
	for <midcom@ietf.org>; Wed, 8 Aug 2001 14:15:33 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 8 Aug 2001 14:15:33 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
In-Reply-To: <016b01c12038$c1aea470$7c8921d9@NAUGA>
Message-ID: <Pine.GSO.4.21.0108081400560.19043-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


	I have always assumed that the policy server was supposed to
answer questions, asked by the middlebox, of the form 'is <this>
Agent allowed to do <this> operation?'

	I have also, tacitly, assumed that this would in practical
implementations reduce to:

	'This Agent has just connected to me, what sorts of things
	 can he do?'

	with answers drawn from:

	'Nothing'
	'Read Stuff'
	'Read Stuff and Alter State'

	Possibly with a revokation capability or a "ticket lifetime"
or the like as qualifiers. Anything else seems to this implementor as
mere navel staring. In any case, the middlebox certainly doesn't
monkey around talking to the policy server every time an Agent
wants to do something. I don't mind if the architecture and protocol
wind up PERMITTING the middlebox to do this, but you'd have to have
rocks in your head to actually do it that way.

	This has ABSOLUTELY NOTHING to do with the "policy" implemented
by the middlebox in the form of pinholes and NAT binding. I suggest the
phrases 'Agent Policy' and 'Traffic Policy' to distinguish between these
two utterly disjoint notions, in contexts where it may not be clear.

	This whole discussion is starting to have something of an OSI
flavor to it, in which a whole phalanx of mystical widgets will interact
in ways which have complete and complex taxonomies defined but which
enjoy absolutely no concrete semantics, and of course no syntax -- that
being (quite rightly) out of scope.

	Taxonomy.
	Semantics.
	Syntax.

	You need all three to get anything practical done, and all
three should be tied cleanly together. If you omit one, the result is
pointless. If the connections between them are not clear, the
result is incomprehensible. If one is too complex, the result is
unusable.

		Andrew



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 15:36:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20060
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 15:36:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29541;
	Wed, 8 Aug 2001 15:36:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29510
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 15:36:47 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20039
	for <midcom@ietf.org>; Wed, 8 Aug 2001 15:35:38 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP
	id 4F38E814A; Wed,  8 Aug 2001 14:36:46 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id OAA24832;
	Wed, 8 Aug 2001 14:36:45 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 8 Aug 2001 14:36:45 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: Sanjoy Sen <sanjoy@nortelnetworks.com>
Cc: "'Pyda Srisuresh'" <srisuresh@yahoo.com>, midcom@ietf.org
Subject: RE: [midcom] Interim rev. of the famework draft
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com>
Message-ID: <Pine.GSO.4.21.0108081420530.19043-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Tue, 7 Aug 2001, Sanjoy Sen wrote:

> I've the following questions/comments on the Interim draft:
> 
> 
> 1) In Section 4 - Midcom Protocol - it has been stated that the Midcom
> protocol will consist of a connection set-up phase, run-time phase and a
> connection termination phase. The meaning of "connection" is not clear.   

	I don't think the word 'connection' needs to be defined.
Ideally, there's a better word which means 'some sort of communications
session with sequence numbers or something to make authentication done
at the beginning of the session carry forward without undue effort
throughout the lifetime of the session'

	Then we should use that word. Anything more detailed gets
into implementation, which we're not doing yet.

> 2) In timeline flow in Section 7.1, how would the SIP proxy identify the
> end-to-end RTP, RTCP sessions from the private SIP UA to the external UA on
> receiving the INVITE from external SIP UA? The INVITE SDP does not contain
> any information of the RTP port of the media source.

	This is correct (as Bob has pointed out). The general approach
to this is to use more "funnel" or "cone" shaped pinholes, with
one end unspecified. This is less secure than we would like.

	The SIP community is working on some schemes ("symmetric RTP")
in which the source of one media stream IS in fact the destination of the
other. Also, SIP could surely be extended to include optional media
source information?
> 
> 3) In Section 7.2, what does creating "NAT session descriptors" mean? In
> this context, the authors implied that this allows the early media flow
> through the NAT. From the prior definition of session state, I would tend to
> think that the flow will be allowed (or disallowed) only after a session
> state (i.e., session descriptor + attributes) is created & a function
> specific resource (e.g., NAT bind) is associated with the session state. Is
> this correct? Please clarify.

	This sounds like it's getting into implementation again,
and not merely protocol implementation but middlebox implementation!

	I think the intention of MIDCOM in general and this document
in particular is to allow a variety of implementations. Certainly it
is reasonable to implement some sort of 'session' object inside the
middlebox, and attach things like pinholes and NAT bindings to it.
It is also reasonable to just treat the middlebox as a huge pile
of NAT bindings and pinholes, some of which are loosely related in
some fashion meaningless to the middlebox, but useful to the Agent.

	It is necessary to perform the NAT bindings before forwarding
a SIP INVITE, since the SDP needs to be re-written with information from
the NAT binding. It is reasonable, and perhaps even a good idea, to
open a pinhole at the same time, to allow the media to flow back to
the originator. It is, I understand, easy for the media to beat the
200 OK back.

	If there is a Session Object implemented in the middlebox,
to which things are attached, I personally would instantiate that
object when I saw the INVITE go by. I would immediately attach to
it a NAT binding, I would forward the INVITE, and then immediately
open a pinhole and associate that to the Session Object for the call.

	This is just one of a variety of schemes that can be used.
I hope that does not make things LESS clear, at any rate.

	I do not think the MIDCOM protocol, when defined, should
explicitly support the creation of session objects. Also, implicit in
the question above (I think) was the idea of being able to create
a Traffic Policy thing (a pinhole, or a NAT binding) and then to
separately activate it. I object strenuously to enshrining this
notion in the MIDCOM protocol. If you require atomic activation
of a collection of Traffic Policy things (which is a heck of a good
idea), you should batch them in a single transaction.

	This suggests a requirement for the protocol, that it should
support transactions with multiple requests in them, to be processed
atomically with respect to traffic processing.

		Andrew



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 19:26:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23557
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 19:26:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04299;
	Wed, 8 Aug 2001 19:24:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04274
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 19:24:36 -0400 (EDT)
Received: from hoteldns02.stsn.com (p95.usslc13.stsn.com [208.32.226.95])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23515
	for <midcom@ietf.org>; Wed, 8 Aug 2001 19:23:28 -0400 (EDT)
Received: from BobP ([10.112.2.159])
	by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f78MKAH23824;
	Wed, 8 Aug 2001 16:20:11 -0600
Message-ID: <007e01c12061$1d6bb8c0$9f02700a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "midcom mail-list" <midcom@ietf.org>, "Mark Duffy" <mduffy@quarrytech.com>
References: <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Date: Wed, 8 Aug 2001 19:23:19 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Mark Duffy" <mduffy@quarrytech.com>
To: "Bob Penfield" <bpenfield@acmepacket.com>; "midcom mail-list"
<midcom@ietf.org>
Sent: Wednesday, August 08, 2001 9:16 AM
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!


> Hi,
>
> I think by bundling so much into one conceptual item (resourse aka
ruleset)
> we will make our job harder.  I would view this thing as being composed of
> several important subcomponents that also need to be named:
>
> 1.  a specification for what packets the rule is to match (the
> 5/6/7/whatever-tuple of source/dest address, etc.)
> 2.  a list of middlebox service actions to be applied (e.g.
> pass/drop/nat/etc).
> (Each of the above 1 and 2 might also contain other auxiliary attributes
> such as expiration time, and/or such attributes might belong to the
> resource/ruleset as a whole.)
>
> In fact, Bob calls out those components but does not name them.  I suggest
> we need some terminology for those, perhaps resource-descriptor and
> resource-action (or ruleset-descriptor, ruleset-action).

I like this.

>
> Relative to Bob's 7 Aug msg re "resource (p.k.a. pin-hole) operations"
> which proposes additional operations such as create and delete, I would
> suggest there should be operations to add/delete ruleset-descriptors and
> ruleset-actions to rulesets.

I'm afraid I don't know what value a descriptor is without actions (at least
action=drop) and even less what an action without a descriptor for it.
Besides I think this is getting too deeply into the middlebox.

I would say we also need a "modify" operation to change the actions for a
ruleset. This might involve adding or removing actions from a ruleset.

>
>
> I do agree we also need the concept resource-bundle (or ruleset-bundle or
> foobar-bundle).
>
> --Mark
>
>
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 19:29:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23580
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 19:29:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04449;
	Wed, 8 Aug 2001 19:29:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04418
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 19:29:12 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com ([47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23571
	for <midcom@ietf.org>; Wed, 8 Aug 2001 19:28:05 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA28753
	for <midcom@ietf.org>; Wed, 8 Aug 2001 18:28:29 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Wed, 8 Aug 2001 16:20:46 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZM6ZT>; Wed, 8 Aug 2001 16:28:06 -0700
Message-ID: <A7895B732354D311A4770008C791841A013147CA@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>,
        "'lear@cisco.com'" <lear@cisco.com>, "'Scott Brim'" <sbrim@cisco.com>
Cc: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 16:27:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12061.C2CCE910"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12061.C2CCE910
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

I also think that besides direction, interface should be included. 

Actually I think this 5 tuple should be a N tuple. We might say that some of
the parameters must be understood (like the basic 5 tuple), and others are
optional. 

Since we are taking intelligence out of the box, I need the agent to be able
to tell me how to apply firewall/NAT for overlapping ip address for
different customers, which might even be dynamic, asymetrical routing, etc.
Allowing someone to put more information on the <tuple> would make it
feasible/easier.

Forget me if I got the wrong impression, but browsing through the emails on
the list if seems that we want to take the intelligence out of the
middlebox...but not quite. It seems we are taking out intelligence of a
middlebox that's not that intelligent, since we are not asking much from the
capabilities of the agent.

regards,

Reinaldo 


> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]
> Sent: Wednesday, August 08, 2001 7:22 AM
> To: lear@cisco.com; Scott Brim
> Cc: midcom@ietf.org
> Subject: Re: [midcom] policy & duration
> 
> 
> At 05:35 AM 8/8/01 -0700, Eliot Lear wrote:
> >Scott Brim wrote:
> ...
> >> There's a hint of directionality in here, which we're 
> still debating.
> >
> >First, very basic packet firewalls understand packets and 
> not connections
> >or conversations.  I don't know that we want to require much 
> more than
> >that.
> >
> >Also, I think we remove directionality at our peril.  In an
> >internal/external communication, the reversing of 
> directional rules on
> >interfaces would lead to a weakening of enterprise security.
> 
> Not only that, but the directionality is already an aspect of 
> the existing
> firewall functionality we are providing control over.  I too believe
> directionality should be included.
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12061.C2CCE910
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>I also think that besides direction, interface should =
be included. </FONT>
</P>

<P><FONT SIZE=3D2>Actually I think this 5 tuple should be a N tuple. We =
might say that some of the parameters must be understood (like the =
basic 5 tuple), and others are optional. </FONT></P>

<P><FONT SIZE=3D2>Since we are taking intelligence out of the box, I =
need the agent to be able to tell me how to apply firewall/NAT for =
overlapping ip address for different customers, which might even be =
dynamic, asymetrical routing, etc. Allowing someone to put more =
information on the &lt;tuple&gt; would make it =
feasible/easier.</FONT></P>

<P><FONT SIZE=3D2>Forget me if I got the wrong impression, but browsing =
through the emails on the list if seems that we want to take the =
intelligence out of the middlebox...but not quite. It seems we are =
taking out intelligence of a middlebox that's not that intelligent, =
since we are not asking much from the capabilities of the =
agent.</FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 08, 2001 7:22 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: lear@cisco.com; Scott Brim</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] policy &amp; =
duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 05:35 AM 8/8/01 -0700, Eliot Lear =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Scott Brim wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; There's a hint of directionality in =
here, which we're </FONT>
<BR><FONT SIZE=3D2>&gt; still debating.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;First, very basic packet firewalls =
understand packets and </FONT>
<BR><FONT SIZE=3D2>&gt; not connections</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;or conversations.&nbsp; I don't know that =
we want to require much </FONT>
<BR><FONT SIZE=3D2>&gt; more than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;that.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Also, I think we remove directionality at =
our peril.&nbsp; In an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;internal/external communication, the =
reversing of </FONT>
<BR><FONT SIZE=3D2>&gt; directional rules on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;interfaces would lead to a weakening of =
enterprise security.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Not only that, but the directionality is =
already an aspect of </FONT>
<BR><FONT SIZE=3D2>&gt; the existing</FONT>
<BR><FONT SIZE=3D2>&gt; firewall functionality we are providing control =
over.&nbsp; I too believe</FONT>
<BR><FONT SIZE=3D2>&gt; directionality should be included.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12061.C2CCE910--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 19:36:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23681
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 19:36:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04784;
	Wed, 8 Aug 2001 19:35:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04753
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 19:35:56 -0400 (EDT)
Received: from hoteldns02.stsn.com (p95.usslc13.stsn.com [208.32.226.95])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23670
	for <midcom@ietf.org>; Wed, 8 Aug 2001 19:34:48 -0400 (EDT)
Received: from BobP ([10.112.2.159])
	by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f78MVJH24104;
	Wed, 8 Aug 2001 16:31:19 -0600
Message-ID: <008e01c12062$ad7b3020$9f02700a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <lear@cisco.com>, "Scott Brim" <sbrim@cisco.com>,
        "Mark Duffy" <mduffy@quarrytech.com>
Cc: <midcom@ietf.org>
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
Subject: Re: [midcom] policy & duration
Date: Wed, 8 Aug 2001 19:34:24 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Mark Duffy" <mduffy@quarrytech.com>
To: <lear@cisco.com>; "Scott Brim" <sbrim@cisco.com>
Cc: <midcom@ietf.org>
Sent: Wednesday, August 08, 2001 10:21 AM
Subject: Re: [midcom] policy & duration


> At 05:35 AM 8/8/01 -0700, Eliot Lear wrote:
> >Scott Brim wrote:
> ...
> >> There's a hint of directionality in here, which we're still debating.
> >
> >First, very basic packet firewalls understand packets and not connections
> >or conversations.  I don't know that we want to require much more than
> >that.
> >
> >Also, I think we remove directionality at our peril.  In an
> >internal/external communication, the reversing of directional rules on
> >interfaces would lead to a weakening of enterprise security.
>
> Not only that, but the directionality is already an aspect of the existing
> firewall functionality we are providing control over.  I too believe
> directionality should be included.
>
I just want to chime in a say expression of direction without a notion of
which side is in or out is not of much use. I think is would be more useful
to define the ingress and egress realms. As I have said before, I believe
assuming all middleboxes will be connected to exactly two realms would be
unwise.

>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 19:36:29 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23708
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 19:36:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04831;
	Wed, 8 Aug 2001 19:36:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04796
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 19:36:09 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23674
	for <midcom@ietf.org>; Wed, 8 Aug 2001 19:35:01 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 8843781E3
	for <midcom@ietf.org>; Wed,  8 Aug 2001 18:36:08 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id SAA10314
	for <midcom@ietf.org>; Wed, 8 Aug 2001 18:36:08 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 8 Aug 2001 18:36:08 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: RE: [midcom] policy & duration
In-Reply-To: <A7895B732354D311A4770008C791841A013147CA@zsc4c014.us.nortel.com>
Message-ID: <Pine.GSO.4.21.0108081833510.19043-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Wed, 8 Aug 2001, Reinaldo Penno wrote:

> Forget me if I got the wrong impression, but browsing through the emails on
> the list if seems that we want to take the intelligence out of the
> middlebox...but not quite. It seems we are taking out intelligence of a
> middlebox that's not that intelligent, since we are not asking much from the
> capabilities of the agent.

	We say this, I think. I think we MEAN that we want to remove
application specific code from the middlebox. I am all for lots of
intelligence in middleboxes, just nothing specific to SIP or whatever.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 19:51:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23856
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 19:51:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05049;
	Wed, 8 Aug 2001 19:51:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05020
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 19:51:44 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com ([47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23843
	for <midcom@ietf.org>; Wed, 8 Aug 2001 19:50:36 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA01759
	for <midcom@ietf.org>; Wed, 8 Aug 2001 18:50:57 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Wed, 8 Aug 2001 16:43:00 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZM7HC>; Wed, 8 Aug 2001 16:50:21 -0700
Message-ID: <A7895B732354D311A4770008C791841A013147D8@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 16:50:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12064.E1E00D20"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12064.E1E00D20
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Andrew Molitor [mailto:amolitor@visi.com]
> Sent: Wednesday, August 08, 2001 4:36 PM
> To: midcom@ietf.org
> Subject: RE: [midcom] policy & duration
> 
> 
> 
> 
> On Wed, 8 Aug 2001, Reinaldo Penno wrote:
> 
> > Forget me if I got the wrong impression, but browsing 
> through the emails on
> > the list if seems that we want to take the intelligence out of the
> > middlebox...but not quite. It seems we are taking out 
> intelligence of a
> > middlebox that's not that intelligent, since we are not 
> asking much from the
> > capabilities of the agent.
> 
> 	We say this, I think. I think we MEAN that we want to remove
> application specific code from the middlebox. 

Hello Andrew,

But when  you remove, for instance, SIP specific code from my middlebox, you
also remove the possibility of interaction that the SIP code had with other
parts of the system (routing processes, interface manager, firewall, etc).

So, unless you compensate that somehow so that the MA can send me extended
information beside the 5/6 tuple, the MA will never be able to open
pinholes/NAT for complex deployments since it has very little knowledge the
system. 

regards,

Reinaldo

I am all for lots of
> intelligence in middleboxes, just nothing specific to SIP or whatever.


> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12064.E1E00D20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Andrew Molitor [<A =
HREF=3D"mailto:amolitor@visi.com">mailto:amolitor@visi.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 08, 2001 4:36 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [midcom] policy &amp; =
duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, 8 Aug 2001, Reinaldo Penno =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Forget me if I got the wrong impression, =
but browsing </FONT>
<BR><FONT SIZE=3D2>&gt; through the emails on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the list if seems that we want to take the =
intelligence out of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; middlebox...but not quite. It seems we are =
taking out </FONT>
<BR><FONT SIZE=3D2>&gt; intelligence of a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; middlebox that's not that intelligent, =
since we are not </FONT>
<BR><FONT SIZE=3D2>&gt; asking much from the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; capabilities of the agent.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We say this, I =
think. I think we MEAN that we want to remove</FONT>
<BR><FONT SIZE=3D2>&gt; application specific code from the middlebox. =
</FONT>
</P>

<P><FONT SIZE=3D2>Hello Andrew,</FONT>
</P>

<P><FONT SIZE=3D2>But when&nbsp; you remove, for instance, SIP specific =
code from my middlebox, you also remove the possibility of interaction =
that the SIP code had with other parts of the system (routing =
processes, interface manager, firewall, etc).</FONT></P>

<P><FONT SIZE=3D2>So, unless you compensate that somehow so that the MA =
can send me extended information beside the 5/6 tuple, the MA will =
never be able to open pinholes/NAT for complex deployments since it has =
very little knowledge the system. </FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>

<P><FONT SIZE=3D2>I am all for lots of</FONT>
<BR><FONT SIZE=3D2>&gt; intelligence in middleboxes, just nothing =
specific to SIP or whatever.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12064.E1E00D20--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 19:58:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23922
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 19:58:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05219;
	Wed, 8 Aug 2001 19:58:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05152
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 19:58:36 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23900
	for <midcom@ietf.org>; Wed, 8 Aug 2001 19:57:28 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 4DB0381D7
	for <midcom@ietf.org>; Wed,  8 Aug 2001 18:58:36 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id SAA13014
	for <midcom@ietf.org>; Wed, 8 Aug 2001 18:58:36 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 8 Aug 2001 18:58:36 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: RE: [midcom] policy & duration
In-Reply-To: <A7895B732354D311A4770008C791841A013147D8@zsc4c014.us.nortel.com>
Message-ID: <Pine.GSO.4.21.0108081851510.10381-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Wed, 8 Aug 2001, Reinaldo Penno wrote:

> 
> 
> > -----Original Message-----
> > From: Andrew Molitor [mailto:amolitor@visi.com]
> > Sent: Wednesday, August 08, 2001 4:36 PM
> > To: midcom@ietf.org
> > Subject: RE: [midcom] policy & duration
> > 
> > 	We say this, I think. I think we MEAN that we want to remove
> > application specific code from the middlebox. 
> 
> Hello Andrew,
> 
> But when  you remove, for instance, SIP specific code from my middlebox, you
> also remove the possibility of interaction that the SIP code had with other
> parts of the system (routing processes, interface manager, firewall, etc).
> 
> So, unless you compensate that somehow so that the MA can send me extended
> information beside the 5/6 tuple, the MA will never be able to open
> pinholes/NAT for complex deployments since it has very little knowledge the
> system. 

	I think it's important to figure out what those essential
interactions are between your SIP code and the routing processes,
interface manager, firewall, etc. Presumably the SIP code interacts
with many things non-SIP, some of those things are sort of network-ish,
and some of THOSE things might naturally fall into a middlebox.

	Whatever interactions can be reasonably imagined between
say, SIP code and such middleboxy non-SIP things should be well
understood before we go much further. The point of MIDCOM is, to
first order, to develop a protocol expressive enough to capture
those interactions. If we fail to produce something powerful enough
for, say, the SIP community, we have failed entirely.

	I don't actually know what, apart from 5-tuples and masks
for them needs to get carted around in these interactions. That much
information seems to work fairly well for pinholes and NAT bindings,
at any rate. Well, it's nice to be able to carry around things
like expected bandwidth and pinhole lifetime and whatnot, is this
the kind of thing you mean? Or do you want to open a pinhole for
RTP traffic, and be able to specify approximately what RTP traffic
looks like BEYOND 'UDP traffic from that place to this other place'?
Things like size of packet, expected values at expected offsets in
the payload?

		Andrew



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 20:07:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24025
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 20:07:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05685;
	Wed, 8 Aug 2001 20:07:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05654
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 20:07:36 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24009
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:06:25 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7906D921490
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:06:14 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Wed, 8 Aug 2001 19:06:39 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZM73G>; Wed, 8 Aug 2001 17:06:12 -0700
Message-ID: <A7895B732354D311A4770008C791841A013147E2@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 17:06:11 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12067.18DF9230"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12067.18DF9230
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Andrew,

> 	I think it's important to figure out what those essential
> interactions are between your SIP code and the routing processes,
> interface manager, firewall, etc. Presumably the SIP code interacts
> with many things non-SIP, some of those things are sort of 
> network-ish,
> and some of THOSE things might naturally fall into a middlebox.
> 
> 	Whatever interactions can be reasonably imagined between
> say, SIP code and such middleboxy non-SIP things should be well
> understood before we go much further. The point of MIDCOM is, to
> first order, to develop a protocol expressive enough to capture
> those interactions. If we fail to produce something powerful enough
> for, say, the SIP community, we have failed entirely. 

We are in agreement. 

> 
> 	I don't actually know what, apart from 5-tuples and masks
> for them needs to get carted around in these interactions. That much
> information seems to work fairly well for pinholes and NAT bindings,
> at any rate. Well, it's nice to be able to carry around things
> like expected bandwidth and pinhole lifetime and whatnot, is this
> the kind of thing you mean? 

I simpler example is interface. 

Or do you want to open a pinhole for
> RTP traffic, and be able to specify approximately what RTP traffic
> looks like BEYOND 'UDP traffic from that place to this other place'?

Yes.

> Things like size of packet, expected values at expected offsets in
> the payload?

Yes.

thanks,

Reinaldo


------_=_NextPart_001_01C12067.18DF9230
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello Andrew,</FONT>
</P>

<P><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think it's important to figure out what those essential</FONT>
<BR><FONT SIZE=2>&gt; interactions are between your SIP code and the routing processes,</FONT>
<BR><FONT SIZE=2>&gt; interface manager, firewall, etc. Presumably the SIP code interacts</FONT>
<BR><FONT SIZE=2>&gt; with many things non-SIP, some of those things are sort of </FONT>
<BR><FONT SIZE=2>&gt; network-ish,</FONT>
<BR><FONT SIZE=2>&gt; and some of THOSE things might naturally fall into a middlebox.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Whatever interactions can be reasonably imagined between</FONT>
<BR><FONT SIZE=2>&gt; say, SIP code and such middleboxy non-SIP things should be well</FONT>
<BR><FONT SIZE=2>&gt; understood before we go much further. The point of MIDCOM is, to</FONT>
<BR><FONT SIZE=2>&gt; first order, to develop a protocol expressive enough to capture</FONT>
<BR><FONT SIZE=2>&gt; those interactions. If we fail to produce something powerful enough</FONT>
<BR><FONT SIZE=2>&gt; for, say, the SIP community, we have failed entirely. </FONT>
</P>

<P><FONT SIZE=2>We are in agreement. </FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I don't actually know what, apart from 5-tuples and masks</FONT>
<BR><FONT SIZE=2>&gt; for them needs to get carted around in these interactions. That much</FONT>
<BR><FONT SIZE=2>&gt; information seems to work fairly well for pinholes and NAT bindings,</FONT>
<BR><FONT SIZE=2>&gt; at any rate. Well, it's nice to be able to carry around things</FONT>
<BR><FONT SIZE=2>&gt; like expected bandwidth and pinhole lifetime and whatnot, is this</FONT>
<BR><FONT SIZE=2>&gt; the kind of thing you mean? </FONT>
</P>

<P><FONT SIZE=2>I simpler example is interface. </FONT>
</P>

<P><FONT SIZE=2>Or do you want to open a pinhole for</FONT>
<BR><FONT SIZE=2>&gt; RTP traffic, and be able to specify approximately what RTP traffic</FONT>
<BR><FONT SIZE=2>&gt; looks like BEYOND 'UDP traffic from that place to this other place'?</FONT>
</P>

<P><FONT SIZE=2>Yes.</FONT>
</P>

<P><FONT SIZE=2>&gt; Things like size of packet, expected values at expected offsets in</FONT>
<BR><FONT SIZE=2>&gt; the payload?</FONT>
</P>

<P><FONT SIZE=2>Yes.</FONT>
</P>

<P><FONT SIZE=2>thanks,</FONT>
</P>

<P><FONT SIZE=2>Reinaldo</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12067.18DF9230--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 20:15:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24114
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 20:15:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05818;
	Wed, 8 Aug 2001 20:14:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05790
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 20:14:54 -0400 (EDT)
Received: from hoteldns02.stsn.com (p95.usslc13.stsn.com [208.32.226.95])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24080
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:13:46 -0400 (EDT)
Received: from BobP ([10.112.2.159])
	by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f78NAKH25113;
	Wed, 8 Aug 2001 17:10:21 -0600
Message-ID: <00ec01c12068$1fa9e4c0$9f02700a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Sanjoy Sen" <sanjoy@nortelnetworks.com>,
        "midcom mail-list" <midcom@ietf.org>
References: <85AA7486A2C1D411BCA20000F8073E43016BC101@crchy271.us.nortel.com>
Subject: Re: [midcom] requirements - resource (p.k.a. pin-hole) operations
Date: Wed, 8 Aug 2001 20:13:28 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



----- Original Message -----
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>; "midcom mail-list"
<midcom@ietf.org>
Sent: Wednesday, August 08, 2001 12:26 PM
Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations


> Bob,
> Why can't we wait till the offer/answer exchange (both for regular & Early
> media) is completed, before "opening" pinholes? What is the purpose of the
> interim "Create" phase?
>

I suppose we could do that. However, one might want to make sure there are
enough resources in the middlebox to handle the flow before sending the
INVITE on the called party.

> > -----Original Message-----
> > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > Sent: Tuesday, August 07, 2001 7:59 AM
> > To: midcom mail-list
> > Subject: [midcom] requirements - resource (p.k.a. pin-hole) operations
> >
> >
> > Hi all,
> >
> > Section 5.3 mentions 3 operations to be performed on a
> > resource (pin-hole)
> > in a middlebox. I believe that we need at least 2 more.
> > Namely "create" (or
> > "allocate") and "delete" (or "free").
> >
> > The create operation would allocate the resource in the middlebox, but
> > packets would not be allowed through until an "open"
> > operation is performed.
> > An open operation for an unallocated resource could imply a
> > create & open
> > operation to minimize the number and size of messages between
> > the agent and
> > the middlebox
> >
> > The delete operation would be used to free the resource.
> > Close would only
> > stop packets from flowing. The resource would not be freed for a close
> > operation. The resource could subsequently re-opened by the agent.
> > A delete operation on an open resource would imply close & delete.
> >
> > A concrete example of an application that needs this
> > capability is SIP. When
> > a session is initiated in SIP with an INVITE, the session
> > description may
> > define multiple media streams that the client is willing to
> > accept. The
> > response from the server may include only a subset of these
> > media streams.
> > The resource in the middlebox needs to be allocated/reserved
> > before the
> > INVITE is forwarded to the client. However, we do not want to
> > enable packet
> > flow until the response is received from the client.
> >
> > cheers,
> > (-:bob
> >
> > Robert F. Penfield
> > Chief Software Architect
> > Acme Packet, Inc.
> > 130 New Boston Street
> > Woburn, MA 01801
> > bpenfield@acmepacket.com
> >
> >
> >
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www1.ietf.org/mailman/listinfo/midcom
> >
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 20:31:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24249
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 20:31:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06103;
	Wed, 8 Aug 2001 20:30:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06062
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 20:30:13 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24205
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:29:04 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f790T8923224
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:29:08 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 8 Aug 2001 19:29:33 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PLQCQPVW>; Wed, 8 Aug 2001 19:29:08 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BC109@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Andrew Molitor'" <amolitor@visi.com>
Cc: "'Pyda Srisuresh'" <srisuresh@yahoo.com>, midcom@ietf.org
Subject: RE: [midcom] Interim rev. of the famework draft
Date: Wed, 8 Aug 2001 19:29:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1206A.4D3F97C0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1206A.4D3F97C0
Content-Type: text/plain;
	charset="iso-8859-1"



> 
> 	I do not think the MIDCOM protocol, when defined, should
> explicitly support the creation of session objects. 

We should separate out Session descriptors and flows. As was pointed out,
Session descriptors relate to end-points. Flow is end-2-end and it may be
possible to construct a flow description, partially or completely, from the
Session descriptors. In my mind, the Midcom agent (via the Midcom protocol)
should provide information to the Middlebox to construct such a flow
description (to match incoming packets) and associate a
function/action/resource/service with the flow description. These two things
- flow description (which is derived by the Middlebox) and
function/action/resource/service (which are entities in the Middlebox) -
should be kept separate. 

> 
> 	This suggests a requirement for the protocol, that it should
> support transactions with multiple requests in them, to be processed
> atomically with respect to traffic processing.
> 

I agree.

------_=_NextPart_001_01C1206A.4D3F97C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Interim rev. of the famework draft</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I do not think =
the MIDCOM protocol, when defined, should</FONT>
<BR><FONT SIZE=3D2>&gt; explicitly support the creation of session =
objects. </FONT>
</P>

<P><FONT SIZE=3D2>We should separate out Session descriptors and flows. =
As was pointed out, Session descriptors relate to end-points. Flow is =
end-2-end and it may be possible to construct a flow description, =
partially or completely, from the Session descriptors. In my mind, the =
Midcom agent (via the Midcom protocol) should provide information to =
the Middlebox to construct such a flow description (to match incoming =
packets) and associate a function/action/resource/service with the flow =
description. These two things - flow description (which is derived by =
the Middlebox) and function/action/resource/service (which are entities =
in the Middlebox) - should be kept separate. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This suggests a =
requirement for the protocol, that it should</FONT>
<BR><FONT SIZE=3D2>&gt; support transactions with multiple requests in =
them, to be processed</FONT>
<BR><FONT SIZE=3D2>&gt; atomically with respect to traffic =
processing.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I agree.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1206A.4D3F97C0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 20:33:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24269
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 20:33:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06299;
	Wed, 8 Aug 2001 20:33:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06270
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 20:33:21 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24262
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:32:12 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f790WK923450
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:32:21 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 8 Aug 2001 19:32:55 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PLQCQPWJ>; Wed, 8 Aug 2001 19:32:30 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BC10A@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Andrew Molitor'" <amolitor@visi.com>, midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 19:32:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1206A.C61B1390"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1206A.C61B1390
Content-Type: text/plain;
	charset="iso-8859-1"



> 
> 	This has ABSOLUTELY NOTHING to do with the "policy" implemented
> by the middlebox in the form of pinholes and NAT binding. I 
> suggest the
> phrases 'Agent Policy' and 'Traffic Policy' to distinguish 
> between these
> two utterly disjoint notions, in contexts where it may not be clear.
> 

I agree.



------_=_NextPart_001_01C1206A.C61B1390
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This has ABSOLUTELY NOTHING to do with the &quot;policy&quot; implemented</FONT>
<BR><FONT SIZE=2>&gt; by the middlebox in the form of pinholes and NAT binding. I </FONT>
<BR><FONT SIZE=2>&gt; suggest the</FONT>
<BR><FONT SIZE=2>&gt; phrases 'Agent Policy' and 'Traffic Policy' to distinguish </FONT>
<BR><FONT SIZE=2>&gt; between these</FONT>
<BR><FONT SIZE=2>&gt; two utterly disjoint notions, in contexts where it may not be clear.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

<P><FONT SIZE=2>I agree.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1206A.C61B1390--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 20:39:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24363
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 20:39:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06381;
	Wed, 8 Aug 2001 20:39:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06348
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 20:39:03 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com ([47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24346
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:37:55 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id TAA05316
	for <midcom@ietf.org>; Wed, 8 Aug 2001 19:38:31 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Wed, 8 Aug 2001 17:30:34 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZM791>; Wed, 8 Aug 2001 17:37:54 -0700
Message-ID: <A7895B732354D311A4770008C791841A013147F4@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Wed, 8 Aug 2001 17:37:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1206B.818D86D0"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1206B.818D86D0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Andrew,
 
just adding some points on what we disucssed based on my reading of the
charter...
 
IMO MIDCOM should be a protocol that is general or extensible enough so that
I can inform the firewall how to identify, for instance, RTP packets or more
generally offsets as you said. 
 
It seems some people only want to solve specifically "how to pass SIP
through a firewall". This is very evident from the fact that some people
think 5 tuple is enough. If we are thinking about getting any type of ALGs
from the middlebox, put on a MA and still have the same funcionality,
clearly this is not enough.
 
The charter of the group is very generic. If what we want to solve is how to
pass SIP through a firewall, then we need to change  the charter to
something like "SIP Firewall Transversal Group", cause we are clearly not
making it general/extensible enough.
 
thanks,
 
Reinaldo

-----Original Message-----   
From: Penno, Reinaldo [SC9:T327:EXCH] 
Sent: Wednesday, August 08, 2001 5:06 PM
To: 'Andrew Molitor';  <mailto:'midcom@ietf.org'> 'midcom@ietf.org'  
Subject: RE: [midcom] policy & duration



Hello Andrew, 

>       I think it's important to figure out what those essential 
> interactions are between your SIP code and the routing processes, 
> interface manager, firewall, etc. Presumably the SIP code interacts 
> with many things non-SIP, some of those things are sort of 
> network-ish, 
> and some of THOSE things might naturally fall into a middlebox. 
> 
>       Whatever interactions can be reasonably imagined between 
> say, SIP code and such middleboxy non-SIP things should be well 
> understood before we go much further. The point of MIDCOM is, to 
> first order, to develop a protocol expressive enough to capture 
> those interactions. If we fail to produce something powerful enough 
> for, say, the SIP community, we have failed entirely. 

We are in agreement. 

> 
>       I don't actually know what, apart from 5-tuples and masks 
> for them needs to get carted around in these interactions. That much 
> information seems to work fairly well for pinholes and NAT bindings, 
> at any rate. Well, it's nice to be able to carry around things 
> like expected bandwidth and pinhole lifetime and whatnot, is this 
> the kind of thing you mean? 

I simpler example is interface. 

Or do you want to open a pinhole for 
> RTP traffic, and be able to specify approximately what RTP traffic 
> looks like BEYOND 'UDP traffic from that place to this other place'? 

Yes. 

> Things like size of packet, expected values at expected offsets in 
> the payload? 

Yes. 

thanks, 

Reinaldo 


------_=_NextPart_001_01C1206B.818D86D0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [midcom] policy & duration</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff size=2>Hello 
Andrew,</FONT></SPAN></DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff size=2>just 
adding some points on what we disucssed based on my reading of the 
charter...</FONT></SPAN></DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2>IMO&nbsp;MIDCOM should be a protocol that is general or extensible enough 
so that I can inform the firewall how to identify, for instance,&nbsp;RTP 
packets or more generally offsets as you said. </FONT></SPAN></DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff size=2>It 
seems some people only want to solve specifically "how to pass SIP through a 
firewall".&nbsp;This is very evident from the fact that some people think 5 
tuple is enough. If we are thinking about getting any type of ALGs from the 
middlebox, put on a MA and still have the same funcionality, clearly this is not 
enough.</FONT></SPAN></DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff size=2>The 
charter of the group is very generic.&nbsp;If what we want to solve is how to 
pass SIP through a firewall, then we need to change&nbsp;&nbsp;the charter to 
something like "SIP Firewall Transversal Group", cause we are clearly not making 
it general/extensible&nbsp;enough.</FONT></SPAN></DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2>thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043092100-09082001><FONT face=Arial color=#0000ff 
size=2>Reinaldo</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2>-----Original Message-----<SPAN class=043092100-09082001><FONT 
  face=Arial color=#0000ff>&nbsp;&nbsp;&nbsp;</FONT></SPAN><BR><B>From:</B> 
  Penno, Reinaldo [SC9:T327:EXCH] <BR><B>Sent:</B> Wednesday, August 08, 2001 
  5:06 PM<BR><B>To:</B> 'Andrew Molitor'; </FONT><A 
  href="mailto:'midcom@ietf.org'"><FONT size=2>'midcom@ietf.org'</FONT></A><FONT 
  size=2><SPAN class=043092100-09082001><FONT face=Arial 
  color=#0000ff>&nbsp;&nbsp;</FONT></SPAN><BR><B>Subject:</B> RE: [midcom] 
  policy &amp; duration<BR><BR></FONT></FONT></DIV>
  <P><FONT size=2>Hello Andrew,</FONT> </P>
  <P><FONT size=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think it's important to 
  figure out what those essential</FONT> <BR><FONT size=2>&gt; interactions are 
  between your SIP code and the routing processes,</FONT> <BR><FONT size=2>&gt; 
  interface manager, firewall, etc. Presumably the SIP code interacts</FONT> 
  <BR><FONT size=2>&gt; with many things non-SIP, some of those things are sort 
  of </FONT><BR><FONT size=2>&gt; network-ish,</FONT> <BR><FONT size=2>&gt; and 
  some of THOSE things might naturally fall into a middlebox.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Whatever interactions can be reasonably imagined between</FONT> <BR><FONT 
  size=2>&gt; say, SIP code and such middleboxy non-SIP things should be 
  well</FONT> <BR><FONT size=2>&gt; understood before we go much further. The 
  point of MIDCOM is, to</FONT> <BR><FONT size=2>&gt; first order, to develop a 
  protocol expressive enough to capture</FONT> <BR><FONT size=2>&gt; those 
  interactions. If we fail to produce something powerful enough</FONT> <BR><FONT 
  size=2>&gt; for, say, the SIP community, we have failed entirely. </FONT></P>
  <P><FONT size=2>We are in agreement. </FONT></P>
  <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I don't actually know what, apart from 5-tuples 
  and masks</FONT> <BR><FONT size=2>&gt; for them needs to get carted around in 
  these interactions. That much</FONT> <BR><FONT size=2>&gt; information seems 
  to work fairly well for pinholes and NAT bindings,</FONT> <BR><FONT 
  size=2>&gt; at any rate. Well, it's nice to be able to carry around 
  things</FONT> <BR><FONT size=2>&gt; like expected bandwidth and pinhole 
  lifetime and whatnot, is this</FONT> <BR><FONT size=2>&gt; the kind of thing 
  you mean? </FONT></P>
  <P><FONT size=2>I simpler example is interface. </FONT></P>
  <P><FONT size=2>Or do you want to open a pinhole for</FONT> <BR><FONT 
  size=2>&gt; RTP traffic, and be able to specify approximately what RTP 
  traffic</FONT> <BR><FONT size=2>&gt; looks like BEYOND 'UDP traffic from that 
  place to this other place'?</FONT> </P>
  <P><FONT size=2>Yes.</FONT> </P>
  <P><FONT size=2>&gt; Things like size of packet, expected values at expected 
  offsets in</FONT> <BR><FONT size=2>&gt; the payload?</FONT> </P>
  <P><FONT size=2>Yes.</FONT> </P>
  <P><FONT size=2>thanks,</FONT> </P>
  <P><FONT size=2>Reinaldo</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1206B.818D86D0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 20:40:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24401
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 20:40:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06439;
	Wed, 8 Aug 2001 20:41:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06410
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 20:41:22 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com ([47.234.0.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24391
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:40:13 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k [47.113.64.104])
	by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f790eL408762
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:40:26 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 8 Aug 2001 19:33:28 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PLQCQPXC>; Wed, 8 Aug 2001 19:39:32 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BC10B@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>,
        Bob Penfield <bpenfield@acmepacket.com>,
        midcom mail-list <midcom@ietf.org>
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!
Date: Wed, 8 Aug 2001 19:39:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1206B.C1143100"
X-Orig: <sanjoy@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1206B.C1143100
Content-Type: text/plain;
	charset="iso-8859-1"



> 
> 1.  a specification for what packets the rule is to match (the
> 5/6/7/whatever-tuple of source/dest address, etc.)
> 2.  a list of middlebox service actions to be applied (e.g.
> pass/drop/nat/etc).
 
> 
> In fact, Bob calls out those components but does not name 
> them.  I suggest
> we need some terminology for those, perhaps resource-descriptor and
> resource-action (or ruleset-descriptor, ruleset-action).
> 

I support this separation. Maybe we can call item # 1. Flow descriptor
(because of their end-2-end nature) and item # 2. Resource-action


------_=_NextPart_001_01C1206B.C1143100
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] pin-holes, sessions and flows, oh my!</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1.&nbsp; a specification for what packets the =
rule is to match (the</FONT>
<BR><FONT SIZE=3D2>&gt; 5/6/7/whatever-tuple of source/dest address, =
etc.)</FONT>
<BR><FONT SIZE=3D2>&gt; 2.&nbsp; a list of middlebox service actions to =
be applied (e.g.</FONT>
<BR><FONT SIZE=3D2>&gt; pass/drop/nat/etc).</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In fact, Bob calls out those components but =
does not name </FONT>
<BR><FONT SIZE=3D2>&gt; them.&nbsp; I suggest</FONT>
<BR><FONT SIZE=3D2>&gt; we need some terminology for those, perhaps =
resource-descriptor and</FONT>
<BR><FONT SIZE=3D2>&gt; resource-action (or ruleset-descriptor, =
ruleset-action).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I support this separation. Maybe we can call item # =
1. Flow descriptor (because of their end-2-end nature) and item # 2. =
Resource-action</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C1206B.C1143100--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug  8 20:45:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24458
	for <midcom-archive@odin.ietf.org>; Wed, 8 Aug 2001 20:45:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06547;
	Wed, 8 Aug 2001 20:46:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06523
	for <midcom@ns.ietf.org>; Wed, 8 Aug 2001 20:46:09 -0400 (EDT)
Received: from hoteldns02.stsn.com (p95.usslc13.stsn.com [208.32.226.95])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24454
	for <midcom@ietf.org>; Wed, 8 Aug 2001 20:44:58 -0400 (EDT)
Received: from BobP ([10.112.2.159])
	by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f78NfXH25861;
	Wed, 8 Aug 2001 17:41:36 -0600
Message-ID: <014401c1206c$7dbd4f80$9f02700a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "Sanjoy Sen" <sanjoy@nortelnetworks.com>,
        "midcom mail-list" <midcom@ietf.org>
References: <85AA7486A2C1D411BCA20000F8073E43016BC101@crchy271.us.nortel.com> <00ec01c12068$1fa9e4c0$9f02700a@acmepacket.com>
Subject: Re: [midcom] requirements - resource (p.k.a. pin-hole) operations
Date: Wed, 8 Aug 2001 20:44:41 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Oops, I forgot that in the case of NAT we need to get the NAT binding to
modify the IP address in the SDP before forwarding the INVITE.

----- Original Message -----
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Sanjoy Sen" <sanjoy@nortelnetworks.com>; "midcom mail-list"
<midcom@ietf.org>
Sent: Wednesday, August 08, 2001 8:13 PM
Subject: Re: [midcom] requirements - resource (p.k.a. pin-hole) operations


>
>
> ----- Original Message -----
> From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
> To: "'Bob Penfield'" <bpenfield@acmepacket.com>; "midcom mail-list"
> <midcom@ietf.org>
> Sent: Wednesday, August 08, 2001 12:26 PM
> Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations
>
>
> > Bob,
> > Why can't we wait till the offer/answer exchange (both for regular &
Early
> > media) is completed, before "opening" pinholes? What is the purpose of
the
> > interim "Create" phase?
> >
>
> I suppose we could do that. However, one might want to make sure there are
> enough resources in the middlebox to handle the flow before sending the
> INVITE on the called party.
>
> > > -----Original Message-----
> > > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > > Sent: Tuesday, August 07, 2001 7:59 AM
> > > To: midcom mail-list
> > > Subject: [midcom] requirements - resource (p.k.a. pin-hole) operations
> > >
> > >
> > > Hi all,
> > >
> > > Section 5.3 mentions 3 operations to be performed on a
> > > resource (pin-hole)
> > > in a middlebox. I believe that we need at least 2 more.
> > > Namely "create" (or
> > > "allocate") and "delete" (or "free").
> > >
> > > The create operation would allocate the resource in the middlebox, but
> > > packets would not be allowed through until an "open"
> > > operation is performed.
> > > An open operation for an unallocated resource could imply a
> > > create & open
> > > operation to minimize the number and size of messages between
> > > the agent and
> > > the middlebox
> > >
> > > The delete operation would be used to free the resource.
> > > Close would only
> > > stop packets from flowing. The resource would not be freed for a close
> > > operation. The resource could subsequently re-opened by the agent.
> > > A delete operation on an open resource would imply close & delete.
> > >
> > > A concrete example of an application that needs this
> > > capability is SIP. When
> > > a session is initiated in SIP with an INVITE, the session
> > > description may
> > > define multiple media streams that the client is willing to
> > > accept. The
> > > response from the server may include only a subset of these
> > > media streams.
> > > The resource in the middlebox needs to be allocated/reserved
> > > before the
> > > INVITE is forwarded to the client. However, we do not want to
> > > enable packet
> > > flow until the response is received from the client.
> > >
> > > cheers,
> > > (-:bob
> > >
> > > Robert F. Penfield
> > > Chief Software Architect
> > > Acme Packet, Inc.
> > > 130 New Boston Street
> > > Woburn, MA 01801
> > > bpenfield@acmepacket.com
> > >
> > >
> > >
> > > _______________________________________________
> > > midcom mailing list
> > > midcom@ietf.org
> > > http://www1.ietf.org/mailman/listinfo/midcom
> > >
> >
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 04:00:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16793
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 04:00:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24997;
	Thu, 9 Aug 2001 03:58:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24920
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 03:58:50 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16738
	for <midcom@ietf.org>; Thu, 9 Aug 2001 03:57:43 -0400 (EDT)
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id AAA29700;
	Thu, 9 Aug 2001 00:58:14 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id AAA18108;
	Thu, 9 Aug 2001 00:58:50 -0700 (PDT)
Received: from xch-pssbh-03.nw.nos.boeing.com (xch-pssbh-03.nw.nos.boeing.com [134.52.3.95])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id f797wn519419;
	Thu, 9 Aug 2001 00:58:49 -0700 (PDT)
Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <QHA5TT7J>; Thu, 9 Aug 2001 00:58:49 -0700
Message-ID: <8006AC6A777F3F4F8B2A6383C19C5B7A05502F06@XCH-NW-01.nw.nos.boeing.com>
From: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>
To: "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'"
	 <midcom@ietf.org>,
        "'Reinaldo Penno'" <reinaldo_penno@nortelnetworks.com>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 00:58:48 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

If a five tuple is not enough information to identify a pinhole, what would be enough?

> ----------
> From: 	Reinaldo Penno[SMTP:reinaldo_penno@nortelnetworks.com]
> Sent: 	Wednesday, August 08, 2001 5:37 PM
> To: 	'Andrew Molitor'; 'midcom@ietf.org'
> Subject: 	RE: [midcom] policy & duration
> 
> Hello Andrew,
>  
> just adding some points on what we disucssed based on my reading of the charter...
>  
> IMO MIDCOM should be a protocol that is general or extensible enough so that I can inform the firewall how to identify, for instance, RTP packets or more generally offsets as you said. 
>  
> It seems some people only want to solve specifically "how to pass SIP through a firewall". This is very evident from the fact that some people think 5 tuple is enough. If we are thinking about getting any type of ALGs from the middlebox, put on a MA and still have the same funcionality, clearly this is not enough.
>  
> The charter of the group is very generic. If what we want to solve is how to pass SIP through a firewall, then we need to change  the charter to something like "SIP Firewall Transversal Group", cause we are clearly not making it general/extensible enough.
>  
> thanks,
>  
> Reinaldo
> 
> 	-----Original Message-----   
> 	From: Penno, Reinaldo [SC9:T327:EXCH] 
> 	Sent: Wednesday, August 08, 2001 5:06 PM
> 	To: 'Andrew Molitor'; 'midcom@ietf.org'  
> 	Subject: RE: [midcom] policy & duration
> 
> 
> 
> 	Hello Andrew, 
> 
> 	>       I think it's important to figure out what those essential 
> 	> interactions are between your SIP code and the routing processes, 
> 	> interface manager, firewall, etc. Presumably the SIP code interacts 
> 	> with many things non-SIP, some of those things are sort of 
> 	> network-ish, 
> 	> and some of THOSE things might naturally fall into a middlebox. 
> 	> 
> 	>       Whatever interactions can be reasonably imagined between 
> 	> say, SIP code and such middleboxy non-SIP things should be well 
> 	> understood before we go much further. The point of MIDCOM is, to 
> 	> first order, to develop a protocol expressive enough to capture 
> 	> those interactions. If we fail to produce something powerful enough 
> 	> for, say, the SIP community, we have failed entirely. 
> 
> 	We are in agreement. 
> 
> 	> 
> 	>       I don't actually know what, apart from 5-tuples and masks 
> 	> for them needs to get carted around in these interactions. That much 
> 	> information seems to work fairly well for pinholes and NAT bindings, 
> 	> at any rate. Well, it's nice to be able to carry around things 
> 	> like expected bandwidth and pinhole lifetime and whatnot, is this 
> 	> the kind of thing you mean? 
> 
> 	I simpler example is interface. 
> 
> 	Or do you want to open a pinhole for 
> 	> RTP traffic, and be able to specify approximately what RTP traffic 
> 	> looks like BEYOND 'UDP traffic from that place to this other place'? 
> 
> 	Yes. 
> 
> 	> Things like size of packet, expected values at expected offsets in 
> 	> the payload? 
> 
> 	Yes. 
> 
> 	thanks, 
> 
> 	Reinaldo 
> 
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 04:02:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16824
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 04:02:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25387;
	Thu, 9 Aug 2001 04:02:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25354
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 04:02:27 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16817
	for <midcom@ietf.org>; Thu, 9 Aug 2001 04:01:20 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7982FE03463
	for <midcom@ietf.org>; Thu, 9 Aug 2001 01:02:15 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-41.cisco.com [10.21.96.41])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIX03450;
	Thu, 9 Aug 2001 01:01:56 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Thu, 9 Aug 2001 09:01:57 +0100
Date: Thu, 9 Aug 2001 09:01:57 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Message-ID: <20010809090157.S1544@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] requirements bullets updated
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I've put a new version of the requirements bullets on
http://www.employees.org/~swb/midcom.html.  This is NOT agreed on by any
aspect of the working group yet.  It was the "sense" of the informal
get-together Monday night, and it's being made available to make
discussion easier.  Since the first version was done so quickly, and we
proposed major moves of a lot of requirements in this version, I haven't
done a diff.  Take a look in preparation for Friday.

See you ... Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 04:33:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17411
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 04:33:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26515;
	Thu, 9 Aug 2001 04:33:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26486
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 04:33:00 -0400 (EDT)
Received: from basto.stsn.com (p5.usslc14.stsn.com [12.23.74.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17378
	for <midcom@ietf.org>; Thu, 9 Aug 2001 04:31:53 -0400 (EDT)
Received: from BobP ([10.112.2.159])
	by basto.stsn.com (8.11.0/8.11.0) with SMTP id f797Tdi31699;
	Thu, 9 Aug 2001 01:29:40 -0600
Message-ID: <005101c120ad$a8158c20$9f02700a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>,
        "'Andrew Molitor'" <amolitor@visi.com>, <midcom@ietf.org>,
        "'Reinaldo Penno'" <reinaldo_penno@nortelnetworks.com>
References: <8006AC6A777F3F4F8B2A6383C19C5B7A05502F06@XCH-NW-01.nw.nos.boeing.com>
Subject: Re: [midcom] policy & duration
Date: Thu, 9 Aug 2001 04:31:08 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>
To: "'Andrew Molitor'" <amolitor@visi.com>; <midcom@ietf.org>; "'Reinaldo
Penno'" <reinaldo_penno@nortelnetworks.com>
Sent: Thursday, August 09, 2001 3:58 AM
Subject: RE: [midcom] policy & duration


> If a five tuple is not enough information to identify a pinhole, what
would be enough?

ingress realm (interface or set of interfaces on which the packets will
arrive)
source address or address mask or address prefix
source port or range of ports
destination address or address mask or address prefix
destination port or range of ports
transport protocol

These would constitute a ruleset-descriptor (or flow-descriptor).

An egress realm (interface or set of interfaces on which the packet should
be sent out) would be part of a ruleset-action (as in "forward packets to
address X in realm Y")

>
> > ----------
> > From: Reinaldo Penno[SMTP:reinaldo_penno@nortelnetworks.com]
> > Sent: Wednesday, August 08, 2001 5:37 PM
> > To: 'Andrew Molitor'; 'midcom@ietf.org'
> > Subject: RE: [midcom] policy & duration
> >
> > Hello Andrew,
> >
> > just adding some points on what we disucssed based on my reading of the
charter...
> >
> > IMO MIDCOM should be a protocol that is general or extensible enough so
that I can inform the firewall how to identify, for instance, RTP packets or
more generally offsets as you said.
> >
> > It seems some people only want to solve specifically "how to pass SIP
through a firewall". This is very evident from the fact that some people
think 5 tuple is enough. If we are thinking about getting any type of ALGs
from the middlebox, put on a MA and still have the same funcionality,
clearly this is not enough.
> >
> > The charter of the group is very generic. If what we want to solve is
how to pass SIP through a firewall, then we need to change  the charter to
something like "SIP Firewall Transversal Group", cause we are clearly not
making it general/extensible enough.
> >
> > thanks,
> >
> > Reinaldo
> >
> > -----Original Message-----
> > From: Penno, Reinaldo [SC9:T327:EXCH]
> > Sent: Wednesday, August 08, 2001 5:06 PM
> > To: 'Andrew Molitor'; 'midcom@ietf.org'
> > Subject: RE: [midcom] policy & duration
> >
> >
> >
> > Hello Andrew,
> >
> > >       I think it's important to figure out what those essential
> > > interactions are between your SIP code and the routing processes,
> > > interface manager, firewall, etc. Presumably the SIP code interacts
> > > with many things non-SIP, some of those things are sort of
> > > network-ish,
> > > and some of THOSE things might naturally fall into a middlebox.
> > >
> > >       Whatever interactions can be reasonably imagined between
> > > say, SIP code and such middleboxy non-SIP things should be well
> > > understood before we go much further. The point of MIDCOM is, to
> > > first order, to develop a protocol expressive enough to capture
> > > those interactions. If we fail to produce something powerful enough
> > > for, say, the SIP community, we have failed entirely.
> >
> > We are in agreement.
> >
> > >
> > >       I don't actually know what, apart from 5-tuples and masks
> > > for them needs to get carted around in these interactions. That much
> > > information seems to work fairly well for pinholes and NAT bindings,
> > > at any rate. Well, it's nice to be able to carry around things
> > > like expected bandwidth and pinhole lifetime and whatnot, is this
> > > the kind of thing you mean?
> >
> > I simpler example is interface.
> >
> > Or do you want to open a pinhole for
> > > RTP traffic, and be able to specify approximately what RTP traffic
> > > looks like BEYOND 'UDP traffic from that place to this other place'?
> >
> > Yes.
> >
> > > Things like size of packet, expected values at expected offsets in
> > > the payload?
> >
> > Yes.
> >
> > thanks,
> >
> > Reinaldo
> >
> >
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 04:39:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17556
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 04:39:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26833;
	Thu, 9 Aug 2001 04:39:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26804
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 04:39:43 -0400 (EDT)
Received: from basto.stsn.com (p5.usslc14.stsn.com [12.23.74.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17534
	for <midcom@ietf.org>; Thu, 9 Aug 2001 04:38:36 -0400 (EDT)
Received: from BobP ([10.112.2.159])
	by basto.stsn.com (8.11.0/8.11.0) with SMTP id f797aki31821;
	Thu, 9 Aug 2001 01:36:46 -0600
Message-ID: <006301c120ae$a60924e0$9f02700a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Andrew Molitor" <amolitor@visi.com>,
        "Sanjoy Sen" <sanjoy@nortelnetworks.com>
Cc: "'Pyda Srisuresh'" <srisuresh@yahoo.com>, <midcom@ietf.org>
References: <Pine.GSO.4.21.0108081420530.19043-100000@isis.visi.com>
Subject: Re: [midcom] Interim rev. of the famework draft
Date: Thu, 9 Aug 2001 04:38:15 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Andrew Molitor wrote:
> I do not think the MIDCOM protocol, when defined, should
> explicitly support the creation of session objects.

I disagree. It does not have to be mandatory, but it would be nice to
associate all the RTP streams of a SIP session together and be able to do
things like extend the timer or delete them with a single handle/identifer.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 05:20:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18431
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 05:20:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28301;
	Thu, 9 Aug 2001 05:21:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28268
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 05:21:03 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18416
	for <midcom@ietf.org>; Thu, 9 Aug 2001 05:19:55 -0400 (EDT)
Received: from cisco.com ([10.49.255.201] (may be forged)) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA22877; Thu, 9 Aug 2001 02:20:30 -0700 (PDT)
Message-ID: <3B7255E1.305AC3@cisco.com>
Date: Thu, 09 Aug 2001 02:20:33 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Molitor <amolitor@visi.com>
CC: midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <Pine.GSO.4.21.0108081833510.19043-100000@isis.visi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Andrew Molitor wrote:

>         We say this, I think. I think we MEAN that we want to remove
> application specific code from the middlebox. I am all for lots of
> intelligence in middleboxes, just nothing specific to SIP or whatever.
> 

A firewall will have what functionality its vendors and users want it to
have. Maybe that will include SIP. Maybe not.  Maybe it will include SMTP
or FTP.  Maybe not.  This is not an either/or proposition.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 05:47:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19251
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 05:47:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29558;
	Thu, 9 Aug 2001 05:46:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29528
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 05:46:40 -0400 (EDT)
Received: from linux.aravox.com (linux.aravox.com [209.46.41.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19212
	for <midcom@ietf.org>; Thu, 9 Aug 2001 05:45:32 -0400 (EDT)
Received: from MPIETRAS (IDENT:root@linux.aravox.com [209.46.41.66] (may be forged))
	by linux.aravox.com (8.9.3/8.9.3) with SMTP id EAA31817;
	Thu, 9 Aug 2001 04:44:03 -0500
From: "Mark Pietras" <mpietras@aravox.com>
To: <lear@cisco.com>, "Andrew Molitor" <amolitor@visi.com>
Cc: <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 04:44:41 -0500
Message-ID: <AHEILOODAGGJDNIMKEGAGELACAAA.mpietras@aravox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3B7255E1.305AC3@cisco.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA29529
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

Eliot Leat wrote:

> Andrew Molitor wrote:
> 
> >         We say this, I think. I think we MEAN that we want to remove
> > application specific code from the middlebox. I am all for lots of
> > intelligence in middleboxes, just nothing specific to SIP or whatever.
> > 
> 
> A firewall will have what functionality its vendors and users want it to
> have. Maybe that will include SIP. Maybe not.  Maybe it will include SMTP
> or FTP.  Maybe not.  This is not an either/or proposition.
> --
> Eliot Lear
> lear@cisco.com

The point is that the functions are LOGICALLY separated in this architecture.  If a middlebox and a MA are implemented on the same PHYSICAL box, so be it.  I suppose it's also possible to have a MA in the same physical middlebox for some functions, and a MA on a different physical box for other functions.

Mark Pietras
mpietras@aravox.com


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 05:57:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19550
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 05:57:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29875;
	Thu, 9 Aug 2001 05:57:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29851
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 05:57:35 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19520
	for <midcom@ietf.org>; Thu, 9 Aug 2001 05:56:27 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f799v5q03107;
	Thu, 9 Aug 2001 02:57:05 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f799v5n10179;
	Thu, 9 Aug 2001 02:57:05 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id CAA05699; Thu, 9 Aug 2001 02:57:03 -0700 (PDT)
Message-ID: <039201c120b9$87a412c0$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <lear@cisco.com>, "Scott Brim" <sbrim@cisco.com>,
        "Mark Duffy" <mduffy@quarrytech.com>
Cc: <midcom@ietf.org>
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
Subject: Re: [midcom] policy & duration
Date: Thu, 9 Aug 2001 05:56:10 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> Mark Duffy:
> Not only that, but the directionality is already an aspect of the existing
> firewall functionality we are providing control over.  I too believe
> directionality should be included.

I think that functionality will be very, very hard to
replicate (i.e. "impossible to do") without introducing
network layer topological and routing information into the
midcom agent.  This is particularly a headache when the
middlebox has more than two interfaces.  Directionality is
implicit in the source and destination addresses in the packet
header and a middlebox with more than one interface already
knows how to route.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 06:08:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19738
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 06:08:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00538;
	Thu, 9 Aug 2001 06:07:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00507
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 06:07:54 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19730
	for <midcom@ietf.org>; Thu, 9 Aug 2001 06:06:46 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f79A71927150
	for <midcom@ietf.org>; Thu, 9 Aug 2001 06:07:01 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Thu, 9 Aug 2001 05:07:32 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZNAXM>; Thu, 9 Aug 2001 03:07:03 -0700
Message-ID: <A7895B732354D311A4770008C791841A01314823@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'Fleischman, Eric W'" <Eric.Fleischman@pss.boeing.com>,
        "'Andrew Molitor'" <amolitor@visi.com>, "'midcom'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 03:07:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C120BB.095827B0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C120BB.095827B0
Content-Type: text/plain;
	charset="windows-1252"



> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, August 09, 2001 3:03 AM
> To: Bob Penfield; Fleischman, Eric W; 'Andrew Molitor'; midcom; Penno,
> Reinaldo [SC9:T327:EXCH]
> Subject: Re: [midcom] policy & duration
> 
> 
> > From: "Bob Penfield" <bpenfield@acmepacket.com>
> >> From: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>
> > To: "'Andrew Molitor'" <amolitor@visi.com>; 
> <midcom@ietf.org>; "'Reinaldo
>  
> > > If a five tuple is not enough information to identify a 
> pinhole, what
> > would be enough?
> > 
> > ingress realm (interface or set of interfaces on which the 
> packets will
> > arrive)
> > source address or address mask or address prefix
> > source port or range of ports
> > destination address or address mask or address prefix
> > destination port or range of ports
> > transport protocol
> 
> I think we need to allow for extremely general filter descriptions,
> which may include well-understood things like protocol and port
> number but which may also include arbitrary length data at arbitrary
> offsets.  Consider the bpf filter machine.

Totally agreed.

> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C120BB.095827B0
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, August 09, 2001 3:03 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Bob Penfield; Fleischman, Eric W; 'Andrew =
Molitor'; midcom; Penno,</FONT>
<BR><FONT SIZE=3D2>&gt; Reinaldo [SC9:T327:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] policy &amp; =
duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: &quot;Bob Penfield&quot; =
&lt;bpenfield@acmepacket.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; From: &quot;Fleischman, Eric W&quot; =
&lt;Eric.Fleischman@pss.boeing.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: &quot;'Andrew Molitor'&quot; =
&lt;amolitor@visi.com&gt;; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;midcom@ietf.org&gt;; &quot;'Reinaldo</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If a five tuple is not enough =
information to identify a </FONT>
<BR><FONT SIZE=3D2>&gt; pinhole, what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; would be enough?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ingress realm (interface or set of =
interfaces on which the </FONT>
<BR><FONT SIZE=3D2>&gt; packets will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; arrive)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; source address or address mask or address =
prefix</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; source port or range of ports</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; destination address or address mask or =
address prefix</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; destination port or range of ports</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transport protocol</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think we need to allow for extremely general =
filter descriptions,</FONT>
<BR><FONT SIZE=3D2>&gt; which may include well-understood things like =
protocol and port</FONT>
<BR><FONT SIZE=3D2>&gt; number but which may also include arbitrary =
length data at arbitrary</FONT>
<BR><FONT SIZE=3D2>&gt; offsets.&nbsp; Consider the bpf filter =
machine.</FONT>
</P>

<P><FONT SIZE=3D2>Totally agreed.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C120BB.095827B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 06:08:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19749
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 06:08:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00419;
	Thu, 9 Aug 2001 06:05:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00387
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 06:05:13 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19681
	for <midcom@ietf.org>; Thu, 9 Aug 2001 06:04:05 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f79A2LZ24223;
	Thu, 9 Aug 2001 03:02:21 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f79A4K021588;
	Thu, 9 Aug 2001 03:04:20 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id DAA07094; Thu, 9 Aug 2001 03:04:06 -0700 (PDT)
Message-ID: <03f601c120ba$84558e90$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>,
        "'Andrew Molitor'" <amolitor@visi.com>, <midcom@ietf.org>,
        "'Reinaldo Penno'" <reinaldo_penno@nortelnetworks.com>
References: <8006AC6A777F3F4F8B2A6383C19C5B7A05502F06@XCH-NW-01.nw.nos.boeing.com> <005101c120ad$a8158c20$9f02700a@acmepacket.com>
Subject: Re: [midcom] policy & duration
Date: Thu, 9 Aug 2001 06:03:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> From: "Bob Penfield" <bpenfield@acmepacket.com>
>> From: "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>
> To: "'Andrew Molitor'" <amolitor@visi.com>; <midcom@ietf.org>; "'Reinaldo
 
> > If a five tuple is not enough information to identify a pinhole, what
> would be enough?
> 
> ingress realm (interface or set of interfaces on which the packets will
> arrive)
> source address or address mask or address prefix
> source port or range of ports
> destination address or address mask or address prefix
> destination port or range of ports
> transport protocol

I think we need to allow for extremely general filter descriptions,
which may include well-understood things like protocol and port
number but which may also include arbitrary length data at arbitrary
offsets.  Consider the bpf filter machine.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 06:18:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19971
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 06:18:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00866;
	Thu, 9 Aug 2001 06:19:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00833
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 06:19:02 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com ([47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19936
	for <midcom@ietf.org>; Thu, 9 Aug 2001 06:17:56 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id FAA22372
	for <midcom@ietf.org>; Thu, 9 Aug 2001 05:18:17 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Thu, 9 Aug 2001 03:10:19 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZNA5Q>; Thu, 9 Aug 2001 03:17:39 -0700
Message-ID: <A7895B732354D311A4770008C791841A01314824@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, "'lear'" <lear@cisco.com>,
        "'Scott Brim'" <sbrim@cisco.com>,
        "'Mark Duffy'" <mduffy@quarrytech.com>
Cc: "'midcom'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 03:17:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C120BC.83FB9CD0"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C120BC.83FB9CD0
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, August 09, 2001 2:56 AM
> To: lear; Scott Brim; Mark Duffy
> Cc: midcom
> Subject: Re: [midcom] policy & duration
> 
> 
> > Mark Duffy:
> > Not only that, but the directionality is already an aspect 
> of the existing
> > firewall functionality we are providing control over.  I too believe
> > directionality should be included.
> 
> I think that functionality will be very, very hard to
> replicate (i.e. "impossible to do") without introducing
> network layer topological and routing information into the
> midcom agent.  This is particularly a headache when the
> middlebox has more than two interfaces.  Directionality is
> implicit in the source and destination addresses in the packet
> header and a middlebox with more than one interface already
> knows how to route.

Hello Melinda,

I am not sure if I follow your argument, but how do you propose to solve,
for instance, a scenario where two customers connected to same middlebox
have overlapping IP address and are going to same destination? Think of
these subscribers as dynamic so that their interface identifier changes.
Anyway, there are several variations for this scenarios if you think of
network based Firewalls, wireless, etc

Now, going back to the point to my discussion with Andrew, we have to assess
what kind of funcionality a MA cannot "mimic". Or if can can, at what cost.
Then we should be very explicit of what subset scenarios midcom propose
solve based on what amount of information of its "surrondings" it should
have (for instance, network layer information as you pointed out). 

regards,

Reinaldo





> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C120BC.83FB9CD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, August 09, 2001 2:56 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: lear; Scott Brim; Mark Duffy</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: midcom</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] policy &amp; =
duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mark Duffy:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Not only that, but the directionality is =
already an aspect </FONT>
<BR><FONT SIZE=3D2>&gt; of the existing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; firewall functionality we are providing =
control over.&nbsp; I too believe</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; directionality should be included.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that functionality will be very, very =
hard to</FONT>
<BR><FONT SIZE=3D2>&gt; replicate (i.e. &quot;impossible to do&quot;) =
without introducing</FONT>
<BR><FONT SIZE=3D2>&gt; network layer topological and routing =
information into the</FONT>
<BR><FONT SIZE=3D2>&gt; midcom agent.&nbsp; This is particularly a =
headache when the</FONT>
<BR><FONT SIZE=3D2>&gt; middlebox has more than two interfaces.&nbsp; =
Directionality is</FONT>
<BR><FONT SIZE=3D2>&gt; implicit in the source and destination =
addresses in the packet</FONT>
<BR><FONT SIZE=3D2>&gt; header and a middlebox with more than one =
interface already</FONT>
<BR><FONT SIZE=3D2>&gt; knows how to route.</FONT>
</P>

<P><FONT SIZE=3D2>Hello Melinda,</FONT>
</P>

<P><FONT SIZE=3D2>I am not sure if I follow your argument, but how do =
you propose to solve, for instance, a scenario where two customers =
connected to same middlebox have overlapping IP address and are going =
to same destination? Think of these subscribers as dynamic so that =
their interface identifier changes. Anyway, there are several =
variations for this scenarios if you think of network based Firewalls, =
wireless, etc</FONT></P>

<P><FONT SIZE=3D2>Now, going back to the point to my discussion with =
Andrew, we have to assess what kind of funcionality a MA cannot =
&quot;mimic&quot;. Or if can can, at what cost. Then we should be very =
explicit of what subset scenarios midcom propose solve based on what =
amount of information of its &quot;surrondings&quot; it should have =
(for instance, network layer information as you pointed out). =
</FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C120BC.83FB9CD0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:16:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22792
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:16:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05771;
	Thu, 9 Aug 2001 09:14:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05740
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:14:38 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22760
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:13:32 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f79DEcr19413
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:14:39 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA16793; Thu, 9 Aug 2001 15:14:38 +0200 (MET DST)
Cc: lear@cisco.com, Scott Brim <sbrim@cisco.com>,
        Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA16768; Thu, 9 Aug 2001 15:14:34 +0200 (MET DST)
Message-ID: <3B728C98.2AA6A9AF@lucent.com>
Date: Thu, 09 Aug 2001 15:14:00 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
Original-CC: lear@cisco.com, Scott Brim <sbrim@cisco.com>,
        Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <3.0.5.32.20010808102142.007df320@email.quarrytech.com> <039201c120b9$87a412c0$7c8921d9@NAUGA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Melinda,

you write:
> I think that functionality will be very, very hard to
> replicate (i.e. "impossible to do") without introducing
> network layer topological and routing information into the
> midcom agent. 

I am not trying to be cheeky (as they might say here) but that is
*exactly* the can of worms that we opened by starting to work on this. 
I am truly sorfry if you did not realise this before.

If a midcom agent takes charge of a packet flow through a *certain*
middlebox it *must* know the topology of the network (or at least a
sufficiently complete view on it).
  
I know we are getting into a mess but it seems to be the only way to solve
the issues we want to solve.

Paul


Melinda Shore wrote:

> I think that functionality will be very, very hard to
> replicate (i.e. "impossible to do") without introducing
> network layer topological and routing information into the
> midcom agent.  This is particularly a headache when the
> middlebox has more than two interfaces.  Directionality is
> implicit in the source and destination addresses in the packet
> header and a middlebox with more than one interface already
> knows how to route.
> 
> Melinda
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:24:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23014
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:24:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06005;
	Thu, 9 Aug 2001 09:24:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05976
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:24:40 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22976
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:23:34 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f79DOEq16123;
	Thu, 9 Aug 2001 06:24:15 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f79DOA923731;
	Thu, 9 Aug 2001 06:24:10 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id GAA26047; Thu, 9 Aug 2001 06:24:09 -0700 (PDT)
Message-ID: <011b01c120d6$758b05e0$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Paul Sijben" <sijben@lucent.com>
Cc: <midcom@ietf.org>
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <3.0.5.32.20010808102142.007df320@email.quarrytech.com> <039201c120b9$87a412c0$7c8921d9@NAUGA> <3B728C98.2AA6A9AF@lucent.com>
Subject: Re: [midcom] policy & duration
Date: Thu, 9 Aug 2001 09:23:19 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> From: "Paul Sijben" <sijben@lucent.com>

> If a midcom agent takes charge of a packet flow through a *certain*
> middlebox it *must* know the topology of the network (or at least a
> sufficiently complete view on it).

People keep saying "must" in regard to directionality
and exporting topology to the application (beyond 
the location of the middlebox), but they haven't made
a particularly strong case.  What would be helpful would
be a realistic example of a problem that can be solved
no other way along with an indication that the people
advocating this fully understand the implications of
interfacing with the routing system.  The advocacy
of this has been adamant in tone and casual in content,
and given how profoundly this proposal violates basic
IP network architecture principles I believe that it 
needs a bit more respect.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:45:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23458
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:44:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06780;
	Thu, 9 Aug 2001 09:44:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06699
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:44:23 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23424
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:43:16 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f79Dh6922881
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:43:08 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Thu, 9 Aug 2001 08:43:39 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZNDFS>; Thu, 9 Aug 2001 06:43:10 -0700
Message-ID: <A7895B732354D311A4770008C791841A01314829@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, "'Paul Sijben'" <sijben@lucent.com>
Cc: "'midcom'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 06:43:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C120D9.39AA03C0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C120D9.39AA03C0
Content-Type: text/plain;
	charset="iso-8859-1"

Melinda,

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, August 09, 2001 6:23 AM
> To: Paul Sijben
> Cc: midcom
> Subject: Re: [midcom] policy & duration
> 
> 
> > From: "Paul Sijben" <sijben@lucent.com>
> 
> > If a midcom agent takes charge of a packet flow through a *certain*
> > middlebox it *must* know the topology of the network (or at least a
> > sufficiently complete view on it).
> 
> People keep saying "must" in regard to directionality
> and exporting topology to the application (beyond 
> the location of the middlebox), but they haven't made
> a particularly strong case.  What would be helpful would
> be a realistic example of a problem that can be solved
> no other way along with an indication that the people
> advocating this fully understand the implications of
> interfacing with the routing system.  The advocacy
> of this has been adamant in tone and casual in content

Is enough to mention any type of assymetric routing?

> and given how profoundly this proposal violates basic
> IP network architecture principles 

can you elaborate on that? "Violates the basic...". When a device knows
topological information it violates the basic principle? 


thanks,

Reinaldo

I believe that it 
> needs a bit more respect.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C120D9.39AA03C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Melinda,</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, August 09, 2001 6:23 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Paul Sijben</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: midcom</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] policy &amp; =
duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: &quot;Paul Sijben&quot; =
&lt;sijben@lucent.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If a midcom agent takes charge of a packet =
flow through a *certain*</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; middlebox it *must* know the topology of =
the network (or at least a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sufficiently complete view on it).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; People keep saying &quot;must&quot; in regard =
to directionality</FONT>
<BR><FONT SIZE=3D2>&gt; and exporting topology to the application =
(beyond </FONT>
<BR><FONT SIZE=3D2>&gt; the location of the middlebox), but they =
haven't made</FONT>
<BR><FONT SIZE=3D2>&gt; a particularly strong case.&nbsp; What would be =
helpful would</FONT>
<BR><FONT SIZE=3D2>&gt; be a realistic example of a problem that can be =
solved</FONT>
<BR><FONT SIZE=3D2>&gt; no other way along with an indication that the =
people</FONT>
<BR><FONT SIZE=3D2>&gt; advocating this fully understand the =
implications of</FONT>
<BR><FONT SIZE=3D2>&gt; interfacing with the routing system.&nbsp; The =
advocacy</FONT>
<BR><FONT SIZE=3D2>&gt; of this has been adamant in tone and casual in =
content</FONT>
</P>

<P><FONT SIZE=3D2>Is enough to mention any type of assymetric =
routing?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; and given how profoundly this proposal violates =
basic</FONT>
<BR><FONT SIZE=3D2>&gt; IP network architecture principles </FONT>
</P>

<P><FONT SIZE=3D2>can you elaborate on that? &quot;Violates the =
basic...&quot;. When a device knows topological information it violates =
the basic principle? </FONT></P>
<BR>

<P><FONT SIZE=3D2>thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>

<P><FONT SIZE=3D2>I believe that it </FONT>
<BR><FONT SIZE=3D2>&gt; needs a bit more respect.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C120D9.39AA03C0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:45:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23479
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:45:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06828;
	Thu, 9 Aug 2001 09:45:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06803
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:45:25 -0400 (EDT)
Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23439
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:44:18 -0400 (EDT)
Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21])
	by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f79CxiW24443;
	Thu, 9 Aug 2001 05:59:48 -0700
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <P05WQHX6>; Thu, 9 Aug 2001 06:44:32 -0700
Message-ID: <B162270C965FD511AB9600B0D0B0AB420EAE38@NAPA>
From: John LaCour <jlacour@netscreen.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        midcom mail-list
	 <midcom@ietf.org>
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!
Date: Thu, 9 Aug 2001 06:46:46 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I don't like using session mostly for pragmatic reasons.  Its
too easily confused to mean many different things.

I like "flow" to describe a stream of traffic in one direction
between end-points.

"Bundle" adequately describes an aggregation of flows.

I think we need to clear on the difference between 
middlebox services/functions/capabilities and the
instance of that capability having been implemented
with specific parameters, presumably as requested by a MIDCOM
agent.  I like using "capability" to describe the things
(services, functions).

Another separate thing to describe is the request that a
capability be implemented along with the appropriate
parameters, which will change depending on the specific
capability.  I think this is what was called a "ruleset"
which I don't like because I find it tends to get confused
with policies.

-John

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Tuesday, August 07, 2001 5:40 AM
> To: midcom mail-list
> Subject: [midcom] pin-holes, sessions and flows, oh my!
> 
> 
> Hi all,
> 
> During some informal discussions between several individuals 
> interested in
> midcom who happened to be in the bar (although no one had any 
> feathers), it
> was noticed that there are variety of inconsistent terms used in the
> framework and requirements to describe the thing in the 
> middlebox that we
> wish to manage with a midcom protocol.
> 
> Our illustrious leader has asked me to take a crack at 
> defining one set of
> terms for these things.
> 
> There are two things we need to represent: 1) an individual 
> NAT/pin-hole to
> enable a stream of packets to traverse the middlebox; and 2) 
> an aggregation
> or grouping of NATs/pin-holes that represent a session from the
> application's point of view.
> 
> Currently, the framework calls an individual thing a 
> session-descriptor, and
> the requirements call it a pin-hole. It was felt by a number of those
> present that pin-hole implied a firewall function to the exclusion NAT
> (Although we realize that is not what was intended). It was 
> also felt by
> some people that "session" was overloaded in that it has been used to
> describe an individual pin-hole/NAT, a group of pin-holes/NATs and the
> communication/connection between a midcom agent and a middlebox.
> 
> I personally liked the term "flow" for an individual thing, 
> and the term
> "session" for a group of things. However, a many of those 
> present felt that
> the term "resource" was best to describe an individual pin hole/NAT. A
> "bundle" was suggested for a group of related "resources".
> 
> So here goes.
> 
> Resource:
> A resource is a single instance of a middlebox service for a 
> specific flow
> or stream of packets (e.g. a NAT session or a firewall 
> pin-hole). It defines
> the information necessary to identify incoming packets that 
> are associated
> with the resource and the actions required to dispose of the packets
> (forward them on or drop them). Note that a service may 
> consist of multiple
> functions. For example, a single resource could include both 
> the NAT and
> firewall functions.
> 
> Resource Bundle:
> A resource bundle is a group of resources that have been 
> associated together
> by the application via the midcom agent, which uses the 
> midcom protocol to
> establish the grouping in the middlebox.
> 
> How's that?
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
> 
> 
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:47:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23513
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:47:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06898;
	Thu, 9 Aug 2001 09:46:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06865
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:46:08 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23473
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:45:02 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f79Dk9r09034
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:46:09 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA00139; Thu, 9 Aug 2001 15:46:08 +0200 (MET DST)
Cc: midcom@ietf.org
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA00110; Thu, 9 Aug 2001 15:46:05 +0200 (MET DST)
Message-ID: <3B7293CB.F31EBA13@lucent.com>
Date: Thu, 09 Aug 2001 15:44:43 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
Original-CC: midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <3.0.5.32.20010808102142.007df320@email.quarrytech.com> <039201c120b9$87a412c0$7c8921d9@NAUGA> <3B728C98.2AA6A9AF@lucent.com> <011b01c120d6$758b05e0$7c8921d9@NAUGA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Melinda,

the issue is clearer when you also address the point that is outside the
scope of MIDCOM, namely discovery of middleboxes. 

If you do not address that problem you have *no* idea where the flows are
going to end up and you can only push a generic policy to *all*
middleboxes in your network rather than send clear commands to *one* box.
Obviously, this does not scale. 

So assuming sufficuently large networks that make midcom deployment
interesting (rather than stuffing all application intelligence in the
firewall), you need to know where the flow is going to hit a middlebox and
(assuming middleboxes with more than 2 interfaces) you need to know where
the flow needs to go to.

This makes the midcom agent party to the network topology information as
far as it needs to know. 

Now, I am OK that we leave the aspect of getting that kind of information
to the agent out of the discussion but we can hardly ignore the larger
architectural impact.  

Paul

Melinda Shore wrote:
> 
> > From: "Paul Sijben" <sijben@lucent.com>
> 
> > If a midcom agent takes charge of a packet flow through a *certain*
> > middlebox it *must* know the topology of the network (or at least a
> > sufficiently complete view on it).
> 
> People keep saying "must" in regard to directionality
> and exporting topology to the application (beyond
> the location of the middlebox), but they haven't made
> a particularly strong case.  What would be helpful would
> be a realistic example of a problem that can be solved
> no other way along with an indication that the people
> advocating this fully understand the implications of
> interfacing with the routing system.  The advocacy
> of this has been adamant in tone and casual in content,
> and given how profoundly this proposal violates basic
> IP network architecture principles I believe that it
> needs a bit more respect.
> 
> Melinda

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:50:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23627
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:50:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07022;
	Thu, 9 Aug 2001 09:50:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06995
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:50:37 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23581
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:49:30 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f79Dng925087
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:49:42 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Thu, 9 Aug 2001 08:49:49 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMHZNDK1>; Thu, 9 Aug 2001 06:49:20 -0700
Message-ID: <A7895B732354D311A4770008C791841A0131482A@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Paul Sijben'" <sijben@lucent.com>, "'Melinda Shore'" <mshore@cisco.com>
Cc: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 06:49:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C120DA.16B90C70"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C120DA.16B90C70
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

> -----Original Message-----
> From: Paul Sijben [mailto:sijben@lucent.com]
> Sent: Thursday, August 09, 2001 6:45 AM
> To: Melinda Shore
> Cc: midcom@ietf.org
> Subject: Re: [midcom] policy & duration
> 
> 
> Melinda,
> 
> the issue is clearer when you also address the point that is 
> outside the
> scope of MIDCOM, namely discovery of middleboxes. 
> 
> If you do not address that problem you have *no* idea where 
> the flows are
> going to end up and you can only push a generic policy to *all*
> middleboxes in your network rather than send clear commands 
> to *one* box.
> Obviously, this does not scale. 
> 
> So assuming sufficuently large networks that make midcom deployment
> interesting (rather than stuffing all application intelligence in the
> firewall), you need to know where the flow is going to hit a 
> middlebox and
> (assuming middleboxes with more than 2 interfaces) you need 
> to know where
> the flow needs to go to go.

Yes, good point. Cedric wrote a draft about this. 

> 
> This makes the midcom agent party to the network topology 
> information as
> far as it needs to know. 
> 
> Now, I am OK that we leave the aspect of getting that kind of 
> information
> to the agent out of the discussion but we can hardly ignore the larger
> architectural impact.  
> 
> Paul
> 

------_=_NextPart_001_01C120DA.16B90C70
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello,</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Paul Sijben [<A HREF="mailto:sijben@lucent.com">mailto:sijben@lucent.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, August 09, 2001 6:45 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Melinda Shore</FONT>
<BR><FONT SIZE=2>&gt; Cc: midcom@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [midcom] policy &amp; duration</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Melinda,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; the issue is clearer when you also address the point that is </FONT>
<BR><FONT SIZE=2>&gt; outside the</FONT>
<BR><FONT SIZE=2>&gt; scope of MIDCOM, namely discovery of middleboxes. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If you do not address that problem you have *no* idea where </FONT>
<BR><FONT SIZE=2>&gt; the flows are</FONT>
<BR><FONT SIZE=2>&gt; going to end up and you can only push a generic policy to *all*</FONT>
<BR><FONT SIZE=2>&gt; middleboxes in your network rather than send clear commands </FONT>
<BR><FONT SIZE=2>&gt; to *one* box.</FONT>
<BR><FONT SIZE=2>&gt; Obviously, this does not scale. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So assuming sufficuently large networks that make midcom deployment</FONT>
<BR><FONT SIZE=2>&gt; interesting (rather than stuffing all application intelligence in the</FONT>
<BR><FONT SIZE=2>&gt; firewall), you need to know where the flow is going to hit a </FONT>
<BR><FONT SIZE=2>&gt; middlebox and</FONT>
<BR><FONT SIZE=2>&gt; (assuming middleboxes with more than 2 interfaces) you need </FONT>
<BR><FONT SIZE=2>&gt; to know where</FONT>
<BR><FONT SIZE=2>&gt; the flow needs to go to go.</FONT>
</P>

<P><FONT SIZE=2>Yes, good point. Cedric wrote a draft about this. </FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This makes the midcom agent party to the network topology </FONT>
<BR><FONT SIZE=2>&gt; information as</FONT>
<BR><FONT SIZE=2>&gt; far as it needs to know. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now, I am OK that we leave the aspect of getting that kind of </FONT>
<BR><FONT SIZE=2>&gt; information</FONT>
<BR><FONT SIZE=2>&gt; to the agent out of the discussion but we can hardly ignore the larger</FONT>
<BR><FONT SIZE=2>&gt; architectural impact.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Paul</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C120DA.16B90C70--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:55:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23776
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:55:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07170;
	Thu, 9 Aug 2001 09:55:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07141
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:55:29 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23755
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:54:22 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f79Dt4J03666;
	Thu, 9 Aug 2001 06:55:04 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f79DsrZ10630;
	Thu, 9 Aug 2001 06:54:53 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id GAA00813; Thu, 9 Aug 2001 06:54:52 -0700 (PDT)
Message-ID: <017201c120da$c0149be0$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
Cc: "'midcom'" <midcom@ietf.org>
References: <A7895B732354D311A4770008C791841A01314829@zsc4c014.us.nortel.com>
Subject: Re: [midcom] policy & duration
Date: Thu, 9 Aug 2001 09:54:02 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> Is enough to mention any type of assymetric routing?

No - I'm not disputing that there are routing decisions
to be made.  I'm trying to understand the benefit of pulling
the midcom agent into the routing system, along with all that
it implies.

> can you elaborate on that? "Violates the basic...". When a device knows
> topological information it violates the basic principle? 

No, but when an application knows the location of network-layer
devices and makes routing decisions based on that knowledge,
you by definition lose all benefits of the fundamental design
principles underlying IP.  You lose robustness in the face of
routing changes, you lose scalability, fate-sharing is undone,
and so on.  You need to be thinking about what happens when routes
change, how routing tables would be exported to midcom agents, and
so on. 

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 09:56:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23811
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 09:56:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07236;
	Thu, 9 Aug 2001 09:56:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07201
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 09:56:22 -0400 (EDT)
Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23768
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:55:15 -0400 (EDT)
Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21])
	by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f79DAZW24679;
	Thu, 9 Aug 2001 06:10:35 -0700
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <P05WQHZL>; Thu, 9 Aug 2001 06:55:23 -0700
Message-ID: <B162270C965FD511AB9600B0D0B0AB420EAE39@NAPA>
From: John LaCour <jlacour@netscreen.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        Sanjoy Sen
	 <sanjoy@nortelnetworks.com>,
        midcom mail-list <midcom@ietf.org>
Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations
Date: Thu, 9 Aug 2001 06:57:38 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org




> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
>
>> From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
> 
> > Bob,
> > Why can't we wait till the offer/answer exchange (both for 
> regular & Early
> > media) is completed, before "opening" pinholes? What is the 
> purpose of the
> > interim "Create" phase?
> 
> I suppose we could do that. However, one might want to make 
> sure there are
> enough resources in the middlebox to handle the flow before 
> sending the
> INVITE on the called party.


Which resources are those?  The only resource you could really
check is if you can add an additional policy/ACL/pin-hole-rule
unless you were to make an assumption about other resource
requirements that pin-holes requested via MIDCOM require
(ie. bandwidth, midbox CPU, etc.) in your implementation.

I'd much rather make the protocol allow these resource requirements
to be specified explicitly in the 'open' request though.

-John

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:06:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24229
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:06:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07886;
	Thu, 9 Aug 2001 10:06:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07853
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:06:30 -0400 (EDT)
Received: from linux.aravox.com (linux.aravox.com [209.46.41.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24156
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:05:23 -0400 (EDT)
Received: from MPIETRAS (IDENT:root@linux.aravox.com [209.46.41.66] (may be forged))
	by linux.aravox.com (8.9.3/8.9.3) with SMTP id JAA23972
	for <midcom@ietf.org>; Thu, 9 Aug 2001 09:04:33 -0500
From: "Mark Pietras" <mpietras@aravox.com>
To: <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 09:05:11 -0500
Message-ID: <AHEILOODAGGJDNIMKEGAMELECAAA.mpietras@aravox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3B7293CB.F31EBA13@lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07854
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

Can someone clarify for me what we're talking about here:

To me, there are two types of multiple-interfaces:

1) I'll call it the ABC-type, where packets arriving on interface A may exit on interface B or interface C (and all the other combinations or a subset thereof)

2) I'll call it the NxAB-type, where packets arriving on the interface A of a pair exit on the corresponding interface B of the pair (and visa-versa).

ABC is a much harder problem to solve than NxAB.  Which multiple-interface type are we discussing?

Mark.

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Paul Sijben
Sent: Thursday, August 09, 2001 8:45 AM
To: Melinda Shore
Cc: midcom@ietf.org
Subject: Re: [midcom] policy & duration


Melinda,

the issue is clearer when you also address the point that is outside the
scope of MIDCOM, namely discovery of middleboxes. 

If you do not address that problem you have *no* idea where the flows are
going to end up and you can only push a generic policy to *all*
middleboxes in your network rather than send clear commands to *one* box.
Obviously, this does not scale. 

So assuming sufficuently large networks that make midcom deployment
interesting (rather than stuffing all application intelligence in the
firewall), you need to know where the flow is going to hit a middlebox and
(assuming middleboxes with more than 2 interfaces) you need to know where
the flow needs to go to.

This makes the midcom agent party to the network topology information as
far as it needs to know. 

Now, I am OK that we leave the aspect of getting that kind of information
to the agent out of the discussion but we can hardly ignore the larger
architectural impact.  

Paul

Melinda Shore wrote:
> 
> > From: "Paul Sijben" <sijben@lucent.com>
> 
> > If a midcom agent takes charge of a packet flow through a *certain*
> > middlebox it *must* know the topology of the network (or at least a
> > sufficiently complete view on it).
> 
> People keep saying "must" in regard to directionality
> and exporting topology to the application (beyond
> the location of the middlebox), but they haven't made
> a particularly strong case.  What would be helpful would
> be a realistic example of a problem that can be solved
> no other way along with an indication that the people
> advocating this fully understand the implications of
> interfacing with the routing system.  The advocacy
> of this has been adamant in tone and casual in content,
> and given how profoundly this proposal violates basic
> IP network architecture principles I believe that it
> needs a bit more respect.
> 
> Melinda

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:10:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24359
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:10:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07958;
	Thu, 9 Aug 2001 10:08:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07930
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:08:23 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24250
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:07:17 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f79E8OL15202
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:08:24 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA08586; Thu, 9 Aug 2001 16:08:23 +0200 (MET DST)
Cc: Reinaldo Penno <reinaldo_penno@nortelnetworks.com>,
        "'midcom'" <midcom@ietf.org>
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA08563; Thu, 9 Aug 2001 16:08:18 +0200 (MET DST)
Message-ID: <3B729905.D7D61281@lucent.com>
Date: Thu, 09 Aug 2001 16:07:01 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
Original-CC: Reinaldo Penno <reinaldo_penno@nortelnetworks.com>,
        "'midcom'" <midcom@ietf.org>
Subject: Re: [midcom] policy & duration
References: <A7895B732354D311A4770008C791841A01314829@zsc4c014.us.nortel.com> <017201c120da$c0149be0$7c8921d9@NAUGA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Melinda,

you wrote:
> You need to be thinking about what happens when routes
> change, how routing tables would be exported to midcom agents, and
> so on.

OK, this line of argument is exactly why QoS should be in scope for
MIDCOM. Because if you want QoS, you are in major trouble anyway when the
route changes. You must know this at application level because of the cost
(real $$) of transporting a QoS flow.

In the cases where that is not necessary to know you do not need to see
this in the view of the network tolopogy you (as a MA) are given.

Paul

Melinda Shore wrote:
> 
> > Is enough to mention any type of assymetric routing?
> 
> No - I'm not disputing that there are routing decisions
> to be made.  I'm trying to understand the benefit of pulling
> the midcom agent into the routing system, along with all that
> it implies.
> 
> > can you elaborate on that? "Violates the basic...". When a device knows
> > topological information it violates the basic principle?
> 
> No, but when an application knows the location of network-layer
> devices and makes routing decisions based on that knowledge,
> you by definition lose all benefits of the fundamental design
> principles underlying IP.  You lose robustness in the face of
> routing changes, you lose scalability, fate-sharing is undone,
> and so on.  You need to be thinking about what happens when routes
> change, how routing tables would be exported to midcom agents, and
> so on.
> 
> Melinda
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:11:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24403
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:11:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08089;
	Thu, 9 Aug 2001 10:11:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08054
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:11:19 -0400 (EDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24332
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:10:11 -0400 (EDT)
Received: from [217.33.147.176] (helo=mduffy)
	by relay3.bt.net with smtp (Exim 3.22 #1)
	id 15UqWG-00045H-02; Thu, 09 Aug 2001 15:10:40 +0100
Message-Id: <3.0.5.32.20010809092043.0085fc20@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 09 Aug 2001 09:20:43 -0400
To: "Bob Penfield" <bpenfield@acmepacket.com>, <lear@cisco.com>,
        "Scott Brim" <sbrim@cisco.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
Cc: <midcom@ietf.org>
In-Reply-To: <008e01c12062$ad7b3020$9f02700a@acmepacket.com>
References: <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
 <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 07:34 PM 8/8/01 -0400, Bob Penfield wrote:
...
>> At 05:35 AM 8/8/01 -0700, Eliot Lear wrote:
>> >Scott Brim wrote:
>> ...
>> >> There's a hint of directionality in here, which we're still debating.
>> >
>> >First, very basic packet firewalls understand packets and not connections
>> >or conversations.  I don't know that we want to require much more than
>> >that.
>> >
>> >Also, I think we remove directionality at our peril.  In an
>> >internal/external communication, the reversing of directional rules on
>> >interfaces would lead to a weakening of enterprise security.
>>
>> Not only that, but the directionality is already an aspect of the existing
>> firewall functionality we are providing control over.  I too believe
>> directionality should be included.
>>
>I just want to chime in a say expression of direction without a notion of
>which side is in or out is not of much use. I think is would be more useful
>to define the ingress and egress realms. As I have said before, I believe
>assuming all middleboxes will be connected to exactly two realms would be
>unwise.

Yes, direction alone is not useful.
At a minimum, <interface> is needed along with it.  <Realm> would be even
better (although I don't know that we have a way to name realms).



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:11:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24415
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:11:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08047;
	Thu, 9 Aug 2001 10:11:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08014
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:11:14 -0400 (EDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24314
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:10:07 -0400 (EDT)
Received: from [217.33.147.176] (helo=mduffy)
	by relay3.bt.net with smtp (Exim 3.22 #1)
	id 15UqWG-00045H-01; Thu, 09 Aug 2001 15:10:40 +0100
Message-Id: <3.0.5.32.20010809090218.0085fc20@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 09 Aug 2001 09:02:18 -0400
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "midcom mail-list" <midcom@ietf.org>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
In-Reply-To: <007e01c12061$1d6bb8c0$9f02700a@acmepacket.com>
References: <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 07:23 PM 8/8/01 -0400, Bob Penfield wrote:
...
>> Relative to Bob's 7 Aug msg re "resource (p.k.a. pin-hole) operations"
>> which proposes additional operations such as create and delete, I would
>> suggest there should be operations to add/delete ruleset-descriptors and
>> ruleset-actions to rulesets.
>
>I'm afraid I don't know what value a descriptor is without actions (at least
>action=drop) and even less what an action without a descriptor for it.
>Besides I think this is getting too deeply into the middlebox.

Bob, I agree with you on the above point.  The original point I intended to
make was that the MA should be able to manipulate the descriptor and
actions independently, to whatever extent that make sense.  I think your 2
lines below capture that fine.

>I would say we also need a "modify" operation to change the actions for a
>ruleset. This might involve adding or removing actions from a ruleset.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:11:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24432
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:11:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08180;
	Thu, 9 Aug 2001 10:11:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08149
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:11:44 -0400 (EDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24369
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:10:37 -0400 (EDT)
Received: from [217.33.147.176] (helo=mduffy)
	by relay3.bt.net with smtp (Exim 3.22 #1)
	id 15UqWH-00045H-00; Thu, 09 Aug 2001 15:10:41 +0100
Message-Id: <3.0.5.32.20010809095744.0085fc20@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 09 Aug 2001 09:57:44 -0400
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "Fleischman, Eric W" <Eric.Fleischman@pss.boeing.com>,
        "'Andrew Molitor'" <amolitor@visi.com>, <midcom@ietf.org>,
        "'Reinaldo Penno'" <reinaldo_penno@nortelnetworks.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
In-Reply-To: <005101c120ad$a8158c20$9f02700a@acmepacket.com>
References: <8006AC6A777F3F4F8B2A6383C19C5B7A05502F06@XCH-NW-01.nw.nos.boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 04:31 AM 8/9/01 -0400, Bob Penfield wrote:
...
>> If a five tuple is not enough information to identify a pinhole, what
>would be enough?
>
>ingress realm (interface or set of interfaces on which the packets will
>arrive)
>source address or address mask or address prefix
>source port or range of ports
>destination address or address mask or address prefix
>destination port or range of ports
>transport protocol
>
>These would constitute a ruleset-descriptor (or flow-descriptor).
>
>An egress realm (interface or set of interfaces on which the packet should
>be sent out) would be part of a ruleset-action (as in "forward packets to
>address X in realm Y")


I *strongly* disagree with the ingres/egress realm parts of that.  Where to
forward the packet should be left (at least sometimes, in some MB's) up to
an IP forwarding (BMP) decision.

Rather, I believe the n-tuple should specify realm (or interface) and
direction (relative to the realm or interface).  Here is why:  In a
generalized case MB with multiple interfaces connecting to multiple realms,
packets may flow from one private realm to another, or from a private realm
to/from the Internet realm, etc.  The MB in such cases should independently
apply MB policy of the realm from which a packet came, followed by MB
policy for the realm to which the packet is going. 

The 2 policies can be independently represented by separate n-tuples: one with
 realm = RealmA, direction = incoming,   and the other with
 realm = RealmB, direction = outgoing
The first would apply the associated actions to matching packets arriving
at the MB from RealmA, and the second would apply the associated actions to
packets flowing to RealmB.

--Mark


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:11:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24439
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:11:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08132;
	Thu, 9 Aug 2001 10:11:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08099
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:11:28 -0400 (EDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24348
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:10:21 -0400 (EDT)
Received: from [217.33.147.176] (helo=mduffy)
	by relay3.bt.net with smtp (Exim 3.22 #1)
	id 15UqWG-00045H-00; Thu, 09 Aug 2001 15:10:40 +0100
Message-Id: <3.0.5.32.20010809084620.0085dd80@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 09 Aug 2001 08:46:20 -0400
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'Melinda Shore'" <mshore@cisco.com>, "'lear'" <lear@cisco.com>,
        "'Scott Brim'" <sbrim@cisco.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: RE: [midcom] policy & duration
Cc: "'midcom'" <midcom@ietf.org>
In-Reply-To: <A7895B732354D311A4770008C791841A01314824@zsc4c014.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I second what Reinaldo wrote.  Specifying interface/realm/direction/etc
may not be as important with simple 2-interface middleboxes, but for
larger/ more complex MBs such as those with many interfaces and
implementing different policies on them, it is key.  


Consider a network based mb that is providing NAT to multiple unrelated
domains, each using network 10.  The direction is not implicit in the
addresses (not unambiguously anyway). 


-Mark


At 03:17 AM 8/9/01 -0700, Reinaldo Penno wrote: 

>>>>

<excerpt>



> -----Original Message----- 

> From: Melinda Shore [<<mailto:mshore@cisco.com>mailto:mshore@cisco.com] 

> Sent: Thursday, August 09, 2001 2:56 AM 

> To: lear; Scott Brim; Mark Duffy 

> Cc: midcom 

> Subject: Re: [midcom] policy & duration 

>  

>  

> > Mark Duffy: 

> > Not only that, but the directionality is already an aspect  

> of the existing 

> > firewall functionality we are providing control over.  I too believe 

> > directionality should be included. 

>  

> I think that functionality will be very, very hard to 

> replicate (i.e. "impossible to do") without introducing 

> network layer topological and routing information into the 

> midcom agent.  This is particularly a headache when the 

> middlebox has more than two interfaces.  Directionality is 

> implicit in the source and destination addresses in the packet 

> header and a middlebox with more than one interface already 

> knows how to route. 


Hello Melinda, 


I am not sure if I follow your argument, but how do you propose to solve,
for instance, a scenario where two customers connected to same middlebox
have overlapping IP address and are going to same destination? Think of
these subscribers as dynamic so that their interface identifier changes.
Anyway, there are several variations for this scenarios if you think of
network based Firewalls, wireless, etc


Now, going back to the point to my discussion with Andrew, we have to
assess what kind of funcionality a MA cannot "mimic". Or if can can, at
what cost. Then we should be very explicit of what subset scenarios
midcom propose solve based on what amount of information of its
"surrondings" it should have (for instance, network layer information as
you pointed out). 


regards, 


Reinaldo 






>  

> Melinda 

>  

>  

>  

> _______________________________________________ 

> midcom mailing list 

> midcom@ietf.org 

>
<<http://www1.ietf.org/mailman/listinfo/midcom>http://www1.ietf.org/mailman/listinfo/midcom 

>  


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




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:17:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24631
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:17:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08400;
	Thu, 9 Aug 2001 10:16:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08329
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:16:48 -0400 (EDT)
Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24578
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:15:41 -0400 (EDT)
Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21])
	by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f79DV4W25106;
	Thu, 9 Aug 2001 06:31:04 -0700
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <P05WQH7B>; Thu, 9 Aug 2001 07:15:52 -0700
Message-ID: <B162270C965FD511AB9600B0D0B0AB420EAE3B@NAPA>
From: John LaCour <jlacour@netscreen.com>
To: "'lear@cisco.com'" <lear@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 07:18:08 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

There are many types of policy decisions a middlebox will
have to make.  I suspect in many implementations many of
them will be implicitly allowed.

For example:
- Which Agents are allowed to talk to me?
- What types of requests can they make?
- Is a specific request allowed?
- How does a middlebox resolve conflicting requests
  from 2 or more agents?
- How does a middlebox resolve conflicting requests
  from Agents and other sources (ie. administratively
  set static policies - eg. CLI)

Its not clear to me what the scope is of our discussion
on policy and policy servers in the drafts.  Changes
should make clear what the scope is of the discussion
and also why we even care.

My preference is to keep the scope limited to authorizing
Agents and authorizing Agents to ask for certain types
of requests and leave.  I don't think any thing else
remotely has any bearing on the protocol.

-John

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Tuesday, August 07, 2001 8:43 AM
> To: midcom@ietf.org
> Subject: [midcom] policy & duration
> 
> 
> 
> In our bar-fob we had a number of issues with policy.  i have 
> promised to
> provide some words to help improve the situation.  I hope this does. 
> Please note that there is a trivial case hidden in these requirements,
> obviating the need for a policy server in many instances.  Thus the
> wording allows for a fairly flexible architecture.  Don't 
> understand the
> policy conditions?  Go ask the policy server.
> 
> This information supersedes section 4.3 of the requirements 
> document and
> augments (and will need to be reconciled with) sections 2.9 
> and 6 of the
> framework document.  The wording here will need to be further 
> reconciled
> with the policy documents.
> 
> Please note that I have not addressed what information is 
> returned to the
> midcom agent.  That is an important topic and it needs to be better
> understood.
> 
> I've also taken a stab at rewriting the duration discussion.  
> There may be
> lots of text we can borrow from the policy people on this subject.
> 
> --
> 
> 4.3  Policy
> 
> Each middlebox decision is made based on either configured 
> policy or by
> querying a policy server.  While it is not within the midcom rubric to
> specify policy configuration methods, the actual policy configuration
> itself is important to discuss.
> 
> A policy statement consists of one or more policy conditions 
> and a policy
> action.[policy]
> 
> 4.3.1 Policy conditions
> 
> Some policy decisions, such as those based on 5-tuple simple 
> access lists
> are likely to be made by a middle box.  Other decisions, however, are
> likely to be more complex.  Hence we propose a nuanced approach that
> allows the policy function to be split.
> 
> The midcom agent MUST be able to satisfy informational 
> requirements of the
> policy conditions in a policy statement in order for the 
> policy server to
> make a decision.  Therefore, a structured exchange that contains those
> components MUST occur between the midcom agent and the middlebox, both
> query and response.  In as much as a policy server is 
> required to resolve
> the policy conditions, a structured exchange MUST also occur 
> between the
> middle box and the policy server.
> 
> If a middle box acts as its own policy server, it MUST understand any
> policy information needed to execute a policy statement.  Put 
> another way,
> it MAY discard any policy information that it doesn't 
> understand so long
> as that information is not required to make a policy decision.
> 
> If the middle box does not understand all of the policy conditions, it
> MUST refer the request to a policy server.  It is a 
> configuration error to
> have a policy condition that neither the middle box nor the 
> policy agent
> can evaluate.
> 
> A middle box SHOULD understand, at a minimum, policy conditions that
> contain the interfaces involved, protocol, source address and port,
> destination address and port, all of which with the exception 
> of protocol
> and interfaces MUST be capable of being expressed as a range 
> of values. 
> This is the trivial case, necessary to deploy a middlebox without the
> assistance of a policy server.
> 
> One should expect a middle box that understands a given 
> policy condition
> to police it.  However, we do not require it.
> 
> 4.3.2 Policy actions
> 
> Policy actions are those actions associated with a set of policy
> conditions in a policy statement.  Examples might be "open a 
> pinhole" or
> "return NAT bindings for a given system".
> 
> The middle box MUST understand the policy action it is to take.  The
> semantics and syntax of each of those policy actions MUST be 
> documented in
> a standard.
> 
> Hence, policy information SHOULD be encoded in a standard form that is
> possible for a middle box to decode, even if it cannot evaluate each
> policy condition.
> 
> Examples of policy statements can be found in [POLICY].
> 
> X Duration
> 
> Decisions made by middle boxes MUST have a specific duration.  That
> duration MUST include a time interval or a set of actual 
> dates and times,
> and MAY include additional termination conditions.  Examples of
> termination conditions include an exchange of TCP FINs, the 
> excessive use
> of bandwidth, or the exchange of unauthorized content.  A 
> midcom agent MAY
> request a change in duration, but the decision of the middle box, like
> every other decision will be bound by policy.
> --
> Eliot Lear
> lear@cisco.com
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:27:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24947
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:27:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08876;
	Thu, 9 Aug 2001 10:27:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08828
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:27:26 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24894
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:26:19 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA01504;
	Thu, 9 Aug 2001 16:27:27 +0200 (MET DST)
Received: from jku.fokus.gmd.de (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79EQrw20048;
	Thu, 9 Aug 2001 16:26:53 +0200
Message-Id: <5.1.0.14.0.20010809150728.02aae980@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 15:09:05 +0200
To: Mark Duffy <mduffy@quarrytech.com>,
        "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "Richard Swale (E-mail)" <richard.swale@bt.com>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] Comments on requirements draft v2
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
In-Reply-To: <3.0.5.32.20010802190118.00917710@email.quarrytech.com>
References: <9154CB41F208D5118DD200508BE39C3044513F@zjguc006.europe.nor tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


>I did raise a question recently about whether the agent needs to be able to influence the address/port bindings in such a way as to ensure e.g. that related flows were assigned bindings with the same IP address.  I do not understand the relevant applications well enough to know if this is a requirement. 

draft-kuthan-fcp-02.txt (to-be-expired-now):

"It is needed, for example, by RTP [9], which recommends allocation of even port numbers for itself, subsequent port number for RTCP and contiguous block of port numbers for layered encoding applications."


-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:27:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24962
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:27:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08978;
	Thu, 9 Aug 2001 10:27:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08844
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:27:27 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24898
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:26:20 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA01510;
	Thu, 9 Aug 2001 16:27:28 +0200 (MET DST)
Received: from jku.fokus.gmd.de (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79EQsw20051;
	Thu, 9 Aug 2001 16:26:54 +0200
Message-Id: <5.1.0.14.0.20010809152533.02aa8348@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 15:32:13 +0200
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "midcom mail-list" <midcom@ietf.org>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] peer-to-peer or client-server
In-Reply-To: <005601c11f48$820a3d20$b89221d9@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I also have trouble understanding why Midcom protocol is called
a peer-to-peer protocol. I would prefer labelling it 
a client(agent)-server(middlebox) protocol. I am not aware of strong 
reasons why a middlebox should initiate midcom-communication to an agent.

-Jiri

At 03:54 PM 8/7/2001, Bob Penfield wrote:
>Hello again,
>
>I have noticed that there seems to be a disconnect between the way many
>people view the relationship between the midcom agent and the middlebox in
>the many informal discussion going on and the text in the framework and
>requirements drafts. Both drafts state that it is a peer-to-peer protocol
>where either the midcom agent or the middlebox can initiate the
>communication between them. However, I and some other people see it more as
>a client-server relationship where the midcom agent initiates the
>communication. The midcom agent requests the services of the middlebox, and
>the middlebox responds with yes or no (hopefully with a reason). The
>middlebox may send asynchronous notifications for certain events (such as
>timeout), but it does not request any services from the midcom agent.
>
>Also, I have a related specific issue with the requirements. In section 5.4
>it states:
>
>   Either the agent or the Middlebox can choose to initiate a
>   connection prior to any data traffic. Alternately, either party
>   (Middlebox or the MIDCOM Agent) may choose to initiate a connection
>   only upon noticing application specific traffic.
>
>I find the second sentence troubling. I thought the main idea was to take
>application intelligence (which would be required to "notice application
>specific traffic") out of the middlebox and put it in the agent.
>
>Hopefully we can discuss this at the meeting on Friday. Although please
>don't wait till then to voice your professional reasoned opinions.
>
>cheers,
>(-:bob
>
>Robert F. Penfield
>Chief Software Architect
>Acme Packet, Inc.
>130 New Boston Street
>Woburn, MA 01801
>bpenfield@acmepacket.com
>
>
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>http://www1.ietf.org/mailman/listinfo/midcom 

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


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:27:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24960
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:27:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08955;
	Thu, 9 Aug 2001 10:27:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08835
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:27:27 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24897
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:26:20 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA01507;
	Thu, 9 Aug 2001 16:27:28 +0200 (MET DST)
Received: from jku.iptel.org (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79EQrw20045;
	Thu, 9 Aug 2001 16:26:53 +0200
Message-Id: <5.1.0.14.0.20010809151153.02aae980@mailhub.fokus.gmd.de>
X-Sender: jiri@iptel.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 15:18:25 +0200
To: "Bob Penfield" <bpenfield@acmepacket.com>,
        "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "Richard Swale \(E-mail\)" <richard.swale@bt.com>,
        "Mark Duffy" <mduffy@quarrytech.com>
From: Jiri Kuthan <jiri@iptel.org>
Subject: NAT associations: query versus set (was Re: [midcom] Comments
  on requirements draft v2
Cc: "Midcom IETF \(E-mail\)" <midcom@ietf.org>
In-Reply-To: <030a01c11c1d$dc6f5e40$2300000a@acmepacket.com>
References: <3.0.5.32.20010802190118.00917710@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I think this discussion appeared on the mailing list looong time
ago and most folks agreed that asking for NAT translation goes
better than setting it.

If we went for "setting", agents (e.g., SIP proxies) would have
to maintain the address pool. Not only does it counter midcom's
decomposition prinicple, but it also introduces lot of tricky
issues. Particularly, things will become more complex with
multiple agents.

-Jiri

><BP>
>There are at least two cases I can think of where the agent wants to tell
>the middlebox what the binding is: 1) when establishing the NAT to allow SIP
>signalling through the middlebox (It will likely want to make the port be
>5060); and 2) for when there are redundant peering points and the agent
>wants to same binding in both NAT middleboxes. It might "learn" the binding
>from one middlebox and "tell" the other middlebox that binding.
></BP>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:27:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24985
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:27:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09029;
	Thu, 9 Aug 2001 10:27:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08909
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:27:32 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24903
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:26:21 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA01513;
	Thu, 9 Aug 2001 16:27:29 +0200 (MET DST)
Received: from jku.fokus.gmd.de (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79EQtw20056;
	Thu, 9 Aug 2001 16:26:55 +0200
Message-Id: <5.1.0.14.0.20010809154027.02a71c78@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 15:46:37 +0200
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Connection,Registration, etc. (was Re: [midcom] Interim rev.
  of the famework draft
In-Reply-To: <20010808102231.F1592@SBRIM-W2K>
References: <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com>
 <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I think I agree. I simply do not see what registration/connection/etc. buys. 
I understand "registration" as a way of telling "Expect some requests from me 
later" and do not understand what problem it solves. Unless some nice reasoning
appears, I would prefer dropping it.

If this is fine, there would be little justification for binding validity of 
a rule (or pinhole, resource, flow state and if we agree on none of these
we may call it simply foo!)  to the notion of connection. It would then only
be bound it its timer.

-Jiri

At 11:22 AM 8/8/2001, Scott Brim wrote:
>On Tue, Aug 07, 2001 at 11:22:50PM -0500, Sanjoy Sen apparently wrote:
>> 1) In Section 4 - Midcom Protocol - it has been stated that the Midcom
>> protocol will consist of a connection set-up phase, run-time phase and a
>> connection termination phase. The meaning of "connection" is not clear.   
>
>The concept of a "connection" is dubious and should be discussed.  Agent
>and middlebox need to authenticate/authorize and then ensure that their
>state is synchronized.  That's about it.
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>http://www1.ietf.org/mailman/listinfo/midcom 

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


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:27:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24996
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:27:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08997;
	Thu, 9 Aug 2001 10:27:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08884
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:27:30 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24892
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:26:19 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA01501;
	Thu, 9 Aug 2001 16:27:27 +0200 (MET DST)
Received: from jku.fokus.gmd.de (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79EQqw20042;
	Thu, 9 Aug 2001 16:26:52 +0200
Message-Id: <5.1.0.14.0.20010809145114.02aae4c8@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 14:51:50 +0200
To: Mark Duffy <mduffy@quarrytech.com>,
        "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>,
        "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: RE: [midcom] defining in-path and out-of-path agents
In-Reply-To: <3.0.5.32.20010801172805.00901a00@email.quarrytech.com>
References: <9154CB41F208D5118DD200508BE39C3044512D@zjguc006.europe.nor tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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 
>
>
>At 06:28 PM 8/1/01 +0100, Cedric Aoun wrote: 
>>>>> 
>
>>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:mshore@cisco.com>mailto:mshore@cisco.com>mailto:mshore@cisco.com] 
>>Sent: Wednesday, August 01, 2001 6:49 PM 
>>To: Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org 
>>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 
><<<< 
>
>
>
>_______________________________________________ midcom mailing list midcom@ietf.org <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
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:27:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25010
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:27:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08826;
	Thu, 9 Aug 2001 10:27:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08793
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:27:24 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24889
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:26:17 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA01492;
	Thu, 9 Aug 2001 16:27:25 +0200 (MET DST)
Received: from jku.fokus.gmd.de (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79EQow20039;
	Thu, 9 Aug 2001 16:26:50 +0200
Message-Id: <5.1.0.14.0.20010809134105.00a76148@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 13:49:54 +0200
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] Requirements summary: all requirements
In-Reply-To: <20010803131556.A1448@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Scott,

I very much appreciate your effort to nail-down the requriement issues.
Let me send my comments on some of them. Mainly, they are motivated by
my desire to limit both framework and requirement documents to a needed
minimum.

-Jiri

   R1: The MIDCOM protocol MUST enable a MIDCOM Agent requiring the
       services of a Middlebox to establish an association between
       itself and the Middlebox for the purposes of requesting pin-hole
       services from the Middlebox and obtaining statistics and other
       reporting information.


*** I am not sure what association means here. I suspect it is not necessarily 
    midcom protocol's task to establish a relationsship (i.e.,
    IP addresses and security credentials) between
    agents and middleboxes (if this is what you mean by association).
    This can be also done by an admin. 
    - proposal: drop R1.

   R3: The Middlebox MUST support multiple simultaneous MIDCOM Agents.

       A specific Middlebox MUST NOT assume any relationship between
       MIDCOM Agents.

*** I do not understand what the second sentence says. I think that
    a middlebox simply does not care whether two agents have some
    relationship or not. 
    - proposal: drop R2


   R4: Agents MUST be known to end system applications.

          This comes from the following text in the framework draft,
          version -03: "In-Path MIDCOM agents are entities that have a
          native role in the path of the application traversal (with
          prior knowledge to one of the application end-hosts),
          independent of their MIDCOM function."

*** I think usage scenarios are out of requirements scope; besides that it is
    not always the case that end-devices know the agent explicitly
    (for example, there might be more SIPproxies in the chain; an
     end-devices sees then only the nearest one which may or may not
     be a midcom agent)
    - proposal: drop R4, fix framework

   R5: a middlebox MUST couple middlebox resources with midcom agents.

          This is from the framework draft, version -03: 

*** I see two issues here: 1) resource ownership and 2) registration/deregistration.
    I think ownership is needed and registration/deregistration not. Both
    these issues need more discussion.

   R6: A middlebox must be able to associate a timer with session
       elements.

*** - proposal: I would like to add a protocol requirement which
      would allow (subject to middlebox policy, of course) agents
      to determine the timer; it is the application that knows best
      what timer values are adequate.


   R7: An agent MUST accept responsibility for application-specific
       processing under direction of a middlebox which is performing a
       related service for that agent.

          This comes from the following text in the framework draft
          version -03: "The MIDCOM protocol between a MIDCOM agent and a
          middlebox allows the MIDCOM agent to gain access to middlebox
          resources and allows the middlebox to delegate application
          specific processing to MIDCOM agent.  The protocol will allow
          MIDCOM agents to signal the middleboxes to let complex
          applications using dynamic port based sessions through them
          (i.e., middleboxes) seamlessly."

          "Delegate" assumes a particular control relationship between
          middlebox and agent.

*** I think R7 says something else than the framework does. The framework
    describes midcom decomposition here. I do not think that an agent
    does anything under direction of a middlebox. I also do not think that
    we can want to dictate agent's responsibility. It is certainly useful
    to describe what an agent may be good for but I do no see the need
    for a requirement here.
    - my proposal: drop R7



   R8: There MUST be some activity between agent and middlebox which
        maintains a "connected" state.

*** Why? Unless this is well documented I would prefer dropping notion
    of connected state (including registration and deregistration) from 
    both framework and requirements. The same for R9.
    - proposal: drop conection,registration,deregistration entirely
      from framework and requriements



   R10: A middlebox MUST be able to notify a midcom agent of the
        following events: Session creation, Session termination, MIDCOM
        protocol failure, Middlebox function failure or any other
        significant event.  Independently, ICMP error codes can also be
        useful to notify transport layer failures to the agents.

           From the framework draft, version -03.

*** I personaly do not expect such notifications to be communicated using
    midcom protocol. As such, I do not see the need for listing it in
    the requirement document. 
    - proposal: drop R10


   R13: Agent hosting entity (whatever that is) MUST be identified in
        the midcom protocol.

           This is from the framework document, version -03.

*** I think this the notion of agent identity is useful and it can be
    used for policy decisions and resource ownership. I do not think
    this must be necessarily feature of the midcom protocol -- this may
    also come from a lower-layer.
    - my proposal: clarify this better in framework, change requriement
      to "Support for communicating agent identity must be present
      either in midcom protocol itself or an accompanying security
      protocol"


   R18: The Middlebox MUST NOT alter packet information unless it
        appears in the packet header.

           There is disagreement over whether this requirement is needed
           or even useful, since it's essentially none of midcom's
           business what a particular middlebox does.

*** I agree with the disagreement,
    - proposal: drop R18

   R21: Where the communication relationship between a Middlebox and a
        MIDCOM Agent becomes invalid, all existing Pin-Holes owned by
        the MIDCOM Agent concerned MUST be closed.

*** The same as for R9. I think that pinhole validity is related to its
    time-to-live rather than to agent's time-to-live.
    proposal: drop it along with connection.disconnecction/registrration/etc.
    (the same later for R34, R35, R36, R37)

   R43: The Midcom Protocol SHOULD allow the aggregation of commands,
        requests and responses.

*** I do not know what command/request/response aggregation is. Could you
    explain please?


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 10:27:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25026
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:27:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09083;
	Thu, 9 Aug 2001 10:28:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09048
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 10:28:01 -0400 (EDT)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24931
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:26:54 -0400 (EDT)
Received: from cisco.com ([10.49.255.233] (may be forged)) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA11833; Thu, 9 Aug 2001 07:27:26 -0700 (PDT)
Message-ID: <3B729DD0.E84CAE56@cisco.com>
Date: Thu, 09 Aug 2001 07:27:28 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Sijben <sijben@lucent.com>
CC: Melinda Shore <mshore@cisco.com>, Scott Brim <sbrim@cisco.com>,
        Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
Subject: Re: [midcom] policy & duration
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <3.0.5.32.20010808102142.007df320@email.quarrytech.com> <039201c120b9$87a412c0$7c8921d9@NAUGA> <3B728C98.2AA6A9AF@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Paul Sijben wrote:

> If a midcom agent takes charge of a packet flow through a *certain*
> middlebox it *must* know the topology of the network (or at least a
> sufficiently complete view on it).

This statement is not necessarily true.  It really depends as much on
discovery or configuration as anything else.  This is why discovery is an
important topic (albeit perhaps one for another venue).
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 11:16:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26671
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 11:16:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11098;
	Thu, 9 Aug 2001 11:11:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11067
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 11:11:53 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26516
	for <midcom@ietf.org>; Thu, 9 Aug 2001 11:10:45 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f79F9UZ06217
	for <midcom@ietf.org>; Thu, 9 Aug 2001 08:09:34 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-179.cisco.com [10.21.112.179])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AIX05734;
	Thu, 9 Aug 2001 08:11:17 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Thu, 9 Aug 2001 16:11:18 +0100
Date: Thu, 9 Aug 2001 16:11:18 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom mail-list <midcom@ietf.org>
Subject: Re: [midcom] requirements - resource (p.k.a. pin-hole) operations
Message-ID: <20010809161118.F1516@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	midcom mail-list <midcom@ietf.org>
References: <003501c11f40$ba8aa160$b89221d9@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <003501c11f40$ba8aa160$b89221d9@acmepacket.com>; from bpenfield@acmepacket.com on Tue, Aug 07, 2001 at 08:59:00AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Tue, Aug 07, 2001 at 08:59:00AM -0400, Bob Penfield apparently wrote:
> Hi all,
> 
> Section 5.3 mentions 3 operations to be performed on a resource (pin-hole)
> in a middlebox. I believe that we need at least 2 more. Namely "create" (or
> "allocate") and "delete" (or "free").
> 
> The create operation would allocate the resource in the middlebox, but
> packets would not be allowed through until an "open" operation is performed.
> An open operation for an unallocated resource could imply a create & open
> operation to minimize the number and size of messages between the agent and
> the middlebox
> 
> The delete operation would be used to free the resource. Close would only
> stop packets from flowing. The resource would not be freed for a close
> operation. The resource could subsequently re-opened by the agent.
> A delete operation on an open resource would imply close & delete.
> 
> A concrete example of an application that needs this capability is SIP. When
> a session is initiated in SIP with an INVITE, the session description may
> define multiple media streams that the client is willing to accept. The
> response from the server may include only a subset of these media streams.
> The resource in the middlebox needs to be allocated/reserved before the
> INVITE is forwarded to the client. However, we do not want to enable packet
> flow until the response is received from the client.

The alternative is to receive the reply and then send your request to
the middlebox.  Are you saying you expect the interval between when the
response is received and when the media packets start arriving to be
very short?  If the pinholes have not been opened when the media packets
arrive, and they are dropped, what happens?

If such a thing as an "activate" message is needed I'm not against it,
but I want to understand the need.  I believe the requirement would be
phrased something like "the midcom protocol must make it possible for
the middlebox to have pinholes available when they are needed".  How
would you phrase it?  The real requirement, not the solution.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 11:16:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26693
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 11:16:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11227;
	Thu, 9 Aug 2001 11:15:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11197
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 11:15:41 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26596
	for <midcom@ietf.org>; Thu, 9 Aug 2001 11:14:34 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id D9C808156
	for <midcom@ietf.org>; Thu,  9 Aug 2001 10:15:42 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA14663
	for <midcom@ietf.org>; Thu, 9 Aug 2001 10:15:42 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Thu, 9 Aug 2001 10:15:42 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] Interim rev. of the famework draft
In-Reply-To: <006301c120ae$a60924e0$9f02700a@acmepacket.com>
Message-ID: <Pine.GSO.4.21.0108091012310.14516-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Thu, 9 Aug 2001, Bob Penfield wrote:

> Andrew Molitor wrote:
> > I do not think the MIDCOM protocol, when defined, should
> > explicitly support the creation of session objects.
> 
> I disagree. It does not have to be mandatory, but it would be nice to
> associate all the RTP streams of a SIP session together and be able to do
> things like extend the timer or delete them with a single handle/identifer.

	I agree with the bundling idea (indeed, I consider it a
requirement). What I want to avoid is some CREATE_SESSION method
which doesn't do anything except create an empty box to put things
in. My preferred approach is to permit the Agents to supply a cookie
with meaningful transactions, and then to apply certain operations
to 'all the stuff with <this> cookie'



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 11:17:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26717
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 11:17:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11276;
	Thu, 9 Aug 2001 11:15:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11243
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 11:15:50 -0400 (EDT)
Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26610
	for <midcom@ietf.org>; Thu, 9 Aug 2001 11:14:43 -0400 (EDT)
Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21])
	by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f79EU1W26427;
	Thu, 9 Aug 2001 07:30:01 -0700
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <P05WQ2FF>; Thu, 9 Aug 2001 08:14:49 -0700
Message-ID: <B162270C965FD511AB9600B0D0B0AB420EAE3D@NAPA>
From: John LaCour <jlacour@netscreen.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>, lear@cisco.com,
        Scott Brim
	 <sbrim@cisco.com>, Mark Duffy <mduffy@quarrytech.com>
Cc: midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 08:17:04 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

> I just want to chime in a say expression of direction without 
> a notion of
> which side is in or out is not of much use. I think is would 
> be more useful
> to define the ingress and egress realms. As I have said 
> before, I believe
> assuming all middleboxes will be connected to exactly two 
> realms would be
> unwise.

Direction doesn't really mean anything to me.  

I think a better description of what we want to describe is the 
PATH through the middlebox.  That may be in one interface and 
out another or in and out the same interface or in/out any type 
of logical interfaces such as those associated with VLAN or 
IPSec tunnels etc.

I see three possible options to deal with this interface, direction,
realm stuff:

1) Agree on a non-confusing abstraction of all of this stuff and
   allow include the appropriate stuff in the protocol to represent it.

  I think it will be hard to get consensus on this without coming up
  with a very simple dumbed down model.

2) Limit the protocol dialogue to affect only one logical middlebox
   and a restricted description of the path through it - maybe one or
   two paths through it.  The MIDCOM server in the middlebox would be
   tied to this specific Path.

  This is actually a good way to do it except that you end having
  multiple conversations between Agents and Physical middleboxes.

3) Include something in the protocol to arbitrarily describe which
   logical middlebox you're talking about.

  This is my suggestion.  If I can say in the protocol this open
  pin hole request is for logical middlebox 'incoming-to-dmz' and in 
  my middlebox implementation I configure my MIDCOM server to
  relate direction, interfaces or whatever to 'incoming-to-dmz' I'm 
  happy.  This also gives me more flexibilty should I decide to
  add interfaces to my middlebox or otherwise change the various
  interfaces, routing, directions, etc.


Anyone else have any preferences for any of these three options?

A fourth is to let the middlebox figure it out.  I don't think
anyone wants that or we wouldn't be having the discussions about
interfaces and direction.

-John





_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 11:27:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27175
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 11:27:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11654;
	Thu, 9 Aug 2001 11:26:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11625
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 11:26:38 -0400 (EDT)
Received: from web13805.mail.yahoo.com (web13805.mail.yahoo.com [216.136.175.15])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27098
	for <midcom@ietf.org>; Thu, 9 Aug 2001 11:25:30 -0400 (EDT)
Message-ID: <20010809152639.75614.qmail@web13805.mail.yahoo.com>
Received: from [66.89.112.150] by web13805.mail.yahoo.com; Thu, 09 Aug 2001 08:26:39 PDT
Date: Thu, 9 Aug 2001 08:26:39 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] Interim rev. of the famework draft
To: Bob Penfield <bpenfield@acmepacket.com>,
        Andrew Molitor <amolitor@visi.com>,
        Sanjoy Sen <sanjoy@nortelnetworks.com>
Cc: "'Pyda Srisuresh'" <srisuresh@yahoo.com>, midcom@ietf.org
In-Reply-To: <006301c120ae$a60924e0$9f02700a@acmepacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

There have been way too many messages to respond. I have not been up 
on all. I hope, my responses below are not out of context. (just a
cautionary note).

--- Bob Penfield <bpenfield@acmepacket.com> wrote:
> Andrew Molitor wrote:
> > I do not think the MIDCOM protocol, when defined, should
> > explicitly support the creation of session objects.
> 
> I disagree. It does not have to be mandatory, but it would be nice to
> associate all the RTP streams of a SIP session together and be able to do
> things like extend the timer or delete them with a single handle/identifer.
> 

Andrew - Why do you say that MIDCOM protocol should not explicitly support
creation of session object? I would think, it is a major requirement to
to be able to create session objects. 

As for session bundling capability - That would be a nice to have, as Bob
points out. Handling a bunch of sessions using a single handle (vs) Agent
tracking the session bundling and sending multiple commands for each of the
bundle member-sessions. (Refer draft-ietf-nat-interface-framework-03.txt for
a way to handle session bundling for NAT).

regards,
suresh



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 11:34:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27527
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 11:34:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12079;
	Thu, 9 Aug 2001 11:31:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12050
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 11:31:06 -0400 (EDT)
Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27272
	for <midcom@ietf.org>; Thu, 9 Aug 2001 11:29:58 -0400 (EDT)
Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21])
	by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f79EjLW26784;
	Thu, 9 Aug 2001 07:45:21 -0700
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <P05WQ2H8>; Thu, 9 Aug 2001 08:30:09 -0700
Message-ID: <B162270C965FD511AB9600B0D0B0AB420EAE3E@NAPA>
From: John LaCour <jlacour@netscreen.com>
To: "'Melinda Shore'" <mshore@cisco.com>, lear@cisco.com,
        Scott Brim
	 <sbrim@cisco.com>, Mark Duffy <mduffy@quarrytech.com>
Cc: midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 08:32:25 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


> Directionality is
> implicit in the source and destination addresses in the packet
> header and a middlebox with more than one interface already
> knows how to route.
> 
> Melinda


I disagree.  Well, sort of.  What we are concerned about is
directionality in the context of security policy.  We don't
want to say that routing policy is the equivalent security policy
with regards to direction.

For example, if all of my SIP phones are behind one interface
and my Gateway behind another, if someone or something screws 
up my routing table, I don't want to my VoIP traffic to be 
sent out to the Internet. 

That said, I don't want to try to express complex network
topologies, interfaces, directions, etc. in MIDCOM.  I'm in favor
of being to able give the logical middlebox and path a name in
the protocol.

-John

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 11:51:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28103
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 11:51:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12644;
	Thu, 9 Aug 2001 11:51:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12614
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 11:51:44 -0400 (EDT)
Received: from web13803.mail.yahoo.com (web13803.mail.yahoo.com [216.136.175.13])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28068
	for <midcom@ietf.org>; Thu, 9 Aug 2001 11:50:36 -0400 (EDT)
Message-ID: <20010809155145.61134.qmail@web13803.mail.yahoo.com>
Received: from [66.89.112.150] by web13803.mail.yahoo.com; Thu, 09 Aug 2001 08:51:45 PDT
Date: Thu, 9 Aug 2001 08:51:45 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: RE: [midcom] Interim rev. of the famework draft
To: midcom@ietf.org
In-Reply-To: <Pine.GSO.4.21.0108081420530.19043-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--- Andrew Molitor <amolitor@visi.com> wrote:
> 
> 
> On Tue, 7 Aug 2001, Sanjoy Sen wrote:
> 
> > I've the following questions/comments on the Interim draft:
> > 
> > 
> > 1) In Section 4 - Midcom Protocol - it has been stated that the Midcom
> > protocol will consist of a connection set-up phase, run-time phase and a
> > connection termination phase. The meaning of "connection" is not clear.   
> 
> 	I don't think the word 'connection' needs to be defined.
> Ideally, there's a better word which means 'some sort of communications
> session with sequence numbers or something to make authentication done
> at the beginning of the session carry forward without undue effort
> throughout the lifetime of the session'
> 
> 	Then we should use that word. Anything more detailed gets
> into implementation, which we're not doing yet.
> 

Yes. 
Folks - We are getting carried away with word-dissection. This type of
thrashing has got to stop. A connection by no means implies TCP/UDP/SCTP
or some other implied transport. Donot assume any transport unless it 
is explicitly stated. People use different terms to imply a lasting 
association (i.e, more than just a datagram association). The FW draft
used the term "connection". That is all there is to it.

RFC 2409 (which uses UDP transport) uses "phase" and "mode" to imply 
a lasting association. (Refer Section 4)

   While Oakley defines "modes", ISAKMP defines "phases"....

   Phase 1 is where the two ISAKMP peers establish a secure,
   authenticated channel with which to communicate... 
   "Main Mode" and "Aggressive Mode" each accomplish a phase 1 exchange. 

   Phase 2 is where Security Associations are negotiated on behalf of
   services such as IPsec or any other service which needs key material
   and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
   exchange.

RFC 2663 uses session/connection toimply a lasting flow.

   A session is defined as the set of traffic that is managed as a unit 
   for translation. TCP/UDP sessions are uniquely identified by the 
   tuple of (source IP address, source TCP/UDP port, target IP address, 
   target TCP/UDP port). 

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 12:07:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28747
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 12:07:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13974;
	Thu, 9 Aug 2001 12:07:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13948
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 12:07:18 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28734
	for <midcom@ietf.org>; Thu, 9 Aug 2001 12:06:10 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA12906;
	Thu, 9 Aug 2001 18:07:19 +0200 (MET DST)
Received: from jku.fokus.gmd.de (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79G6iw20536;
	Thu, 9 Aug 2001 18:06:44 +0200
Message-Id: <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 17:37:56 +0200
To: Mark Duffy <mduffy@quarrytech.com>, lear@cisco.com,
        Scott Brim <sbrim@cisco.com>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
References: <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

How does a, say SIP proxy, know what the direction of a media stream
belonging to a SIP session will be?

-Jiri

At 04:21 PM 8/8/2001, Mark Duffy wrote:
>>Also, I think we remove directionality at our peril.  In an
>>internal/external communication, the reversing of directional rules on
>>interfaces would lead to a weakening of enterprise security.
>
>Not only that, but the directionality is already an aspect of the existing
>firewall functionality we are providing control over.  I too believe
>directionality should be included.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 12:16:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29090
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 12:16:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14191;
	Thu, 9 Aug 2001 12:15:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14162
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 12:15:29 -0400 (EDT)
Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28989
	for <midcom@ietf.org>; Thu, 9 Aug 2001 12:14:21 -0400 (EDT)
Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21])
	by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f79FTkW28314;
	Thu, 9 Aug 2001 08:29:50 -0700
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <P05WQ2Y8>; Thu, 9 Aug 2001 09:14:34 -0700
Message-ID: <B162270C965FD511AB9600B0D0B0AB420EAE41@NAPA>
From: John LaCour <jlacour@netscreen.com>
To: "'Mark Pietras'" <mpietras@aravox.com>, midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 09:16:50 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I dont think the problem is different.

Even if you only have two interfaces you might have
packets that go in and out the same interface.

What is important is that the Middlebox know which
path to apply the MIDCOM request to.

It can either be told explicitly by the agent, it can
try to figure it out on its own - explicit policy
such as the middlebox MIDCOM server being tied to
a specific path or implicitly by something such
as routing.

If we decide we want the agent to tell it explicitly
then we need to decide what kind of data model
for Path will work for all cases of middleboxes.

I support the Middlebox figuring it out on its own
with one small caveat.  An one-token identifier
be included in the protocol to identify which logical
middlebox path this request applies to.  That way
we don't need to have multiple MIDCOM dialogues for
multiple logical middleboxes and Paths.

-John

> -----Original Message-----
> From: Mark Pietras [mailto:mpietras@aravox.com]
> Sent: Thursday, August 09, 2001 7:05 AM
> To: midcom@ietf.org
> Subject: RE: [midcom] policy & duration
> 
> 
> Can someone clarify for me what we're talking about here:
> 
> To me, there are two types of multiple-interfaces:
> 
> 1) I'll call it the ABC-type, where packets arriving on 
> interface A may exit on interface B or interface C (and all 
> the other combinations or a subset thereof)
> 
> 2) I'll call it the NxAB-type, where packets arriving on the 
> interface A of a pair exit on the corresponding interface B 
> of the pair (and visa-versa).
> 
> ABC is a much harder problem to solve than NxAB.  Which 
> multiple-interface type are we discussing?
> 
> Mark.
> 
> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
> Paul Sijben
> Sent: Thursday, August 09, 2001 8:45 AM
> To: Melinda Shore
> Cc: midcom@ietf.org
> Subject: Re: [midcom] policy & duration
> 
> 
> Melinda,
> 
> the issue is clearer when you also address the point that is 
> outside the
> scope of MIDCOM, namely discovery of middleboxes. 
> 
> If you do not address that problem you have *no* idea where 
> the flows are
> going to end up and you can only push a generic policy to *all*
> middleboxes in your network rather than send clear commands 
> to *one* box.
> Obviously, this does not scale. 
> 
> So assuming sufficuently large networks that make midcom deployment
> interesting (rather than stuffing all application intelligence in the
> firewall), you need to know where the flow is going to hit a 
> middlebox and
> (assuming middleboxes with more than 2 interfaces) you need 
> to know where
> the flow needs to go to.
> 
> This makes the midcom agent party to the network topology 
> information as
> far as it needs to know. 
> 
> Now, I am OK that we leave the aspect of getting that kind of 
> information
> to the agent out of the discussion but we can hardly ignore the larger
> architectural impact.  
> 
> Paul
> 
> Melinda Shore wrote:
> > 
> > > From: "Paul Sijben" <sijben@lucent.com>
> > 
> > > If a midcom agent takes charge of a packet flow through a 
> *certain*
> > > middlebox it *must* know the topology of the network (or 
> at least a
> > > sufficiently complete view on it).
> > 
> > People keep saying "must" in regard to directionality
> > and exporting topology to the application (beyond
> > the location of the middlebox), but they haven't made
> > a particularly strong case.  What would be helpful would
> > be a realistic example of a problem that can be solved
> > no other way along with an indication that the people
> > advocating this fully understand the implications of
> > interfacing with the routing system.  The advocacy
> > of this has been adamant in tone and casual in content,
> > and given how profoundly this proposal violates basic
> > IP network architecture principles I believe that it
> > needs a bit more respect.
> > 
> > Melinda
> 
> -- 
> Paul Sijben              Tel:+31 356874774 
> Lucent Technologies      Fax:+31 356875954
> Forward Looking Work     
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 12:24:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29394
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 12:24:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14550;
	Thu, 9 Aug 2001 12:25:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14523
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 12:25:09 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29357
	for <midcom@ietf.org>; Thu, 9 Aug 2001 12:24:03 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA14655;
	Thu, 9 Aug 2001 18:25:10 +0200 (MET DST)
Received: from jku.fokus.gmd.de (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f79GOZw20679;
	Thu, 9 Aug 2001 18:24:35 +0200
Message-Id: <5.1.0.14.0.20010809182101.00a75e28@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 18:28:38 +0200
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
In-Reply-To: <A7895B732354D311A4770008C791841A013147F4@zsc4c014.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Expressiveness of Filtering Expression (was RE: [midcom]
 policy & duration
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 02:37 AM 8/9/2001, Reinaldo Penno wrote:
>Hello Andrew,
> 
>just adding some points on what we disucssed based on my reading of the charter...
> 
>IMO MIDCOM should be a protocol that is general or extensible enough so that I can inform the firewall how to identify, for instance, RTP packets or more generally offsets as you said. 
> 
>It seems some people only want to solve specifically "how to pass SIP through a firewall". This is very evident from the fact that some people think 5 tuple is enough. If we are thinking about getting any type of ALGs from the middlebox, put on a MA and still have the same funcionality, clearly this is not enough.

Could you give me a specific example of an application where a 5-tuple is clearly not 
enough? My personal opinion is that staying simple is good and if someone desires
higher complexity the burden is on him/her to show the need for it.

-Jiri, the believer in "5-tuple is good enough for removing ALGs from middleboxes"


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 12:38:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29685
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 12:38:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15029;
	Thu, 9 Aug 2001 12:36:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15000
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 12:36:47 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29642
	for <midcom@ietf.org>; Thu, 9 Aug 2001 12:35:40 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f79GZu913044
	for <midcom@ietf.org>; Thu, 9 Aug 2001 12:35:56 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Thu, 9 Aug 2001 11:36:21 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <QSVA8F21>; Thu, 9 Aug 2001 09:35:52 -0700
Message-ID: <A7895B732354D311A4770008C791841A01314893@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Jiri Kuthan'" <kuthan@fokus.gmd.de>,
        "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom] poli cy & 
         duration
Date: Thu, 9 Aug 2001 09:35:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C120F1.567ACC60"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C120F1.567ACC60
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Thursday, August 09, 2001 9:29 AM
> To: Penno, Reinaldo [SC9:T327:EXCH]; 'Andrew Molitor'; 
> 'midcom@ietf.org'
> Subject: Expressiveness of Filtering Expression (was RE: 
> [midcom] policy
> & duration
> 
> 
> At 02:37 AM 8/9/2001, Reinaldo Penno wrote:
> >Hello Andrew,
> > 
> >just adding some points on what we disucssed based on my 
> reading of the charter...
> > 
> >IMO MIDCOM should be a protocol that is general or 
> extensible enough so that I can inform the firewall how to 
> identify, for instance, RTP packets or more generally offsets 
> as you said. 
> > 
> >It seems some people only want to solve specifically "how to 
> pass SIP through a firewall". This is very evident from the 
> fact that some people think 5 tuple is enough. If we are 
> thinking about getting any type of ALGs from the middlebox, 
> put on a MA and still have the same funcionality, clearly 
> this is not enough.
> 
> Could you give me a specific example of an application where 
> a 5-tuple is clearly not 
> enough? 

Filter based on TCP flags
Filter based on type of media carried on RTP
Filter based on HTTP method (GET, POST, etc)
Filter based on URL
Filter based on cookies
Filter based on interface
Filter based on VPN-ID
Filter based on subscribe-ID
Filter based on ranges
Filter based on time of day
Filter based on day of week
Filter based on the temperature outside

My personal opinion is that staying simple is good 
> and if omeone desires
> higher complexity the burden is on him/her to show the need for it.
> 
> -Jiri, the believer in "5-tuple is good enough for removing 
> ALGs from middleboxes"

I would rewrite it as "Jiri, someone that wants to solve his SIP problem"

regards,

-RP

> 
> 

------_=_NextPart_001_01C120F1.567ACC60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Expressiveness of Filtering Expression (was RE: [midcom] policy &amp;  duration</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Jiri Kuthan [<A HREF="mailto:kuthan@fokus.gmd.de">mailto:kuthan@fokus.gmd.de</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, August 09, 2001 9:29 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Penno, Reinaldo [SC9:T327:EXCH]; 'Andrew Molitor'; </FONT>
<BR><FONT SIZE=2>&gt; 'midcom@ietf.org'</FONT>
<BR><FONT SIZE=2>&gt; Subject: Expressiveness of Filtering Expression (was RE: </FONT>
<BR><FONT SIZE=2>&gt; [midcom] policy</FONT>
<BR><FONT SIZE=2>&gt; &amp; duration</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 02:37 AM 8/9/2001, Reinaldo Penno wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;Hello Andrew,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;just adding some points on what we disucssed based on my </FONT>
<BR><FONT SIZE=2>&gt; reading of the charter...</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;IMO MIDCOM should be a protocol that is general or </FONT>
<BR><FONT SIZE=2>&gt; extensible enough so that I can inform the firewall how to </FONT>
<BR><FONT SIZE=2>&gt; identify, for instance, RTP packets or more generally offsets </FONT>
<BR><FONT SIZE=2>&gt; as you said. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;It seems some people only want to solve specifically &quot;how to </FONT>
<BR><FONT SIZE=2>&gt; pass SIP through a firewall&quot;. This is very evident from the </FONT>
<BR><FONT SIZE=2>&gt; fact that some people think 5 tuple is enough. If we are </FONT>
<BR><FONT SIZE=2>&gt; thinking about getting any type of ALGs from the middlebox, </FONT>
<BR><FONT SIZE=2>&gt; put on a MA and still have the same funcionality, clearly </FONT>
<BR><FONT SIZE=2>&gt; this is not enough.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Could you give me a specific example of an application where </FONT>
<BR><FONT SIZE=2>&gt; a 5-tuple is clearly not </FONT>
<BR><FONT SIZE=2>&gt; enough? </FONT>
</P>

<P><FONT SIZE=2>Filter based on TCP flags</FONT>
<BR><FONT SIZE=2>Filter based on type of media carried on RTP</FONT>
<BR><FONT SIZE=2>Filter based on HTTP method (GET, POST, etc)</FONT>
<BR><FONT SIZE=2>Filter based on URL</FONT>
<BR><FONT SIZE=2>Filter based on cookies</FONT>
<BR><FONT SIZE=2>Filter based on interface</FONT>
<BR><FONT SIZE=2>Filter based on VPN-ID</FONT>
<BR><FONT SIZE=2>Filter based on subscribe-ID</FONT>
<BR><FONT SIZE=2>Filter based on ranges</FONT>
<BR><FONT SIZE=2>Filter based on time of day</FONT>
<BR><FONT SIZE=2>Filter based on day of week</FONT>
<BR><FONT SIZE=2>Filter based on the temperature outside</FONT>
</P>

<P><FONT SIZE=2>My personal opinion is that staying simple is good </FONT>
<BR><FONT SIZE=2>&gt; and if omeone desires</FONT>
<BR><FONT SIZE=2>&gt; higher complexity the burden is on him/her to show the need for it.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Jiri, the believer in &quot;5-tuple is good enough for removing </FONT>
<BR><FONT SIZE=2>&gt; ALGs from middleboxes&quot;</FONT>
</P>

<P><FONT SIZE=2>I would rewrite it as &quot;Jiri, someone that wants to solve his SIP problem&quot;</FONT>
</P>

<P><FONT SIZE=2>regards,</FONT>
</P>

<P><FONT SIZE=2>-RP</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C120F1.567ACC60--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 13:53:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01520
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 13:53:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17081;
	Thu, 9 Aug 2001 13:52:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17050
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 13:52:50 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01499
	for <midcom@ietf.org>; Thu, 9 Aug 2001 13:51:43 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id 9E94C81D9
	for <midcom@ietf.org>; Thu,  9 Aug 2001 12:52:51 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA24418
	for <midcom@ietf.org>; Thu, 9 Aug 2001 12:52:51 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Thu, 9 Aug 2001 12:52:51 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: Expressiveness of Filtering Expression (was RE: [midcom]  policy
 & duration
In-Reply-To: <5.1.0.14.0.20010809182101.00a75e28@mailhub.fokus.gmd.de>
Message-ID: <Pine.GSO.4.21.0108091245540.23970-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



	WARNING: I am about to diverge into implementation. Please
consider me pre-chastised, and these comments to be random chitchat.

	I'd rather avoid having MIDCOM include some sort of complicated
syntax for describing packets. On the other hand, it's clearly useful to
go beyond 5-tuples for pinholes. Supporting such a syntax is potentially
and implmentation nightmare, since the middlebox implementor has to
build a compiler to convert it into middlebox native filtering.

	Thus, I'd like to see pinholes specified with something like:

	- a 5 tuple (masked)
	- a time to live (of some sort -- see earlier discussions for
	  the ugly problems HERE)
	- a syntactical cookie of the form, e.g. RTP or RTP(256)

	The syntactical cookie would mean 'this pinhole applies to
RT traffic, so if you happen to know anything about what RTP traffic
should look like, please do that'. The cookies might allow cookie-specific
parameters like maximum packet size or whatever.

	Then we could have a little cottage industry producing an endless
stream of RFCs (remember TCP options, I think telnet options, and
MIME types) which define new cookies and what their parameters mean,
together with suggestions for filtering logic to match them.

	A middlebox would ignore cookies it doesn't understand and just
use the 5-tuple.

	This seems to be a more nicely abstract interface, and a WHOLE
lot easier for a middlebox implementor, say, me, to do. The idea of
accepting tcpdump expressions and compiling them on the fly (or matching
them against existing patterns or something) fills me with horror and
dread.

		Andrew



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 14:21:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02102
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 14:21:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18089;
	Thu, 9 Aug 2001 14:21:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18058
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 14:21:27 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02040
	for <midcom@ietf.org>; Thu, 9 Aug 2001 14:20:19 -0400 (EDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f79ILBE23631;
	Thu, 9 Aug 2001 11:21:11 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f79IKse12873;
	Thu, 9 Aug 2001 11:20:54 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id LAA29034; Thu, 9 Aug 2001 11:20:53 -0700 (PDT)
Message-ID: <003401c120ff$e9f56f50$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Paul Sijben" <sijben@lucent.com>
Cc: <midcom@ietf.org>
References: <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <3.0.5.32.20010808102142.007df320@email.quarrytech.com> <039201c120b9$87a412c0$7c8921d9@NAUGA> <3B728C98.2AA6A9AF@lucent.com> <011b01c120d6$758b05e0$7c8921d9@NAUGA> <3B7293CB.F31EBA13@lucent.com>
Subject: Re: [midcom] policy & duration
Date: Thu, 9 Aug 2001 14:18:27 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> the issue is clearer when you also address the point that is outside the
> scope of MIDCOM, namely discovery of middleboxes. 

No, those issues are largely orthogonal.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 14:21:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02113
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 14:21:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18133;
	Thu, 9 Aug 2001 14:21:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18100
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 14:21:32 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02044
	for <midcom@ietf.org>; Thu, 9 Aug 2001 14:20:24 -0400 (EDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f79ILEE23677;
	Thu, 9 Aug 2001 11:21:14 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f79IKuY12924;
	Thu, 9 Aug 2001 11:20:56 -0700 (PDT)
Received: from NAUGA (ssh-rtp1.cisco.com [161.44.11.166]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id LAA29044; Thu, 9 Aug 2001 11:20:54 -0700 (PDT)
Message-ID: <003501c120ff$eaed15c0$7c8921d9@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: "Paul Sijben" <sijben@lucent.com>
Cc: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'midcom'" <midcom@ietf.org>
References: <A7895B732354D311A4770008C791841A01314829@zsc4c014.us.nortel.com> <017201c120da$c0149be0$7c8921d9@NAUGA> <3B729905.D7D61281@lucent.com>
Subject: Re: [midcom] policy & duration
Date: Thu, 9 Aug 2001 14:19:55 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> OK, this line of argument is exactly why QoS should be in scope for
> MIDCOM. 

QoS is not in scope.  This is not negotiable.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 16:24:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04788
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 16:24:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21485;
	Thu, 9 Aug 2001 16:22:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21453
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 16:22:50 -0400 (EDT)
Received: from linux.aravox.com (linux.aravox.com [209.46.41.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04749
	for <midcom@ietf.org>; Thu, 9 Aug 2001 16:21:44 -0400 (EDT)
Received: from MPIETRAS (IDENT:root@linux.aravox.com [209.46.41.66] (may be forged))
	by linux.aravox.com (8.9.3/8.9.3) with SMTP id PAA12795;
	Thu, 9 Aug 2001 15:20:02 -0500
From: "Mark Pietras" <mpietras@aravox.com>
To: "John LaCour" <jlacour@netscreen.com>, <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Thu, 9 Aug 2001 15:20:41 -0500
Message-ID: <AHEILOODAGGJDNIMKEGACELLCAAA.mpietras@aravox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <B162270C965FD511AB9600B0D0B0AB420EAE41@NAPA>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA21454
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

Okay, I (and others, I think) have made the assumption that once a packet arrives on side-A, it may or may not exit on side-B, but not exit again on side-A (without being routed back through by another device, i.e. a new packet to the middlebox).  To me it makes sense to leave that type of routing decision to a router, which to me the device currently defined is not.

If you're trying to solve the VoIP problem of preventing RTP packets from routing outside a LAN just to be routed right back in because the source and destination are on the same side, this should be solved by putting the CALL routing intelligence into the proxy server (or gatekeeper, or whatever) on the same side.  In this case, the middlebox is left out of the call altogether.

Mark.

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
John LaCour
Sent: Thursday, August 09, 2001 11:17 AM
To: 'Mark Pietras'; midcom@ietf.org
Subject: RE: [midcom] policy & duration


I dont think the problem is different.

Even if you only have two interfaces you might have
packets that go in and out the same interface.

What is important is that the Middlebox know which
path to apply the MIDCOM request to.

It can either be told explicitly by the agent, it can
try to figure it out on its own - explicit policy
such as the middlebox MIDCOM server being tied to
a specific path or implicitly by something such
as routing.

If we decide we want the agent to tell it explicitly
then we need to decide what kind of data model
for Path will work for all cases of middleboxes.

I support the Middlebox figuring it out on its own
with one small caveat.  An one-token identifier
be included in the protocol to identify which logical
middlebox path this request applies to.  That way
we don't need to have multiple MIDCOM dialogues for
multiple logical middleboxes and Paths.

-John

> -----Original Message-----
> From: Mark Pietras [mailto:mpietras@aravox.com]
> Sent: Thursday, August 09, 2001 7:05 AM
> To: midcom@ietf.org
> Subject: RE: [midcom] policy & duration
> 
> 
> Can someone clarify for me what we're talking about here:
> 
> To me, there are two types of multiple-interfaces:
> 
> 1) I'll call it the ABC-type, where packets arriving on 
> interface A may exit on interface B or interface C (and all 
> the other combinations or a subset thereof)
> 
> 2) I'll call it the NxAB-type, where packets arriving on the 
> interface A of a pair exit on the corresponding interface B 
> of the pair (and visa-versa).
> 
> ABC is a much harder problem to solve than NxAB.  Which 
> multiple-interface type are we discussing?
> 
> Mark.
> 
> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
> Paul Sijben
> Sent: Thursday, August 09, 2001 8:45 AM
> To: Melinda Shore
> Cc: midcom@ietf.org
> Subject: Re: [midcom] policy & duration
> 
> 
> Melinda,
> 
> the issue is clearer when you also address the point that is 
> outside the
> scope of MIDCOM, namely discovery of middleboxes. 
> 
> If you do not address that problem you have *no* idea where 
> the flows are
> going to end up and you can only push a generic policy to *all*
> middleboxes in your network rather than send clear commands 
> to *one* box.
> Obviously, this does not scale. 
> 
> So assuming sufficuently large networks that make midcom deployment
> interesting (rather than stuffing all application intelligence in the
> firewall), you need to know where the flow is going to hit a 
> middlebox and
> (assuming middleboxes with more than 2 interfaces) you need 
> to know where
> the flow needs to go to.
> 
> This makes the midcom agent party to the network topology 
> information as
> far as it needs to know. 
> 
> Now, I am OK that we leave the aspect of getting that kind of 
> information
> to the agent out of the discussion but we can hardly ignore the larger
> architectural impact.  
> 
> Paul
> 
> Melinda Shore wrote:
> > 
> > > From: "Paul Sijben" <sijben@lucent.com>
> > 
> > > If a midcom agent takes charge of a packet flow through a 
> *certain*
> > > middlebox it *must* know the topology of the network (or 
> at least a
> > > sufficiently complete view on it).
> > 
> > People keep saying "must" in regard to directionality
> > and exporting topology to the application (beyond
> > the location of the middlebox), but they haven't made
> > a particularly strong case.  What would be helpful would
> > be a realistic example of a problem that can be solved
> > no other way along with an indication that the people
> > advocating this fully understand the implications of
> > interfacing with the routing system.  The advocacy
> > of this has been adamant in tone and casual in content,
> > and given how profoundly this proposal violates basic
> > IP network architecture principles I believe that it
> > needs a bit more respect.
> > 
> > Melinda
> 
> -- 
> Paul Sijben              Tel:+31 356874774 
> Lucent Technologies      Fax:+31 356875954
> Forward Looking Work     
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 19:31:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07493
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 19:31:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24904;
	Thu, 9 Aug 2001 19:29:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24865
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 19:29:06 -0400 (EDT)
Received: from basto.stsn.com (p5.usslc14.stsn.com [12.23.74.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07442
	for <midcom@ietf.org>; Thu, 9 Aug 2001 19:27:59 -0400 (EDT)
Received: from BobP ([10.112.3.243])
	by basto.stsn.com (8.11.0/8.11.0) with SMTP id f79MQIi26016;
	Thu, 9 Aug 2001 16:26:18 -0600
Message-ID: <008c01c1212a$e68c9340$f303700a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Andrew Molitor" <amolitor@visi.com>, <midcom@ietf.org>
References: <Pine.GSO.4.21.0108091012310.14516-100000@isis.visi.com>
Subject: Re: [midcom] Interim rev. of the famework draft
Date: Thu, 9 Aug 2001 19:27:46 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Andrew Molitor" <amolitor@visi.com>
To: <midcom@ietf.org>
Sent: Thursday, August 09, 2001 11:15 AM
Subject: Re: [midcom] Interim rev. of the famework draft


>
>
> On Thu, 9 Aug 2001, Bob Penfield wrote:
>
> > Andrew Molitor wrote:
> > > I do not think the MIDCOM protocol, when defined, should
> > > explicitly support the creation of session objects.
> >
> > I disagree. It does not have to be mandatory, but it would be nice to
> > associate all the RTP streams of a SIP session together and be able to
do
> > things like extend the timer or delete them with a single
handle/identifer.
>
> I agree with the bundling idea (indeed, I consider it a
> requirement). What I want to avoid is some CREATE_SESSION method
> which doesn't do anything except create an empty box to put things
> in. My preferred approach is to permit the Agents to supply a cookie
> with meaningful transactions, and then to apply certain operations
> to 'all the stuff with <this> cookie'

I think I agree with that. I would want to say to the middlebox "create this
ruleset/pin-hole/whatever, oh and by the way, please give me an id for that,
and please associate it with bundle X". The bundle should not require a
separate command/request. Also, I would like to say to the middlebox "create
this ruleset, give me an id for it, and give me a new bundle id associated
with it that I can use to tell you what other rulesets are a part of this
bundle".

>
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug  9 22:31:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10769
	for <midcom-archive@odin.ietf.org>; Thu, 9 Aug 2001 22:31:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27935;
	Thu, 9 Aug 2001 22:31:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27909
	for <midcom@ns.ietf.org>; Thu, 9 Aug 2001 22:31:22 -0400 (EDT)
Received: from web13808.mail.yahoo.com (web13808.mail.yahoo.com [216.136.175.18])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10109
	for <midcom@ietf.org>; Thu, 9 Aug 2001 22:30:13 -0400 (EDT)
Message-ID: <20010810023122.61797.qmail@web13808.mail.yahoo.com>
Received: from [66.89.112.150] by web13808.mail.yahoo.com; Thu, 09 Aug 2001 19:31:22 PDT
Date: Thu, 9 Aug 2001 19:31:22 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
To: midcom@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [midcom] Summary of the informal gathering on thursday (08/09)
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Folks,

This is to make public the gist of the informal meeting that
took place today (08/09) to collectively figure out what we need to 
do to make the framework draft through the last call. Thanks to Cedric
Aoun for arranging the Thames suite for the meeting. I called in
over the telephone to parttake in the conversation.

1. Melinda Stated that the objective is not to devoid the framework
   draft of requirements or vice versa. But, it is important that the
   stated or implied requirements be only those that are agreed upon
   (rough consensus). Refer http://www.employees.org/~swb/midcom.html
   for a list of implied requirements in the framework draft

2. Section 2.2: Add a couple of sentences describing 
   traditional Middleboxes that embed application intelligence,
   MIDCOM supported middleboxes that externalize application 
   intelligence and middleboxes that embed application intelligence 
   for some applications and use MIDCOM support for others.

3. Section 2.3: No need to change the defintion of firewall.
   Also, no need to replace the term firewall with "packet filtering".
   Leave the reference to firewall as is.

4. Section 2.6: Change the first sentence as follows:
   Application Level Gateways (ALGs) are entities that possess the 
   application specific intelligence and knowledge of an associated
   middlebox function. 

5. Section 2.8: Mark Duffy will propose new text to replace existing 
   text. There was concern about whether or not intrusive MIDCOM agents
   (in the native path) should be considered In-Path agents. 

6. Section 4.0 - Provide definition of what connection means for 
   the context of this document in the terminology section (section 2.0).
   Connection is described to be a lasting association between a MIDCOM 
   agent and a middlebox and by no means is assumed to be any specific 
   transport layer protocol.

7. Section 6.0 - Paragraph 2 - Last sentence will read as follows.
   In the context of MIDCOM framework, the Policy server does not 
   assist a middlebox in the implementation of the services it 
   provides.

8. Section 6.1 - Second paragraph end - Text on non-Repudiation.
   Looks good. Should stay.

9. Section 6.2 - Provide definition for registration and deregistration
   upfron in terminology section.  
 
10. Section 6.2 - first paragraph - Replace the first paragraph as follows.

   Prior to giving MIDCOM agents access to the middlebox resources,
   a registration process MUST take place. Registration is a
   different process than establishing a transport connection.
   The former requires exchanging agent profile information with the
   middlebox or policy server(s). Agent registration is often a
   manual operation performed by an operator rather than the agent
   itself. The transport connection refers to establishing a MIDCOM 
   transport connection and exchanging security credentials between 
   an agent and a middlebox. The transport connection uses the 
   registered information for connection establishment.

Thats all I have. Thanks.

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 03:53:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00807
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:53:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13325;
	Fri, 10 Aug 2001 03:52:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13220
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 03:52:29 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00782
	for <midcom@ietf.org>; Fri, 10 Aug 2001 03:51:19 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id JAA05520;
	Fri, 10 Aug 2001 09:52:28 +0200 (MET DST)
Received: from jku.iptel.org (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7A7ptw31037;
	Fri, 10 Aug 2001 09:51:55 +0200
Message-Id: <5.1.0.14.0.20010810002255.036f6c60@mailhub.fokus.gmd.de>
X-Sender: jiri@iptel.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 10 Aug 2001 00:52:44 +0200
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
In-Reply-To: <A7895B732354D311A4770008C791841A01314893@zsc4c014.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] RE: Expressiveness of Filtering Expression (was RE: [midcom]
 poli cy &  duration
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 06:35 PM 8/9/2001, Reinaldo Penno wrote:
>Filter based on TCP flags 

I buy this one. I am also eager to buy DS fields. (I'm not kidding, I myself
did propose this in Section 4.5.1 of draft-kuthan-fcp-02.txt).


>Filter based on type of media carried on RTP 
>Filter based on HTTP method (GET, POST, etc) 
>Filter based on URL 
>Filter based on cookies 

I understand removing application-layer intelligence out of routers is 
midcom WG's goal. From this perspective, filtering on HTTP method, cookies, etc.
does not help me to reach this objective. It could end up with a very
powerful midcom command saying "let SIP sessions go through!". I see
the border line of app-independent midcom protocol between transport 
and application layer. I think application-independence is a feature,
not a bug.

>Filter based on interface 

Filtering based in interfaces/directions is an idea which still deserves to
be discussed. 


>Filter based on ranges 

I'm perfectly fine with ranges of values for whatever field we will have.

BTW, I fear you misunderstood me -- I was not interested in seeinga list of
possible extentensions which is potentially endless. I wanted you to
show what they are needed for.

>I would rewrite it as "Jiri, someone that wants to solve his SIP problem" 

That's absolutely correct :-) I am not interested in solving 
outside temperature problem. Don't get me wrong -- I think
that certain generality is good. But it needs to be well 
justified. Remeber that WG's objective is (at least if I got it
right) to allow for modular FWs/NATs and not necessarily to
build a general-use management protocol.

-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 03:56:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00870
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:56:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13336;
	Fri, 10 Aug 2001 03:52:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13248
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 03:52:30 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00785
	for <midcom@ietf.org>; Fri, 10 Aug 2001 03:51:20 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id JAA05525;
	Fri, 10 Aug 2001 09:52:29 +0200 (MET DST)
Received: from jku.iptel.org (host217-33-137-14.ietf.ignite.net [217.33.137.14])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7A7puw31041;
	Fri, 10 Aug 2001 09:51:57 +0200
Message-Id: <5.1.0.14.0.20010809213548.00a753f8@mailhub.fokus.gmd.de>
X-Sender: jiri@iptel.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 10 Aug 2001 01:07:39 +0200
To: John LaCour <jlacour@netscreen.com>, "'Melinda Shore'" <mshore@cisco.com>,
        lear@cisco.com, Scott Brim <sbrim@cisco.com>,
        Mark Duffy <mduffy@quarrytech.com>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Notion of Direction (was RE: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <B162270C965FD511AB9600B0D0B0AB420EAE3E@NAPA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

John,

Let me assume:
a) it is desirable that a middlebox knows through which 
   interfaces a packet is expected to go (which is what I call
   direction) 
b) the flow 5-tuple is known to SIP proxy (which is not necessarily 
   the case with SIP but let us ignore it for now)

Do you expect the SIP proxy to know direction/interfaces 
(even if expressed very abstractly) better than a middlebox? 
If so, I will certainly want to have it in the protocol. 
I am not sure otherwise.

-Jiri


At 05:32 PM 8/9/2001, John LaCour wrote:
>For example, if all of my SIP phones are behind one interface
>and my Gateway behind another, if someone or something screws 
>up my routing table, I don't want to my VoIP traffic to be 
>sent out to the Internet. 
>
>That said, I don't want to try to express complex network
>topologies, interfaces, directions, etc. in MIDCOM.  I'm in favor
>of being to able give the logical middlebox and path a name in
>the protocol.
>
>-John
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>http://www1.ietf.org/mailman/listinfo/midcom 

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


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 04:41:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01435
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 04:41:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14715;
	Fri, 10 Aug 2001 04:41:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14682
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 04:41:44 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01424
	for <midcom@ietf.org>; Fri, 10 Aug 2001 04:40:32 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7A8eo929618
	for <midcom@ietf.org>; Fri, 10 Aug 2001 04:40:50 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Fri, 10 Aug 2001 03:41:10 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <QSVA8WSB>; Fri, 10 Aug 2001 01:40:40 -0700
Message-ID: <A7895B732354D311A4770008C791841A01314A6C@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Jiri Kuthan'" <kuthan@fokus.gmd.de>,
        "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom] poli cy & 
         duration
Date: Fri, 10 Aug 2001 01:40:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12178.21277270"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12178.21277270
Content-Type: text/plain;
	charset="iso-8859-1"

Jiri,

it seems we are almost in agreement. 

I am not trying to change the MIDCOM protocol upside down. I just want to
make the "rule" (I might get killed by using this word) extensible. If, for
instance, GMD Fokus wants to write an informational draft proposing an
extension of the 5 tuple where the it could signal the middlebox to do
filtering based on SIP Messages, INVITEE name, via header, etc, it could. 

I do not know how making the rule extensible could be such a headache. We
are not changing the protocol, just the rule object.

Now, as far as applications that are needed, for instance, URL filtering
that I mentioned is an aplication per se. It is used today in several
firewalls. The same goes for cookie filtering, etc. These are not
extensions, they are applications used by customers/users. I need more than
5 tuple to signal that. 

The same goes for overlapping IP address on the same PE router and SIP
example above.

regards,

Reinaldo 

> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Thursday, August 09, 2001 3:53 PM
> To: Penno, Reinaldo [SC9:T327:EXCH]; 'Andrew Molitor'; 
> 'midcom@ietf.org'
> Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom]
> poli cy & duration
> 
> 
> At 06:35 PM 8/9/2001, Reinaldo Penno wrote:
> >Filter based on TCP flags 
> 
> I buy this one. I am also eager to buy DS fields. (I'm not his word)
> kidding, I myself
> did propose this in Section 4.5.1 of draft-kuthan-fcp-02.txt).
> 
> 
> >Filter based on type of media carried on RTP 
> >Filter based on HTTP method (GET, POST, etc) 
> >Filter based on URL 
> >Filter based on cookies 
> 
> I understand removing application-layer intelligence out of 
> routers is 
> midcom WG's goal. From this perspective, filtering on HTTP 
> method, cookies, etc.
> does not help me to reach this objective. It could end up with a very
> powerful midcom command saying "let SIP sessions go through!". I see
> the border line of app-independent midcom protocol between transport 
> and application layer. I think application-independence is a feature,
> not a bug.
> 
> >Filter based on interface 
> 
> Filtering based in interfaces/directions is an idea which 
> still deserves to
> be discussed. 
> 
> 
> >Filter based on ranges 
> 
> I'm perfectly fine with ranges of values for whatever field 
> we will have.
> 
> BTW, I fear you misunderstood me -- I was not interested in 
> seeinga list of
> possible extentensions which is potentially endless. I wanted you to
> show what they are needed for.
> 
> >I would rewrite it as "Jiri, someone that wants to solve his 
> SIP problem" 
> 
> That's absolutely correct :-) I am not interested in solving 
> outside temperature problem. Don't get me wrong -- I think
> that certain generality is good. But it needs to be well 
> justified. Remeber that WG's objective is (at least if I got it
> right) to allow for modular FWs/NATs and not necessarily to
> build a general-use management protocol.
> 
> -Jiri
> 
> 

------_=_NextPart_001_01C12178.21277270
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Expressiveness of Filtering Expression (was RE: [midcom] =
poli cy &amp;  duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jiri,</FONT>
</P>

<P><FONT SIZE=3D2>it seems we are almost in agreement. </FONT>
</P>

<P><FONT SIZE=3D2>I am not trying to change the MIDCOM protocol upside =
down. I just want to make the &quot;rule&quot; (I might get killed by =
using this word) extensible. If, for instance, GMD Fokus wants to write =
an informational draft proposing an extension of the 5 tuple where the =
it could signal the middlebox to do filtering based on SIP Messages, =
INVITEE name, via header, etc, it could. </FONT></P>

<P><FONT SIZE=3D2>I do not know how making the rule extensible could be =
such a headache. We are not changing the protocol, just the rule =
object.</FONT></P>

<P><FONT SIZE=3D2>Now, as far as applications that are needed, for =
instance, URL filtering that I mentioned is an aplication per se. It is =
used today in several firewalls. The same goes for cookie filtering, =
etc. These are not extensions, they are applications used by =
customers/users. I need more than 5 tuple to signal that. </FONT></P>

<P><FONT SIZE=3D2>The same goes for overlapping IP address on the same =
PE router and SIP example above.</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Jiri Kuthan [<A =
HREF=3D"mailto:kuthan@fokus.gmd.de">mailto:kuthan@fokus.gmd.de</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, August 09, 2001 3:53 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Penno, Reinaldo [SC9:T327:EXCH]; 'Andrew =
Molitor'; </FONT>
<BR><FONT SIZE=3D2>&gt; 'midcom@ietf.org'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Expressiveness of Filtering =
Expression (was RE: [midcom]</FONT>
<BR><FONT SIZE=3D2>&gt; poli cy &amp; duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 06:35 PM 8/9/2001, Reinaldo Penno =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Filter based on TCP flags </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I buy this one. I am also eager to buy DS =
fields. (I'm not his word)</FONT>
<BR><FONT SIZE=3D2>&gt; kidding, I myself</FONT>
<BR><FONT SIZE=3D2>&gt; did propose this in Section 4.5.1 of =
draft-kuthan-fcp-02.txt).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Filter based on type of media carried on =
RTP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Filter based on HTTP method (GET, POST, =
etc) </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Filter based on URL </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Filter based on cookies </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I understand removing application-layer =
intelligence out of </FONT>
<BR><FONT SIZE=3D2>&gt; routers is </FONT>
<BR><FONT SIZE=3D2>&gt; midcom WG's goal. From this perspective, =
filtering on HTTP </FONT>
<BR><FONT SIZE=3D2>&gt; method, cookies, etc.</FONT>
<BR><FONT SIZE=3D2>&gt; does not help me to reach this objective. It =
could end up with a very</FONT>
<BR><FONT SIZE=3D2>&gt; powerful midcom command saying &quot;let SIP =
sessions go through!&quot;. I see</FONT>
<BR><FONT SIZE=3D2>&gt; the border line of app-independent midcom =
protocol between transport </FONT>
<BR><FONT SIZE=3D2>&gt; and application layer. I think =
application-independence is a feature,</FONT>
<BR><FONT SIZE=3D2>&gt; not a bug.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Filter based on interface </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Filtering based in interfaces/directions is an =
idea which </FONT>
<BR><FONT SIZE=3D2>&gt; still deserves to</FONT>
<BR><FONT SIZE=3D2>&gt; be discussed. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Filter based on ranges </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm perfectly fine with ranges of values for =
whatever field </FONT>
<BR><FONT SIZE=3D2>&gt; we will have.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; BTW, I fear you misunderstood me -- I was not =
interested in </FONT>
<BR><FONT SIZE=3D2>&gt; seeinga list of</FONT>
<BR><FONT SIZE=3D2>&gt; possible extentensions which is potentially =
endless. I wanted you to</FONT>
<BR><FONT SIZE=3D2>&gt; show what they are needed for.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I would rewrite it as &quot;Jiri, someone =
that wants to solve his </FONT>
<BR><FONT SIZE=3D2>&gt; SIP problem&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That's absolutely correct :-) I am not =
interested in solving </FONT>
<BR><FONT SIZE=3D2>&gt; outside temperature problem. Don't get me wrong =
-- I think</FONT>
<BR><FONT SIZE=3D2>&gt; that certain generality is good. But it needs =
to be well </FONT>
<BR><FONT SIZE=3D2>&gt; justified. Remeber that WG's objective is (at =
least if I got it</FONT>
<BR><FONT SIZE=3D2>&gt; right) to allow for modular FWs/NATs and not =
necessarily to</FONT>
<BR><FONT SIZE=3D2>&gt; build a general-use management protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -Jiri</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12178.21277270--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 07:04:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03475
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 07:04:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18148;
	Fri, 10 Aug 2001 07:00:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18113
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 07:00:01 -0400 (EDT)
Received: from relay2.bt.net (relay2.bt.net [194.72.6.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03387
	for <midcom@ietf.org>; Fri, 10 Aug 2001 06:58:51 -0400 (EDT)
Received: from [217.33.147.176] (helo=mduffy)
	by relay2.bt.net with smtp (Exim 3.15 #1)
	id 15VA06-0000V5-00; Fri, 10 Aug 2001 11:58:46 +0100
Message-Id: <3.0.5.32.20010810065723.009265a0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 10 Aug 2001 06:57:23 -0400
To: Jiri Kuthan <kuthan@fokus.gmd.de>, Mark Duffy <mduffy@quarrytech.com>,
        lear@cisco.com, Scott Brim <sbrim@cisco.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
References: <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
 <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

In general, a mb has no idea what direction anything *wants* to go in.  All
it does is open pinholes etc at the behest of agents.  If the agent, with
the applic. intelligence, can't determine that, then probably no one can --
maybe in that case the agent should just ask the mb for both directions.
From the point of view of the typical mb, a 5-tuple in one direction is
completely different from the same 5-tuple in the opposite direction.  If
the agent via the midcom protocol cannot express that difference, then the
overall system is essentially dumbed-down to that level.  The result would
be reduced security, if packets matching an n-tuple are permitted in either
direction when in fact they should only be permitted in one.  I believe
that would be an unacceptable reduction in security.

-Mark

At 05:37 PM 8/9/01 +0200, Jiri Kuthan wrote:
>How does a, say SIP proxy, know what the direction of a media stream
>belonging to a SIP session will be?
>
>-Jiri
>
>At 04:21 PM 8/8/2001, Mark Duffy wrote:
>>>Also, I think we remove directionality at our peril.  In an
>>>internal/external communication, the reversing of directional rules on
>>>interfaces would lead to a weakening of enterprise security.
>>
>>Not only that, but the directionality is already an aspect of the existing
>>firewall functionality we are providing control over.  I too believe
>>directionality should be included.
>

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 11:48:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06752
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 11:48:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23556;
	Fri, 10 Aug 2001 11:41:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23523
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 11:41:34 -0400 (EDT)
Received: from web14309.mail.yahoo.com (web14309.mail.yahoo.com [216.136.224.59])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06505
	for <midcom@ietf.org>; Fri, 10 Aug 2001 11:40:23 -0400 (EDT)
Message-ID: <20010810154133.60417.qmail@web14309.mail.yahoo.com>
Received: from [134.117.114.50] by web14309.mail.yahoo.com; Fri, 10 Aug 2001 11:41:33 EDT
Date: Fri, 10 Aug 2001 11:41:33 -0400 (EDT)
From: Abdallah Rayhan <ar_rayhan@yahoo.ca>
Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom] poli cy &          duration
To: midcom@ietf.org
In-Reply-To: <A7895B732354D311A4770008C791841A01314A6C@zsc4c014.us.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

--- Reinaldo Penno <reinaldo_penno@nortelnetworks.com> wrote:
> Jiri,
> 
> it seems we are almost in agreement. 
> 
> I am not trying to change the MIDCOM protocol upside down. I just
> want to
> make the "rule" (I might get killed by using this word) extensible.
> If, for
> instance, GMD Fokus wants to write an informational draft proposing
> an
> extension of the 5 tuple where the it could signal the middlebox to
> do
> filtering based on SIP Messages, INVITEE name, via header, etc, it
> could. 
> 
> I do not know how making the rule extensible could be such a
> headache. We
> are not changing the protocol, just the rule object.

I dont see how that is possible. Once you go beyond L3 upwards
you are changing a major part of the MIDCOM requirement. 
That is bringing the application awareness back into the
middlebox.

regards
Abdallah

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 12:11:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07318
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 12:11:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24554;
	Fri, 10 Aug 2001 12:05:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24525
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 12:05:33 -0400 (EDT)
Received: from web14304.mail.yahoo.com (web14304.mail.yahoo.com [216.136.173.80])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07088
	for <midcom@ietf.org>; Fri, 10 Aug 2001 12:04:22 -0400 (EDT)
Message-ID: <20010810160532.37920.qmail@web14304.mail.yahoo.com>
Received: from [134.117.114.50] by web14304.mail.yahoo.com; Fri, 10 Aug 2001 12:05:32 EDT
Date: Fri, 10 Aug 2001 12:05:32 -0400 (EDT)
From: Abdallah Rayhan <ar_rayhan@yahoo.ca>
Subject: Re: [midcom] Summary of the informal gathering on thursday (08/09)
To: midcom@ietf.org
In-Reply-To: <20010810023122.61797.qmail@web13808.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Suresh,

Thanks for the summary. See comments below.

--- Pyda Srisuresh <srisuresh@yahoo.com> wrote:
> 9. Section 6.2 - Provide definition for registration and
> deregistration
>    upfron in terminology section.  
>  
> 10. Section 6.2 - first paragraph - Replace the first paragraph as
> follows.
> 
>    Prior to giving MIDCOM agents access to the middlebox resources,
>    a registration process MUST take place. Registration is a
>    different process than establishing a transport connection.
>    The former requires exchanging agent profile information with the
>    middlebox or policy server(s). Agent registration is often a
>    manual operation performed by an operator rather than the agent
>    itself. The transport connection refers to establishing a MIDCOM 
>    transport connection and exchanging security credentials between 
>    an agent and a middlebox. The transport connection uses the 
>    registered information for connection establishment.
 
I believe that the idea behind reg/dereg is to address the trust
issue. If an agent registers successfully then it is trusted to 
carry out what it is supposed to do. Restricting that to manual 
operation only and not addressing the possibility of the agent 
doing the reg/dereg process is probably not a desirable outcome. 
I rather refer to this operation as provisioning which is perfectly 
alright if it is manual. IMHO, when an agent registers with an 
middlebox it should indicate the terms under which it is going to
operate whatever those terms are. It could be something like "I am
agent x and want to perform filtering with NAT and no QoS." 
I know QoS is not yet part of any requirements but just an example.

regards
Abdallah

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 12:37:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07814
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 12:37:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25265;
	Fri, 10 Aug 2001 12:34:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25232
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 12:34:00 -0400 (EDT)
Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07698
	for <midcom@ietf.org>; Fri, 10 Aug 2001 12:32:50 -0400 (EDT)
Message-ID: <20010810163359.54946.qmail@web13802.mail.yahoo.com>
Received: from [66.89.112.150] by web13802.mail.yahoo.com; Fri, 10 Aug 2001 09:33:59 PDT
Date: Fri, 10 Aug 2001 09:33:59 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] Summary of the informal gathering on thursday (08/09)
To: Abdallah Rayhan <ar_rayhan@yahoo.ca>, midcom@ietf.org
In-Reply-To: <20010810160532.37920.qmail@web14304.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--- Abdallah Rayhan <ar_rayhan@yahoo.ca> wrote:
> Suresh,
> 
> Thanks for the summary. See comments below.
> 
> --- Pyda Srisuresh <srisuresh@yahoo.com> wrote:
> > 9. Section 6.2 - Provide definition for registration and
> > deregistration
> >    upfron in terminology section.  
> >  
> > 10. Section 6.2 - first paragraph - Replace the first paragraph as
> > follows.
> > 
> >    Prior to giving MIDCOM agents access to the middlebox resources,
> >    a registration process MUST take place. Registration is a
> >    different process than establishing a transport connection.
> >    The former requires exchanging agent profile information with the
> >    middlebox or policy server(s). Agent registration is often a
> >    manual operation performed by an operator rather than the agent
> >    itself. The transport connection refers to establishing a MIDCOM 
> >    transport connection and exchanging security credentials between 
> >    an agent and a middlebox. The transport connection uses the 
> >    registered information for connection establishment.
>  
> I believe that the idea behind reg/dereg is to address the trust
> issue. If an agent registers successfully then it is trusted to 
> carry out what it is supposed to do. Restricting that to manual 

Abdallah - Registration is merely provisioning agent profile information.
(Read the following pragraph that descriebs what the profile may contain). 
I will replace the text "The former requires exchanging agent profile"
with "The former requires provisioning agent profile" - so the meaning
is clearer.

> operation only and not addressing the possibility of the agent 
> doing the reg/dereg process is probably not a desirable outcome. 
> I rather refer to this operation as provisioning which is perfectly 
> alright if it is manual. IMHO, when an agent registers with an 
> middlebox it should indicate the terms under which it is going to
> operate whatever those terms are. It could be something like "I am
> agent x and want to perform filtering with NAT and no QoS." 

See my comment above. 

> I know QoS is not yet part of any requirements but just an example.
> 
> regards
> Abdallah
> 

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 13:07:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08380
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 13:07:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25925;
	Fri, 10 Aug 2001 13:01:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25900
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 13:01:18 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08290
	for <midcom@ietf.org>; Fri, 10 Aug 2001 13:00:08 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA16448
	for <midcom@ietf.org>; Fri, 10 Aug 2001 12:00:45 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Fri, 10 Aug 2001 12:00:36 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <QSVA80Q6>; Fri, 10 Aug 2001 10:00:04 -0700
Message-ID: <A7895B732354D311A4770008C791841A01314ACD@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Abdallah Rayhan'" <ar_rayhan@yahoo.ca>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom] poli cy & 
         duration
Date: Fri, 10 Aug 2001 09:59:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C121BD.E2E1F800"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C121BD.E2E1F800
Content-Type: text/plain;
	charset="iso-8859-1"

Not true,

I can filter based on offsets and know nothing about the application. This
available today.

regards,

Reinaldo

> -----Original Message-----
> From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca]
> Sent: Friday, August 10, 2001 8:42 AM
> To: midcom@ietf.org
> Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom]
> poli cy & duration
> 
> 
> --- Reinaldo Penno <reinaldo_penno@nortelnetworks.com> wrote:
> > Jiri,
> > 
> > it seems we are almost in agreement. 
> > 
> > I am not trying to change the MIDCOM protocol upside down. I just
> > want to
> > make the "rule" (I might get killed by using this word) extensible.
> > If, for
> > instance, GMD Fokus wants to write an informational draft proposing
> > an
> > extension of the 5 tuple where the it could signal the middlebox to
> > do
> > filtering based on SIP Messages, INVITEE name, via header, etc, it
> > could. 
> > 
> > I do not know how making the rule extensible could be such a
> > headache. We
> > are not changing the protocol, just the rule object.
> 
> I dont see how that is possible. Once you go beyond L3 upwards
> you are changing a major part of the MIDCOM requirement. 
> That is bringing the application awareness back into the
> middlebox.
> 
> regards
> Abdallah
> 
> _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C121BD.E2E1F800
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Expressiveness of Filtering Expression (was RE: [midcom] =
poli cy &amp;  duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Not true,</FONT>
</P>

<P><FONT SIZE=3D2>I can filter based on offsets and know nothing about =
the application. This available today.</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Abdallah Rayhan [<A =
HREF=3D"mailto:ar_rayhan@yahoo.ca">mailto:ar_rayhan@yahoo.ca</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Friday, August 10, 2001 8:42 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Expressiveness of Filtering =
Expression (was RE: [midcom]</FONT>
<BR><FONT SIZE=3D2>&gt; poli cy &amp; duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --- Reinaldo Penno =
&lt;reinaldo_penno@nortelnetworks.com&gt; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Jiri,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it seems we are almost in agreement. =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I am not trying to change the MIDCOM =
protocol upside down. I just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; want to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; make the &quot;rule&quot; (I might get =
killed by using this word) extensible.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If, for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; instance, GMD Fokus wants to write an =
informational draft proposing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; extension of the 5 tuple where the it =
could signal the middlebox to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; filtering based on SIP Messages, INVITEE =
name, via header, etc, it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; could. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I do not know how making the rule =
extensible could be such a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; headache. We</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are not changing the protocol, just the =
rule object.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I dont see how that is possible. Once you go =
beyond L3 upwards</FONT>
<BR><FONT SIZE=3D2>&gt; you are changing a major part of the MIDCOM =
requirement. </FONT>
<BR><FONT SIZE=3D2>&gt; That is bringing the application awareness back =
into the</FONT>
<BR><FONT SIZE=3D2>&gt; middlebox.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; regards</FONT>
<BR><FONT SIZE=3D2>&gt; Abdallah</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>&gt; Get your free @yahoo.ca address at <A =
HREF=3D"http://mail.yahoo.ca" =
TARGET=3D"_blank">http://mail.yahoo.ca</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C121BD.E2E1F800--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 10 14:55:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09761
	for <midcom-archive@odin.ietf.org>; Fri, 10 Aug 2001 14:55:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28711;
	Fri, 10 Aug 2001 14:51:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28680
	for <midcom@ns.ietf.org>; Fri, 10 Aug 2001 14:51:46 -0400 (EDT)
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09702
	for <midcom@ietf.org>; Fri, 10 Aug 2001 14:50:35 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #47837)
 with ESMTP id <0GHV001NI8C95P@firewall.mcit.com> for midcom@ietf.org; Fri,
 10 Aug 2001 18:50:33 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GHV00M018BNDY@pmismtp01.wcomnet.com>;
 Fri, 10 Aug 2001 18:50:32 +0000 (GMT)
Received: from rccc6131 ([166.35.225.218])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GHV00KGY8B5JZ@pmismtp01.wcomnet.com>; Fri,
 10 Aug 2001 18:50:09 +0000 (GMT)
Date: Fri, 10 Aug 2001 13:49:48 -0500
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [midcom] policy & duration
In-reply-to: <20010808170926.G1544@SBRIM-W2K>
To: "'Scott Brim'" <sbrim@cisco.com>, midcom@ietf.org
Reply-to: christopher.a.martin@wcom.com
Message-id: <005201c121cd$3be721a0$dae123a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Since pinholes are associated with the packet filtering functionality of a
middlebox I think the following paragraph from the Benchmark WG defines the
packet filter function well:

"Packet-filtering devices forward or deny packets based on information in
each packet's header, such as IP address or TCP/UDP port number. A
packet-filtering firewall uses a rule set to determine which traffic should
be forwarded and which should be blocked." [RFC2647]

In my opinion, a pinhole is related to a receiving or transmitting
tcp/udp/icmp port number or type code associated with a specific session,
typically with one pinhole (port) associated with an inbound data stream
and/or outbound data stream, relative to ingress or egress interface(s) of
the middlebox.



> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
> Scott Brim
> Sent: Wednesday, August 08, 2001 11:09 AM
> To: midcom@ietf.org
> Subject: Re: [midcom] policy & duration
>
>
> On Wed, Aug 08, 2001 at 02:42:31PM +0200, Paul Sijben
> apparently wrote:
> > I beg to differ. Pinholes MAY be *described* by rulesets.
>
> What is a pinhole?  How do you differentiate one pinhole from another,
> functionally?  What thing of substance do you deal with to create a
> pinhole?  I'm looking for your word for that thing.
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sat Aug 11 11:10:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06768
	for <midcom-archive@odin.ietf.org>; Sat, 11 Aug 2001 11:10:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00707;
	Sat, 11 Aug 2001 11:09:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00678
	for <midcom@ns.ietf.org>; Sat, 11 Aug 2001 11:09:28 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06754
	for <midcom@ietf.org>; Sat, 11 Aug 2001 11:08:17 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D9624; Sat, 11 Aug 2001 11:08:57 -0400
Message-Id: <3.0.5.32.20010810155210.00878be0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 10 Aug 2001 15:52:10 -0400
To: John LaCour <jlacour@netscreen.com>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>, lear@cisco.com,
        Scott Brim <sbrim@cisco.com>, Mark Duffy <mduffy@quarrytech.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: RE: [midcom] policy & duration (re direction, realm)
Cc: midcom@ietf.org
In-Reply-To: <B162270C965FD511AB9600B0D0B0AB420EAE3D@NAPA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi John, see below...  -Mark

At 08:17 AM 8/9/01 -0700, John LaCour wrote:
>> I just want to chime in a say expression of direction without 
>> a notion of
>> which side is in or out is not of much use. I think is would 
>> be more useful
>> to define the ingress and egress realms. As I have said 
>> before, I believe
>> assuming all middleboxes will be connected to exactly two 
>> realms would be
>> unwise.
>
>Direction doesn't really mean anything to me.  
>
>I think a better description of what we want to describe is the 
>PATH through the middlebox.  That may be in one interface and 
>out another or in and out the same interface or in/out any type 
>of logical interfaces such as those associated with VLAN or 
>IPSec tunnels etc.

I agree with you in general but I think specifying the "path" (such as
'coming from realmA and going to realmB') couples together two things that
should not be related and the result is that one then has to deal with an
n-squared cross product of all the rules governing what comes in from
RealmA and the rules governing what goes out to RealmB!

A more appropriate way to deal with this, IMHO, is that each
rule/pinhole/resource specify the realm and direction as part of the
n-tuple.  One then ends up with rules that apply to say, packets entering
the MB from RealmA, or those leaving the MB to realmB.  Then if a packet
comes in from realmA and goes out to realmB, both rules could match it, one
at a time.  (The way the MB decides where the packet goes out is of course
out of scope of midcom.)

>I see three possible options to deal with this interface, direction,
>realm stuff:
>
>1) Agree on a non-confusing abstraction of all of this stuff and
>   allow include the appropriate stuff in the protocol to represent it.
>
>  I think it will be hard to get consensus on this without coming up
>  with a very simple dumbed down model.

I like option 1 and I am trying to be more optimistic about it :-)  For
example, even if <realm> got dumbed down to <interface>, that wouldn't be
too dumb, nor too far out, would it?

I agree that your other 2 options below would work as well, although I do
not prefer them.  And I would still like to have logical mb PLUS direction,
rather than encode the direction into the definition of a logical mb such
as 'incoming-to-dmz'.

>2) Limit the protocol dialogue to affect only one logical middlebox
>   and a restricted description of the path through it - maybe one or
>   two paths through it.  The MIDCOM server in the middlebox would be
>   tied to this specific Path.
>
>  This is actually a good way to do it except that you end having
>  multiple conversations between Agents and Physical middleboxes.
>
>3) Include something in the protocol to arbitrarily describe which
>   logical middlebox you're talking about.
>
>  This is my suggestion.  If I can say in the protocol this open
>  pin hole request is for logical middlebox 'incoming-to-dmz' and in 
>  my middlebox implementation I configure my MIDCOM server to
>  relate direction, interfaces or whatever to 'incoming-to-dmz' I'm 
>  happy.  This also gives me more flexibilty should I decide to
>  add interfaces to my middlebox or otherwise change the various
>  interfaces, routing, directions, etc.
>
>
>Anyone else have any preferences for any of these three options?
>
>A fourth is to let the middlebox figure it out.  I don't think
>anyone wants that or we wouldn't be having the discussions about
>interfaces and direction.
>
>-John


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sat Aug 11 14:55:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08192
	for <midcom-archive@odin.ietf.org>; Sat, 11 Aug 2001 14:55:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04925;
	Sat, 11 Aug 2001 14:54:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04894
	for <midcom@ns.ietf.org>; Sat, 11 Aug 2001 14:54:19 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08181
	for <midcom@ietf.org>; Sat, 11 Aug 2001 14:53:07 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D96L7; Sat, 11 Aug 2001 14:53:48 -0400
Message-Id: <3.0.5.32.20010811145307.00867450@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 11 Aug 2001 14:53:07 -0400
To: Jiri Kuthan <kuthan@fokus.gmd.de>, Pyda Srisuresh <srisuresh@yahoo.com>,
        midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
In-Reply-To: <5.1.0.14.0.20010809150728.02aae980@mailhub.fokus.gmd.de>
References: <3.0.5.32.20010802190118.00917710@email.quarrytech.com>
 <9154CB41F208D5118DD200508BE39C3044513F@zjguc006.europe.nor tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] defining the terminology
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Jiri, Suresh,

There has been a lot of discussion about the some of the terms and I
believe someone took an action in London to improve the definitions.

I will leave it to others to select the terms themselves but I would assert
that we should have a separate term for each of the following concepts (at
least):


  <#1>  A single instance of an application-to-application flow of packets
which is identified by source address, source port, destination address,
destination port and protocol id.  (That is the definition for "Microflow"
in RFC 2465 diffserv).

  <#2>  An n-tuple classifier rule within the middlebox (for our purposes,
the rule is placed there using the midcom protocol) that specifies one or
more instances of <#1>.

  <#3>  An action, associated with a specific <#2>, that the middlebox will
apply to packets of any <#1> matching that <#2>.

  <#4>  The set of <#1>'s associated with a single application session.
E.g. all the microflows associated with a given SIP call.

  <#5>  The set of <#2>'s within the middlebox that correspond to a <#4>.
E.g. all the classifier rules that relate to microflows associated with a
given SIP call.


In particular, the above will give us a rich enough set of terms to
distinguish between sets of packets flowing through the network (<#1>,
<#4>, and artifacts in the middlebox the relate to those sets of packets
(<#2>, <#3>, <#5>).

-- Mark



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sat Aug 11 17:32:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09057
	for <midcom-archive@odin.ietf.org>; Sat, 11 Aug 2001 17:32:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07433;
	Sat, 11 Aug 2001 17:31:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07403
	for <midcom@ns.ietf.org>; Sat, 11 Aug 2001 17:31:46 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09040
	for <midcom@ietf.org>; Sat, 11 Aug 2001 17:30:35 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7BLVKQ04372
	for <midcom@ietf.org>; Sat, 11 Aug 2001 14:31:20 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-136.cisco.com [10.21.112.136])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH02295;
	Sat, 11 Aug 2001 14:31:15 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Sat, 11 Aug 2001 22:31:20 +0100
Date: Sat, 11 Aug 2001 22:31:20 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Message-ID: <20010811223120.B500@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] no state in agent?
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Christian, on Friday you said you thought the agent should retain no
state, and that if the middlebox had issues it should communicate
directly with the end node which the agent was representing when it made
its request to the middlebox.  This is an architectural issue, and not
one that we should put off.  If you want us to discuss this, could you
submit a requirement sentence for consideration?

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sat Aug 11 17:33:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09075
	for <midcom-archive@odin.ietf.org>; Sat, 11 Aug 2001 17:33:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07491;
	Sat, 11 Aug 2001 17:33:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07456
	for <midcom@ns.ietf.org>; Sat, 11 Aug 2001 17:33:37 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09067
	for <midcom@ietf.org>; Sat, 11 Aug 2001 17:32:25 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7BLVcQ04432
	for <midcom@ietf.org>; Sat, 11 Aug 2001 14:31:39 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-136.cisco.com [10.21.112.136])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH02299;
	Sat, 11 Aug 2001 14:31:33 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Sat, 11 Aug 2001 22:31:39 +0100
Date: Sat, 11 Aug 2001 22:31:39 +0100
From: Scott Brim <sbrim@cisco.com>
To: midcom mail-list <midcom@ietf.org>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Message-ID: <20010811223138.D500@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	midcom mail-list <midcom@ietf.org>
References: <002b01c11f3e$12a32640$b89221d9@acmepacket.com> <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>; from mduffy@quarrytech.com on Wed, Aug 08, 2001 at 09:16:41AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 08, 2001 at 09:16:41AM -0400, Mark Duffy apparently wrote:
> 1.  a specification for what packets the rule is to match (the
> 5/6/7/whatever-tuple of source/dest address, etc.)
> 2.  a list of middlebox service actions to be applied (e.g.
> pass/drop/nat/etc).
> (Each of the above 1 and 2 might also contain other auxiliary attributes
> such as expiration time, and/or such attributes might belong to the
> resource/ruleset as a whole.) 

> In fact, Bob calls out those components but does not name them.  I suggest
> we need some terminology for those, perhaps resource-descriptor and
> resource-action (or ruleset-descriptor, ruleset-action).

As Dave Oran said, there are 20 years of packet filtering work we can
call on (which I haven't investigated).  He -- I assume he was
representing tradition -- called them matching rules and transform
rules.  I'm willing to call them anything you want.  This is
terminology, this goes in the Framework.  I think those who are serious
about the semantics of rulesets in the protocol ask Dave what he had in
mind.

> Relative to Bob's 7 Aug msg re "resource (p.k.a. pin-hole) operations"
> which proposes additional operations such as create and delete, I would
> suggest there should be operations to add/delete ruleset-descriptors and
> ruleset-actions to rulesets.

I think an action is meaningless without a descriptor, and don't see any
benefit in making it possible for an agent to say "install this
descriptor please" with no associated actions.  I suggest that every
request must include the complete descriptor it relates to, but can
add/delete actions.

> I do agree we also need the concept resource-bundle (or ruleset-bundle or
> foobar-bundle).

Is this more than a descriptor that matches an aggregate?  Do you want
the middlebox to maintain lists of unrelated rulesets?  As you saw in
previous mail I'm uncomfortable with that because I don't think it helps
the agent appropriately, and burdens the middlebox in new ways.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sun Aug 12 09:00:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14793
	for <midcom-archive@odin.ietf.org>; Sun, 12 Aug 2001 09:00:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29082;
	Sun, 12 Aug 2001 08:00:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29040
	for <midcom@ns.ietf.org>; Sun, 12 Aug 2001 08:00:01 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13488
	for <midcom@ietf.org>; Sun, 12 Aug 2001 07:58:47 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id GAA18832
	for <midcom@ietf.org>; Sun, 12 Aug 2001 06:59:15 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Sun, 12 Aug 2001 04:51:43 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <QSVA9TS2>; Sun, 12 Aug 2001 04:59:00 -0700
Message-ID: <A7895B732354D311A4770008C791841A013F3F97@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Scott Brim'" <sbrim@cisco.com>, "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom] poli cy & 
         duration
Date: Sun, 12 Aug 2001 04:59:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12326.2C6C50B0"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12326.2C6C50B0
Content-Type: text/plain;
	charset="iso-8859-1"

yes it is.

thanks,

Reinaldo

> -----Original Message-----
> From: Scott Brim [mailto:sbrim@cisco.com]
> Sent: Sunday, August 12, 2001 4:55 AM
> To: 'midcom@ietf.org'
> Subject: Re: Expressiveness of Filtering Expression (was RE: [midcom]
> poli cy & duration
> 
> 
> On Fri, Aug 10, 2001 at 01:40:37AM -0700, Reinaldo Penno 
> apparently wrote:
> > I am not trying to change the MIDCOM protocol upside down. 
> I just want to
> > make the "rule" (I might get killed by using this word) 
> extensible. If, for
> > instance, GMD Fokus wants to write an informational draft 
> proposing an
> > extension of the 5 tuple where the it could signal the 
> middlebox to do
> > filtering based on SIP Messages, INVITEE name, via header, 
> etc, it could. 
> 
>    R2: The syntax and semantics of the Midcom Protocol MUST be
>        extensible to allow the requirements of future applications to
> 	   be adopted.
> 
> Is this requirement enough or not?
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12326.2C6C50B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Expressiveness of Filtering Expression (was RE: [midcom] =
poli cy &amp;  duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>yes it is.</FONT>
</P>

<P><FONT SIZE=3D2>thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Scott Brim [<A =
HREF=3D"mailto:sbrim@cisco.com">mailto:sbrim@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Sunday, August 12, 2001 4:55 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'midcom@ietf.org'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Expressiveness of Filtering =
Expression (was RE: [midcom]</FONT>
<BR><FONT SIZE=3D2>&gt; poli cy &amp; duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Fri, Aug 10, 2001 at 01:40:37AM -0700, =
Reinaldo Penno </FONT>
<BR><FONT SIZE=3D2>&gt; apparently wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I am not trying to change the MIDCOM =
protocol upside down. </FONT>
<BR><FONT SIZE=3D2>&gt; I just want to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; make the &quot;rule&quot; (I might get =
killed by using this word) </FONT>
<BR><FONT SIZE=3D2>&gt; extensible. If, for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; instance, GMD Fokus wants to write an =
informational draft </FONT>
<BR><FONT SIZE=3D2>&gt; proposing an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; extension of the 5 tuple where the it =
could signal the </FONT>
<BR><FONT SIZE=3D2>&gt; middlebox to do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; filtering based on SIP Messages, INVITEE =
name, via header, </FONT>
<BR><FONT SIZE=3D2>&gt; etc, it could. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; R2: The syntax and semantics =
of the Midcom Protocol MUST be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
extensible to allow the requirements of future applications to</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; be =
adopted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is this requirement enough or not?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12326.2C6C50B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Sun Aug 12 09:00:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14796
	for <midcom-archive@odin.ietf.org>; Sun, 12 Aug 2001 09:00:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29002;
	Sun, 12 Aug 2001 07:55:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28966
	for <midcom@ns.ietf.org>; Sun, 12 Aug 2001 07:55:13 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13383
	for <midcom@ietf.org>; Sun, 12 Aug 2001 07:53:59 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7CBsfQ25230
	for <midcom@ietf.org>; Sun, 12 Aug 2001 04:54:41 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-72.cisco.com [10.21.96.72])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH03458;
	Sun, 12 Aug 2001 04:54:39 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Sun, 12 Aug 2001 07:54:39 -0400
Date: Sun, 12 Aug 2001 07:54:39 -0400
From: Scott Brim <sbrim@cisco.com>
To: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: Re: Expressiveness of Filtering Expression (was RE: [midcom] poli cy & duration
Message-ID: <20010812075439.E1572@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	"'midcom@ietf.org'" <midcom@ietf.org>
References: <A7895B732354D311A4770008C791841A01314A6C@zsc4c014.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <A7895B732354D311A4770008C791841A01314A6C@zsc4c014.us.nortel.com>; from reinaldo_penno@nortelnetworks.com on Fri, Aug 10, 2001 at 01:40:37AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Fri, Aug 10, 2001 at 01:40:37AM -0700, Reinaldo Penno apparently wrote:
> I am not trying to change the MIDCOM protocol upside down. I just want to
> make the "rule" (I might get killed by using this word) extensible. If, for
> instance, GMD Fokus wants to write an informational draft proposing an
> extension of the 5 tuple where the it could signal the middlebox to do
> filtering based on SIP Messages, INVITEE name, via header, etc, it could. 

   R2: The syntax and semantics of the Midcom Protocol MUST be
       extensible to allow the requirements of future applications to
	   be adopted.

Is this requirement enough or not?

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 07:07:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13725
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 07:07:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02606;
	Mon, 13 Aug 2001 07:07:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02577
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 07:07:32 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13659
	for <midcom@ietf.org>; Mon, 13 Aug 2001 07:06:22 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7DB76Q09357;
	Mon, 13 Aug 2001 04:07:06 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp39.cisco.com [10.21.64.39])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABU01409;
	Mon, 13 Aug 2001 04:07:00 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010813070015.00a32240@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Aug 2001 07:08:29 -0400
To: Mark Duffy <mduffy@quarrytech.com>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <3.0.5.32.20010810065723.009265a0@email.quarrytech.com>
References: <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
 <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
 <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 06:57 AM 8/10/01 -0400, Mark Duffy wrote:
>In general, a mb has no idea what direction anything *wants* to go in.  All
>it does is open pinholes etc at the behest of agents.  If the agent, with
>the applic. intelligence, can't determine that, then probably no one can --

That's not really true.

*Clearly* the semantics of a filtering rule are going to be different
when applied to one interface from what they'll be when applied to
another.  The problem is how/whether to bring that information out to an 
application.  I think it's a mistake to assume that software can be
as smart as the network administrator who sits down to manually configure
the box, or that somehow having the agent know the network topology and
the contents of the routing table is equivalent to having a human scribble
the same information on a piece of paper.

It seems to me that the problem here is how to convey the necessary
information to the middlebox that will allow the middlebox to apply
the rules to the correct interface without forcing the agent to become
a participant in the routing system.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 07:08:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13761
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 07:08:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02175;
	Mon, 13 Aug 2001 06:58:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02149
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 06:58:39 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13361
	for <midcom@ietf.org>; Mon, 13 Aug 2001 06:57:29 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7DAwPT06423;
	Mon, 13 Aug 2001 03:58:25 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp39.cisco.com [10.21.64.39])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABU01338;
	Mon, 13 Aug 2001 03:57:59 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010813065715.00a388b0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Aug 2001 06:59:28 -0400
To: Abdallah Rayhan <ar_rayhan@yahoo.ca>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
In-Reply-To: <20010810154133.60417.qmail@web14309.mail.yahoo.com>
References: <A7895B732354D311A4770008C791841A01314A6C@zsc4c014.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] RE: Expressiveness of Filtering Expression (was RE: [midcom]
 poli cy &          duration
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:41 AM 8/10/01 -0400, Abdallah Rayhan wrote:
>I dont see how that is possible. Once you go beyond L3 upwards
>you are changing a major part of the MIDCOM requirement. 
>That is bringing the application awareness back into the
>middlebox.

Two things: 1) you can filter on elements in the IP packet
header other than addresses and ports, and 2) you can filter
on values at fixed offsets (although you might get into trouble
if options are present).

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 07:36:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14776
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 07:36:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03232;
	Mon, 13 Aug 2001 07:35:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03203
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 07:35:45 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14717
	for <midcom@ietf.org>; Mon, 13 Aug 2001 07:34:35 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7DBZQn15758
	for <midcom@ietf.org>; Mon, 13 Aug 2001 04:35:26 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-86.cisco.com [10.21.112.86])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH06920;
	Mon, 13 Aug 2001 04:35:15 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 13 Aug 2001 07:35:15 -0400
Date: Mon, 13 Aug 2001 07:35:15 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Requirements summary: all requirements
Message-ID: <20010813073514.A1560@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010803131556.A1448@SBRIM-W2K> <5.1.0.14.0.20010809134105.00a76148@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010809134105.00a76148@mailhub.fokus.gmd.de>; from kuthan@fokus.gmd.de on Thu, Aug 09, 2001 at 01:49:54PM +0200
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Thu, Aug 09, 2001 at 01:49:54PM +0200, Jiri Kuthan apparently wrote:
> Let me send my comments on some of them. Mainly, they are motivated by
> my desire to limit both framework and requirement documents to a
> needed minimum.
> 
> -Jiri

I hope(!) much of this was taken care of in our meetings.  As I said
before I believe the chair should select no more than three requirements
at a time, and make sure discussion focuses only on those.

It's my turn to catch up on mail ...

>    R1: The MIDCOM protocol MUST enable a MIDCOM Agent requiring the
>    services of a Middlebox to establish an association between itself
>    and the Middlebox for the purposes of requesting pin-hole services
>    from the Middlebox and obtaining statistics and other reporting
>    information.
> 
> 
> *** I am not sure what association means here. I suspect it is not
> necessarily midcom protocol's task to establish a relationsship (i.e.,
> IP addresses and security credentials) between agents and middleboxes
> (if this is what you mean by association).  This can be also done by
> an admin.  - proposal: drop R1.

We truncated from "for the purposes" onward, but we still don't have
agreement -- I think that's simply because we haven't got around to it
(Scott nudges Melinda).

I'll make a note of your interesting suggestion under this bullet item.

>    R3: The Middlebox MUST support multiple simultaneous MIDCOM Agents.
> 
>        A specific Middlebox MUST NOT assume any relationship between
>        MIDCOM Agents.
> 
> *** I do not understand what the second sentence says. I think that a
> middlebox simply does not care whether two agents have some
> relationship or not.  - proposal: drop R2

This has been split into two -- that comment is gone, although I believe
I meant the same thing you do:

   R3a: The Midcom protocol MUST support communication between multiple
        MIDCOM Agents and multiple middleboxes.

   R3b: The Midcom protocol MUST support multiple agents manipulating
        the same middlebox resource.

>    R4: Agents MUST be known to end system applications.
> 
>           This comes from the following text in the framework draft,
>           version -03: "In-Path MIDCOM agents are entities that have a
>           native role in the path of the application traversal (with
>           prior knowledge to one of the application end-hosts),
>           independent of their MIDCOM function."
> 
> *** I think usage scenarios are out of requirements scope; besides
> that it is not always the case that end-devices know the agent
> explicitly (for example, there might be more SIPproxies in the chain;
> an end-devices sees then only the nearest one which may or may not be
> a midcom agent) - proposal: drop R4, fix framework

R4 is dropped because the "interim" framework draft removed the problem
text.


>    R5: a middlebox MUST couple middlebox resources with midcom agents.
> 
>           This is from the framework draft, version -03: 
> 
> *** I see two issues here: 1) resource ownership and 2)
> registration/deregistration.  I think ownership is needed and
> registration/deregistration not. Both these issues need more
> discussion.

Right.  I had already noted that you believe in ownership and I look
forward to that discussion -- the purpose of "ownership" and so on.

>    R6: A middlebox must be able to associate a timer with session
>    elements.
> 
> *** - proposal: I would like to add a protocol requirement which would
> allow (subject to middlebox policy, of course) agents to determine the
> timer; it is the application that knows best what timer values are
> adequate.

We already have:

   R6: A middlebox must be able to associate a timer with a ruleset.
       When a timer expires, resources are freed.

Is that enough?

>    R7: An agent MUST accept responsibility for application-specific
>    processing under direction of a middlebox which is performing a
>    related service for that agent.
> 
>           This comes from the following text in the framework draft
>           version -03: "The MIDCOM protocol between a MIDCOM agent and
>           a middlebox allows the MIDCOM agent to gain access to
>           middlebox resources and allows the middlebox to delegate
>           application specific processing to MIDCOM agent.  The
>           protocol will allow MIDCOM agents to signal the middleboxes
>           to let complex applications using dynamic port based
>           sessions through them (i.e., middleboxes) seamlessly."
> 
>           "Delegate" assumes a particular control relationship between
>           middlebox and agent.
> 
> *** I think R7 says something else than the framework does. The
> framework describes midcom decomposition here. I do not think that an
> agent does anything under direction of a middlebox. I also do not
> think that we can want to dictate agent's responsibility. It is
> certainly useful to describe what an agent may be good for but I do no
> see the need for a requirement here.  - my proposal: drop R7

I put this in the requirements bullets because of the word "delegate".
This one was tentatively tossed out on Monday night because people
didn't care what "delegate" might mean or imply.  (I'll be sending out a
draft of the changes to the requirements bullets I believe we've agreed
to very soon.)

>    R8: There MUST be some activity between agent and middlebox which
>    maintains a "connected" state.
> 
> *** Why? Unless this is well documented I would prefer dropping notion
> of connected state (including registration and deregistration) from
> both framework and requirements. The same for R9.  - proposal: drop
> conection,registration,deregistration entirely from framework and
> requriements

Yes, the Monday night crowd agreed :-).  For different reasons, though.
You're saying we should remove capabilities from the midcom protocol
which we can already do by some other means.  They just thought it was
wrong.  

Your suggestion that we do what we can outside of the midcom protocol
leads us back to the idea of not creating a new protocol, but rather
just adding a slight extension to an existing protocol, like COPS or
Diameter or something on BEEP.  I have a suspicion that we will satisfy
you by selecting a protocol which already does these things.

>    R10: A middlebox MUST be able to notify a midcom agent of the
>    following events: Session creation, Session termination, MIDCOM
>    protocol failure, Middlebox function failure or any other
>    significant event.  Independently, ICMP error codes can also be
>    useful to notify transport layer failures to the agents.
> 
>            From the framework draft, version -03.
> 
> *** I personaly do not expect such notifications to be communicated
> using midcom protocol. As such, I do not see the need for listing it
> in the requirement document.  - proposal: drop R10

Noted.  Still not discussed by the group.

>    R13: Agent hosting entity (whatever that is) MUST be identified in
>    the midcom protocol.
> 
>            This is from the framework document, version -03.
> 
> *** I think this the notion of agent identity is useful and it can be
> used for policy decisions and resource ownership. I do not think this
> must be necessarily feature of the midcom protocol -- this may also
> come from a lower-layer.  - my proposal: clarify this better in
> framework, change requriement to "Support for communicating agent
> identity must be present either in midcom protocol itself or an
> accompanying security protocol"

Noted in the bullets.

>    R18: The Middlebox MUST NOT alter packet information unless it
>    appears in the packet header.
> 
>            There is disagreement over whether this requirement is
>            needed or even useful, since it's essentially none of
>            midcom's business what a particular middlebox does.
> 
> *** I agree with the disagreement, - proposal: drop R18

Done, on Friday.

>    R21: Where the communication relationship between a Middlebox and a
>    MIDCOM Agent becomes invalid, all existing Pin-Holes owned by the
>    MIDCOM Agent concerned MUST be closed.
> 
> *** The same as for R9. I think that pinhole validity is related to
> its time-to-live rather than to agent's time-to-live.  proposal: drop
> it along with connection.disconnecction/registrration/etc.  (the same
> later for R34, R35, R36, R37)

Noted, for those not already rejected as duplicates or subsets.

>    R43: The Midcom Protocol SHOULD allow the aggregation of commands,
>    requests and responses.
> 
> *** I do not know what command/request/response aggregation is. Could
> you explain please?

This means that a single packet could contain multiple requests or
responses.  

Requirements bullets soon.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 07:51:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15329
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 07:51:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03462;
	Mon, 13 Aug 2001 07:51:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03431
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 07:51:34 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15298
	for <midcom@ietf.org>; Mon, 13 Aug 2001 07:50:24 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7DBnFD06898
	for <midcom@ietf.org>; Mon, 13 Aug 2001 04:49:15 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-86.cisco.com [10.21.112.86])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH06969;
	Mon, 13 Aug 2001 04:51:03 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 13 Aug 2001 07:51:03 -0400
Date: Mon, 13 Aug 2001 07:51:03 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: Connection,Registration, etc. (was Re: [midcom] Interim rev. of the famework draft
Message-ID: <20010813075103.C1560@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com> <85AA7486A2C1D411BCA20000F8073E43016BC0FB@crchy271.us.nortel.com> <20010808102231.F1592@SBRIM-W2K> <5.1.0.14.0.20010809154027.02a71c78@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010809154027.02a71c78@mailhub.fokus.gmd.de>; from kuthan@fokus.gmd.de on Thu, Aug 09, 2001 at 03:46:37PM +0200
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Thu, Aug 09, 2001 at 03:46:37PM +0200, Jiri Kuthan apparently wrote:
> I think I agree. I simply do not see what registration/connection/etc. buys. 
> I understand "registration" as a way of telling "Expect some requests from me 
> later" and do not understand what problem it solves. Unless some nice reasoning
> appears, I would prefer dropping it.
> 
> If this is fine, there would be little justification for binding validity of 
> a rule (or pinhole, resource, flow state and if we agree on none of these
> we may call it simply foo!)  to the notion of connection. It would then only
> be bound it its timer.

It turns out Suresh uses "registration" to mean the simple act of making
an agent's *potential* relationship known -- typically done by
configuration of the policy server or the middlebox.  That's why the
current framework draft says less about deregistration and more about
disconnection.

A frob probably needs more than just a timer.  A middlebox probably
needs to keep track of overlapping requests, and who made the requests
(at least for management, perhaps for other reasons).  But the group
agreed that the "connection" requirement was rejected.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 07:51:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15360
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 07:51:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03508;
	Mon, 13 Aug 2001 07:51:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03473
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 07:51:48 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15312
	for <midcom@ietf.org>; Mon, 13 Aug 2001 07:50:37 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7DBpXT23119
	for <midcom@ietf.org>; Mon, 13 Aug 2001 04:51:34 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-86.cisco.com [10.21.112.86])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH06971;
	Mon, 13 Aug 2001 04:51:16 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 13 Aug 2001 07:51:17 -0400
Date: Mon, 13 Aug 2001 07:51:16 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Interim rev. of the famework draft
Message-ID: <20010813075116.D1560@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <Pine.GSO.4.21.0108091012310.14516-100000@isis.visi.com> <008c01c1212a$e68c9340$f303700a@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <008c01c1212a$e68c9340$f303700a@acmepacket.com>; from bpenfield@acmepacket.com on Thu, Aug 09, 2001 at 07:27:46PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Thu, Aug 09, 2001 at 07:27:46PM -0400, Bob Penfield apparently wrote:
> > > I disagree. It does not have to be mandatory, but it would be nice to
> > > associate all the RTP streams of a SIP session together and be able to
> do
> > > things like extend the timer or delete them with a single
> handle/identifer.
> >
> > I agree with the bundling idea (indeed, I consider it a
> > requirement). What I want to avoid is some CREATE_SESSION method
> > which doesn't do anything except create an empty box to put things
> > in. My preferred approach is to permit the Agents to supply a cookie
> > with meaningful transactions, and then to apply certain operations
> > to 'all the stuff with <this> cookie'
> 
> I think I agree with that. I would want to say to the middlebox "create this
> ruleset/pin-hole/whatever, oh and by the way, please give me an id for that,
> and please associate it with bundle X". The bundle should not require a
> separate command/request. Also, I would like to say to the middlebox "create
> this ruleset, give me an id for it, and give me a new bundle id associated
> with it that I can use to tell you what other rulesets are a part of this
> bundle".

This is the where-to-put-state issue again.  It's convenient for the
agent but not for the middlebox.  In the case of a SIP agent, doesn't
the agent have to retain some state information about all the rtp
streams it has arranged for?  The middlebox has no reason to know what's
bundled, except to purportedly offload the agent, and it can't offload
the agent completely.  This looks like an almost perfect example of the
end-to-end argument
<http://web.mit.edu/Saltzer/www/publications/endtoend/>.  If you believe
that you won't put this state into the middlebox.  (On the other hand,
if Christian is right you're going to want lots of state in the
middlebox and very little in the agent anyway.)

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 07:57:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15600
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 07:57:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03712;
	Mon, 13 Aug 2001 07:57:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03406
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 07:51:20 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15285
	for <midcom@ietf.org>; Mon, 13 Aug 2001 07:50:09 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7DBp1n19168
	for <midcom@ietf.org>; Mon, 13 Aug 2001 04:51:01 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-86.cisco.com [10.21.112.86])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH06967;
	Mon, 13 Aug 2001 04:50:49 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 13 Aug 2001 07:50:49 -0400
Date: Mon, 13 Aug 2001 07:50:49 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Message-ID: <20010813075048.B1560@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="oUm6qI6fnHOrTLWp"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] tentative revision of requirement bullets
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--oUm6qI6fnHOrTLWp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

I have created a new version of the requirements bullets.  However, I'm
having trouble with my FTP server (it's probably just a weekend thing).
Since this is a tentative version I'm going to send it to the list now,
and make it FTPable later once I work out the problems.

This is my sense of the FOBs Monday and Thursday night plus anything
that was resolved at the Friday meeting.  I don't know of anything that
has been declared resolved on the mailing list since Friday.  This
version is only based on my notes, not on the "official" meeting notes,
so please review it closely and comment to the midcom list.

I will also include a diff from the version of last Wednesday.

..Scott



--oUm6qI6fnHOrTLWp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="midcom-reqs-bullets-010810.txt"


			  Midcom Requirements

1. Introduction and Goals

   This document lists all agreements made by the IETF Midcom Working
   Group regarding requirements for a protocol between a Midcom agent
   and a middlebox.  Requirements are divided into four sections: those
   requirements which have been discussed and for which consensus has
   been reached; those requirements which are currently under
   discussion; those requirements which have been suggested by working
   group participants but which have not yet been discussed; and
   finally, those requirements which have been discussed and rejected.

   Nothing should be moved into the "agreed on" section without security
   considerations being explicitly addressed.

   For terminology and background information see the Midcom Framework
   document [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

2. Requirements agreed upon by the working group

2.1 Relationship Between Agent and Middlebox


2.2 Relationship Between Agent and Endpoint


2.3 Relationship Between Middlebox and Policy Server


2.4 Middlebox Responsibilities

2.5 Agent Responsibilities


2.6 Midcom Protocol Machinery

   R22: Where a multiplicity of MIDCOM Agents are interacting with a
        given Middlebox, the Midcom Protocol MUST provide mechanisms
        ensuring that the overall behaviour is deterministic.

           Security considerations:

   R23: The Midcom Protocol MUST enable the Middlebox and any associated
        Midcom Agents to establish known and stable state.  This must
        include the case of power failure, or other failure, where the
        protocol must ensure that any resources used by a failed element
        can be released.

           Security considerations:

   R31: The Middlebox MUST be able to report its status to a Midcom
        Agent with which it is associated.

           Security considerations:

   R34: The Midcom Protocol MUST allow either the Midcom Agent or the
        Middlebox to terminate the communications relationship between a
        Midcom Agent and a Middlebox.  This allows either entity to
        close the session for maintenance, security or other reasons.

		   Jiri Kuthan: remove all requirements related to the
		   relationship between agent and middlebox, and have the
		   relationship maintained outside of the midcom protocol.

   R39: A Midcom Agent MUST be able to determine whether a request was
        successful or not.  (Huitema)

           Security considerations:

   R41: The MIDCOM Protocol MUST contain version inter-working
        capabilities to enable subsequent extensions to support
        different types of Middlebox and future requirements of
        applications not considered at this stage.

           Security considerations:


2.7 Midcom Protocol Semantics

   R2: The syntax and semantics of the Midcom Protocol MUST be
       extensible to allow the requirements of future applications to be
       adopted.

           Security considerations:

   R61: If a peer does not understand an option it MUST be clear whether
        the action required is to proceed without the unknown attribute
        being taken into account or the request is to be rejected.
        Where attributes may be ignored if not understood, a means MAY
        be provided to inform the client about what has been ignored.

           This may be provided as a version and capability exchange
           mechanism.

	   Security considerations:


2.8 General Security Requirements

   R69: The Midcom Protocol MUST allow for optional confidentiality
        protection of control messages.  (If provided the mechanism
        should allow a choice in the algorithm to be used.)

	   Security considerations:

   R70: The Midcom Protocol MUST operate across un-trusted domains
        between the MIDCOM Agent and Middlebox in a secure fashion.

	   Security considerations:

   R73: The Midcom Protocol MUST define mechanisms to mitigate replay
        attacks on the control messages.

	   Security considerations:


3. Requirements under discussion

3.1 Relationship Between Agent and Middlebox


3.2 Relationship Between Agent and Endpoint


3.3 Relationship Between Middlebox and Policy Server


3.4 Middlebox Responsibilities

   R5: a middlebox MUST couple middlebox resources with midcom agents.

          This is from the framework draft, version -03: "Coupling
          MIDCOM agents with the middlebox resources requires a means of
          reflecting that into the resource description table of the
          middlebox."

	  Jiri likes the concept of ownership.  Jonathan and Scott think
	  someone else should be able to delete it.  Also if it's
	  requested twice it needs to be deleted twice, with a request
	  identifier.  Christian: what if the "owning" process moves?

   R6: A middlebox must be able to associate a timer with a ruleset.
       When a timer expires, resources are freed.

          From the framework draft, version -03.

	  Session element is undefined.  Ruleset?

   R79: If a particular ruleset is created multiple times, it must be
        deleted the same number of times.

   R80: If two rulesets overlap, and one is deleted, the overlapping
        area must not be deleted until the other is deleted.

	   Lemma to R79.


3.6 Midcom Protocol Machinery

   R1a: The MIDCOM protocol MUST enable a MIDCOM Agent requiring the
        services of a Middlebox to establish an authorized association
	between
        itself and the Middlebox.

	   Some trailing text deleted, but still no agreement at the London
	   meeting.

	   Jiri Kuthan: have authentication and authorization
	   established by some other means outside the midcom protocol.

	   Security considerations:

   R3a1: The Midcom protocol MUST allow a Midcom agent to communicate
         with more than one middleboxes simultaneously.

           Reworded as per 6 Aug 01 discussion and split into R3a1 and
           R3a2 at the London meeting.

           Security considerations:

   R3a2: The Midcom protocol MUST allow a middlebox to communicate with
         more than one Midcom agent simultaneously.

           Reworded as per 6 Aug 01 discussion and split into R3a1 and
           R3a2 at the London meeting.

           Security considerations:

   R3b: The Midcom protocol MUST support multiple agents manipulating
        the same middlebox resource.

   R10: A middlebox MUST be able to notify a midcom agent of the
        following events: Session creation, Session termination, MIDCOM
        protocol failure, Middlebox function failure or any other
        significant event.  Independently, ICMP error codes can also be
        useful to notify transport layer failures to the agents.

           From the framework draft, version -03.

	   "Session" is ugly as a concept and as a word.  Christian
	   likes "for pinholes specifically do this".

	   Jiri Kutan: these things may be communicated but don't use
	   the midcom protocol to do so, use some other existing
	   protocol.  

   R59: The MIDCOM Protocol must allow the ownership of a requested flow
        to be transferred from one MIDCOM Agent to another.

	   Accepted after deleting "In doing so the Middlebox may need
           to act as a mediation point for affecting the transfer of
           ownership.  This is necessary for a variety of reasons
           including scalability of the solution."

	   Ownership has been brought into question.  We can force
	   "ownership" and synchronization issues onto the agents and
	   not require the middlebox to deal with them.  It's not a
	   mutual exclusion property (since we also allow a second box
	   which knows the cookie to kill it), so it must be a security
	   property -- but what security property?

	   It should be expressed as a negative, that the protocol
	   should not preclude this -- but since all of ownership is in
	   question etc.

	   Security considerations:


3.7 Midcom Protocol Semantics

   R11: A "session descriptor" MUST be uniquely identified by the tuple
        {SessionDirection, SourceAddress, DestinationAddress, Protocol,
        SourcePort, DestinationPort}.

           From the framework draft version -03.

           We don't yet know if that's true -- in fact for extensibility
           we cannot assume it's true.  We cannot assume how agents will
           refer to state information they want to control ...  until we
           finish the requirements.

	   Implies directionality of pinholes.  Still under debate.

   R13: Agent hosting entity (whatever that is) MUST be identified in
        the midcom protocol.

           This is from the framework document, version -03.

	   Want to tell not only what the agent is, but something about
	   the host.  IPsec has something equivalent -- Huitema.

	    Jiri Kutan: "Support for communicating agent identity must
	    be present either in midcom protocol itself or an
	    accompanying security protocol."

   R14: Once a connection is established between a middlebox and a
        MIDCOM agent, that connection should be usable with multiple
        instances of the application(s), as appropriate.

           From the framework draft, version -03.

	   "Connection" is a bad term.  Fix.  This is okay, but it MIGHT
	   be redundant.

   R15: A Midcom agent ought to be able to have a single MIDCOM
        connection with a middlebox and use the MIDCOM interface on the
        middlebox to interface with different middlebox functions on the
        same middlebox interface.

           From the framework draft, version -03.

	   Changed "service" to "middlebox function" per 06 Aug 01
	   discussion.  

   R79: The midcom protocol must not preclude multiple authorized agents
	from working on the same ruleset.

	   This was accepted at the London meeting, except that we need
	   to decide on the very last word.


3.8 General Security Requirements

   R16: Security shall be specified to minimize the impact on
        connections that do not use the security option.

           This is from the framework document, version -03.

   R78: The Midcom protocol MUST allow an agent to request that a
	pinhole be opened with specific address(es) and port(s).


4. Requirements not yet discussed

4.1 Relationship Between Agent and Middlebox


4.2 Relationship Between Agent and Endpoint


4.3 Relationship Between Middlebox and Policy Server


4.4 Middlebox Responsibilities


4.5 Agent Responsibilities


4.6 Midcom Protocol Machinery

   R19: A pin-hole may be closed such that ICMP reporting for
        subsequently discarded packets is either enabled or disabled.

   R20: As Pin-Holes may be shared across Middlebox functions, it MUST
        be possible for a Pinhole-Descriptor to be created by one
        function, and terminated by a different one.

           Clarify language.  Are we talking about different middlebox
           functions?  In that case this doesn't make sense.  Is it
           multiple agents?  In that case it's debatable.

   R25: The Midcom Protocol MUST be robust in the face of packet loss,
        packet reordering, mumble.

           Eliminated old wording "MUST be able to operate in an
           extended network environment between the Midcom Agent and the
           Middlebox that may be susceptible to the loss of packets."
           Still need more new words.

   R27: The Midcom Protocol MUST NOT inhibit the deployment of real-time
        communication applications in a Middlebox environment.  It
        therefore MUST exhibit low latency characteristics commensurate
        with the control of such applications.

   R29: The protocol MUST NOT assume 0 (zero) delay in communication
        paths to enable realistic deployment scenarios.  The protocol
        MUST be capable of being used over low speed links.

   R30: The Midcom Agent MUST be able to report its status to a
        Middlebox with which it is associated.

	   Does this imply unnecessary dependency between middlebox and
	   agent?  

   R32: The protocol MUST support unsolicited messages, for event
        reporting and propagation of alarms.

	   Needs to be clarified.

   R33: The relationship between a Midcom Agent and a given Middlebox
        may be pre-configured through a manual configuration process or
        may be established dynamically through a registration process.
        In either case, depending upon the policy applied to the
        Middlebox, the Middlebox MUST appropriately authenticate the
        identity and credentials of the Midcom Agent seeking to make use
        of its services prior to servicing any other requests from the
        Midcom Agent.

	   Need to separate provisioning from authentication.  Two
	   issues.  

   R35: Once the need for the relationship between a Midcom Agent and a
        Middlebox established during the registration process has
        lapsed, a deregistration process will be required.  This will
        break the trust relationship between the specific Middlebox and
        Midcom Agent.  Once this has been done, a Middlebox MUST NOT
        service any further requests from a given Midcom Agent without
        the Midcom Agent first re-establishing the appropriate trust
        relationship with the Middlebox.

	   Wording problems.  "Registration" needs better definition (in
	   framework?).  "Lapsed" is not understood the same by
	   everyone.

   R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom
        Agent to determine when a registration session is no longer
        valid.  This is to address cases such as when either a Middlebox
        or MIDCOM Agent restarts.


4.7 Midcom Protocol Semantics

   R40: A Pin-Hole MUST be identified by a suitable Pinhole-Descriptor
        which uniquely identifies a flow denoted by the tuple of
        FlowDirection, SourceAddress, DestinationAddress, Protocol,
        SourcePort and DestinationPort.

           Should we be this specific?

           Does this statement unduly constrain what the midcom protocol
           may communicate?

           What's the point of having a "MAY" here?

	   This is a better phraseology of what we had back at the
           beginning.  Either make it vague, leave it open, or make it
           specific to pinholes.  Very open, especially because of
           directionality, and add interface.

   R42: The syntax and semantics of the Midcom Protocol MUST be
        independent of the application(s) requesting Middlebox services.

   R43: The Midcom Protocol SHOULD allow the aggregation of commands,
        requests and responses.

	   We don't know what this one really means, but we're putting
	   off judgment until we know more about our other
	   requirements.  

   R44: The protocol MUST permit the expression of direction to be
        associated with a pin-hole.  The direction MUST be specified in
        terms that apply to external view of the Middlebox.  This
        directionality shall be expressed as 'in', 'out' or 'loopback'
        (meaning both 'in' and 'out' of the same side of the same
        Middlebox realm).

   R45: It MUST be possible for the attributes associated with a
        Pinhole-Descriptor to be specific to a given Middlebox or MIDCOM
        Agent.

	   Delay.  Don't know what it means.

   R46: The Midcom Protocol MUST support the concept of an aggregated
        Pinhole-Descriptor comprising a multiple of individual flows to
        be treated as an aggregate.

	   Made SHOULD a MUST.

   R47: When accepting a request for a pin-hole, the Middlebox MUST be
        able to provide the MIDCOM Agent with information that may be
        used to identify the resource in subsequent operations.

	   Temporarily changed "flow" to "resource".  Need better word
	   than "resource".

   R48: The Midcom Protocol MUST allow the MIDCOM Agent to describe the
        desired behaviour of the Middlebox for the purposes of a
        requested flow(s).

           What does this mean in concrete terms?  Paul Sijben should
           figure that out.

   R50: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of IPv4 source
        and destination IP address, protocol number, and diffserv field.

	   Still needs rewording, but yes will allow selection on
	   diffserv field (that's not the same as specifying QoS to
	   apply).  

   R51: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of packet size
        (maximum and minimum length, inter-packet arrival time.

	   Eliot Lear wants to rewrite this section.

   R52: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of IPv4 source
        and destination IP address or group of them determined by a
        netmask, protocol number, diffserv field.

	   Eliot Lear wants to rewrite this section.

   R53: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of IPv6 source
        and destination IP address or group of them determined by a
        netmask, next header fields (Note: multiple fields may need to
        be traversed until a match is found) and traffic class field.

	   Eliot Lear wants to rewrite this section.

   R54: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of UDP source and
        destination port numbers or group of them.

	   Eliot Lear wants to rewrite this section.

   R55: The requests communicated between a MIDCOM Agent and a Middlebox
        MUST permit pin-holes to be specified in terms of TCP source and
        destination port numbers or group of them, 'SYN packets'
        permission.

	   Eliot Lear wants to rewrite this section.

   R56: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of ICMP type
        and code.

	   Eliot Lear wants to rewrite this section.

   R57: The requests communicated between a MIDCOM Agent and a Middlebox
        SHOULD permit pin-holes to be specified in terms of IGMP type.

	   Eliot Lear wants to rewrite this section.

   R60: An operation is needed to enable a MIDCOM Agent to request that
        a Middlebox maintain (refresh) an established Pin-Hole over
        which the Agent has ownership.

	  In general no.  State in the middlebox will have timers on it,
	  so you know it will go away.  It will probably have absolute
	  timers on it.  If the agent wants to extend its life it can
	  issue another request message.

	  Do we want messages to be idempotent?

   R63: To enable management systems to interact with the Midcom
        environment, the protocol MUST include failure reasons that
        allow the Midcom Agent behaviour to be modified as a result of
        the information contained in the reason.  Failure reasons need
        to be chosen such that they do not make an attack on security
        easier.

	   This means "Be helpful -- if you tell me anything, tell me
	   something useful".


4.8 General Security Requirements

   R65: Individual message authentication MUST be used in addition to
        host authentication.  Further message confidentiality MAY be
        administered by employing techniques appropriate to Midcom
        messages.  Simple Source-address based security is the least
        form of security and MAY be permitted only to the most trusted
        hosts.

   R68: The Midcom Protocol MUST allow for preservation of the control
        messages once the association has been established.

	   Richard Swale will correct & resubmit.

   R71: The Midcom Protocol MUST support non-repudiation for a customer-
        located Middlebox communicating with a network operator's MIDCOM
        Agent.

	   Reword this?  Repudiation has legal meaning.  Do we really
	   want all that?

   R74: A Midcom Agent MUST be able to discover what resources are
        available on a middlebox.

   R75: The Midcom Protocol must produce robust operation even when
        routing changes such that traffic from a particular end system
        passes through a different middlebox.  (Huitema)

	   Eliot Lear says "this takes too much state".


5. Requirements already rejected

5.1 Relationship Between Agent and Middlebox


5.2 Relationship Between Agent and Endpoint

   R4: Agents MUST be known to end system applications.

          This comes from the following text in the framework draft,
          version -03: "In-Path MIDCOM agents are entities that have a
          native role in the path of the application traversal (with
          prior knowledge to one of the application end-hosts),
          independent of their MIDCOM function."

	  Jonathan Rosenberg believes this is okay because agents are
	  essentially proxies??

	  Rejected: fixed in the next version of the framework draft.


5.3 Relationship Between Middlebox and Policy Server


5.4 Middlebox Responsibilities

   R18: The Middlebox MUST NOT alter packet information unless it
        appears in the packet header.

           This is to ensure that there is an appropriate separation of
           concerns between the Midcom Agent and the Middlebox.

           There is disagreement over whether this requirement is needed
           or even useful, since it's essentially none of midcom's
           business what a particular middlebox does.

	   This is good: if you want something else done, put it in some
	   other function in the same box.  The point of this protocol
	   is so that the middlebox doesn't have to do these things, and
	   we should support it.

	   This is bad: It's out of scope, we can't mandate what the
	   middlebox does.  Manufacturers will ignore it.  Our job is
	   not to tell people how to design a firewall.  "Packet header"
	   is undefined anyway.  What if there's a trailer?

	   Oran suggests: Packet filters consist of matching rules and
	   transformation rules.  Requirement: you cannot transform a
	   piece of the packet which cannot be defined in a matching
	   rule.

	   Bradner: this would not go through the IESG.

   R76: To enable the MIDCOM Agent to implement the desired application
        level functionality, it may be necessary for the Middlebox to
        forward IP packets received on specific IP addresses and/or
        ports directly to the MIDCOM Agent.

           Diversion has been ruled out of scope.  Future working groups
           may address diversion.

   R77: The Middlebox MUST support the explicit forwarding of
        application control session information received on one, or
        more, destination address/port combinations to an appropriate
        MIDCOM Agent.


5.5 Agent Responsibilities

   R7: An agent MUST accept responsibility for application-specific
       processing under direction of a middlebox which is performing a
       related service for that agent.

          This comes from the following text in the framework draft
          version -03: "The MIDCOM protocol between a MIDCOM agent and a
          middlebox allows the MIDCOM agent to gain access to middlebox
          resources and allows the middlebox to delegate application
          specific processing to MIDCOM agent.  The protocol will allow
          MIDCOM agents to signal the middleboxes to let complex
          applications using dynamic port based sessions through them
          (i.e., middleboxes) seamlessly."

          "Delegate" assumes a particular control relationship between
          middlebox and agent.

	  Rejected because we don't care what "delegate" means.  We'll
	  just ignore this.

5.6 Midcom Protocol Machinery

   R1b: The Midcom protocol MUST enable a Midcom Agent to request 
        services from the Middlebox and obtain statistics and other
        reporting information.

	   Bad: Again, too specific about what the middlebox can and
	   cannot do.  You don't want statistics you want auditing
	   information.  What does "services" mean?
	   
   R8: There MUST be some activity between agent and middlebox which
        maintains a "connected" state.

           This is from the framework document, version -03.

           What kind of interaction do we *require* between agent and
           middlebox, beyond registration and deregistration?

	   Rejected: You don't need keepalives or any other connectivity
	   maintenace.  You just need persistence of state and
	   synchronization when necessary.

   R9: Either the agent or the middlebox may initiate a registration.

           This is from the framework document, version -03.

	   Rejected, and should be fixed in framework.

   R12: The midcom protocol MUST allow for agents to communicate with
        one or more middleboxes, and for middleboxes to communicate with
        one or more agents.

           This is from the framework document, version -03.

	   Rejected: duplicate of R3b

   R21: Where the communication relationship between a Middlebox and a
        MIDCOM Agent becomes invalid, all existing Pin-Holes owned by
        the MIDCOM Agent concerned MUST be closed.

	   Really an imperfect subset of R23, which is accepted.

   R24: The protocol MUST provide per message acknowledgements, in order
        to achieve reliable communication.

	   Rejected in favor of R25 with its rewording.

   R26: The Midcom Protocol SHOULD allow a multiplicity of MIDCOM Agents
        to concurrently interact with a given Middlebox.

	   Rejected, duplicate of R3b.

   R28: The protocol MUST support time-constrained operation to enable
        scalability of the complete solution.  This may include, amongst
        other things, the use of short messages and minimal messages per
        operation.

	   Rejected: too general.

   R36: At the end of a Midcom session between a Middlebox and Midcom
        Agent, it MUST be possible for either the Middlebox or the
        Midcom Agent to initiate the disconnection of the relationship.

	   Rejected: duplicates R34.

   R37: As part of the de-registration process, any Pin-Holes or other
        Middlebox resources requested by the Midcom Agent MUST be
        immediately released by the Middlebox.

	   Rejected: Duplicate.


5.7 Midcom Protocol Semantics

   R49: To enable real-time streamed media to be supported, the Midcom
        Protocol MUST allow a MIDCOM Agent to specify a Pin-Hole in
        terms of the packet size and flow rate which is required.

	   Rejected: for now, no QoS.

   R58: The Midcom Protocol MUST enable a MIDCOM Agent to tear-down an
        active pin-hole.

	   Rejected: duplicate.

   R62: The Midcom Protocol SHOULD allow the aggregation of commands,
        requests and responses.

	   Rejected: duplicate


5.8 General Security Requirements

   R17: Security should be designed to avoid introducing and to minimize
        the impact of denial of service attacks.

           This is from the framework document, version -03.

	   Rejected: motherhood.

   R64: The Midcom Protocol MUST allow communications between
        Middleboxes and MIDCOM Agents to be authenticated.

	   Rejected: duplicate

   R66: Communications between a MIDCOM Agent and a Middlebox constitute
        a flow of requests for services and associated responses.  The
        transport of this information may present a security concern and
        SHOULD be appropriately protected.

	   Rejected: obvious

   R67: The Midcom Protocol MUST allow for mutual authentication at the
        start of an MIDCOM Agent-Middlebox association.

	   Rejected: duplicate

   R72: The Midcom Protocol MUST define mechanisms to mitigate denial of
        service attacks.

	   Rejected: duplicate of R17.


6. Security Considerations

   This document lists individual requirements.  Security considerations
   are listed under the discussion notes for each requirements.

References

   [1]  Srisuresh, P., Kuthan, J., Rosenberg, J. and A. Rayhan,
        "Middlebox Communication Architecture and framework", Internet
        Draft draft-ietf-midcom-framework-03.txt, July 2001.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















Swale, et al.           Expires February 1, 2002               [Page 15]




--oUm6qI6fnHOrTLWp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="diff.txt"

*** midcom-reqs-bullets-010808.txt	Wed Aug  8 09:41:33 2001
--- midcom-reqs-bullets-010810.txt	Sat Aug 11 11:32:23 2001
***************
*** 64,70 ****
          Midcom Agent and a Middlebox.  This allows either entity to
          close the session for maintenance, security or other reasons.
  
!           Security considerations:
  
     R39: A Midcom Agent MUST be able to determine whether a request was
          successful or not.  (Huitema)
--- 64,72 ----
          Midcom Agent and a Middlebox.  This allows either entity to
          close the session for maintenance, security or other reasons.
  
! 		   Jiri Kuthan: remove all requirements related to the
! 		   relationship between agent and middlebox, and have the
! 		   relationship maintained outside of the midcom protocol.
  
     R39: A Midcom Agent MUST be able to determine whether a request was
          successful or not.  (Huitema)
***************
*** 87,102 ****
  
             Security considerations:
  
-    R59: The MIDCOM Protocol must allow the ownership of a requested flow
-         to be transferred from one MIDCOM Agent to another.
- 
- 	   Accepted after deleting "In doing so the Middlebox may need
-            to act as a mediation point for affecting the transfer of
-            ownership.  This is necessary for a variety of reasons
-            including scalability of the solution."
- 
- 	   Security considerations:
- 
     R61: If a peer does not understand an option it MUST be clear whether
          the action required is to proceed without the unknown attribute
          being taken into account or the request is to be rejected.
--- 89,94 ----
***************
*** 135,151 ****
  
  3.2 Relationship Between Agent and Endpoint
  
-    R4: Agents MUST be known to end system applications.
- 
-           This comes from the following text in the framework draft,
-           version -03: "In-Path MIDCOM agents are entities that have a
-           native role in the path of the application traversal (with
-           prior knowledge to one of the application end-hosts),
-           independent of their MIDCOM function."
- 
- 	  Jonathan Rosenberg believes this is okay because agents are
- 	  essentially proxies??
- 
  
  3.3 Relationship Between Middlebox and Policy Server
  
--- 127,132 ----
***************
*** 171,176 ****
--- 152,165 ----
  
  	  Session element is undefined.  Ruleset?
  
+    R79: If a particular ruleset is created multiple times, it must be
+         deleted the same number of times.
+ 
+    R80: If two rulesets overlap, and one is deleted, the overlapping
+         area must not be deleted until the other is deleted.
+ 
+ 	   Lemma to R79.
+ 
  
  3.6 Midcom Protocol Machinery
  
***************
*** 179,194 ****
  	between
          itself and the Middlebox.
  
!    R1b: The Midcom protocol MUST enable a Midcom Agent to request 
!         services from the Middlebox and obtain statistics and other
!         reporting information.
  
            Security considerations:
  
!    R3a: The Midcom protocol MUST support communication between multiple
!         MIDCOM Agents and multiple middleboxes.
  
!           Reworded as per 6 Aug 01 discussion.
  
            Security considerations:
  
--- 168,194 ----
  	between
          itself and the Middlebox.
  
! 	   Some trailing text deleted, but still no agreement at the London
! 	   meeting.
! 
! 	   Jiri Kuthan: have authentication and authorization
! 	   established by some other means outside the midcom protocol.
! 
! 	   Security considerations:
! 
!    R3a1: The Midcom protocol MUST allow a Midcom agent to communicate
!          with more than one middleboxes simultaneously.
! 
!            Reworded as per 6 Aug 01 discussion and split into R3a1 and
!            R3a2 at the London meeting.
  
             Security considerations:
  
!    R3a2: The Midcom protocol MUST allow a middlebox to communicate with
!          more than one Midcom agent simultaneously.
  
!            Reworded as per 6 Aug 01 discussion and split into R3a1 and
!            R3a2 at the London meeting.
  
             Security considerations:
  
***************
*** 206,211 ****
--- 206,237 ----
  	   "Session" is ugly as a concept and as a word.  Christian
  	   likes "for pinholes specifically do this".
  
+ 	   Jiri Kutan: these things may be communicated but don't use
+ 	   the midcom protocol to do so, use some other existing
+ 	   protocol.  
+ 
+    R59: The MIDCOM Protocol must allow the ownership of a requested flow
+         to be transferred from one MIDCOM Agent to another.
+ 
+ 	   Accepted after deleting "In doing so the Middlebox may need
+            to act as a mediation point for affecting the transfer of
+            ownership.  This is necessary for a variety of reasons
+            including scalability of the solution."
+ 
+ 	   Ownership has been brought into question.  We can force
+ 	   "ownership" and synchronization issues onto the agents and
+ 	   not require the middlebox to deal with them.  It's not a
+ 	   mutual exclusion property (since we also allow a second box
+ 	   which knows the cookie to kill it), so it must be a security
+ 	   property -- but what security property?
+ 
+ 	   It should be expressed as a negative, that the protocol
+ 	   should not preclude this -- but since all of ownership is in
+ 	   question etc.
+ 
+ 	   Security considerations:
+ 
+ 
  3.7 Midcom Protocol Semantics
  
     R11: A "session descriptor" MUST be uniquely identified by the tuple
***************
*** 229,234 ****
--- 255,264 ----
  	   Want to tell not only what the agent is, but something about
  	   the host.  IPsec has something equivalent -- Huitema.
  
+ 	    Jiri Kutan: "Support for communicating agent identity must
+ 	    be present either in midcom protocol itself or an
+ 	    accompanying security protocol."
+ 
     R14: Once a connection is established between a middlebox and a
          MIDCOM agent, that connection should be usable with multiple
          instances of the application(s), as appropriate.
***************
*** 248,253 ****
--- 278,289 ----
  	   Changed "service" to "middlebox function" per 06 Aug 01
  	   discussion.  
  
+    R79: The midcom protocol must not preclude multiple authorized agents
+ 	from working on the same ruleset.
+ 
+ 	   This was accepted at the London meeting, except that we need
+ 	   to decide on the very last word.
+ 
  
  3.8 General Security Requirements
  
***************
*** 273,288 ****
  
  4.4 Middlebox Responsibilities
  
-    R18: The Middlebox MUST NOT alter packet information unless it
-         appears in the packet header.
- 
-            This is to ensure that there is an appropriate separation of
-            concerns between the Midcom Agent and the Middlebox.
- 
-            There is disagreement over whether this requirement is needed
-            or even useful, since it's essentially none of midcom's
-            business what a particular middlebox does.
- 
  
  4.5 Agent Responsibilities
  
--- 309,314 ----
***************
*** 300,311 ****
             functions?  In that case this doesn't make sense.  Is it
             multiple agents?  In that case it's debatable.
  
-    R21: Where the communication relationship between a Middlebox and a
-         MIDCOM Agent becomes invalid, all existing Pin-Holes owned by
-         the MIDCOM Agent concerned MUST be closed.
- 
- 	   Really an imperfect subset of R23, which is accepted.
- 
     R25: The Midcom Protocol MUST be robust in the face of packet loss,
          packet reordering, mumble.
  
--- 326,331 ----
***************
*** 364,381 ****
          valid.  This is to address cases such as when either a Middlebox
          or MIDCOM Agent restarts.
  
-    R26: The Midcom Protocol SHOULD allow a multiplicity of MIDCOM Agents
-         to concurrently interact with a given Middlebox.
- 
- 	   Rejected, duplicate of R3b.
- 
-    R28: The protocol MUST support time-constrained operation to enable
-         scalability of the complete solution.  This may include, amongst
-         other things, the use of short messages and minimal messages per
-         operation.
- 
- 	   Rejected: too general.
- 
  
  4.7 Midcom Protocol Semantics
  
--- 384,389 ----
***************
*** 552,563 ****
--- 560,611 ----
  
  5.2 Relationship Between Agent and Endpoint
  
+    R4: Agents MUST be known to end system applications.
+ 
+           This comes from the following text in the framework draft,
+           version -03: "In-Path MIDCOM agents are entities that have a
+           native role in the path of the application traversal (with
+           prior knowledge to one of the application end-hosts),
+           independent of their MIDCOM function."
+ 
+ 	  Jonathan Rosenberg believes this is okay because agents are
+ 	  essentially proxies??
+ 
+ 	  Rejected: fixed in the next version of the framework draft.
+ 
  
  5.3 Relationship Between Middlebox and Policy Server
  
  
  5.4 Middlebox Responsibilities
  
+    R18: The Middlebox MUST NOT alter packet information unless it
+         appears in the packet header.
+ 
+            This is to ensure that there is an appropriate separation of
+            concerns between the Midcom Agent and the Middlebox.
+ 
+            There is disagreement over whether this requirement is needed
+            or even useful, since it's essentially none of midcom's
+            business what a particular middlebox does.
+ 
+ 	   This is good: if you want something else done, put it in some
+ 	   other function in the same box.  The point of this protocol
+ 	   is so that the middlebox doesn't have to do these things, and
+ 	   we should support it.
+ 
+ 	   This is bad: It's out of scope, we can't mandate what the
+ 	   middlebox does.  Manufacturers will ignore it.  Our job is
+ 	   not to tell people how to design a firewall.  "Packet header"
+ 	   is undefined anyway.  What if there's a trailer?
+ 
+ 	   Oran suggests: Packet filters consist of matching rules and
+ 	   transformation rules.  Requirement: you cannot transform a
+ 	   piece of the packet which cannot be defined in a matching
+ 	   rule.
+ 
+ 	   Bradner: this would not go through the IESG.
+ 
     R76: To enable the MIDCOM Agent to implement the desired application
          level functionality, it may be necessary for the Middlebox to
          forward IP packets received on specific IP addresses and/or
***************
*** 595,600 ****
--- 643,656 ----
  
  5.6 Midcom Protocol Machinery
  
+    R1b: The Midcom protocol MUST enable a Midcom Agent to request 
+         services from the Middlebox and obtain statistics and other
+         reporting information.
+ 
+ 	   Bad: Again, too specific about what the middlebox can and
+ 	   cannot do.  You don't want statistics you want auditing
+ 	   information.  What does "services" mean?
+ 	   
     R8: There MUST be some activity between agent and middlebox which
          maintains a "connected" state.
  
***************
*** 621,630 ****
--- 677,704 ----
  
  	   Rejected: duplicate of R3b
  
+    R21: Where the communication relationship between a Middlebox and a
+         MIDCOM Agent becomes invalid, all existing Pin-Holes owned by
+         the MIDCOM Agent concerned MUST be closed.
+ 
+ 	   Really an imperfect subset of R23, which is accepted.
+ 
     R24: The protocol MUST provide per message acknowledgements, in order
          to achieve reliable communication.
  
  	   Rejected in favor of R25 with its rewording.
+ 
+    R26: The Midcom Protocol SHOULD allow a multiplicity of MIDCOM Agents
+         to concurrently interact with a given Middlebox.
+ 
+ 	   Rejected, duplicate of R3b.
+ 
+    R28: The protocol MUST support time-constrained operation to enable
+         scalability of the complete solution.  This may include, amongst
+         other things, the use of short messages and minimal messages per
+         operation.
+ 
+ 	   Rejected: too general.
  
     R36: At the end of a Midcom session between a Middlebox and Midcom
          Agent, it MUST be possible for either the Middlebox or the

--oUm6qI6fnHOrTLWp--


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 09:01:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18550
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 09:01:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05108;
	Mon, 13 Aug 2001 09:00:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05079
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 09:00:46 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18465
	for <midcom@ietf.org>; Mon, 13 Aug 2001 08:59:37 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7DCwPD25238
	for <midcom@ietf.org>; Mon, 13 Aug 2001 05:58:28 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-174.cisco.com [10.21.96.174])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJH07252;
	Mon, 13 Aug 2001 06:00:14 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 13 Aug 2001 09:00:14 -0400
Date: Mon, 13 Aug 2001 09:00:14 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] tentative revision of requirement bullets
Message-ID: <20010813090014.A632@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010813075048.B1560@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010813075048.B1560@SBRIM-W2K>; from sbrim@cisco.com on Mon, Aug 13, 2001 at 07:50:49AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is now available: <http://www.employees.org/~swb/midcom.html>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 10:55:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21430
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 10:55:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08060;
	Mon, 13 Aug 2001 10:54:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08032
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 10:54:43 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21413
	for <midcom@ietf.org>; Mon, 13 Aug 2001 10:53:32 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7DEqND09864
	for <midcom@ietf.org>; Mon, 13 Aug 2001 07:52:23 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp39.cisco.com [10.21.64.39])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACA00846;
	Mon, 13 Aug 2001 07:54:10 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010813104657.00a47cd0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Aug 2001 10:55:35 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Update
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Detailed minutes from Friday's meeting will be going out later this
week (many thanks to Cedric Aoun for volunteering to take notes), but
here's a brief list of some of the decisions/actions (please send
corrections where necessary):

1) The terminology discussion will be taken off the mailing list,
and a design team will bring something back to us in two weeks (by
24 August).  I didn't write down who's going to be managing the
terminology-wrangling (Doh!) - could that person step forward?

2) Jiri is going to work on text regarding "pinhole" ownership

3) There was consensus that we're talking about a client-server
protocol, not a peer<->peer protocol

4) Christian Huitema is going to be shepherding a design team to
describe filtering rules (5-tuples vs. what?)

5) The topology issue is a sticky one.  Ted Hardie proposed and
we agreed that the way we will be handling this is that proponents
of various ways of addressing the problem will write SHORT Internet
Drafts describing how they'd like to see this handled, and the
proposals will be reviewed by the working group AND the Transport
Area Directors.  Please get these to internet-drafts@ietf.org by
the end of August.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 12:16:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23582
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 12:16:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11783;
	Mon, 13 Aug 2001 12:15:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11754
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 12:15:51 -0400 (EDT)
Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23490
	for <midcom@ietf.org>; Mon, 13 Aug 2001 12:14:40 -0400 (EDT)
Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id JAA22088
	for <midcom@ietf.org>; Mon, 13 Aug 2001 09:15:00 -0700 (MST)
Received: from agcs.com ([130.131.56.106]) by pxmail1.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA4847;
          Mon, 13 Aug 2001 09:15:50 -0700
Message-ID: <3B77FD35.3C8EF617@agcs.com>
Date: Mon, 13 Aug 2001 09:15:49 -0700
From: "Brian Hagar" <hagarb@agcs.com>
Reply-To: hagarb@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pyda Srisuresh <srisuresh@yahoo.com>
CC: midcom@ietf.org
Subject: Re: [midcom] Summary of the informal gathering on thursday (08/09)
References: <20010810023122.61797.qmail@web13808.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Pyda,

What is the definition of an intrusive midcom agent mentioned below?

Brian

Pyda Srisuresh wrote:

> Folks,
>
> This is to make public the gist of the informal meeting that
> took place today (08/09) to collectively figure out what we need to
> do to make the framework draft through the last call. Thanks to Cedric
> Aoun for arranging the Thames suite for the meeting. I called in
> over the telephone to parttake in the conversation.
>
> 1. Melinda Stated that the objective is not to devoid the framework
>    draft of requirements or vice versa. But, it is important that the
>    stated or implied requirements be only those that are agreed upon
>    (rough consensus). Refer http://www.employees.org/~swb/midcom.html
>    for a list of implied requirements in the framework draft
>
> 2. Section 2.2: Add a couple of sentences describing
>    traditional Middleboxes that embed application intelligence,
>    MIDCOM supported middleboxes that externalize application
>    intelligence and middleboxes that embed application intelligence
>    for some applications and use MIDCOM support for others.
>
> 3. Section 2.3: No need to change the defintion of firewall.
>    Also, no need to replace the term firewall with "packet filtering".
>    Leave the reference to firewall as is.
>
> 4. Section 2.6: Change the first sentence as follows:
>    Application Level Gateways (ALGs) are entities that possess the
>    application specific intelligence and knowledge of an associated
>    middlebox function.
>
> 5. Section 2.8: Mark Duffy will propose new text to replace existing
>    text. There was concern about whether or not intrusive MIDCOM agents
>    (in the native path) should be considered In-Path agents.
>
> 6. Section 4.0 - Provide definition of what connection means for
>    the context of this document in the terminology section (section 2.0).
>    Connection is described to be a lasting association between a MIDCOM
>    agent and a middlebox and by no means is assumed to be any specific
>    transport layer protocol.
>
> 7. Section 6.0 - Paragraph 2 - Last sentence will read as follows.
>    In the context of MIDCOM framework, the Policy server does not
>    assist a middlebox in the implementation of the services it
>    provides.
>
> 8. Section 6.1 - Second paragraph end - Text on non-Repudiation.
>    Looks good. Should stay.
>
> 9. Section 6.2 - Provide definition for registration and deregistration
>    upfron in terminology section.
>
> 10. Section 6.2 - first paragraph - Replace the first paragraph as follows.
>
>    Prior to giving MIDCOM agents access to the middlebox resources,
>    a registration process MUST take place. Registration is a
>    different process than establishing a transport connection.
>    The former requires exchanging agent profile information with the
>    middlebox or policy server(s). Agent registration is often a
>    manual operation performed by an operator rather than the agent
>    itself. The transport connection refers to establishing a MIDCOM
>    transport connection and exchanging security credentials between
>    an agent and a middlebox. The transport connection uses the
>    registered information for connection establishment.
>
> Thats all I have. Thanks.
>
> regards,
> suresh
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 12:57:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24766
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 12:57:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13539;
	Mon, 13 Aug 2001 12:57:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13502
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 12:57:56 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24738
	for <midcom@ietf.org>; Mon, 13 Aug 2001 12:56:46 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA19734;
	Mon, 13 Aug 2001 18:57:56 +0200 (MET DST)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7DGvKw16024;
	Mon, 13 Aug 2001 18:57:21 +0200
Message-Id: <5.1.0.14.0.20010813162414.029beb70@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Aug 2001 16:49:10 +0200
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
In-Reply-To: <A7895B732354D311A4770008C791841A01314A6C@zsc4c014.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] RE: Expressiveness of Filtering Expression (was RE: [midcom]
 poli cy &  duration
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I do not think we are in agreement. Again, the value I see in Midcom is it allows for outsourcing 
applications out of routers. If we keep app patchwork in routers, there is little reason for midcom. 
The SIP example I gave before was indeed thought as a demonstration of bad idea.

I think Midcom was chartered to get apps through NATs/firewalls. Keeping things as simple
as possible is good. I welcome good proposals for extensibility model but I am very reluctant
to require too many protocol features unless the need for them is known.

-Jiri

At 10:40 AM 8/10/2001, Reinaldo Penno wrote:

>Jiri, 
>
>it seems we are almost in agreement. 
>
>I am not trying to change the MIDCOM protocol upside down. I just want to make the "rule" (I might get killed by using this word) extensible. If, for instance, GMD Fokus wants to write an informational draft proposing an extension of the 5 tuple where the it could signal the middlebox to do filtering based on SIP Messages, INVITEE name, via header, etc, it could. 
>
>I do not know how making the rule extensible could be such a headache. We are not changing the protocol, just the rule object.
>
>Now, as far as applications that are needed, for instance, URL filtering that I mentioned is an aplication per se. It is used today in several firewalls. The same goes for cookie filtering, etc. These are not extensions, they are applications used by customers/users. I need more than 5 tuple to signal that. 
>
>The same goes for overlapping IP address on the same PE router and SIP example above. 
>
>regards, 
>
>Reinaldo 


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 12:57:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24777
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 12:57:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13568;
	Mon, 13 Aug 2001 12:58:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13510
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 12:57:57 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24741
	for <midcom@ietf.org>; Mon, 13 Aug 2001 12:56:47 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA19737;
	Mon, 13 Aug 2001 18:57:57 +0200 (MET DST)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7DGvMw16027;
	Mon, 13 Aug 2001 18:57:22 +0200
Message-Id: <5.1.0.14.0.20010813164939.02a09ea8@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Aug 2001 17:26:16 +0200
To: Mark Duffy <mduffy@quarrytech.com>, Mark Duffy <mduffy@quarrytech.com>,
        lear@cisco.com, Scott Brim <sbrim@cisco.com>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <3.0.5.32.20010810065723.009265a0@email.quarrytech.com>
References: <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
 <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
 <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Mark,

I am still sceptic about agent's ability to figure out the direction.
In the example I gave before agents actually do not know. The only thing
a SIP proxy surely knows is destination address and port number of media. 
(It also might try to guess source IP address, though guessing might fail). 
So it might try to infer direction from the 5-tuple. Doing so is 
however not app-specific and might be done in middleboxes as well.

Consider the following example: two SIP phones which are registered with a company's
SIP server are temporarily in an external network. Which means there is no need
for pinholes at all if they want to speak to each other! Who will figure it out?
I doubt there is something useful for determining the direction what a SIP proxy knows 
a middlebox does not. A middlebox can be configured to guess which IP
addresses is external and which not. Doing the same in every agent 
is lot of work which is perhaps not needed.

This is where my doubts for use of interfaces come from. 

-Jiri

At 12:57 PM 8/10/2001, Mark Duffy wrote:
>In general, a mb has no idea what direction anything *wants* to go in.  All
>it does is open pinholes etc at the behest of agents.  If the agent, with
>the applic. intelligence, can't determine that, then probably no one can --
>maybe in that case the agent should just ask the mb for both directions.
>>From the point of view of the typical mb, a 5-tuple in one direction is
>completely different from the same 5-tuple in the opposite direction.  If
>the agent via the midcom protocol cannot express that difference, then the
>overall system is essentially dumbed-down to that level.  The result would
>be reduced security, if packets matching an n-tuple are permitted in either
>direction when in fact they should only be permitted in one.  I believe
>that would be an unacceptable reduction in security.
>
>-Mark
>
>At 05:37 PM 8/9/01 +0200, Jiri Kuthan wrote:
>>How does a, say SIP proxy, know what the direction of a media stream
>>belonging to a SIP session will be?
>>
>>-Jiri
>>
>>At 04:21 PM 8/8/2001, Mark Duffy wrote:
>>>>Also, I think we remove directionality at our peril.  In an
>>>>internal/external communication, the reversing of directional rules on
>>>>interfaces would lead to a weakening of enterprise security.
>>>
>>>Not only that, but the directionality is already an aspect of the existing
>>>firewall functionality we are providing control over.  I too believe
>>>directionality should be included.
>>
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>http://www1.ietf.org/mailman/listinfo/midcom 

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


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 13:20:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25379
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:20:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14346;
	Mon, 13 Aug 2001 13:19:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14282
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 13:19:05 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25328
	for <midcom@ietf.org>; Mon, 13 Aug 2001 13:17:55 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D98BB; Mon, 13 Aug 2001 13:18:35 -0400
Message-Id: <3.0.5.32.20010813131315.00917780@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 13 Aug 2001 13:13:15 -0400
To: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
In-Reply-To: <5.1.0.14.0.20010813070015.00a32240@mira-sjc5-4.cisco.com>
References: <3.0.5.32.20010810065723.009265a0@email.quarrytech.com>
 <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
 <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
 <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi Melinda,

Let me see if I understand what you have said.

I think we are in agreement that "interface" is an important component of
the classifier n-tuple.

I think you are saying that the humans running the show will know which
interface/direction but that it may be hard to get this knowledge into the
midcom agent and/or the mb.

I don't disgree with that, but I suggest the way to deal with it is to have
the operator provision the required information into the agent.  Presumably
the agent must somehow determine which middlebox it needs to talk to about
particular application flows.  This must be determined by some sort of
discovery (out of scope) or by provisioning the agent.  (In fact, how the
agent actually gets the knowledge should not be any concern of midcom!)

It seems to me that for the agent to know that a pinhole needs to be opened
up on a particular interface of a multi-port mb, is not materially
different than just knowing which 2-port mb to use.

-Mark

P.S. I also believe that "interface" should actually be generalized to
"realm" and that direction should also be included, but those points are
somewhat unimportant to the discussion at hand.


At 07:08 AM 8/13/01 -0400, Melinda Shore wrote:
>At 06:57 AM 8/10/01 -0400, Mark Duffy wrote:
>>In general, a mb has no idea what direction anything *wants* to go in.  All
>>it does is open pinholes etc at the behest of agents.  If the agent, with
>>the applic. intelligence, can't determine that, then probably no one can --
>
>That's not really true.
>
>*Clearly* the semantics of a filtering rule are going to be different
>when applied to one interface from what they'll be when applied to
>another.  The problem is how/whether to bring that information out to an 
>application.  I think it's a mistake to assume that software can be
>as smart as the network administrator who sits down to manually configure
>the box, or that somehow having the agent know the network topology and
>the contents of the routing table is equivalent to having a human scribble
>the same information on a piece of paper.
>
>It seems to me that the problem here is how to convey the necessary
>information to the middlebox that will allow the middlebox to apply
>the rules to the correct interface without forcing the agent to become
>a participant in the routing system.
>
>Melinda
>
>

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 13:27:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25503
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:27:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14340;
	Mon, 13 Aug 2001 13:19:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14280
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 13:19:04 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25327
	for <midcom@ietf.org>; Mon, 13 Aug 2001 13:17:55 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D98A0; Mon, 13 Aug 2001 13:18:35 -0400
Message-Id: <3.0.5.32.20010813121728.0091a430@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 13 Aug 2001 12:17:28 -0400
To: Scott Brim <sbrim@cisco.com>, midcom mail-list <midcom@ietf.org>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
In-Reply-To: <20010811223138.D500@SBRIM-W2K>
References: <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
 <002b01c11f3e$12a32640$b89221d9@acmepacket.com>
 <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi Scott, see below ...

At 10:31 PM 8/11/01 +0100, Scott Brim wrote:
...
>> Relative to Bob's 7 Aug msg re "resource (p.k.a. pin-hole) operations"
>> which proposes additional operations such as create and delete, I would
>> suggest there should be operations to add/delete ruleset-descriptors and
>> ruleset-actions to rulesets.
>
>I think an action is meaningless without a descriptor, and don't see any
>benefit in making it possible for an agent to say "install this
>descriptor please" with no associated actions.  I suggest that every
>request must include the complete descriptor it relates to, but can
>add/delete actions.

Yes, Bob Penfield had the same reaction and I told him I agreed ...   The
original point I intended to make was that the agent should be able to
manipulate the descriptor and actions independently, to whatever extent
that make sense.  I think add/delete actions to an existing descriptor
covers it just fine.



>> I do agree we also need the concept resource-bundle (or ruleset-bundle or
>> foobar-bundle).
>
>Is this more than a descriptor that matches an aggregate?  Do you want
>the middlebox to maintain lists of unrelated rulesets?  As you saw in
>previous mail I'm uncomfortable with that because I don't think it helps
>the agent appropriately, and burdens the middlebox in new ways.

I see it as a useful but certainly not essential feature of the protocol
that the agent can identify to the mb that multiple pinholes belong to a
grouping such that the agent can then operate on them in bulk, say, delete
them all at once.  Presumably the agent posesses some application
intelligence that these pinholes bear some relationship to one another.  

Whether we require such a feature in the protocol should perhaps be one of
the discussion items.  I don't recall who if anyone asked for it.  The
recent discussion seesm to have originated with Bob Penfield proposing a
term for referring to this concept.

-Mark


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 13:41:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25830
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:41:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15064;
	Mon, 13 Aug 2001 13:40:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15035
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 13:40:31 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25770
	for <midcom@ietf.org>; Mon, 13 Aug 2001 13:39:21 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7DHeJT03955;
	Mon, 13 Aug 2001 10:40:19 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp39.cisco.com [10.21.64.39])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACD00809;
	Mon, 13 Aug 2001 10:39:59 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010813133703.009f9800@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Aug 2001 13:41:20 -0400
To: Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] policy & duration
In-Reply-To: <3.0.5.32.20010813131315.00917780@email.quarrytech.com>
References: <5.1.0.14.0.20010813070015.00a32240@mira-sjc5-4.cisco.com>
 <3.0.5.32.20010810065723.009265a0@email.quarrytech.com>
 <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
 <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
 <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 01:13 PM 8/13/01 -0400, Mark Duffy wrote:
>I think we are in agreement that "interface" is an important component of
>the classifier n-tuple.

I don't think that I'd agree with that.  I agree that "interface"
is an important (indeed, necessary) component of the routing/filtering 
rules on the middlebox, which isn't the same thing.

This is a difficult problem and there's great potential here for us to
do something very, very wrong.  I don't see any easy answers, myself,
and I'm looking forward to seeing what people come up with in their
various proposals to address this problem.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 13:49:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25973
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:49:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15296;
	Mon, 13 Aug 2001 13:48:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15263
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 13:48:20 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25943
	for <midcom@ietf.org>; Mon, 13 Aug 2001 13:47:09 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7DHm1n25668
	for <midcom@ietf.org>; Mon, 13 Aug 2001 10:48:01 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-174.cisco.com [10.21.96.174])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJI02996;
	Mon, 13 Aug 2001 10:47:49 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 13 Aug 2001 13:47:48 -0400
Date: Mon, 13 Aug 2001 13:47:47 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom mail-list <midcom@ietf.org>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Message-ID: <20010813134747.J632@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	midcom mail-list <midcom@ietf.org>
References: <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com> <002b01c11f3e$12a32640$b89221d9@acmepacket.com> <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com> <20010811223138.D500@SBRIM-W2K> <3.0.5.32.20010813121728.0091a430@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.5.32.20010813121728.0091a430@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Aug 13, 2001 at 12:17:28PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Mon, Aug 13, 2001 at 12:17:28PM -0400, Mark Duffy apparently wrote:
> >> I do agree we also need the concept resource-bundle (or ruleset-bundle or
> >> foobar-bundle).
> >
> >Is this more than a descriptor that matches an aggregate?  Do you want
> >the middlebox to maintain lists of unrelated rulesets?  As you saw in
> >previous mail I'm uncomfortable with that because I don't think it helps
> >the agent appropriately, and burdens the middlebox in new ways.
> 
> I see it as a useful but certainly not essential feature of the protocol
> that the agent can identify to the mb that multiple pinholes belong to a
> grouping such that the agent can then operate on them in bulk, say, delete
> them all at once.  Presumably the agent posesses some application
> intelligence that these pinholes bear some relationship to one another.  
> 
> Whether we require such a feature in the protocol should perhaps be one of
> the discussion items.  I don't recall who if anyone asked for it.  The
> recent discussion seesm to have originated with Bob Penfield proposing a
> term for referring to this concept.

I'd like to hear people's requirements for atomic execution and how
flexible it needs to be.  For example, does the agent need to be able to
say "please create this and delete that" in such a way that if the first
doesn't happen the second must not either?  Is an aggregate delete
request, with the possibility of mixed results, satisfactory?

On the other hand it would also be good to limit discussion to just a
few requirements at a time (nudge nudge).


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 13:50:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26003
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:50:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15214;
	Mon, 13 Aug 2001 13:45:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15183
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 13:45:19 -0400 (EDT)
Received: from exchange_03.2wire.com (gateway.2wire.com [63.203.253.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25891
	for <midcom@ietf.org>; Mon, 13 Aug 2001 13:44:09 -0400 (EDT)
Received: by exchange_03.2wire.com with Internet Mail Service (5.5.2653.19)
	id <QW9MHSDG>; Mon, 13 Aug 2001 10:49:19 -0700
Message-ID: <629F94188789D5119577009027E79125214FF6@exchange_03.2wire.com>
From: Randy Turner <rturner@2wire.com>
To: "'midcom mail-list '" <midcom@ietf.org>
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!
Date: Mon, 13 Aug 2001 10:49:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

 
I think the idea of a session bundle (a logical association of multiple
sessions or pinholes) is needed to express the sophisticated requirements of
certain agents. It could also be used by MBs to optimize resource
reclamation when the state of a particular session or session-related state
becomes invalid, and by association, the MB can cleanup the bundle as well,
since there would be an implied coupling of all resources related to a
bundle.  There could be exceptions where the entire bundle cleanup might not
be what the agent wants, but this could be handled by the agent not included
certain sessions/pinholes in a bundle.

Randy

-----Original Message-----
From: Mark Duffy
To: Scott Brim; midcom mail-list
Sent: 8/13/01 9:17 AM
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!

Hi Scott, see below ...

At 10:31 PM 8/11/01 +0100, Scott Brim wrote:
...
>> Relative to Bob's 7 Aug msg re "resource (p.k.a. pin-hole)
operations"
>> which proposes additional operations such as create and delete, I
would
>> suggest there should be operations to add/delete ruleset-descriptors
and
>> ruleset-actions to rulesets.
>
>I think an action is meaningless without a descriptor, and don't see
any
>benefit in making it possible for an agent to say "install this
>descriptor please" with no associated actions.  I suggest that every
>request must include the complete descriptor it relates to, but can
>add/delete actions.

Yes, Bob Penfield had the same reaction and I told him I agreed ...
The
original point I intended to make was that the agent should be able to
manipulate the descriptor and actions independently, to whatever extent
that make sense.  I think add/delete actions to an existing descriptor
covers it just fine.



>> I do agree we also need the concept resource-bundle (or
ruleset-bundle or
>> foobar-bundle).
>
>Is this more than a descriptor that matches an aggregate?  Do you want
>the middlebox to maintain lists of unrelated rulesets?  As you saw in
>previous mail I'm uncomfortable with that because I don't think it
helps
>the agent appropriately, and burdens the middlebox in new ways.

I see it as a useful but certainly not essential feature of the protocol
that the agent can identify to the mb that multiple pinholes belong to a
grouping such that the agent can then operate on them in bulk, say,
delete
them all at once.  Presumably the agent posesses some application
intelligence that these pinholes bear some relationship to one another.


Whether we require such a feature in the protocol should perhaps be one
of
the discussion items.  I don't recall who if anyone asked for it.  The
recent discussion seesm to have originated with Bob Penfield proposing a
term for referring to this concept.

-Mark


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 13:51:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26039
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:51:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15355;
	Mon, 13 Aug 2001 13:50:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15326
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 13:50:38 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25968
	for <midcom@ietf.org>; Mon, 13 Aug 2001 13:49:27 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D981G; Mon, 13 Aug 2001 13:50:08 -0400
Message-Id: <3.0.5.32.20010813134926.0091a750@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 13 Aug 2001 13:49:26 -0400
To: Jiri Kuthan <kuthan@fokus.gmd.de>, lear@cisco.com,
        Scott Brim <sbrim@cisco.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <5.1.0.14.0.20010813164939.02a09ea8@mailhub.fokus.gmd.de>
References: <3.0.5.32.20010810065723.009265a0@email.quarrytech.com>
 <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
 <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
 <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi Jiri,

I would refer you to my response sent  just a few minutes ago to Melinda's
question on this same thread.  I believe that knowing the
realm/interface/direction for the pinhole is just a minor detail of the
larger problem of knowing which middlebox to go to.  I guess the whole
topology thing is a bit of an open issue at the moment.  But it seems clear
to me that the agent must somehow determine which mb to go to.  Whether it
is through discovery, provisioning, or default (only having 1 mb to deal
with), I would venture it is the problem of the agent.

Middleboxes dealing with NAT and/or VPNs are typically dealing with
overlapping (non unique) address spaces and therefore cannot necessarily
determine 'where' particular IP addresses lie.

-Mark


At 05:26 PM 8/13/01 +0200, Jiri Kuthan wrote:
>Mark,
>
>I am still sceptic about agent's ability to figure out the direction.
>In the example I gave before agents actually do not know. The only thing
>a SIP proxy surely knows is destination address and port number of media. 
>(It also might try to guess source IP address, though guessing might fail). 
>So it might try to infer direction from the 5-tuple. Doing so is 
>however not app-specific and might be done in middleboxes as well.
>
>Consider the following example: two SIP phones which are registered with a
company's
>SIP server are temporarily in an external network. Which means there is no
need
>for pinholes at all if they want to speak to each other! Who will figure
it out?
>I doubt there is something useful for determining the direction what a SIP
proxy knows 
>a middlebox does not. A middlebox can be configured to guess which IP
>addresses is external and which not. Doing the same in every agent 
>is lot of work which is perhaps not needed.
>
>This is where my doubts for use of interfaces come from. 
>
>-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 13:51:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26051
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:51:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15434;
	Mon, 13 Aug 2001 13:52:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15403
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 13:52:03 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26024
	for <midcom@ietf.org>; Mon, 13 Aug 2001 13:50:52 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7DHndD19031
	for <midcom@ietf.org>; Mon, 13 Aug 2001 10:49:43 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-174.cisco.com [10.21.96.174])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJI03068;
	Mon, 13 Aug 2001 10:51:28 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 13 Aug 2001 13:51:26 -0400
Date: Mon, 13 Aug 2001 13:51:26 -0400
From: Scott Brim <sbrim@cisco.com>
To: "'midcom mail-list '" <midcom@ietf.org>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Message-ID: <20010813135126.K632@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	'midcom mail-list ' <midcom@ietf.org>
References: <629F94188789D5119577009027E79125214FF6@exchange_03.2wire.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <629F94188789D5119577009027E79125214FF6@exchange_03.2wire.com>; from rturner@2wire.com on Mon, Aug 13, 2001 at 10:49:09AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Mon, Aug 13, 2001 at 10:49:09AM -0700, Randy Turner apparently wrote:
> I think the idea of a session bundle (a logical association of multiple
> sessions or pinholes) is needed to express the sophisticated requirements of
> certain agents. 

Could you be more specific, and/or give an example?


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 14:44:17 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26928
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 14:44:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17339;
	Mon, 13 Aug 2001 14:43:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17311
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 14:43:40 -0400 (EDT)
Received: from exchange_03.2wire.com (gateway.2wire.com [63.203.253.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26900
	for <midcom@ietf.org>; Mon, 13 Aug 2001 14:42:29 -0400 (EDT)
Received: by exchange_03.2wire.com with Internet Mail Service (5.5.2653.19)
	id <QW9MHSFL>; Mon, 13 Aug 2001 11:48:00 -0700
Message-ID: <629F94188789D5119577009027E79125214FF7@exchange_03.2wire.com>
From: Randy Turner <rturner@2wire.com>
To: "''midcom mail-list ' '" <midcom@ietf.org>
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!
Date: Mon, 13 Aug 2001 11:47:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

 I was specifically thinking about something like an H323 ALG/agent, that
would have to express the relationship between multiple flows for a
particular session being negotiated. The same could apply to SIP I would
imagine.  It would be nice if an agent could "aggregate" control information
across the MIDCOM protocol. The more individual streams that make up an
application "session", the more valuable the aggregate control over the app
session would be. Regarding resource reclamation, it might be nice to have
the MB "cleanup" a bundle in which one of the streams (probably a control
connection) is closed. If the MB does not have enough app intelligence to
determine whether or not "all" pinholes should be closed, then it could just
notify the agent, and the agent could close out the "bundle" with one
protocol operation.

These are just off the top of my head, but my experience with H323 and NAT
seemed to indicate that this functionality might be a good idea.

Randy

-----Original Message-----
From: Scott Brim
To: 'midcom mail-list '
Sent: 8/13/01 10:51 AM
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!

On Mon, Aug 13, 2001 at 10:49:09AM -0700, Randy Turner apparently wrote:
> I think the idea of a session bundle (a logical association of
multiple
> sessions or pinholes) is needed to express the sophisticated
requirements of
> certain agents. 

Could you be more specific, and/or give an example?


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 15:12:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27300
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 15:12:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17823;
	Mon, 13 Aug 2001 15:11:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17795
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 15:11:51 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27283
	for <midcom@ietf.org>; Mon, 13 Aug 2001 15:10:40 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 216348157
	for <midcom@ietf.org>; Mon, 13 Aug 2001 14:11:52 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id OAA04797
	for <midcom@ietf.org>; Mon, 13 Aug 2001 14:11:51 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Mon, 13 Aug 2001 14:11:51 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
In-Reply-To: <3.0.5.32.20010813134926.0091a750@email.quarrytech.com>
Message-ID: <Pine.GSO.4.21.0108131411290.4704-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


On Mon, 13 Aug 2001, Jiri Kuthan wrote:

> Mark,
> 
> Consider the following example: two SIP phones which are registered with a company's
> SIP server are temporarily in an external network. Which means there is no need
> for pinholes at all if they want to speak to each other! Who will figure it out?
> I doubt there is something useful for determining the direction what a SIP proxy knows 
> a middlebox does not. A middlebox can be configured to guess which IP
> addresses is external and which not. Doing the same in every agent 
> is lot of work which is perhaps not needed.

	A SIP proxy is as well positioned as anything to figure out
which phone is where. In the simple case, an enterprise (think IP PBX)
SIP proxy can determine with relative ease that:

	- phone A is inside the enterprise
	- phone B is not
	- therefore pinholes from the outside to the inside so and so
	  are needed, and pinholes from the inside to the outside thus
	  and such are needed.

	There are also techniques which allow a SIP proxy, in conjunction
with a set of middleboxes, to steer traffic along desired paths.

	A SIP proxy by its very nature is capable of understanding, at
some coarse level, 'where endpoints live.' With a little additional
configuration information, and corresponding restrictions in network
topology, the SIP proxy may accurately determine which middleboxes
need to be managed, and what directions through them the traffic will
take.

	At the end of the day, figuring out which direction traffic will
take through a middlebox will fall out of the task of determining which
middleboxes need to be managed for a particular call. The Agent, in
general, MUST solve this latter problem, so the former problem is
sort of a non-issue.

	Just to drive home the point: a MIDCOM Agent MUST know something
about network topology to function at all. In many cases, it need not know
more than 'these addresses are inside, everything else is outside' but
it MUST know something. Even a standard firewall needs to know as much,
and for essentially the same reasons.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 15:20:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27392
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 15:20:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17970;
	Mon, 13 Aug 2001 15:20:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17890
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 15:20:16 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27368
	for <midcom@ietf.org>; Mon, 13 Aug 2001 15:19:05 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7DJJoQ11416
	for <midcom@ietf.org>; Mon, 13 Aug 2001 12:19:50 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp39.cisco.com [10.21.64.39])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACF00333;
	Mon, 13 Aug 2001 12:19:43 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010813151742.00a02a10@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Aug 2001 15:21:01 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] tentative revision of requirement bullets
In-Reply-To: <20010813075048.B1560@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 07:50 AM 8/13/01 -0400, Scott Brim wrote:
>I have created a new version of the requirements bullets. 

The list that Scott's maintaining is how we get from here through 
WG last call and eventually to publication.  *Please* take a good
look at it, particularly Sections 3 and forward, and over the next
few weeks we'll be working through the list of bulleted items,
gradually moving them into the "Requirements agreed upon by the 
working group" section (Section 2).

Melinda





_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 16:39:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28334
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 16:39:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19886;
	Mon, 13 Aug 2001 16:38:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19860
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 16:38:20 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28317
	for <midcom@ietf.org>; Mon, 13 Aug 2001 16:37:10 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id A112F8192
	for <midcom@ietf.org>; Mon, 13 Aug 2001 15:38:18 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id PAA09511
	for <midcom@ietf.org>; Mon, 13 Aug 2001 15:38:18 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Mon, 13 Aug 2001 15:38:17 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
In-Reply-To: <20010813134747.J632@SBRIM-W2K>
Message-ID: <Pine.GSO.4.21.0108131412200.4704-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Mon, 13 Aug 2001, Scott Brim wrote:
> I'd like to hear people's requirements for atomic execution and how
> flexible it needs to be.  For example, does the agent need to be able to
> say "please create this and delete that" in such a way that if the first
> doesn't happen the second must not either?  Is an aggregate delete
> request, with the possibility of mixed results, satisfactory?

	I think it's necessary to do a set of policy "adds" or "creates"
which either succeed or fail together. I think it's also necessary to
be able to delete an aggregate the same way.

	It's not at all obvious to me that it's neccessary to handle adds
and deletes within the same atomic transaction.

	It's also not obvious to me that this makes implementation
any easier, but if it does for someone -- great!

	There are probably many operations which can be handled
non-atomically. Only operations which affect the actual handling
of data traffic passing through the middlebox really need the
atomic-transaction-bundle concept. Even deletes don't really need
a bundle of operations, at the MIDCOM protocol level, a single
operation 'delete all the stuff with this ID atomically' would
probably suffice.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 17:10:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28710
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 17:10:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20638;
	Mon, 13 Aug 2001 17:08:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20610
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 17:08:05 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28691
	for <midcom@ietf.org>; Mon, 13 Aug 2001 17:06:55 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id OAA11755;
	Mon, 13 Aug 2001 14:07:57 -0700 (PDT)
Message-Id: <200108132107.OAA11755@nemo.corp.equinix.com>
Subject: Re: [midcom] policy & duration
To: amolitor@visi.com (Andrew Molitor)
Date: Mon, 13 Aug 2001 14:07:57 -0700 (PDT)
Cc: midcom@ietf.org
In-Reply-To: <Pine.GSO.4.21.0108131411290.4704-100000@isis.visi.com> from "Andrew Molitor" at Aug 13, 2001 02:11:51 PM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Andrew writes: 
> 	Just to drive home the point: a MIDCOM Agent MUST know something
> about network topology to function at all. In many cases, it need not know
> more than 'these addresses are inside, everything else is outside' but
> it MUST know something. Even a standard firewall needs to know as much,
> and for essentially the same reasons.
> 

	I don't think this is quite right, and I think it is important
to get it right.  I'm also still a bit muddle-headed from my flights
back from London, so please understand that this is probably the first
of a series of efforts to get it right, rather than a correct formulation.

NATs manage the exchange of traffic between address realms.

Firewalls manage the exchange of traffic between trust realms.

Historically, realms map onto a network topology, but this is a
function of how they have been implemented and deployed and is not
their essential function.
	
	I think we need to describe the MIDCOM Agent's behavior in
terms of the address and trust realms, rather than in terms of the
network topology onto which those map.  That seem to me to get us
moving to a protocol that will leave routing to the routing systems,
because it won't have built in assumptions about the mapping between
topology and realm.

	I understand that this leaves out the question of how the
mapping between topology and realm occurs, but I think that (very
hard) problem has been ruled out of scope for the group.  I also
suspect that if we discipline ourselves to talk in terms of realm
rather than topology that we are more likely to less to further
hinder the discover problem with assumptions built into the MIDCOM
agents.

			regards,
				Ted Hardie


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 17:34:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29076
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 17:34:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21483;
	Mon, 13 Aug 2001 17:31:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21456
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 17:31:31 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29046
	for <midcom@ietf.org>; Mon, 13 Aug 2001 17:30:16 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA18451;
        Mon, 13 Aug 2001 17:31:25 -0400 (EDT)
Message-Id: <200108132131.RAA18451@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: hardie@equinix.com
cc: amolitor@visi.com (Andrew Molitor), midcom@ietf.org
Subject: Re: [midcom] policy & duration 
In-reply-to: Your message of "Mon, 13 Aug 2001 14:07:57 PDT."
             <200108132107.OAA11755@nemo.corp.equinix.com> 
Date: Mon, 13 Aug 2001 17:31:25 -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

> NATs manage the exchange of traffic between address realms.
> 
> Firewalls manage the exchange of traffic between trust realms.
> 
> Historically, realms map onto a network topology, but this is a
> function of how they have been implemented and deployed and is not
> their essential function.
> 
>         I think we need to describe the MIDCOM Agent's behavior in
> terms of the address and trust realms, rather than in terms of the
> network topology onto which those map. 

I'm very much in agreement with Ted on this.  

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 18:10:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29497
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 18:10:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22282;
	Mon, 13 Aug 2001 18:10:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22255
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 18:10:10 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29483
	for <midcom@ietf.org>; Mon, 13 Aug 2001 18:08:58 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7DM8pJ05625;
	Mon, 13 Aug 2001 17:08:51 -0500
From: "Ram Dantu" <ramd@netrake.com>
To: <hardie@equinix.com>, "Andrew Molitor" <amolitor@visi.com>
Cc: <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Mon, 13 Aug 2001 17:08:51 -0500
Message-ID: <AEEDLFNKBFAGGEGOFBPIMEMGCBAA.ramd@netrake.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <200108132107.OAA11755@nemo.corp.equinix.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I understand you do not like the MIDCOM Agent
knowing the network topology. If we do not want
to embed the application-specific knowledge in the
middle box, can you give an example how you think
agent can set the direction ? (using the realm scenario).

For information, I asked the question in the MIDCOM WG meeting
if the discovery is part of the MIDCOM charter,
the answer was NO.

On the other hand, the network topology updates
between Agent and Middlebox may get into more
complex/messy situations.


Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
hardie@equinix.com
Sent: Monday, August 13, 2001 4:08 PM
To: Andrew Molitor
Cc: midcom@ietf.org
Subject: Re: [midcom] policy & duration


Andrew writes:
> 	Just to drive home the point: a MIDCOM Agent MUST know something
> about network topology to function at all. In many cases, it need not know
> more than 'these addresses are inside, everything else is outside' but
> it MUST know something. Even a standard firewall needs to know as much,
> and for essentially the same reasons.
>

	I don't think this is quite right, and I think it is important
to get it right.  I'm also still a bit muddle-headed from my flights
back from London, so please understand that this is probably the first
of a series of efforts to get it right, rather than a correct formulation.

NATs manage the exchange of traffic between address realms.

Firewalls manage the exchange of traffic between trust realms.

Historically, realms map onto a network topology, but this is a
function of how they have been implemented and deployed and is not
their essential function.

	I think we need to describe the MIDCOM Agent's behavior in
terms of the address and trust realms, rather than in terms of the
network topology onto which those map.  That seem to me to get us
moving to a protocol that will leave routing to the routing systems,
because it won't have built in assumptions about the mapping between
topology and realm.

	I understand that this leaves out the question of how the
mapping between topology and realm occurs, but I think that (very
hard) problem has been ruled out of scope for the group.  I also
suspect that if we discipline ourselves to talk in terms of realm
rather than topology that we are more likely to less to further
hinder the discover problem with assumptions built into the MIDCOM
agents.

			regards,
				Ted Hardie


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 22:27:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02915
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 22:27:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26239;
	Mon, 13 Aug 2001 22:26:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26208
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 22:26:36 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02906
	for <midcom@ietf.org>; Mon, 13 Aug 2001 22:25:24 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id ACF2D81A3
	for <midcom@ietf.org>; Mon, 13 Aug 2001 21:26:36 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id VAA26087
	for <midcom@ietf.org>; Mon, 13 Aug 2001 21:26:36 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Mon, 13 Aug 2001 21:26:36 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration 
In-Reply-To: <200108132131.RAA18451@astro.cs.utk.edu>
Message-ID: <Pine.GSO.4.21.0108132124370.25982-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Mon, 13 Aug 2001, Keith Moore wrote:

> > NATs manage the exchange of traffic between address realms.
> > 
> > Firewalls manage the exchange of traffic between trust realms.
> > 
> > Historically, realms map onto a network topology, but this is a
> > function of how they have been implemented and deployed and is not
> > their essential function.
> > 
> >         I think we need to describe the MIDCOM Agent's behavior in
> > terms of the address and trust realms, rather than in terms of the
> > network topology onto which those map. 
> 
> I'm very much in agreement with Ted on this.  

	I agree as well, of course. This was made clear when I spoke
of 'inside versus outside' being an example of a perfectly adequate
notion of network topology in some cases, right? The attentive observer
has probably noticed that I am not one to pick nits.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 23:08:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04441
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 23:08:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27267;
	Mon, 13 Aug 2001 23:04:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27241
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 23:04:04 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04416
	for <midcom@ietf.org>; Mon, 13 Aug 2001 23:02:53 -0400 (EDT)
Received: from MDUFFY ([10.1.1.16]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D99A9; Mon, 13 Aug 2001 23:03:33 -0400
Message-Id: <3.0.5.32.20010813225838.00868ad0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 13 Aug 2001 22:58:38 -0400
To: hardie@equinix.com, amolitor@visi.com (Andrew Molitor)
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <200108132107.OAA11755@nemo.corp.equinix.com>
References: <Pine.GSO.4.21.0108131411290.4704-100000@isis.visi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is really interesting.  Wouldn't it be fair to say that realms are
interconnected in a toplology of their own?  (At a higher layer than the IP
network topology.)  And that frequently, middleboxes such as firewalls and
NATs appear at the realm interconnection points?  Not only that but these
middleboxes generally operate on behalf of one of the realms at a
connection point, not both (thus there is an "in"side and an "out"side.
And perhaps the good news about all this is that maybe midcom can get
pretty far without understanding the overall topology of all the realms,
but just the agent statically knowing for each middlebox (or each realm
served by a multipoint mb) which side is in and which is out.

Of course, for agents that are not "near" one specific middlebox this
doesn't help the agent to know which mb a given traffic flow needs to go
through (as function of IP routing)...



At 02:07 PM 8/13/01 -0700, hardie@equinix.com wrote:
>Andrew writes: 
>> 	Just to drive home the point: a MIDCOM Agent MUST know something
>> about network topology to function at all. In many cases, it need not know
>> more than 'these addresses are inside, everything else is outside' but
>> it MUST know something. Even a standard firewall needs to know as much,
>> and for essentially the same reasons.
>> 
>
>	I don't think this is quite right, and I think it is important
>to get it right.  I'm also still a bit muddle-headed from my flights
>back from London, so please understand that this is probably the first
>of a series of efforts to get it right, rather than a correct formulation.
>
>NATs manage the exchange of traffic between address realms.
>
>Firewalls manage the exchange of traffic between trust realms.
>
>Historically, realms map onto a network topology, but this is a
>function of how they have been implemented and deployed and is not
>their essential function.
>	
>	I think we need to describe the MIDCOM Agent's behavior in
>terms of the address and trust realms, rather than in terms of the
>network topology onto which those map.  That seem to me to get us
>moving to a protocol that will leave routing to the routing systems,
>because it won't have built in assumptions about the mapping between
>topology and realm.
>
>	I understand that this leaves out the question of how the
>mapping between topology and realm occurs, but I think that (very
>hard) problem has been ruled out of scope for the group.  I also
>suspect that if we discipline ourselves to talk in terms of realm
>rather than topology that we are more likely to less to further
>hinder the discover problem with assumptions built into the MIDCOM
>agents.
>
>			regards,
>				Ted Hardie
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 23:14:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04476
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 23:14:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27411;
	Mon, 13 Aug 2001 23:15:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27380
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 23:14:59 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04471
	for <midcom@ietf.org>; Mon, 13 Aug 2001 23:13:47 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id DE946814E
	for <midcom@ietf.org>; Mon, 13 Aug 2001 22:14:59 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id WAA28026
	for <midcom@ietf.org>; Mon, 13 Aug 2001 22:14:59 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Mon, 13 Aug 2001 22:14:59 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
In-Reply-To: <3.0.5.32.20010813225838.00868ad0@email.quarrytech.com>
Message-ID: <Pine.GSO.4.21.0108132209510.27696-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Mon, 13 Aug 2001, Mark Duffy wrote:

> This is really interesting.  Wouldn't it be fair to say that realms are
> interconnected in a toplology of their own?  (At a higher layer than the IP
> network topology.)  And that frequently, middleboxes such as firewalls and
> NATs appear at the realm interconnection points?  Not only that but these
> middleboxes generally operate on behalf of one of the realms at a
> connection point, not both (thus there is an "in"side and an "out"side.
> And perhaps the good news about all this is that maybe midcom can get
> pretty far without understanding the overall topology of all the realms,
> but just the agent statically knowing for each middlebox (or each realm
> served by a multipoint mb) which side is in and which is out.

	This is all absolutely and 100 percent correct. One winds
up carving the world up into some small set of blobs interconnected
by the middleboxes nearby, and using that as a "sufficiently good"
definition of network topology. This is exactly like firewall
configuration. A "blob" might as well be defined as:

	- an arbitrary set of IP addresses explicitly called out
	- all the IP addresses not in any other set ("the world")

	Well, I agree 100 percent with ALMOST all of the above. It's
actually not very interesting ;) I can't imagine anyone thinks a
middlebox needs to know any more than an "administrative view" of
the network tolopogy.

	Is there anyone who thinks more detailed topology than I
have described above needs to be known by the Agent?

	Is there anyone who thinks that an Agent should not even know
this much?

		Andrew


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 13 23:15:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04498
	for <midcom-archive@odin.ietf.org>; Mon, 13 Aug 2001 23:15:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27463;
	Mon, 13 Aug 2001 23:16:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27435
	for <midcom@ns.ietf.org>; Mon, 13 Aug 2001 23:15:58 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04487
	for <midcom@ietf.org>; Mon, 13 Aug 2001 23:14:47 -0400 (EDT)
Received: from MDUFFY ([10.1.1.16]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D99BG; Mon, 13 Aug 2001 23:15:28 -0400
Message-Id: <3.0.5.32.20010813231445.007d0700@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 13 Aug 2001 23:14:45 -0400
To: Pyda Srisuresh <srisuresh@yahoo.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
In-Reply-To: <20010810023122.61797.qmail@web13808.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] proposed text for framework sect. 2.8
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

>5. Section 2.8: Mark Duffy will propose new text to replace existing 
>   text. There was concern about whether or not intrusive MIDCOM agents
>   (in the native path) should be considered In-Path agents. 

Here is the proposed text:

2.8. MIDCOM Agents

MIDCOM agents are entities performing ALG functions, logically external to a middlebox. MIDCOM agents possess a combination of application awareness and knowledge of the middlebox function, which combination enables the agents to facilitate traversal of the middlebox by the application's packets. A MIDCOM agent may interact with one or more middleboxes.

Only "In-Path MIDCOM agents" are considered in this document. In-Path Midcom agents are agents which are within the path of those datagrams that the agent needs to examine and/or modify in fulfilling its role as a MIDCOM agent. "Within the path" here simply means that the packets in question flow through the node that hosts the agent.  The packets may be addressed to the agent node at the IP layer.  Alternatively they may not be addressed to the agent node but may be constrained by other factors to flow through it. In fact, it is immaterial to the MIDCOM protocol which of these is the case. Some examples of In-Path MIDCOM agents are application proxies, gateways, or even end-hosts that are party to the application. 

Agents not resident on nodes that are within the path of their relevant application flows are refered to as "Out-of-Path (OOP) MIDCOM agents" and are out of scope of this document.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 02:16:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22697
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 02:16:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09708;
	Tue, 14 Aug 2001 02:13:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09681
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 02:13:53 -0400 (EDT)
Received: from pallas.host4u.net (pallas.host4u.net [216.71.64.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22655
	for <midcom@ietf.org>; Tue, 14 Aug 2001 02:12:43 -0400 (EDT)
Received: from C1380748B (c1380748-b.snvl1.sfba.home.com [65.11.102.112])
	by pallas.host4u.net (8.8.5/8.8.5) with SMTP id BAA16995
	for <midcom@ietf.org>; Tue, 14 Aug 2001 01:11:31 -0500
From: "Shai Mohaban" <shai@kagoor.com>
To: <midcom@ietf.org>
Date: Mon, 13 Aug 2001 23:10:15 -0700
Message-ID: <NBBBKGLPAACDDACNPCCMMEDOIFAA.shai@kagoor.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 7bit
Subject: [midcom] Ownership and state requirements
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

There seem to be a couple of requirements on Scott's list which still go
well into implementation details. I am specifically talking about some of
the requirements dealing with ownership and states including R5
(ownership/reference counter), R3b (multiple agents manipulating the same
middlebox resource), R59 (ownership transfer), R79 (sounds like R3b...), and
possibly others.

Correct me if I am wrong but the main goal of these requirements is to allow
for a failover between multiple MidCom agents for sessions which are already
in place. In that case we want the backup MidCom agent to be able to
continue the current services to go on uninterrupted, and eventually
terminated, without compromising security.
So if that is the case wouldn't it be better to have one generic requirement
just for that ("supporting failover...") instead of getting into all those
implementation details in the requirements draft, and leave the actual
implementation to the protocol draft TBD?



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 05:30:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24753
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 05:30:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14204;
	Tue, 14 Aug 2001 05:29:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14171
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 05:29:28 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24689
	for <midcom@ietf.org>; Tue, 14 Aug 2001 05:28:10 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA09907;
	Tue, 14 Aug 2001 11:29:22 +0200 (MET DST)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7E9Snw26845;
	Tue, 14 Aug 2001 11:28:49 +0200
Message-Id: <5.1.0.14.0.20010814105518.00a76ef8@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 11:00:22 +0200
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Soft-state (was Re: [midcom] Requirements summary: all
  requirements
In-Reply-To: <20010813073514.A1560@SBRIM-W2K>
References: <5.1.0.14.0.20010809134105.00a76148@mailhub.fokus.gmd.de>
 <20010803131556.A1448@SBRIM-W2K>
 <5.1.0.14.0.20010809134105.00a76148@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 01:35 PM 8/13/2001, Scott Brim wrote:
>>    R6: A middlebox must be able to associate a timer with session
>>    elements.
>> 
>> *** - proposal: I would like to add a protocol requirement which would
>> allow (subject to middlebox policy, of course) agents to determine the
>> timer; it is the application that knows best what timer values are
>> adequate.
>
>We already have:
>
>   R6: A middlebox must be able to associate a timer with a ruleset.
>       When a timer expires, resources are freed.
>
>Is that enough?

I would actually like to require that the midcom protocol must allow
agents to set (or ask for) timer. (The point is that your
R6 requirement for middlebox products still does not imply agents 
be able to manipulate the timer.)

-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 05:30:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24776
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 05:30:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14148;
	Tue, 14 Aug 2001 05:29:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14101
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 05:29:24 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24687
	for <midcom@ietf.org>; Tue, 14 Aug 2001 05:28:10 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA09902;
	Tue, 14 Aug 2001 11:29:22 +0200 (MET DST)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7E9Smw26842;
	Tue, 14 Aug 2001 11:28:48 +0200
Message-Id: <5.1.0.14.0.20010814101652.029f1420@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 10:47:35 +0200
To: Mark Duffy <mduffy@quarrytech.com>, Scott Brim <sbrim@cisco.com>,
        midcom mail-list <midcom@ietf.org>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
In-Reply-To: <3.0.5.32.20010813121728.0091a430@email.quarrytech.com>
References: <20010811223138.D500@SBRIM-W2K>
 <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
 <002b01c11f3e$12a32640$b89221d9@acmepacket.com>
 <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

What you suggest seems to me to exceed requirements and run into protocol
specification. The minimum midcom protocol operations that seem required to 
me are request for opening/closing pinholes and querying/releasing NAT 
translations.

One might implement the same thing in a variety of ways. For example, I might
implement the same behaviour as you describe using a "set state" and
"release state" operation where "set" is used to communicate and
set full per-flow state (new or existing). There are certainly some
designers who would prefer this "set-full-state" approach to "delta-operations" 
as it features higher robustness.

Anyway, I see requirements for robustness and the operations above.
How the protocol exactly looks like is TBD.

-Jiri

At 06:17 PM 8/13/2001, Mark Duffy wrote:
>Yes, Bob Penfield had the same reaction and I told him I agreed ...   The
>original point I intended to make was that the agent should be able to
>manipulate the descriptor and actions independently, to whatever extent
>that make sense.  I think add/delete actions to an existing descriptor
>covers it just fine.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 05:30:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24793
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 05:30:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14167;
	Tue, 14 Aug 2001 05:29:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14108
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 05:29:24 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24690
	for <midcom@ietf.org>; Tue, 14 Aug 2001 05:28:10 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA09910;
	Tue, 14 Aug 2001 11:29:22 +0200 (MET DST)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7E9Snw26848;
	Tue, 14 Aug 2001 11:28:50 +0200
Message-Id: <5.1.0.14.0.20010814111844.02a09ea8@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 11:31:30 +0200
To: Andrew Molitor <amolitor@visi.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] policy & duration
In-Reply-To: <Pine.GSO.4.21.0108131411290.4704-100000@isis.visi.com>
References: <3.0.5.32.20010813134926.0091a750@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 09:11 PM 8/13/2001, Andrew Molitor wrote:
>        A SIP proxy is as well positioned as anything to figure out
>which phone is where. In the simple case, an enterprise (think IP PBX)
>SIP proxy can determine with relative ease that:
>
>        - phone A is inside the enterprise
>        - phone B is not

let me put the question this way: what is the piece of information a SIP
proxy knows and a middlebox does not? (Note that if you infer who is
inside/outside from Contact or SDP you can do it in middlebox too
without having to replicate this logic in every agent you have.)

>        There are also techniques which allow a SIP proxy, in conjunction
>with a set of middleboxes, to steer traffic along desired paths.

This is a matter of designer taste, I personally do not desire traffic
to be steered along desired paths. Indeed, I believe that IP model is
a feature, not a bug. Unless I got it wrong, this is not what the WG 
has been charted for.


-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 07:44:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27447
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 07:44:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17146;
	Tue, 14 Aug 2001 07:43:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17115
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 07:43:52 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27368
	for <midcom@ietf.org>; Tue, 14 Aug 2001 07:42:39 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7EBhaT10499
	for <midcom@ietf.org>; Tue, 14 Aug 2001 04:43:36 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp75.cisco.com [10.21.64.75])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACF22566;
	Tue, 14 Aug 2001 04:43:17 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010814074152.00a2bec0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 07:44:26 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Filtering rules
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I've just heard from the ADs that they don't like seeing
filtering rules/expressions added to our work.  I think that
it would probably be sufficient to have a requirement that says
that the protocol must be capable of transporting filtering
and transformation rules (or whatever we decide to call them) 
from the midcom agent to the middlebox without going into the 
details of the rule contents.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 07:54:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27795
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 07:54:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17292;
	Tue, 14 Aug 2001 07:54:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17263
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 07:54:40 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27757
	for <midcom@ietf.org>; Tue, 14 Aug 2001 07:53:29 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7EBsFQ18718
	for <midcom@ietf.org>; Tue, 14 Aug 2001 04:54:15 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJJ07850;
	Tue, 14 Aug 2001 04:54:08 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 14 Aug 2001 07:54:10 -0400
Date: Tue, 14 Aug 2001 07:54:09 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] proposed text for framework sect. 2.8
Message-ID: <20010814075409.D1512@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010810023122.61797.qmail@web13808.mail.yahoo.com> <3.0.5.32.20010813231445.007d0700@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.5.32.20010813231445.007d0700@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Aug 13, 2001 at 11:14:45PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Looks okay to me.  I like the way you finessed the "signaling packets
versus data packets" bit ...

> In-Path Midcom agents are agents which are within the path of those
> datagrams that the agent needs to examine and/or modify in fulfilling
> its role as a MIDCOM agent. 



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 08:02:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28154
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 08:02:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17813;
	Tue, 14 Aug 2001 08:01:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17785
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 08:01:53 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28066
	for <midcom@ietf.org>; Tue, 14 Aug 2001 08:00:42 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7EC1qG25252
	for <midcom@ietf.org>; Tue, 14 Aug 2001 08:01:52 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA16671; Tue, 14 Aug 2001 14:01:51 +0200 (MET DST)
Cc: midcom@ietf.org
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA16662; Tue, 14 Aug 2001 14:01:49 +0200 (MET DST)
Message-ID: <3B791364.4206239F@lucent.com>
Date: Tue, 14 Aug 2001 14:02:44 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
Original-CC: midcom@ietf.org
Subject: Re: [midcom] Filtering rules
References: <5.1.0.14.0.20010814074152.00a2bec0@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Melinda,

I would appreciate some guidance in this matter from the ADs. If we can
not specify in enough detail WHAT we want to filter/transform etc on.
Selecting a protocol will be impossible and we will need to go through
another (semi) requirements round to get additional information.

I thought that the filtering rules/expressions would give us the needed
clarity. Since that is outlawed now, what alternative can we expect to get
away with?

Paul

Melinda Shore wrote:
> 
> I've just heard from the ADs that they don't like seeing
> filtering rules/expressions added to our work.  I think that
> it would probably be sufficient to have a requirement that says
> that the protocol must be capable of transporting filtering
> and transformation rules (or whatever we decide to call them)
> from the midcom agent to the middlebox without going into the
> details of the rule contents.
> 
> Melinda
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 08:16:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29025
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 08:16:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18145;
	Tue, 14 Aug 2001 08:15:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18103
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 08:15:50 -0400 (EDT)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28908
	for <midcom@ietf.org>; Tue, 14 Aug 2001 08:14:38 -0400 (EDT)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id IAA01017;
	Tue, 14 Aug 2001 08:15:37 -0400 (EDT)
Date: Tue, 14 Aug 2001 08:15:37 -0400 (EDT)
From: Scott Bradner <sob@harvard.edu>
Message-Id: <200108141215.IAA01017@newdev.harvard.edu>
To: mshore@cisco.com, sijben@lucent.com
Subject: Re: [midcom] Filtering rules
Cc: midcom@ietf.org
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

> I would appreciate some guidance in this matter from the ADs. If we can
> not specify in enough detail WHAT we want to filter/transform etc on.
> Selecting a protocol will be impossible and we will need to go through
> another (semi) requirements round to get additional information. 

I see no need to spend time at this point figuring out all possible filters
I would like the WG to define a basic 'punch a pinhole' function for
a single stream and identify the stream in the simplest possible way.
i.e. 5-tuples

this should be sufficient to get something that will work - when that
is done we can worry about creating the filter language from hell if
that is what the Internet community feels it needs.

also - I see no reason that the midcom protocol needs to change just
because of a change in filter rules - any such rules should be
sent in a chunk to the midcom box which can then say 'can not do' if
it does not know how to do what has been asked 

Scott (the AD in question)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 08:21:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29308
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 08:21:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18263;
	Tue, 14 Aug 2001 08:21:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18234
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 08:21:38 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29275
	for <midcom@ietf.org>; Tue, 14 Aug 2001 08:20:26 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7ECLaV15468
	for <midcom@ietf.org>; Tue, 14 Aug 2001 08:21:36 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA19514; Tue, 14 Aug 2001 14:21:35 +0200 (MET DST)
Cc: mshore@cisco.com, midcom@ietf.org
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA19471; Tue, 14 Aug 2001 14:21:31 +0200 (MET DST)
Message-ID: <3B791802.DC2EE64@lucent.com>
Date: Tue, 14 Aug 2001 14:22:26 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Bradner <sob@harvard.edu>
Original-CC: mshore@cisco.com, midcom@ietf.org
Subject: Re: [midcom] Filtering rules
References: <200108141215.IAA01017@newdev.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Scott,

> also - I see no reason that the midcom protocol needs to change just
> because of a change in filter rules - any such rules should be
> sent in a chunk to the midcom box which can then say 'can not do' if
> it does not know how to do what has been asked

I can agree with you there if we were to create a _new_ protocol. Yet we
are supposed to _select_ one that exists when the requirements are done.
So the power we may seek in the filtering may guide our protocol choice.

Paul

Scott Bradner wrote:
> 
> > I would appreciate some guidance in this matter from the ADs. If we can
> > not specify in enough detail WHAT we want to filter/transform etc on.
> > Selecting a protocol will be impossible and we will need to go through
> > another (semi) requirements round to get additional information.
> 
> I see no need to spend time at this point figuring out all possible filters
> I would like the WG to define a basic 'punch a pinhole' function for
> a single stream and identify the stream in the simplest possible way.
> i.e. 5-tuples
> 
> this should be sufficient to get something that will work - when that
> is done we can worry about creating the filter language from hell if
> that is what the Internet community feels it needs.
> 
> also - I see no reason that the midcom protocol needs to change just
> because of a change in filter rules - any such rules should be
> sent in a chunk to the midcom box which can then say 'can not do' if
> it does not know how to do what has been asked
> 
> Scott (the AD in question)

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 08:33:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00082
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 08:33:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18944;
	Tue, 14 Aug 2001 08:33:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18914
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 08:33:52 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00022
	for <midcom@ietf.org>; Tue, 14 Aug 2001 08:32:39 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7ECXLQ02763;
	Tue, 14 Aug 2001 05:33:21 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp75.cisco.com [10.21.64.75])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACF23012;
	Tue, 14 Aug 2001 05:33:20 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010814083105.00a288e0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 08:34:48 -0400
To: Paul Sijben <sijben@lucent.com>, Scott Bradner <sob@harvard.edu>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Filtering rules
Cc: midcom@ietf.org
In-Reply-To: <3B791802.DC2EE64@lucent.com>
References: <200108141215.IAA01017@newdev.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 02:22 PM 8/14/01 +0200, Paul Sijben wrote:
>I can agree with you there if we were to create a _new_ protocol. Yet we
>are supposed to _select_ one that exists when the requirements are done.
>So the power we may seek in the filtering may guide our protocol choice.

!!!  I certainly hope not.  The protocol will be a transport for
whatever we say it's going to transport, and there's absolutely
no dependency whatsoever on the details of the filter specification.  
I don't see a need to specify a filter spec at all at this time -
I do think it's sufficient to say that the protocol must be
capable of transporting filter specifications from the agent to
the middlebox.  

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 09:04:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02261
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 09:04:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19913;
	Tue, 14 Aug 2001 09:04:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19837
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 09:04:01 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02141
	for <midcom@ietf.org>; Tue, 14 Aug 2001 09:02:49 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7ED3ZQ15534
	for <midcom@ietf.org>; Tue, 14 Aug 2001 06:03:35 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJJ08140;
	Tue, 14 Aug 2001 06:03:30 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 14 Aug 2001 09:03:31 -0400
Date: Tue, 14 Aug 2001 09:03:31 -0400
From: Scott Brim <sbrim@cisco.com>
To: "''midcom mail-list ' '" <midcom@ietf.org>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
Message-ID: <20010814090331.G1512@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	''midcom mail-list ' ' <midcom@ietf.org>
References: <629F94188789D5119577009027E79125214FF7@exchange_03.2wire.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <629F94188789D5119577009027E79125214FF7@exchange_03.2wire.com>; from rturner@2wire.com on Mon, Aug 13, 2001 at 11:47:55AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Mon, Aug 13, 2001 at 11:47:55AM -0700, Randy Turner apparently wrote:
>  I was specifically thinking about something like an H323 ALG/agent, that
> would have to express the relationship between multiple flows for a
> particular session being negotiated. The same could apply to SIP I would
> imagine.  It would be nice if an agent could "aggregate" control information
> across the MIDCOM protocol. The more individual streams that make up an
> application "session", the more valuable the aggregate control over the app
> session would be. Regarding resource reclamation, it might be nice to have
> the MB "cleanup" a bundle in which one of the streams (probably a control
> connection) is closed. If the MB does not have enough app intelligence to
> determine whether or not "all" pinholes should be closed, then it could just
> notify the agent, and the agent could close out the "bundle" with one
> protocol operation.
> 
> These are just off the top of my head, but my experience with H323 and NAT
> seemed to indicate that this functionality might be a good idea.

Is R46 a good enough bullet?  I don't mean, does it say everything you
want to say, but rather, is it a good enough placeholder to make sure
that what you want to see discussed will be discussed (when we finally
get around to it)?  

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 09:40:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04362
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 09:40:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20792;
	Tue, 14 Aug 2001 09:40:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20759
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 09:40:29 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04247
	for <midcom@ietf.org>; Tue, 14 Aug 2001 09:39:17 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7EDe3Q02729
	for <midcom@ietf.org>; Tue, 14 Aug 2001 06:40:03 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJJ08389;
	Tue, 14 Aug 2001 06:39:57 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 14 Aug 2001 09:39:58 -0400
Date: Tue, 14 Aug 2001 09:39:58 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
Message-ID: <20010814093957.I1512@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3.0.5.32.20010810065723.009265a0@email.quarrytech.com> <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de> <3.0.5.32.20010808102142.007df320@email.quarrytech.com> <3B713214.11AE0A1@cisco.com> <3B700C72.35EC5BD8@cisco.com> <20010808105712.I1592@SBRIM-W2K> <5.1.0.14.0.20010813164939.02a09ea8@mailhub.fokus.gmd.de> <3.0.5.32.20010813134926.0091a750@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.5.32.20010813134926.0091a750@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Aug 13, 2001 at 01:49:26PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Mon, Aug 13, 2001 at 01:49:26PM -0400, Mark Duffy apparently wrote:
> Middleboxes dealing with NAT and/or VPNs are typically dealing with
> overlapping (non unique) address spaces and therefore cannot necessarily
> determine 'where' particular IP addresses lie.

This is the "Twice NAT" scenario (rfc2663).  When you have overlapping
address spaces, you use a DNS ALG to trap DNS requests and assign a
unique address, which is then used for actual communication with the
remote device.  Therefore, from the point of view of the midcom
protocol, which doesn't care about all that initial setup, an address
always "appears" to be either inside or outside.

(The DNS ALG is interesting, since you could put that in an agent of its
own.)

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 09:44:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04535
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 09:44:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21001;
	Tue, 14 Aug 2001 09:43:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20966
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 09:43:35 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04418
	for <midcom@ietf.org>; Tue, 14 Aug 2001 09:42:22 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7EDhFn25352
	for <midcom@ietf.org>; Tue, 14 Aug 2001 06:43:15 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJJ08413;
	Tue, 14 Aug 2001 06:43:03 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 14 Aug 2001 09:43:04 -0400
Date: Tue, 14 Aug 2001 09:43:04 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
Message-ID: <20010814094304.J1512@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3.0.5.32.20010813225838.00868ad0@email.quarrytech.com> <Pine.GSO.4.21.0108132209510.27696-100000@isis.visi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.21.0108132209510.27696-100000@isis.visi.com>; from amolitor@visi.com on Mon, Aug 13, 2001 at 10:14:59PM -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Mon, Aug 13, 2001 at 10:14:59PM -0500, Andrew Molitor apparently wrote:
> 	Well, I agree 100 percent with ALMOST all of the above. It's
> actually not very interesting ;) I can't imagine anyone thinks a
> middlebox needs to know any more than an "administrative view" of
> the network tolopogy.
> 
> 	Is there anyone who thinks more detailed topology than I
> have described above needs to be known by the Agent?
> 
> 	Is there anyone who thinks that an Agent should not even know
> this much?

Since I don't know what "administrative view" means (it didn't seem to
refer to anything above it) I don't know, but I probably would like
agents to know less than that.  Get out your net and pitchfork and write
your draft :-).

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 11:12:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06923
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 11:12:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23974;
	Tue, 14 Aug 2001 11:12:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23945
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 11:12:11 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06899
	for <midcom@ietf.org>; Tue, 14 Aug 2001 11:10:57 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 85274815A
	for <midcom@ietf.org>; Tue, 14 Aug 2001 10:12:10 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA18054
	for <midcom@ietf.org>; Tue, 14 Aug 2001 10:12:10 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Tue, 14 Aug 2001 10:12:10 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
In-Reply-To: <5.1.0.14.0.20010814111844.02a09ea8@mailhub.fokus.gmd.de>
Message-ID: <Pine.GSO.4.21.0108141004500.17607-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Tue, 14 Aug 2001, Jiri Kuthan wrote:

> At 09:11 PM 8/13/2001, Andrew Molitor wrote:
> >        A SIP proxy is as well positioned as anything to figure out
> >which phone is where. In the simple case, an enterprise (think IP PBX)
> >SIP proxy can determine with relative ease that:
> >
> >        - phone A is inside the enterprise
> >        - phone B is not
> 
> let me put the question this way: what is the piece of information a SIP
> proxy knows and a middlebox does not? (Note that if you infer who is
> inside/outside from Contact or SDP you can do it in middlebox too
> without having to replicate this logic in every agent you have.)

	The SIP proxy has the contents of the INVITE, which includes
the IP address of the originating phone, and an identifier for the
target phone. The SIP proxy also may have available a database of,
say, all the identifiers of all the local phones and may thereby
deduce that the identifier included in this INVITE refers to a remote
phone.

	The 200 OK contains, in general, similar information but with
"originating" and "target" reversed.

	There are also other header fields which can be useful for
making these determinations, but I am a little hazy on the details of
SIP messages, so I will defer to wiser heads.


> >        There are also techniques which allow a SIP proxy, in conjunction
> >with a set of middleboxes, to steer traffic along desired paths.
> 
> This is a matter of designer taste, I personally do not desire traffic
> to be steered along desired paths. Indeed, I believe that IP model is
> a feature, not a bug. Unless I got it wrong, this is not what the WG 
> has been charted for.

	Oh, certainly. I didn't intend at all to drag this material in to
the working group. My point is simply:

	- MIDCOM Agents need to know (approximate) topology to
	  function at all
	- MIDCOM Agents may optionally use techniques to steer traffic,
	  thereby to some extent controlling topology
	- with this type of information in hand, a MIDCOM Agent is
	  perfectly clever enough to know (at a high level of
	  abstraction) which way traffic will be entering and
	  leaving a particular middlebox under control.

	Therefore it is probably a good idea to include some notion
of directionality, it is not a pointless exercise and is in fact
quite useful.

	Everything except the conclusion is totally out of scope for
actual working group work.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 11:17:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07049
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 11:17:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24097;
	Tue, 14 Aug 2001 11:18:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24072
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 11:18:09 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07023
	for <midcom@ietf.org>; Tue, 14 Aug 2001 11:16:56 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 16BDE813E
	for <midcom@ietf.org>; Tue, 14 Aug 2001 10:18:09 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA18444
	for <midcom@ietf.org>; Tue, 14 Aug 2001 10:18:08 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Tue, 14 Aug 2001 10:18:08 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] Filtering rules
In-Reply-To: <200108141215.IAA01017@newdev.harvard.edu>
Message-ID: <Pine.GSO.4.21.0108141013050.17607-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Tue, 14 Aug 2001, Scott Bradner wrote:

> > I would appreciate some guidance in this matter from the ADs. If we can
> > not specify in enough detail WHAT we want to filter/transform etc on.
> > Selecting a protocol will be impossible and we will need to go through
> > another (semi) requirements round to get additional information. 
> 
> I see no need to spend time at this point figuring out all possible filters
> I would like the WG to define a basic 'punch a pinhole' function for
> a single stream and identify the stream in the simplest possible way.
> i.e. 5-tuples


	I agree whole heartedly. I cannot tell you the horror I felt,
as a packet filtering designer and implementor these last 8-9 years,
at the idea of taking some nasty packet filtering description in
tcpdump format or whatever other hellish thing got invented, and
compiling that into my own thing.

	Anyways, it's a layering violation, and a pretty severe one,
and one that doesn't need to get done. A SIP proxy doesn't have any
business knowing what RTP packets look like inside.

	I was actually girding my loins for a much longer and more
boring missive on exactly this issue.

> this should be sufficient to get something that will work - when that
> is done we can worry about creating the filter language from hell if
> that is what the Internet community feels it needs.


	How do you feel about extending the 5-tuple to include an
arbitrary cookie like 'RTP' which the middlebox can ignore? Obviously
there's a namespace management issue here. Is the IETF already managing
such a namespace? Certainly anything more complex strikes me as a frob
nobody will ever implement.




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 11:51:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07884
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 11:51:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25155;
	Tue, 14 Aug 2001 11:48:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25123
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 11:48:39 -0400 (EDT)
Received: from pallas.host4u.net (pallas.host4u.net [216.71.64.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07705
	for <midcom@ietf.org>; Tue, 14 Aug 2001 11:47:25 -0400 (EDT)
Received: from C1380748B (c1380748-b.snvl1.sfba.home.com [65.11.102.112])
	by pallas.host4u.net (8.8.5/8.8.5) with SMTP id KAA04547;
	Tue, 14 Aug 2001 10:46:09 -0500
From: "Shai Mohaban" <shai@kagoor.com>
To: <midcom@ietf.org>
Cc: "Melinda Shore" <mshore@cisco.com>, "Mark Duffy" <mduffy@quarrytech.com>
Subject: Topology, pinholes and policy roles (was RE: [midcom] policy & duration)
Date: Tue, 14 Aug 2001 08:44:56 -0700
Message-ID: <NBBBKGLPAACDDACNPCCMCEEMIFAA.shai@kagoor.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <5.1.0.14.0.20010813133703.009f9800@mira-sjc5-4.cisco.com>
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Melinda keeps trying to avoid that topology/direction rat hole - I think
very rightfully so.

I think a direction element is not needed as long is we deal with pure
5-tuple rules: in this case a packet either matches the rule or does not
match the rule and will be forwarded or discarded accordingly no matter what
its direction is and which interface it arrived on.

The real problem starts as soon as we start dealing with more creative
rules. E.g. maybe we would not like a rule like "let all UDP traffic coming
from source IP X port Y go through" to be applied to traffic arriving on an
"external" interface while we would like it to work for some internal SIP
phones. In that case it seems that the topology/direction data piece does
have a meaning.

Maybe one way to overcome this is to use the notion of roles to abstract the
topology/interface information (like in COPS?). If each interface is
assigned a role (e.g. "Internal", "External") then we can assign
rulesets/pinholes to roles instead of to actual interfaces. Would that be
more acceptable? Isn't that how firewalls are configured anyway?


> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On
> Behalf Of Melinda Shore
> Sent: Monday, August 13, 2001 10:41 AM
> To: Mark Duffy; midcom@ietf.org
> Subject: Re: [midcom] policy & duration
>
>
> At 01:13 PM 8/13/01 -0400, Mark Duffy wrote:
> >I think we are in agreement that "interface" is an important component of
> >the classifier n-tuple.
>
> I don't think that I'd agree with that.  I agree that "interface"
> is an important (indeed, necessary) component of the routing/filtering
> rules on the middlebox, which isn't the same thing.
>
> This is a difficult problem and there's great potential here for us to
> do something very, very wrong.  I don't see any easy answers, myself,
> and I'm looking forward to seeing what people come up with in their
> various proposals to address this problem.
>
> Melinda
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 12:21:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08791
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 12:21:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26808;
	Tue, 14 Aug 2001 12:21:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26777
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 12:21:12 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08738
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:20:01 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id 201CB8174
	for <midcom@ietf.org>; Tue, 14 Aug 2001 11:21:12 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id LAA22934
	for <midcom@ietf.org>; Tue, 14 Aug 2001 11:21:12 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Tue, 14 Aug 2001 11:21:11 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: Topology, pinholes and policy roles (was RE: [midcom] policy &
 duration)
In-Reply-To: <NBBBKGLPAACDDACNPCCMCEEMIFAA.shai@kagoor.com>
Message-ID: <Pine.GSO.4.21.0108141108590.18585-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Tue, 14 Aug 2001, Shai Mohaban wrote:

> Melinda keeps trying to avoid that topology/direction rat hole - I think
> very rightfully so.
> 
> I think a direction element is not needed as long is we deal with pure
> 5-tuple rules: in this case a packet either matches the rule or does not
> match the rule and will be forwarded or discarded accordingly no matter what
> its direction is and which interface it arrived on.

	Let us imagine I can persuade your SIP proxy to accept an INVITE
from the outside, giving the IP address and port of your internal NFS
server as 'my' media endpoint. Call this 10.0.0.1 port 5723. The SIP
proxy, acting as a MIDCOM Agent, opens a pinhole that says 'anything at
all can send UDP traffic to 10.0.0.1 5723' assuming that this is OUTBOUND
traffic from some internal phone to the call originator (me). But, alas,
there's no way to specify that in the MIDCOM message. Plus, the Agent
doesn't have any notion of 'inside' versus 'outside' so it doesn't even
know that 10.0.0.1 is inside its network.

	Now I, being part of 'anything at all' can send UDP traffic to
your NFS server. No, validating addresses at the interfaces won't work,
because the packets are actually going the right way. Sure, you could
stick specific rules in to protect your NFS server, and everything else.

	Cool, huh!

	To put it another way, this is functionally identical to opening
all your UDP ports up to the world, since opening any specific one can be
accomplished by forging a suitable INVITE.

	Not to put too fine of a point on it: That dog don't hunt.

P.S. I know perfectly well that 10.0.0.1 isn't public, replace it with
your favorite routable address to get the full effect.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 12:29:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09035
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 12:29:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27134;
	Tue, 14 Aug 2001 12:29:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27101
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 12:29:42 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09011
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:28:29 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7EGTRT08894;
	Tue, 14 Aug 2001 09:29:27 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp75.cisco.com [10.21.64.75])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACG00799;
	Tue, 14 Aug 2001 09:29:08 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010814122708.00a3d630@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 12:30:31 -0400
To: Andrew Molitor <amolitor@visi.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
In-Reply-To: <Pine.GSO.4.21.0108141108590.18585-100000@isis.visi.com>
References: <NBBBKGLPAACDDACNPCCMCEEMIFAA.shai@kagoor.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Re: Topology, pinholes and policy roles (was RE: [midcom]
 policy & duration)
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:21 AM 8/14/01 -0500, Andrew Molitor wrote:
>        Now I, being part of 'anything at all' can send UDP traffic to
>your NFS server. No, validating addresses at the interfaces won't work,
>because the packets are actually going the right way. Sure, you could
>stick specific rules in to protect your NFS server, and everything else.

Anybody who relies on a firewall to protect a particular application -
any particular application - deserves what they get.

In the meantime, I hope that people who do have a particular view
of how this all should work are scribbling (or typing) away,
preparing short documents that they'd like to champion when the
time comes.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 12:39:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09411
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 12:39:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27547;
	Tue, 14 Aug 2001 12:34:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27520
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 12:34:51 -0400 (EDT)
Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09225
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:33:39 -0400 (EDT)
Message-ID: <20010814163450.23293.qmail@web13802.mail.yahoo.com>
Received: from [66.89.112.150] by web13802.mail.yahoo.com; Tue, 14 Aug 2001 09:34:50 PDT
Date: Tue, 14 Aug 2001 09:34:50 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
To: Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
In-Reply-To: <3.0.5.32.20010813231445.007d0700@email.quarrytech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi Mark,

Looks good. I do have a comment below. Thanks.

regards,
suresh

--- Mark Duffy <mduffy@quarrytech.com> wrote:
> >5. Section 2.8: Mark Duffy will propose new text to replace existing 
> >   text. There was concern about whether or not intrusive MIDCOM agents
> >   (in the native path) should be considered In-Path agents. 
> 
> Here is the proposed text:
> 
> 2.8. MIDCOM Agents
> 
> MIDCOM agents are entities performing ALG functions, logically external to a
> middlebox. MIDCOM agents possess a combination of application awareness and
> knowledge of the middlebox function, which combination enables the agents to
> facilitate traversal of the middlebox by the application's packets. A MIDCOM
> agent may interact with one or more middleboxes.
> 
> Only "In-Path MIDCOM agents" are considered in this document. In-Path Midcom
> agents are agents which are within the path of those datagrams that the agent
> needs to examine and/or modify in fulfilling its role as a MIDCOM agent.
> "Within the path" here simply means that the packets in question flow through
> the node that hosts the agent.  The packets may be addressed to the agent
> node at the IP layer.  Alternatively they may not be addressed to the agent
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> node but may be constrained by other factors to flow through it. In fact, it
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you suggesting that a middlebox can be a MIDCOM agent to another
middlebox? This can happen, when packets are not targeted to the
MIDCOM agent.

> is immaterial to the MIDCOM protocol which of these is the case. Some
> examples of In-Path MIDCOM agents are application proxies, gateways, or even
> end-hosts that are party to the application. 
> 
> Agents not resident on nodes that are within the path of their relevant
> application flows are refered to as "Out-of-Path (OOP) MIDCOM agents" and are
> out of scope of this document.


=====


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 12:46:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09796
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 12:46:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28062;
	Tue, 14 Aug 2001 12:45:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28031
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 12:45:25 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09706
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:44:13 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7EGj5n20849
	for <midcom@ietf.org>; Tue, 14 Aug 2001 09:45:05 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJJ10833;
	Tue, 14 Aug 2001 09:44:53 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 14 Aug 2001 12:44:53 -0400
Date: Tue, 14 Aug 2001 12:44:53 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] proposed text for framework sect. 2.8
Message-ID: <20010814124452.V1512@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3.0.5.32.20010813231445.007d0700@email.quarrytech.com> <20010814163450.23293.qmail@web13802.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010814163450.23293.qmail@web13802.mail.yahoo.com>; from srisuresh@yahoo.com on Tue, Aug 14, 2001 at 09:34:50AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Tue, Aug 14, 2001 at 09:34:50AM -0700, Pyda Srisuresh apparently wrote:
> > Only "In-Path MIDCOM agents" are considered in this document. In-Path Midcom
> > agents are agents which are within the path of those datagrams that the agent
> > needs to examine and/or modify in fulfilling its role as a MIDCOM agent.
> > "Within the path" here simply means that the packets in question flow through
> > the node that hosts the agent.  The packets may be addressed to the agent
> > node at the IP layer.  Alternatively they may not be addressed to the agent
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > node but may be constrained by other factors to flow through it. In fact, it
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Are you suggesting that a middlebox can be a MIDCOM agent to another
> middlebox? This can happen, when packets are not targeted to the
> MIDCOM agent.

By definition the middlebox function and agent function are distinct
(although they could be in the same physical enclosure).  However, I
don't believe that's what he's talking about.

Consider an FTP agent.  The client application knows nothing about the
agent (otherwise it would just be a proxy).  It's sending its packets
toward what it believes is the address of its remote peer.  Some of
those packets are FTP signaling, and some are data.  The agent wiretaps
the FTP communications in general and communicates with the middlebox to
make sure the client succeeds.  This is just like NAT+ALG today, except
for the separation of the NAT and ALG functions and the midcom protocol
between them.  As the text points out, the packets are not addressed to
the agent, they just flow through it.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 12:46:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09832
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 12:46:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27987;
	Tue, 14 Aug 2001 12:43:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27934
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 12:43:39 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09604
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:42:26 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id JAA16766;
	Tue, 14 Aug 2001 09:43:28 -0700 (PDT)
Message-Id: <200108141643.JAA16766@nemo.corp.equinix.com>
Subject: Re: [midcom] policy & duration
To: amolitor@visi.com (Andrew Molitor)
Date: Tue, 14 Aug 2001 09:43:28 -0700 (PDT)
Cc: midcom@ietf.org
In-Reply-To: <Pine.GSO.4.21.0108132209510.27696-100000@isis.visi.com> from "Andrew Molitor" at Aug 13, 2001 10:14:59 PM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Andrew, Mark,
	Every time I try to write something about this, I find myself
falling into metaphors which use topological terms.  At the risk of
sounding like a pedantic twit, though, I still think we have to think
first in terms of address or trust realm and only afterwards in terms
of topology.  You are both right, of course, that the middleboxes
exist to mediate between the two realms.  And as you both know, there
is also clearly a "from" and a "to" in a packet flow, and mapping that
"from" and "to" onto the address realm or trust realm is a function
which must occur in this process.  The question at hand, though, is
should the MIDCOM agent's signal be focused on the topology or on the
realm?
	Let's assume for a second that we use "managed" and "global"
as the contrasting address realms for a NAT.  Using that terminology,
we can imagine MIDCOM agent statements to a specific NAT taking the
form "Map 'global' address x.x.x.x to 'managed' address y.y.y.y for
all ports until timer value reaches DATE XX:YY UT".  Similarly, we can
use "managed" and "global" for the trust realms associated with a
firewall in statements like "Allow 'global' trust realm member
associated with credential X to participate in 'managed' trust realm
with rights of type Y".
	It is absolutely true that in both cases what will likely
happen is that the NAT or Firewall will allow a specific flow to
travel from one interface to another.  The key is that the MIDCOM agent
need know nothing about which interfaces those are; that knowledge
stays inside the middlebox and can be as simple or as complex as the
circumstances require without any consequential increase in complexity
in the MIDCOM agent.
	Again, my apologies if this sounds nit-picky or pedantic.
				regards,
					Ted Hardie


> On Mon, 13 Aug 2001, Mark Duffy wrote:
> 
> > This is really interesting.  Wouldn't it be fair to say that realms are
> > interconnected in a toplology of their own?  (At a higher layer than the IP
> > network topology.)  And that frequently, middleboxes such as firewalls and
> > NATs appear at the realm interconnection points?  Not only that but these
> > middleboxes generally operate on behalf of one of the realms at a
> > connection point, not both (thus there is an "in"side and an "out"side.
> > And perhaps the good news about all this is that maybe midcom can get
> > pretty far without understanding the overall topology of all the realms,
> > but just the agent statically knowing for each middlebox (or each realm
> > served by a multipoint mb) which side is in and which is out.
> 
> 	This is all absolutely and 100 percent correct. One winds
> up carving the world up into some small set of blobs interconnected
> by the middleboxes nearby, and using that as a "sufficiently good"
> definition of network topology. This is exactly like firewall
> configuration. A "blob" might as well be defined as:
> 
> 	- an arbitrary set of IP addresses explicitly called out
> 	- all the IP addresses not in any other set ("the world")
> 
> 	Well, I agree 100 percent with ALMOST all of the above. It's
> actually not very interesting ;) I can't imagine anyone thinks a
> middlebox needs to know any more than an "administrative view" of
> the network tolopogy.
> 
> 	Is there anyone who thinks more detailed topology than I
> have described above needs to be known by the Agent?
> 
> 	Is there anyone who thinks that an Agent should not even know
> this much?
> 
> 		Andrew
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 13:00:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10251
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 13:00:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28430;
	Tue, 14 Aug 2001 12:58:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28397
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 12:58:49 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10162
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:57:31 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA28846
	for <midcom@ietf.org>; Tue, 14 Aug 2001 11:58:06 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Tue, 14 Aug 2001 11:57:36 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5XV6SC4>; Tue, 14 Aug 2001 09:57:03 -0700
Message-ID: <A7895B732354D311A4770008C791841A013F4286@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>,
        "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Re: Topology, pinholes and policy roles (was RE: [mi 
         dcom] policy & duration)
Date: Tue, 14 Aug 2001 09:57:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C124E2.231B11F0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C124E2.231B11F0
Content-Type: text/plain;
	charset="iso-8859-1"

Melinda,

would you consider having someone from a firewall perspective as a co-chair
in this WG? No matter how many emails people write describing scenarios,
network topologies, etc.. It seems we are not getting through. 

other comments inline.


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, August 14, 2001 9:31 AM
> To: Andrew Molitor; midcom@ietf.org
> Subject: [midcom] Re: Topology, pinholes and policy roles (was RE:
> [midcom] policy & duration)
> 
> 
> At 11:21 AM 8/14/01 -0500, Andrew Molitor wrote:
> >        Now I, being part of 'anything at all' can send UDP 
> traffic to
> >your NFS server. No, validating addresses at the interfaces 
> won't work,
> >because the packets are actually going the right way. Sure, you could
> >stick specific rules in to protect your NFS server, and 
> everything else.
> 
> Anybody who relies on a firewall to protect a particular application -
> any particular application - deserves what they get.

huh? Do you speak on behalf of Cisco Systems on this list? Are you including
Cisco Systems Firewall owners on your statement? 

> 
> In the meantime, I hope that people who do have a particular view
> of how this all should work are scribbling (or typing) away,
> preparing short documents that they'd like to champion when the
> time comes.

More docs? There was already enough emails on this list with deployment
scenarios to fill any mailbox. 

-RP

> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C124E2.231B11F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Re: Topology, pinholes and policy roles (was RE: =
[midcom]  policy &amp; duration)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Melinda,</FONT>
</P>

<P><FONT SIZE=3D2>would you consider having someone from a firewall =
perspective as a co-chair in this WG? No matter how many emails people =
write describing scenarios, network topologies, etc.. It seems we are =
not getting through. </FONT></P>

<P><FONT SIZE=3D2>other comments inline.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 14, 2001 9:31 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Andrew Molitor; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Re: Topology, pinholes and =
policy roles (was RE:</FONT>
<BR><FONT SIZE=3D2>&gt; [midcom] policy &amp; duration)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 11:21 AM 8/14/01 -0500, Andrew Molitor =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Now I, being part of 'anything at all' can send UDP </FONT>
<BR><FONT SIZE=3D2>&gt; traffic to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;your NFS server. No, validating addresses =
at the interfaces </FONT>
<BR><FONT SIZE=3D2>&gt; won't work,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;because the packets are actually going the =
right way. Sure, you could</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;stick specific rules in to protect your NFS =
server, and </FONT>
<BR><FONT SIZE=3D2>&gt; everything else.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Anybody who relies on a firewall to protect a =
particular application -</FONT>
<BR><FONT SIZE=3D2>&gt; any particular application - deserves what they =
get.</FONT>
</P>

<P><FONT SIZE=3D2>huh? Do you speak on behalf of Cisco Systems on this =
list? Are you including Cisco Systems Firewall owners on your =
statement? </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In the meantime, I hope that people who do have =
a particular view</FONT>
<BR><FONT SIZE=3D2>&gt; of how this all should work are scribbling (or =
typing) away,</FONT>
<BR><FONT SIZE=3D2>&gt; preparing short documents that they'd like to =
champion when the</FONT>
<BR><FONT SIZE=3D2>&gt; time comes.</FONT>
</P>

<P><FONT SIZE=3D2>More docs? There was already enough emails on this =
list with deployment scenarios to fill any mailbox. </FONT>
</P>

<P><FONT SIZE=3D2>-RP</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C124E2.231B11F0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 13:00:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10262
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 13:00:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28388;
	Tue, 14 Aug 2001 12:58:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28355
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 12:58:18 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10111
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:57:05 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA24414;
	Tue, 14 Aug 2001 18:58:16 +0200 (MET DST)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7EGvew29066;
	Tue, 14 Aug 2001 18:57:41 +0200
Message-Id: <5.1.0.14.0.20010814180034.029d0c58@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 19:05:17 +0200
To: Andrew Molitor <amolitor@visi.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] policy & duration
In-Reply-To: <Pine.GSO.4.21.0108141004500.17607-100000@isis.visi.com>
References: <5.1.0.14.0.20010814111844.02a09ea8@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 05:12 PM 8/14/2001, Andrew Molitor wrote:


>On Tue, 14 Aug 2001, Jiri Kuthan wrote:
>> let me put the question this way: what is the piece of information a SIP
>> proxy knows and a middlebox does not? (Note that if you infer who is
>> inside/outside from Contact or SDP you can do it in middlebox too
>> without having to replicate this logic in every agent you have.)
>
>        The SIP proxy has the contents of the INVITE, which includes
>the IP address of the originating phone, and an identifier for the
>target phone. The SIP proxy also may have available a database of,
>say, all the identifiers of all the local phones and may thereby
>deduce that the identifier included in this INVITE refers to a remote
>phone.

Andrew,

I'm glad you came up with these details. I think they show some frequent
misunderstandings on which we should not build.

SIP user identifiers will not help you as they do not relate to user's current 
location. (Note that SIP has no phone identifiers, it has user identifiers). 
For example, you cannot infer from my address "sip:jiri@iptel.org"
or from my athentication id "jiri" on which side of firewall I am
currently located.

So you might try looking at IP addresses in SDP payloads. My point is, 
however, that a SIP middlebox is not able to infer the expected
direction in this case any better than a middlebox is. If a SIP proxy 
knows from SDP payloads that media will flow from A to B, the middlebox
will know it too. So where do you want to build the direction-guessing 
logic? In one middlebox or in ten different agents?

I still have not said there is no scenario in which an agent knows well
what the expected direction is. I simply want to see it first.

>        - MIDCOM Agents need to know (approximate) topology to
>          function at all

It is likely that a middlebox needs to know that. As said, I still have
not seen a reasoning which explains why the agent knows better then
middlebox does.

>        - MIDCOM Agents may optionally use techniques to steer traffic,
>          thereby to some extent controlling topology

Please no.

>        Everything except the conclusion is totally out of scope for
>actual working group work.


I think that any WG's document which are limited to assertations without
a good justification are useless.

-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 13:18:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10829
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 13:18:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29185;
	Tue, 14 Aug 2001 13:17:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29154
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 13:17:33 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10780
	for <midcom@ietf.org>; Tue, 14 Aug 2001 13:16:20 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id BC7E1811C
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:17:31 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA26597
	for <midcom@ietf.org>; Tue, 14 Aug 2001 12:17:31 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Tue, 14 Aug 2001 12:17:31 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
In-Reply-To: <5.1.0.14.0.20010814180034.029d0c58@mailhub.fokus.gmd.de>
Message-ID: <Pine.GSO.4.21.0108141204260.25650-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


	Despite the ongoing thread, I think Jiri and I are in almost
complete agreement ;)

On Tue, 14 Aug 2001, Jiri Kuthan wrote:
> SIP user identifiers will not help you as they do not relate to user's current 
> location. (Note that SIP has no phone identifiers, it has user identifiers). 
> For example, you cannot infer from my address "sip:jiri@iptel.org"
> or from my athentication id "jiri" on which side of firewall I am
> currently located.

	Nontheless, a SIP Proxy may well be able to determine that
there isn't a sip:jiri@iptel.org currently located "inside" and thereby
deduce that you are somewhere else.

> So you might try looking at IP addresses in SDP payloads. My point is, 
> however, that a SIP middlebox is not able to infer the expected
> direction in this case any better than a middlebox is. If a SIP proxy 
> knows from SDP payloads that media will flow from A to B, the middlebox
> will know it too. So where do you want to build the direction-guessing 
> logic? In one middlebox or in ten different agents?

	My point is actually slightly different. The Agent in general
has to sort out which middlebox(es), if any, to talk to. Consider a
simple case of an enterprise, if a call is phone-to-phone inside,
the Agent Must Not do a NAT binding on the middlebox connecting
the Enterprise to the outside world. If it did, the INVITE sent
to the target phone (in the next cubicle) would have been re-written
to use an external address for the media back to the originating
phone. This can be solved through squirrelly routing which
hairpins media out through the middlebox and back in, but it's
exceedingly ugly.

	The process of figuring out which middleboxes to talk to
is, it turns out, a superset of the problem of figuring out
directionality.

	There are other, more complex, scenarios which I expect
I could write up demonstrating the same notion for robustly.

	The point is not that it's easy for the Agent to know this
stuff -- it may be very hard, it may only be possible in limited
scenarios -- but rather that it simply won't work if the Agent
doesn't.

	The middlebox is, in the abstract, far less capable of guessing
direction and location of endpoints since information is lost. In the
land of SIP and RTP, all the middlebox gets is a five-tuple with masks
or wildcards -- which contains NO information about the expected
originator of media! Only one endpoint is known, only one can be
specified, the middlebox cannot reasonably compute a "direction"
based on just one end.

	But more generally, a masked 5-tuple (what the middlebox sees)
has potentially far less information than the Agent has available (in
SIP INVITES, or whatever other messages of whatever other protocol
it's managing).

> >        - MIDCOM Agents need to know (approximate) topology to
> >          function at all
> 
> It is likely that a middlebox needs to know that. As said, I still have
> not seen a reasoning which explains why the agent knows better then
> middlebox does.

	Actually, mine doesn't have a clue. It knows that port is
named 'open' and that port is named 'secure' and that's pretty much
it ;) DUMB middleboxes, SMART Agents!

> >        Everything except the conclusion is totally out of scope for
> >actual working group work.
> 
> I think that any WG's document which are limited to assertations without
> a good justification are useless.

	I concur entirely. It's certainly worthwhile to think through
usage scenarios, and include summaries of them in documents. However,
these are not part of the work proper, just supporting documentation.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 13:21:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10950
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 13:21:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29111;
	Tue, 14 Aug 2001 13:16:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29080
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 13:16:37 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10703
	for <midcom@ietf.org>; Tue, 14 Aug 2001 13:15:24 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7EHEKQ00331;
	Tue, 14 Aug 2001 10:14:20 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp75.cisco.com [10.21.64.75])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACI00077;
	Tue, 14 Aug 2001 10:14:18 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010814130621.00a3fbe0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 13:14:17 -0400
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'Andrew Molitor'" <amolitor@visi.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Re: Topology, pinholes and policy roles (was RE:
  [mi  dcom] policy & duration)
In-Reply-To: <A7895B732354D311A4770008C791841A013F4286@zsc4c014.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 09:57 AM 8/14/01 -0700, Reinaldo Penno wrote:
>huh? Do you speak on behalf of Cisco Systems on this list? Are you including Cisco Systems Firewall owners on your statement? 

I never speak on behalf of Cisco Systems.  This is the IETF, where
participation is individual and should never be construed as representing
the official position of the individual's employer.  This is not the
ITU-T.

That said, firewalls "protect" networks.  They do *not* protect
applications, and, in fact, interfere with application security
in many cases.  Relying on firewalls (or VPNs, or NATs, or ... )
to provide application security is asking for problems.

>More docs? There was already enough emails on this list with deployment scenarios to fill any mailbox. 

As I described in yesterday's email, we decided at the meeting
that because we're highly unlikely to resolve the topology issue
on the mailing list, because there may be serious consequences
resulting from a bad decision, and because we have to get this 
thing through IESG review and some of what's been proposed wouldn't
survive it, people with opinions about how the topology problem
should be handled need to document them in a SHORT internet draft,
which will be looked at both by the working group and by our
Area Directors.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 14:30:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12428
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 14:30:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01185;
	Tue, 14 Aug 2001 14:18:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01107
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 14:18:42 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12215
	for <midcom@ietf.org>; Tue, 14 Aug 2001 14:17:29 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA01187
	for <midcom@ietf.org>; Tue, 14 Aug 2001 13:18:10 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 14 Aug 2001 13:18:19 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YHCP8N>; Tue, 14 Aug 2001 13:17:45 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF34@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Scott Brim'" <sbrim@cisco.com>, midcom mail-list <midcom@ietf.org>
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!
Date: Tue, 14 Aug 2001 13:17:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C124ED.65A92EC0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C124ED.65A92EC0
Content-Type: text/plain;
	charset="iso-8859-1"


> -----Original Message-----
> From: Scott Brim [mailto:sbrim@cisco.com]
> Sent: Monday, August 13, 2001 12:48 PM
> To: midcom mail-list
> Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
> 
> 
> I'd like to hear people's requirements for atomic execution and how
> flexible it needs to be.  For example, does the agent need to 
> be able to
> say "please create this and delete that" in such a way that 
> if the first
> doesn't happen the second must not either?  Is an aggregate delete
> request, with the possibility of mixed results, satisfactory?
> 
> On the other hand it would also be good to limit discussion to just a
> few requirements at a time (nudge nudge).
> 

I support the concept of ruleset-bundle (or whatever-bundle) &
ruleset-bundle-id, if this applies to RELATED rulesets. There should be
operations targeted to the bundle (i.e. to ALL rulesets within the bundle)
and there can be (micro)operations aggregated within a message (e.g., a
single UDP message) which are targeted individually to each rule-set within
a bundle. However, I do not see it necessary (at least, at this stage) to
impose any dependency between the micro-operations within a message. 

Sanjoy

------_=_NextPart_001_01C124ED.65A92EC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] pin-holes, sessions and flows, oh my!</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Scott Brim [<A =
HREF=3D"mailto:sbrim@cisco.com">mailto:sbrim@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, August 13, 2001 12:48 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom mail-list</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] pin-holes, sessions and =
flows, oh my!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'd like to hear people's requirements for =
atomic execution and how</FONT>
<BR><FONT SIZE=3D2>&gt; flexible it needs to be.&nbsp; For example, =
does the agent need to </FONT>
<BR><FONT SIZE=3D2>&gt; be able to</FONT>
<BR><FONT SIZE=3D2>&gt; say &quot;please create this and delete =
that&quot; in such a way that </FONT>
<BR><FONT SIZE=3D2>&gt; if the first</FONT>
<BR><FONT SIZE=3D2>&gt; doesn't happen the second must not =
either?&nbsp; Is an aggregate delete</FONT>
<BR><FONT SIZE=3D2>&gt; request, with the possibility of mixed results, =
satisfactory?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On the other hand it would also be good to =
limit discussion to just a</FONT>
<BR><FONT SIZE=3D2>&gt; few requirements at a time (nudge =
nudge).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I support the concept of ruleset-bundle (or =
whatever-bundle) &amp; ruleset-bundle-id, if this applies to RELATED =
rulesets. There should be operations targeted to the bundle (i.e. to =
ALL rulesets within the bundle) and there can be (micro)operations =
aggregated within a message (e.g., a single UDP message) which are =
targeted individually to each rule-set within a bundle. However, I do =
not see it necessary (at least, at this stage) to impose any dependency =
between the micro-operations within a message. </FONT></P>

<P><FONT SIZE=3D2>Sanjoy</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C124ED.65A92EC0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 14:54:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12933
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 14:54:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01990;
	Tue, 14 Aug 2001 14:39:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01961
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 14:39:37 -0400 (EDT)
Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12631
	for <midcom@ietf.org>; Tue, 14 Aug 2001 14:38:24 -0400 (EDT)
Message-ID: <20010814183936.13777.qmail@web13807.mail.yahoo.com>
Received: from [66.89.112.150] by web13807.mail.yahoo.com; Tue, 14 Aug 2001 11:39:36 PDT
Date: Tue, 14 Aug 2001 11:39:36 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
In-Reply-To: <20010814124452.V1512@SBRIM-W2K>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--- Scott Brim <sbrim@cisco.com> wrote:
> On Tue, Aug 14, 2001 at 09:34:50AM -0700, Pyda Srisuresh apparently wrote:
> > > Only "In-Path MIDCOM agents" are considered in this document. In-Path
> Midcom
> > > agents are agents which are within the path of those datagrams that the
> agent
> > > needs to examine and/or modify in fulfilling its role as a MIDCOM agent.
> > > "Within the path" here simply means that the packets in question flow
> through
> > > the node that hosts the agent.  The packets may be addressed to the agent
> > > node at the IP layer.  Alternatively they may not be addressed to the
> agent
> >                         
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > node but may be constrained by other factors to flow through it. In fact,
> it
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > Are you suggesting that a middlebox can be a MIDCOM agent to another
> > middlebox? This can happen, when packets are not targeted to the
> > MIDCOM agent.
> 
> By definition the middlebox function and agent function are distinct
> (although they could be in the same physical enclosure).  However, I
> don't believe that's what he's talking about.
> 
Sure, I wasnt alluding to that either.

> Consider an FTP agent.  The client application knows nothing about the
> agent (otherwise it would just be a proxy).  It's sending its packets
> toward what it believes is the address of its remote peer.  Some of
> those packets are FTP signaling, and some are data.  The agent wiretaps
> the FTP communications in general and communicates with the middlebox to
> make sure the client succeeds.  This is just like NAT+ALG today, except
> for the separation of the NAT and ALG functions and the midcom protocol
> between them.  As the text points out, the packets are not addressed to
> the agent, they just flow through it.
> 
Yes. This is what I was refering to. The text suggests allowing a 
middlebox to be a MIDCOM agent to another middlebox. I am not necessarily
against this. I wanted this to be explicitly understood and agreed upon,
so this doesnt show up later on during last call or IESG review or what
have you.

Perhaps, you could track this along with the requirements you are tracking
- debated, agreed-upon etc...

Thanks.

> ..Scott
> 

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 14:59:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13027
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 14:59:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02577;
	Tue, 14 Aug 2001 14:52:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02545
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 14:52:04 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12863
	for <midcom@ietf.org>; Tue, 14 Aug 2001 14:50:50 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7EIpWQ22743;
	Tue, 14 Aug 2001 11:51:32 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp75.cisco.com [10.21.64.75])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACI04797;
	Tue, 14 Aug 2001 11:51:31 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010814145144.00a40240@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 14:52:49 -0400
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
In-Reply-To: <20010814144839.A1756@SBRIM-W2K>
References: <20010814183936.13777.qmail@web13807.mail.yahoo.com>
 <20010814124452.V1512@SBRIM-W2K>
 <20010814183936.13777.qmail@web13807.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 02:48 PM 8/14/01 -0400, Scott Brim wrote:
>So, the text for the requirement would be "A middlebox can be an agent
>to another middlebox"?

Let's not.  We're trying to reduce the bloat, and the above text
doesn't add anything that's not already in there.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 15:03:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13103
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 15:03:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02861;
	Tue, 14 Aug 2001 14:56:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02834
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 14:56:43 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12967
	for <midcom@ietf.org>; Tue, 14 Aug 2001 14:55:29 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7EItwJ15992;
	Tue, 14 Aug 2001 13:55:58 -0500
From: "Ram Dantu" <ramd@netrake.com>
To: "Melinda Shore" <mshore@cisco.com>,
        "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'Andrew Molitor'" <amolitor@visi.com>, <midcom@ietf.org>
Subject: RE: [midcom] Re: Topology, pinholes and policy roles (was RE: [mi  dcom] policy & duration)
Date: Tue, 14 Aug 2001 13:55:58 -0500
Message-ID: <AEEDLFNKBFAGGEGOFBPIAENICBAA.ramd@netrake.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.1.0.14.0.20010814130621.00a3fbe0@mira-sjc5-4.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I have a feeling that we are reinventing the wheel.
The Softswitch and Media Gateway (MGW) do have similar problem
and I believe the softswitch does have some knowledge
of the MGW topology (probably static info).
Infact, MGCP does set the direction rcv/snd
for the media flow.  I am not sure we have any protocol
for discovering the mediagateways or topology updates.

Regards
Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Melinda Shore
Sent: Tuesday, August 14, 2001 12:14 PM
To: Reinaldo Penno; 'Andrew Molitor'; 'midcom@ietf.org'
Subject: RE: [midcom] Re: Topology, pinholes and policy roles (was RE:
[mi dcom] policy & duration)


At 09:57 AM 8/14/01 -0700, Reinaldo Penno wrote:
>huh? Do you speak on behalf of Cisco Systems on this list? Are you
including Cisco Systems Firewall owners on your statement?

I never speak on behalf of Cisco Systems.  This is the IETF, where
participation is individual and should never be construed as representing
the official position of the individual's employer.  This is not the
ITU-T.

That said, firewalls "protect" networks.  They do *not* protect
applications, and, in fact, interfere with application security
in many cases.  Relying on firewalls (or VPNs, or NATs, or ... )
to provide application security is asking for problems.

>More docs? There was already enough emails on this list with deployment
scenarios to fill any mailbox.

As I described in yesterday's email, we decided at the meeting
that because we're highly unlikely to resolve the topology issue
on the mailing list, because there may be serious consequences
resulting from a bad decision, and because we have to get this
thing through IESG review and some of what's been proposed wouldn't
survive it, people with opinions about how the topology problem
should be handled need to document them in a SHORT internet draft,
which will be looked at both by the working group and by our
Area Directors.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 15:54:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13025
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 14:59:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02309;
	Tue, 14 Aug 2001 14:49:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02283
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 14:49:14 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12786
	for <midcom@ietf.org>; Tue, 14 Aug 2001 14:48:01 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7EImrn23279
	for <midcom@ietf.org>; Tue, 14 Aug 2001 11:48:53 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJK01203;
	Tue, 14 Aug 2001 11:48:40 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 14 Aug 2001 14:48:39 -0400
Date: Tue, 14 Aug 2001 14:48:39 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] proposed text for framework sect. 2.8
Message-ID: <20010814144839.A1756@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010814124452.V1512@SBRIM-W2K> <20010814183936.13777.qmail@web13807.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010814183936.13777.qmail@web13807.mail.yahoo.com>; from srisuresh@yahoo.com on Tue, Aug 14, 2001 at 11:39:36AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

See bottom ...

On Tue, Aug 14, 2001 at 11:39:36AM -0700, Pyda Srisuresh apparently wrote:
> 
> --- Scott Brim <sbrim@cisco.com> wrote:
> > On Tue, Aug 14, 2001 at 09:34:50AM -0700, Pyda Srisuresh apparently wrote:
> > > > Only "In-Path MIDCOM agents" are considered in this document. In-Path
> > Midcom
> > > > agents are agents which are within the path of those datagrams that the
> > agent
> > > > needs to examine and/or modify in fulfilling its role as a MIDCOM agent.
> > > > "Within the path" here simply means that the packets in question flow
> > through
> > > > the node that hosts the agent.  The packets may be addressed to the agent
> > > > node at the IP layer.  Alternatively they may not be addressed to the
> > agent
> > >                         
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > node but may be constrained by other factors to flow through it. In fact,
> > it
> > >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > 
> > > Are you suggesting that a middlebox can be a MIDCOM agent to another
> > > middlebox? This can happen, when packets are not targeted to the
> > > MIDCOM agent.
> > 
> > By definition the middlebox function and agent function are distinct
> > (although they could be in the same physical enclosure).  However, I
> > don't believe that's what he's talking about.
> > 
> Sure, I wasnt alluding to that either.
> 
> > Consider an FTP agent.  The client application knows nothing about the
> > agent (otherwise it would just be a proxy).  It's sending its packets
> > toward what it believes is the address of its remote peer.  Some of
> > those packets are FTP signaling, and some are data.  The agent wiretaps
> > the FTP communications in general and communicates with the middlebox to
> > make sure the client succeeds.  This is just like NAT+ALG today, except
> > for the separation of the NAT and ALG functions and the midcom protocol
> > between them.  As the text points out, the packets are not addressed to
> > the agent, they just flow through it.
> > 
> Yes. This is what I was refering to. The text suggests allowing a 
> middlebox to be a MIDCOM agent to another middlebox. I am not necessarily
> against this. I wanted this to be explicitly understood and agreed upon,
> so this doesnt show up later on during last call or IESG review or what
> have you.
> 
> Perhaps, you could track this along with the requirements you are tracking
> - debated, agreed-upon etc...

So, the text for the requirement would be "A middlebox can be an agent
to another middlebox"?

I'm willing to put it in (I just line 'em up, anyone can bowl 'em over),
but (1) I still don't see how the text above leads to that idea, and (2)
I don't think it makes sense.  Perhaps a single physical enclosure could
contain both a middlebox function and an agent for some other middlebox,
but those would still be distinct functions.

I don't understand how you envision things.  Just because packets are
flowing through something doesn't make it a middlebox.  In the above,
what is the agent doing that makes it a middlebox?

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 16:23:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14431
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 16:23:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04668;
	Tue, 14 Aug 2001 16:19:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04637
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 16:19:58 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14273
	for <midcom@ietf.org>; Tue, 14 Aug 2001 16:18:45 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7EKJcT24727
	for <midcom@ietf.org>; Tue, 14 Aug 2001 13:19:42 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp75.cisco.com [10.21.64.75])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACI08316;
	Tue, 14 Aug 2001 13:19:19 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010814161912.00a36d90@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 16:20:30 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] terminology design team
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I didn't write down who's going to be shepherding the terminology
design team, and it doesn't appear in the draft minutes (which I'll
have to you by the end of the week).  Does anybody remember who took
this on?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 17:17:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15355
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 17:17:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06089;
	Tue, 14 Aug 2001 17:13:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06060
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 17:13:23 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15257
	for <midcom@ietf.org>; Tue, 14 Aug 2001 17:12:10 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D907X; Tue, 14 Aug 2001 17:12:52 -0400
Message-Id: <3.0.5.32.20010814170017.00994d80@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 14 Aug 2001 17:00:17 -0400
To: Jiri Kuthan <kuthan@fokus.gmd.de>, Mark Duffy <mduffy@quarrytech.com>,
        Scott Brim <sbrim@cisco.com>, midcom mail-list <midcom@ietf.org>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
In-Reply-To: <5.1.0.14.0.20010814101652.029f1420@mailhub.fokus.gmd.de>
References: <3.0.5.32.20010813121728.0091a430@email.quarrytech.com>
 <20010811223138.D500@SBRIM-W2K>
 <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
 <002b01c11f3e$12a32640$b89221d9@acmepacket.com>
 <3.0.5.32.20010808091641.007e45c0@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Jiri, I agree with you and I retract my comment below.  I do not actually
think it is necessary that the midcom protocol  allow manipulating the
descriptor and actions independently.

The way I initially got started on this was that in the framework-03, it
doesn't clearly separate out the _concepts_ of descriptor and action (or
whatever we are going to call them).  I do think we need to separate those
concepts, so that for instance we can use the same descriptor
representation whether it is being used with a FW pinhole or a NAT binding
or whatever.  

I went a little too far in suggesting that the protocol needed to provide a
way to manipulate the concepts separately.

-Mark

At 10:47 AM 8/14/01 +0200, Jiri Kuthan wrote:
>What you suggest seems to me to exceed requirements and run into protocol
>specification. The minimum midcom protocol operations that seem required to 
>me are request for opening/closing pinholes and querying/releasing NAT 
>translations.
>
>One might implement the same thing in a variety of ways. For example, I might
>implement the same behaviour as you describe using a "set state" and
>"release state" operation where "set" is used to communicate and
>set full per-flow state (new or existing). There are certainly some
>designers who would prefer this "set-full-state" approach to
"delta-operations" 
>as it features higher robustness.
>
>Anyway, I see requirements for robustness and the operations above.
>How the protocol exactly looks like is TBD.
>
>-Jiri
>
>At 06:17 PM 8/13/2001, Mark Duffy wrote:
>>Yes, Bob Penfield had the same reaction and I told him I agreed ...   The
>>original point I intended to make was that the agent should be able to
>>manipulate the descriptor and actions independently, to whatever extent
>>that make sense.  I think add/delete actions to an existing descriptor
>>covers it just fine.
>
>

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 17:42:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15633
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 17:42:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06787;
	Tue, 14 Aug 2001 17:39:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06757
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 17:39:32 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15600
	for <midcom@ietf.org>; Tue, 14 Aug 2001 17:38:19 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D909L; Tue, 14 Aug 2001 17:39:02 -0400
Message-Id: <3.0.5.32.20010814173816.007d0b00@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 14 Aug 2001 17:38:16 -0400
To: Pyda Srisuresh <srisuresh@yahoo.com>, Scott Brim <sbrim@cisco.com>,
        midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
In-Reply-To: <20010814183936.13777.qmail@web13807.mail.yahoo.com>
References: <20010814124452.V1512@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

First Mark wrote:
>> > > Alternatively they may not be addressed to the agent
>> > > node but may be constrained by other factors to flow through it.

Then Suresh asked: 
>> > Are you suggesting that a middlebox can be a MIDCOM agent to another
>> > middlebox? This can happen, when packets are not targeted to the
>> > MIDCOM agent.

Then Scott said:
>> Consider an FTP agent.  The client application knows nothing about the
>> agent (otherwise it would just be a proxy).  It's sending its packets
>> toward what it believes is the address of its remote peer.  Some of
>> those packets are FTP signaling, and some are data.  The agent wiretaps
>> the FTP communications in general and communicates with the middlebox to
>> make sure the client succeeds.  This is just like NAT+ALG today, except
>> for the separation of the NAT and ALG functions and the midcom protocol
>> between them.  As the text points out, the packets are not addressed to
>> the agent, they just flow through it.

Then Suresh said:
>Yes. This is what I was refering to. The text suggests allowing a 
>middlebox to be a MIDCOM agent to another middlebox. I am not necessarily
>against this. I wanted this to be explicitly understood and agreed upon,
>so this doesnt show up later on during last call or IESG review or what
>have you.

Then Mark said:
Scott's description of the ftp agent is an excellent example of what
I had in mind.  I am a bit mystified as to what in the proposed text 
is leading Suresh to his conclusion.  I don't see anything in the text
to suggest that one mb is acting as agent to another mb.

I think it was Scott who pointed out the irony a few weeks back that
a midcom agent (or the box hosting it) is actually a middlebox of
sorts.  At least, under the definition of middlebox in
draft-carpenter-midtax-02.txt.  Framework-03 seems to narrow the
definition somewhat.  BUT, all that is the case whether the agent
is being addressed at the IP layer or not and I don't see a
connection between that and the text I have proposed for section 2.8.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 14 18:41:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16448
	for <midcom-archive@odin.ietf.org>; Tue, 14 Aug 2001 18:41:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08662;
	Tue, 14 Aug 2001 18:41:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08628
	for <midcom@ns.ietf.org>; Tue, 14 Aug 2001 18:41:12 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16407
	for <midcom@ietf.org>; Tue, 14 Aug 2001 18:40:00 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0AB8; Tue, 14 Aug 2001 18:40:41 -0400
Message-Id: <3.0.5.32.20010814183934.009929f0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 14 Aug 2001 18:39:34 -0400
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration (where addresses lie)
In-Reply-To: <20010814093957.I1512@SBRIM-W2K>
References: <3.0.5.32.20010813134926.0091a750@email.quarrytech.com>
 <3.0.5.32.20010810065723.009265a0@email.quarrytech.com>
 <5.1.0.14.0.20010809173557.00af8458@mailhub.fokus.gmd.de>
 <3.0.5.32.20010808102142.007df320@email.quarrytech.com>
 <3B713214.11AE0A1@cisco.com>
 <3B700C72.35EC5BD8@cisco.com>
 <20010808105712.I1592@SBRIM-W2K>
 <5.1.0.14.0.20010813164939.02a09ea8@mailhub.fokus.gmd.de>
 <3.0.5.32.20010813134926.0091a750@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Err.. I don't know too much about twice nat but I just had a quick look and
I don't think that is what I was getting at.  It looks like twice NAT is
for when public addresess have been reused in a private realm and so there
is ambiguity when such an address is the destination.

My scenario was about a network based middlebox serving multiple
enterprises.  Say each enterprise is separately using network 10.0.0.0/8
and the middlebox wants to provide each with vanilla NAT.  Assume that the
NATs are logically independent of one another so that from the perspective
of one enterprise and its instance of NAT it doesn't matter that the other
enterprises are using NATs within the same physical box.

Now if an agent comes along and wants to talk to the mb about a nat binding
between 10.1.2.3 and 192.1.2.3, the middlebox cannot tell *just from the
addresses* which realm or interface the request relates to.  What it needs
in addition is either an explicit specification of the realm or interface,
or some some higher-level context that makes it implicit which
realm/interface the request relates to.  Either way, it seems to me this
information needs to come from the agent.  If you consider that this is
really a case of a number of logically independent middleboxes in the same
physical box, you may come to the conclusion that this is really just
another case of the agent needing to know *which* middlebox to talk to.

-- Mark

At 09:39 AM 8/14/01 -0400, you wrote:
>On Mon, Aug 13, 2001 at 01:49:26PM -0400, Mark Duffy apparently wrote:
>> Middleboxes dealing with NAT and/or VPNs are typically dealing with
>> overlapping (non unique) address spaces and therefore cannot necessarily
>> determine 'where' particular IP addresses lie.
>
>This is the "Twice NAT" scenario (rfc2663).  When you have overlapping
>address spaces, you use a DNS ALG to trap DNS requests and assign a
>unique address, which is then used for actual communication with the
>remote device.  Therefore, from the point of view of the midcom
>protocol, which doesn't care about all that initial setup, an address
>always "appears" to be either inside or outside.
>
>(The DNS ALG is interesting, since you could put that in an agent of its
>own.)
>
>..Scott


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 04:32:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10934
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 04:32:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29039;
	Wed, 15 Aug 2001 04:30:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29008
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 04:30:56 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10901
	for <midcom@ietf.org>; Wed, 15 Aug 2001 04:29:43 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7F8UtQ29616
	for <midcom@ietf.org>; Wed, 15 Aug 2001 04:30:55 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA15951; Wed, 15 Aug 2001 10:30:54 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA15928; Wed, 15 Aug 2001 10:30:50 +0200 (MET DST)
Message-ID: <3B7A336B.90C77C14@lucent.com>
Date: Wed, 15 Aug 2001 10:31:39 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Bradner <sob@harvard.edu>, mshore@cisco.com, midcom@ietf.org
Subject: Re: [midcom] Filtering rules
References: <200108141215.IAA01017@newdev.harvard.edu> <3B791802.DC2EE64@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Scott,

after having slept a night over this issue. I believe you are right. Just
the 5-tuple will do nicely for anything we may come up with at the moment
and it will not unduly inconvenience us when selecting a protocol.

paul

Paul Sijben wrote:
> 
> Scott,
> 
> > also - I see no reason that the midcom protocol needs to change just
> > because of a change in filter rules - any such rules should be
> > sent in a chunk to the midcom box which can then say 'can not do' if
> > it does not know how to do what has been asked
> 
> I can agree with you there if we were to create a _new_ protocol. Yet we
> are supposed to _select_ one that exists when the requirements are done.
> So the power we may seek in the filtering may guide our protocol choice.
> 
> Paul
> 
> Scott Bradner wrote:
> >
> > > I would appreciate some guidance in this matter from the ADs. If we can
> > > not specify in enough detail WHAT we want to filter/transform etc on.
> > > Selecting a protocol will be impossible and we will need to go through
> > > another (semi) requirements round to get additional information.
> >
> > I see no need to spend time at this point figuring out all possible filters
> > I would like the WG to define a basic 'punch a pinhole' function for
> > a single stream and identify the stream in the simplest possible way.
> > i.e. 5-tuples
> >
> > this should be sufficient to get something that will work - when that
> > is done we can worry about creating the filter language from hell if
> > that is what the Internet community feels it needs.
> >
> > also - I see no reason that the midcom protocol needs to change just
> > because of a change in filter rules - any such rules should be
> > sent in a chunk to the midcom box which can then say 'can not do' if
> > it does not know how to do what has been asked
> >
> > Scott (the AD in question)
> 
> --
> Paul Sijben              Tel:+31 356874774
> Lucent Technologies      Fax:+31 356875954
> Forward Looking Work
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 07:01:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12601
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 07:01:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02132;
	Wed, 15 Aug 2001 06:53:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02103
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 06:53:49 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12180
	for <midcom@ietf.org>; Wed, 15 Aug 2001 06:52:36 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7FArJQ06173;
	Wed, 15 Aug 2001 03:53:19 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7FArG426858;
	Wed, 15 Aug 2001 03:53:17 -0700 (PDT)
Message-ID: <3B7A440D.290B508@cisco.com>
Date: Wed, 15 Aug 2001 02:42:37 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Molitor <amolitor@visi.com>
CC: midcom@ietf.org
Subject: Re: Topology, pinholes and policy roles (was RE: [midcom] policy 
 &duration)
References: <Pine.GSO.4.21.0108141108590.18585-100000@isis.visi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Andrew,

Having a midcom agent know what's inside is easy.  One doesn't need
protocol support for that.  One needs a few configuration entries.
--
Eliot Lear
lear@cisco.com


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 08:11:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15174
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 08:11:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03833;
	Wed, 15 Aug 2001 08:04:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03800
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 08:04:05 -0400 (EDT)
Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14804
	for <midcom@ietf.org>; Wed, 15 Aug 2001 08:02:52 -0400 (EDT)
Message-ID: <20010815120405.38902.qmail@web13807.mail.yahoo.com>
Received: from [65.12.33.187] by web13807.mail.yahoo.com; Wed, 15 Aug 2001 05:04:05 PDT
Date: Wed, 15 Aug 2001 05:04:05 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
In-Reply-To: <20010814144839.A1756@SBRIM-W2K>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--- Scott Brim <sbrim@cisco.com> wrote:
> See bottom ...
> 
> On Tue, Aug 14, 2001 at 11:39:36AM -0700, Pyda Srisuresh apparently wrote:
> > 
> > --- Scott Brim <sbrim@cisco.com> wrote:
> > > On Tue, Aug 14, 2001 at 09:34:50AM -0700, Pyda Srisuresh apparently
> wrote:
> > > > > Only "In-Path MIDCOM agents" are considered in this document. In-Path
> > > Midcom
> > > > > agents are agents which are within the path of those datagrams that
> the
> > > agent
> > > > > needs to examine and/or modify in fulfilling its role as a MIDCOM
> agent.
> > > > > "Within the path" here simply means that the packets in question flow
> > > through
> > > > > the node that hosts the agent.  The packets may be addressed to the
> agent
> > > > > node at the IP layer.  Alternatively they may not be addressed to the
> > > agent
> > > >                         
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > node but may be constrained by other factors to flow through it. In
> fact,
> > > it
> > > >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > 
> > > > Are you suggesting that a middlebox can be a MIDCOM agent to another
> > > > middlebox? This can happen, when packets are not targeted to the
> > > > MIDCOM agent.
> > > 
> > > By definition the middlebox function and agent function are distinct
> > > (although they could be in the same physical enclosure).  However, I
> > > don't believe that's what he's talking about.
> > > 
> > Sure, I wasnt alluding to that either.
> > 
> > > Consider an FTP agent.  The client application knows nothing about the
> > > agent (otherwise it would just be a proxy).  It's sending its packets
> > > toward what it believes is the address of its remote peer.  Some of
> > > those packets are FTP signaling, and some are data.  The agent wiretaps
> > > the FTP communications in general and communicates with the middlebox to
> > > make sure the client succeeds.  This is just like NAT+ALG today, except
> > > for the separation of the NAT and ALG functions and the midcom protocol
> > > between them.  As the text points out, the packets are not addressed to
> > > the agent, they just flow through it.
> > > 
> > Yes. This is what I was refering to. The text suggests allowing a 
> > middlebox to be a MIDCOM agent to another middlebox. I am not necessarily
> > against this. I wanted this to be explicitly understood and agreed upon,
> > so this doesnt show up later on during last call or IESG review or what
> > have you.
> > 
> > Perhaps, you could track this along with the requirements you are tracking
> > - debated, agreed-upon etc...
> 
> So, the text for the requirement would be "A middlebox can be an agent
> to another middlebox"?
> 

The requirement I was alluding to is the following.
A MIDCOM agent function can be resident on transit as well as termination
devices that are in the message path of an application. A middlebox is a 
a transit device.
 
> I'm willing to put it in (I just line 'em up, anyone can bowl 'em over),
> but (1) I still don't see how the text above leads to that idea, and (2)

If I am still not making myself clear, let us drop this thread.

> I don't think it makes sense.  Perhaps a single physical enclosure could
> contain both a middlebox function and an agent for some other middlebox,
> but those would still be distinct functions.
> 
> I don't understand how you envision things.  Just because packets are
> flowing through something doesn't make it a middlebox.  In the above,
> what is the agent doing that makes it a middlebox?
> 
See my comment above. Not every transit box is a middlebox. But, a
middlebox is a transit box. The comment I made refers to transit
boxes; and hence, by that implication to middleboxes.

> ..Scott
> 
regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 08:14:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15363
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 08:14:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03987;
	Wed, 15 Aug 2001 08:14:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03958
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 08:14:36 -0400 (EDT)
Received: from web13803.mail.yahoo.com (web13803.mail.yahoo.com [216.136.175.13])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15316
	for <midcom@ietf.org>; Wed, 15 Aug 2001 08:13:22 -0400 (EDT)
Message-ID: <20010815121435.25958.qmail@web13803.mail.yahoo.com>
Received: from [65.12.33.187] by web13803.mail.yahoo.com; Wed, 15 Aug 2001 05:14:35 PDT
Date: Wed, 15 Aug 2001 05:14:35 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
To: Mark Duffy <mduffy@quarrytech.com>, Scott Brim <sbrim@cisco.com>,
        midcom@ietf.org
In-Reply-To: <3.0.5.32.20010814173816.007d0b00@email.quarrytech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--- Mark Duffy <mduffy@quarrytech.com> wrote:
> First Mark wrote:
> >> > > Alternatively they may not be addressed to the agent
> >> > > node but may be constrained by other factors to flow through it.
> 
> Then Suresh asked: 
> >> > Are you suggesting that a middlebox can be a MIDCOM agent to another
> >> > middlebox? This can happen, when packets are not targeted to the
> >> > MIDCOM agent.
> 
> Then Scott said:
> >> Consider an FTP agent.  The client application knows nothing about the
> >> agent (otherwise it would just be a proxy).  It's sending its packets
> >> toward what it believes is the address of its remote peer.  Some of
> >> those packets are FTP signaling, and some are data.  The agent wiretaps
> >> the FTP communications in general and communicates with the middlebox to
> >> make sure the client succeeds.  This is just like NAT+ALG today, except
> >> for the separation of the NAT and ALG functions and the midcom protocol
> >> between them.  As the text points out, the packets are not addressed to
> >> the agent, they just flow through it.
> 
> Then Suresh said:
> >Yes. This is what I was refering to. The text suggests allowing a 
> >middlebox to be a MIDCOM agent to another middlebox. I am not necessarily
> >against this. I wanted this to be explicitly understood and agreed upon,
> >so this doesnt show up later on during last call or IESG review or what
> >have you.
> 
> Then Mark said:
> Scott's description of the ftp agent is an excellent example of what
> I had in mind.  I am a bit mystified as to what in the proposed text 
> is leading Suresh to his conclusion.  I don't see anything in the text
> to suggest that one mb is acting as agent to another mb.
> 

Mark - Please see my response to Scott. The text suggests any intermediate
device (whether terminating the traffic as in Proxy/Gateway/VPN tunnel or
merely transiting the traffic as in switch/router/middlebox) as a 
candidate for hosting MIDCOM agent. The former was discussed in the 
past. The latter seemed like a new revelation. 

I am not disagreeing with the text, per se. I wanted the distinction to
be recognozed and agreed upon (for future reference). Thanks.

<... stuff deleted>

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 08:22:38 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15921
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 08:22:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04163;
	Wed, 15 Aug 2001 08:23:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04087
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 08:23:02 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15858
	for <midcom@ietf.org>; Wed, 15 Aug 2001 08:21:44 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7FCMVQ04650;
	Wed, 15 Aug 2001 05:22:31 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp71.cisco.com [10.21.64.71])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACJ03885;
	Wed, 15 Aug 2001 05:22:24 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010815082141.00a3bb40@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 08:23:54 -0400
To: Pyda Srisuresh <srisuresh@yahoo.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
In-Reply-To: <20010815121435.25958.qmail@web13803.mail.yahoo.com>
References: <3.0.5.32.20010814173816.007d0b00@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 05:14 AM 8/15/01 -0700, Pyda Srisuresh wrote:
>Mark - Please see my response to Scott. The text suggests any intermediate
>device (whether terminating the traffic as in Proxy/Gateway/VPN tunnel or
>merely transiting the traffic as in switch/router/middlebox) as a 
>candidate for hosting MIDCOM agent. The former was discussed in the 
>past. The latter seemed like a new revelation. 

I really don't think so.  We've already agreed that we're talking
about functions, not boxes, and that we're not constraining the
placement of functions (other than packet diversion not being
in scope).

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 09:08:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18346
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 09:08:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05208;
	Wed, 15 Aug 2001 09:07:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05181
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 09:07:56 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18248
	for <midcom@ietf.org>; Wed, 15 Aug 2001 09:06:42 -0400 (EDT)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7FD7Jq29620;
	Wed, 15 Aug 2001 15:07:19 +0200
Message-Id: <5.1.0.14.0.20010815140017.028684d0@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 15:15:04 +0200
To: Andrew Molitor <amolitor@visi.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] policy & duration
In-Reply-To: <Pine.GSO.4.21.0108141204260.25650-100000@isis.visi.com>
References: <5.1.0.14.0.20010814180034.029d0c58@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 07:17 PM 8/14/2001, Andrew Molitor wrote:
>        Despite the ongoing thread, I think Jiri and I are in almost
>complete agreement ;)

I sincerely wish we were but I am not entirely sure. Particularly,
I still do not understand *HOW* the SIP proxy would learn whether
a participant is or is not inside. Can you be please more specific
on that?

(More generally, I do not expect applications to have better knowledge
 of IP topology than a router does. Indeed, I think it is a great design
 feature rather than a bug.)

>        Nontheless, a SIP Proxy may well be able to determine that
>there isn't a sip:jiri@iptel.org currently located "inside" and thereby
>deduce that you are somewhere else.



>> So you might try looking at IP addresses in SDP payloads. My point is, 
>> however, that a SIP middlebox is not able to infer the expected
>> direction in this case any better than a middlebox is. If a SIP proxy 
>> knows from SDP payloads that media will flow from A to B, the middlebox
>> will know it too. So where do you want to build the direction-guessing 
>> logic? In one middlebox or in ten different agents?
>
>        My point is actually slightly different. The Agent in general
>has to sort out which middlebox(es), if any, to talk to. Consider a
>simple case of an enterprise, if a call is phone-to-phone inside,
>the Agent Must Not do a NAT binding on the middlebox connecting
>the Enterprise to the outside world. If it did, the INVITE sent
>to the target phone (in the next cubicle) would have been re-written
>to use an external address for the media back to the originating
>phone. This can be solved through squirrelly routing which
>hairpins media out through the middlebox and back in, but it's
>exceedingly ugly.

I'm glad you gave this specific example. It shows the choice of putting
direction-guessing-logic in agent. The protocol conversation could then
look like "A: please, allocate a translation from address A in realm
RA to address B in RB. MB: Yes, sir." The opposite choice is to have the
piece of logic in the middlebox. Fictive conversation example: "A: Please,
allocate a translation from A to B. MB: No translation needed."

Our implementation takes the second way. Why? Because we have limited
manpower and do not want to replicate the same direction-guessing-logic 
in every possible agent. 


[...]

>        The middlebox is, in the abstract, far less capable of guessing
>direction and location of endpoints since information is lost. 

Which specific piece of information that may help you to figure out the
direction gets lost?

-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 09:08:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18357
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 09:08:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05265;
	Wed, 15 Aug 2001 09:08:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05235
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 09:08:33 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18275
	for <midcom@ietf.org>; Wed, 15 Aug 2001 09:07:18 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7FD8FT29223
	for <midcom@ietf.org>; Wed, 15 Aug 2001 06:08:16 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-50.cisco.com [10.21.96.50])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJK12065;
	Wed, 15 Aug 2001 06:07:58 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 15 Aug 2001 09:08:01 -0400
Date: Wed, 15 Aug 2001 09:08:01 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] proposed text for framework sect. 2.8
Message-ID: <20010815090801.H2068@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010814144839.A1756@SBRIM-W2K> <20010815120405.38902.qmail@web13807.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010815120405.38902.qmail@web13807.mail.yahoo.com>; from srisuresh@yahoo.com on Wed, Aug 15, 2001 at 05:04:05AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 15, 2001 at 05:04:05AM -0700, Pyda Srisuresh apparently wrote:
> > So, the text for the requirement would be "A middlebox can be an agent
> > to another middlebox"?
> > 
> 
> The requirement I was alluding to is the following.
> A MIDCOM agent function can be resident on transit as well as termination
> devices that are in the message path of an application. A middlebox is a 
> a transit device.

Aha.  I thought you might be talking about an assumption that agents
terminate packets, but I didn't think that made sense.

I think this is a framework issue, a concept/terminology issue, not a
requirement.

You might recall I had trouble with the framework terminology to start
with but, when I finally understood it, I thought you had everything
nicely internally consistent.  Now I'm having trouble again.  The
framework says "MIDCOM agents are entities performing ALG function", and
"An ALG examines application traffic in transit and assists middlebox in
carrying out its function." Note the "in transit", which says to me that
the packets continue on their course.  The only thing mentioned which
actually terminates sessions is a proxy.

Do you really think an agent function terminates all packets it responds
to?  

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 09:10:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18539
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 09:10:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05343;
	Wed, 15 Aug 2001 09:10:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05312
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 09:10:43 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18482
	for <midcom@ietf.org>; Wed, 15 Aug 2001 09:09:28 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7FDAGQ21987
	for <midcom@ietf.org>; Wed, 15 Aug 2001 06:10:16 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-50.cisco.com [10.21.96.50])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJK12083;
	Wed, 15 Aug 2001 06:10:11 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 15 Aug 2001 09:10:14 -0400
Date: Wed, 15 Aug 2001 09:10:14 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] proposed text for framework sect. 2.8
Message-ID: <20010815091014.I2068@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3.0.5.32.20010814173816.007d0b00@email.quarrytech.com> <20010815121435.25958.qmail@web13803.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010815121435.25958.qmail@web13803.mail.yahoo.com>; from srisuresh@yahoo.com on Wed, Aug 15, 2001 at 05:14:35AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 15, 2001 at 05:14:35AM -0700, Pyda Srisuresh apparently wrote:
> Mark - Please see my response to Scott. The text suggests any intermediate
> device (whether terminating the traffic as in Proxy/Gateway/VPN tunnel or
> merely transiting the traffic as in switch/router/middlebox) as a 
> candidate for hosting MIDCOM agent. The former was discussed in the 
> past. The latter seemed like a new revelation. 

I don't think so.  A function is defined as an agent based on that fact
that it uses the midcom protocol to speak with one or more middleboxes.
Whether it is explicitly addressed by the client, or it is just
triggered by packets going by -- and whether it terminates/regenerates
packets or just notices them in transit -- is orthogonal to its being an
agent.

This is all framework stuff.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 09:26:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19292
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 09:26:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05589;
	Wed, 15 Aug 2001 09:26:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05560
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 09:26:31 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19211
	for <midcom@ietf.org>; Wed, 15 Aug 2001 09:25:14 -0400 (EDT)
Received: from MDUFFY ([10.1.1.16]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0AYZ; Wed, 15 Aug 2001 09:25:55 -0400
Message-Id: <3.0.5.32.20010815092509.00851b40@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 15 Aug 2001 09:25:09 -0400
To: Jiri Kuthan <kuthan@fokus.gmd.de>, Andrew Molitor <amolitor@visi.com>,
        midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] policy & duration
In-Reply-To: <5.1.0.14.0.20010815140017.028684d0@mailhub.fokus.gmd.de>
References: <Pine.GSO.4.21.0108141204260.25650-100000@isis.visi.com>
 <5.1.0.14.0.20010814180034.029d0c58@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

>I'm glad you gave this specific example. It shows the choice of putting
>direction-guessing-logic in agent. The protocol conversation could then
>look like "A: please, allocate a translation from address A in realm
>RA to address B in RB. MB: Yes, sir." The opposite choice is to have the
>piece of logic in the middlebox. Fictive conversation example: "A: Please,
>allocate a translation from A to B. MB: No translation needed."
>
>Our implementation takes the second way. Why? Because we have limited
>manpower and do not want to replicate the same direction-guessing-logic 
>in every possible agent. 

Jiri, no matter how smart the middlebox is, doesn't each agent need
sufficient topological information that it can determine which middlebox to
make a request of?  Given that the agent must know that, it seems to me to
be a very small increment in knowledge for the agent to know the direction
of the flow relative to that middlebox.

-Mark


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 09:54:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20844
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 09:54:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06187;
	Wed, 15 Aug 2001 09:54:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06153
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 09:54:12 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20812
	for <midcom@ietf.org>; Wed, 15 Aug 2001 09:52:59 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7FDrLJ17961;
	Wed, 15 Aug 2001 08:53:21 -0500
From: "Ram Dantu" <ramd@netrake.com>
To: "Melinda Shore" <mshore@cisco.com>, "Pyda Srisuresh" <srisuresh@yahoo.com>,
        <midcom@ietf.org>
Subject: RE: [midcom] proposed text for framework sect. 2.8
Date: Wed, 15 Aug 2001 08:53:21 -0500
Message-ID: <AEEDLFNKBFAGGEGOFBPIGEOCCBAA.ramd@netrake.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.1.0.14.0.20010815082141.00a3bb40@mira-sjc5-4.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I completely support Melinda's statement ("we are talking about functions
not boxes). Infact, in some cases, the Middlebox (as a physical entity)
may be in the path of the SIP messages and then the MIDCOM-agent function
can be
inside the this particular Middlebox.

Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Melinda Shore
Sent: Wednesday, August 15, 2001 7:24 AM
To: Pyda Srisuresh; midcom@ietf.org
Subject: Re: [midcom] proposed text for framework sect. 2.8


At 05:14 AM 8/15/01 -0700, Pyda Srisuresh wrote:
>Mark - Please see my response to Scott. The text suggests any intermediate
>device (whether terminating the traffic as in Proxy/Gateway/VPN tunnel or
>merely transiting the traffic as in switch/router/middlebox) as a
>candidate for hosting MIDCOM agent. The former was discussed in the
>past. The latter seemed like a new revelation.

I really don't think so.  We've already agreed that we're talking
about functions, not boxes, and that we're not constraining the
placement of functions (other than packet diversion not being
in scope).

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 09:59:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21025
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 09:59:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06338;
	Wed, 15 Aug 2001 09:59:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06309
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 09:59:04 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20959
	for <midcom@ietf.org>; Wed, 15 Aug 2001 09:57:51 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7FDwpT21107
	for <midcom@ietf.org>; Wed, 15 Aug 2001 06:58:51 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-50.cisco.com [10.21.96.50])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJK12329;
	Wed, 15 Aug 2001 06:58:32 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 15 Aug 2001 09:58:35 -0400
Date: Wed, 15 Aug 2001 09:58:35 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
Message-ID: <20010815095835.K2068@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <Pine.GSO.4.21.0108141204260.25650-100000@isis.visi.com> <5.1.0.14.0.20010814180034.029d0c58@mailhub.fokus.gmd.de> <5.1.0.14.0.20010815140017.028684d0@mailhub.fokus.gmd.de> <3.0.5.32.20010815092509.00851b40@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.5.32.20010815092509.00851b40@email.quarrytech.com>; from mduffy@quarrytech.com on Wed, Aug 15, 2001 at 09:25:09AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 15, 2001 at 09:25:09AM -0400, Mark Duffy apparently wrote:
> Jiri, no matter how smart the middlebox is, doesn't each agent need
> sufficient topological information that it can determine which middlebox to
> make a request of?  Given that the agent must know that, it seems to me to
> be a very small increment in knowledge for the agent to know the direction
> of the flow relative to that middlebox.

There are alternatives which don't require it to have topology
knowledge.  For example discovery mechanisms such as (1) service
location protocol, and (2) anycast.  The C15N BOF kind of fizzled, it
seems, but it indicated some work on discovery done somewhere else.  

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 10:14:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21674
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 10:14:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06881;
	Wed, 15 Aug 2001 10:13:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06851
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 10:13:51 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21618
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:12:38 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7FEDDJ18889;
	Wed, 15 Aug 2001 09:13:13 -0500
From: "Ram Dantu" <ramd@netrake.com>
To: "Scott Brim" <sbrim@cisco.com>, <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Wed, 15 Aug 2001 09:13:13 -0500
Message-ID: <AEEDLFNKBFAGGEGOFBPICEOECBAA.ramd@netrake.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010815095835.K2068@SBRIM-W2K>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

It seems to me that it is really a burden on the agent
if it is required to run a middlebox discovery protocol.

I agree that agent can have
some toplogy related information for
controlling the services in the middlebox
but why should it be part of MIDCOM protocol ?


Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Scott Brim
Sent: Wednesday, August 15, 2001 8:59 AM
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration


On Wed, Aug 15, 2001 at 09:25:09AM -0400, Mark Duffy apparently wrote:
> Jiri, no matter how smart the middlebox is, doesn't each agent need
> sufficient topological information that it can determine which middlebox
to
> make a request of?  Given that the agent must know that, it seems to me to
> be a very small increment in knowledge for the agent to know the direction
> of the flow relative to that middlebox.

There are alternatives which don't require it to have topology
knowledge.  For example discovery mechanisms such as (1) service
location protocol, and (2) anycast.  The C15N BOF kind of fizzled, it
seems, but it indicated some work on discovery done somewhere else.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 10:24:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21999
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 10:24:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07181;
	Wed, 15 Aug 2001 10:24:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07150
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 10:24:48 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21973
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:23:35 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7FEOUn01183
	for <midcom@ietf.org>; Wed, 15 Aug 2001 07:24:30 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-50.cisco.com [10.21.96.50])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJK12542;
	Wed, 15 Aug 2001 07:24:17 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 15 Aug 2001 10:24:20 -0400
Date: Wed, 15 Aug 2001 10:24:20 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
Message-ID: <20010815102420.M2068@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <20010815095835.K2068@SBRIM-W2K> <AEEDLFNKBFAGGEGOFBPICEOECBAA.ramd@netrake.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <AEEDLFNKBFAGGEGOFBPICEOECBAA.ramd@netrake.com>; from ramd@netrake.com on Wed, Aug 15, 2001 at 09:13:13AM -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 15, 2001 at 09:13:13AM -0500, Ram Dantu apparently wrote:
> It seems to me that it is really a burden on the agent
> if it is required to run a middlebox discovery protocol.

There's no need, you can configure static information, just as in any
other case.  What would you propose instead of a discovery protocol?

> I agree that agent can have
> some toplogy related information for
> controlling the services in the middlebox
> but why should it be part of MIDCOM protocol ?

I didn't say it should.  I must be missing something.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 10:39:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22542
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 10:39:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07738;
	Wed, 15 Aug 2001 10:37:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07705
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 10:37:30 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22458
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:36:17 -0400 (EDT)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7FEZtq30003;
	Wed, 15 Aug 2001 16:35:55 +0200
Message-Id: <5.1.0.14.0.20010815160519.00a84cc8@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 16:43:36 +0200
To: Mark Duffy <mduffy@quarrytech.com>, Andrew Molitor <amolitor@visi.com>,
        midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] policy & duration
In-Reply-To: <3.0.5.32.20010815092509.00851b40@email.quarrytech.com>
References: <5.1.0.14.0.20010815140017.028684d0@mailhub.fokus.gmd.de>
 <Pine.GSO.4.21.0108141204260.25650-100000@isis.visi.com>
 <5.1.0.14.0.20010814180034.029d0c58@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 03:25 PM 8/15/2001, Mark Duffy wrote:
>Jiri, no matter how smart the middlebox is, doesn't each agent need
>sufficient topological information that it can determine which middlebox to
>make a request of?  

Mark, 

yes, an agent needs to know where to send its requests. (IP address, port number)

>Given that the agent must know that, it seems to me to
>be a very small increment in knowledge for the agent to know the direction
>of the flow relative to that middlebox.

The real question for me is from what we infer the realms. Let us assume
we infer it from IP addresses. In a simple case, a table stating 
"192.168.99.* belongs to an internal realm whereas anything else belongs 
to an outside realm" could work. Alas, such a table might be much more 
complex. You would have to build it in every agent (does a SIP proxy
implementor really want to do that?). You would have to configure
every agent (Does every admin want to do that and update all app-agent
configuration files whenever things change?)

To answer your question: one could certainly put this piece of logic in
agents. However, it seems to me more difficult than the other way around. 
It would sound different to me if an application agent could infer realm 
from its application-layer knowledge. I am currently not aware of such 
a scenario -- if someone knows, please post it.

-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 10:53:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22920
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 10:53:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07955;
	Wed, 15 Aug 2001 10:52:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07924
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 10:52:17 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22881
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:51:03 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7FEpZJ20511;
	Wed, 15 Aug 2001 09:51:35 -0500
From: "Ram Dantu" <ramd@netrake.com>
To: "Scott Brim" <sbrim@cisco.com>, <midcom@ietf.org>
Subject: RE: [midcom] policy & duration
Date: Wed, 15 Aug 2001 09:51:35 -0500
Message-ID: <AEEDLFNKBFAGGEGOFBPIOEOFCBAA.ramd@netrake.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010815102420.M2068@SBRIM-W2K>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


On Wed, Aug 15, 2001 at 09:13:13AM -0500, Ram Dantu apparently wrote:
> It seems to me that it is really a burden on the agent
> if it is required to run a middlebox discovery protocol.

Scott:
There's no need, you can configure static information, just as in any
other case.  What would you propose instead of a discovery protocol?

Ram:
I am not proposing anything expect static configuration
for this purpose. So, I strongly agree with your static config. proposal.

> I agree that agent can have
> some toplogy related information for
> controlling the services in the middlebox
> but why should it be part of MIDCOM protocol ?
Scott:
I didn't say it should.  I must be missing something.

Ram:
OK, we agree on this as well.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 11:01:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23081
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 11:01:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08387;
	Wed, 15 Aug 2001 11:00:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08358
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 11:00:57 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23014
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:59:43 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7FF0Sn25940
	for <midcom@ietf.org>; Wed, 15 Aug 2001 08:00:28 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp71.cisco.com [10.21.64.71])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACJ06070;
	Wed, 15 Aug 2001 08:00:15 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010815093054.00a3bd00@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 11:01:43 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Going through the requirements
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

We really need to hunker down and get the outstanding issues
resolved.  Some of them have been farmed out to design teams
or have been otherwise taken off the mailing list temporarily,
but some have not.  I've tried to categorize the unresolved 
requirements.  In cases where the requirement fits more than one
category I've placed it in the gating category.

Note that the list of unresolved issues is long.  Beginning this
afternoon I'm going to start sending out mail working through
the list.  We're spinning our wheels and need to focus on getting 
these documents finished.

Melinda

Going through http://www.employees.org/~swb/midreqs/midcom-reqs-bullets-010810.txt,
these issues need attention now:

R79-80
R1a
R3a1-R3a2
R3b
R10
R13
R14
R15
R16
R78
R19
R20
R25
R27
R29
R30
R32
R33
R35
R38
R40 (although we've received guidance on this from our AD)
R42
R43
R45
R46
R48
R50 (see R40)
R51 (ditto)
R52 (ditto again)
R60
R63
R65
R71
R74
R75

These have terminological issues:

R6
R79
R47

These are being resolved by design teams and being brought
back to the WG:

R5
R59
R11
R44
R53-R57
R68



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 11:12:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23270
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 11:12:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08569;
	Wed, 15 Aug 2001 11:11:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08540
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 11:11:18 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23218
	for <midcom@ietf.org>; Wed, 15 Aug 2001 11:10:05 -0400 (EDT)
Received: from BobP [62.254.249.43] by acmepacket.com
  (SMTPD32-6.05) id A07B3680011E; Wed, 15 Aug 2001 11:08:43 -0400
Message-ID: <015701c1259c$339652a0$2bf9fe3e@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Pyda Srisuresh" <srisuresh@yahoo.com>, <midcom@ietf.org>,
        "Mark Duffy" <mduffy@quarrytech.com>
References: <3.0.5.32.20010813231445.007d0700@email.quarrytech.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
Date: Wed, 15 Aug 2001 11:08:53 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I think Mark's text is excellent. I do not think any of the issues/questions
in the various e-mails in response to Mark necessitate a change. It is
beyond the scope of MIDCOM how the agents are "in-path".

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "Mark Duffy" <mduffy@quarrytech.com>
To: "Pyda Srisuresh" <srisuresh@yahoo.com>; <midcom@ietf.org>
Sent: Monday, August 13, 2001 11:14 PM
Subject: [midcom] proposed text for framework sect. 2.8


> >5. Section 2.8: Mark Duffy will propose new text to replace existing
> >   text. There was concern about whether or not intrusive MIDCOM agents
> >   (in the native path) should be considered In-Path agents.
>
> Here is the proposed text:
>
> 2.8. MIDCOM Agents
>
> MIDCOM agents are entities performing ALG functions, logically external to
a middlebox. MIDCOM agents possess a combination of application awareness
and knowledge of the middlebox function, which combination enables the
agents to facilitate traversal of the middlebox by the application's
packets. A MIDCOM agent may interact with one or more middleboxes.
>
> Only "In-Path MIDCOM agents" are considered in this document. In-Path
Midcom agents are agents which are within the path of those datagrams that
the agent needs to examine and/or modify in fulfilling its role as a MIDCOM
agent. "Within the path" here simply means that the packets in question flow
through the node that hosts the agent.  The packets may be addressed to the
agent node at the IP layer.  Alternatively they may not be addressed to the
agent node but may be constrained by other factors to flow through it. In
fact, it is immaterial to the MIDCOM protocol which of these is the case.
Some examples of In-Path MIDCOM agents are application proxies, gateways, or
even end-hosts that are party to the application.
>
> Agents not resident on nodes that are within the path of their relevant
application flows are refered to as "Out-of-Path (OOP) MIDCOM agents" and
are out of scope of this document.
>
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 11:16:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23364
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 11:16:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08682;
	Wed, 15 Aug 2001 11:14:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08650
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 11:14:28 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23295
	for <midcom@ietf.org>; Wed, 15 Aug 2001 11:13:14 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA27818
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:13:58 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 15 Aug 2001 10:12:19 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YHC841>; Wed, 15 Aug 2001 10:11:47 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF3C@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>, Jiri Kuthan <kuthan@fokus.gmd.de>,
        Andrew Molitor <amolitor@visi.com>, midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Wed, 15 Aug 2001 10:11:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1259C.995ADFC0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1259C.995ADFC0
Content-Type: text/plain;
	charset="iso-8859-1"


Since there'll be both types of implementations in the market, can we not
make the direction (or Realm) an optional element in the Midcom protocol
instead of a mandatory one? 

Or, even if the protocol element is there, a Middlebox implementation with
the capability to determine the direction, will chose to ignore it (i.e.
Middlebox's decision is final). 

Sanjoy

> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]
> Sent: Wednesday, August 15, 2001 8:25 AM
> To: Jiri Kuthan; Andrew Molitor; midcom@ietf.org
> Subject: Re: [midcom] policy & duration
> 
> 
> >I'm glad you gave this specific example. It shows the choice 
> of putting
> >direction-guessing-logic in agent. The protocol conversation 
> could then
> >look like "A: please, allocate a translation from address A in realm
> >RA to address B in RB. MB: Yes, sir." The opposite choice is 
> to have the
> >piece of logic in the middlebox. Fictive conversation 
> example: "A: Please,
> >allocate a translation from A to B. MB: No translation needed."
> >
> >Our implementation takes the second way. Why? Because we have limited
> >manpower and do not want to replicate the same 
> direction-guessing-logic 
> >in every possible agent. 
> 
> Jiri, no matter how smart the middlebox is, doesn't each agent need
> sufficient topological information that it can determine 
> which middlebox to
> make a request of?  Given that the agent must know that, it 
> seems to me to
> be a very small increment in knowledge for the agent to know 
> the direction
> of the flow relative to that middlebox.
> 
> -Mark
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C1259C.995ADFC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Since there'll be both types of implementations in =
the market, can we not make the direction (or Realm) an optional =
element in the Midcom protocol instead of a mandatory one? </FONT></P>

<P><FONT SIZE=3D2>Or, even if the protocol element is there, a =
Middlebox implementation with the capability to determine the =
direction, will chose to ignore it (i.e. Middlebox's decision is =
final). </FONT></P>

<P><FONT SIZE=3D2>Sanjoy</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 15, 2001 8:25 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Jiri Kuthan; Andrew Molitor; =
midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] policy &amp; =
duration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I'm glad you gave this specific example. It =
shows the choice </FONT>
<BR><FONT SIZE=3D2>&gt; of putting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;direction-guessing-logic in agent. The =
protocol conversation </FONT>
<BR><FONT SIZE=3D2>&gt; could then</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;look like &quot;A: please, allocate a =
translation from address A in realm</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;RA to address B in RB. MB: Yes, sir.&quot; =
The opposite choice is </FONT>
<BR><FONT SIZE=3D2>&gt; to have the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;piece of logic in the middlebox. Fictive =
conversation </FONT>
<BR><FONT SIZE=3D2>&gt; example: &quot;A: Please,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;allocate a translation from A to B. MB: No =
translation needed.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Our implementation takes the second way. =
Why? Because we have limited</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;manpower and do not want to replicate the =
same </FONT>
<BR><FONT SIZE=3D2>&gt; direction-guessing-logic </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;in every possible agent. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Jiri, no matter how smart the middlebox is, =
doesn't each agent need</FONT>
<BR><FONT SIZE=3D2>&gt; sufficient topological information that it can =
determine </FONT>
<BR><FONT SIZE=3D2>&gt; which middlebox to</FONT>
<BR><FONT SIZE=3D2>&gt; make a request of?&nbsp; Given that the agent =
must know that, it </FONT>
<BR><FONT SIZE=3D2>&gt; seems to me to</FONT>
<BR><FONT SIZE=3D2>&gt; be a very small increment in knowledge for the =
agent to know </FONT>
<BR><FONT SIZE=3D2>&gt; the direction</FONT>
<BR><FONT SIZE=3D2>&gt; of the flow relative to that middlebox.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -Mark</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1259C.995ADFC0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 11:17:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23386
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 11:17:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08726;
	Wed, 15 Aug 2001 11:14:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08695
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 11:14:56 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23311
	for <midcom@ietf.org>; Wed, 15 Aug 2001 11:13:38 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 8644F8127
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:14:52 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA21217
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:14:52 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 15 Aug 2001 10:14:52 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: Topology, pinholes and policy roles (was RE: [midcom] policy 
 &duration)
In-Reply-To: <3B7A440D.290B508@cisco.com>
Message-ID: <Pine.GSO.4.21.0108151005180.20816-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Wed, 15 Aug 2001, Eliot Lear wrote:

> Andrew,
> 
> Having a midcom agent know what's inside is easy.  One doesn't need
> protocol support for that.  One needs a few configuration entries.

	The issue of how the Agent knows what's inside, what's outside
and what's in Timbuktu is out of scope.

	There does need to be protocol support for something a little
more than a pure masked 5-tuple. As I have indicated many times, if
there isn't SOME way for the Agent to indicate to the middlebox which
end of the 5-tuple is expected to be (in the simple example) inside,
the middlebox serves no useful function beyond that of a switch, allowing
all traffic to flow in all directions.

	The only reason topology considerations arise at all is to counter
this argument: The Agent should not have to know enough about topology
to supply the inside/outside component to the middlebox

	The Agent DOES know enough. It won't work at all if it doesn't
know enough. Thus, it's not a problem to for the agent to supply annotated
5-tuples basically of the form:

	Inside Address: <stuff> / <mask>
	Inside Port: <stuff> / <mask>
	Outside Address: <stuff> / <mask>
	Outside Port: <stuff> / <mask>
	Protocol: <number>

	This last bit, that the 5-tuples have inside/outside information,
or more generally port information is all I am asking for. Any other
construct that is at least as semantically expressive would also be fine.

	I'm working on my draft, having it reviewed by some local people
before I inflict it on the world.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 11:29:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23706
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 11:29:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08941;
	Wed, 15 Aug 2001 11:23:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08865
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 11:23:54 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23553
	for <midcom@ietf.org>; Wed, 15 Aug 2001 11:22:41 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 50DC98165
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:23:55 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA21739
	for <midcom@ietf.org>; Wed, 15 Aug 2001 10:23:55 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 15 Aug 2001 10:23:55 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] policy & duration
In-Reply-To: <5.1.0.14.0.20010815140017.028684d0@mailhub.fokus.gmd.de>
Message-ID: <Pine.GSO.4.21.0108151017340.20816-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Wed, 15 Aug 2001, Jiri Kuthan wrote:

> >        The middlebox is, in the abstract, far less capable of guessing
> >direction and location of endpoints since information is lost. 
> 
> Which specific piece of information that may help you to figure out the
> direction gets lost?

	If I send an INVITE to sip:jiri@iptel.org, and the Agent is
a SIP proxy implemented to allow early media to work (that is, it
opens a pinhole immediately), the 5-tuple describing the pinhole
has no information about YOU, since we don't know what IP address
you're at. The pinhole description only has data about my phone,
where my phone will receive media, to be exact. The source end is
wildcarded completely.

	If you don't think early media is an issue, then consider
a NAT binding for my phone.

	The INVITE doesn't have your IP address, but it does have the
text 'sip:jiri@iptel.org' which may well be useful for direction/path
guessing. Indeed, during INVITE processing, this text may be the ONLY
information we have available to figure out where the heck Jiri's
media is likely to be coming from, and surely we're not going to send
'sip:jiri@iptel.org' to the middlebox? It is exactly this piece of
information I consider the Agent to have, but not the middlebox.

	Does that help?

		Andrew




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 12:49:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25912
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 12:49:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11476;
	Wed, 15 Aug 2001 12:47:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11445
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 12:47:33 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25801
	for <midcom@ietf.org>; Wed, 15 Aug 2001 12:46:20 -0400 (EDT)
Received: from jku.fokus.gmd.de ([62.254.249.109])
	by fox.iptel.org (8.11.2/8.11.2) with ESMTP id f7FGkpq30727;
	Wed, 15 Aug 2001 18:46:51 +0200
Message-Id: <5.1.0.14.0.20010815183752.02a19ec8@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 18:54:30 +0200
To: Andrew Molitor <amolitor@visi.com>, midcom@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Re: [midcom] policy & duration
In-Reply-To: <Pine.GSO.4.21.0108151017340.20816-100000@isis.visi.com>
References: <5.1.0.14.0.20010815140017.028684d0@mailhub.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 05:23 PM 8/15/2001, Andrew Molitor wrote:
[...]

>        The INVITE doesn't have your IP address, but it does have the
>text 'sip:jiri@iptel.org' which may well be useful for direction/path
>guessing.

Sorry to repeat myself for so many times, but similarly to email addresses
it is difficult to infer users' location from SIP addresses. In fact, I'm 
traveling and using my address jiri@iptel.org in a network which is
completely outside of the network, where hosts are called xyz.iptel.org.

> Indeed, during INVITE processing, this text may be the ONLY
>information we have available to figure out where the heck Jiri's
>media is likely to be coming from, and surely we're not going to send
>'sip:jiri@iptel.org' to the middlebox? It is exactly this piece of
>information I consider the Agent to have, but not the middlebox.

I agree that telling middlebox about jiri@iptel.org is useless. However, 
the example you  gave does not seem to me to demonstrate the 
application-specific ability to guess the from/to realms.

-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 14:43:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28901
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 14:43:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14245;
	Wed, 15 Aug 2001 14:42:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14217
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 14:42:10 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28852
	for <midcom@ietf.org>; Wed, 15 Aug 2001 14:40:57 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7FIfjQ25615
	for <midcom@ietf.org>; Wed, 15 Aug 2001 11:41:45 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACJ14895;
	Wed, 15 Aug 2001 11:41:39 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 14:42:58 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Deleting requirements
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I've received a clear "small is beautiful" message from our ADs,
and with that in mind I'd like to propose deleting the following
requirements as redundant, obvious, or unnecessary (note that some
of these have already been identified as things to be handled by
design teams, but which I think we can kill to no ill effect):

R16 (needs to be deleted or reworded)
R78
R19
R25
R27
R29
R30
R42
R48
R50 (redundant with R40)
R51 (see earlier note from Scott Bradner)
R52 (redundant with R50 and R40)
R53 (ditto - just need to state somewhere that the protocol must support
     both v4 and v6)
R54 
R55
R56
R57
R71
R74


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 15:37:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29907
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 15:37:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16037;
	Wed, 15 Aug 2001 15:33:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16007
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 15:33:10 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29803
	for <midcom@ietf.org>; Wed, 15 Aug 2001 15:31:56 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA17749
	for <midcom@ietf.org>; Wed, 15 Aug 2001 14:32:35 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 15 Aug 2001 14:29:10 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YHDFHR>; Wed, 15 Aug 2001 14:28:37 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF42@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Going through the requirements
Date: Wed, 15 Aug 2001 14:28:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C125C0.78B06820"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C125C0.78B06820
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, August 15, 2001 10:02 AM

> 
> These have terminological issues:
> 
> R6
> R79
> R47
> 

Melinda, Apart from the above list, I think we had terminological issues
with ruleset (in R80), session (R10), session-descriptor (R11), registration
session (R38) and pinholes (R19-20, R40, R44-46, R50-57, R60, R78)


> These are being resolved by design teams and being brought
> back to the WG:
> 
> R44

Does this mean the discussions will be taken off the mailing list? We're
having some active discussions on Direction (R44).

> R68

Clarification needed on this requirement. Actually, Scott's draft says
"Richard Swale will correct & resubmit".

Thanks,
Sanjoy



------_=_NextPart_001_01C125C0.78B06820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Going through the requirements</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 15, 2001 10:02 =
AM</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; These have terminological issues:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R6</FONT>
<BR><FONT SIZE=3D2>&gt; R79</FONT>
<BR><FONT SIZE=3D2>&gt; R47</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Melinda, Apart from the above list, I think we had =
terminological issues with ruleset (in R80), session (R10), =
session-descriptor (R11), registration session (R38) and pinholes =
(R19-20, R40, R44-46, R50-57, R60, R78)</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; These are being resolved by design teams and =
being brought</FONT>
<BR><FONT SIZE=3D2>&gt; back to the WG:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R44</FONT>
</P>

<P><FONT SIZE=3D2>Does this mean the discussions will be taken off the =
mailing list? We're having some active discussions on Direction =
(R44).</FONT></P>

<P><FONT SIZE=3D2>&gt; R68</FONT>
</P>

<P><FONT SIZE=3D2>Clarification needed on this requirement. Actually, =
Scott's draft says &quot;Richard Swale will correct &amp; =
resubmit&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Sanjoy</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C125C0.78B06820--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 15:51:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00088
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 15:51:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16442;
	Wed, 15 Aug 2001 15:49:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16413
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 15:49:42 -0400 (EDT)
Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00057
	for <midcom@ietf.org>; Wed, 15 Aug 2001 15:48:28 -0400 (EDT)
Message-ID: <20010815194940.89456.qmail@web13802.mail.yahoo.com>
Received: from [66.89.112.150] by web13802.mail.yahoo.com; Wed, 15 Aug 2001 12:49:40 PDT
Date: Wed, 15 Aug 2001 12:49:40 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: [midcom] proposed text for framework sect. 2.8
To: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
In-Reply-To: <5.1.0.14.0.20010815082141.00a3bb40@mira-sjc5-4.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org


--- Melinda Shore <mshore@cisco.com> wrote:
> At 05:14 AM 8/15/01 -0700, Pyda Srisuresh wrote:
> >Mark - Please see my response to Scott. The text suggests any intermediate
> >device (whether terminating the traffic as in Proxy/Gateway/VPN tunnel or
> >merely transiting the traffic as in switch/router/middlebox) as a 
> >candidate for hosting MIDCOM agent. The former was discussed in the 
> >past. The latter seemed like a new revelation. 
> 
> I really don't think so.  We've already agreed that we're talking
> about functions, not boxes, and that we're not constraining the
> placement of functions (other than packet diversion not being
> in scope).

OK, folks, My mistake. I will gladly take Mark's definition
for "MIDCOM agent" into the FW draft. Thanks, Mark and thanks 
to all for putting up with the innuendo.

cheers,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 16:01:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00228
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 16:01:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16551;
	Wed, 15 Aug 2001 15:55:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16524
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 15:55:49 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00115
	for <midcom@ietf.org>; Wed, 15 Aug 2001 15:54:35 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7FJtNQ19690
	for <midcom@ietf.org>; Wed, 15 Aug 2001 12:55:23 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-50.cisco.com [10.21.96.50])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJL02962;
	Wed, 15 Aug 2001 12:55:17 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 15 Aug 2001 15:55:18 -0400
Date: Wed, 15 Aug 2001 15:55:18 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Deleting requirements
Message-ID: <20010815155518.B1712@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Wed, Aug 15, 2001 at 02:42:58PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 15, 2001 at 02:42:58PM -0400, Melinda Shore apparently wrote:
> I've received a clear "small is beautiful" message from our ADs,
> and with that in mind I'd like to propose deleting the following
> requirements as redundant, obvious, or unnecessary (note that some
> of these have already been identified as things to be handled by
> design teams, but which I think we can kill to no ill effect):
> 
> R16 (needs to be deleted or reworded)

(Security should be low-impact.)  I'd delete it.  I disagree with it.

> R78

(Must be able to request specific addr/port.)  Are you saying that
shouldn't be a requirement, or that it's obvious?  Personally I'm in
favor.  It's easy.

> R19

(Optional ICMP reporting after closure.)  Agreed, delete.

> R25

(Robust in face of packet loss.)  Again, why?  Because it's obvious?

> R27

(Low latency.)  Why?

> R29

(Don't assume 0 delay.)  Agreed.  Obvious.

> R30

(Agent must be able to report status to middlebox.)  I think you can
delete this as a subset of R23, already accepted.

> R42

(independence from any app.)  Agreed.  Obvious.

> R48

Agreed.  Unclear, probably a subset of a different one.

> R50 (redundant with R40)

No.  R50 says you should be able to specify DSCP for matching on (note,
this is NOT saying you can say what QoS treatment to GIVE the packets).
R40 only covers the basic tuple.

> R51 (see earlier note from Scott Bradner)

Yes.

> R52 (redundant with R50 and R40)

Yes, my mistake.

> R53 (ditto - just need to state somewhere that the protocol must support
>      both v4 and v6)

And where would that be?  That's what this requirement was supposed to
be for :-)

> R54 

Agreed, redundant.

> R55

Agreed, redundant.

> R56

Well, ICMP type is not part of the usual tuple and could easily be
overlooked.  I think this one could use some consensus.  

> R57

Well, IGMP type is not part of the usual tuple and could easily be
overlooked.  I think this one could use some consensus.  

> R71

OK

> R74

(Ask what resources are available.)  We should put this off until Version
2, but I think it should be discussed eventually.  The point was that
after discovery (or perhaps as part of it) you want to be able to do
selection.  This was a mechanism for the agent to gather information in
order to make a selection.


I won't do anything with any of these until the Chair declares consensus
on them (individually).  At that point I'll put out a new version of the
bullets.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 16:21:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00467
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 16:21:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17191;
	Wed, 15 Aug 2001 16:20:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17160
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 16:20:29 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00437
	for <midcom@ietf.org>; Wed, 15 Aug 2001 16:19:14 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7FKI7D03610;
	Wed, 15 Aug 2001 13:18:07 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACJ19058;
	Wed, 15 Aug 2001 13:19:55 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010815161833.00a161e0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 16:21:03 -0400
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Deleting requirements
In-Reply-To: <20010815155518.B1712@SBRIM-W2K>
References: <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I got a "thanks and good luck" from Scott Bradner in response
to this.  Hah.

I'm thinking of getting another husky.  Clearly, one dog doing
this: 
http://www.employees.org/~shore/mov00051.mpg

is not enough (note the completely shredded bedding).

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 16:24:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00495
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 16:24:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17292;
	Wed, 15 Aug 2001 16:24:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17263
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 16:24:19 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00484
	for <midcom@ietf.org>; Wed, 15 Aug 2001 16:23:04 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7FKO3T24348
	for <midcom@ietf.org>; Wed, 15 Aug 2001 13:24:03 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACJ19206;
	Wed, 15 Aug 2001 13:23:47 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010815162410.00a1d280@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 16:24:56 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Sorry 'bout that
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I accidentally sent personal mail to the mailing list.  

I don't suppose you want to hear more about my dogs ...

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 17:13:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01232
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 17:13:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18598;
	Wed, 15 Aug 2001 17:01:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18567
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 17:01:32 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01013
	for <midcom@ietf.org>; Wed, 15 Aug 2001 17:00:19 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id C1B0681BD
	for <midcom@ietf.org>; Wed, 15 Aug 2001 16:01:33 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA12239
	for <midcom@ietf.org>; Wed, 15 Aug 2001 16:01:33 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 15 Aug 2001 16:01:33 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: Topology, pinholes and policy roles (was RE: [midcom] policy 
 &duration)
In-Reply-To: <3B7A978B.3F53CF91@cisco.com>
Message-ID: <Pine.GSO.4.21.0108151558130.11822-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Wed, 15 Aug 2001, Eliot Lear wrote:

> Right.  This is nearly what I wrote a week ago.  The only difference was
> that I put it in terms of policy;
> 
> > A middle box SHOULD understand, at a minimum, policy conditions that
> > contain the interfaces involved, protocol, source address and port,
> > destination address and port, all of which with the exception of protocol
> > and interfaces MUST be capable of being expressed as a range of values. 
> > This is the trivial case, necessary to deploy a middlebox without the
> > assistance of a policy server.
> 
> I think you are looking for the following substitution:
> 
> s/source/internal/
> s/destination/external/

	Source and Destination are not interchangeable with Internal
versus External. Communications are often bidirectional, as you know.
Internal and External are notions that should be bound to the two
sides of a 5-tuple, source and destination are not.

	Unless by source you mean something like 'the end that sends
the first packet of a communication' or something, and even then I
think it's not powerful enough absent some discussion of interface
(such as Internal and External).

> 
> remove interface for purposes of protocol discussion.

	If the MIDCOM protocol doesn't talk about interfaces, it
becomes a mere can opener which hackers can use to punch arbitrary
holes in your firewall. _vide_ my earlier note on forged INVITES
and your internal NFS server.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 17:13:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01237
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 17:13:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18640;
	Wed, 15 Aug 2001 17:01:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18607
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 17:01:50 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01016
	for <midcom@ietf.org>; Wed, 15 Aug 2001 17:00:35 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7FL1YT21184;
	Wed, 15 Aug 2001 14:01:34 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACL00898;
	Wed, 15 Aug 2001 14:01:17 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010815165259.00a1d7d0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 Aug 2001 17:02:24 -0400
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Deleting requirements
In-Reply-To: <20010815155518.B1712@SBRIM-W2K>
References: <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 03:55 PM 8/15/01 -0400, Scott Brim wrote:
>(Must be able to request specific addr/port.)  Are you saying that
>shouldn't be a requirement, or that it's obvious?  Personally I'm in
>favor.  It's easy.

I think it's obvious.

>(Robust in face of packet loss.)  Again, why?  Because it's obvious?

I think so.  Consider the alternative.

>> R27
>
>(Low latency.)  Why?

I could go either way on it.  I'm not convinced that it's a
necessary requirement, but I could be.  At any rate, I'm just
putting it out there.

>> R50 (redundant with R40)
>
>No.  R50 says you should be able to specify DSCP for matching on (note,
>this is NOT saying you can say what QoS treatment to GIVE the packets).
>R40 only covers the basic tuple.

Right, but if we decide to define the filter elements at all (and 
I tend to think that we should not), it should be in one place.

>And where would that be?  That's what this requirement was supposed to
>be for :-)

We need one requirement saying that the protocol must support both
v4 and v6 addresses.  Come to think of it, we need a requirement saying
that the protocol should run over both v4 and v6 networks.

>> R56
>
>Well, ICMP type is not part of the usual tuple and could easily be
>overlooked.  I think this one could use some consensus.  

See my comments on R50.

>I won't do anything with any of these until the Chair declares consensus
>on them (individually).  

That's why I've put out a proposal to delete these.  I'm trying to 
get yes/no answers.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 15 18:09:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01242
	for <midcom-archive@odin.ietf.org>; Wed, 15 Aug 2001 17:13:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18787;
	Wed, 15 Aug 2001 17:08:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18758
	for <midcom@ns.ietf.org>; Wed, 15 Aug 2001 17:08:11 -0400 (EDT)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01147
	for <midcom@ietf.org>; Wed, 15 Aug 2001 17:06:58 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP
	id 88A108171; Wed, 15 Aug 2001 16:08:12 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA12701;
	Wed, 15 Aug 2001 16:08:12 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Wed, 15 Aug 2001 16:08:12 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: midcom@ietf.org
Subject: Re: [midcom] policy & duration
In-Reply-To: <5.1.0.14.0.20010815183752.02a19ec8@mailhub.fokus.gmd.de>
Message-ID: <Pine.GSO.4.21.0108151602410.11822-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Wed, 15 Aug 2001, Jiri Kuthan wrote:

> At 05:23 PM 8/15/2001, Andrew Molitor wrote:
> [...]
> 
> >        The INVITE doesn't have your IP address, but it does have the
> >text 'sip:jiri@iptel.org' which may well be useful for direction/path
> >guessing.
> 
> Sorry to repeat myself for so many times, but similarly to email addresses
> it is difficult to infer users' location from SIP addresses.

	I never said it was easy. I have said:

	- the Agent must solve the location problem, at least
	  approximately, to work at all.
	- the text 'sip:jiri@iptel.org' is available to the Agent
	  and not to the middlebox, and perhaps could help the
	  Agent out.

	It doesn't matter a whit to me how the Agent figures out
where 'sip:jiri@iptel.org', but a SIP Agent has to come up with an
answer to this question or it WILL NOT WORK.

	The answer doesn't have to be good. Often 'on my network'
or 'not on my network' will do fine, but the question of where
Jiri is MUST be answered at least approximately before the Agent can
proceed. This is not a question of good, better, or bad. This
is not a question of elegance and correct factorization. This IS
a question of WORKS versus DOESN'T WORK.

	My oft repeated corollary, which is the only thing I care
about at all is:

	- therefore, an Agent can specify path/direction information
	  to the middlebox, since it has to solve the problem to function


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 00:30:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08165
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 00:30:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26719;
	Thu, 16 Aug 2001 00:25:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26674
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 00:24:57 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08069
	for <midcom@ietf.org>; Thu, 16 Aug 2001 00:23:47 -0400 (EDT)
Received: from MDUFFY ([10.1.1.16]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0CWC; Thu, 16 Aug 2001 00:24:28 -0400
Message-Id: <3.0.5.32.20010816002238.00910100@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 16 Aug 2001 00:22:38 -0400
To: midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] question about direction requirements
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Another requirements question related to direction.  The proposed
requirements mention direction as part of the tuple.  My understanding is
that this refers to direction of individual packets.  Do we also need
support for expressing to the middlebox the direction of transport session
setup?

We might consider adding the following requirement to the to-be-discussed
list:

Ri:  The Midcom protocol must allow the agent to specify to the middlebox
that a pinhole (etc...) is to be opened only if the transport connection as
viewed by the middlebox is initiated in a certain direction relative to the
realms mediated by the middlebox.

Discussion:  Legacy middleboxes typically allow for rules that says e.g.:
open pinhole for packets matching this tuple only if the tcp (etc.) session
is  initiated from inside towards outside.  Do we need the midcom agent to
be able to specify such a rule?



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 00:30:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08166
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 00:30:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26683;
	Thu, 16 Aug 2001 00:24:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26651
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 00:24:56 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08067
	for <midcom@ietf.org>; Thu, 16 Aug 2001 00:23:46 -0400 (EDT)
Received: from MDUFFY ([10.1.1.16]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0CWA; Thu, 16 Aug 2001 00:24:27 -0400
Message-Id: <3.0.5.32.20010815235649.0091f5b0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 15 Aug 2001 23:56:49 -0400
To: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] Deleting requirements
In-Reply-To: <20010815155518.B1712@SBRIM-W2K>
References: <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Melinda, I agree with all the deletions you propose, except a few as noted
below.

R52: I don't think we should delete it.  R52 is mostly redundant with R40
and R50 but adds the additional requirement that masks be supported.
Perhaps we can reduce R52 to R40b: "all items in the tuple are maskable"
and then debate that when we come to it.

I agree with Scott on 50, 56, 57:

>> R50 (redundant with R40)
>
>No.  R50 says you should be able to specify DSCP for matching on (note,
>this is NOT saying you can say what QoS treatment to GIVE the packets).
>R40 only covers the basic tuple.
>
>> R56
>
>Well, ICMP type is not part of the usual tuple and could easily be
>overlooked.  I think this one could use some consensus.  
>
>> R57
>
>Well, IGMP type is not part of the usual tuple and could easily be
>overlooked.  I think this one could use some consensus.  


Besides the ones you identified for deletion, I think R11 is a duplicate of
R40 so can be deleted.

-Mark


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 04:59:17 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26515
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 04:59:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11806;
	Thu, 16 Aug 2001 04:53:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11781
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 04:53:51 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26392
	for <midcom@ietf.org>; Thu, 16 Aug 2001 04:52:38 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7G8rMQ20130;
	Thu, 16 Aug 2001 01:53:22 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7G8rJX21853;
	Thu, 16 Aug 2001 01:53:20 -0700 (PDT)
Message-ID: <3B7B8A07.A2AA146D@cisco.com>
Date: Thu, 16 Aug 2001 01:53:27 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Molitor <amolitor@visi.com>
CC: midcom@ietf.org
Subject: Re: Topology, pinholes and policy roles (was RE: [midcom] policy 
 &duration)
References: <Pine.GSO.4.21.0108151558130.11822-100000@isis.visi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Andrew Molitor wrote:
>        Source and Destination are not interchangeable with Internal
> versus External. Communications are often bidirectional, as you know.
> Internal and External are notions that should be bound to the two
> sides of a 5-tuple, source and destination are not.

Right.  We're not disagreeing here.  It's what that implies that causes us
some grief.  How would you reference an interface in the protocol?  By
name?  How would you determine which interface to name, even if you knew
their names?

Your earlier example, by the way, did NOT require interfaces.  Rather, it
required that the midcom box take responsibility for understanding the
security implications of the service it provides.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 07:52:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29907
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 07:52:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16119;
	Thu, 16 Aug 2001 07:49:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16090
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 07:49:15 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29745
	for <midcom@ietf.org>; Thu, 16 Aug 2001 07:48:03 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7GBn2T12731
	for <midcom@ietf.org>; Thu, 16 Aug 2001 04:49:02 -0700 (PDT)
Received: from SBRIMW2K (sjc-vpn2-4.cisco.com [10.21.112.4])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJM04328;
	Thu, 16 Aug 2001 04:48:43 -0700 (PDT)
From: "Scott Brim" <sbrim@cisco.com>
To: <midcom@ietf.org>
Subject: RE: [midcom] Deleting requirements
Date: Thu, 16 Aug 2001 07:48:49 -0400
Message-ID: <GCEDKPLNCJFMNCNKCCKJOEHLCEAA.sbrim@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Given Melinda's clarification, my positions:

> R16 (needs to be deleted or reworded)

	Delete

> R78

	Keep.  I don't think it's obvious. 

> R19

	Delete

> R25

	Delete

> R27 (low latency)

	Delete -- I can't imagine anyone wanting this protocol not to be 
	low latency.

> R29

	Delete

> R30

	Delete, subset of R23 (already accepted)

> R42

	Delete

> R48

	Delete

> R50 (redundant with R40)

	Keep.  R40 has "flow direction".  R50 has "DSCP".  I believe you should
	remove the obvious fields from both, but leave both, because they are
	contentious.  I don't think a requirement which lists all the fields 
	different people want is as useful as multiple requirements, one for
	each.  Keep both these, with just the one contentious field.

> R51 (see earlier note from Scott Bradner)

	Delete

> R52 (redundant with R50 and R40)

	Delete

> R53 (ditto - just need to state somewhere that the protocol must support
>      both v4 and v6)

	Keep ... until someone submits such text, this can be a placeholder.

> R54 

	Delete

> R55

	Delete

> R56 (icmp)
> R57 (igmp)

	Keep both.  In both these cases, someone wants to be able to request 
	a particular matching rule.  You said see comment above on R50.  I
	say the same thing :-).  Actually, the best would be for the author
	who proposed them in the requirements draft to say he doesn't think
	they're worth keeping.

> R71

	Delete

> R74

	Delete

...Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 09:14:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04569
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 09:14:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17698;
	Thu, 16 Aug 2001 09:13:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17671
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 09:13:24 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04444
	for <midcom@ietf.org>; Thu, 16 Aug 2001 09:12:11 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7GDDBT14160;
	Thu, 16 Aug 2001 06:13:11 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp85.cisco.com [10.21.64.85])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACM11357;
	Thu, 16 Aug 2001 06:12:51 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 Aug 2001 09:14:22 -0400
To: Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Deleting requirements
In-Reply-To: <3.0.5.32.20010815235649.0091f5b0@email.quarrytech.com>
References: <20010815155518.B1712@SBRIM-W2K>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:56 PM 8/15/01 -0400, Mark Duffy wrote:
>R52: I don't think we should delete it.  R52 is mostly redundant with R40
>and R50 but adds the additional requirement that masks be supported.
>Perhaps we can reduce R52 to R40b: "all items in the tuple are maskable"
>and then debate that when we come to it.

I'd like to see the filtering elements required in one place, so that
suggestion sounds good to me.  The big caveat, of course, is that
we've already received an admonition from one of the ADs, and that time
taken to go into great detail about filtering elements is not time well-
spent.  My personal preference would be to specify no filtering elements
at all - this is not a protocol specification document.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 09:20:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04988
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 09:20:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17822;
	Thu, 16 Aug 2001 09:20:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17790
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 09:20:03 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04928
	for <midcom@ietf.org>; Thu, 16 Aug 2001 09:18:49 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7GDJhn22152;
	Thu, 16 Aug 2001 06:19:43 -0700 (PDT)
Received: from SBRIM-W2K.cisco.com (sjc-vpn2-4.cisco.com [10.21.112.4])
	by airborne.cisco.com (Mirapoint)
	with ESMTP id AJM04784;
	Thu, 16 Aug 2001 06:19:31 -0700 (PDT)
X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I);
	VM 6.94 under Emacs 20.7.1
From: "Scott Brim" <sbrim@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15227.51302.490000.624760@gargle.gargle.HOWL>
Date: Thu, 16 Aug 2001 09:19:34 -0400
To: Melinda Shore <mshore@cisco.com>
Cc: Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
Subject: Re: [midcom] Deleting requirements
In-Reply-To: <5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
References: <20010815155518.B1712@SBRIM-W2K>
	<5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
	<5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

On 16 Aug 2001 at 09:14 -0400, Melinda Shore apparently wrote:
> I'd like to see the filtering elements required in one place, so that
> suggestion sounds good to me.  The big caveat, of course, is that
> we've already received an admonition from one of the ADs, and that time
> taken to go into great detail about filtering elements is not time well-
> spent.  My personal preference would be to specify no filtering elements
> at all - this is not a protocol specification document.

I thought we had general agreement that there was a minimum set of
filtering elements which were absolutely necessary, like destination
address, and that we could/would require those.  


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 10:09:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08011
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 10:09:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19148;
	Thu, 16 Aug 2001 10:08:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19119
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 10:08:57 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07890
	for <midcom@ietf.org>; Thu, 16 Aug 2001 10:07:45 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0DJS; Thu, 16 Aug 2001 10:08:27 -0400
Message-Id: <3.0.5.32.20010816100744.00854320@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 16 Aug 2001 10:07:44 -0400
To: Melinda Shore <mshore@cisco.com>, Mark Duffy <mduffy@quarrytech.com>,
        midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] Deleting requirements -tuple items
In-Reply-To: <5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
References: <3.0.5.32.20010815235649.0091f5b0@email.quarrytech.com>
 <20010815155518.B1712@SBRIM-W2K>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 09:14 AM 8/16/01 -0400, Melinda Shore wrote:
>At 11:56 PM 8/15/01 -0400, Mark Duffy wrote:
>>R52: I don't think we should delete it.  R52 is mostly redundant with R40
>>and R50 but adds the additional requirement that masks be supported.
>>Perhaps we can reduce R52 to R40b: "all items in the tuple are maskable"
>>and then debate that when we come to it.
>
>I'd like to see the filtering elements required in one place, so that
>suggestion sounds good to me.  The big caveat, of course, is that
>we've already received an admonition from one of the ADs, and that time
>taken to go into great detail about filtering elements is not time well-
>spent.  My personal preference would be to specify no filtering elements
>at all - this is not a protocol specification document.
>
>Melinda



Melinda, I have 2 procedural approaches to propose.

1.  Remove all requirements or parts of requirements that state what the
components of the n-tuple are.  Leave this to be determined later.

2. (Building here on Scott Brim's last message.)  Replace all the existing
requirements items about tuple composition with the following:
 
 Ri: The Midcom protocol must permit the following to be specified as
criteria for each session-descriptor [replace "session-descriptor with
chosen term].  It must also be possible to specify "don't care" for any
packet field, either using the mask available or by other means.

  Ri.01  Source IP address 
  Ri.02  Source IP address mask
  Ri.03  Destination IP address
  Ri.04  Destination IP address mask
  Ri.05  IP protocol/ next header field
  Ri.06  Transport layer source port
  Ri.07  Transport layer source port mask
  Ri.08  Transport layer destination port
  Ri.09  Transport layer destination port mask
  Ri.10  DiffServ Code Point
  Ri.11  TCP SYN set or not
  Ri.12  interface/realm
  Ri.13  Direction relative to interface/realm
  Ri.14  ICMP type field
  Ri.15  ICMP code field
  Ri.16  IGMP type field

The above list is a compilation of all the proposed requirements we have
circulating.  I'm sure we would need to approve or reject each at some point.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 11:01:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11214
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 11:01:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20629;
	Thu, 16 Aug 2001 10:59:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20555
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 10:59:12 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10996
	for <midcom@ietf.org>; Thu, 16 Aug 2001 10:58:00 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7GEx0T12850;
	Thu, 16 Aug 2001 07:59:00 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp85.cisco.com [10.21.64.85])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACM13233;
	Thu, 16 Aug 2001 07:58:40 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010816105102.009efbe0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 Aug 2001 11:00:09 -0400
To: Mark Duffy <mduffy@quarrytech.com>, Mark Duffy <mduffy@quarrytech.com>,
        midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Deleting requirements -tuple items
In-Reply-To: <3.0.5.32.20010816100744.00854320@email.quarrytech.com>
References: <5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
 <3.0.5.32.20010815235649.0091f5b0@email.quarrytech.com>
 <20010815155518.B1712@SBRIM-W2K>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 10:07 AM 8/16/01 -0400, Mark Duffy wrote:
>2. (Building here on Scott Brim's last message.)  Replace all the existing
>requirements items about tuple composition with the following:
> 
> Ri: The Midcom protocol must permit the following to be specified as
>criteria for each session-descriptor [replace "session-descriptor with
>chosen term].  It must also be possible to specify "don't care" for any
>packet field, either using the mask available or by other means.
>
>  Ri.01  Source IP address 
>  Ri.02  Source IP address mask
>  Ri.03  Destination IP address
>  Ri.04  Destination IP address mask
>  Ri.05  IP protocol/ next header field
>  Ri.06  Transport layer source port
>  Ri.07  Transport layer source port mask
>  Ri.08  Transport layer destination port
>  Ri.09  Transport layer destination port mask
>  Ri.10  DiffServ Code Point
>  Ri.11  TCP SYN set or not
>  Ri.12  interface/realm
>  Ri.13  Direction relative to interface/realm
>  Ri.14  ICMP type field
>  Ri.15  ICMP code field
>  Ri.16  IGMP type field

First, I've got to say that I'm pretty disappointed that people
aren't listening to the *very* clear message coming down from 
the ADs.  Small is beautiful, trim the fat, the 5-tuple is
sufficient for now, etc.

Second, this is actually a very good representation of the problem with 
enumerating the filtering elements.  It appears to be intended to
be comprehensive, but the fact is that network operators are filtering
on all sorts of stuff, not just what's listed here.  Another problem
is how this is going to scale.  When you talk about using a "don't care"
flag for elements as needed, you're saying that the whole filter needs
to be sent down every time.  It's either going to become very large or
it's going to remain insufficient.

Third, see item the first.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 12:05:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14506
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:05:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22835;
	Thu, 16 Aug 2001 12:01:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22801
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 12:01:21 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14319
	for <midcom@ietf.org>; Thu, 16 Aug 2001 12:00:08 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0D44; Thu, 16 Aug 2001 12:00:52 -0400
Message-Id: <3.0.5.32.20010816120006.008fc9f0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 16 Aug 2001 12:00:06 -0400
To: Melinda Shore <mshore@cisco.com>, Mark Duffy <mduffy@quarrytech.com>,
        Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] Deleting requirements -tuple items
In-Reply-To: <5.1.0.14.0.20010816105102.009efbe0@mira-sjc5-4.cisco.com>
References: <3.0.5.32.20010816100744.00854320@email.quarrytech.com>
 <5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
 <3.0.5.32.20010815235649.0091f5b0@email.quarrytech.com>
 <20010815155518.B1712@SBRIM-W2K>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:00 AM 8/16/01 -0400, Melinda Shore wrote:
>First, I've got to say that I'm pretty disappointed that people
>aren't listening to the *very* clear message coming down from 
>the ADs.  Small is beautiful, trim the fat, the 5-tuple is
>sufficient for now, etc.

Melinda, I don't think it is realistic to expect everyone to just get in
line for that -- not everyone has the same objectives as the ADs.  I
suggest that you as chair should declare this out of scope for the
requirements, if you and the ADs feel it is.  Otherwise it should be up to
the wg concensus whether this belongs in the requirements or not.

BTW I did present this option in my email, along with the proposed list of
tuple requirements, perhaps you missed it:

>1.  Remove all requirements or parts of requirements that state what the
>components of the n-tuple are.  Leave this to be determined later.



>Second, this is actually a very good representation of the problem with 
>enumerating the filtering elements.  It appears to be intended to
>be comprehensive, but the fact is that network operators are filtering

Actually, it was not intended to be comprhensive of the possibilities, only
comprehensive of what was already in the requirements doc.

>on all sorts of stuff, not just what's listed here.  Another problem
>is how this is going to scale.  When you talk about using a "don't care"
>flag for elements as needed, you're saying that the whole filter needs
>to be sent down every time.  It's either going to become very large or

No, I didn't say that.  I just proposed requirements for an initial list of
elements to support.  It is a protocol design issue whether they all need
to be sent every time (and as you point out, that might well be a poor
design).

>it's going to remain insufficient.
>
>Third, see item the first.
>
>Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 12:22:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15107
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:22:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23200;
	Thu, 16 Aug 2001 12:20:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23171
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 12:20:28 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15012
	for <midcom@ietf.org>; Thu, 16 Aug 2001 12:19:15 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7GGI6D07831;
	Thu, 16 Aug 2001 09:18:06 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp85.cisco.com [10.21.64.85])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACM15535;
	Thu, 16 Aug 2001 09:19:55 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010816120432.00a1f170@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 Aug 2001 12:21:22 -0400
To: Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Deleting requirements -tuple items
In-Reply-To: <3.0.5.32.20010816120006.008fc9f0@email.quarrytech.com>
References: <5.1.0.14.0.20010816105102.009efbe0@mira-sjc5-4.cisco.com>
 <3.0.5.32.20010816100744.00854320@email.quarrytech.com>
 <5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
 <3.0.5.32.20010815235649.0091f5b0@email.quarrytech.com>
 <20010815155518.B1712@SBRIM-W2K>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 12:00 PM 8/16/01 -0400, Mark Duffy wrote:
>Melinda, I don't think it is realistic to expect everyone to just get in
>line for that -- not everyone has the same objectives as the ADs.  

Fair enough.  But I do think that we need to keep in mind that
the document will have to go through IESG review and IETF last
call, so anybody who advocates heading off in a different
direction from what's been recommended by both the ADs and the
chair should be prepared to make a very strong case.  What I'm
trying to avoid is getting through WG last call with a document 
containing stuff that I know for a fact won't survive IESG review.

>I
>suggest that you as chair should declare this out of scope for the
>requirements, if you and the ADs feel it is.  

I'm about that -><- close to doing something similar (the topic *isn't*
out of scope, but we're making a mess of it by trying to do too much).  
However, I don't like unilateralism and I'm hoping that we can find some 
sort of compromise that works.  Sticking with just a 5-tuple may be that 
compromise, but there may be something else, as well.  

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 12:24:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15170
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:24:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23335;
	Thu, 16 Aug 2001 12:24:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23306
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 12:24:06 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15143
	for <midcom@ietf.org>; Thu, 16 Aug 2001 12:22:54 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7GGNln11975;
	Thu, 16 Aug 2001 09:23:48 -0700 (PDT)
Received: from SBRIM-W2K.cisco.com (sjc-vpn2-4.cisco.com [10.21.112.4])
	by airborne.cisco.com (Mirapoint)
	with ESMTP id AJM06774;
	Thu, 16 Aug 2001 09:23:35 -0700 (PDT)
X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I);
	VM 6.94 under Emacs 20.7.1
From: "Scott Brim" <sbrim@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15227.62346.300000.892204@gargle.gargle.HOWL>
Date: Thu, 16 Aug 2001 12:23:38 -0400
To: Melinda Shore <mshore@cisco.com>
Cc: Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
Subject: Re: [midcom] Deleting requirements -tuple items
In-Reply-To: <5.1.0.14.0.20010816120432.00a1f170@mira-sjc5-4.cisco.com>
References: <5.1.0.14.0.20010816105102.009efbe0@mira-sjc5-4.cisco.com>
	<3.0.5.32.20010816100744.00854320@email.quarrytech.com>
	<5.1.0.14.0.20010816091144.00a34b80@mira-sjc5-4.cisco.com>
	<3.0.5.32.20010815235649.0091f5b0@email.quarrytech.com>
	<20010815155518.B1712@SBRIM-W2K>
	<5.1.0.14.0.20010815142658.00a4ad00@mira-sjc5-4.cisco.com>
	<5.1.0.14.0.20010816120432.00a1f170@mira-sjc5-4.cisco.com>
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

The bullets aren't meant to be an actual requirements draft.  Once we
agree (using the bullets) on what *should* be in a requirements draft,
the authors say they'll go off and fix one up.  So I wouldn't spend a
lot of time on how the content of the bullets should be organized.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 12:33:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15342
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:33:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23433;
	Thu, 16 Aug 2001 12:29:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23405
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 12:29:20 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15234
	for <midcom@ietf.org>; Thu, 16 Aug 2001 12:28:08 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7GGSog18555
	for <midcom@ietf.org>; Thu, 16 Aug 2001 17:28:50 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Thu, 16 Aug 2001 17:28:31 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5WJXZ48>; Thu, 16 Aug 2001 17:28:29 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451A9@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Jiri Kuthan'" <kuthan@fokus.gmd.de>, Mark Duffy <mduffy@quarrytech.com>,
        lear@cisco.com, Scott Brim <sbrim@cisco.com>
Cc: midcom@ietf.org
Subject: RE: [midcom] policy & duration
Date: Thu, 16 Aug 2001 17:28:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12670.7E306CE0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12670.7E306CE0
Content-Type: text/plain;
	charset="iso-8859-1"

I don't know if this has been covered or not ..., if sorry apologies for the
spam.


We should not consider the simplistic MB approach.
Let's consider this practical example:

Alice is part of VPN A and Bob is in VPN B . Here I'm talking of IP VPN and
Telephony VPNs.
If Alice calls BOB, you know from your application translation (E164 or
through domain names) that you are going outside of your VPN.
Assuming that MB discovery is not used, you will configure on the agent that
users of telephony VPN A are behind Middle Boxes x,y and z.
Based on the translation of the uri or the E164 number, the agent knows that
it is an extra VPN call (again telephony VPN).Now it has to discuss MIDCOM
with one of the MBs.

1- By looking through the *crystal ball* (:-) the agent knows that y is the
MB to talk to. 
The problem is that MB y is a provider provisioned MB where other realms
overlap on the address realm of VPN B (here I'm talking of IP VPN). How can
I use the standard matching expression to identify the flow (i.e 5 tuple) ?

By some way I need to tell my MB y that I'm talking of traffing flowing from
realm B to the outer realm, the outer realm is probably the registered
address realm (i.e. public realm), in case it is not I will need to indicate
it because maybe it is overlapped by another (or several realms) that MB y
is connected to; thus requiring the outer realm id.

This is the reason to have the realm identifier(s) in the n tuple.
Since we are already configuring application client information on the
application servers (user id ...), the realm id will not be such an
overload.

In case Alice calls Pat who is in telephony VPN A, the MA knows that it
doesn't need to get in touch with the MB.
I don't know if could use the same analogy to other applications or not (any
comments ?)

I tried to raise the concerns/reasons relevant to topology, I think that
they are quite clear in this example (hopefully).

Cedric
-----Original Message-----
From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
Sent: Monday, August 13, 2001 5:26 PM
To: Mark Duffy; Mark Duffy; lear@cisco.com; Scott Brim
Cc: midcom@ietf.org
Subject: Re: [midcom] policy & duration


Mark,

I am still sceptic about agent's ability to figure out the direction.
In the example I gave before agents actually do not know. The only thing
a SIP proxy surely knows is destination address and port number of media. 
(It also might try to guess source IP address, though guessing might fail). 
So it might try to infer direction from the 5-tuple. Doing so is 
however not app-specific and might be done in middleboxes as well.

Consider the following example: two SIP phones which are registered with a
company's
SIP server are temporarily in an external network. Which means there is no
need
for pinholes at all if they want to speak to each other! Who will figure it
out?
I doubt there is something useful for determining the direction what a SIP
proxy knows 
a middlebox does not. A middlebox can be configured to guess which IP
addresses is external and which not. Doing the same in every agent 
is lot of work which is perhaps not needed.

This is where my doubts for use of interfaces come from. 

-Jiri

At 12:57 PM 8/10/2001, Mark Duffy wrote:
>In general, a mb has no idea what direction anything *wants* to go in.  All
>it does is open pinholes etc at the behest of agents.  If the agent, with
>the applic. intelligence, can't determine that, then probably no one can --
>maybe in that case the agent should just ask the mb for both directions.
>>From the point of view of the typical mb, a 5-tuple in one direction is
>completely different from the same 5-tuple in the opposite direction.  If
>the agent via the midcom protocol cannot express that difference, then the
>overall system is essentially dumbed-down to that level.  The result would
>be reduced security, if packets matching an n-tuple are permitted in either
>direction when in fact they should only be permitted in one.  I believe
>that would be an unacceptable reduction in security.
>
>-Mark
>
>At 05:37 PM 8/9/01 +0200, Jiri Kuthan wrote:
>>How does a, say SIP proxy, know what the direction of a media stream
>>belonging to a SIP session will be?
>>
>>-Jiri
>>
>>At 04:21 PM 8/8/2001, Mark Duffy wrote:
>>>>Also, I think we remove directionality at our peril.  In an
>>>>internal/external communication, the reversing of directional rules on
>>>>interfaces would lead to a weakening of enterprise security.
>>>
>>>Not only that, but the directionality is already an aspect of the
existing
>>>firewall functionality we are providing control over.  I too believe
>>>directionality should be included.
>>
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>http://www1.ietf.org/mailman/listinfo/midcom 

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


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C12670.7E306CE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] policy &amp; duration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I don't know if this has been covered or not ..., if =
sorry apologies for the spam.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>We should not consider the simplistic MB =
approach.</FONT>
<BR><FONT SIZE=3D2>Let's consider this practical example:</FONT>
</P>

<P><FONT SIZE=3D2>Alice is part of VPN A and Bob is in VPN B . Here I'm =
talking of IP VPN and Telephony VPNs.</FONT>
<BR><FONT SIZE=3D2>If Alice calls BOB, you know from your application =
translation (E164 or through domain names) that you are going outside =
of your VPN.</FONT></P>

<P><FONT SIZE=3D2>Assuming that MB discovery is not used, you will =
configure on the agent that users of telephony VPN A are behind Middle =
Boxes x,y and z.</FONT></P>

<P><FONT SIZE=3D2>Based on the translation of the uri or the E164 =
number, the agent knows that it is an extra VPN call (again telephony =
VPN).Now it has to discuss MIDCOM with one of the MBs.</FONT></P>

<P><FONT SIZE=3D2>1- By looking through the *crystal ball* (:-) the =
agent knows that y is the MB to talk to. </FONT>
<BR><FONT SIZE=3D2>The problem is that MB y is a provider provisioned =
MB where other realms overlap on the address realm of VPN B (here I'm =
talking of IP VPN). How can I use the standard matching expression to =
identify the flow (i.e 5 tuple) ?</FONT></P>

<P><FONT SIZE=3D2>By some way I need to tell my MB y that I'm talking =
of traffing flowing from realm B to the outer realm, the outer realm is =
probably the registered address realm (i.e. public realm), in case it =
is not I will need to indicate it because maybe it is overlapped by =
another (or several realms) that MB y is connected to; thus requiring =
the outer realm id.</FONT></P>

<P><FONT SIZE=3D2>This is the reason to have the realm identifier(s) in =
the n tuple.</FONT>
<BR><FONT SIZE=3D2>Since we are already configuring application client =
information on the application servers (user id ...), the realm id will =
not be such an overload.</FONT></P>

<P><FONT SIZE=3D2>In case Alice calls Pat who is in telephony VPN A, =
the MA knows that it doesn't need to get in touch with the MB.</FONT>
<BR><FONT SIZE=3D2>I don't know if could use the same analogy to other =
applications or not (any comments ?)</FONT>
</P>

<P><FONT SIZE=3D2>I tried to raise the concerns/reasons relevant to =
topology, I think that they are quite clear in this example =
(hopefully).</FONT></P>

<P><FONT SIZE=3D2>Cedric</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jiri Kuthan [<A =
HREF=3D"mailto:kuthan@fokus.gmd.de">mailto:kuthan@fokus.gmd.de</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Monday, August 13, 2001 5:26 PM</FONT>
<BR><FONT SIZE=3D2>To: Mark Duffy; Mark Duffy; lear@cisco.com; Scott =
Brim</FONT>
<BR><FONT SIZE=3D2>Cc: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [midcom] policy &amp; duration</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mark,</FONT>
</P>

<P><FONT SIZE=3D2>I am still sceptic about agent's ability to figure =
out the direction.</FONT>
<BR><FONT SIZE=3D2>In the example I gave before agents actually do not =
know. The only thing</FONT>
<BR><FONT SIZE=3D2>a SIP proxy surely knows is destination address and =
port number of media. </FONT>
<BR><FONT SIZE=3D2>(It also might try to guess source IP address, =
though guessing might fail). </FONT>
<BR><FONT SIZE=3D2>So it might try to infer direction from the 5-tuple. =
Doing so is </FONT>
<BR><FONT SIZE=3D2>however not app-specific and might be done in =
middleboxes as well.</FONT>
</P>

<P><FONT SIZE=3D2>Consider the following example: two SIP phones which =
are registered with a company's</FONT>
<BR><FONT SIZE=3D2>SIP server are temporarily in an external network. =
Which means there is no need</FONT>
<BR><FONT SIZE=3D2>for pinholes at all if they want to speak to each =
other! Who will figure it out?</FONT>
<BR><FONT SIZE=3D2>I doubt there is something useful for determining =
the direction what a SIP proxy knows </FONT>
<BR><FONT SIZE=3D2>a middlebox does not. A middlebox can be configured =
to guess which IP</FONT>
<BR><FONT SIZE=3D2>addresses is external and which not. Doing the same =
in every agent </FONT>
<BR><FONT SIZE=3D2>is lot of work which is perhaps not needed.</FONT>
</P>

<P><FONT SIZE=3D2>This is where my doubts for use of interfaces come =
from. </FONT>
</P>

<P><FONT SIZE=3D2>-Jiri</FONT>
</P>

<P><FONT SIZE=3D2>At 12:57 PM 8/10/2001, Mark Duffy wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;In general, a mb has no idea what direction =
anything *wants* to go in.&nbsp; All</FONT>
<BR><FONT SIZE=3D2>&gt;it does is open pinholes etc at the behest of =
agents.&nbsp; If the agent, with</FONT>
<BR><FONT SIZE=3D2>&gt;the applic. intelligence, can't determine that, =
then probably no one can --</FONT>
<BR><FONT SIZE=3D2>&gt;maybe in that case the agent should just ask the =
mb for both directions.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;From the point of view of the typical mb, a =
5-tuple in one direction is</FONT>
<BR><FONT SIZE=3D2>&gt;completely different from the same 5-tuple in =
the opposite direction.&nbsp; If</FONT>
<BR><FONT SIZE=3D2>&gt;the agent via the midcom protocol cannot express =
that difference, then the</FONT>
<BR><FONT SIZE=3D2>&gt;overall system is essentially dumbed-down to =
that level.&nbsp; The result would</FONT>
<BR><FONT SIZE=3D2>&gt;be reduced security, if packets matching an =
n-tuple are permitted in either</FONT>
<BR><FONT SIZE=3D2>&gt;direction when in fact they should only be =
permitted in one.&nbsp; I believe</FONT>
<BR><FONT SIZE=3D2>&gt;that would be an unacceptable reduction in =
security.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-Mark</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;At 05:37 PM 8/9/01 +0200, Jiri Kuthan =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;How does a, say SIP proxy, know what the =
direction of a media stream</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;belonging to a SIP session will be?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;-Jiri</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;At 04:21 PM 8/8/2001, Mark Duffy =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Also, I think we remove =
directionality at our peril.&nbsp; In an</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;internal/external communication, the =
reversing of directional rules on</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;interfaces would lead to a weakening =
of enterprise security.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Not only that, but the directionality is =
already an aspect of the existing</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;firewall functionality we are providing =
control over.&nbsp; I too believe</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;directionality should be =
included.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;<A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A> =
</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Jiri =
Kuthan&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 <A HREF=3D"http://iptel.org/~jiri" =
TARGET=3D"_blank">http://iptel.org/~jiri</A></FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12670.7E306CE0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 12:33:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15353
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:33:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23254;
	Thu, 16 Aug 2001 12:21:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23223
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 12:21:36 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15075
	for <midcom@ietf.org>; Thu, 16 Aug 2001 12:20:23 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA26815
	for <midcom@ietf.org>; Thu, 16 Aug 2001 11:21:05 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Thu, 16 Aug 2001 09:13:24 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5XV81VD>; Thu, 16 Aug 2001 09:20:46 -0700
Message-ID: <A7895B732354D311A4770008C791841A013F466F@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>,
        "'Melinda Shore'" <mshore@cisco.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Deleting requirements -tuple items
Date: Thu, 16 Aug 2001 09:20:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1266F.66407450"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1266F.66407450
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Melinda,

I second Mark on this. Just because the AD (I think in this case Scott
Bardner) wants that, doen't mean we all have to comply blindly. Of course I
respect Scott's direction on this, but my opinion is different. Otherwise
the IETF stop being a "rough consensus and running code" to a "you do what I
told you to".

We can as Mark propose,

1.  Remove all requirements or parts of requirements that state what the
components of the n-tuple are.  Leave this to be determined later.

And also base my opinion due to the fact that I agree with you when you say
that "It appears to be intended to
be comprehensive, but the fact is that network operators are filtering on
all sorts of stuff, not just what's listed here."
 

regards,

Reinaldo



> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]
> Sent: Thursday, August 16, 2001 9:00 AM
> To: Melinda Shore; Mark Duffy; Mark Duffy; midcom@ietf.org
> Subject: Re: [midcom] Deleting requirements -tuple items
> 
> 
> At 11:00 AM 8/16/01 -0400, Melinda Shore wrote:
> >First, I've got to say that I'm pretty disappointed that people
> >aren't listening to the *very* clear message coming down from 
> >the ADs.  Small is beautiful, trim the fat, the 5-tuple is
> >sufficient for now, etc.
> 
> Melinda, I don't think it is realistic to expect everyone to 
> just get in
> line for that -- not everyone has the same objectives as the ADs.  I
> suggest that you as chair should declare this out of scope for the
> requirements, if you and the ADs feel it is.  Otherwise it 
> should be up to
> the wg concensus whether this belongs in the requirements or not.
> 
> BTW I did present this option in my email, along with the 
> proposed list of
> tuple requirements, perhaps you missed it:
> 
> >1.  Remove all requirements or parts of requirements that 
> state what the
> >components of the n-tuple are.  Leave this to be determined later.
> 
> 
> 
> >Second, this is actually a very good representation of the 
> problem with 
> >enumerating the filtering elements.  It appears to be intended to
> >be comprehensive, but the fact is that network operators are 
> filtering
> 
> Actually, it was not intended to be comprhensive of the 
> possibilities, only
> comprehensive of what was already in the requirements doc.
> 
> >on all sorts of stuff, not just what's listed here.  Another problem
> >is how this is going to scale.  When you talk about using a 
> "don't care"
> >flag for elements as needed, you're saying that the whole 
> filter needs
> >to be sent down every time.  It's either going to become 
> very large or
> 
> No, I didn't say that.  I just proposed requirements for an 
> initial list of
> elements to support.  It is a protocol design issue whether 
> they all need
> to be sent every time (and as you point out, that might well be a poor
> design).
> 
> >it's going to remain insufficient.
> >
> >Third, see item the first.
> >
> >Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C1266F.66407450
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Deleting requirements -tuple items</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello Melinda,</FONT>
</P>

<P><FONT SIZE=3D2>I second Mark on this. Just because the AD (I think =
in this case Scott Bardner) wants that, doen't mean we all have to =
comply blindly. Of course I respect Scott's direction on this, but my =
opinion is different. Otherwise the IETF stop being a &quot;rough =
consensus and running code&quot; to a &quot;you do what I told you =
to&quot;.</FONT></P>

<P><FONT SIZE=3D2>We can as Mark propose,</FONT>
</P>

<P><FONT SIZE=3D2>1.&nbsp; Remove all requirements or parts of =
requirements that state what the components of the n-tuple are.&nbsp; =
Leave this to be determined later.</FONT></P>

<P><FONT SIZE=3D2>And also base my opinion due to the fact that I agree =
with you when you say that &quot;It appears to be intended to</FONT>
<BR><FONT SIZE=3D2>be comprehensive, but the fact is that network =
operators are filtering on all sorts of stuff, not just what's listed =
here.&quot;</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, August 16, 2001 9:00 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Melinda Shore; Mark Duffy; Mark Duffy; =
midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] Deleting requirements =
-tuple items</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 11:00 AM 8/16/01 -0400, Melinda Shore =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;First, I've got to say that I'm pretty =
disappointed that people</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;aren't listening to the *very* clear =
message coming down from </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;the ADs.&nbsp; Small is beautiful, trim the =
fat, the 5-tuple is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;sufficient for now, etc.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda, I don't think it is realistic to =
expect everyone to </FONT>
<BR><FONT SIZE=3D2>&gt; just get in</FONT>
<BR><FONT SIZE=3D2>&gt; line for that -- not everyone has the same =
objectives as the ADs.&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; suggest that you as chair should declare this =
out of scope for the</FONT>
<BR><FONT SIZE=3D2>&gt; requirements, if you and the ADs feel it =
is.&nbsp; Otherwise it </FONT>
<BR><FONT SIZE=3D2>&gt; should be up to</FONT>
<BR><FONT SIZE=3D2>&gt; the wg concensus whether this belongs in the =
requirements or not.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; BTW I did present this option in my email, =
along with the </FONT>
<BR><FONT SIZE=3D2>&gt; proposed list of</FONT>
<BR><FONT SIZE=3D2>&gt; tuple requirements, perhaps you missed =
it:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;1.&nbsp; Remove all requirements or parts =
of requirements that </FONT>
<BR><FONT SIZE=3D2>&gt; state what the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;components of the n-tuple are.&nbsp; Leave =
this to be determined later.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Second, this is actually a very good =
representation of the </FONT>
<BR><FONT SIZE=3D2>&gt; problem with </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;enumerating the filtering elements.&nbsp; =
It appears to be intended to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;be comprehensive, but the fact is that =
network operators are </FONT>
<BR><FONT SIZE=3D2>&gt; filtering</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Actually, it was not intended to be =
comprhensive of the </FONT>
<BR><FONT SIZE=3D2>&gt; possibilities, only</FONT>
<BR><FONT SIZE=3D2>&gt; comprehensive of what was already in the =
requirements doc.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;on all sorts of stuff, not just what's =
listed here.&nbsp; Another problem</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;is how this is going to scale.&nbsp; When =
you talk about using a </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;don't care&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;flag for elements as needed, you're saying =
that the whole </FONT>
<BR><FONT SIZE=3D2>&gt; filter needs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;to be sent down every time.&nbsp; It's =
either going to become </FONT>
<BR><FONT SIZE=3D2>&gt; very large or</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No, I didn't say that.&nbsp; I just proposed =
requirements for an </FONT>
<BR><FONT SIZE=3D2>&gt; initial list of</FONT>
<BR><FONT SIZE=3D2>&gt; elements to support.&nbsp; It is a protocol =
design issue whether </FONT>
<BR><FONT SIZE=3D2>&gt; they all need</FONT>
<BR><FONT SIZE=3D2>&gt; to be sent every time (and as you point out, =
that might well be a poor</FONT>
<BR><FONT SIZE=3D2>&gt; design).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;it's going to remain insufficient.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Third, see item the first.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1266F.66407450--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 16:26:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21975
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 16:26:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29186;
	Thu, 16 Aug 2001 16:24:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29110
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 16:24:46 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21952
	for <midcom@ietf.org>; Thu, 16 Aug 2001 16:23:32 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D013P; Thu, 16 Aug 2001 16:24:15 -0400
Message-Id: <3.0.5.32.20010816162332.00964760@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 16 Aug 2001 16:23:32 -0400
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
From: Mark Duffy <mduffy@quarrytech.com>
Subject: RE: [midcom] policy & duration
Cc: midcom@ietf.org
In-Reply-To: <9154CB41F208D5118DD200508BE39C304451A9@zjguc006.europe.nor
 tel.com>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Yes!


At 05:28 PM 8/16/01 +0100, Cedric Aoun wrote: 

>>>>

<excerpt>The problem is that MB y is a provider provisioned MB where
other realms overlap on the address realm of VPN B (here I'm talking of
IP VPN). How can I use the standard matching expression to identify the
flow (i.e 5 tuple) ?


By some way I need to tell my MB y that I'm talking of traffing flowing
from realm B to the outer realm, the outer realm is probably the
registered address realm (i.e. public realm), in case it is not I will
need to indicate it because maybe it is overlapped by another (or several
realms) that MB y is connected to; thus requiring the outer realm id.


This is the reason to have the realm identifier(s) in the n tuple. 

Since we are already configuring application client information on the
application servers (user id ...), the realm id will not be such an
overload.

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



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 16:46:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22539
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 16:46:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29671;
	Thu, 16 Aug 2001 16:46:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29638
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 16:46:15 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22527
	for <midcom@ietf.org>; Thu, 16 Aug 2001 16:45:01 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7GKk1T09899
	for <midcom@ietf.org>; Thu, 16 Aug 2001 13:46:01 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp85.cisco.com [10.21.64.85])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACM27721;
	Thu, 16 Aug 2001 13:45:42 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010816164208.00a1a660@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 Aug 2001 16:46:59 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Meeting notes, first draft
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Mary Barnes and Cedric Aoun took outstanding notes at Friday's
meeting.  Unfortunately I had to edit them down to meet the
IETF keeper-of-the-minutes requirements, but I will put the
original up for download and let you know where they are.

In the meantime, I've appended a first draft of the minutes.
Please look them over and post comments to the mailing list.

And many, many thanks to Mary and Cedric.

Melinda

Minutes of midcom working group at 51st IETF Meeting London, England
Friday, August 10, 2001, 9:00-11:30

Chaired by Melinda Shore (mshore@cisco.com)
Reported by Mary Barnes (mbarnes@nortelnetworks.com) and
   Cedric Aoun (cedric.aoun@nortelnetworks.com), edited by
   Melinda Shore


Status update/working methods:
  * Neither document editor was able to be present.
  * Both docs are supposed to be in last call this month.
  * Framework document was in last call, had to be stopped
    due to issues raised.
  * Issues (showstoppers) need to be raised ASAP.  4 people
    need to object for consensus not to be agreed.


Relationship to OPES - Open Pluggable Edge Services  (Michael Condry)
--------
OPES is about building application level services between
where the content starts and where the content ends (both IP
endpoints), typically web services.  The working group is
looking at callout protocols that go to something like an
ALG.  Does service and ships elsewhere.  Will ensure that
overlap with MIDCOM is cross pollinated.  OPES is looking at
application middleboxes, while MIDCOM is looking at
transport middleboxes.

Example:
Presentation services at the edge of the network (close to
the "consumer")


Framework document (discussion led by Jiri Kuthan):
--------
Current Issues:
There's a great deal of terminology that isn't agreed
upon.  We will form a design team 

There's currently a requirement for rule "ownership.  The
intent is to keep someone from closing someone else's
pinhole.  Some folks want multiple owners to handle
takeover-type scenarios.

The ensuing discussion centered around the following
points/questions: 
1) is "ownership" useful"
2) what is the basis of ownership?
3) what is the underlying model (file locking
   vs. authorization) 
4) is this the correct robustness model?

Jiri Kuthan will develop some text around the ownership
question and submit it to the list.

Another unresolved issue is whether the MIDCOM protocol will
be peer-to-peer or client/server.  The consensus was that it
will be client/server.

A discussion of identifiers/handles for the open "pinholes"
and "sessions" raised additional questions about how pinhole
requests should be specified.  There was a suggestion that
the things that are created on the middlebox (firewall
pinholes, NAT mappings) may be identified by the contents of
the things themselves (such as a 5-tuple describing a
firewall pinhole) or by an identifier allocated by the
middlebox.  Concerns included how (and whether) to
aggregate, directionality, whether allocation and open are
separate operations, and whether or not atomic actions
across multiple middleboxes should be supported.  The group
concluded that there was a need for a design team, to be
shepherded by Christian Huitema.  Their job is to restate
the problem more clearly.

Jiri asked if there's an issue with fragmented packets
traversing the middlebox.  The consensus was that this is
not the working group's problem.

The working group has been unable to resolve the question of
how network topology should be handled by the midcom agent.
Because we've had so little progress despite extensive
discussion, the chair proposed forming a design team.  Ted
Hardie suggested that instead we should use the old IETF
contest of champions approach, in which champions write
drafts describing their solution to the problem.  The chair
agreed.  The Area Director present, Scott Bradner, agreed
with this approach and indicated that the Transport Area
Directors will assist in evaluating the proposals.

Someone asked why we have a design team for one problem and
a contest for another area.  The design teams are for work
that's currently within the charter and on which there's
fundamental agreement about what we're doing.  The contest
of champions approach is being used for the topology
question because there is not even basic agreement on what
the question is, and there's a need to define the problem.

Requirements document (discussion led by Paul Sijben)
--------
Status:
* Information get togethers have given a lot of input

* Scott Brim has been maintaining a list of requirements
  that are either implicit in the framework document and are
  unresolved or are explicit and unresolved.

The discussion in the meeting focused on 1) the structure of
working group deliverable, and 2) trying to get common
understanding on remaining issues (based on Scott's list)

There was general agreement that there were far too many
requirements, although Graham Travers disagreed with trying
to place a limit on the number of requirements.  Christian
Huitema said that the document should be about six pages
long.

Paul Sijben said that the document should not be simply a
bulleted list of requirements.  It was reiterated that it
shouldn't be necessary to have no requirements in the
framework document and no discussion in the requirements
document, but that some seepage was inevitable.  Scott
Bradner said that a list of requirements without explanation
is almost useless, and that a thick document is almost
useless.  If it takes more than a paragraph then it's
probably too long.

Terminology needs to be defined in the framework document
and then used consistently in both documents.

Unresolved Issues:
Elliot Lear is preparing the definition of a pinhole.
Elliot said that there were a bunch of requirements
describing the purpose of a pinhole with regard to
associated resources, and this should roll up to policy.
He's come come up with a general description but it may be
misconstrued as describing the protocol.  The only
information in the protocol should be that necessary to
describe the policy.  An extensive discussion of which
elements to include, including directionality, left the
question still unresolved.  

The issue of whether or not agents must be known to
endsystem applications has been closed, and the text has
been deleted.

Requirement R18 from Scott Brim's list of unresolved issues
says that the middlebox MUST NOT alter packet information
unless it appears in the packet header.  Paul Sijben said
taht the reason for the requirement is to have a clear
separation of concerns.  Objections included that the
definition of "header" is unclear.  It was pointed out that
we cannot put requirements on the middlebox.  Dave Oran said
that the requirement has no technical content and proposed
that it could be rewritten to say that the middlebox is not
permitted to write a transformation rule that operates on
something that is not specified in a filter.  The chair
started a poll asking how many people wanted the requirement
gone completely (some), how many people wanted to keep the
requirement as is (none), and how many people want to
discuss Dave Oran's proposal.  The last was interrupted by
Scott Bradner, who said that the requirement would not go
through the IESG.  It was therefore dropped.

* Requirement R3a: The MIDCOM protocol MUST support
  communication between multiple MIDCOM agents and multiple
  middleboxes.

Someone said that the requirement should be that one agent
may open a pinhole and another may close it, and that the
requirement needs to be reworded.  Scott Brim responded that
it wasn't intended for two agents working on the same
pinhole, but that a middlebox can talk to more than one
midcom agents (and tell the difference).  Scott then said
that it should either be tossed out or split in two.  It was
agreed that it should be split into two requirements.

* Issue: There must be ownership of resources/pinholes, and
  there must be a way to transfer this ownership from one
  agent to another

Christian said to leave it to the policy server.  There is
authorization, but it's not expressed in terms of ownership.
Someone responded that we don't want it expressed in terms
of policy, and proposed that agents should coordinate
ownership outside the protocol.  Dave Oran asked whether
ownership is a 1) security or 2) mutual exclusion property.
Paul said it's not about mutual exclusion.  Dave then
suggested that this is a capability-based authorization,
although he thinks that capabilities are a bad idea.
Christian said that he didn't like the implications of
ownership transfer.  Jiri is going to work on some alternate
text.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 19:25:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27457
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 19:25:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05184;
	Thu, 16 Aug 2001 19:07:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05155
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 19:07:02 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27152
	for <midcom@ietf.org>; Thu, 16 Aug 2001 19:05:50 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7GN6Wg19100
	for <midcom@ietf.org>; Fri, 17 Aug 2001 00:06:32 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 17 Aug 2001 00:06:13 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RBXZ9PZP>; Fri, 17 Aug 2001 00:06:12 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451B9@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "Midcom IETF (E-mail)" <midcom@ietf.org>
Subject: Re: [midcom] Filtering rules
Date: Fri, 17 Aug 2001 00:06:15 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C126A8.0CBDEFA0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C126A8.0CBDEFA0
Content-Type: text/plain;
	charset="iso-8859-1"


I think that the following statement could buy peace on earth:

The agent requires the Middle Box to provide services over a stream or
several streams (open pinhole, provide a BIND ...), therefore the MB needs
to have a proper matching (or filtering expression) to identify the
stream(s) on which it will apply the requested service.

Comments?

Cedric

-----Original Message-----
From: Paul Sijben [mailto:sijben@lucent.com]
Sent: Wednesday, August 15, 2001 10:32 AM
To: Scott Bradner; mshore@cisco.com; midcom@ietf.org
Subject: Re: [midcom] Filtering rules


Scott,

after having slept a night over this issue. I believe you are right. Just
the 5-tuple will do nicely for anything we may come up with at the moment
and it will not unduly inconvenience us when selecting a protocol.

paul

Paul Sijben wrote:
> 
> Scott,
> 
> > also - I see no reason that the midcom protocol needs to change just
> > because of a change in filter rules - any such rules should be
> > sent in a chunk to the midcom box which can then say 'can not do' if
> > it does not know how to do what has been asked
> 
> I can agree with you there if we were to create a _new_ protocol. Yet we
> are supposed to _select_ one that exists when the requirements are done.
> So the power we may seek in the filtering may guide our protocol choice.
> 
> Paul
> 
> Scott Bradner wrote:
> >
> > > I would appreciate some guidance in this matter from the ADs. If we
can
> > > not specify in enough detail WHAT we want to filter/transform etc on.
> > > Selecting a protocol will be impossible and we will need to go through
> > > another (semi) requirements round to get additional information.
> >
> > I see no need to spend time at this point figuring out all possible
filters
> > I would like the WG to define a basic 'punch a pinhole' function for
> > a single stream and identify the stream in the simplest possible way.
> > i.e. 5-tuples
> >
> > this should be sufficient to get something that will work - when that
> > is done we can worry about creating the filter language from hell if
> > that is what the Internet community feels it needs.
> >
> > also - I see no reason that the midcom protocol needs to change just
> > because of a change in filter rules - any such rules should be
> > sent in a chunk to the midcom box which can then say 'can not do' if
> > it does not know how to do what has been asked
> >
> > Scott (the AD in question)
> 
> --
> Paul Sijben              Tel:+31 356874774
> Lucent Technologies      Fax:+31 356875954
> Forward Looking Work
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C126A8.0CBDEFA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Re:  [midcom] Filtering rules</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I think that the following statement could buy peace =
on earth:</FONT>
</P>

<P><FONT SIZE=3D2>The agent requires the Middle Box to provide services =
over a stream or several streams (open pinhole, provide a BIND ...), =
therefore the MB needs to have a proper matching (or filtering =
expression) to identify the stream(s) on which it will apply the =
requested service.</FONT></P>

<P><FONT SIZE=3D2>Comments?</FONT>
</P>

<P><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Paul Sijben [<A =
HREF=3D"mailto:sijben@lucent.com">mailto:sijben@lucent.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 15, 2001 10:32 AM</FONT>
<BR><FONT SIZE=3D2>To: Scott Bradner; mshore@cisco.com; =
midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [midcom] Filtering rules</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Scott,</FONT>
</P>

<P><FONT SIZE=3D2>after having slept a night over this issue. I believe =
you are right. Just</FONT>
<BR><FONT SIZE=3D2>the 5-tuple will do nicely for anything we may come =
up with at the moment</FONT>
<BR><FONT SIZE=3D2>and it will not unduly inconvenience us when =
selecting a protocol.</FONT>
</P>

<P><FONT SIZE=3D2>paul</FONT>
</P>

<P><FONT SIZE=3D2>Paul Sijben wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Scott,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; also - I see no reason that the midcom =
protocol needs to change just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; because of a change in filter rules - any =
such rules should be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sent in a chunk to the midcom box which =
can then say 'can not do' if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it does not know how to do what has been =
asked</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I can agree with you there if we were to create =
a _new_ protocol. Yet we</FONT>
<BR><FONT SIZE=3D2>&gt; are supposed to _select_ one that exists when =
the requirements are done.</FONT>
<BR><FONT SIZE=3D2>&gt; So the power we may seek in the filtering may =
guide our protocol choice.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Paul</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Scott Bradner wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I would appreciate some guidance in =
this matter from the ADs. If we can</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; not specify in enough detail WHAT we =
want to filter/transform etc on.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Selecting a protocol will be =
impossible and we will need to go through</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; another (semi) requirements round to =
get additional information.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I see no need to spend time at this point =
figuring out all possible filters</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I would like the WG to define a basic =
'punch a pinhole' function for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a single stream and identify the stream in =
the simplest possible way.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; i.e. 5-tuples</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this should be sufficient to get something =
that will work - when that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is done we can worry about creating the =
filter language from hell if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that is what the Internet community feels =
it needs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; also - I see no reason that the midcom =
protocol needs to change just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; because of a change in filter rules - any =
such rules should be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sent in a chunk to the midcom box which =
can then say 'can not do' if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it does not know how to do what has been =
asked</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Scott (the AD in question)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Paul =
Sijben&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; Tel:+31 356874774</FONT>
<BR><FONT SIZE=3D2>&gt; Lucent =
Technologies&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax:+31 356875954</FONT>
<BR><FONT SIZE=3D2>&gt; Forward Looking Work</FONT>
<BR><FONT SIZE=3D2>&gt; Huizen, The Netherlands&nbsp; <A =
HREF=3D"http://voip.nl.lucent.com/~sijben" =
TARGET=3D"_blank">http://voip.nl.lucent.com/~sijben</A> =
(internal)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Paul =
Sijben&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; Tel:+31 356874774 </FONT>
<BR><FONT SIZE=3D2>Lucent Technologies&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax:+31 356875954</FONT>
<BR><FONT SIZE=3D2>Forward Looking Work&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Huizen, The Netherlands&nbsp; <A =
HREF=3D"http://voip.nl.lucent.com/~sijben" =
TARGET=3D"_blank">http://voip.nl.lucent.com/~sijben</A> =
(internal)</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C126A8.0CBDEFA0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 19:39:29 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27724
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 19:39:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05961;
	Thu, 16 Aug 2001 19:30:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05934
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 19:30:51 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27529
	for <midcom@ietf.org>; Thu, 16 Aug 2001 19:29:39 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA27120
	for <midcom@ietf.org>; Thu, 16 Aug 2001 18:30:18 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Thu, 16 Aug 2001 18:23:33 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YHD9D7>; Thu, 16 Aug 2001 18:29:41 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF50@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Deleting requirements
Date: Thu, 16 Aug 2001 18:29:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C126AB.51AFE6B0"
X-Orig: <sanjoy@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C126AB.51AFE6B0
Content-Type: text/plain;
	charset="iso-8859-1"

I would support deletion of all proposed by Melinda except R74. The reason
is, the MA should be able to know the capabilities/resources (e.g., # of
available NAT ports) of MB after establishing the "communications
relationship" with the MB. This would be useful, for example, to allow a SIP
call Server (associated with the MA) to make a decision on whether to
admit/reject a new call.

Sanjoy

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, August 15, 2001 4:02 PM
> To: Scott Brim; midcom@ietf.org
> Subject: Re: [midcom] Deleting requirements
> 
> 
> At 03:55 PM 8/15/01 -0400, Scott Brim wrote:
> >(Must be able to request specific addr/port.)  Are you saying that
> >shouldn't be a requirement, or that it's obvious?  Personally I'm in
> >favor.  It's easy.
> 
> I think it's obvious.
> 
> >(Robust in face of packet loss.)  Again, why?  Because it's obvious?
> 
> I think so.  Consider the alternative.
> 
> >> R27
> >
> >(Low latency.)  Why?
> 
> I could go either way on it.  I'm not convinced that it's a
> necessary requirement, but I could be.  At any rate, I'm just
> putting it out there.
> 
> >> R50 (redundant with R40)
> >
> >No.  R50 says you should be able to specify DSCP for 
> matching on (note,
> >this is NOT saying you can say what QoS treatment to GIVE 
> the packets).
> >R40 only covers the basic tuple.
> 
> Right, but if we decide to define the filter elements at all (and 
> I tend to think that we should not), it should be in one place.
> 
> >And where would that be?  That's what this requirement was 
> supposed to
> >be for :-)
> 
> We need one requirement saying that the protocol must support both
> v4 and v6 addresses.  Come to think of it, we need a 
> requirement saying
> that the protocol should run over both v4 and v6 networks.
> 
> >> R56
> >
> >Well, ICMP type is not part of the usual tuple and could easily be
> >overlooked.  I think this one could use some consensus.  
> 
> See my comments on R50.
> 
> >I won't do anything with any of these until the Chair 
> declares consensus
> >on them (individually).  
> 
> That's why I've put out a proposal to delete these.  I'm trying to 
> get yes/no answers.
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C126AB.51AFE6B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Deleting requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I would support deletion of all proposed by Melinda =
except R74. The reason is, the MA should be able to know the =
capabilities/resources (e.g., # of available NAT ports) of MB after =
establishing the &quot;communications relationship&quot; with the MB. =
This would be useful, for example, to allow a SIP call Server =
(associated with the MA) to make a decision on whether to admit/reject =
a new call.</FONT></P>

<P><FONT SIZE=3D2>Sanjoy</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 15, 2001 4:02 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Scott Brim; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] Deleting =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 03:55 PM 8/15/01 -0400, Scott Brim =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(Must be able to request specific =
addr/port.)&nbsp; Are you saying that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;shouldn't be a requirement, or that it's =
obvious?&nbsp; Personally I'm in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;favor.&nbsp; It's easy.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think it's obvious.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(Robust in face of packet loss.)&nbsp; =
Again, why?&nbsp; Because it's obvious?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think so.&nbsp; Consider the =
alternative.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; R27</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(Low latency.)&nbsp; Why?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I could go either way on it.&nbsp; I'm not =
convinced that it's a</FONT>
<BR><FONT SIZE=3D2>&gt; necessary requirement, but I could be.&nbsp; At =
any rate, I'm just</FONT>
<BR><FONT SIZE=3D2>&gt; putting it out there.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; R50 (redundant with R40)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;No.&nbsp; R50 says you should be able to =
specify DSCP for </FONT>
<BR><FONT SIZE=3D2>&gt; matching on (note,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;this is NOT saying you can say what QoS =
treatment to GIVE </FONT>
<BR><FONT SIZE=3D2>&gt; the packets).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;R40 only covers the basic tuple.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Right, but if we decide to define the filter =
elements at all (and </FONT>
<BR><FONT SIZE=3D2>&gt; I tend to think that we should not), it should =
be in one place.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;And where would that be?&nbsp; That's what =
this requirement was </FONT>
<BR><FONT SIZE=3D2>&gt; supposed to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;be for :-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We need one requirement saying that the =
protocol must support both</FONT>
<BR><FONT SIZE=3D2>&gt; v4 and v6 addresses.&nbsp; Come to think of it, =
we need a </FONT>
<BR><FONT SIZE=3D2>&gt; requirement saying</FONT>
<BR><FONT SIZE=3D2>&gt; that the protocol should run over both v4 and =
v6 networks.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; R56</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Well, ICMP type is not part of the usual =
tuple and could easily be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;overlooked.&nbsp; I think this one could =
use some consensus.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; See my comments on R50.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I won't do anything with any of these until =
the Chair </FONT>
<BR><FONT SIZE=3D2>&gt; declares consensus</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;on them (individually).&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That's why I've put out a proposal to delete =
these.&nbsp; I'm trying to </FONT>
<BR><FONT SIZE=3D2>&gt; get yes/no answers.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C126AB.51AFE6B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 16 23:06:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01598
	for <midcom-archive@odin.ietf.org>; Thu, 16 Aug 2001 23:06:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09618;
	Thu, 16 Aug 2001 22:53:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09545
	for <midcom@ns.ietf.org>; Thu, 16 Aug 2001 22:53:25 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01486
	for <midcom@ietf.org>; Thu, 16 Aug 2001 22:52:11 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7H2qsg27534
	for <midcom@ietf.org>; Fri, 17 Aug 2001 03:52:54 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 17 Aug 2001 03:52:53 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RBXZ9Q6X>; Fri, 17 Aug 2001 03:52:51 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451BE@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>, midcom@ietf.org
Subject: RE: [midcom] question about direction requirements
Date: Fri, 17 Aug 2001 03:52:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C126C7.B83B0E70"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C126C7.B83B0E70
Content-Type: text/plain;
	charset="iso-8859-1"

"Discussion:  Legacy middleboxes typically allow for rules that says e.g.:
open pinhole for packets matching this tuple only if the tcp (etc.) session
is  initiated from inside towards outside.  Do we need the midcom agent to
be able to specify such a rule?"

This = allow tcp SYN sent inside towards outside.
This is similar to R55 but with the added direction, and I support that this
is required. 

It's just on in which format does this go to into the reqs document.

We need to decide to group all the matching expression under, something
similar to:
The protocol should have sufficient syntax to allow the MB to identify a
flow by all it's possible characteristics.
Or depict every single matching expression, I think that everybody will
raise hands for the previous (although it sounds a bit really really
general).

Cedric


-----Original Message-----
From: Mark Duffy [mailto:mduffy@quarrytech.com]
Sent: Thursday, August 16, 2001 6:23 AM
To: midcom@ietf.org
Subject: [midcom] question about direction requirements


Another requirements question related to direction.  The proposed
requirements mention direction as part of the tuple.  My understanding is
that this refers to direction of individual packets.  Do we also need
support for expressing to the middlebox the direction of transport session
setup?

We might consider adding the following requirement to the to-be-discussed
list:

Ri:  The Midcom protocol must allow the agent to specify to the middlebox
that a pinhole (etc...) is to be opened only if the transport connection as
viewed by the middlebox is initiated in a certain direction relative to the
realms mediated by the middlebox.

Discussion:  Legacy middleboxes typically allow for rules that says e.g.:
open pinhole for packets matching this tuple only if the tcp (etc.) session
is  initiated from inside towards outside.  Do we need the midcom agent to
be able to specify such a rule?



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C126C7.B83B0E70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] question about direction requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&quot;Discussion:&nbsp; Legacy middleboxes typically =
allow for rules that says e.g.:</FONT>
<BR><FONT SIZE=3D2>open pinhole for packets matching this tuple only if =
the tcp (etc.) session</FONT>
<BR><FONT SIZE=3D2>is&nbsp; initiated from inside towards =
outside.&nbsp; Do we need the midcom agent to</FONT>
<BR><FONT SIZE=3D2>be able to specify such a rule?&quot;</FONT>
</P>

<P><FONT SIZE=3D2>This =3D allow tcp SYN sent inside towards =
outside.</FONT>
<BR><FONT SIZE=3D2>This is similar to R55 but with the added direction, =
and I support that this is required. </FONT>
</P>

<P><FONT SIZE=3D2>It's just on in which format does this go to into the =
reqs document.</FONT>
</P>

<P><FONT SIZE=3D2>We need to decide to group all the matching =
expression under, something similar to:</FONT>
<BR><FONT SIZE=3D2>The protocol should have sufficient syntax to allow =
the MB to identify a flow by all it's possible characteristics.</FONT>
<BR><FONT SIZE=3D2>Or depict every single matching expression, I think =
that everybody will raise hands for the previous (although it sounds a =
bit really really general).</FONT></P>

<P><FONT SIZE=3D2>Cedric</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, August 16, 2001 6:23 AM</FONT>
<BR><FONT SIZE=3D2>To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [midcom] question about direction =
requirements</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Another requirements question related to =
direction.&nbsp; The proposed</FONT>
<BR><FONT SIZE=3D2>requirements mention direction as part of the =
tuple.&nbsp; My understanding is</FONT>
<BR><FONT SIZE=3D2>that this refers to direction of individual =
packets.&nbsp; Do we also need</FONT>
<BR><FONT SIZE=3D2>support for expressing to the middlebox the =
direction of transport session</FONT>
<BR><FONT SIZE=3D2>setup?</FONT>
</P>

<P><FONT SIZE=3D2>We might consider adding the following requirement to =
the to-be-discussed</FONT>
<BR><FONT SIZE=3D2>list:</FONT>
</P>

<P><FONT SIZE=3D2>Ri:&nbsp; The Midcom protocol must allow the agent to =
specify to the middlebox</FONT>
<BR><FONT SIZE=3D2>that a pinhole (etc...) is to be opened only if the =
transport connection as</FONT>
<BR><FONT SIZE=3D2>viewed by the middlebox is initiated in a certain =
direction relative to the</FONT>
<BR><FONT SIZE=3D2>realms mediated by the middlebox.</FONT>
</P>

<P><FONT SIZE=3D2>Discussion:&nbsp; Legacy middleboxes typically allow =
for rules that says e.g.:</FONT>
<BR><FONT SIZE=3D2>open pinhole for packets matching this tuple only if =
the tcp (etc.) session</FONT>
<BR><FONT SIZE=3D2>is&nbsp; initiated from inside towards =
outside.&nbsp; Do we need the midcom agent to</FONT>
<BR><FONT SIZE=3D2>be able to specify such a rule?</FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C126C7.B83B0E70--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 03:06:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20708
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 03:06:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22763;
	Fri, 17 Aug 2001 02:53:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22733
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 02:53:05 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20519
	for <midcom@ietf.org>; Fri, 17 Aug 2001 02:51:52 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7H6qZg07582
	for <midcom@ietf.org>; Fri, 17 Aug 2001 07:52:35 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 17 Aug 2001 07:52:25 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <RC36D9P0>;
          Fri, 17 Aug 2001 07:50:29 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451C0@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Jiri Kuthan'" <jiri@iptel.org>,
        "Richard Swale (E-mail)" <richard.swale@bt.com>,
        Mark Duffy <mduffy@quarrytech.com>
Cc: Bob Penfield <bpenfield@acmepacket.com>,
        "Midcom IETF (E-mail)" <midcom@ietf.org>
Subject: RE: NAT associations: query versus set (was Re: [midcom] Comments on 
         requirements draft v2
Date: Fri, 17 Aug 2001 04:21:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C126CB.BEB3B730"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C126CB.BEB3B730
Content-Type: text/plain;
	charset="iso-8859-1"

Jiri,
What we are saying is that:
In cases there are several MB separating between 2 networks, and we don't
know which one will be traversed by the flows, we might want to have same
BINDs created on all the MBs. This will be required until we have MB
discovery defined.
This will bring certain issues such as the BIND allocated on one MB might
conflict with another MB (because it is already allocated to another flow),
but there is no other alternative for now ...
Cedric



-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Thursday, August 09, 2001 3:18 PM
To: Bob Penfield; Aoun, Cedric [QPD:MA01:EXCH]; Richard Swale (E-mail);
Mark Duffy
Cc: Midcom IETF (E-mail)
Subject: NAT associations: query versus set (was Re: [midcom] Comments
on requirements draft v2


I think this discussion appeared on the mailing list looong time
ago and most folks agreed that asking for NAT translation goes
better than setting it.

If we went for "setting", agents (e.g., SIP proxies) would have
to maintain the address pool. Not only does it counter midcom's
decomposition prinicple, but it also introduces lot of tricky
issues. Particularly, things will become more complex with
multiple agents.

-Jiri

><BP>
>There are at least two cases I can think of where the agent wants to tell
>the middlebox what the binding is: 1) when establishing the NAT to allow
SIP
>signalling through the middlebox (It will likely want to make the port be
>5060); and 2) for when there are redundant peering points and the agent
>wants to same binding in both NAT middleboxes. It might "learn" the binding
>from one middlebox and "tell" the other middlebox that binding.
></BP>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C126CB.BEB3B730
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: NAT associations: query versus set (was Re: [midcom] =
Comments on  requirements draft v2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jiri,</FONT>
<BR><FONT SIZE=3D2>What we are saying is that:</FONT>
<BR><FONT SIZE=3D2>In cases there are several MB separating between 2 =
networks, and we don't know which one will be traversed by the flows, =
we might want to have same BINDs created on all the MBs. This will be =
required until we have MB discovery defined.</FONT></P>

<P><FONT SIZE=3D2>This will bring certain issues such as the BIND =
allocated on one MB might conflict with another MB (because it is =
already allocated to another flow), but there is no other alternative =
for now ...</FONT></P>

<P><FONT SIZE=3D2>Cedric</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jiri Kuthan [<A =
HREF=3D"mailto:jiri@iptel.org">mailto:jiri@iptel.org</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, August 09, 2001 3:18 PM</FONT>
<BR><FONT SIZE=3D2>To: Bob Penfield; Aoun, Cedric [QPD:MA01:EXCH]; =
Richard Swale (E-mail);</FONT>
<BR><FONT SIZE=3D2>Mark Duffy</FONT>
<BR><FONT SIZE=3D2>Cc: Midcom IETF (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: NAT associations: query versus set (was Re: =
[midcom] Comments</FONT>
<BR><FONT SIZE=3D2>on requirements draft v2</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think this discussion appeared on the mailing list =
looong time</FONT>
<BR><FONT SIZE=3D2>ago and most folks agreed that asking for NAT =
translation goes</FONT>
<BR><FONT SIZE=3D2>better than setting it.</FONT>
</P>

<P><FONT SIZE=3D2>If we went for &quot;setting&quot;, agents (e.g., SIP =
proxies) would have</FONT>
<BR><FONT SIZE=3D2>to maintain the address pool. Not only does it =
counter midcom's</FONT>
<BR><FONT SIZE=3D2>decomposition prinicple, but it also introduces lot =
of tricky</FONT>
<BR><FONT SIZE=3D2>issues. Particularly, things will become more =
complex with</FONT>
<BR><FONT SIZE=3D2>multiple agents.</FONT>
</P>

<P><FONT SIZE=3D2>-Jiri</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&lt;BP&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;There are at least two cases I can think of =
where the agent wants to tell</FONT>
<BR><FONT SIZE=3D2>&gt;the middlebox what the binding is: 1) when =
establishing the NAT to allow SIP</FONT>
<BR><FONT SIZE=3D2>&gt;signalling through the middlebox (It will likely =
want to make the port be</FONT>
<BR><FONT SIZE=3D2>&gt;5060); and 2) for when there are redundant =
peering points and the agent</FONT>
<BR><FONT SIZE=3D2>&gt;wants to same binding in both NAT middleboxes. =
It might &quot;learn&quot; the binding</FONT>
<BR><FONT SIZE=3D2>&gt;from one middlebox and &quot;tell&quot; the =
other middlebox that binding.</FONT>
<BR><FONT SIZE=3D2>&gt;&lt;/BP&gt;</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C126CB.BEB3B730--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 03:12:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20795
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 03:12:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22805;
	Fri, 17 Aug 2001 02:53:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22777
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 02:53:22 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20521
	for <midcom@ietf.org>; Fri, 17 Aug 2001 02:52:10 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7H6qrg07628
	for <midcom@ietf.org>; Fri, 17 Aug 2001 07:52:53 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 17 Aug 2001 07:52:41 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <RC36D93X>;
          Fri, 17 Aug 2001 07:50:05 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451BC@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Deleting requirements
Date: Fri, 17 Aug 2001 03:35:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C126C5.49AB7230"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C126C5.49AB7230
Content-Type: text/plain;
	charset="iso-8859-1"

Melinda,
Some comments below:

R25: Suggest that we reword to the protocol MUST have assured data transfer
capabilities ---This provides robustness to packet loss, retransmissions
etc..I prefer that we keep it, this provides independence from the chosen
transport protocol
why to take out R27?
R48:This is redundant unless we haven't a requirement somewhere, that the
protocol should have
sufficient syntax to allow a MA to request services on a stream or several
streams (stream=flow), i.e. bundles. I think we have this covered somewhere.
right?
R53  need to check if there is a  statement covering IPv4 and v6 
R54-R57 could be aggregated in one : 
Syntax need to be sufficiently flexible to allow creation of several
matching expressions that depicts certain fields of the IP header, UDP
header or TCP header, and other layer 3 protocols.
R74:This is related to resource auditing and I think it is useful.

Thanks
Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, August 15, 2001 8:43 PM
To: midcom@ietf.org
Subject: [midcom] Deleting requirements


I've received a clear "small is beautiful" message from our ADs,
and with that in mind I'd like to propose deleting the following
requirements as redundant, obvious, or unnecessary (note that some
of these have already been identified as things to be handled by
design teams, but which I think we can kill to no ill effect):

R16 (needs to be deleted or reworded)
R78
R19
R25
R27
R29
R30
R42
R48
R50 (redundant with R40)
R51 (see earlier note from Scott Bradner)
R52 (redundant with R50 and R40)
R53 (ditto - just need to state somewhere that the protocol must support
     both v4 and v6)
R54 
R55
R56
R57
R71
R74


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C126C5.49AB7230
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Deleting requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Melinda,</FONT>
<BR><FONT SIZE=3D2>Some comments below:</FONT>
</P>

<P><FONT SIZE=3D2>R25: Suggest that we reword to the protocol MUST have =
assured data transfer capabilities ---This provides robustness to =
packet loss, retransmissions etc..I prefer that we keep it, this =
provides independence from the chosen transport protocol</FONT></P>

<P><FONT SIZE=3D2>why to take out R27?</FONT>
<BR><FONT SIZE=3D2>R48:This is redundant unless we haven't a =
requirement somewhere, that the protocol should have</FONT>
<BR><FONT SIZE=3D2>sufficient syntax to allow a MA to request services =
on a stream or several streams (stream=3Dflow), i.e. bundles. I think =
we have this covered somewhere. right?</FONT></P>

<P><FONT SIZE=3D2>R53&nbsp; need to check if there is a&nbsp; statement =
covering IPv4 and v6 </FONT>
<BR><FONT SIZE=3D2>R54-R57 could be aggregated in one : </FONT>
<BR><FONT SIZE=3D2>Syntax need to be sufficiently flexible to allow =
creation of several matching expressions that depicts certain fields of =
the IP header, UDP header or TCP header, and other layer 3 =
protocols.</FONT></P>

<P><FONT SIZE=3D2>R74:This is related to resource auditing and I think =
it is useful.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 15, 2001 8:43 PM</FONT>
<BR><FONT SIZE=3D2>To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [midcom] Deleting requirements</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I've received a clear &quot;small is beautiful&quot; =
message from our ADs,</FONT>
<BR><FONT SIZE=3D2>and with that in mind I'd like to propose deleting =
the following</FONT>
<BR><FONT SIZE=3D2>requirements as redundant, obvious, or unnecessary =
(note that some</FONT>
<BR><FONT SIZE=3D2>of these have already been identified as things to =
be handled by</FONT>
<BR><FONT SIZE=3D2>design teams, but which I think we can kill to no =
ill effect):</FONT>
</P>

<P><FONT SIZE=3D2>R16 (needs to be deleted or reworded)</FONT>
<BR><FONT SIZE=3D2>R78</FONT>
<BR><FONT SIZE=3D2>R19</FONT>
<BR><FONT SIZE=3D2>R25</FONT>
<BR><FONT SIZE=3D2>R27</FONT>
<BR><FONT SIZE=3D2>R29</FONT>
<BR><FONT SIZE=3D2>R30</FONT>
<BR><FONT SIZE=3D2>R42</FONT>
<BR><FONT SIZE=3D2>R48</FONT>
<BR><FONT SIZE=3D2>R50 (redundant with R40)</FONT>
<BR><FONT SIZE=3D2>R51 (see earlier note from Scott Bradner)</FONT>
<BR><FONT SIZE=3D2>R52 (redundant with R50 and R40)</FONT>
<BR><FONT SIZE=3D2>R53 (ditto - just need to state somewhere that the =
protocol must support</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; both v4 and v6)</FONT>
<BR><FONT SIZE=3D2>R54 </FONT>
<BR><FONT SIZE=3D2>R55</FONT>
<BR><FONT SIZE=3D2>R56</FONT>
<BR><FONT SIZE=3D2>R57</FONT>
<BR><FONT SIZE=3D2>R71</FONT>
<BR><FONT SIZE=3D2>R74</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C126C5.49AB7230--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 05:54:38 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22553
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 05:54:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26891;
	Fri, 17 Aug 2001 05:52:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26866
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 05:52:21 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22522
	for <midcom@ietf.org>; Fri, 17 Aug 2001 05:51:04 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7H9pmg05622
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:51:48 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 17 Aug 2001 10:51:23 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RCF5Y0B0>; Fri, 17 Aug 2001 10:51:17 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451C1@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Scott Brim'" <sbrim@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Requirements summary: all requirements
Date: Fri, 17 Aug 2001 10:26:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C126FE.C3F86870"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C126FE.C3F86870
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry if this has already been covered ..

Scott,
I think we already discussed that, Elliot reminded us of asynchronous
messages used for notification of events (during the WG session on last
Friday).
I think that Paul raised this as well on Friday.
These asynchronous messages has to be within the protocol.
Thanks
Cedric

>    R10: A middlebox MUST be able to notify a midcom agent of the
>    following events: Session creation, Session termination, MIDCOM
>    protocol failure, Middlebox function failure or any other
>    significant event.  Independently, ICMP error codes can also be
>    useful to notify transport layer failures to the agents.
> 
>            From the framework draft, version -03.
> 
> *** I personaly do not expect such notifications to be communicated
> using midcom protocol. As such, I do not see the need for listing it
> in the requirement document.  - proposal: drop R10

Noted.  Still not discussed by the group.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C126FE.C3F86870
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Requirements summary: all requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Sorry if this has already been covered ..</FONT>
</P>

<P><FONT SIZE=3D2>Scott,</FONT>
<BR><FONT SIZE=3D2>I think we already discussed that, Elliot reminded =
us of asynchronous messages used for notification of events (during the =
WG session on last Friday).</FONT></P>

<P><FONT SIZE=3D2>I think that Paul raised this as well on =
Friday.</FONT>
<BR><FONT SIZE=3D2>These asynchronous messages has to be within the =
protocol.</FONT>
<BR><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; R10: A middlebox MUST be able =
to notify a midcom agent of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; following events: Session =
creation, Session termination, MIDCOM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; protocol failure, Middlebox =
function failure or any other</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; significant event.&nbsp; =
Independently, ICMP error codes can also be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; useful to notify transport =
layer failures to the agents.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; From the framework draft, version -03.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; *** I personaly do not expect such =
notifications to be communicated</FONT>
<BR><FONT SIZE=3D2>&gt; using midcom protocol. As such, I do not see =
the need for listing it</FONT>
<BR><FONT SIZE=3D2>&gt; in the requirement document.&nbsp; - proposal: =
drop R10</FONT>
</P>

<P><FONT SIZE=3D2>Noted.&nbsp; Still not discussed by the group.</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C126FE.C3F86870--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 05:54:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22567
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 05:54:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26822;
	Fri, 17 Aug 2001 05:51:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26785
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 05:51:52 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22515
	for <midcom@ietf.org>; Fri, 17 Aug 2001 05:50:36 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7H9pKg05360
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:51:20 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 17 Aug 2001 10:50:57 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RCF5Y0A9>; Fri, 17 Aug 2001 10:50:54 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451C2@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Scott Brim'" <sbrim@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Interim rev. of the famework draft
Date: Fri, 17 Aug 2001 10:29:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C126FF.2C63F9B0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C126FF.2C63F9B0
Content-Type: text/plain;
	charset="iso-8859-1"

Scott, 
I agree with you that there are some states maintained on the agents.
The agents have already flow related states, it's a sort of call-ID and
connection IDs related to the call (dependent on what application we are
talking about). The bundle is related to the the call ID or something
similar.
Once the call or the application session (hope this will not bring some
confusion :-)) ended, the agent will request to take out the bundle related
to the application session or call.
Cedric

-----Original Message-----
From: Scott Brim [mailto:sbrim@cisco.com]
Sent: Monday, August 13, 2001 1:51 PM
To: midcom@ietf.org
Subject: Re: [midcom] Interim rev. of the famework draft


On Thu, Aug 09, 2001 at 07:27:46PM -0400, Bob Penfield apparently wrote:
> > > I disagree. It does not have to be mandatory, but it would be nice to
> > > associate all the RTP streams of a SIP session together and be able to
> do
> > > things like extend the timer or delete them with a single
> handle/identifer.
> >
> > I agree with the bundling idea (indeed, I consider it a
> > requirement). What I want to avoid is some CREATE_SESSION method
> > which doesn't do anything except create an empty box to put things
> > in. My preferred approach is to permit the Agents to supply a cookie
> > with meaningful transactions, and then to apply certain operations
> > to 'all the stuff with <this> cookie'
> 
> I think I agree with that. I would want to say to the middlebox "create
this
> ruleset/pin-hole/whatever, oh and by the way, please give me an id for
that,
> and please associate it with bundle X". The bundle should not require a
> separate command/request. Also, I would like to say to the middlebox
"create
> this ruleset, give me an id for it, and give me a new bundle id associated
> with it that I can use to tell you what other rulesets are a part of this
> bundle".

This is the where-to-put-state issue again.  It's convenient for the
agent but not for the middlebox.  In the case of a SIP agent, doesn't
the agent have to retain some state information about all the rtp
streams it has arranged for?  The middlebox has no reason to know what's
bundled, except to purportedly offload the agent, and it can't offload
the agent completely.  This looks like an almost perfect example of the
end-to-end argument
<http://web.mit.edu/Saltzer/www/publications/endtoend/>.  If you believe
that you won't put this state into the middlebox.  (On the other hand,
if Christian is right you're going to want lots of state in the
middlebox and very little in the agent anyway.)

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C126FF.2C63F9B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Interim rev. of the famework draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Scott, </FONT>
<BR><FONT SIZE=3D2>I agree with you that there are some states =
maintained on the agents.</FONT>
<BR><FONT SIZE=3D2>The agents have already flow related states, it's a =
sort of call-ID and connection IDs related to the call (dependent on =
what application we are talking about). The bundle is related to the =
the call ID or something similar.</FONT></P>

<P><FONT SIZE=3D2>Once the call or the application session (hope this =
will not bring some confusion :-)) ended, the agent will request to =
take out the bundle related to the application session or =
call.</FONT></P>

<P><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Scott Brim [<A =
HREF=3D"mailto:sbrim@cisco.com">mailto:sbrim@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 13, 2001 1:51 PM</FONT>
<BR><FONT SIZE=3D2>To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [midcom] Interim rev. of the famework =
draft</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Thu, Aug 09, 2001 at 07:27:46PM -0400, Bob =
Penfield apparently wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I disagree. It does not have to be =
mandatory, but it would be nice to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; associate all the RTP streams of a =
SIP session together and be able to</FONT>
<BR><FONT SIZE=3D2>&gt; do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; things like extend the timer or =
delete them with a single</FONT>
<BR><FONT SIZE=3D2>&gt; handle/identifer.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree with the bundling idea (indeed, I =
consider it a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirement). What I want to avoid is some =
CREATE_SESSION method</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; which doesn't do anything except create an =
empty box to put things</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in. My preferred approach is to permit the =
Agents to supply a cookie</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with meaningful transactions, and then to =
apply certain operations</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to 'all the stuff with &lt;this&gt; =
cookie'</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think I agree with that. I would want to say =
to the middlebox &quot;create this</FONT>
<BR><FONT SIZE=3D2>&gt; ruleset/pin-hole/whatever, oh and by the way, =
please give me an id for that,</FONT>
<BR><FONT SIZE=3D2>&gt; and please associate it with bundle X&quot;. =
The bundle should not require a</FONT>
<BR><FONT SIZE=3D2>&gt; separate command/request. Also, I would like to =
say to the middlebox &quot;create</FONT>
<BR><FONT SIZE=3D2>&gt; this ruleset, give me an id for it, and give me =
a new bundle id associated</FONT>
<BR><FONT SIZE=3D2>&gt; with it that I can use to tell you what other =
rulesets are a part of this</FONT>
<BR><FONT SIZE=3D2>&gt; bundle&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>This is the where-to-put-state issue again.&nbsp; =
It's convenient for the</FONT>
<BR><FONT SIZE=3D2>agent but not for the middlebox.&nbsp; In the case =
of a SIP agent, doesn't</FONT>
<BR><FONT SIZE=3D2>the agent have to retain some state information =
about all the rtp</FONT>
<BR><FONT SIZE=3D2>streams it has arranged for?&nbsp; The middlebox has =
no reason to know what's</FONT>
<BR><FONT SIZE=3D2>bundled, except to purportedly offload the agent, =
and it can't offload</FONT>
<BR><FONT SIZE=3D2>the agent completely.&nbsp; This looks like an =
almost perfect example of the</FONT>
<BR><FONT SIZE=3D2>end-to-end argument</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"http://web.mit.edu/Saltzer/www/publications/endtoend/" =
TARGET=3D"_blank">http://web.mit.edu/Saltzer/www/publications/endtoend/<=
/A>&gt;.&nbsp; If you believe</FONT>
<BR><FONT SIZE=3D2>that you won't put this state into the =
middlebox.&nbsp; (On the other hand,</FONT>
<BR><FONT SIZE=3D2>if Christian is right you're going to want lots of =
state in the</FONT>
<BR><FONT SIZE=3D2>middlebox and very little in the agent =
anyway.)</FONT>
</P>

<P><FONT SIZE=3D2>..Scott</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C126FF.2C63F9B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 08:55:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27674
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 08:54:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00708;
	Fri, 17 Aug 2001 08:41:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00675
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 08:41:45 -0400 (EDT)
Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27195
	for <midcom@ietf.org>; Fri, 17 Aug 2001 08:40:30 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f4353f556d298d53@cvis21.Marconicomms.com> for <midcom@ietf.org>;
 Fri, 17 Aug 2001 13:40:59 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id NAA03180; Fri, 17 Aug 2001 13:41:11 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256AAB.0045A45B ; Fri, 17 Aug 2001 13:40:40 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Philip Mart" <Philip.Mart@marconi.com>
To: midcom@ietf.org
Message-ID: <80256AAB.0045A017.00@marconicomms.com>
Date: Fri, 17 Aug 2001 13:41:58 +0100
Subject: Re: [midcom] Deleting requirements
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



My vote on the deletion candidates.

>R16 (needs to be deleted or reworded)

OK delete.

>R78

I agree with Scott Brim, it is not obvious.

Retain

>R19

Given the tight specification desired by the AD this should be deleted.
However it should be noted in order to help specify extensibility requirements
in outline rather than by enumeration.

>R25
>R27
>R29

Taken together these three requirements permit the use of UDP with timers which
take topology into account. This permits the entities to be separated by
considerable distances. I can only agree to their deletion if consensus is
reached
that the interpretation of other requirements meets these goals. Therefore,
until
that position is reached -

Retain

>R30

Delete

>R42

Delete. On the basis that the protocol is to allow minimal description of the
pinhole this becomes obvious.


>R48

Delete. I agree to this reluctantly following our A-D's advice to use a minimal
pinhole description.

>R50 (redundant with R40)

Delete. I agree to this subject to an ability to include packet-handling
information, in addition to packet selection criteria, in the extensible
part of the protocol.

>R51 (see earlier note from Scott Bradner)

Delete. Notwithstanding the note from Scott Bradner I agree to this subject
to an ability to include packet-handling information, in addition to packet
selection criteria, in the extensible part of the protocol.

>R52 (redundant with R50 and R40)

Delete. But...
This is a requirement that allows multiple pinholes to be opened with one
operation where the range of applicable addresses is determined by reference
to an address mask and was intended as an aid to protocol efficiency.

I don't recall that being ruled out of scope.

>R53 (ditto - just need to state somewhere that the protocol must support
>     both v4 and v6)

Delete, subject to IPv4 and v6 statement.

>R54

This is a requirement that allows multiple pinholes to be opened with one
operation. It can be seen that the use of this feature, for RTP/RTCP at least,
may aid protocol efficiency.

I do not agree to the deletion of this requirement but would accept rewording.
I prefer to await other reaction rather than offer words at the moment.

>R55

Delete.

>R56

Delete, subject to Richard's agreement.

>R57

Delete, subject to Richard's agreement.

>R71

Delete.
Actually people do need this but it will have to be an extension given our
present minimalism.

>R74

I am not happy to delete this because it is needed for recovery of state
after failure and subsequent recovery of an agent or its replacement by an
authorized substitute.

Retain.
>



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 09:12:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29046
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 09:12:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01315;
	Fri, 17 Aug 2001 09:10:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01284
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 09:09:59 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28747
	for <midcom@ietf.org>; Fri, 17 Aug 2001 09:08:43 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7HD9Zn25898
	for <midcom@ietf.org>; Fri, 17 Aug 2001 06:09:35 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp167.cisco.com [10.21.64.167])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACN05670;
	Fri, 17 Aug 2001 06:09:23 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010817090740.00a54ec0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 09:10:53 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Trying to bring this to closure ...
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

We need to try to find some middle ground on this filter
rule problem.  Scott proposed that we leave it at the oft-
mentioned 5-tuple.  Would it be sufficient to say that the
midcom protocol must be able to carry filtering rules,
including but not limited to the 5-tuple, from the midcom
agent to the middlebox?  

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 09:52:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01881
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 09:52:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02261;
	Fri, 17 Aug 2001 09:49:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02233
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 09:49:11 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01635
	for <midcom@ietf.org>; Fri, 17 Aug 2001 09:47:56 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7HDmiQ20400
	for <midcom@ietf.org>; Fri, 17 Aug 2001 06:48:44 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJO06206;
	Fri, 17 Aug 2001 06:48:39 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 09:48:46 -0400
Date: Fri, 17 Aug 2001 09:48:46 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Trying to bring this to closure ...
Message-ID: <20010817094846.B1672@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <5.1.0.14.0.20010817090740.00a54ec0@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010817090740.00a54ec0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Fri, Aug 17, 2001 at 09:10:53AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Fri, Aug 17, 2001 at 09:10:53AM -0400, Melinda Shore apparently wrote:
> We need to try to find some middle ground on this filter
> rule problem.  Scott proposed that we leave it at the oft-
> mentioned 5-tuple.  Would it be sufficient to say that the
> midcom protocol must be able to carry filtering rules,
> including but not limited to the 5-tuple, from the midcom
> agent to the middlebox?  

Exact agreement.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 10:37:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03816
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 10:37:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03503;
	Fri, 17 Aug 2001 10:37:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03472
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 10:37:42 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03778
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:36:28 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0F5M; Fri, 17 Aug 2001 10:37:10 -0400
Message-Id: <3.0.5.32.20010817103618.0096fda0@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 17 Aug 2001 10:36:18 -0400
To: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] Trying to bring this to closure ...
In-Reply-To: <5.1.0.14.0.20010817090740.00a54ec0@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
>We need to try to find some middle ground on this filter
>rule problem.  Scott proposed that we leave it at the oft-
>mentioned 5-tuple.  Would it be sufficient to say that the
>midcom protocol must be able to carry filtering rules,
>including but not limited to the 5-tuple, from the midcom
>agent to the middlebox?  
>
>Melinda

I could be happy with that.
Even more so if it went on to say that the criteria filtered on must be
readily extensible.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 10:41:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03927
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 10:41:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03691;
	Fri, 17 Aug 2001 10:40:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03609
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 10:40:11 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03860
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:38:55 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7HEdon24072
	for <midcom@ietf.org>; Fri, 17 Aug 2001 07:39:50 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJO06542;
	Fri, 17 Aug 2001 07:39:36 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 10:39:42 -0400
Date: Fri, 17 Aug 2001 10:39:42 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Deleting requirements
Message-ID: <20010817103942.H1672@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <no.id>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <no.id>; from mduffy@quarrytech.com on Wed, Aug 15, 2001 at 11:56:49PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Wed, Aug 15, 2001 at 11:56:49PM -0400, Mark Duffy apparently wrote:
> R52: I don't think we should delete it.  R52 is mostly redundant with R40
> and R50 but adds the additional requirement that masks be supported.
> Perhaps we can reduce R52 to R40b: "all items in the tuple are maskable"
> and then debate that when we come to it.
> 
> I agree with Scott on 50, 56, 57:

I now believe we're in the phase where it's time to consolidate this
pile of requirements into something cohesive.  I hadn't expected to get
here so soon but we're making pretty good progress.  Therefore I suggest
that instead of just listing out all the requirements that any protocol
would have, we assume some intelligence on the part of implementors and
list what requirements are unexpected, or make this protocol special.  

With this in mind, and with the new requirement Melinda proposed: "The
midcom protocol must be able to carry filtering rules, including but not
limited to the 5-tuple, from the midcom agent to the middlebox", I now
agree with Melinda's entire list.

R52 adds masks but that doesn't change anything fundamental about the
protocol.  I think this can be argued out in a few hours in
son-of-midcom, and that we don't need a requirement at this level of
detail.  Again, let's stick to requirements that actually make a
difference.

R50, R40 are subsumed into Melinda's general requirement.  (R40 is
pretty bogus to start with in that it implies that a pinhole is uniquely
identified by a 5-tuple, which blocks extensibility.  But since we're
deleting it anyway, let's not have that discussion.)

> Besides the ones you identified for deletion, I think R11 is a duplicate of
> R40 so can be deleted.

Yup.

This is like DNA research.  We have empty, meaningless sections, and a
lot of redundancy. :-)

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 10:43:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04003
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 10:43:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03794;
	Fri, 17 Aug 2001 10:43:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03760
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 10:43:53 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03975
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:42:38 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7HEfPD15491
	for <midcom@ietf.org>; Fri, 17 Aug 2001 07:41:29 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJO06579;
	Fri, 17 Aug 2001 07:43:15 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 10:43:21 -0400
Date: Fri, 17 Aug 2001 10:43:21 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Deleting requirements
Message-ID: <20010817104321.J1672@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <85AA7486A2C1D411BCA20000F8073E430317FF50@crchy271.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430317FF50@crchy271.us.nortel.com>; from sanjoy@nortelnetworks.com on Thu, Aug 16, 2001 at 06:29:39PM -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Thu, Aug 16, 2001 at 06:29:39PM -0500, Sanjoy Sen apparently wrote:
> I would support deletion of all proposed by Melinda except R74. The reason
> is, the MA should be able to know the capabilities/resources (e.g., # of
> available NAT ports) of MB after establishing the "communications
> relationship" with the MB. This would be useful, for example, to allow a SIP
> call Server (associated with the MA) to make a decision on whether to
> admit/reject a new call.

It would be useful.  Personally I'd like to keep it but I'm willing to
let it get deleted and trust the son-of-midcom group.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 10:50:38 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04144
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 10:50:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04022;
	Fri, 17 Aug 2001 10:50:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03993
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 10:50:19 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04095
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:49:04 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7HEnmg25268
	for <midcom@ietf.org>; Fri, 17 Aug 2001 15:49:48 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 17 Aug 2001 15:49:30 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RCF5ZJWT>; Fri, 17 Aug 2001 15:49:27 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451C8@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>, Melinda Shore <mshore@cisco.com>,
        midcom@ietf.org
Subject: RE: [midcom] Trying to bring this to closure ...
Date: Fri, 17 Aug 2001 15:49:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1272B.CC09DD00"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1272B.CC09DD00
Content-Type: text/plain;
	charset="iso-8859-1"

I support the text added with Mark's suggestion
-----Original Message-----
From: Mark Duffy [mailto:mduffy@quarrytech.com]
Sent: Friday, August 17, 2001 4:36 PM
To: Melinda Shore; midcom@ietf.org
Subject: Re: [midcom] Trying to bring this to closure ...


At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
>We need to try to find some middle ground on this filter
>rule problem.  Scott proposed that we leave it at the oft-
>mentioned 5-tuple.  Would it be sufficient to say that the
>midcom protocol must be able to carry filtering rules,
>including but not limited to the 5-tuple, from the midcom
>agent to the middlebox?  
>
>Melinda

I could be happy with that.
Even more so if it went on to say that the criteria filtered on must be
readily extensible.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C1272B.CC09DD00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Trying to bring this to closure ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I support the text added with Mark's =
suggestion</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, August 17, 2001 4:36 PM</FONT>
<BR><FONT SIZE=3D2>To: Melinda Shore; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [midcom] Trying to bring this to =
closure ...</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 09:10 AM 8/17/01 -0400, Melinda Shore =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;We need to try to find some middle ground on =
this filter</FONT>
<BR><FONT SIZE=3D2>&gt;rule problem.&nbsp; Scott proposed that we leave =
it at the oft-</FONT>
<BR><FONT SIZE=3D2>&gt;mentioned 5-tuple.&nbsp; Would it be sufficient =
to say that the</FONT>
<BR><FONT SIZE=3D2>&gt;midcom protocol must be able to carry filtering =
rules,</FONT>
<BR><FONT SIZE=3D2>&gt;including but not limited to the 5-tuple, from =
the midcom</FONT>
<BR><FONT SIZE=3D2>&gt;agent to the middlebox?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Melinda</FONT>
</P>

<P><FONT SIZE=3D2>I could be happy with that.</FONT>
<BR><FONT SIZE=3D2>Even more so if it went on to say that the criteria =
filtered on must be</FONT>
<BR><FONT SIZE=3D2>readily extensible.</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1272B.CC09DD00--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:04:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04544
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:04:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04545;
	Fri, 17 Aug 2001 11:02:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04519
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:01:58 -0400 (EDT)
Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04434
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:00:43 -0400 (EDT)
Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103])
	by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA18220;
	Fri, 17 Aug 2001 16:01:26 +0100
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44])
	by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA49082;
	Fri, 17 Aug 2001 16:01:26 +0100
Message-ID: <3B7D31E8.F33AC14A@hursley.ibm.com>
Date: Fri, 17 Aug 2001 10:02:00 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Mark Duffy <mduffy@quarrytech.com>
CC: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] Trying to bring this to closure ...
References: <3.0.5.32.20010817103618.0096fda0@email.quarrytech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

What he said

   Brian

Mark Duffy wrote:
> 
> At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
> >We need to try to find some middle ground on this filter
> >rule problem.  Scott proposed that we leave it at the oft-
> >mentioned 5-tuple.  Would it be sufficient to say that the
> >midcom protocol must be able to carry filtering rules,
> >including but not limited to the 5-tuple, from the midcom
> >agent to the middlebox?
> >
> >Melinda
> 
> I could be happy with that.
> Even more so if it went on to say that the criteria filtered on must be
> readily extensible.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:05:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04563
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:05:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04668;
	Fri, 17 Aug 2001 11:03:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04639
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:03:51 -0400 (EDT)
Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04488
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:02:36 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T01010101cf556dabd7e1@cvis29.marconicomms.com>;
 Fri, 17 Aug 2001 16:03:18 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id QAA00995; Fri, 17 Aug 2001 16:03:18 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256AAB.0052A686 ; Fri, 17 Aug 2001 16:02:45 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Philip Mart" <Philip.Mart@marconi.com>
To: Mark Duffy <mduffy@quarrytech.com>
cc: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Message-ID: <80256AAB.0052A386.00@marconicomms.com>
Date: Fri, 17 Aug 2001 16:04:12 +0100
Subject: Re: [midcom] Trying to bring this to closure ...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org






Mark,

I suggest that we treat the addition of filters as an extension to the basic
5-tuple. That way we won't have to fight the IESG on the point and the principle
of Midcom gets establish with a way forward for the group that will follow it.
Including the filter directly takes us straight to arguing what the filter items
may or may not be and we have seen what happens there at the London meeting.

Let's go for the basic 5-tuple now but build in the extension method knowing
that it should work when carrying filtering rules etc as well as a base 5-tuple.

Phil



                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:       Melinda Shore <mshore@cisco.com>, midcom@ietf.org  
                                                              
 cc:       (bcc: Philip Mart/MAIN/MC1)                        
                                                              
                                                              
                                                              
 Subject:  Re: [midcom] Trying to bring this to closure ...   
                                                              







At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
>We need to try to find some middle ground on this filter
>rule problem.  Scott proposed that we leave it at the oft-
>mentioned 5-tuple.  Would it be sufficient to say that the
>midcom protocol must be able to carry filtering rules,
>including but not limited to the 5-tuple, from the midcom
>agent to the middlebox?
>
>Melinda

I could be happy with that.
Even more so if it went on to say that the criteria filtered on must be
readily extensible.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:07:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04629
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:07:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04624;
	Fri, 17 Aug 2001 11:03:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04592
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:03:30 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04479
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:02:15 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0F8F; Fri, 17 Aug 2001 11:02:58 -0400
Message-Id: <3.0.5.32.20010817110215.00988c50@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 17 Aug 2001 11:02:15 -0400
To: midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] precedence of rules?
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I hope I'm not adding fuel to a fire we are trying to extinguish but...  I
don't recall any discussion about precedence of rules installed into the
middlebox.

Assuming that rules may be specified whose packet-matching criteria contain
masks/wildcards/don't-cares in any of their fields, then it becomes
possible for more than one (possibly conflicting) rule to match any given
packet.  Moreover, there is no meaningful way to impose a canonical
ordering on such rules.  IMHO, having the middlebox order the rules however
it pleases is unacceptable.

To me this suggests that the agent must be able to specify a precedence for
each rule it installs.  But this gets sticky when there are multiple agents
directing the same mb.  

Any thoughts?

--Mark


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:08:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04656
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:08:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05026;
	Fri, 17 Aug 2001 11:08:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04997
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:08:42 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04626
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:07:27 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7HF6ID01119
	for <midcom@ietf.org>; Fri, 17 Aug 2001 08:06:19 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJO06844;
	Fri, 17 Aug 2001 08:08:08 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 11:08:14 -0400
Date: Fri, 17 Aug 2001 11:08:14 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] precedence of rules?
Message-ID: <20010817110814.L1672@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <3.0.5.32.20010817110215.00988c50@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.5.32.20010817110215.00988c50@email.quarrytech.com>; from mduffy@quarrytech.com on Fri, Aug 17, 2001 at 11:02:15AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Fri, Aug 17, 2001 at 11:02:15AM -0400, Mark Duffy apparently wrote:
> I hope I'm not adding fuel to a fire we are trying to extinguish but...  I
> don't recall any discussion about precedence of rules installed into the
> middlebox.
> 
> Assuming that rules may be specified whose packet-matching criteria contain
> masks/wildcards/don't-cares in any of their fields, then it becomes
> possible for more than one (possibly conflicting) rule to match any given
> packet.  Moreover, there is no meaningful way to impose a canonical
> ordering on such rules.  IMHO, having the middlebox order the rules however
> it pleases is unacceptable.
> 
> To me this suggests that the agent must be able to specify a precedence for
> each rule it installs.  But this gets sticky when there are multiple agents
> directing the same mb.  

Yes, but let's not go there this week :-).  Adding precedence to the
syntax will be an easy add-on if and when we or the next WG decide to do
it.  

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:12:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04737
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:12:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05192;
	Fri, 17 Aug 2001 11:11:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05164
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:11:28 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04692
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:10:11 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7HFAxQ22782;
	Fri, 17 Aug 2001 08:10:59 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp167.cisco.com [10.21.64.167])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACQ00665;
	Fri, 17 Aug 2001 08:10:52 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010817110650.00a555c0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 11:12:19 -0400
To: Mark Duffy <mduffy@quarrytech.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] precedence of rules?
In-Reply-To: <3.0.5.32.20010817110215.00988c50@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:02 AM 8/17/01 -0400, Mark Duffy wrote:
>Any thoughts?

I'd really like to keep us moving forward, and one thing that 
would help is if when you want to see something added, you 
propose actual text.  I continue to be somewhat concerned that
we're designing a camel, either way.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:23:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05038
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:23:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05574;
	Fri, 17 Aug 2001 11:18:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05537
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:18:51 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04868
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:17:36 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA28178
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:18:18 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Fri, 17 Aug 2001 08:10:17 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5XV855L>; Fri, 17 Aug 2001 08:17:40 -0700
Message-ID: <A7895B732354D311A4770008C791841A013F48BC@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Mark Duffy'" <mduffy@quarrytech.com>,
        "'Melinda Shore'" <mshore@cisco.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Trying to bring this to closure ...
Date: Fri, 17 Aug 2001 08:17:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1272F.C0359DD0"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1272F.C0359DD0
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with this statement.

"That the midcom protocol MUST be able to carry filtering rules,including
but not limited to the 5-tuple, from the midcom agent to the middlebox". 

thanks,

Reinaldo

> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]
> Sent: Friday, August 17, 2001 7:36 AM
> To: Melinda Shore; midcom@ietf.org
> Subject: Re: [midcom] Trying to bring this to closure ...
> 
> 
> At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
> >We need to try to find some middle ground on this filter
> >rule problem.  Scott proposed that we leave it at the oft-
> >mentioned 5-tuple.  Would it be sufficient to say that the
> >midcom protocol must be able to carry filtering rules,
> >including but not limited to the 5-tuple, from the midcom
> >agent to the middlebox?  
> >
> >Melinda
> 
> I could be happy with that.
> Even more so if it went on to say that the criteria filtered 
> on must be
> readily extensible.
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C1272F.C0359DD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Trying to bring this to closure ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with this statement.</FONT>
</P>

<P><FONT SIZE=3D2>&quot;That the midcom protocol MUST be able to carry =
filtering rules,including but not limited to the 5-tuple, from the =
midcom agent to the middlebox&quot;. </FONT></P>

<P><FONT SIZE=3D2>thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Mark Duffy [<A =
HREF=3D"mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, August 17, 2001 7:36 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Melinda Shore; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] Trying to bring this to =
closure ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 09:10 AM 8/17/01 -0400, Melinda Shore =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;We need to try to find some middle ground =
on this filter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;rule problem.&nbsp; Scott proposed that we =
leave it at the oft-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;mentioned 5-tuple.&nbsp; Would it be =
sufficient to say that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;midcom protocol must be able to carry =
filtering rules,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;including but not limited to the 5-tuple, =
from the midcom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;agent to the middlebox?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I could be happy with that.</FONT>
<BR><FONT SIZE=3D2>&gt; Even more so if it went on to say that the =
criteria filtered </FONT>
<BR><FONT SIZE=3D2>&gt; on must be</FONT>
<BR><FONT SIZE=3D2>&gt; readily extensible.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1272F.C0359DD0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:25:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05094
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:25:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05792;
	Fri, 17 Aug 2001 11:25:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05764
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:25:05 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05039
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:23:49 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7HFOEJ09514;
	Fri, 17 Aug 2001 10:24:14 -0500
Reply-To: <ramd@netrake.com>
From: "Ram Dantu" <ramd@netrake.com>
To: "'Melinda Shore'" <mshore@cisco.com>,
        "'Mark Duffy'" <mduffy@quarrytech.com>, <midcom@ietf.org>
Subject: RE: [midcom] precedence of rules?
Date: Fri, 17 Aug 2001 10:24:12 -0500
Message-ID: <7E06D3212981524CA10D2A114937C41406F684@NREXCH.netrake.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0002_01C12706.C3604D80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.1.0.14.0.20010817110650.00a555c0@mira-sjc5-4.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0002_01C12706.C3604D80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I think Melinda's wording does cover extensibility
but to be more explicit, I would suggest the following

The midcom protocol must be able to carry filtering rules,
like 5-tuple and to be extensible, from the midcom
agent to the middlebox.  

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Melinda Shore
Sent: Friday, August 17, 2001 10:12 AM
To: Mark Duffy; midcom@ietf.org
Subject: Re: [midcom] precedence of rules?


At 11:02 AM 8/17/01 -0400, Mark Duffy wrote:
>Any thoughts?

I'd really like to keep us moving forward, and one thing that 
would help is if when you want to see something added, you 
propose actual text.  I continue to be somewhat concerned that
we're designing a camel, either way.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------=_NextPart_000_0002_01C12706.C3604D80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [midcom] precedence of rules?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I think Melinda's wording does cover =
extensibility</FONT>

<BR><FONT SIZE=3D2>but to be more explicit, I would suggest the =
following</FONT>
</P>

<P><FONT SIZE=3D2>The midcom protocol must be able to carry filtering =
rules,</FONT>

<BR><FONT SIZE=3D2>like 5-tuple and to be extensible, from the =
midcom</FONT>

<BR><FONT SIZE=3D2>agent to the middlebox.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: midcom-admin@ietf.org [<A =
HREF=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>]On=
 Behalf Of</FONT>

<BR><FONT SIZE=3D2>Melinda Shore</FONT>

<BR><FONT SIZE=3D2>Sent: Friday, August 17, 2001 10:12 AM</FONT>

<BR><FONT SIZE=3D2>To: Mark Duffy; midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>Subject: Re: [midcom] precedence of rules?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 11:02 AM 8/17/01 -0400, Mark Duffy wrote:</FONT>

<BR><FONT SIZE=3D2>&gt;Any thoughts?</FONT>
</P>

<P><FONT SIZE=3D2>I'd really like to keep us moving forward, and one =
thing that </FONT>

<BR><FONT SIZE=3D2>would help is if when you want to see something =
added, you </FONT>

<BR><FONT SIZE=3D2>propose actual text.&nbsp; I continue to be somewhat =
concerned that</FONT>

<BR><FONT SIZE=3D2>we're designing a camel, either way.</FONT>
</P>

<P><FONT SIZE=3D2>Melinda</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>_______________________________________________</FONT>

<BR><FONT SIZE=3D2>midcom mailing list</FONT>

<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.or=
g/mailman/listinfo/midcom</A></FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0002_01C12706.C3604D80--


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:27:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05189
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:27:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05875;
	Fri, 17 Aug 2001 11:26:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05844
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:26:35 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05110
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:25:20 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7HFQ8Q05017
	for <midcom@ietf.org>; Fri, 17 Aug 2001 08:26:09 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJO07090;
	Fri, 17 Aug 2001 08:26:02 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 11:26:06 -0400
Date: Fri, 17 Aug 2001 11:26:06 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Trying to bring this to closure ...
Message-ID: <20010817112606.M1672@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <5.1.0.14.0.20010817090740.00a54ec0@mira-sjc5-4.cisco.com> <3.0.5.32.20010817103618.0096fda0@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3.0.5.32.20010817103618.0096fda0@email.quarrytech.com>; from mduffy@quarrytech.com on Fri, Aug 17, 2001 at 10:36:18AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Fri, Aug 17, 2001 at 10:36:18AM -0400, Mark Duffy apparently wrote:
> At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
> >We need to try to find some middle ground on this filter
> >rule problem.  Scott proposed that we leave it at the oft-
> >mentioned 5-tuple.  Would it be sufficient to say that the
> >midcom protocol must be able to carry filtering rules,
> >including but not limited to the 5-tuple, from the midcom
> >agent to the middlebox?  
> >
> >Melinda
> 
> I could be happy with that.
> Even more so if it went on to say that the criteria filtered on must be
> readily extensible.

These aren't going away, and express the requirement better by
themselves than they would if bundled with the tuple (minimum
requirement):

   R2: The syntax and semantics of the Midcom Protocol MUST be
       extensible to allow the requirements of future applications to be
       adopted.

   R41: The MIDCOM Protocol MUST contain version inter-working
        capabilities to enable subsequent extensions to support
        different types of Middlebox and future requirements of
        applications not considered at this stage.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:32:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05387
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:32:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05963;
	Fri, 17 Aug 2001 11:27:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05930
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:27:38 -0400 (EDT)
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05139
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:26:23 -0400 (EDT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GI700474XL0AM@firewall.mcit.com> for midcom@ietf.org; Fri,
 17 Aug 2001 15:27:00 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GI700G01XJPB5@pmismtp03.wcomnet.com>;
 Fri, 17 Aug 2001 15:26:59 +0000 (GMT)
Received: from rccc6131 ([166.35.225.191])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GI700FDRXJF0U@pmismtp03.wcomnet.com>; Fri,
 17 Aug 2001 15:26:03 +0000 (GMT)
Date: Fri, 17 Aug 2001 10:25:58 -0500
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [midcom] Trying to bring this to closure ...
In-reply-to: <5.1.0.14.0.20010817090740.00a54ec0@mira-sjc5-4.cisco.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Reply-to: christopher.a.martin@wcom.com
Message-id: <001001c12730$eb163860$bfe123a6@rccc6131.mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I think that for the filters being requested 5-tuple should be sufficient
(as it is currently).

I also believe that the agent would be requesting a filter from the
middlebox based on application signaling (in the case of SIP and SDP).

It would not necessarily be carrying a filter rule, rather requesting a
filter be defined. In the case of SIP/RTP it may also request a precedence
be applied to the filter if the middlebox is capable of this level of packet
filtering.


> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
> Melinda Shore
> Sent: Friday, August 17, 2001 8:11 AM
> To: midcom@ietf.org
> Subject: [midcom] Trying to bring this to closure ...
>
>
> We need to try to find some middle ground on this filter
> rule problem.  Scott proposed that we leave it at the oft-
> mentioned 5-tuple.  Would it be sufficient to say that the
> midcom protocol must be able to carry filtering rules,
> including but not limited to the 5-tuple, from the midcom
> agent to the middlebox?
>
> Melinda
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:34:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05418
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:34:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06490;
	Fri, 17 Aug 2001 11:34:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06461
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:34:26 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05399
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:33:11 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7HFXuQ11650
	for <midcom@ietf.org>; Fri, 17 Aug 2001 08:33:56 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJO07182;
	Fri, 17 Aug 2001 08:33:54 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 11:34:00 -0400
Date: Fri, 17 Aug 2001 11:34:00 -0400
From: "'Scott Brim'" <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Requirements summary: all requirements
Message-ID: <20010817113400.N1672@SBRIM-W2K>
Mail-Followup-To: 'Scott Brim' <sbrim@cisco.com>, midcom@ietf.org
References: <9154CB41F208D5118DD200508BE39C304451C1@zjguc006.europe.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9154CB41F208D5118DD200508BE39C304451C1@zjguc006.europe.nortel.com>; from CEDRIC.AOUN@nortelnetworks.com on Fri, Aug 17, 2001 at 10:26:59AM +0100
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Jiri's point is that many such communication requirements *might* be
handled using existing techniques, outside of any new midcom protocol
machinery.  For example, associations could be set up by any
authentication/authorization mechanism, and you wouldn't actually have
to have, e.g., key exchange, in the midcom protocol.  You would just
have to say that such a mechanism has to exist.  "Session" messages of
any sort would not be in the midcom protocol.  Second, if the midcom
protocol "fails", how are you going to use the midcom protocol to signal
that it has?  Finally, the requirement itself suggests using ICMP in
some way as an alternative -- strange if there's an actual requirement.

I haven't put much thought into this.  In any case the requirement as
phrased is vague.  I think it's still open.  Let's wait and deal with it
when Melinda calls for discussion.

..Scott

On Fri, Aug 17, 2001 at 10:26:59AM +0100, Cedric Aoun apparently wrote:
> Sorry if this has already been covered ..
> 
> Scott,
> I think we already discussed that, Elliot reminded us of asynchronous
> messages used for notification of events (during the WG session on last
> Friday).
> I think that Paul raised this as well on Friday.
> These asynchronous messages has to be within the protocol.
> Thanks
> Cedric
> 
> >    R10: A middlebox MUST be able to notify a midcom agent of the
> >    following events: Session creation, Session termination, MIDCOM
> >    protocol failure, Middlebox function failure or any other
> >    significant event.  Independently, ICMP error codes can also be
> >    useful to notify transport layer failures to the agents.
> > 
> >            From the framework draft, version -03.
> > 
> > *** I personaly do not expect such notifications to be communicated
> > using midcom protocol. As such, I do not see the need for listing it
> > in the requirement document.  - proposal: drop R10
> 
> Noted.  Still not discussed by the group.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:34:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05445
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:34:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06596;
	Fri, 17 Aug 2001 11:34:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06517
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:34:48 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05407
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:33:33 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA04990
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:34:14 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Fri, 17 Aug 2001 10:33:49 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5XV86KP>; Fri, 17 Aug 2001 08:33:13 -0700
Message-ID: <A7895B732354D311A4770008C791841A013F48CC@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'christopher.a.martin@wcom.com'" <christopher.a.martin@wcom.com>,
        "'Melinda Shore'" <mshore@cisco.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Trying to bring this to closure ...
Date: Fri, 17 Aug 2001 08:33:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12731.ECF90CB0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12731.ECF90CB0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Christopher, 

> -----Original Message-----
> From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com]
> Sent: Friday, August 17, 2001 8:26 AM
> To: 'Melinda Shore'; midcom@ietf.org
> Subject: RE: [midcom] Trying to bring this to closure ...
> 
> 
> I think that for the filters being requested 5-tuple should 
> be sufficient
> (as it is currently).

Not for me. Being a provider provisioned device 5-tuple won't cut it, so I
need the protocol to be extensible.

> 
> I also believe that the agent would be requesting a filter from the
> middlebox based on application signaling (in the case of SIP and SDP).
> 
> It would not necessarily be carrying a filter rule, rather 
> requesting a
> filter be defined. In the case of SIP/RTP it may also request 
> a precedence
> be applied to the filter if the middlebox is capable of this 
> level of packet
> filtering.
> 
> 
> > -----Original Message-----
> > From: midcom-admin@ietf.org 
> [mailto:midcom-admin@ietf.org]On Behalf Of
> > Melinda Shore
> > Sent: Friday, August 17, 2001 8:11 AM
> > To: midcom@ietf.org
> > Subject: [midcom] Trying to bring this to closure ...
> >
> >
> > We need to try to find some middle ground on this filter
> > rule problem.  Scott proposed that we leave it at the oft-
> > mentioned 5-tuple.  Would it be sufficient to say that the
> > midcom protocol must be able to carry filtering rules,
> > including but not limited to the 5-tuple, from the midcom
> > agent to the middlebox?
> >
> > Melinda
> >
> >
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www1.ietf.org/mailman/listinfo/midcom
> >
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12731.ECF90CB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Trying to bring this to closure ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello Christopher, </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Christopher A. Martin [<A =
HREF=3D"mailto:christopher.a.martin@wcom.com">mailto:christopher.a.marti=
n@wcom.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, August 17, 2001 8:26 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Melinda Shore'; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [midcom] Trying to bring this to =
closure ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that for the filters being requested =
5-tuple should </FONT>
<BR><FONT SIZE=3D2>&gt; be sufficient</FONT>
<BR><FONT SIZE=3D2>&gt; (as it is currently).</FONT>
</P>

<P><FONT SIZE=3D2>Not for me. Being a provider provisioned device =
5-tuple won't cut it, so I need the protocol to be extensible.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I also believe that the agent would be =
requesting a filter from the</FONT>
<BR><FONT SIZE=3D2>&gt; middlebox based on application signaling (in =
the case of SIP and SDP).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It would not necessarily be carrying a filter =
rule, rather </FONT>
<BR><FONT SIZE=3D2>&gt; requesting a</FONT>
<BR><FONT SIZE=3D2>&gt; filter be defined. In the case of SIP/RTP it =
may also request </FONT>
<BR><FONT SIZE=3D2>&gt; a precedence</FONT>
<BR><FONT SIZE=3D2>&gt; be applied to the filter if the middlebox is =
capable of this </FONT>
<BR><FONT SIZE=3D2>&gt; level of packet</FONT>
<BR><FONT SIZE=3D2>&gt; filtering.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: midcom-admin@ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>]O=
n Behalf Of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Melinda Shore</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Friday, August 17, 2001 8:11 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: [midcom] Trying to bring this to =
closure ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We need to try to find some middle ground =
on this filter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; rule problem.&nbsp; Scott proposed that we =
leave it at the oft-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mentioned 5-tuple.&nbsp; Would it be =
sufficient to say that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; midcom protocol must be able to carry =
filtering rules,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; including but not limited to the 5-tuple, =
from the midcom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; agent to the middlebox?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12731.ECF90CB0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:38:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05524
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:38:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06773;
	Fri, 17 Aug 2001 11:38:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06744
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:38:33 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05499
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:37:18 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA06224
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:38:02 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Fri, 17 Aug 2001 10:36:55 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5XV86MR>; Fri, 17 Aug 2001 08:36:19 -0700
Message-ID: <A7895B732354D311A4770008C791841A013F48CD@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Scott Brim'" <sbrim@cisco.com>, "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Trying to bring this to closure ...
Date: Fri, 17 Aug 2001 08:36:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12732.5A96E0D0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12732.5A96E0D0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Scott,


I think these statements are too vague and will give room to all kind of
interpretations in the future on what is, for example,  "extensible to allow
the requirements of future applications to be adopted."

We could keep yours, but I would like a specific item on the extensibility
of the filtering rules.

regards,

Reinaldo

> -----Original Message-----
> From: Scott Brim [mailto:sbrim@cisco.com]
> Sent: Friday, August 17, 2001 8:26 AM
> To: midcom@ietf.org
> Subject: Re: [midcom] Trying to bring this to closure ...
> 
> 
> On Fri, Aug 17, 2001 at 10:36:18AM -0400, Mark Duffy apparently wrote:
> > At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
> > >We need to try to find some middle ground on this filter
> > >rule problem.  Scott proposed that we leave it at the oft-
> > >mentioned 5-tuple.  Would it be sufficient to say that the
> > >midcom protocol must be able to carry filtering rules,
> > >including but not limited to the 5-tuple, from the midcom
> > >agent to the middlebox?  
> > >
> > >Melinda
> > 
> > I could be happy with that.
> > Even more so if it went on to say that the criteria 
> filtered on must be
> > readily extensible.
> 
> These aren't going away, and express the requirement better by
> themselves than they would if bundled with the tuple (minimum
> requirement):
> 
>    R2: The syntax and semantics of the Midcom Protocol MUST be
>        extensible to allow the requirements of future 
> applications to be
>        adopted.
> 
>    R41: The MIDCOM Protocol MUST contain version inter-working
>         capabilities to enable subsequent extensions to support
>         different types of Middlebox and future requirements of
>         applications not considered at this stage.
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12732.5A96E0D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Trying to bring this to closure ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello Scott,</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think these statements are too vague and will give =
room to all kind of interpretations in the future on what is, for =
example,&nbsp; &quot;extensible to allow the requirements of future =
applications to be adopted.&quot;</FONT></P>

<P><FONT SIZE=3D2>We could keep yours, but I would like a specific item =
on the extensibility of the filtering rules.</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Scott Brim [<A =
HREF=3D"mailto:sbrim@cisco.com">mailto:sbrim@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, August 17, 2001 8:26 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] Trying to bring this to =
closure ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Fri, Aug 17, 2001 at 10:36:18AM -0400, Mark =
Duffy apparently wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; At 09:10 AM 8/17/01 -0400, Melinda Shore =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;We need to try to find some middle =
ground on this filter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;rule problem.&nbsp; Scott proposed =
that we leave it at the oft-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;mentioned 5-tuple.&nbsp; Would it be =
sufficient to say that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;midcom protocol must be able to carry =
filtering rules,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;including but not limited to the =
5-tuple, from the midcom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;agent to the middlebox?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I could be happy with that.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Even more so if it went on to say that the =
criteria </FONT>
<BR><FONT SIZE=3D2>&gt; filtered on must be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; readily extensible.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; These aren't going away, and express the =
requirement better by</FONT>
<BR><FONT SIZE=3D2>&gt; themselves than they would if bundled with the =
tuple (minimum</FONT>
<BR><FONT SIZE=3D2>&gt; requirement):</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; R2: The syntax and semantics =
of the Midcom Protocol MUST be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
extensible to allow the requirements of future </FONT>
<BR><FONT SIZE=3D2>&gt; applications to be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
adopted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; R41: The MIDCOM Protocol MUST =
contain version inter-working</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
capabilities to enable subsequent extensions to support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
different types of Middlebox and future requirements of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
applications not considered at this stage.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12732.5A96E0D0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:44:17 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05685
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:44:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05920;
	Fri, 17 Aug 2001 11:27:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05888
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:27:31 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05136
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:26:16 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id C0965811B
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:27:30 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA22221
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:27:30 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Fri, 17 Aug 2001 10:27:29 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: RE: [midcom] Interim rev. of the famework draft
In-Reply-To: <9154CB41F208D5118DD200508BE39C304451C2@zjguc006.europe.nortel.com>
Message-ID: <Pine.GSO.4.21.0108171024010.21793-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Fri, 17 Aug 2001, Cedric Aoun wrote:

> Scott, 
> I agree with you that there are some states maintained on the agents.
> The agents have already flow related states, it's a sort of call-ID and
> connection IDs related to the call (dependent on what application we are
> talking about). The bundle is related to the the call ID or something
> similar.
>
> Once the call or the application session (hope this will not bring some
> confusion :-)) ended, the agent will request to take out the bundle related
> to the application session or call.

	If I understand this right, it won't work at all in many cases.
If I am a SIP proxy handling an INVITE going out from my private network
to the world, I need to come up with a Public Address and a port I
can shove into the INVITE in lieu of the private one the phone put
in there.

	If I have 2 or more middleboxes, and I don't know which one to
use, I cannot simply bind in all of them and somehow resolve the multiple
addresses. I need ONE address to stick in the SDP in the INVITE, and
I need it before I send the INVITE on.

	Solving the topology problem, at least coarsely, is not
optional for Agents. They won't work unless they do.



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:45:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05730
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:45:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06841;
	Fri, 17 Aug 2001 11:40:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06814
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:40:24 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05544
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:39:08 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0GAL; Fri, 17 Aug 2001 11:39:52 -0400
Message-Id: <3.0.5.32.20010817113905.0094db10@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 17 Aug 2001 11:39:05 -0400
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] Trying to bring this to closure ...
In-Reply-To: <20010817112606.M1672@SBRIM-W2K>
References: <3.0.5.32.20010817103618.0096fda0@email.quarrytech.com>
 <5.1.0.14.0.20010817090740.00a54ec0@mira-sjc5-4.cisco.com>
 <3.0.5.32.20010817103618.0096fda0@email.quarrytech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hi Scott, 
I was well aware of R2 when I proposed the statement below, and I proposed
it anyway because it made a clear requirement that extensibilty was
required *in this specific area*  as well as just in general.  That said,
as I stated earlier I can be satisfied with what Melinda proposed (without
the additional extensibility clause).
-Mark

P.S. We've been having this discussion using the term "filtering rules".  I
am presuming that term is subject to revision according to the terminology
being selected?


At 11:26 AM 8/17/01 -0400, Scott Brim wrote:
>On Fri, Aug 17, 2001 at 10:36:18AM -0400, Mark Duffy apparently wrote:
>> At 09:10 AM 8/17/01 -0400, Melinda Shore wrote:
>> >We need to try to find some middle ground on this filter
>> >rule problem.  Scott proposed that we leave it at the oft-
>> >mentioned 5-tuple.  Would it be sufficient to say that the
>> >midcom protocol must be able to carry filtering rules,
>> >including but not limited to the 5-tuple, from the midcom
>> >agent to the middlebox?  
>> >
>> >Melinda
>> 
>> I could be happy with that.
>> Even more so if it went on to say that the criteria filtered on must be
>> readily extensible.
>
>These aren't going away, and express the requirement better by
>themselves than they would if bundled with the tuple (minimum
>requirement):
>
>   R2: The syntax and semantics of the Midcom Protocol MUST be
>       extensible to allow the requirements of future applications to be
>       adopted.
>
>   R41: The MIDCOM Protocol MUST contain version inter-working
>        capabilities to enable subsequent extensions to support
>        different types of Middlebox and future requirements of
>        applications not considered at this stage.
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:51:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06013
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:51:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07472;
	Fri, 17 Aug 2001 11:51:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07445
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:51:54 -0400 (EDT)
Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05998
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:50:38 -0400 (EDT)
Received: from MDUFFY ([10.1.3.237]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q13D0GB1; Fri, 17 Aug 2001 11:51:22 -0400
Message-Id: <3.0.5.32.20010817115014.0094dd00@email.quarrytech.com>
X-Sender: mduffy@email.quarrytech.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 17 Aug 2001 11:50:14 -0400
To: "'Scott Brim'" <sbrim@cisco.com>, midcom@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: Re: [midcom] Requirements summary: all requirements
In-Reply-To: <20010817113400.N1672@SBRIM-W2K>
References: <9154CB41F208D5118DD200508BE39C304451C1@zjguc006.europe.nortel.com>
 <9154CB41F208D5118DD200508BE39C304451C1@zjguc006.europe.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I had been assuming that when talk about the "midcom protocol", in contexts
such as "requirements for the midcom protocol", that the term encompasses
the whole solution, including any preexisting protocols that are used as
components.

For example, if the chosen solution used ipsec and ike in order to meet the
security requirements, it would still be correct to say "the midcom
protocol provides authentication of...".  No?  Your statement below seems
to evidence a different interpretation.

-Mark

At 11:34 AM 8/17/01 -0400, 'Scott Brim' wrote:
>Jiri's point is that many such communication requirements *might* be
>handled using existing techniques, outside of any new midcom protocol
>machinery.  For example, associations could be set up by any
>authentication/authorization mechanism, and you wouldn't actually have
>to have, e.g., key exchange, in the midcom protocol.  You would just
>have to say that such a mechanism has to exist.  "Session" messages of
>any sort would not be in the midcom protocol.  Second, if the midcom
>protocol "fails", how are you going to use the midcom protocol to signal
>that it has?  Finally, the requirement itself suggests using ICMP in
>some way as an alternative -- strange if there's an actual requirement.
>
>I haven't put much thought into this.  In any case the requirement as
>phrased is vague.  I think it's still open.  Let's wait and deal with it
>when Melinda calls for discussion.
>
>..Scott


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 11:57:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06252
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:57:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06974;
	Fri, 17 Aug 2001 11:43:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06949
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 11:43:11 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05607
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:41:55 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7HFgeQ18219
	for <midcom@ietf.org>; Fri, 17 Aug 2001 08:42:40 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp167.cisco.com [10.21.64.167])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACQ01422;
	Fri, 17 Aug 2001 08:42:38 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010817114253.00a3a4b0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 11:44:06 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] 5-tuple - just checking
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I thought I'd better check to make sure that we all agree on
the contents of the 5-tuple: {protocol, destination address,
source address, destination port, source port}.  Is there
anyone who thinks we're talking about something else?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 12:44:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08050
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 12:43:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09799;
	Fri, 17 Aug 2001 12:44:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09768
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 12:44:18 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08031
	for <midcom@ietf.org>; Fri, 17 Aug 2001 12:43:04 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id 7A85A8228
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:44:17 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id LAA26432
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:44:17 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Fri, 17 Aug 2001 11:44:17 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Subject: Re: [midcom] 5-tuple - just checking
In-Reply-To: <5.1.0.14.0.20010817114253.00a3a4b0@mira-sjc5-4.cisco.com>
Message-ID: <Pine.GSO.4.21.0108171142560.26144-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org



On Fri, 17 Aug 2001, Melinda Shore wrote:

> I thought I'd better check to make sure that we all agree on
> the contents of the 5-tuple: {protocol, destination address,
> source address, destination port, source port}.  Is there
> anyone who thinks we're talking about something else?

        I despise pedantry in everyone, but most especially myself.
It therefore pains me deeply to argue this microscopic piece of
terminology.

        I agree entirely except about the words "source" and
"destination." Indeed, these are fine taken literally, but then it
takes TWO 5-tuples to describe a TCP stream.

        The way I usually talk about 5-tuples is to in terms
of two endpoints designated perhaps, so we have:

        IP address A, Port A, IP Address B, Port B, Protocol

	If it turns out everyone else (or even a majority) prefer it
in terms of source and destination, that's fine if we also agree
that a 5-tuple describes a half-duplex data stream.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 12:59:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08349
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 12:59:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09980;
	Fri, 17 Aug 2001 12:57:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09953
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 12:57:34 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08296
	for <midcom@ietf.org>; Fri, 17 Aug 2001 12:56:19 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA06282
	for <midcom@ietf.org>; Fri, 17 Aug 2001 11:56:57 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 17 Aug 2001 11:50:18 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YH1HBA>; Fri, 17 Aug 2001 11:56:24 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF55@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "'Mark Duffy'" <mduffy@quarrytech.com>,
        "'Melinda Shore'" <mshore@cisco.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Trying to bring this to closure ...
Date: Fri, 17 Aug 2001 11:56:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1273D.8BA13210"
X-Orig: <sanjoy@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1273D.8BA13210
Content-Type: text/plain;
	charset="iso-8859-1"

I second Reinaldo on this.

-----Original Message-----
From: Penno, Reinaldo [SC9:T327:EXCH] 
Sent: Friday, August 17, 2001 10:18 AM
To: 'Mark Duffy'; 'Melinda Shore'; 'midcom@ietf.org'
Subject: RE: [midcom] Trying to bring this to closure ...



I agree with this statement. 

"That the midcom protocol MUST be able to carry filtering rules,including
but not limited to the 5-tuple, from the midcom agent to the middlebox". 

thanks, 

Reinaldo 

> -----Original Message----- 
> From: Mark Duffy [ mailto:mduffy@quarrytech.com
<mailto:mduffy@quarrytech.com> ] 
> Sent: Friday, August 17, 2001 7:36 AM 
> To: Melinda Shore; midcom@ietf.org 
> Subject: Re: [midcom] Trying to bring this to closure ... 
> 
> 
> At 09:10 AM 8/17/01 -0400, Melinda Shore wrote: 
> >We need to try to find some middle ground on this filter 
> >rule problem.  Scott proposed that we leave it at the oft- 
> >mentioned 5-tuple.  Would it be sufficient to say that the 
> >midcom protocol must be able to carry filtering rules, 
> >including but not limited to the 5-tuple, from the midcom 
> >agent to the middlebox?  
> > 
> >Melinda 
> 
> I could be happy with that. 
> Even more so if it went on to say that the criteria filtered 
> on must be 
> readily extensible. 
> 
> 
> _______________________________________________ 
> midcom mailing list 
> midcom@ietf.org 
> http://www1.ietf.org/mailman/listinfo/midcom
<http://www1.ietf.org/mailman/listinfo/midcom>  
> 


------_=_NextPart_001_01C1273D.8BA13210
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [midcom] Trying to bring this to closure ...</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=990215116-17082001>I 
second Reinaldo on this.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Penno, Reinaldo 
  [SC9:T327:EXCH] <BR><B>Sent:</B> Friday, August 17, 2001 10:18 
  AM<BR><B>To:</B> 'Mark Duffy'; 'Melinda Shore'; 
  'midcom@ietf.org'<BR><B>Subject:</B> RE: [midcom] Trying to bring this to 
  closure ...<BR><BR></DIV></FONT>
  <P><FONT size=2>I agree with this statement.</FONT> </P>
  <P><FONT size=2>"That the midcom protocol MUST be able to carry filtering 
  rules,including but not limited to the 5-tuple, from the midcom agent to the 
  middlebox". </FONT></P>
  <P><FONT size=2>thanks,</FONT> </P>
  <P><FONT size=2>Reinaldo</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Mark Duffy [<A 
  href="mailto:mduffy@quarrytech.com">mailto:mduffy@quarrytech.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Friday, August 17, 2001 7:36 AM</FONT> <BR><FONT 
  size=2>&gt; To: Melinda Shore; midcom@ietf.org</FONT> <BR><FONT size=2>&gt; 
  Subject: Re: [midcom] Trying to bring this to closure ...</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; At 09:10 
  AM 8/17/01 -0400, Melinda Shore wrote:</FONT> <BR><FONT size=2>&gt; &gt;We 
  need to try to find some middle ground on this filter</FONT> <BR><FONT 
  size=2>&gt; &gt;rule problem.&nbsp; Scott proposed that we leave it at the 
  oft-</FONT> <BR><FONT size=2>&gt; &gt;mentioned 5-tuple.&nbsp; Would it be 
  sufficient to say that the</FONT> <BR><FONT size=2>&gt; &gt;midcom protocol 
  must be able to carry filtering rules,</FONT> <BR><FONT size=2>&gt; 
  &gt;including but not limited to the 5-tuple, from the midcom</FONT> <BR><FONT 
  size=2>&gt; &gt;agent to the middlebox?&nbsp; </FONT><BR><FONT size=2>&gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt;Melinda</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; I could be happy with that.</FONT> <BR><FONT 
  size=2>&gt; Even more so if it went on to say that the criteria filtered 
  </FONT><BR><FONT size=2>&gt; on must be</FONT> <BR><FONT size=2>&gt; readily 
  extensible.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  midcom mailing list</FONT> <BR><FONT size=2>&gt; midcom@ietf.org</FONT> 
  <BR><FONT size=2>&gt; <A href="http://www1.ietf.org/mailman/listinfo/midcom" 
  target=_blank>http://www1.ietf.org/mailman/listinfo/midcom</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1273D.8BA13210--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 13:19:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08958
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 13:19:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10490;
	Fri, 17 Aug 2001 13:10:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10462
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 13:10:50 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08629
	for <midcom@ietf.org>; Fri, 17 Aug 2001 13:09:27 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7HGs6D10828
	for <midcom@ietf.org>; Fri, 17 Aug 2001 10:07:27 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AJO08406;
	Fri, 17 Aug 2001 09:55:05 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 12:55:10 -0400
Date: Fri, 17 Aug 2001 12:55:10 -0400
From: "'Scott Brim'" <sbrim@cisco.com>
To: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: Re: [midcom] Trying to bring this to closure ...
Message-ID: <20010817125510.O1672@SBRIM-W2K>
Mail-Followup-To: 'Scott Brim' <sbrim@cisco.com>,
	"'midcom@ietf.org'" <midcom@ietf.org>
References: <A7895B732354D311A4770008C791841A013F48CD@zsc4c014.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <A7895B732354D311A4770008C791841A013F48CD@zsc4c014.us.nortel.com>; from reinaldo_penno@nortelnetworks.com on Fri, Aug 17, 2001 at 08:36:16AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Fri, Aug 17, 2001 at 08:36:16AM -0700, Reinaldo Penno apparently wrote:
> I would like a specific item on the extensibility
> of the filtering rules.

OK with me.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 13:31:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09226
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 13:31:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10693;
	Fri, 17 Aug 2001 13:21:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10664
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 13:21:53 -0400 (EDT)
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08999
	for <midcom@ietf.org>; Fri, 17 Aug 2001 13:20:39 -0400 (EDT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-33 #47837)
 with ESMTP id <0GI800L1P2VMD2@firewall.mcit.com> for midcom@ietf.org; Fri,
 17 Aug 2001 17:21:22 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GI8001012VGIP@pmismtp03.wcomnet.com>;
 Fri, 17 Aug 2001 17:21:22 +0000 (GMT)
Received: from rccc6131 ([166.35.225.191])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GI800GP72V8FW@pmismtp03.wcomnet.com>; Fri,
 17 Aug 2001 17:21:09 +0000 (GMT)
Date: Fri, 17 Aug 2001 12:21:03 -0500
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [midcom] Trying to bring this to closure ...
In-reply-to: <A7895B732354D311A4770008C791841A013F48CC@zsc4c014.us.nortel.com>
To: "'Reinaldo Penno'" <reinaldo_penno@nortelnetworks.com>,
        "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Reply-to: christopher.a.martin@wcom.com
Message-id: <002901c12740$feb2b780$bfe123a6@rccc6131.mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_jPQPi3AotkJSDQwutAZlNw)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

--Boundary_(ID_jPQPi3AotkJSDQwutAZlNw)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

RE: [midcom] Trying to bring this to closure ...I would need some
clarification on extensible here...
  -----Original Message-----
  From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Reinaldo Penno
  Sent: Friday, August 17, 2001 10:33 AM
  To: 'christopher.a.martin@wcom.com'; 'Melinda Shore'; 'midcom@ietf.org'
  Subject: RE: [midcom] Trying to bring this to closure ...


  Hello Christopher,

  > -----Original Message-----
  > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com]
  > Sent: Friday, August 17, 2001 8:26 AM
  > To: 'Melinda Shore'; midcom@ietf.org
  > Subject: RE: [midcom] Trying to bring this to closure ...
  >
  >
  > I think that for the filters being requested 5-tuple should
  > be sufficient
  > (as it is currently).

  Not for me. Being a provider provisioned device 5-tuple won't cut it, so I
need the protocol to be extensible.

  >
  > I also believe that the agent would be requesting a filter from the
  > middlebox based on application signaling (in the case of SIP and SDP).
  >
  > It would not necessarily be carrying a filter rule, rather
  > requesting a
  > filter be defined. In the case of SIP/RTP it may also request
  > a precedence
  > be applied to the filter if the middlebox is capable of this
  > level of packet
  > filtering.
  >
  >
  > > -----Original Message-----
  > > From: midcom-admin@ietf.org
  > [mailto:midcom-admin@ietf.org]On Behalf Of
  > > Melinda Shore
  > > Sent: Friday, August 17, 2001 8:11 AM
  > > To: midcom@ietf.org
  > > Subject: [midcom] Trying to bring this to closure ...
  > >
  > >
  > > We need to try to find some middle ground on this filter
  > > rule problem.  Scott proposed that we leave it at the oft-
  > > mentioned 5-tuple.  Would it be sufficient to say that the
  > > midcom protocol must be able to carry filtering rules,
  > > including but not limited to the 5-tuple, from the midcom
  > > agent to the middlebox?
  > >
  > > Melinda
  > >
  > >
  > > _______________________________________________
  > > midcom mailing list
  > > midcom@ietf.org
  > > http://www1.ietf.org/mailman/listinfo/midcom
  > >
  >
  >
  > _______________________________________________
  > midcom mailing list
  > midcom@ietf.org
  > http://www1.ietf.org/mailman/listinfo/midcom
  >


--Boundary_(ID_jPQPi3AotkJSDQwutAZlNw)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [midcom] Trying to bring this to closure ...</TITLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D380492017-17082001><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
would need some clarification on extensible here...</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
midcom-admin@ietf.org=20
  [mailto:midcom-admin@ietf.org]<B>On Behalf Of</B> Reinaldo=20
  Penno<BR><B>Sent:</B> Friday, August 17, 2001 10:33 AM<BR><B>To:</B>=20
  'christopher.a.martin@wcom.com'; 'Melinda Shore';=20
  'midcom@ietf.org'<BR><B>Subject:</B> RE: [midcom] Trying to bring this =
to=20
  closure ...<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Hello Christopher, </FONT></P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Christopher A. Martin [<A=20
  =
href=3D"mailto:christopher.a.martin@wcom.com">mailto:christopher.a.martin=
@wcom.com</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Friday, August 17, 2001 8:26 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: 'Melinda Shore'; midcom@ietf.org</FONT> <BR><FONT =
size=3D2>&gt;=20
  Subject: RE: [midcom] Trying to bring this to closure ...</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; I think=20
  that for the filters being requested 5-tuple should </FONT><BR><FONT=20
  size=3D2>&gt; be sufficient</FONT> <BR><FONT size=3D2>&gt; (as it is=20
  currently).</FONT> </P>
  <P><FONT size=3D2>Not for me. Being a provider provisioned device =
5-tuple won't=20
  cut it, so I need the protocol to be extensible.</FONT> </P>
  <P><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I also believe =
that the=20
  agent would be requesting a filter from the</FONT> <BR><FONT =
size=3D2>&gt;=20
  middlebox based on application signaling (in the case of SIP and =
SDP).</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; It would not =
necessarily be=20
  carrying a filter rule, rather </FONT><BR><FONT size=3D2>&gt; =
requesting=20
  a</FONT> <BR><FONT size=3D2>&gt; filter be defined. In the case of =
SIP/RTP it=20
  may also request </FONT><BR><FONT size=3D2>&gt; a precedence</FONT> =
<BR><FONT=20
  size=3D2>&gt; be applied to the filter if the middlebox is capable of =
this=20
  </FONT><BR><FONT size=3D2>&gt; level of packet</FONT> <BR><FONT =
size=3D2>&gt;=20
  filtering.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; -----Original Message-----</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; From: midcom-admin@ietf.org </FONT><BR><FONT =
size=3D2>&gt; [<A=20
  =
href=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>]On=
 Behalf=20
  Of</FONT> <BR><FONT size=3D2>&gt; &gt; Melinda Shore</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; Sent: Friday, August 17, 2001 8:11 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; To: midcom@ietf.org</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  Subject: [midcom] Trying to bring this to closure ...</FONT> <BR><FONT =

  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; We need to try to find some middle ground on this=20
  filter</FONT> <BR><FONT size=3D2>&gt; &gt; rule problem.&nbsp; Scott =
proposed=20
  that we leave it at the oft-</FONT> <BR><FONT size=3D2>&gt; &gt; =
mentioned=20
  5-tuple.&nbsp; Would it be sufficient to say that the</FONT> <BR><FONT =

  size=3D2>&gt; &gt; midcom protocol must be able to carry filtering =
rules,</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; including but not limited to the 5-tuple, =
from the=20
  midcom</FONT> <BR><FONT size=3D2>&gt; &gt; agent to the =
middlebox?</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
Melinda</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; =
_______________________________________________</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; midcom mailing list</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; midcom@ietf.org</FONT> <BR><FONT size=3D2>&gt; &gt; <A =
target=3D_blank=20
  =
href=3D"http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.or=
g/mailman/listinfo/midcom</A></FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  midcom mailing list</FONT> <BR><FONT size=3D2>&gt; =
midcom@ietf.org</FONT>=20
  <BR><FONT size=3D2>&gt; <A target=3D_blank=20
  =
href=3D"http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.or=
g/mailman/listinfo/midcom</A></FONT>=20
  <BR><FONT size=3D2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_jPQPi3AotkJSDQwutAZlNw)--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 13:34:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09305
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 13:34:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10646;
	Fri, 17 Aug 2001 13:21:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10615
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 13:21:05 -0400 (EDT)
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08955
	for <midcom@ietf.org>; Fri, 17 Aug 2001 13:19:51 -0400 (EDT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GI800G3Q2U99Y@firewall.mcit.com> for midcom@ietf.org; Fri,
 17 Aug 2001 17:20:33 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GI8001012U97P@pmismtp03.wcomnet.com>;
 Fri, 17 Aug 2001 17:20:33 +0000 (GMT)
Received: from rccc6131 ([166.35.225.191])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GI800LLA2TT9K@pmismtp03.wcomnet.com>; Fri,
 17 Aug 2001 17:20:18 +0000 (GMT)
Date: Fri, 17 Aug 2001 12:20:12 -0500
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [midcom] 5-tuple - just checking
In-reply-to: <Pine.GSO.4.21.0108171142560.26144-100000@isis.visi.com>
To: "'Andrew Molitor'" <amolitor@visi.com>, midcom@ietf.org
Reply-to: christopher.a.martin@wcom.com
Message-id: <002801c12740$e06218c0$bfe123a6@rccc6131.mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I agree with your comment fully src_ip src_port dest_ip dest_port protocol.
Also on another note, I would assume precedence and other "extensions" be
taken care of by local policy at the middlebox.

> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
> Andrew Molitor
> Sent: Friday, August 17, 2001 11:44 AM
> To: midcom@ietf.org
> Subject: Re: [midcom] 5-tuple - just checking
>
>
>
>
> On Fri, 17 Aug 2001, Melinda Shore wrote:
>
> > I thought I'd better check to make sure that we all agree on
> > the contents of the 5-tuple: {protocol, destination address,
> > source address, destination port, source port}.  Is there
> > anyone who thinks we're talking about something else?
>
>         I despise pedantry in everyone, but most especially myself.
> It therefore pains me deeply to argue this microscopic piece of
> terminology.
>
>         I agree entirely except about the words "source" and
> "destination." Indeed, these are fine taken literally, but then it
> takes TWO 5-tuples to describe a TCP stream.
>
>         The way I usually talk about 5-tuples is to in terms
> of two endpoints designated perhaps, so we have:
>
>         IP address A, Port A, IP Address B, Port B, Protocol
>
> 	If it turns out everyone else (or even a majority) prefer it
> in terms of source and destination, that's fine if we also agree
> that a 5-tuple describes a half-duplex data stream.
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 13:45:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09699
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 13:45:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11158;
	Fri, 17 Aug 2001 13:42:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11129
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 13:42:08 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09493
	for <midcom@ietf.org>; Fri, 17 Aug 2001 13:40:53 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7HHfjn21464;
	Fri, 17 Aug 2001 10:41:45 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp167.cisco.com [10.21.64.167])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACQ05885;
	Fri, 17 Aug 2001 10:41:29 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010817133747.009ffbc0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 13:42:54 -0400
To: christopher.a.martin@wcom.com, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Trying to bring this to closure ...
In-Reply-To: <002901c12740$feb2b780$bfe123a6@rccc6131.mcit.com>
References: <A7895B732354D311A4770008C791841A013F48CC@zsc4c014.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 12:21 PM 8/17/01 -0500, Christopher A. Martin wrote:
>I would need some clarification on extensible here...

Let's not.  I don't think that "extensible" is particularly
ambiguous in this context, and if we're spinning our wheels on
this one it can't possibly bode well for finishing up the rest
of the document.  

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 13:45:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09710
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 13:45:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11217;
	Fri, 17 Aug 2001 13:43:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11188
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 13:43:10 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09532
	for <midcom@ietf.org>; Fri, 17 Aug 2001 13:41:55 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7HHgYQ02460;
	Fri, 17 Aug 2001 10:42:35 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7HHgRC18261;
	Fri, 17 Aug 2001 10:42:28 -0700 (PDT)
Message-ID: <3B7D50DB.D05FB104@cisco.com>
Date: Fri, 17 Aug 2001 10:14:03 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Molitor <amolitor@visi.com>
CC: midcom@ietf.org, march@external.cisco.com
Subject: Re: [midcom] Interim rev. of the famework draft
References: <Pine.GSO.4.21.0108171024010.21793-100000@isis.visi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

First,

We are now smack in the territory of discovery.  I think it would be
useful for you to read my discovery requirements draft.  However, I now
understand that Jonathan Rosenberg has a proposal that sounds interesting,
involving something that would reflect the publicly viewable address from
"outside" for some value of outside.  This sounds interesting, but I've
not seen it yet.  In particular I'd like to know whether it gets port
information correct.

Andrew Molitor wrote:
> 
> On Fri, 17 Aug 2001, Cedric Aoun wrote:
> 
> > Scott,
> > I agree with you that there are some states maintained on the agents.
> > The agents have already flow related states, it's a sort of call-ID and
> > connection IDs related to the call (dependent on what application we are
> > talking about). The bundle is related to the the call ID or something
> > similar.
> >
> > Once the call or the application session (hope this will not bring some
> > confusion :-)) ended, the agent will request to take out the bundle related
> > to the application session or call.
> 
>         If I understand this right, it won't work at all in many cases.
> If I am a SIP proxy handling an INVITE going out from my private network
> to the world, I need to come up with a Public Address and a port I
> can shove into the INVITE in lieu of the private one the phone put
> in there.
> 
>         If I have 2 or more middleboxes, and I don't know which one to
> use, I cannot simply bind in all of them and somehow resolve the multiple
> addresses. I need ONE address to stick in the SDP in the INVITE, and
> I need it before I send the INVITE on.
> 
>         Solving the topology problem, at least coarsely, is not
> optional for Agents. They won't work unless they do.
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

--
Eliot Lear
lear@cisco.com


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 15:50:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14087
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 15:50:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15230;
	Fri, 17 Aug 2001 15:47:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15190
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 15:47:24 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13969
	for <midcom@ietf.org>; Fri, 17 Aug 2001 15:46:08 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7HJl8T13343
	for <midcom@ietf.org>; Fri, 17 Aug 2001 12:47:09 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp167.cisco.com [10.21.64.167])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACQ11480;
	Fri, 17 Aug 2001 12:46:48 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010817154629.009fb280@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 15:48:04 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] As promised - original minutes
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

The detailed minutes by Mary Barnes and Cedric Aoun are now available
at http://www.employees.org/~shore/IETF-51-MIDCOM-WG-minutesv0.1.html.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 16:02:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14290
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 16:02:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15468;
	Fri, 17 Aug 2001 15:59:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15436
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 15:59:30 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14202
	for <midcom@ietf.org>; Fri, 17 Aug 2001 15:58:13 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7HJx9n24402
	for <midcom@ietf.org>; Fri, 17 Aug 2001 12:59:09 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-112.cisco.com [10.21.112.112])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAA02330;
	Fri, 17 Aug 2001 12:58:55 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 17 Aug 2001 15:59:01 -0400
Date: Fri, 17 Aug 2001 15:59:00 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Message-ID: <20010817155900.A1544@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] no bullets today
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I said I'd send out a new list of requirement bullets today.  Since
we're on the verge of agreeing to replace a lot of bullets with one,
I'll wait a bit. 

Perhaps we could close discussion on Melinda's big list of deletables by
the end of today?

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 16:06:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14363
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 16:06:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15970;
	Fri, 17 Aug 2001 16:06:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15939
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 16:06:49 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14341
	for <midcom@ietf.org>; Fri, 17 Aug 2001 16:05:33 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7HK6LQ19831;
	Fri, 17 Aug 2001 13:06:21 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp167.cisco.com [10.21.64.167])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACQ12172;
	Fri, 17 Aug 2001 13:06:15 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010817160651.00a04250@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 16:07:36 -0400
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] no bullets today
In-Reply-To: <20010817155900.A1544@SBRIM-W2K>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 03:59 PM 8/17/01 -0400, Scott Brim wrote:
>I said I'd send out a new list of requirement bullets today.  Since
>we're on the verge of agreeing to replace a lot of bullets with one,
>I'll wait a bit. 

I'm intending to determine whether or not we've got consensus on
them on Monday.  I know that a lot of people are on vacation right
now.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 17 17:45:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15692
	for <midcom-archive@odin.ietf.org>; Fri, 17 Aug 2001 17:45:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18561;
	Fri, 17 Aug 2001 17:41:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18530
	for <midcom@ns.ietf.org>; Fri, 17 Aug 2001 17:41:03 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15623
	for <midcom@ietf.org>; Fri, 17 Aug 2001 17:39:47 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA14321
	for <midcom@ietf.org>; Fri, 17 Aug 2001 16:40:27 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 17 Aug 2001 16:32:18 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YH13CD>; Fri, 17 Aug 2001 16:38:25 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF5B@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Scott Brim'" <sbrim@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Deleting requirements
Date: Fri, 17 Aug 2001 16:38:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12764.F1F73F10"
X-Orig: <sanjoy@americasm01.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12764.F1F73F10
Content-Type: text/plain;
	charset="iso-8859-1"


I still think that we need some sort of resource auditing type capabilities
(between the MA & MB) in version 1 of the protocol. Maybe we should replace
the term "discovery" with "auditing" as suggested by Cedric. 


> -----Original Message-----
> From: Scott Brim [mailto:sbrim@cisco.com]
> Sent: Friday, August 17, 2001 9:43 AM
> To: midcom@ietf.org
> Subject: Re: [midcom] Deleting requirements
> 
> 
> On Thu, Aug 16, 2001 at 06:29:39PM -0500, Sanjoy Sen apparently wrote:
> > I would support deletion of all proposed by Melinda except 
> R74. The reason
> > is, the MA should be able to know the 
> capabilities/resources (e.g., # of
> > available NAT ports) of MB after establishing the "communications
> > relationship" with the MB. This would be useful, for 
> example, to allow a SIP
> > call Server (associated with the MA) to make a decision on 
> whether to
> > admit/reject a new call.
> 
> It would be useful.  Personally I'd like to keep it but I'm willing to
> let it get deleted and trust the son-of-midcom group.
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12764.F1F73F10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Deleting requirements</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I still think that we need some sort of resource =
auditing type capabilities (between the MA &amp; MB) in version 1 of =
the protocol. Maybe we should replace the term &quot;discovery&quot; =
with &quot;auditing&quot; as suggested by Cedric. </FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Scott Brim [<A =
HREF=3D"mailto:sbrim@cisco.com">mailto:sbrim@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, August 17, 2001 9:43 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] Deleting =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Thu, Aug 16, 2001 at 06:29:39PM -0500, =
Sanjoy Sen apparently wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I would support deletion of all proposed =
by Melinda except </FONT>
<BR><FONT SIZE=3D2>&gt; R74. The reason</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is, the MA should be able to know the =
</FONT>
<BR><FONT SIZE=3D2>&gt; capabilities/resources (e.g., # of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; available NAT ports) of MB after =
establishing the &quot;communications</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; relationship&quot; with the MB. This would =
be useful, for </FONT>
<BR><FONT SIZE=3D2>&gt; example, to allow a SIP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; call Server (associated with the MA) to =
make a decision on </FONT>
<BR><FONT SIZE=3D2>&gt; whether to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; admit/reject a new call.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It would be useful.&nbsp; Personally I'd like =
to keep it but I'm willing to</FONT>
<BR><FONT SIZE=3D2>&gt; let it get deleted and trust the son-of-midcom =
group.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12764.F1F73F10--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 05:02:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09707
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 05:02:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21111;
	Mon, 20 Aug 2001 04:56:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21082
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 04:56:44 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09657
	for <midcom@ietf.org>; Mon, 20 Aug 2001 04:55:22 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7K8ub813362
	for <midcom@ietf.org>; Mon, 20 Aug 2001 04:56:37 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA14512; Mon, 20 Aug 2001 10:56:15 +0200 (MET DST)
Cc: midcom@ietf.org
Received: from hzsgg01.nl.lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA14508; Mon, 20 Aug 2001 10:56:14 +0200 (MET DST)
Received: from lucent.com by hzsgg01.nl.lucent.com (8.8.8+Sun/EMS-1.4.1 client sol2)
	id KAA13759; Mon, 20 Aug 2001 10:56:14 +0200 (MET DST)
Message-ID: <3B80D0EB.A6A9342@lucent.com>
Date: Mon, 20 Aug 2001 10:57:15 +0200
From: Paul Sijben <sijben@lucent.com>
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: midcom@ietf.org
Subject: Re: [midcom] Deleting requirements
References: <80256AAB.0045A017.00@marconicomms.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

The results from the Dutch jury:

R16 sure, kill

R78 this seems very sensible, yet, is it a security requirement or a
functional requirement?

R19 this is one of the functions I'd like to see in the protocol. How to
align this with the ADs directive?

R25,27,29 I agree with phil. These requirements per se may not be very
clear. But together they clearly convey an intention. I would only agree
with removing them if there is a clearer replacement.

R30 this requirement is obviously a genric requirement for all such
protocols. If we take the stance that such requirements have to go, this
indeed has to be removed.

R42, ought to be obvious as well. yet, after dropping it I surely hope
that we will not see MIDCOM versions for SIP, MIDCOM versions for H.323
and MIDCOM versions for whatever.

R48, IF we agree to delete this, where do we put the requirement that we
want to specify a pinhole description and actions on the flow (such as
header rewriting or possibly body rewriting)?

R50 agreed, remove. Yet I agree with Phil, we do need the extensibility to
add other stuff later.

R51, my intentions with the MIDCOM protocol are clear, as long as I still
can do that. I can agree to removing this one.

R52, hmm, removing this requirement may impact protocol efficiency. Why
would this need to be removed?

R53, indeed if we state that we need to support v4 & v6, I am cool with
removing it.

R54 same comment as R52.

R55, if small is beautiful this one has to go

R56, R57 Hmm, this looks like a security requirement. hearing from people
with more operational experience than I have, this one is _really_ needed!

R71  my intentions with the MIDCOM protocol are clear, as long as I still
can do that. I can agree to removing this one.

R74 I'd say this is a rather useful thing to have for auto-configuration
of the network and recovery situations. Retain

Paul
-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 10:27:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22052
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 10:27:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29204;
	Mon, 20 Aug 2001 10:26:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29175
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 10:26:00 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21977
	for <midcom@ietf.org>; Mon, 20 Aug 2001 10:24:43 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA24267;
        Mon, 20 Aug 2001 10:25:44 -0400 (EDT)
Message-Id: <200108201425.KAA24267@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: ramd@netrake.com
cc: "'Melinda Shore'" <mshore@cisco.com>,
        "'Mark Duffy'" <mduffy@quarrytech.com>, midcom@ietf.org
Subject: Re: [midcom] precedence of rules? 
In-reply-to: Your message of "Fri, 17 Aug 2001 10:24:12 CDT."
             <7E06D3212981524CA10D2A114937C41406F684@NREXCH.netrake.net> 
Date: Mon, 20 Aug 2001 10:25:44 -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I realize this will be unpopular, but I actually believe that the
midcom filtering rules should not be extensible.  The reason is
that I see midcom as a stopgap measure.  Topological filtering is
not something that should be encouraged as part of the architecture,
and the notion that midcom can or should someday be extended to solve 
this problem is IMHO fanciful.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 11:03:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23209
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 11:03:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29991;
	Mon, 20 Aug 2001 10:55:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29960
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 10:55:34 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22776
	for <midcom@ietf.org>; Mon, 20 Aug 2001 10:54:17 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7KEsjb32527;
	Mon, 20 Aug 2001 09:54:45 -0500
Reply-To: <ramd@netrake.com>
From: "Ram Dantu" <ramd@netrake.com>
To: "'Keith Moore'" <moore@cs.utk.edu>
Cc: "'Melinda Shore'" <mshore@cisco.com>,
        "'Mark Duffy'" <mduffy@quarrytech.com>, <midcom@ietf.org>
Subject: RE: [midcom] precedence of rules? 
Date: Mon, 20 Aug 2001 09:54:44 -0500
Message-ID: <7E06D3212981524CA10D2A114937C414073BF7@NREXCH.netrake.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0002_01C1295E.23E63A80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200108201425.KAA24267@astro.cs.utk.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0002_01C1295E.23E63A80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I do not understand what you mean by midcom is a stopgap measure.
Can you please explain why you think filtering rules should
NOT be extensible ?  

Midcom wg is discussing whether topology information is required 
as part of the communication between agent and middlebox. This
particular info. may be optional.

Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Keith Moore
Sent: Monday, August 20, 2001 9:26 AM
To: Ram Dantu
Cc: 'Melinda Shore'; 'Mark Duffy'; midcom@ietf.org
Subject: Re: [midcom] precedence of rules? 


I realize this will be unpopular, but I actually believe that the
midcom filtering rules should not be extensible.  The reason is
that I see midcom as a stopgap measure.  Topological filtering is
not something that should be encouraged as part of the architecture,
and the notion that midcom can or should someday be extended to solve 
this problem is IMHO fanciful.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------=_NextPart_000_0002_01C1295E.23E63A80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [midcom] precedence of rules? </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I do not understand what you mean by midcom is a =
stopgap measure.</FONT>

<BR><FONT SIZE=3D2>Can you please explain why you think filtering rules =
should</FONT>

<BR><FONT SIZE=3D2>NOT be extensible ?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Midcom wg is discussing whether topology information =
is required </FONT>

<BR><FONT SIZE=3D2>as part of the communication between agent and =
middlebox. This</FONT>

<BR><FONT SIZE=3D2>particular info. may be optional.</FONT>
</P>

<P><FONT SIZE=3D2>Ram Dantu</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: midcom-admin@ietf.org [<A =
HREF=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>]On=
 Behalf Of</FONT>

<BR><FONT SIZE=3D2>Keith Moore</FONT>

<BR><FONT SIZE=3D2>Sent: Monday, August 20, 2001 9:26 AM</FONT>

<BR><FONT SIZE=3D2>To: Ram Dantu</FONT>

<BR><FONT SIZE=3D2>Cc: 'Melinda Shore'; 'Mark Duffy'; =
midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>Subject: Re: [midcom] precedence of rules? </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I realize this will be unpopular, but I actually =
believe that the</FONT>

<BR><FONT SIZE=3D2>midcom filtering rules should not be =
extensible.&nbsp; The reason is</FONT>

<BR><FONT SIZE=3D2>that I see midcom as a stopgap measure.&nbsp; =
Topological filtering is</FONT>

<BR><FONT SIZE=3D2>not something that should be encouraged as part of =
the architecture,</FONT>

<BR><FONT SIZE=3D2>and the notion that midcom can or should someday be =
extended to solve </FONT>

<BR><FONT SIZE=3D2>this problem is IMHO fanciful.</FONT>
</P>

<P><FONT SIZE=3D2>Keith</FONT>
</P>

<P><FONT SIZE=3D2>_______________________________________________</FONT>

<BR><FONT SIZE=3D2>midcom mailing list</FONT>

<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.or=
g/mailman/listinfo/midcom</A></FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0002_01C1295E.23E63A80--


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 11:07:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23262
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 11:07:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00527;
	Mon, 20 Aug 2001 11:05:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00496
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 11:05:07 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23219
	for <midcom@ietf.org>; Mon, 20 Aug 2001 11:03:50 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7KF4bQ21555;
	Mon, 20 Aug 2001 08:04:37 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp66.cisco.com [10.21.64.66])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACV00268;
	Mon, 20 Aug 2001 08:04:35 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010820105916.00a439c0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 20 Aug 2001 11:06:06 -0400
To: <ramd@netrake.com>, "'Keith Moore'" <moore@cs.utk.edu>
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] precedence of rules? 
Cc: <midcom@ietf.org>
In-Reply-To: <7E06D3212981524CA10D2A114937C414073BF7@NREXCH.netrake.net>
References: <200108201425.KAA24267@astro.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 09:54 AM 8/20/01 -0500, Ram Dantu wrote:
>I do not understand what you mean by midcom is a stopgap measure. 
>Can you please explain why you think filtering rules should 
>NOT be extensible ?  

Hi -

I think that in general the question of the stopgapness of midcom 
probably belongs on the general ietf mailing list or in off-mailing-
list discussions with the IESG or IAB.  Let's try to limit discussion
of that issue to how it might affect protocol requirements (yes, that's
*way* too vague, but what I'm saying is that while the issue has some
relevance to the deliverables we cannot get sucked into another 
Good vs. Evil argument).

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 12:46:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26321
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 12:46:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04359;
	Mon, 20 Aug 2001 12:44:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04332
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 12:44:22 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26220
	for <midcom@ietf.org>; Mon, 20 Aug 2001 12:43:06 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA25580;
        Mon, 20 Aug 2001 12:44:11 -0400 (EDT)
Message-Id: <200108201644.MAA25580@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: ramd@netrake.com
cc: "'Keith Moore'" <moore@cs.utk.edu>, "'Melinda Shore'" <mshore@cisco.com>,
        "'Mark Duffy'" <mduffy@quarrytech.com>, midcom@ietf.org
Subject: Re: [midcom] precedence of rules? 
In-reply-to: Your message of "Mon, 20 Aug 2001 09:54:44 CDT."
             <7E06D3212981524CA10D2A114937C414073BF7@NREXCH.netrake.net> 
Date: Mon, 20 Aug 2001 12:44:10 -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

> I do not understand what you mean by midcom is a stopgap measure.
> Can you please explain why you think filtering rules should
> NOT be extensible ? 

Because firewalls in general are a stopgap measure.  Security boundaries 
do not naturally follow network topology, particularly in a world where 
wireless access is common.  It doesn't scale to expect the network 
(and I include middleboxes in the network) to be aware of applications, 
nor to expect applications to be aware of network topology.

I'm not trying to argue good vs. evil, but I do want to argue against the 
assumption that it's reasonable to extend the work currently being done 
by midcom.  And I'm not trying to distract the midcom group from its 
immediate goal as defined by its charter. But since there's a general 
tendency to believe that silence = assent, I think it's necessary for 
dissenting voices to speak up once in awhile.

your loyal dissenter,

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 14:01:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28725
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 14:01:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06269;
	Mon, 20 Aug 2001 14:00:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06238
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 14:00:16 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28652
	for <midcom@ietf.org>; Mon, 20 Aug 2001 13:58:59 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7KHvpD20544
	for <midcom@ietf.org>; Mon, 20 Aug 2001 10:57:52 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-338.cisco.com [10.21.65.82])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACY03627;
	Mon, 20 Aug 2001 10:59:40 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010820140037.00a45030@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 20 Aug 2001 14:01:06 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Delete R48?
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

There's a proposal to delete R48 from Scott's bulleted
list.  Any objections?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 14:01:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28741
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 14:01:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06077;
	Mon, 20 Aug 2001 13:59:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06045
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 13:59:39 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28638
	for <midcom@ietf.org>; Mon, 20 Aug 2001 13:58:22 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7KHxAQ21333
	for <midcom@ietf.org>; Mon, 20 Aug 2001 10:59:11 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-338.cisco.com [10.21.65.82])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACY03605;
	Mon, 20 Aug 2001 10:59:02 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010820134938.00a4d8c0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 20 Aug 2001 14:00:33 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Where we are with proposed deletions
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I've spent the morning plowing through posts on the proposed 
deletions, and here's where we are, agreement-wise:

Don't delete:
R74

Delete:
R16 
R78
R19
R25
R27
R29
R30
R42
R48
R50-57 should be deleted and a new, more concise requirement
	developed (pending)
R71

New proposed deletions:
R11	I think we actually do have agreement that this should be
	subsumed under R50-57
R48	This hasn't yet been agreed

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 15:44:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01438
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 15:44:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09408;
	Mon, 20 Aug 2001 15:43:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09381
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 15:43:08 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01395
	for <midcom@ietf.org>; Mon, 20 Aug 2001 15:41:50 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7KJgUb11042;
	Mon, 20 Aug 2001 14:42:30 -0500
Reply-To: <ramd@netrake.com>
From: "Ram Dantu" <ramd@netrake.com>
To: "'Melinda Shore'" <mshore@cisco.com>, <midcom@ietf.org>
Subject: RE: [midcom] Delete R48?
Date: Mon, 20 Aug 2001 14:42:29 -0500
Message-ID: <7E06D3212981524CA10D2A114937C41406F6AC@NREXCH.netrake.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C12986.56EFB0F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.1.0.14.0.20010820140037.00a45030@mira-sjc5-4.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C12986.56EFB0F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

R48: Unless we describe what is the desired behavior
     (e.g., describing set of actions and selecting one from them),
     this requirement can not exist . 
 

Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Melinda Shore
Sent: Monday, August 20, 2001 1:01 PM
To: midcom@ietf.org
Subject: [midcom] Delete R48?


There's a proposal to delete R48 from Scott's bulleted
list.  Any objections?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------=_NextPart_000_000C_01C12986.56EFB0F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [midcom] Delete R48?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>R48: Unless we describe what is the desired =
behavior</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; (e.g., describing set of =
actions and selecting one from them),</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; this requirement can not =
exist . </FONT>

<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>Ram Dantu</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: midcom-admin@ietf.org [<A =
HREF=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>]On=
 Behalf Of</FONT>

<BR><FONT SIZE=3D2>Melinda Shore</FONT>

<BR><FONT SIZE=3D2>Sent: Monday, August 20, 2001 1:01 PM</FONT>

<BR><FONT SIZE=3D2>To: midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>Subject: [midcom] Delete R48?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>There's a proposal to delete R48 from Scott's =
bulleted</FONT>

<BR><FONT SIZE=3D2>list.&nbsp; Any objections?</FONT>
</P>

<P><FONT SIZE=3D2>Melinda</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>_______________________________________________</FONT>

<BR><FONT SIZE=3D2>midcom mailing list</FONT>

<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.or=
g/mailman/listinfo/midcom</A></FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_000C_01C12986.56EFB0F0--


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 20 15:54:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01747
	for <midcom-archive@odin.ietf.org>; Mon, 20 Aug 2001 15:54:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09663;
	Mon, 20 Aug 2001 15:54:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09634
	for <midcom@ns.ietf.org>; Mon, 20 Aug 2001 15:54:39 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01688
	for <midcom@ietf.org>; Mon, 20 Aug 2001 15:53:17 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA24197
	for <midcom@ietf.org>; Mon, 20 Aug 2001 14:54:03 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 20 Aug 2001 14:52:16 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YHFBMS>; Mon, 20 Aug 2001 14:51:37 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF60@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Delete R48?
Date: Mon, 20 Aug 2001 14:51:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C129B1.82754C00"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C129B1.82754C00
Content-Type: text/plain;
	charset="iso-8859-1"

Melinda,

	Most of us agreed that we need to have two parts to describe a
pinhole - a "descriptor" and "actions". According to Paul's email, R48 can
be a placeholder for the "actions" part. If we're going to subsume both
these parts under pinhole definition (TBD), then R48 is redundant. 

Sanjoy


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Monday, August 20, 2001 1:01 PM
> To: midcom@ietf.org
> Subject: [midcom] Delete R48?
> 
> 
> There's a proposal to delete R48 from Scott's bulleted
> list.  Any objections?
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C129B1.82754C00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Delete R48?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Melinda,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Most of us =
agreed that we need to have two parts to describe a pinhole - a =
&quot;descriptor&quot; and &quot;actions&quot;. According to Paul's =
email, R48 can be a placeholder for the &quot;actions&quot; part. If =
we're going to subsume both these parts under pinhole definition (TBD), =
then R48 is redundant. </FONT></P>

<P><FONT SIZE=3D2>Sanjoy</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, August 20, 2001 1:01 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Delete R48?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There's a proposal to delete R48 from Scott's =
bulleted</FONT>
<BR><FONT SIZE=3D2>&gt; list.&nbsp; Any objections?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C129B1.82754C00--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 06:53:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04003
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 06:53:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16937;
	Tue, 21 Aug 2001 06:46:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16910
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 06:46:36 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03938
	for <midcom@ietf.org>; Tue, 21 Aug 2001 06:45:20 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7LAk6g08111
	for <midcom@ietf.org>; Tue, 21 Aug 2001 11:46:06 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Tue, 21 Aug 2001 11:45:51 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RCF550WT>; Tue, 21 Aug 2001 11:45:49 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451DE@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Delete R48?
Date: Tue, 21 Aug 2001 11:45:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12A2E.70765530"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12A2E.70765530
Content-Type: text/plain;
	charset="iso-8859-1"

Melinda,
I haven't found any section saying that the MIDCOM protocol will request
actions
to be applied to a flow descriptor. I vote to keep R48 unless we provide a
better text for it
Thanks 
Cedric
> -----Original Message----- 
> From: Melinda Shore [mailto:mshore@cisco.com] 
> Sent: Monday, August 20, 2001 1:01 PM 
> To: midcom@ietf.org 
> Subject: [midcom] Delete R48? 
> 
> 
> There's a proposal to delete R48 from Scott's bulleted 
> list.  Any objections? 
> 
> Melinda 
> 
> 
> _______________________________________________ 
> midcom mailing list 
> midcom@ietf.org 
> http://www1.ietf.org/mailman/listinfo/midcom 
> 

------_=_NextPart_001_01C12A2E.70765530
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Delete R48?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Melinda,</FONT>
<BR><FONT SIZE=3D2>I haven't found any section saying that the MIDCOM =
protocol will request actions</FONT>
<BR><FONT SIZE=3D2>to be applied to a flow descriptor. I vote to keep =
R48 unless we provide a better text for it</FONT>
<BR><FONT SIZE=3D2>Thanks </FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, August 20, 2001 1:01 PM </FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Delete R48? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There's a proposal to delete R48 from Scott's =
bulleted </FONT>
<BR><FONT SIZE=3D2>&gt; list.&nbsp; Any objections? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; _______________________________________________ =
</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list </FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A> =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A2E.70765530--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 07:20:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04742
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 07:20:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17958;
	Tue, 21 Aug 2001 07:11:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17920
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 07:11:46 -0400 (EDT)
Received: from rafi ([213.8.76.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04434
	for <midcom@ietf.org>; Tue, 21 Aug 2001 07:10:29 -0400 (EDT)
From: sales@seebex.com
Received: from mail pickup service by rafi with Microsoft SMTPSVC;
	 Tue, 21 Aug 2001 14:12:00 +0200
To: <midcom@ietf.org>
Date: Tue, 21 Aug 2001 14:12:00 +0200
Message-ID: <11ca01c12a3a$7b11abf0$0200a8c0@rafi>
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcEqOnsIt5mSkWO8TkGC6ORCE/bHoQ==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-OriginalArrivalTime: 21 Aug 2001 12:12:00.0631 (UTC) FILETIME=[7B303070:01C12A3A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA17921
Subject: [midcom] Instant Messaging platform at your Web site is now a few clicks away
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

Instant Messaging platform at your Web site is now a few clicks away
----------------------------------------------------------------------
Install a FREE Instant Messaging server at your Web site. 
Use it as is or customize to meet your specific branding.
Cross platform servers line support 25 and up to 1000 concurrent users
All servers offered can be secured with RSA 512Bit (and higher) encryption!!
Download free 10 concurrent users server at:
http://www.seebex.com/download/get_server.asp

It is easier, faster and affordable than ever!!
For further information please check seebex Web site at: http://www.seebex.com
or contact our Marketing & Sales department  at sales@seebex.com

First 50 Web sites to download and embed the free 10 concurrent users server 
are entitled to a free 100 concurrent users server 
and will be listed on Seebex Web site.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 08:33:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08367
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 08:33:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20923;
	Tue, 21 Aug 2001 08:32:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20896
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 08:32:11 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08237
	for <midcom@ietf.org>; Tue, 21 Aug 2001 08:30:54 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7LCVjQ20751;
	Tue, 21 Aug 2001 05:31:45 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp127.cisco.com [10.21.64.127])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ADC06344;
	Tue, 21 Aug 2001 05:31:39 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010821083132.00a56d50@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 21 Aug 2001 08:33:12 -0400
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Delete R48?
In-Reply-To: <9154CB41F208D5118DD200508BE39C304451DE@zjguc006.europe.nor
 tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:45 AM 8/21/01 +0100, Cedric Aoun wrote:
>I haven't found any section saying that the MIDCOM protocol will request actions 
>to be applied to a flow descriptor. I vote to keep R48 unless we provide a better text for it 

It seems to me to be highly unlikely that this working group
would exist if we weren't requesting actions against a set
of parameters.  Are we at some risk of this being unclear?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 08:33:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08408
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 08:33:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20997;
	Tue, 21 Aug 2001 08:34:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20968
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 08:34:13 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08331
	for <midcom@ietf.org>; Tue, 21 Aug 2001 08:32:55 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7LCVoD29667;
	Tue, 21 Aug 2001 05:31:50 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp127.cisco.com [10.21.64.127])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ADC06352;
	Tue, 21 Aug 2001 05:33:41 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010821083422.00a4e080@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 21 Aug 2001 08:35:14 -0400
To: "Sanjoy Sen" <sanjoy@nortelnetworks.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Delete R48?
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430317FF60@crchy271.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 02:51 PM 8/20/01 -0500, Sanjoy Sen wrote:
>        Most of us agreed that we need to have two parts to describe a pinhole - a "descriptor" and "actions". According to Paul's email, R48 can be a placeholder for the "actions" part. If we're going to subsume both these parts under pinhole definition (TBD), then R48 is redundant. 

I'm a little unclear on why the protocol itself is insufficient to
describe actions.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 10:14:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15054
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 10:14:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23918;
	Tue, 21 Aug 2001 10:08:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23886
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 10:07:58 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14409
	for <midcom@ietf.org>; Tue, 21 Aug 2001 10:06:40 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7LE7Rg24371
	for <midcom@ietf.org>; Tue, 21 Aug 2001 15:07:27 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Tue, 21 Aug 2001 15:07:12 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RCF56F87>; Tue, 21 Aug 2001 15:06:36 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451E1@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Delete R48?
Date: Tue, 21 Aug 2001 15:06:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12A4A.74E3D7C0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12A4A.74E3D7C0
Content-Type: text/plain;
	charset="iso-8859-1"

The WG objectives are clear but the exercise we are doing is
to document the protocol requirements (both implicit and explicit types)
right?
I don't want to generate spam threads on this issue, so if it's a big deal I
agree to drop it.
I much prefer we finish all this and that we submit the documents to IESG
(next Friday 31st if we
want to meet our targeted date and we haven't discussed bunch of other
requirements).
Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, August 21, 2001 2:33 PM
To: Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org
Subject: RE: [midcom] Delete R48?


At 11:45 AM 8/21/01 +0100, Cedric Aoun wrote:
>I haven't found any section saying that the MIDCOM protocol will request
actions 
>to be applied to a flow descriptor. I vote to keep R48 unless we provide a
better text for it 

It seems to me to be highly unlikely that this working group
would exist if we weren't requesting actions against a set
of parameters.  Are we at some risk of this being unclear?

Melinda


------_=_NextPart_001_01C12A4A.74E3D7C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [midcom] Delete R48?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The WG objectives are clear but the exercise we are doing is</FONT>
<BR><FONT SIZE=2>to document the protocol requirements (both implicit and explicit types) right?</FONT>
<BR><FONT SIZE=2>I don't want to generate spam threads on this issue, so if it's a big deal I agree to drop it.</FONT>
<BR><FONT SIZE=2>I much prefer we finish all this and that we submit the documents to IESG (next Friday 31st if we</FONT>
<BR><FONT SIZE=2>want to meet our targeted date and we haven't discussed bunch of other requirements).</FONT>
<BR><FONT SIZE=2>Cedric</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Melinda Shore [<A HREF="mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, August 21, 2001 2:33 PM</FONT>
<BR><FONT SIZE=2>To: Aoun, Cedric [QPD:MA01:EXCH]; midcom@ietf.org</FONT>
<BR><FONT SIZE=2>Subject: RE: [midcom] Delete R48?</FONT>
</P>
<BR>

<P><FONT SIZE=2>At 11:45 AM 8/21/01 +0100, Cedric Aoun wrote:</FONT>
<BR><FONT SIZE=2>&gt;I haven't found any section saying that the MIDCOM protocol will request actions </FONT>
<BR><FONT SIZE=2>&gt;to be applied to a flow descriptor. I vote to keep R48 unless we provide a better text for it </FONT>
</P>

<P><FONT SIZE=2>It seems to me to be highly unlikely that this working group</FONT>
<BR><FONT SIZE=2>would exist if we weren't requesting actions against a set</FONT>
<BR><FONT SIZE=2>of parameters.&nbsp; Are we at some risk of this being unclear?</FONT>
</P>

<P><FONT SIZE=2>Melinda</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A4A.74E3D7C0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 10:15:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15125
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 10:15:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24106;
	Tue, 21 Aug 2001 10:13:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24079
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 10:13:48 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14858
	for <midcom@ietf.org>; Tue, 21 Aug 2001 10:12:30 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7LEDTn12187;
	Tue, 21 Aug 2001 07:13:29 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp127.cisco.com [10.21.64.127])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ADC07537;
	Tue, 21 Aug 2001 07:13:16 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010821101320.00a60ec0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 21 Aug 2001 10:14:47 -0400
To: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Delete R48?
In-Reply-To: <9154CB41F208D5118DD200508BE39C304451E1@zjguc006.europe.nor
 tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 03:06 PM 8/21/01 +0100, Cedric Aoun wrote:
>The WG objectives are clear but the exercise we are doing is 
>to document the protocol requirements (both implicit and explicit types) right? 

Within reason.

>I don't want to generate spam threads on this issue, so if it's a big deal I agree to drop it. 
>I much prefer we finish all this and that we submit the documents to IESG (next Friday 31st if we 
>want to meet our targeted date and we haven't discussed bunch of other requirements). 

We cannot hit our milestones - we need to allow 2 weeks for working
group last call, and we're getting bogged down in horse->camel conversion.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 12:04:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22125
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 12:04:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00336;
	Tue, 21 Aug 2001 12:02:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00307
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 12:02:12 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21899
	for <midcom@ietf.org>; Tue, 21 Aug 2001 12:00:55 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7LG1lQ27786;
	Tue, 21 Aug 2001 09:01:47 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7LG1eT09277;
	Tue, 21 Aug 2001 09:01:41 -0700 (PDT)
Message-ID: <3B8285F0.6A1D55EC@cisco.com>
Date: Tue, 21 Aug 2001 09:01:52 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
CC: Cedric Aoun <CEDRIC.AOUN@nortelnetworks.com>, midcom@ietf.org
Subject: Re: [midcom] Delete R48?
References: <5.1.0.14.0.20010821101320.00a60ec0@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Not to put too fine a point on it, but the test of these requirements will
be in the selection of a protocol.  Then we'll *really* see what people
*really* need.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 14:42:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27323
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 14:42:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04997;
	Tue, 21 Aug 2001 14:41:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04962
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 14:41:33 -0400 (EDT)
Received: from web14302.mail.yahoo.com (web14302.mail.yahoo.com [216.136.173.78])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27201
	for <midcom@ietf.org>; Tue, 21 Aug 2001 14:40:16 -0400 (EDT)
Message-ID: <20010821184133.77634.qmail@web14302.mail.yahoo.com>
Received: from [207.164.4.53] by web14302.mail.yahoo.com; Tue, 21 Aug 2001 14:41:33 EDT
Date: Tue, 21 Aug 2001 14:41:33 -0400 (EDT)
From: Abdallah Rayhan <ar_rayhan@yahoo.ca>
To: midcom@ietf.org
In-Reply-To: <7E06D3212981524CA10D2A114937C41406F684@NREXCH.netrake.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [midcom] Rule Extensibility
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

The thing about extensibility is that it brings us back into
integrating application intelligence into the middlebox
which is something the WG is trying to avoid. I believe
that the term and the application of extensibility is and
going to be abused badly and will introduce vendor 
incompatibility. 

IMHO, when extensibility is discussed it should be focused
on new types of agents and new types of middleboxes and not
over stretching the protocol to over NAT or over filter 
packets in the firewall.

regards
Abdallah

--- Ram Dantu <ramd@netrake.com> wrote:
> I think Melinda's wording does cover extensibility
> but to be more explicit, I would suggest the following
> 
> The midcom protocol must be able to carry filtering rules,
> like 5-tuple and to be extensible, from the midcom
> agent to the middlebox.  
> 
> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf
> Of
> Melinda Shore
> Sent: Friday, August 17, 2001 10:12 AM
> To: Mark Duffy; midcom@ietf.org
> Subject: Re: [midcom] precedence of rules?
> 
> 
> At 11:02 AM 8/17/01 -0400, Mark Duffy wrote:
> >Any thoughts?
> 
> I'd really like to keep us moving forward, and one thing that 
> would help is if when you want to see something added, you 
> propose actual text.  I continue to be somewhat concerned that
> we're designing a camel, either way.
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 


_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 14:46:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27523
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 14:46:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05193;
	Tue, 21 Aug 2001 14:46:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05158
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 14:46:44 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27486
	for <midcom@ietf.org>; Tue, 21 Aug 2001 14:45:27 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7LIkVT00469
	for <midcom@ietf.org>; Tue, 21 Aug 2001 11:46:31 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-86.cisco.com [10.21.112.86])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAC00937;
	Tue, 21 Aug 2001 11:46:13 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 21 Aug 2001 14:46:13 -0400
Date: Tue, 21 Aug 2001 14:46:13 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Rule Extensibility
Message-ID: <20010821144613.F1604@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <7E06D3212981524CA10D2A114937C41406F684@NREXCH.netrake.net> <20010821184133.77634.qmail@web14302.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010821184133.77634.qmail@web14302.mail.yahoo.com>; from ar_rayhan@yahoo.ca on Tue, Aug 21, 2001 at 02:41:33PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

On Tue, Aug 21, 2001 at 02:41:33PM -0400, Abdallah Rayhan allegedly wrote:
> The thing about extensibility is that it brings us back into
> integrating application intelligence into the middlebox
> which is something the WG is trying to avoid. I believe
> that the term and the application of extensibility is and
> going to be abused badly and will introduce vendor 
> incompatibility. 
> 
> IMHO, when extensibility is discussed it should be focused
> on new types of agents and new types of middleboxes and not
> over stretching the protocol to over NAT or over filter 
> packets in the firewall.
> 
> regards
> Abdallah

Sounds good to me.  That's what R41 and R2 were meant for.

btw there should be a new version of the bullets available in a few
minutes.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 14:50:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27678
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 14:50:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05325;
	Tue, 21 Aug 2001 14:50:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05294
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 14:50:01 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27633
	for <midcom@ietf.org>; Tue, 21 Aug 2001 14:48:39 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7LIlYh07832;
	Tue, 21 Aug 2001 11:47:34 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7LInNn24268;
	Tue, 21 Aug 2001 11:49:23 -0700 (PDT)
Message-ID: <3B82AD3F.7DBC7AF4@cisco.com>
Date: Tue, 21 Aug 2001 11:49:35 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Abdallah Rayhan <ar_rayhan@yahoo.ca>
CC: midcom@ietf.org
Subject: Re: [midcom] Rule Extensibility
References: <20010821184133.77634.qmail@web14302.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Quite frankly I think the reason extensibility is an issue is that
different people have different goals.  If you're a firewall vendor,
perhaps you want to make your box more intelligent, and that you'd like to
parse more stuff.  If you build policy boxes, you need a way to opaquely
pass some amount of information into the policy system.  This is
particularly the case if the end host *is* the midcom agent.  This,
combined with the experimental nature of the middle box approach, is why
we cannot come to consensus on this point.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 15:12:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28489
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 15:12:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06498;
	Tue, 21 Aug 2001 15:11:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06462
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 15:10:58 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28420
	for <midcom@ietf.org>; Tue, 21 Aug 2001 15:09:41 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7LJ8ah19581
	for <midcom@ietf.org>; Tue, 21 Aug 2001 12:08:36 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-86.cisco.com [10.21.112.86])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAC01406;
	Tue, 21 Aug 2001 12:10:25 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Tue, 21 Aug 2001 15:10:25 -0400
Date: Tue, 21 Aug 2001 15:10:25 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Message-ID: <20010821151025.G1604@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] new requirements bullets
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

A new version of the requirements bullets is now at
<http://www.employees.org/~swb/midcom.html>.

What's new?

- R82 introduced to define scope of rules carried by protocol.

- R11, R50-R57 replaced by R82.

- R16, R19, R27, R29, R30, R42, R48, R78 rejected as part of general
  cleanup of "motherhood" requirements.

- R71 rejected -- punted to next WG.

- R81 added for timer issues.

- Extra notes to reflect discussion.  There were not many of these,
  since the conclusions we reached were better reflected in actual
  bullet status changes.

- I took out the explicit per-bullet security considerations reminders,
  since we're not getting there and I suspect we're only going to do
  security considerations for the newly refrobnicated requirements draft
  as a whole.


We now have:

  12 accepted.
  14 "under discussion".
  18 "not yet discussed".
  42 rejected (a good number).



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 15:20:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28960
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 15:20:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06634;
	Tue, 21 Aug 2001 15:18:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06609
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 15:18:05 -0400 (EDT)
Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28851
	for <midcom@ietf.org>; Tue, 21 Aug 2001 15:16:48 -0400 (EDT)
Received: from NRPC15 (nrpc-15 [10.10.111.222])
	by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f7LJHTb09906;
	Tue, 21 Aug 2001 14:17:29 -0500
Reply-To: <ramd@netrake.com>
From: "Ram Dantu" <ramd@netrake.com>
To: "'Abdallah Rayhan'" <ar_rayhan@yahoo.ca>, <midcom@ietf.org>
Subject: RE: [midcom] Rule Extensibility
Date: Tue, 21 Aug 2001 14:17:27 -0500
Message-ID: <7E06D3212981524CA10D2A114937C414073BF8@NREXCH.netrake.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C12A4C.02A2CF70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <20010821184133.77634.qmail@web14302.mail.yahoo.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C12A4C.02A2CF70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Middleboxes can offer several other features than
just one function (e.g., opening a pin hole using the 5-tuple).
Eliot Lear has stated this more explicitly with examples(please see his
email).
In this context, I do not see any reason limiting to 5-tuple.

Several IETF protocol information elements were extended
several times and I do not call it abuse.

Having said that I have no objection for Melinda's proposal
("including but not limited to 5-tuple")

Regards
Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of
Abdallah Rayhan
Sent: Tuesday, August 21, 2001 1:42 PM
To: midcom@ietf.org
Subject: [midcom] Rule Extensibility


The thing about extensibility is that it brings us back into
integrating application intelligence into the middlebox
which is something the WG is trying to avoid. I believe
that the term and the application of extensibility is and
going to be abused badly and will introduce vendor
incompatibility.

IMHO, when extensibility is discussed it should be focused
on new types of agents and new types of middleboxes and not
over stretching the protocol to over NAT or over filter
packets in the firewall.

regards
Abdallah

--- Ram Dantu <ramd@netrake.com> wrote:
> I think Melinda's wording does cover extensibility
> but to be more explicit, I would suggest the following
>
> The midcom protocol must be able to carry filtering rules,
> like 5-tuple and to be extensible, from the midcom
> agent to the middlebox.
>
> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf
> Of
> Melinda Shore
> Sent: Friday, August 17, 2001 10:12 AM
> To: Mark Duffy; midcom@ietf.org
> Subject: Re: [midcom] precedence of rules?
>
>
> At 11:02 AM 8/17/01 -0400, Mark Duffy wrote:
> >Any thoughts?
>
> I'd really like to keep us moving forward, and one thing that
> would help is if when you want to see something added, you
> propose actual text.  I continue to be somewhat concerned that
> we're designing a camel, either way.
>
> Melinda
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------=_NextPart_000_0006_01C12A4C.02A2CF70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [midcom] Rule Extensibility</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Middleboxes can offer several other features =
than</FONT>

<BR><FONT SIZE=3D2>just one function (e.g., opening a pin hole using the =
5-tuple). </FONT>

<BR><FONT SIZE=3D2>Eliot Lear has stated this more explicitly with =
examples(please see his email). </FONT>

<BR><FONT SIZE=3D2>In this context, I do not see any reason limiting to =
5-tuple.</FONT>
</P>

<P><FONT SIZE=3D2>Several IETF protocol information elements were =
extended </FONT>

<BR><FONT SIZE=3D2>several times and I do not call it abuse.</FONT>
</P>

<P><FONT SIZE=3D2>Having said that I have no objection for Melinda's =
proposal</FONT>

<BR><FONT SIZE=3D2>(&quot;including but not limited to =
5-tuple&quot;)</FONT>
</P>

<P><FONT SIZE=3D2>Regards</FONT>

<BR><FONT SIZE=3D2>Ram Dantu</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: midcom-admin@ietf.org [<A =
HREF=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>]On=
 Behalf Of</FONT>

<BR><FONT SIZE=3D2>Abdallah Rayhan</FONT>

<BR><FONT SIZE=3D2>Sent: Tuesday, August 21, 2001 1:42 PM</FONT>

<BR><FONT SIZE=3D2>To: midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>Subject: [midcom] Rule Extensibility</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The thing about extensibility is that it brings us =
back into</FONT>

<BR><FONT SIZE=3D2>integrating application intelligence into the =
middlebox</FONT>

<BR><FONT SIZE=3D2>which is something the WG is trying to avoid. I =
believe</FONT>

<BR><FONT SIZE=3D2>that the term and the application of extensibility is =
and</FONT>

<BR><FONT SIZE=3D2>going to be abused badly and will introduce vendor =
</FONT>

<BR><FONT SIZE=3D2>incompatibility. </FONT>
</P>

<P><FONT SIZE=3D2>IMHO, when extensibility is discussed it should be =
focused</FONT>

<BR><FONT SIZE=3D2>on new types of agents and new types of middleboxes =
and not</FONT>

<BR><FONT SIZE=3D2>over stretching the protocol to over NAT or over =
filter </FONT>

<BR><FONT SIZE=3D2>packets in the firewall.</FONT>
</P>

<P><FONT SIZE=3D2>regards</FONT>

<BR><FONT SIZE=3D2>Abdallah</FONT>
</P>

<P><FONT SIZE=3D2>--- Ram Dantu &lt;ramd@netrake.com&gt; wrote:</FONT>

<BR><FONT SIZE=3D2>&gt; I think Melinda's wording does cover =
extensibility</FONT>

<BR><FONT SIZE=3D2>&gt; but to be more explicit, I would suggest the =
following</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; The midcom protocol must be able to carry =
filtering rules,</FONT>

<BR><FONT SIZE=3D2>&gt; like 5-tuple and to be extensible, from the =
midcom</FONT>

<BR><FONT SIZE=3D2>&gt; agent to the middlebox.&nbsp; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: midcom-admin@ietf.org [<A =
HREF=3D"mailto:midcom-admin@ietf.org">mailto:midcom-admin@ietf.org</A>]On=
 Behalf</FONT>

<BR><FONT SIZE=3D2>&gt; Of</FONT>

<BR><FONT SIZE=3D2>&gt; Melinda Shore</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Friday, August 17, 2001 10:12 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: Mark Duffy; midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] precedence of =
rules?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; At 11:02 AM 8/17/01 -0400, Mark Duffy =
wrote:</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;Any thoughts?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; I'd really like to keep us moving forward, and =
one thing that </FONT>

<BR><FONT SIZE=3D2>&gt; would help is if when you want to see something =
added, you </FONT>

<BR><FONT SIZE=3D2>&gt; propose actual text.&nbsp; I continue to be =
somewhat concerned that</FONT>

<BR><FONT SIZE=3D2>&gt; we're designing a camel, either way.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Melinda</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>

<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>

<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.or=
g/mailman/listinfo/midcom</A></FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________________</FONT>

<BR><FONT SIZE=3D2>Do You Yahoo!?</FONT>

<BR><FONT SIZE=3D2>Get your free @yahoo.ca address at <A =
HREF=3D"http://mail.yahoo.ca">http://mail.yahoo.ca</A></FONT>
</P>

<P><FONT SIZE=3D2>_______________________________________________</FONT>

<BR><FONT SIZE=3D2>midcom mailing list</FONT>

<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom">http://www1.ietf.or=
g/mailman/listinfo/midcom</A></FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0006_01C12A4C.02A2CF70--


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 21 18:09:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02460
	for <midcom-archive@odin.ietf.org>; Tue, 21 Aug 2001 18:09:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10626;
	Tue, 21 Aug 2001 18:08:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10598
	for <midcom@ns.ietf.org>; Tue, 21 Aug 2001 18:07:55 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02437
	for <midcom@ietf.org>; Tue, 21 Aug 2001 18:06:38 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA11112
	for <midcom@ietf.org>; Tue, 21 Aug 2001 17:07:18 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Tue, 21 Aug 2001 14:59:34 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RKKYBJAQ>; Tue, 21 Aug 2001 15:06:58 -0700
Message-ID: <A7895B732354D311A4770008C791841A013F4E29@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'midcom@ietf.org'" <midcom@ietf.org>
Cc: "'Abdallah Rayhan'" <ar_rayhan@yahoo.ca>
Subject: RE: [midcom] Rule Extensibility
Date: Tue, 21 Aug 2001 15:06:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12A8D.989B3B70"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12A8D.989B3B70
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca]
> Sent: Tuesday, August 21, 2001 11:42 AM
> To: midcom@ietf.org
> Subject: [midcom] Rule Extensibility
> 
> 
> The thing about extensibility is that it brings us back into
> integrating application intelligence into the middlebox
> which is something the WG is trying to avoid. I believe
> that the term and the application of extensibility is and
> going to be abused badly and will introduce vendor 
> incompatibility. 

Hello Abadallah,

I do not think vendor incompatibility is an issue due to extensibility.
Radius, for instance, started out with a some attributes that were later
greatly extended in the IETF,  by other vendors and I do not see any
incompatibility.

You just grab Lucent's, Nortel's or Cisco's dictionary, install them and
presto. This is a good example on how extensibility didn't mess with the
base protocol and allowed vendors to put attributes to suit their needs.

regards,

Reinaldo


------_=_NextPart_001_01C12A8D.989B3B70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Rule Extensibility</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Abdallah Rayhan [<A =
HREF=3D"mailto:ar_rayhan@yahoo.ca">mailto:ar_rayhan@yahoo.ca</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 21, 2001 11:42 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Rule Extensibility</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The thing about extensibility is that it brings =
us back into</FONT>
<BR><FONT SIZE=3D2>&gt; integrating application intelligence into the =
middlebox</FONT>
<BR><FONT SIZE=3D2>&gt; which is something the WG is trying to avoid. I =
believe</FONT>
<BR><FONT SIZE=3D2>&gt; that the term and the application of =
extensibility is and</FONT>
<BR><FONT SIZE=3D2>&gt; going to be abused badly and will introduce =
vendor </FONT>
<BR><FONT SIZE=3D2>&gt; incompatibility. </FONT>
</P>

<P><FONT SIZE=3D2>Hello Abadallah,</FONT>
</P>

<P><FONT SIZE=3D2>I do not think vendor incompatibility is an issue due =
to extensibility. Radius, for instance, started out with a some =
attributes that were later greatly extended in the IETF,&nbsp; by other =
vendors and I do not see any incompatibility.</FONT></P>

<P><FONT SIZE=3D2>You just grab Lucent's, Nortel's or Cisco's =
dictionary, install them and presto. This is a good example on how =
extensibility didn't mess with the base protocol and allowed vendors to =
put attributes to suit their needs.</FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A8D.989B3B70--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 22 10:15:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09463
	for <midcom-archive@odin.ietf.org>; Wed, 22 Aug 2001 10:15:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13147;
	Wed, 22 Aug 2001 10:08:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13114
	for <midcom@ns.ietf.org>; Wed, 22 Aug 2001 10:08:48 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08925
	for <midcom@ietf.org>; Wed, 22 Aug 2001 10:07:28 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA12887
	for <midcom@ietf.org>; Wed, 22 Aug 2001 09:08:16 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Wed, 22 Aug 2001 07:00:31 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RKKYBW5H>; Wed, 22 Aug 2001 07:07:56 -0700
Message-ID: <A7895B732354D311A4770008C791841A0146AC33@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'midcom@ietf.org'" <midcom@ietf.org>
Date: Wed, 22 Aug 2001 07:07:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12B13.D63B7B80"
X-Orig: <reinaldo_penno@americasm06.nt.com>
Subject: [midcom] MIDCOM and OOP
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12B13.D63B7B80
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

I know OOP agents are out of scope but since I'll probably need to use them,
even for OPES, we decided to write something on the subject. Comments are
welcome (in private please, since this subject is not in scope)

thanks,

-RP


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Out-Of-Path (OOP) Agents and MIDCOM Framework 
                          Integration
	Author(s)	: R. Penno, A. Rayhan, M. Duffy
	Filename	: draft-penno-midcom-oop-00.txt
	Pages		: 
	Date		: 21-Aug-01
	
This draft extends the MIDCOM framework  described in [midcom] to
support Out-Of-Path (OOP) agents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-penno-midcom-oop-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-penno-midcom-oop-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------_=_NextPart_001_01C12B13.D63B7B80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>MIDCOM and OOP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>I know OOP agents are out of scope but since I'll =
probably need to use them, even for OPES, we decided to write something =
on the subject. Comments are welcome (in private please, since this =
subject is not in scope)</FONT></P>

<P><FONT SIZE=3D2>thanks,</FONT>
</P>

<P><FONT SIZE=3D2>-RP</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Out-Of-Path (OOP) Agents and MIDCOM Framework </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; Integration</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : R. Penno, A. =
Rayhan, M. Duffy</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-penno-midcom-oop-00.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 21-Aug-01</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>This draft extends the MIDCOM framework&nbsp; =
described in [midcom] to</FONT>
<BR><FONT SIZE=3D2>support Out-Of-Path (OOP) agents.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-penno-midcom-oop-00.tx=
t" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-penno-midcom=
-oop-00.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
Login with the username</FONT>
<BR><FONT SIZE=3D2>&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT SIZE=3D2>type &quot;cd internet-drafts&quot; and then</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
draft-penno-midcom-oop-00.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found =
in</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12B13.D63B7B80--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 22 11:16:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12834
	for <midcom-archive@odin.ietf.org>; Wed, 22 Aug 2001 11:16:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15550;
	Wed, 22 Aug 2001 11:13:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15523
	for <midcom@ns.ietf.org>; Wed, 22 Aug 2001 11:13:46 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12587
	for <midcom@ietf.org>; Wed, 22 Aug 2001 11:12:26 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7MFDQn04697
	for <midcom@ietf.org>; Wed, 22 Aug 2001 08:13:26 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7MFDDi25043
	for <midcom@ietf.org>; Wed, 22 Aug 2001 08:13:13 -0700 (PDT)
Message-ID: <3B83CAFB.F6156118@cisco.com>
Date: Wed, 22 Aug 2001 08:08:43 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: midcom@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [midcom] comments on latest rev.
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

I'll try and keep this short:

R31:  too vague.  remove.

R39:  Motherhood and apple pie.  Remove.

R2 and R41 are redundant with one another.

R68:  s/confidentiality protection/authentication mechanisms and &/

R70:

Is this redundant with R69, given the modification to R68?

R73:  not vague enough ;-)  I recommend replace with the following:

...MUST provide mechanisms that robustly protect against hostile attempts
at unauthorized access and denial of service.

R5:

This is in large part redundant with R3b.  What's not redundant is simply
wrong.  What is the response to a delete? "one down one to go"?

Similarly R79.  Remove.

R80:

Why is it not an error to allocate overlapping resources in the first
place?

R14:

Going beyond the following is beyond scope of a protocol:

>       The MIDCOM protocol must support multiple transactions over the same
>       transport connection.

--
Eliot Lear
lear@cisco.com


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 22 11:59:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14670
	for <midcom-archive@odin.ietf.org>; Wed, 22 Aug 2001 11:59:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17437;
	Wed, 22 Aug 2001 11:53:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17409
	for <midcom@ns.ietf.org>; Wed, 22 Aug 2001 11:53:00 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14397
	for <midcom@ietf.org>; Wed, 22 Aug 2001 11:51:40 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA03441
	for <midcom@ietf.org>; Wed, 22 Aug 2001 10:52:29 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 22 Aug 2001 10:52:58 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YHGBCT>; Wed, 22 Aug 2001 10:52:18 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF68@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Delete R48?
Date: Wed, 22 Aug 2001 10:52:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12B22.6A4AE460"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12B22.6A4AE460
Content-Type: text/plain;
	charset="iso-8859-1"


If you're implying that the "actions" will be carried as a protocol element
then I'm with you.
Sanjoy

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, August 21, 2001 7:35 AM
> To: Sen, Sanjoy [NGB:B602:EXCH]; midcom@ietf.org
> Subject: RE: [midcom] Delete R48?
> 
> 
> At 02:51 PM 8/20/01 -0500, Sanjoy Sen wrote:
> >        Most of us agreed that we need to have two parts to 
> describe a pinhole - a "descriptor" and "actions". According 
> to Paul's email, R48 can be a placeholder for the "actions" 
> part. If we're going to subsume both these parts under 
> pinhole definition (TBD), then R48 is redundant. 
> 
> I'm a little unclear on why the protocol itself is insufficient to
> describe actions.
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12B22.6A4AE460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Delete R48?</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>If you're implying that the &quot;actions&quot; will =
be carried as a protocol element then I'm with you.</FONT>
<BR><FONT SIZE=3D2>Sanjoy</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 21, 2001 7:35 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Sen, Sanjoy [NGB:B602:EXCH]; =
midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [midcom] Delete R48?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 02:51 PM 8/20/01 -0500, Sanjoy Sen =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Most of us agreed that we need to have two parts to </FONT>
<BR><FONT SIZE=3D2>&gt; describe a pinhole - a &quot;descriptor&quot; =
and &quot;actions&quot;. According </FONT>
<BR><FONT SIZE=3D2>&gt; to Paul's email, R48 can be a placeholder for =
the &quot;actions&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; part. If we're going to subsume both these =
parts under </FONT>
<BR><FONT SIZE=3D2>&gt; pinhole definition (TBD), then R48 is =
redundant. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm a little unclear on why the protocol itself =
is insufficient to</FONT>
<BR><FONT SIZE=3D2>&gt; describe actions.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12B22.6A4AE460--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 22 17:27:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24399
	for <midcom-archive@odin.ietf.org>; Wed, 22 Aug 2001 17:27:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02346;
	Wed, 22 Aug 2001 17:26:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02317
	for <midcom@ns.ietf.org>; Wed, 22 Aug 2001 17:26:43 -0400 (EDT)
Received: from permissiononly.com (permissiononly.com [216.133.253.90])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24360
	for <midcom@ietf.org>; Wed, 22 Aug 2001 17:25:21 -0400 (EDT)
Received: (from mailman@localhost)
	by permissiononly.com (8.9.3/8.9.3) id NAA02476;
	Wed, 22 Aug 2001 13:47:07 -0700
Date: Wed, 22 Aug 2001 13:47:07 -0700
Message-Id: <200108222047.NAA02476@permissiononly.com>
Content-type: text/html
From: C.Bryce@permissiononly.com
To: midcom@ietf.org
Subject: [midcom] Add Streaming Media to your Web Site
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

<!--
Your E-mail Client Does Not Support HTML. 

Visit http://www.vitalstream.com/ads/wme/signin.html for your FREE Streaming Kit.
-->

<HTML>
<HEAD>
<TITLE>VitalStream</TITLE>

</HEAD>
<BODY BGCOLOR=#0038A8 background="http://www.vitalstream.com/ads/wme/images/background.gif" link="#0038A8" vlink="#339900" alink="#00A3DD">
<TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 width="680" align="center">
  <TR>
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-tl.gif" WIDTH=5 HEIGHT=5></TD>
    <TD bgcolor="#FFFFFF" height="5" width="670"><img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="5" height="5"></TD>
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-tr.gif" WIDTH=5 HEIGHT=5></TD></TR>
        <TR>
                
    <TD bgcolor="#FFFFFF" width="5">&nbsp; </TD>
    <TD bgcolor="#FFFFFF" width="670">
      <table width="670" border="0" cellspacing="0" cellpadding="5">
        <tr> 
          <td rowspan="2" width="230"> 
            <table border=0 cellpadding=0 cellspacing=0 align="center">
              <tr> 
                <td colspan=3> <img src="http://www.vitalstream.com/ads/wme/images/wm-t.gif" width=220 height=12></td>
              </tr>
              <tr> 
                <td> <img src="http://www.vitalstream.com/ads/wme/images/wm-l.gif" width=30 height=120></td>
                <td> <a href="http://www.vitalstream.com/streaming/showcase.html"><img src="http://www.vitalstream.com/ads/wme/images/screen-showcase.jpg" width=160 height=120 alt="Now Showing" border="0"></a></td>
                <td> <img src="http://www.vitalstream.com/ads/wme/images/wm-r.gif" width=30 height=120></td>
              </tr>
              <tr> 
                <td colspan=3> <a href="http://www.vitalstream.com/ads/wme/signin.asp"><img src="http://www.vitalstream.com/ads/wme/images/wm-b.gif" width=220 height=92 alt="Free Streaming Kit" border="0"></a></td>
              </tr>
            </table>
          </td>
          <td colspan="2" align="center"><font face="Arial, Helvetica, sans-serif" size="4" color="#5BBF21"><b>You 
            Can Add Streaming Media to<br>
            Your Company's Web Site</b></font></td>
        </tr>
        <tr> 
          <td valign="top" width="220"> 
            <p><font face="Arial, Helvetica, sans-serif" color="#0038A8"><b>Streaming 
              Media is Easier Than You Think</b></font><br>
              <img src="images/clear-pixel.gif" width="10" height="10"><br>
              <font face="Arial, Helvetica, sans-serif" size="2">I invite you 
              to learn more about streaming media by reading our <a href="http://www.vitalstream.com/ads/wme/signin.asp">Free 
              Streaming Kit</a> on Live Streaming with Windows Media. It contains 
              a step-by-step tutorial on how to stream media over the Internet 
              with Windows Media technologies.</font></p>
            </td>
          <td valign="top" width="220"> 
            <p><font face="Arial, Helvetica, sans-serif" size="2">VitalStream 
              specializes in customized streaming and hosting solutions for small 
              to medium sized businesses.</font><br>
              <img src="images/clear-pixel.gif" width="10" height="10"><br>
              <font face="Arial, Helvetica, sans-serif" color="#0038A8"><b>VitalStream 
              Delivers...</b></font><font face="Arial, Helvetica, sans-serif" size="2"><br>
              <img src="images/clear-pixel.gif" width="5" height="5"><br>
              - Live and On-Demand Streaming <br>
              - Pay-Per-View Solutions <br>
              - 24 x 7 Live Technical Support <br>
              - 99.7% Guaranteed Uptime <br>
              - And More...</font></p>
            </td>
        </tr>
        <tr> 
          <td width="230" align="center" valign="top"> 
            <p><font color="#0038A8" face="Arial, Helvetica, sans-serif" size="2"> 
              <a href="http://www.vitalstream.com/streaming/showcase.html">These 
              companies</a> use us <br>
              for their streaming needs. </font></p>
            <p><font color="#0038A8" face="Arial, Helvetica, sans-serif" size="2">Call 
              today to see what <br>
              VitalStream can do for <br>
              your company's web site</font></p>
          </td>
          <td width="220" valign="middle" align="center"><img src="http://www.vitalstream.com/ads/wme/images/logo-wmsp-h.gif" width="110" height="58" alt="Windows Media Service Provider"></td>
          <td width="220" valign="top"> 
            <p><font face="Arial, Helvetica, sans-serif" size="2" color="#0038A8">
             cbryce@vitalstream.cc</font><font face="Arial, Helvetica, sans-serif" size="2"><br>
              Account Representative<br>
              (800) 254-7554 x2025<br>
              C. Bryce</font><br>
              <img src="images/clear-pixel.gif" width="10" height="10"><br>
              <a href="http://www.vitalstream.com"><img src="http://www.vitalstream.com/ads/wme/images/logo-vs.gif" width="166" height="37" alt="VitalStream" border="0"></a></p>
            </td>
        </tr>
      </table>
    </TD>
    <TD bgcolor="#FFFFFF" width="5">&nbsp; </TD>
        </TR>
        <TR>            
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-bl.gif" WIDTH=5 HEIGHT=5></TD>             
    <TD bgcolor="#FFFFFF" height="5" width="670"><img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="5" height="5"></TD>           
    <TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-br.gif" WIDTH=5 HEIGHT=5></TD></TR>
</TABLE>
<div align="center">
  <p><br>
    <a href="http://www.vitalstream.com/vscc/vscc.asp"><font face="Arial, Helvetica, sans-serif" size="1" color="#6699FF">Click 
    here</font></a> <font face="Arial, Helvetica, sans-serif" size="1" color="#6699FF">if 
    you received this message in error.</font></p>
  <p><font face="Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Microsoft, 
    Windows Media, and the Windows Logo are trademarks or registered <br>
    trademarks of Microsoft Corporation </font><font face="Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">in 
    the United States and/or other countries.</font></p>
  </div>
</BODY>
</HTML>
 

 


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 10:37:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24448
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 10:37:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07763;
	Thu, 23 Aug 2001 10:37:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07734
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 10:37:05 -0400 (EDT)
Received: from WIN2K-SRV-001.reddo.net (57.131.88.213.host.tele1europe.se [213.88.131.57] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24408
	for <midcom@ietf.org>; Thu, 23 Aug 2001 10:35:47 -0400 (EDT)
Received: by WIN2K-SRV-001.reddo.net with Internet Mail Service (5.5.2650.21)
	id <RJQ2BHPX>; Thu, 23 Aug 2001 16:31:11 +0200
Message-ID: <8346B686B0DBC1469AA5307F8BABBB3F01ABFC@WIN2K-SRV-001.reddo.net>
From: Johan Gerhardsson <johan.gerhardsson@reddo.net>
To: "'midcom@ietf.org'" <midcom@ietf.org>
Date: Thu, 23 Aug 2001 16:31:06 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [midcom] Does midcom work with RTSP?
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Hello all,

my name is Johan Gerhardsson, I'm thinking of a use case where a RTSP proxy
"implements" midcom agent procuderes (i.e. a RTSP proxy uses midcom to do
nat bindings and opens a pin-hole in a middlebox in order to let media
through to an end-user application that is located in a private network).
Question: Does RTSP really work with midcom?

RFC2326 (RTSP), page.59, general parameters: destination: "A server SHOULD
not allow a client to direct media streams to an address that differs from
the address commands are coming from." 
I.e. the RTSP protocol recomend RTSP servers to NOT allow clients to specify
an alternate IP address to receive media (e.g. RTP) other than what was used
in the RTSP signalling (the TCP stream where RTSP is in use). 

How is it then possible to use midcom in order to open a pinhole through a
middlebox that routes the RTP packets from the server directly to the client
(not through the proxy) when the proxy opens a second TCP stream connection
towards the server which implicitely tells the server to send the RTP
packets to the proxy?

I think fig.2 in <draft-ietf-midcom-framework-03.txt> isn't in harmony with
the statement above from the RTSP RFC.

Have I missed something?

Thanks


Johan Gerhardsson
Reddo Networks AB
email: johan.gerhardsson@reddonetworks.se
http://reddo.net




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 11:01:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25035
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 11:01:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08602;
	Thu, 23 Aug 2001 11:00:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08554
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 11:00:00 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24848
	for <midcom@ietf.org>; Thu, 23 Aug 2001 10:58:42 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7NEvbh02999;
	Thu, 23 Aug 2001 07:57:38 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-47.cisco.com [10.21.112.47])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAB03670;
	Thu, 23 Aug 2001 07:59:29 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Aug 2001 10:59:28 -0400
Date: Thu, 23 Aug 2001 10:59:27 -0400
From: Scott Brim <sbrim@cisco.com>
To: Johan Gerhardsson <johan.gerhardsson@reddo.net>
Cc: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: Re: [midcom] Does midcom work with RTSP?
Message-ID: <20010823105927.A596@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	Johan Gerhardsson <johan.gerhardsson@reddo.net>,
	"'midcom@ietf.org'" <midcom@ietf.org>
References: <8346B686B0DBC1469AA5307F8BABBB3F01ABFC@WIN2K-SRV-001.reddo.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <8346B686B0DBC1469AA5307F8BABBB3F01ABFC@WIN2K-SRV-001.reddo.net>; from johan.gerhardsson@reddo.net on Thu, Aug 23, 2001 at 04:31:06PM +0200
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Johan Gerhardsson schrieb am Thu, Aug 23, 2001 04:31:06PM +0200:
> Hello all,
> 
> my name is Johan Gerhardsson, I'm thinking of a use case where a RTSP proxy
> "implements" midcom agent procuderes (i.e. a RTSP proxy uses midcom to do
> nat bindings and opens a pin-hole in a middlebox in order to let media
> through to an end-user application that is located in a private network).
> Question: Does RTSP really work with midcom?
> 
> RFC2326 (RTSP), page.59, general parameters: destination: "A server SHOULD
> not allow a client to direct media streams to an address that differs from
> the address commands are coming from." 
> I.e. the RTSP protocol recomend RTSP servers to NOT allow clients to specify
> an alternate IP address to receive media (e.g. RTP) other than what was used
> in the RTSP signalling (the TCP stream where RTSP is in use). 
> 
> How is it then possible to use midcom in order to open a pinhole through a
> middlebox that routes the RTP packets from the server directly to the client
> (not through the proxy) when the proxy opens a second TCP stream connection
> towards the server which implicitely tells the server to send the RTP
> packets to the proxy?
> 
> I think fig.2 in <draft-ietf-midcom-framework-03.txt> isn't in harmony with
> the statement above from the RTSP RFC.
> 
> Have I missed something?

The issue raised in rfc2326 would be between a client and and an RTSP
proxy.  The midcom machinery is separate and wouldn't even know there's
an issue.

The midcom protocol has not been specified yet.  However, the general
feeling is that it will be very simple.  An authorized agent will be
able to request a middlebox to install packet matching and modifying
rules, for example "let packets between X and Y to pass through".  The
requirements on the midcom protocol, to the extent that they have been
worked out, do not say anything about restricting which addresses or
group of addresses can be in such a rule.

Similarly, there is nothing in the midcom protocol that would require a
middlebox to know about any relationship between agent and endpoint
client.  Unless new requirements come up, the middlebox has no reason or
means to know which particular endpoint activity caused an agent to
generate a particular ruleset request.  In fact the whole point of the
Midcom WG is to remove such intelligence from the middlebox.

So, if there is an issue, it is with the RTSP proxy -- it needs to
follow rfc2326 in deciding how it grants client requests.  Once those
decisions are made, the requests it makes to the middlebox via the
midcom protocol will fall out automatically.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 16:38:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01186
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 16:38:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21828;
	Thu, 23 Aug 2001 16:37:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21795
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 16:37:14 -0400 (EDT)
Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01133
	for <midcom@ietf.org>; Thu, 23 Aug 2001 16:35:53 -0400 (EDT)
Received: from 157.54.9.101 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Aug 2001 13:36:20 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:36:19 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:36:18 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:36:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [midcom] Delete R48?
Date: Thu, 23 Aug 2001 13:36:02 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BF24@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [midcom] Delete R48?
Thread-Index: AcErIzTsATumRfNFSDiHlIF1tPmmRwA71iOQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Sanjoy Sen" <sanjoy@nortelnetworks.com>,
        "Melinda Shore" <mshore@cisco.com>, <midcom@ietf.org>
X-OriginalArrivalTime: 23 Aug 2001 20:36:03.0140 (UTC) FILETIME=[39F45840:01C12C13]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA21796
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

Melinda,

I think that we may want to keep some version of rule 48 -- possibly
rewritten. When you open a pinhole through a firewall, it seems
reasonable to inform the firewall of the stated purpose of the opening:
a voice conversation, a video stream, a file transfer. Stating it allows
the firewall to check whether the opening conforms to policy, e.g. "no
video calls during business hours"; it also allows the firewall, at a
later stage, to check that the traffic profile is consistent with the
stated purpose.

-- Christian Huitema

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 16:45:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01368
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 16:45:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22203;
	Thu, 23 Aug 2001 16:45:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22173
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 16:45:13 -0400 (EDT)
Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01314
	for <midcom@ietf.org>; Thu, 23 Aug 2001 16:43:52 -0400 (EDT)
Received: from 157.54.1.52 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Aug 2001 13:44:35 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:44:12 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:44:17 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:44:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 23 Aug 2001 13:44:01 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BF25@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Pinhole definition and attributes, not parameters and actions
Thread-Index: AcErIzTsATumRfNFSDiHlIF1tPmmRwA8A4eQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: <midcom@ietf.org>
X-OriginalArrivalTime: 23 Aug 2001 20:44:02.0125 (UTC) FILETIME=[5773A7D0:01C12C14]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA22174
Subject: [midcom] Pinhole definition and attributes, not parameters and actions
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

During the discussion of rule 48, we started speaking about rule
parameters and actions. I think this is inappropriate, and would rather
see us speak about rule "definition" and "attributes."

A rule "definition" is the set of parameter that defines the rule --
i.e., exactly what we are going to study as part of the "filter
specification." The basic idea here is that there can be only one rule
for a given definition. An example of definition might be a five tuple.

The rule "attributes" is everything else, for example the NAT mapping
associated to the five tupple, the time to live of the rule, maybe the
expected "application profile" alluded to in R48. The MIDCOM protocol
will allow MIDCOM agents to modify these attributes, under appropriate
control.

-- Christian Huitema

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 16:58:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01542
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 16:58:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22732;
	Thu, 23 Aug 2001 16:57:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22705
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 16:57:41 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01527
	for <midcom@ietf.org>; Thu, 23 Aug 2001 16:56:22 -0400 (EDT)
Received: from 157.54.9.104 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Aug 2001 13:56:41 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:56:41 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:56:40 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 13:56:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 23 Aug 2001 13:56:24 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BF26@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Proposed R83,R84, RTP+RTCP port numbers
Thread-Index: AcErIzTsATumRfNFSDiHlIF1tPmmRwA71iOQAACw5sA=
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: <midcom@ietf.org>
X-OriginalArrivalTime: 23 Aug 2001 20:56:25.0093 (UTC) FILETIME=[124B9350:01C12C16]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA22706
Subject: [midcom] Proposed R83,R84, RTP+RTCP port numbers
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

In order to accommodate RTP and RTCP "oddity" and "sequence"
requirements, I propose that we add the following requirements:

R83: When the MIDCOM server performs a port mapping function, the
protocol should allow the MIDCOM agent to request that the external port
number have the same oddity as the internal port.

R84: When the MIDCOM server performs a port mapping function, the
protocol should allow the MIDCOM agent to request that a consecutive
range of external port numbers be mapped to consecutive external ports.

-- Christian Huitema

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 17:26:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02086
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:26:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23822;
	Thu, 23 Aug 2001 17:24:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23794
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 17:24:15 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02048
	for <midcom@ietf.org>; Thu, 23 Aug 2001 17:22:56 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7NLLqh08735
	for <midcom@ietf.org>; Thu, 23 Aug 2001 14:21:52 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-47.cisco.com [10.21.112.47])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAB11120;
	Thu, 23 Aug 2001 14:23:42 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Aug 2001 17:23:39 -0400
Date: Thu, 23 Aug 2001 17:23:39 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Proposed R83,R84, RTP+RTCP port numbers
Message-ID: <20010823172339.H596@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <F66A04C29AD9034A8205949AD0C9010418BF26@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010418BF26@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>; from huitema@windows.microsoft.com on Thu, Aug 23, 2001 at 01:56:24PM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Friendly amendment: s/MIDCOM server/middlebox/.  OK?

Christian Huitema schrieb am Thu, Aug 23, 2001 01:56:24PM -0700:
> In order to accommodate RTP and RTCP "oddity" and "sequence"
> requirements, I propose that we add the following requirements:
> 
> R83: When the MIDCOM server performs a port mapping function, the
> protocol should allow the MIDCOM agent to request that the external port
> number have the same oddity as the internal port.
> 
> R84: When the MIDCOM server performs a port mapping function, the
> protocol should allow the MIDCOM agent to request that a consecutive
> range of external port numbers be mapped to consecutive external ports.
> 
> -- Christian Huitema

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 17:36:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02297
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:36:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24330;
	Thu, 23 Aug 2001 17:32:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24293
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 17:32:44 -0400 (EDT)
Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02227
	for <midcom@ietf.org>; Thu, 23 Aug 2001 17:31:25 -0400 (EDT)
Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Aug 2001 14:31:43 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 14:31:02 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 14:31:02 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 23 Aug 2001 14:30:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [midcom] Proposed R83,R84, RTP+RTCP port numbers
Date: Thu, 23 Aug 2001 14:30:46 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C90104A3E6C6@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [midcom] Proposed R83,R84, RTP+RTCP port numbers
Thread-Index: AcEsGiXD5woYjD/zQaisnJuavZjvkQAAJaAw
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Scott Brim" <sbrim@cisco.com>, <midcom@ietf.org>
X-OriginalArrivalTime: 23 Aug 2001 21:30:46.0984 (UTC) FILETIME=[DF472C80:01C12C1A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA24296
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

OK. Also, s/external/internal/ once on last line. (my typo)

> From: Scott Brim [mailto:sbrim@cisco.com]
> 
> Friendly amendment: s/MIDCOM server/middlebox/.  OK?
> 
> Christian Huitema schrieb am Thu, Aug 23, 2001 01:56:24PM -0700:
> > In order to accommodate RTP and RTCP "oddity" and "sequence"
> > requirements, I propose that we add the following requirements:
> >
> > R83: When the MIDCOM server performs a port mapping function, the
> > protocol should allow the MIDCOM agent to request that the external
> port
> > number have the same oddity as the internal port.
> >
> > R84: When the MIDCOM server performs a port mapping function, the
> > protocol should allow the MIDCOM agent to request that a consecutive
> > range of external port numbers be mapped to consecutive external
> ports.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 23 17:43:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02377
	for <midcom-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:43:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24597;
	Thu, 23 Aug 2001 17:43:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24569
	for <midcom@ns.ietf.org>; Thu, 23 Aug 2001 17:43:20 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02368
	for <midcom@ietf.org>; Thu, 23 Aug 2001 17:42:00 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7NLh1n20947
	for <midcom@ietf.org>; Thu, 23 Aug 2001 14:43:01 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-47.cisco.com [10.21.112.47])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAB11441;
	Thu, 23 Aug 2001 14:42:47 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Aug 2001 17:42:44 -0400
Date: Thu, 23 Aug 2001 17:42:44 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Proposed R83,R84, RTP+RTCP port numbers
Message-ID: <20010823174244.J596@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <F66A04C29AD9034A8205949AD0C90104A3E6C6@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F66A04C29AD9034A8205949AD0C90104A3E6C6@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>; from huitema@windows.microsoft.com on Thu, Aug 23, 2001 at 02:30:46PM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I'll add this to the next version of the requirements.  I was trying to
do a version every Friday but we were delayed working out the Big Delete
last time.  I'll wait until Monday (unless Melinda says different).

..Scott

Christian Huitema schrieb am Thu, Aug 23, 2001 02:30:46PM -0700:
> OK. Also, s/external/internal/ once on last line. (my typo)
> 
> > From: Scott Brim [mailto:sbrim@cisco.com]
> > 
> > Friendly amendment: s/MIDCOM server/middlebox/.  OK?
> > 
> > Christian Huitema schrieb am Thu, Aug 23, 2001 01:56:24PM -0700:
> > > In order to accommodate RTP and RTCP "oddity" and "sequence"
> > > requirements, I propose that we add the following requirements:
> > >
> > > R83: When the MIDCOM server performs a port mapping function, the
> > > protocol should allow the MIDCOM agent to request that the external
> > port
> > > number have the same oddity as the internal port.
> > >
> > > R84: When the MIDCOM server performs a port mapping function, the
> > > protocol should allow the MIDCOM agent to request that a consecutive
> > > range of external port numbers be mapped to consecutive external
> > ports.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 24 03:57:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27023
	for <midcom-archive@odin.ietf.org>; Fri, 24 Aug 2001 03:57:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20579;
	Fri, 24 Aug 2001 03:45:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20549
	for <midcom@ns.ietf.org>; Fri, 24 Aug 2001 03:45:49 -0400 (EDT)
Received: from WIN2K-SRV-001.reddo.net (57.131.88.213.host.tele1europe.se [213.88.131.57] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26930
	for <midcom@ietf.org>; Fri, 24 Aug 2001 03:44:31 -0400 (EDT)
Received: by WIN2K-SRV-001.reddo.net with Internet Mail Service (5.5.2650.21)
	id <RJQ2BHTP>; Fri, 24 Aug 2001 09:39:53 +0200
Message-ID: <8346B686B0DBC1469AA5307F8BABBB3F01ABFD@WIN2K-SRV-001.reddo.net>
From: Johan Gerhardsson <johan.gerhardsson@reddo.net>
To: "'Scott Brim'" <sbrim@cisco.com>
Cc: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Does midcom work with RTSP?
Date: Fri, 24 Aug 2001 09:39:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

> -----Original Message-----
> From: Scott Brim [mailto:sbrim@cisco.com]
> Sent: Thursday, August 23, 2001 4:59 PM
> To: Johan Gerhardsson
> Cc: 'midcom@ietf.org'
> Subject: Re: [midcom] Does midcom work with RTSP?
> 
> 
> Johan Gerhardsson schrieb am Thu, Aug 23, 2001 04:31:06PM +0200:
> > Hello all,
> > 
> > my name is Johan Gerhardsson, I'm thinking of a use case 
> where a RTSP proxy
> > "implements" midcom agent procuderes (i.e. a RTSP proxy 
> uses midcom to do
> > nat bindings and opens a pin-hole in a middlebox in order 
> to let media
> > through to an end-user application that is located in a 
> private network).
> > Question: Does RTSP really work with midcom?
> > 
> > RFC2326 (RTSP), page.59, general parameters: destination: 
> "A server SHOULD
> > not allow a client to direct media streams to an address 
> that differs from
> > the address commands are coming from." 
> > I.e. the RTSP protocol recomend RTSP servers to NOT allow 
> clients to specify
> > an alternate IP address to receive media (e.g. RTP) other 
> than what was used
> > in the RTSP signalling (the TCP stream where RTSP is in use). 
> > 
> > How is it then possible to use midcom in order to open a 
> pinhole through a
> > middlebox that routes the RTP packets from the server 
> directly to the client
> > (not through the proxy) when the proxy opens a second TCP 
> stream connection
> > towards the server which implicitely tells the server to 
> send the RTP
> > packets to the proxy?
> > 
> > I think fig.2 in <draft-ietf-midcom-framework-03.txt> isn't 
> in harmony with
> > the statement above from the RTSP RFC.
> > 
> > Have I missed something?
> 
> The issue raised in rfc2326 would be between a client and and an RTSP
> proxy.  The midcom machinery is separate and wouldn't even 
> know there's
> an issue.
> 
> The midcom protocol has not been specified yet.  However, the general
> feeling is that it will be very simple.  An authorized agent will be
> able to request a middlebox to install packet matching and modifying
> rules, for example "let packets between X and Y to pass through".  The
> requirements on the midcom protocol, to the extent that they have been
> worked out, do not say anything about restricting which addresses or
> group of addresses can be in such a rule.
> 
> Similarly, there is nothing in the midcom protocol that would 
> require a
> middlebox to know about any relationship between agent and endpoint
> client.  Unless new requirements come up, the middlebox has 
> no reason or
> means to know which particular endpoint activity caused an agent to
> generate a particular ruleset request.  In fact the whole point of the
> Midcom WG is to remove such intelligence from the middlebox.
> 
> So, if there is an issue, it is with the RTSP proxy -- it needs to
> follow rfc2326 in deciding how it grants client requests.  Once those
> decisions are made, the requests it makes to the middlebox via the
> midcom protocol will fall out automatically.
> 
> ..Scott
> 

I agree that there is no issue regarding midcom in this scenario (the mb is
just doing what it is told via midcom), except I think the picture (fig.2)
in the framework draft is wrong. The RTP and RSTP data streams, opened by
the RTSP proxy via midcom, must be routed through the RTSP proxy because of
the statement in FRC2326 which I quoted below.
http://search.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt
ftp://ftp.isi.edu/in-notes/rfc2326.txt

// Johan

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 24 09:00:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03996
	for <midcom-archive@odin.ietf.org>; Fri, 24 Aug 2001 09:00:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27942;
	Fri, 24 Aug 2001 08:59:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27915
	for <midcom@ns.ietf.org>; Fri, 24 Aug 2001 08:59:32 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03923
	for <midcom@ietf.org>; Fri, 24 Aug 2001 08:58:14 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7OCv9J19208;
	Fri, 24 Aug 2001 05:57:09 -0700 (PDT)
Received: from cisco.com (sjc-vpn2-142.cisco.com [10.21.112.142])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAD04628;
	Fri, 24 Aug 2001 05:58:59 -0700 (PDT)
Received: by cisco.com (sSMTP sendmail emulation); Fri, 24 Aug 2001 08:59:01 -0400
Date: Fri, 24 Aug 2001 08:59:01 -0400
From: "'Scott Brim'" <sbrim@cisco.com>
To: Johan Gerhardsson <johan.gerhardsson@reddo.net>
Cc: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: Re: [midcom] Does midcom work with RTSP?
Message-ID: <20010824085901.D1096@SBRIM-W2K>
Mail-Followup-To: 'Scott Brim' <sbrim@cisco.com>,
	Johan Gerhardsson <johan.gerhardsson@reddo.net>,
	"'midcom@ietf.org'" <midcom@ietf.org>
References: <8346B686B0DBC1469AA5307F8BABBB3F01ABFD@WIN2K-SRV-001.reddo.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <8346B686B0DBC1469AA5307F8BABBB3F01ABFD@WIN2K-SRV-001.reddo.net>; from johan.gerhardsson@reddo.net on Fri, Aug 24, 2001 at 09:39:47AM +0200
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Suresh?

Johan Gerhardsson schrieb am Fri, Aug 24, 2001 09:39:47AM +0200:
> > -----Original Message-----
> > From: Scott Brim [mailto:sbrim@cisco.com]
> > Sent: Thursday, August 23, 2001 4:59 PM
> > To: Johan Gerhardsson
> > Cc: 'midcom@ietf.org'
> > Subject: Re: [midcom] Does midcom work with RTSP?
> > 
> > 
> > Johan Gerhardsson schrieb am Thu, Aug 23, 2001 04:31:06PM +0200:
> > > Hello all,
> > > 
> > > my name is Johan Gerhardsson, I'm thinking of a use case 
> > where a RTSP proxy
> > > "implements" midcom agent procuderes (i.e. a RTSP proxy 
> > uses midcom to do
> > > nat bindings and opens a pin-hole in a middlebox in order 
> > to let media
> > > through to an end-user application that is located in a 
> > private network).
> > > Question: Does RTSP really work with midcom?
> > > 
> > > RFC2326 (RTSP), page.59, general parameters: destination: 
> > "A server SHOULD
> > > not allow a client to direct media streams to an address 
> > that differs from
> > > the address commands are coming from." 
> > > I.e. the RTSP protocol recomend RTSP servers to NOT allow 
> > clients to specify
> > > an alternate IP address to receive media (e.g. RTP) other 
> > than what was used
> > > in the RTSP signalling (the TCP stream where RTSP is in use). 
> > > 
> > > How is it then possible to use midcom in order to open a 
> > pinhole through a
> > > middlebox that routes the RTP packets from the server 
> > directly to the client
> > > (not through the proxy) when the proxy opens a second TCP 
> > stream connection
> > > towards the server which implicitely tells the server to 
> > send the RTP
> > > packets to the proxy?
> > > 
> > > I think fig.2 in <draft-ietf-midcom-framework-03.txt> isn't 
> > in harmony with
> > > the statement above from the RTSP RFC.
> > > 
> > > Have I missed something?
> > 
> > The issue raised in rfc2326 would be between a client and and an RTSP
> > proxy.  The midcom machinery is separate and wouldn't even 
> > know there's
> > an issue.
> > 
> > The midcom protocol has not been specified yet.  However, the general
> > feeling is that it will be very simple.  An authorized agent will be
> > able to request a middlebox to install packet matching and modifying
> > rules, for example "let packets between X and Y to pass through".  The
> > requirements on the midcom protocol, to the extent that they have been
> > worked out, do not say anything about restricting which addresses or
> > group of addresses can be in such a rule.
> > 
> > Similarly, there is nothing in the midcom protocol that would 
> > require a
> > middlebox to know about any relationship between agent and endpoint
> > client.  Unless new requirements come up, the middlebox has 
> > no reason or
> > means to know which particular endpoint activity caused an agent to
> > generate a particular ruleset request.  In fact the whole point of the
> > Midcom WG is to remove such intelligence from the middlebox.
> > 
> > So, if there is an issue, it is with the RTSP proxy -- it needs to
> > follow rfc2326 in deciding how it grants client requests.  Once those
> > decisions are made, the requests it makes to the middlebox via the
> > midcom protocol will fall out automatically.
> > 
> > ..Scott
> > 
> 
> I agree that there is no issue regarding midcom in this scenario (the mb is
> just doing what it is told via midcom), except I think the picture (fig.2)
> in the framework draft is wrong. The RTP and RSTP data streams, opened by
> the RTSP proxy via midcom, must be routed through the RTSP proxy because of
> the statement in FRC2326 which I quoted below.
> http://search.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt
> ftp://ftp.isi.edu/in-notes/rfc2326.txt
> 
> // Johan

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 24 10:59:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06405
	for <midcom-archive@odin.ietf.org>; Fri, 24 Aug 2001 10:59:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01714;
	Fri, 24 Aug 2001 10:58:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01685
	for <midcom@ns.ietf.org>; Fri, 24 Aug 2001 10:58:07 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06364
	for <midcom@ietf.org>; Fri, 24 Aug 2001 10:56:48 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7OEtjJ10398;
	Fri, 24 Aug 2001 07:55:45 -0700 (PDT)
Received: from spandex.cisco.com (rtp-vpn-161.cisco.com [10.82.192.161])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id AAV00635;
	Fri, 24 Aug 2001 07:54:58 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010824105358.00a48270@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 Aug 2001 10:56:30 -0400
To: "Christian Huitema" <huitema@windows.microsoft.com>,
        "Sanjoy Sen" <sanjoy@nortelnetworks.com>, <midcom@ietf.org>
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [midcom] Delete R48?
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010418BF24@win-msg-02.wingroup
 .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 01:36 PM 8/23/01 -0700, Christian Huitema wrote:
>I think that we may want to keep some version of rule 48 -- possibly
>rewritten. When you open a pinhole through a firewall, it seems
>reasonable to inform the firewall of the stated purpose of the opening:
>a voice conversation, a video stream, a file transfer. 

This strikes me as something that belongs with other filter
rule elements describing the desired pinhole/mapping/whatever.
I think it's covered (implicitly) by the current text.  It seems
to me that a more interesting question might be how it fits
into the policy framework.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 24 11:53:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07777
	for <midcom-archive@odin.ietf.org>; Fri, 24 Aug 2001 11:53:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03618;
	Fri, 24 Aug 2001 11:45:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03587
	for <midcom@ns.ietf.org>; Fri, 24 Aug 2001 11:45:55 -0400 (EDT)
Received: from web14304.mail.yahoo.com (web14304.mail.yahoo.com [216.136.173.80])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07521
	for <midcom@ietf.org>; Fri, 24 Aug 2001 11:44:32 -0400 (EDT)
Message-ID: <20010824154551.16798.qmail@web14304.mail.yahoo.com>
Received: from [134.117.114.50] by web14304.mail.yahoo.com; Fri, 24 Aug 2001 11:45:51 EDT
Date: Fri, 24 Aug 2001 11:45:51 -0400 (EDT)
From: Abdallah Rayhan <ar_rayhan@yahoo.ca>
Subject: RE: [midcom] Delete R48?
To: midcom@ietf.org
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010418BF24@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This brings to mind the relationship between the midcom agent
and the policy server. I remember that being out of scope.
However, adding more hooks to convey policy information
that can be communicated indirectly to the the policy server
is one way around this. I am not in favor of such an approach 
but it is worth the the thought.

regards
Abdallah

--- Christian Huitema <huitema@windows.microsoft.com> wrote:
> Melinda,
> 
> I think that we may want to keep some version of rule 48 -- possibly
> rewritten. When you open a pinhole through a firewall, it seems
> reasonable to inform the firewall of the stated purpose of the
> opening:
> a voice conversation, a video stream, a file transfer. Stating it
> allows
> the firewall to check whether the opening conforms to policy, e.g.
> "no
> video calls during business hours"; it also allows the firewall, at a
> later stage, to check that the traffic profile is consistent with the
> stated purpose.
> 
> -- Christian Huitema
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 24 11:54:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07801
	for <midcom-archive@odin.ietf.org>; Fri, 24 Aug 2001 11:54:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03851;
	Fri, 24 Aug 2001 11:53:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03824
	for <midcom@ns.ietf.org>; Fri, 24 Aug 2001 11:53:11 -0400 (EDT)
Received: from web14307.mail.yahoo.com (web14307.mail.yahoo.com [216.136.173.83])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07739
	for <midcom@ietf.org>; Fri, 24 Aug 2001 11:51:52 -0400 (EDT)
Message-ID: <20010824155311.16963.qmail@web14307.mail.yahoo.com>
Received: from [134.117.114.50] by web14307.mail.yahoo.com; Fri, 24 Aug 2001 11:53:11 EDT
Date: Fri, 24 Aug 2001 11:53:11 -0400 (EDT)
From: Abdallah Rayhan <ar_rayhan@yahoo.ca>
Subject: Re: [midcom] Pinhole definition and attributes, not parameters and actions
To: midcom@ietf.org
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010418BF25@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

I second this email.

--- Christian Huitema <huitema@windows.microsoft.com> wrote:
> During the discussion of rule 48, we started speaking about rule
> parameters and actions. I think this is inappropriate, and would
> rather
> see us speak about rule "definition" and "attributes."
> 
> A rule "definition" is the set of parameter that defines the rule --
> i.e., exactly what we are going to study as part of the "filter
> specification." The basic idea here is that there can be only one
> rule
> for a given definition. An example of definition might be a five
> tuple.
> 
> The rule "attributes" is everything else, for example the NAT mapping
> associated to the five tupple, the time to live of the rule, maybe
> the
> expected "application profile" alluded to in R48. The MIDCOM protocol
> will allow MIDCOM agents to modify these attributes, under
> appropriate
> control.
> 
> -- Christian Huitema
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 24 13:56:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10955
	for <midcom-archive@odin.ietf.org>; Fri, 24 Aug 2001 13:56:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08274;
	Fri, 24 Aug 2001 13:53:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08246
	for <midcom@ns.ietf.org>; Fri, 24 Aug 2001 13:53:25 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10866
	for <midcom@ietf.org>; Fri, 24 Aug 2001 13:52:06 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7OHp1J12135
	for <midcom@ietf.org>; Fri, 24 Aug 2001 10:51:01 -0700 (PDT)
Received: from spandex.cisco.com (rtp-vpn-161.cisco.com [10.82.192.161])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id AAW02528;
	Fri, 24 Aug 2001 10:52:47 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010824135129.00a4be30@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 Aug 2001 13:53:35 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Topology submissions reminder
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a reminder that submissions for the topology "contest
of champions" are due next Friday, 31 August.  Submit via the
usual internet drafts mechanism and send a heads-up to the 
midcom mailing list.

Thanks,

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 14:04:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26099
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:04:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28545;
	Mon, 27 Aug 2001 13:59:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28516
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 13:59:51 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25982
	for <midcom@ietf.org>; Mon, 27 Aug 2001 13:58:28 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7RHxb615283
	for <midcom@ietf.org>; Mon, 27 Aug 2001 10:59:37 -0700 (PDT)
Received: from spandex.cisco.com (rtp-vpn-86.cisco.com [10.82.192.86])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABH07389;
	Mon, 27 Aug 2001 10:59:15 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010827135805.00a65ec0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Aug 2001 14:00:38 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Working the list, R5
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

R5 says "a middlebox MUST couple middlebox resources with midcom agents.

 This is from the framework draft, version -03: "'Coupling
          MIDCOM agents with the middlebox resources requires a means of
          reflecting that into the resource description table of the
          middlebox.'"


Dump or do?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 14:05:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26157
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:05:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29067;
	Mon, 27 Aug 2001 14:03:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29035
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 14:03:45 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26068
	for <midcom@ietf.org>; Mon, 27 Aug 2001 14:02:19 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7RI3L525334
	for <midcom@ietf.org>; Mon, 27 Aug 2001 11:03:21 -0700 (PDT)
Received: from spandex.cisco.com (rtp-vpn-86.cisco.com [10.82.192.86])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABH07507;
	Mon, 27 Aug 2001 11:01:21 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010827140120.00a696e0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 27 Aug 2001 14:02:23 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Working the list, R4
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

R4 says "Agents MUST be known to end system applications.

          This comes from the following text in the framework draft,
          version -03: 'In-Path MIDCOM agents are entities that have a
          native role in the path of the application traversal (with
          prior knowledge to one of the application end-hosts),
          independent of their MIDCOM function.'"

Keep?  Delete?

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 14:09:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26200
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:09:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29169;
	Mon, 27 Aug 2001 14:07:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29138
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 14:07:03 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26169
	for <midcom@ietf.org>; Mon, 27 Aug 2001 14:05:42 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7RI6h527976;
	Mon, 27 Aug 2001 11:06:43 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7RI6Vb29512;
	Mon, 27 Aug 2001 11:06:31 -0700 (PDT)
Message-ID: <3B8A8C3A.9FDF0876@cisco.com>
Date: Mon, 27 Aug 2001 11:06:50 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] Working the list, R5
References: <5.1.0.14.0.20010827135805.00a65ec0@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Melinda Shore wrote:
> 
> R5 says "a middlebox MUST couple middlebox resources with midcom agents.
> 
>  This is from the framework draft, version -03: "'Coupling
>           MIDCOM agents with the middlebox resources requires a means of
>           reflecting that into the resource description table of the
>           middlebox.'"
> 
> Dump or do?

dump!  see my previous email!
-
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 15:47:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28301
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 15:47:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01400;
	Mon, 27 Aug 2001 15:34:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01371
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 15:34:33 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28042
	for <midcom@ietf.org>; Mon, 27 Aug 2001 15:33:13 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RJXPX07380;
	Mon, 27 Aug 2001 12:33:25 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7RJXLp26024;
	Mon, 27 Aug 2001 12:33:21 -0700 (PDT)
Message-ID: <3B8AA093.363784C4@cisco.com>
Date: Mon, 27 Aug 2001 12:33:39 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] Working the list, R4
References: <5.1.0.14.0.20010827140120.00a696e0@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


> R4 says "Agents MUST be known to end system applications.
> 
>           This comes from the following text in the framework draft,
>           version -03: 'In-Path MIDCOM agents are entities that have a
>           native role in the path of the application traversal (with
>           prior knowledge to one of the application end-hosts),
>           independent of their MIDCOM function.'"
> 

If the protocol is between the agent and the middle box, this statement is
beyond the scope of the requirements document, since we are not discussing
communication requirements between the agent and the application. 
Besides, it borders on a non-protocol requirement in any event.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 15:56:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28490
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 15:56:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01734;
	Mon, 27 Aug 2001 15:47:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01701
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 15:47:17 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28259
	for <midcom@ietf.org>; Mon, 27 Aug 2001 15:45:52 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA15812
	for <midcom@ietf.org>; Mon, 27 Aug 2001 14:46:42 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Mon, 27 Aug 2001 14:46:20 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RKKY1XQ7>; Mon, 27 Aug 2001 12:45:21 -0700
Message-ID: <A7895B732354D311A4770008C791841A0146B3FD@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'lear@cisco.com'" <lear@cisco.com>, "'Melinda Shore'" <mshore@cisco.com>
Cc: "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Working the list, R4
Date: Mon, 27 Aug 2001 12:45:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12F30.CD71D690"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12F30.CD71D690
Content-Type: text/plain;
	charset="iso-8859-1"

I second Eliot's last two emails.

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Monday, August 27, 2001 12:34 PM
> To: Melinda Shore
> Cc: midcom@ietf.org
> Subject: Re: [midcom] Working the list, R4
> 
> 
> 
> > R4 says "Agents MUST be known to end system applications.
> > 
> >           This comes from the following text in the framework draft,
> >           version -03: 'In-Path MIDCOM agents are entities 
> that have a
> >           native role in the path of the application traversal (with
> >           prior knowledge to one of the application end-hosts),
> >           independent of their MIDCOM function.'"
> > 
> 
> If the protocol is between the agent and the middle box, this 
> statement is
> beyond the scope of the requirements document, since we are 
> not discussing
> communication requirements between the agent and the application. 
> Besides, it borders on a non-protocol requirement in any event.
> --
> Eliot Lear
> lear@cisco.com
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C12F30.CD71D690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Working the list, R4</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I second Eliot's last two emails.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Eliot Lear [<A =
HREF=3D"mailto:lear@cisco.com">mailto:lear@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, August 27, 2001 12:34 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Melinda Shore</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [midcom] Working the list, =
R4</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; R4 says &quot;Agents MUST be known to end =
system applications.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
comes from the following text in the framework draft,</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
version -03: 'In-Path MIDCOM agents are entities </FONT>
<BR><FONT SIZE=3D2>&gt; that have a</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; native =
role in the path of the application traversal (with</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; prior =
knowledge to one of the application end-hosts),</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
independent of their MIDCOM function.'&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the protocol is between the agent and the =
middle box, this </FONT>
<BR><FONT SIZE=3D2>&gt; statement is</FONT>
<BR><FONT SIZE=3D2>&gt; beyond the scope of the requirements document, =
since we are </FONT>
<BR><FONT SIZE=3D2>&gt; not discussing</FONT>
<BR><FONT SIZE=3D2>&gt; communication requirements between the agent =
and the application. </FONT>
<BR><FONT SIZE=3D2>&gt; Besides, it borders on a non-protocol =
requirement in any event.</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Eliot Lear</FONT>
<BR><FONT SIZE=3D2>&gt; lear@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12F30.CD71D690--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 17:07:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00462
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 17:07:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03839;
	Mon, 27 Aug 2001 16:45:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03813
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 16:45:13 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29560
	for <midcom@ietf.org>; Mon, 27 Aug 2001 16:43:53 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A0B3F2400136; Mon, 27 Aug 2001 16:42:27 -0400
Message-ID: <001501c12f38$f22b90e0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <lear@cisco.com>, "Melinda Shore" <mshore@cisco.com>
Cc: <midcom@ietf.org>
References: <5.1.0.14.0.20010827140120.00a696e0@mira-sjc5-4.cisco.com> <3B8AA093.363784C4@cisco.com>
Subject: Re: [midcom] Working the list, R4
Date: Mon, 27 Aug 2001 16:41:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Eliot Lear" <lear@cisco.com>
To: "Melinda Shore" <mshore@cisco.com>
Cc: <midcom@ietf.org>
Sent: Monday, August 27, 2001 3:33 PM
Subject: Re: [midcom] Working the list, R4


>
> > R4 says "Agents MUST be known to end system applications.
> >
> >           This comes from the following text in the framework draft,
> >           version -03: 'In-Path MIDCOM agents are entities that have a
> >           native role in the path of the application traversal (with
> >           prior knowledge to one of the application end-hosts),
> >           independent of their MIDCOM function.'"
> >
>

The phrase "with prior knowledge to one of the application end-hosts" has
already been removed from Suresh's interim version 4 of the framework draft.
I think we can safely remove it.

> If the protocol is between the agent and the middle box, this statement is
> beyond the scope of the requirements document, since we are not discussing
> communication requirements between the agent and the application.
> Besides, it borders on a non-protocol requirement in any event.
> --
> Eliot Lear
> lear@cisco.com
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 17:08:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00548
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 17:08:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04172;
	Mon, 27 Aug 2001 16:57:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04143
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 16:57:08 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00120
	for <midcom@ietf.org>; Mon, 27 Aug 2001 16:55:48 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A381FF3D0126; Mon, 27 Aug 2001 16:54:25 -0400
Message-ID: <003d01c12f3a$9d2c0140$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "midcom mail-list" <midcom@ietf.org>
References: <20010821151025.G1604@SBRIM-W2K>
Subject:  [midcom] more requirements deletions
Date: Mon, 27 Aug 2001 16:55:33 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,

I have a few more items I think we ought to consider removing or combining.

R23: Isn't this marketing? or just plain motherhood & apple pie?

R75: I'm not sure exactly what this means, but it sounds like a requirement
on the middlebox and the midcom agents to figure out that the routing has
changed and make necessary changes to existing pin-hole rules. How does this
affect the protocol? I propose we remove this requirement.

R45: Does anybody know what this means? It should be clarified or deleted.

R39+R63: These 2 need to be combined since they are basically talking about
response codes. The initial phrase in R63 "To enable management systems to
interact with the Midcom environment" is not needed. The real reason for
useful failure codes is to allow the midcom agent to do something reasonable
in response to the failure.

R68: Do we have new text for this yet?

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Mon Aug 27 18:30:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03108
	for <midcom-archive@odin.ietf.org>; Mon, 27 Aug 2001 18:30:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07911;
	Mon, 27 Aug 2001 18:11:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07862
	for <midcom@ns.ietf.org>; Mon, 27 Aug 2001 18:11:01 -0400 (EDT)
Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02192
	for <midcom@ietf.org>; Mon, 27 Aug 2001 18:09:40 -0400 (EDT)
Received: from 157.54.9.108 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Aug 2001 15:10:17 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 27 Aug 2001 15:10:15 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 27 Aug 2001 15:10:15 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 27 Aug 2001 15:09:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [midcom] Working the list, R4
Date: Mon, 27 Aug 2001 15:09:55 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C90104A3E6E0@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [midcom] Working the list, R4
Thread-Index: AcEvM4kYd1ENjSmASZOfybxyNGakswAEXIrQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>, <lear@cisco.com>,
        "Melinda Shore" <mshore@cisco.com>
Cc: <midcom@ietf.org>
X-OriginalArrivalTime: 27 Aug 2001 22:09:55.0753 (UTC) FILETIME=[00E7E190:01C12F45]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA07866
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

Ditto. Dump R4 & R5.

-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] 
Sent: Monday, August 27, 2001 12:45 PM
To: 'lear@cisco.com'; 'Melinda Shore'
Cc: 'midcom@ietf.org'
Subject: RE: [midcom] Working the list, R4

I second Eliot's last two emails. 
 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 12:18:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14430
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 12:18:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18010;
	Tue, 28 Aug 2001 12:14:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17980
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 12:14:18 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14253
	for <midcom@ietf.org>; Tue, 28 Aug 2001 12:12:58 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7SGDng21717
	for <midcom@ietf.org>; Tue, 28 Aug 2001 17:13:49 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Tue, 28 Aug 2001 17:13:19 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <R3T0C7BJ>;
          Tue, 28 Aug 2001 17:13:14 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C304451FD@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        lear <lear@cisco.com>, Melinda Shore <mshore@cisco.com>
Cc: midcom <midcom@ietf.org>
Subject: RE: [midcom] Working the list, R4
Date: Tue, 28 Aug 2001 17:13:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12FDC.5FD6AE60"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12FDC.5FD6AE60
Content-Type: text/plain;
	charset="iso-8859-1"

I second this as well.
I thought we agreed on R4 deletion back on August 10th during the WG session

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.microsoft.com]
Sent: Tuesday, August 28, 2001 12:10 AM
To: Penno, Reinaldo [SC9:T327:EXCH]; lear; Melinda Shore
Cc: midcom
Subject: RE: [midcom] Working the list, R4


Ditto. Dump R4 & R5.

-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] 
Sent: Monday, August 27, 2001 12:45 PM
To: 'lear@cisco.com'; 'Melinda Shore'
Cc: 'midcom@ietf.org'
Subject: RE: [midcom] Working the list, R4

I second Eliot's last two emails. 
 

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C12FDC.5FD6AE60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Working the list, R4</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I second this as well.</FONT>
<BR><FONT SIZE=3D2>I thought we agreed on R4 deletion back on August =
10th during the WG session</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Huitema [<A =
HREF=3D"mailto:huitema@windows.microsoft.com">mailto:huitema@windows.mic=
rosoft.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, August 28, 2001 12:10 AM</FONT>
<BR><FONT SIZE=3D2>To: Penno, Reinaldo [SC9:T327:EXCH]; lear; Melinda =
Shore</FONT>
<BR><FONT SIZE=3D2>Cc: midcom</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [midcom] Working the list, R4</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Ditto. Dump R4 &amp; R5.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Reinaldo Penno [<A =
HREF=3D"mailto:reinaldo_penno@nortelnetworks.com">mailto:reinaldo_penno@=
nortelnetworks.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 27, 2001 12:45 PM</FONT>
<BR><FONT SIZE=3D2>To: 'lear@cisco.com'; 'Melinda Shore'</FONT>
<BR><FONT SIZE=3D2>Cc: 'midcom@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [midcom] Working the list, R4</FONT>
</P>

<P><FONT SIZE=3D2>I second Eliot's last two emails. </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12FDC.5FD6AE60--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 14:57:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18657
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 14:57:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22105;
	Tue, 28 Aug 2001 14:55:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22076
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 14:55:24 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18577
	for <midcom@ietf.org>; Tue, 28 Aug 2001 14:54:04 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7SItCH10109
	for <midcom@ietf.org>; Tue, 28 Aug 2001 11:55:12 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp155.cisco.com [10.21.64.155])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABJ20246;
	Tue, 28 Aug 2001 11:53:05 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010828145331.00a22dd0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 28 Aug 2001 14:54:37 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Deleting R4 and R5
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

So far it's looking like we have consensus to delete both
R4 and R5.  Objectors, if there are any, need to speak up 
post-haste.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 15:01:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18734
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 15:01:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22486;
	Tue, 28 Aug 2001 15:00:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22447
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 15:00:40 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18695
	for <midcom@ietf.org>; Tue, 28 Aug 2001 14:59:20 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7SIw2V08959
	for <midcom@ietf.org>; Tue, 28 Aug 2001 11:58:12 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn1-132.cisco.com [10.21.96.132])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAL05146;
	Tue, 28 Aug 2001 11:59:54 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 28 Aug 2001 14:59:59 -0400
Date: Tue, 28 Aug 2001 14:59:59 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] Working the list, R5
Message-ID: <20010828145959.B1176@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <5.1.0.14.0.20010827135805.00a65ec0@mira-sjc5-4.cisco.com> <3B8A8C3A.9FDF0876@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B8A8C3A.9FDF0876@cisco.com>; from lear@cisco.com on Mon, Aug 27, 2001 at 11:06:50AM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

When will we know when consensus is achieved on this?

Eliot Lear schrieb am Mon, Aug 27, 2001 11:06:50AM -0700:
> 
> 
> Melinda Shore wrote:
> > 
> > R5 says "a middlebox MUST couple middlebox resources with midcom agents.
> > 
> >  This is from the framework draft, version -03: "'Coupling
> >           MIDCOM agents with the middlebox resources requires a means of
> >           reflecting that into the resource description table of the
> >           middlebox.'"
> > 
> > Dump or do?
> 
> dump!  see my previous email!
> -
> Eliot Lear
> lear@cisco.com
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 15:06:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18907
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 15:06:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22662;
	Tue, 28 Aug 2001 15:05:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22631
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 15:05:08 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18798
	for <midcom@ietf.org>; Tue, 28 Aug 2001 15:03:49 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7SJ2gV11763;
	Tue, 28 Aug 2001 12:02:45 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp155.cisco.com [10.21.64.155])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABJ20773;
	Tue, 28 Aug 2001 12:03:51 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010828150510.00a270c0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 28 Aug 2001 15:05:25 -0400
To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Working the list, R5
In-Reply-To: <20010828145959.B1176@SBRIM-W2K>
References: <3B8A8C3A.9FDF0876@cisco.com>
 <5.1.0.14.0.20010827135805.00a65ec0@mira-sjc5-4.cisco.com>
 <3B8A8C3A.9FDF0876@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 02:59 PM 8/28/01 -0400, Scott Brim wrote:
>When will we know when consensus is achieved on this?

By tomorrow.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 15:16:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19141
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 15:16:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22861;
	Tue, 28 Aug 2001 15:11:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22831
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 15:11:31 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18998
	for <midcom@ietf.org>; Tue, 28 Aug 2001 15:10:11 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7SJB6l25772
	for <midcom@ietf.org>; Tue, 28 Aug 2001 12:11:06 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp155.cisco.com [10.21.64.155])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABJ21159;
	Tue, 28 Aug 2001 12:10:56 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010828151206.00a27220@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 28 Aug 2001 15:12:29 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] My bad
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

R4 has already been deleted.  R5 is still open, however, and
we need to get it closed.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 15:17:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19176
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 15:17:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23016;
	Tue, 28 Aug 2001 15:16:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22989
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 15:16:42 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19099
	for <midcom@ietf.org>; Tue, 28 Aug 2001 15:15:22 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7SJGMN25936
	for <midcom@ietf.org>; Tue, 28 Aug 2001 12:16:22 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn1-132.cisco.com [10.21.96.132])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAM00143;
	Tue, 28 Aug 2001 12:16:07 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 28 Aug 2001 15:16:12 -0400
Date: Tue, 28 Aug 2001 15:16:12 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom mail-list <midcom@ietf.org>
Subject: Re: [midcom] more requirements deletions
Message-ID: <20010828151612.C1176@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>,
	midcom mail-list <midcom@ietf.org>
References: <20010821151025.G1604@SBRIM-W2K> <003d01c12f3a$9d2c0140$2300000a@acmepacket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <003d01c12f3a$9d2c0140$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Mon, Aug 27, 2001 at 04:55:33PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Bob Penfield schrieb am Mon, Aug 27, 2001 04:55:33PM -0400:
> R23: Isn't this marketing? or just plain motherhood & apple pie?

Disagree.  This was to make sure the state stayed synchronized, partly
as a generalization of the idea that when an agent is de-authorized all
pinholes created by it should be closed.  I like this one.  It answers
the protocol design question of just how state synchronization you need
-- not much.

> R75: I'm not sure exactly what this means, but it sounds like a
> requirement on the middlebox and the midcom agents to figure out that
> the routing has changed and make necessary changes to existing
> pin-hole rules. How does this affect the protocol? I propose we remove
> this requirement.

Agreed, kill.  It's an important question about state and multiple
middleboxes, but I don't how the answer will affect the protocol itself.

> R45: Does anybody know what this means? It should be clarified or
> deleted.

Agreed, kill. 

> R39+R63: These 2 need to be combined since they are basically talking
> about response codes. The initial phrase in R63 "To enable management
> systems to interact with the Midcom environment" is not needed. The
> real reason for useful failure codes is to allow the midcom agent to
> do something reasonable in response to the failure.

Agreed: kill R39, keep R63, take out first bit of text.

> R68: Do we have new text for this yet?

I suggest we kill it and let Richard or anyone submit new if they wish.

My 2 cents ... Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 15:19:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19220
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 15:19:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22978;
	Tue, 28 Aug 2001 15:16:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22928
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 15:15:36 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19086
	for <midcom@ietf.org>; Tue, 28 Aug 2001 15:14:16 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7SJF7l28964
	for <midcom@ietf.org>; Tue, 28 Aug 2001 12:15:07 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp155.cisco.com [10.21.64.155])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABJ21340;
	Tue, 28 Aug 2001 12:14:54 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010828151305.00a21590@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 28 Aug 2001 15:16:27 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] R79/80
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Next question:

R79/80 - kill or keep?  It's related to the question of ownership
but isn't the same.  R79 says:

"If a particular ruleset is created multiple times, it must be
deleted the same number of times"

and R80 says:

"If two rulesets overlap, and one is deleted, the overlapping
area must not be deleted until the other is deleted."

If we keep R80 we need to do something about defining "overlap."
I believe that it's not currently addressed elsewhere in our documents.

Melinda



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 16:13:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20328
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 16:13:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24979;
	Tue, 28 Aug 2001 16:11:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24902
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 16:11:42 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20215
	for <midcom@ietf.org>; Tue, 28 Aug 2001 16:10:21 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7SKBCl16663;
	Tue, 28 Aug 2001 13:11:12 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7SKBBt20058;
	Tue, 28 Aug 2001 13:11:12 -0700 (PDT)
Message-ID: <3B8BFADE.96E490FD@cisco.com>
Date: Tue, 28 Aug 2001 13:11:10 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Melinda Shore <mshore@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] R79/80
References: <5.1.0.14.0.20010828151305.00a21590@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


Melinda Shore wrote:
> 
> Next question:
> 
> R79/80 - kill or keep?  It's related to the question of ownership
> but isn't the same.  R79 says:
> 
> "If a particular ruleset is created multiple times, it must be
> deleted the same number of times"

Dump.  See previous Email.

> and R80 says:
> 
> "If two rulesets overlap, and one is deleted, the overlapping
> area must not be deleted until the other is deleted."

Why should it be anything other than an error to have overlapping rule
sets in the first place?  We may instead have to mention something about
race conditions when changing allocations/reservations.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 16:35:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAB20786
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 16:35:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25726;
	Tue, 28 Aug 2001 16:34:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25699
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 16:34:50 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20759
	for <midcom@ietf.org>; Tue, 28 Aug 2001 16:33:29 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7SKV6V28828
	for <midcom@ietf.org>; Tue, 28 Aug 2001 13:32:21 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn1-63.cisco.com [10.21.96.63])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAM01575;
	Tue, 28 Aug 2001 13:32:58 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 28 Aug 2001 16:32:57 -0400
Date: Tue, 28 Aug 2001 16:32:57 -0400
From: Scott Brim <sbrim@cisco.com>
To: midcom@ietf.org
Subject: Re: [midcom] R79/80
Message-ID: <20010828163257.A1376@SBRIM-W2K>
Mail-Followup-To: Scott Brim <sbrim@cisco.com>, midcom@ietf.org
References: <5.1.0.14.0.20010828151305.00a21590@mira-sjc5-4.cisco.com> <3B8BFADE.96E490FD@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B8BFADE.96E490FD@cisco.com>; from lear@cisco.com on Tue, Aug 28, 2001 at 01:11:10PM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Eliot Lear schrieb am Tue, Aug 28, 2001 01:11:10PM -0700:
> Melinda Shore wrote:
> > 
> > Next question:
> > 
> > R79/80 - kill or keep?  It's related to the question of ownership
> > but isn't the same.  R79 says:
> > 
> > "If a particular ruleset is created multiple times, it must be
> > deleted the same number of times"
> 
> Dump.  See previous Email.

Eliot, could you repeat the opinion in the previous Email?  I don't know
which message you're referring to.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 16:50:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21107
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 16:50:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25943;
	Tue, 28 Aug 2001 16:45:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25916
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 16:45:44 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21005
	for <midcom@ietf.org>; Tue, 28 Aug 2001 16:44:23 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id NAA26140;
	Tue, 28 Aug 2001 13:45:40 -0700 (PDT)
Message-Id: <200108282045.NAA26140@nemo.corp.equinix.com>
Subject: Re: [midcom] R79/80
To: mshore@cisco.com (Melinda Shore)
Date: Tue, 28 Aug 2001 13:45:40 -0700 (PDT)
Cc: midcom@ietf.org
In-Reply-To: <5.1.0.14.0.20010828151305.00a21590@mira-sjc5-4.cisco.com> from "Melinda Shore" at Aug 28, 2001 03:16:27 PM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> and R80 says:
> 
> "If two rulesets overlap, and one is deleted, the overlapping
> area must not be deleted until the other is deleted."
> 
> If we keep R80 we need to do something about defining "overlap."
> I believe that it's not currently addressed elsewhere in our documents.
> 
> Melinda


I had been assuming that the ruleset overlap related to CIDR block
overlap, but can I see that there might be other issues.  To use the
CIDR block example, let's assume that we get an pinhole request that
says:

allow from 128.102.33.5/32

then a covering request:

allow from 128.102.33/24

If you delete:

allow from 128.102.33/24

should 

allow from 128.102.33.5/32

also go away?  I would say it should not.  

The worse problem here relates to ruleset discovery and the crafting
of behaviors based on dependency on multiple rules, but since that
falls into the discovery bin I believe it to be out of scope for
this discussion.

			regards,
				Ted Hardie

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 17:04:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21492
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 17:04:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26759;
	Tue, 28 Aug 2001 17:02:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26731
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 17:02:46 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21423
	for <midcom@ietf.org>; Tue, 28 Aug 2001 17:01:25 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7SL2QN08721;
	Tue, 28 Aug 2001 14:02:27 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7SL2DE00372;
	Tue, 28 Aug 2001 14:02:13 -0700 (PDT)
Message-ID: <3B8C06D3.DE6CCFC6@cisco.com>
Date: Tue, 28 Aug 2001 14:02:11 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hardie@equinix.com
CC: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] R79/80
References: <200108282045.NAA26140@nemo.corp.equinix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi Ted!

> allow from 128.102.33.5/32
> 
> then a covering request:
> 
> allow from 128.102.33/24

Why is this NOT an error?
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 17:25:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21817
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 17:24:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27294;
	Tue, 28 Aug 2001 17:24:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27267
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 17:24:43 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAB21784
	for <midcom@ietf.org>; Tue, 28 Aug 2001 17:23:22 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id OAA27494;
	Tue, 28 Aug 2001 14:24:41 -0700 (PDT)
Message-Id: <200108282124.OAA27494@nemo.corp.equinix.com>
Subject: Re: [midcom] R79/80
To: lear@cisco.com
Date: Tue, 28 Aug 2001 14:24:41 -0700 (PDT)
Cc: hardie@equinix.com, mshore@cisco.com (Melinda Shore), midcom@ietf.org
In-Reply-To: <3B8C06D3.DE6CCFC6@cisco.com> from "Eliot Lear" at Aug 28, 2001 02:02:11 PM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi Eliot,

The covering request isn't necessarily from the same agent; I was
representing what the request would look like to the MIDCOM box.  

For the second agent to re-write its request not to cover the original
request /32, it would have to know about the /32 pinhole and decide
whether its request should or shouldn't over-ride.  If it does have
to construct its request to avoid the 128.102.33.5/32,it's going to
have to keep state about the same rule applying to plural bit boundaries
(the 128.102.33.0/30 and whatever hash it makes for the 128.102.33.6+).
That seems icky.  

Perhaps the underlying question is whether the operation is "Delete
rule 'allow from 128.102.33/24'" or "deny from 128.102.33/24".  I
would agree that if a midcom box got "deny from 128.102.33/24" it
should delete all rules that allowed from that range.  If it gets a
"delete rule 'allow from 128.102.33/24'" (or that rule expired), then
I believe the other rule should remain valid.
		regards,

				Ted

> 
> Hi Ted!
> 
> > allow from 128.102.33.5/32
> > 
> > then a covering request:
> > 
> > allow from 128.102.33/24
> 
> Why is this NOT an error?
> --
> Eliot Lear
> lear@cisco.com
> 


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 17:25:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21831
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 17:25:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27207;
	Tue, 28 Aug 2001 17:20:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27178
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 17:20:06 -0400 (EDT)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21735
	for <midcom@ietf.org>; Tue, 28 Aug 2001 17:18:45 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f7SLJN903436
	for <midcom@ietf.org>; Tue, 28 Aug 2001 17:19:24 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f7SLJNQ03427
	for <midcom@ietf.org>; Tue, 28 Aug 2001 17:19:23 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [midcom] R79/80
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Tue, 28 Aug 2001 15:20:20 -0600
Message-ID: <EF4C65F18BE6464B8E9DF3C212B6B293BE6271@cof110avexu1.global.avaya.com>
Thread-Topic: [midcom] R79/80
Thread-Index: AcEwBOn3qrc8775DRe6DVOVGvsyxiQAAUepg
From: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>
To: <lear@cisco.com>, <hardie@equinix.com>
Cc: "Melinda Shore" <mshore@cisco.com>, <midcom@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA27179
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

>> allow from 128.102.33.5/32
>> 
>> then a covering request:
>> 
>> allow from 128.102.33/24
>
> Why is this NOT an error?

Routers face this problem regularly without error; they match against
the most specific mask in the presence of mask overlap. Can that type
logic work within a middlebox generally to resolve this?

--Andy Zmolek 
   Technology & Standards Engineer 
    CTO Standards 
      Avaya Inc. 
         zmolek@avaya.com 
          +1 720 444 4001 




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 17:44:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22127
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 17:44:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28278;
	Tue, 28 Aug 2001 17:44:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28246
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 17:44:02 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22110
	for <midcom@ietf.org>; Tue, 28 Aug 2001 17:42:42 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7SLhmH25090;
	Tue, 28 Aug 2001 14:43:49 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7SLhTj01553;
	Tue, 28 Aug 2001 14:43:29 -0700 (PDT)
Message-ID: <3B8C107F.534F84E4@cisco.com>
Date: Tue, 28 Aug 2001 14:43:27 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hardie@equinix.com
CC: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] R79/80
References: <200108282124.OAA27494@nemo.corp.equinix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Ted,
> The covering request isn't necessarily from the same agent; I was
> representing what the request would look like to the MIDCOM box.

Understood.  The error doesn't necessarily need to be a logic error, but
more of a 4xx-like error because someone else has already grabbed the
resource.  If a pinhole is being opened on behalf of an application on an
end host, the application is working in concert with the the midcom agent.

In the case where the request is simply superfluous because firewall
policy already allows the ports through or because someone has already
authorized the access, that other somebody is responsible for monitoring
and closing the hole.  So return an error indicating such.

Perhaps the concern is that a wildcard has been opened by one application
when another application is planning to use a more specific pinhole?  I
would need to see an example of this.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 18:23:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22717
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 18:23:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29418;
	Tue, 28 Aug 2001 18:20:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29391
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 18:20:48 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22665
	for <midcom@ietf.org>; Tue, 28 Aug 2001 18:19:28 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id PAA29591;
	Tue, 28 Aug 2001 15:20:43 -0700 (PDT)
Message-Id: <200108282220.PAA29591@nemo.corp.equinix.com>
Subject: Re: [midcom] R79/80
To: lear@cisco.com
Date: Tue, 28 Aug 2001 15:20:43 -0700 (PDT)
Cc: hardie@equinix.com, mshore@cisco.com (Melinda Shore), midcom@ietf.org
In-Reply-To: <3B8C107F.534F84E4@cisco.com> from "Eliot Lear" at Aug 28, 2001 02:43:27 PM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


> Understood.  The error doesn't necessarily need to be a logic error, but
> more of a 4xx-like error because someone else has already grabbed the
> resource.  If a pinhole is being opened on behalf of an application on an
> end host, the application is working in concert with the the midcom agent.
> 
> In the case where the request is simply superfluous because firewall
> policy already allows the ports through or because someone has already
> authorized the access, that other somebody is responsible for monitoring
> and closing the hole.  So return an error indicating such.

I think I'm lost in somebodies.  Let's imagine a case where
application A asks Midcom Agent Z for a pinhole, and Midcom Agent 
Z says to Midcom Box M:

Open pinhole 128.102.33.5/32

then Application B asks Midcom Agent W for a hole, and
Midcom Agent W say to Midcom Box M:

Open hole 128.102.33/24

Do you believe the M should send an error to Agent W noting that
128.102.33.5/24 is already open and reserved?

	If so, does Agent W then send some combination of CIDR blocks
	that excludes that /32 to request the other part of the /24?
	
		Doesn't that mean that when Midcom Agent Z withdraws
		its rule (or it expires) that Agent W hasn't accomplished
		what Application B requested?  If so, should it error
		to Application B at the start?

As I said, my view is that covering rules should be allowed and should
expire/be withdrawn independently, but that a new rule denying access
should override both matching rules and any rules they cover.

This does mean we require different behavior for "Withdraw 'allow from
128.102.33/24'" and "Deny from 128.102.33/24", but I think that's okay.
			regards,
				Ted




> 
> Perhaps the concern is that a wildcard has been opened by one application
> when another application is planning to use a more specific pinhole?  I
> would need to see an example of this.
> --
> Eliot Lear
> lear@cisco.com
> 


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 19:11:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23343
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 19:10:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00672;
	Tue, 28 Aug 2001 19:08:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00645
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 19:07:59 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23272
	for <midcom@ietf.org>; Tue, 28 Aug 2001 19:06:40 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7SN7mH24729;
	Tue, 28 Aug 2001 16:07:48 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7SN7TC27114;
	Tue, 28 Aug 2001 16:07:29 -0700 (PDT)
Message-ID: <3B8C242F.C7991A7@cisco.com>
Date: Tue, 28 Aug 2001 16:07:27 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hardie@equinix.com
CC: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] R79/80
References: <200108282220.PAA29591@nemo.corp.equinix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit



Ted wrote:

> I think I'm lost in somebodies.  Let's imagine a case where
> application A asks Midcom Agent Z for a pinhole, and Midcom Agent
> Z says to Midcom Box M:
> 
> Open pinhole 128.102.33.5/32
> 
> then Application B asks Midcom Agent W for a hole, and
> Midcom Agent W say to Midcom Box M:
> 
> Open hole 128.102.33/24

Let me more fully specify this example:

Z -> M: open pinhole("internal" address 128.102.33.5/32,port *,
                     "external" address *, port *, tcp)

W -> M: open pinhole("internal" address 128.102.33.0/24,port *,
                     "external" address *, port *, tcp)

> Do you believe the M should send an error to Agent W noting that
> 128.102.33.5/24 is already open and reserved?

Not quite.  I believe M should send an error to W saying that it is unable
to perform the request due to a conflict.

>         If so, does Agent W then send some combination of CIDR blocks
>         that excludes that /32 to request the other part of the /24?

Application specific.

By the way, the more interesting case is if this happens in reverse
order.  Suppose an application requests a pinhole for a subset of a range
that is already opened.  I would still return an error.

What's going on that a MIDCOM agent would make such a wildcard request as
described above?  It's not helping an application at that point.  It's
essentially granting any access to a host.  Big difference.  So what if a
port were mentioned in each request?  That way one could argue that MIDCOM
is now helping the application.  Well if that's the case, while it's not
reasonable to expect midcom agents for two completely different
applications to coordinate, it is quite reasonable to expect two midcom
agents for the SAME application to coordinate.

> This does mean we require different behavior for "Withdraw 'allow from
> 128.102.33/24'" and "Deny from 128.102.33/24", but I think that's okay.

Hold the phone on this one.  Let's come back to it.

Regards,

Eliot

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Tue Aug 28 20:29:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24521
	for <midcom-archive@odin.ietf.org>; Tue, 28 Aug 2001 20:29:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04007;
	Tue, 28 Aug 2001 20:27:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03942
	for <midcom@ns.ietf.org>; Tue, 28 Aug 2001 20:27:41 -0400 (EDT)
Received: from market0 ([208.158.105.111])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24477
	for <midcom@ietf.org>; Tue, 28 Aug 2001 20:26:22 -0400 (EDT)
From: promotion@market.gogocity.com
Received: from mail pickup service by market0 with Microsoft SMTPSVC;
	 Tue, 28 Aug 2001 17:24:22 -0700
To: <midcom@ietf.org>
Date: Tue, 28 Aug 2001 17:24:22 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_BB8B0_01C12FE6.47186850"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <MARKET0QXwEeN7h0web0002ee9d@market0>
X-OriginalArrivalTime: 29 Aug 2001 00:24:22.0685 (UTC) FILETIME=[F395C4D0:01C13020]
Subject: [midcom] ADV: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_BB8B0_01C12FE6.47186850
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

 
<http://www.gogocity.com//searchresults.asp?department=5031&parent%5Fid=
5>
<http://www.gogocity.com//searchresults.asp?department=5031&parent%5Fid=
5> 
Big Saving from GoGoCity. If you'd rather not receive any future
promotional E-mails from GoGoCity.com, 
please click --> Un-Subscribe My E-mai
<http://www.gogocity.com/ggc_unsubscribe.asp>  l
<http://www.gogocity.com/ggc_unsubscribe.asp> 
International Order Welcome FREE SHIPPING NOT APPLY 

Cell Phone Accessories
Blow out Sale...!!
Save Up to 80%...!! 
***** FREE SHIPPING (in US only) *****
Why pay more in Retail Store..???


1. Antenna Booster for All Cell Phone (1pack)	 9. Antenna Booster for
All Cell Phone (5 pack)	 
Antenna Booster for All Cell Phone (1pack)
large image
<http://www.gogocity.com//product_details.asp?dept_id=5031&pf_id=OS01AB>

Retail Price: $19.95
Blow Out Price: $5.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB> 
	
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K> Antenna Booster for All Cell Phone (5 pack)
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB5PACK> 
Retail Price: $99.75
Blow Out Price: $19.95 (save 80%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB5PACK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept_id=5031&pf_id=OS01AB>

2. NOKIA 51xx/6xx Black Car Charger	 10. Nokia 3310/3390 Data Cable

NOKIA 51xx/6xx Black Car Charger
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K> 
Retail Price: $19.99
Blow Out Price: $5.49 (save 73%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K> 
	Nokia 82xx/33xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN331090K> 
Retail Price: $79.99
Blow Out Price: $19.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN331090K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K> 	 
3. NOKIA 82xx/33xx Black Car Charger
	11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib
Battery 	
NOKIA 82xx/33xx Black Car Charger
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K> 
Retail Price: $19.99
Blow Out Price: $5.49 (save 73%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K> 
	Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV> 
Retail Price: $65.99
Blow Out Price: $24.95 (save 62%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV> 	 
4. NOKIA 51xx/61xx Hands Free with on/off Switch	 12. NOKIA
51xx/6xx Data Cable	 
NOKIA 51xx/61xx Hands Free with on/off Switch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK> 
Retail Price: $19.99
Blow Out Price: $5.99 (save 70%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK> 
	NOKIA 51xx/6xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K> 
Retail Price: $69.99
Blow Out Price: $14.95 (save 79%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K> 	 
5. NOKIA 82xx/33xx Hands Free with on/off Switch	 13. Nokia
8260/8290 Li-ion 1200mAh Vibrating Battery	 
NOKIA 82xx/33xx Hands Free with on/off Switch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK> 
Retail Price: $19.99
Blow Out Price: $5.99 (save 70%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK> 
	Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V> 
Retail Price: $45.99
Blow Out Price: $24.95 (save 46%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V> 	 
6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery	 14.Nokia
51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery	 
NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1> 
Retail Price: $79.99
Blow Out Price: $34.95 (save 56%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1> 
	Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM> 
Retail Price: $70.99
Blow Out Price: $29.95 (save 58%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM> 	 
7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery	 15. Nokia
3310/3390 Vertical Leather Magnetic Button Pouch	 
NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1> 
Retail Price: $45.99
Blow Out Price: $14.95 (save 67%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1> 
	Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN331090LK> 
Retail Price: $24.99 
Blow Out Price: $9.95 (save 60%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN331090LK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK> 	 
8. Nokia 8260/8290 Data Cable	 16. Nokia 8260/8290 Vertical Leather
Magnetic Button Pouch	 
NOKIA 51xx/6xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K> 
Retail Price: $79.99
Blow Out Price: $19.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K> 	 Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK> 
Retail Price: $24.99 
Blow Out Price: $9.95 (save 60%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK>  
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK> 	 

------=_NextPart_000_BB8B0_01C12FE6.47186850
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<body bgcolor=3D"#ffffff" text=3D"#000000">
<div align=3D"center">=20
  <p><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D5031&amp;=
parent%5Fid=3D5" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/logo50.gif" =
border=3D"0"></a><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D5031&amp;=
parent%5Fid=3D5" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/Home399Banner.gif" =
border=3D"0"></a><br>
    <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">Big Saving =
from GoGoCity.=20
    If you'd rather not receive any future promotional E-mails from =
GoGoCity.com,=20
    <br>
    please click --&gt; <b><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp">Un-Subscribe=20
    My E-mai</a></b></font><font size=3D"2"><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp"><font =
face=3D"Arial, Helvetica, sans-serif"><b>l</b></font></a></font><br>
    <font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font =
size=3D"2">International=20
    Order Welcome</font></b></font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">=20
    FREE SHIPPING NOT APPLY</font></b></font> </p>
  <table width=3D"75%" cellpadding=3D"0" height=3D"30" cellspacing=3D"0" =
bgcolor=3D"#3366cc">
    <tr>=20
      <td height=3D"58" valign=3D"top">=20
        <div align=3D"center"><font face=3D"Arial, Helvetica, =
sans-serif" color=3D"#ffffff"><b><font size=3D"4">Cell=20
          Phone Accessories</font><br>
          Blow out Sale...!!<br>
          </b><i>Save Up to 80%...!! </i></font></div>
      </td>
    </tr>
  </table>
  <font size=3D"4" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">***** FREE=20
  SHIPPING</font> <font face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000" size=3D"2">(in=20
  US only)</font><font face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000"> *****</font><br>
  <font face=3D"Arial, Helvetica, sans-serif"><i><b>Why pay more in =
Retail Store..???</b></i></font><br>
  <br>
  <table width=3D"75%" cellspacing=3D"3">
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">1.=20
        Antenna Booster for All Cell Phone =
(1pack)</font></b></font></td>
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">9.=20
        Antenna Booster for All Cell Phone (5 =
pack)</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"29">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D5031&amp;p=
f_id=3DOS01AB"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/AB-80.GIF" =
width=3D"70" border=3D"0" alt=3D"Antenna Booster for All Cell Phone =
(1pack)"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
        </div>
      </td>
      <td width=3D"305" height=3D"29" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.95<br>
        <font color=3D"#ff0000">Blow Out Price: <STRONG>$5.95</STRONG> =
(save 75%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font> </a><br>
      </td>
      <td width=3D"70" height=3D"29">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     ></a><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB5PACK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/AB-80.GIF" =
width=3D"70" border=3D"0" alt=3D"Antenna Booster for All Cell Phone (5 =
pack)"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td width=3D"309" height=3D"29" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $99.75<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
80%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01AB5PACK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D5031&amp;p=
f_id=3DOS01AB"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">2.=20
        </font><font size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
        51xx/6xx Black Car Charger</font></b></font></td>
      <td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">10.=20
        Nokia 3310/3390 Data Cable</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN56K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CGN56K-80.JPG"=
 border=3D"0" alt=3D"NOKIA 51xx/6xx Black Car Charger" =
height=3D"70"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"70" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.49</b> (save =
73%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN56K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN56K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"70" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN331090K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN8233K-80.JP=
G" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Data Cable"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"70" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $79.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
75%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN331090K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">3.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        82xx/33xx Black Car Charger<br>
        </font></b></font></b></font></td>
      <td height=3D"2" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">11.=20
        Nokia 8260/8290 Li-ion 1200mAh </font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">12=20
        Lights</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif"> Flashing=20
        &amp; Vib Battery </font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"36">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN8233K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CGN56K-80.JPG"=
 border=3D"0" alt=3D"NOKIA 82xx/33xx Black Car Charger" =
height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.49</b> (save =
73%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN8233K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CGN8233K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"36" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2FV"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/emailimg/BTN8233L2FV.JPG" =
width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Li-ion 1200mAh 12 =
Lights Flashing &amp; Vib Battery"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $65.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$24.95</b> (save =
62%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2FV"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2FV"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"5"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">4.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        51xx/61xx Hands Free with on/off =
Switch</font></b></font></b></font></td>
      <td height=3D"5" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">12.=20
        </font><font face=3D"Arial, Helvetica, sans-serif"> </font><font =
size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
        51xx/6xx Data Cable</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"39">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN56BTK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/HFN56BTK-80.JP=
G" border=3D"0" alt=3D"NOKIA 51xx/61xx Hands Free with on/off Switch" =
height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"39" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.99</b> (save =
70%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN56BTK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN56BTK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"39" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN56K-80.JPG"=
 width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Data Cable"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"39" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $69.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$14.95</b> (save =
79%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN56K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"10"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">5.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        82xx/33xx Hands Free with on/off =
Switch</font></b></font></b></font></td>
      <td height=3D"10" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">13.=20
        Nokia 8260/8290 Li-ion 1200mAh Vibrating =
Battery</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"36">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN8233BTK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/HFN8233BTK-80.=
JPG" border=3D"0" alt=3D"NOKIA 82xx/33xx Hands Free with on/off Switch" =
height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $19.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$5.99</b> (save =
70%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN8233BTK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01HFN8233BTK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"36" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2V"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN8233L2V-80.=
JPG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Li-ion 1200mAh =
Vibrating Battery"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $45.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$24.95</b> (save =
46%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2V"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN8233L2V"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">6.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
        51xx/6xx Li-ion 3200mAh Vibrating =
Battery</font></b></font></b></font></td>
      <td height=3D"2" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">14.Nokia=20
        51xx/6xx Super Slim Black Li-ion 1200mAh Vib =
Battery</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"36">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" border=3D"0" alt=3D"NOKIA 51xx/6xx Li-ion 3200mAh Vibrating =
Battery" height=3D"70"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $79.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$34.95</b> (save =
56%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"36" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" width=3D"70" border=3D"0" alt=3D"Nokia 51xx/6xx Super Slim Black =
Li-ion 1200mAh Vib Battery"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $70.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$29.95</b> (save =
58%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"12"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">7.=20
        </font><font size=3D"2"><b><font size=3D"2"><b><font =
size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
        51xx/6xx Black NIMH-700mAh Vibrating =
Battery</font></b></font></b></font></b></font></td>
      <td colspan=3D"2" height=3D"12"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">15.=20
        Nokia 3310/3390 Vertical Leather Magnetic Button =
Pouch</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"73">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56N2VK1"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Black NIMH-700mAh =
Vibrating Battery"><br>
          <font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"73" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $45.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$14.95</b> (save =
67%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56N2VK1"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01BTN56N2VK1"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a><br>
      </td>
      <td height=3D"73" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN331090LK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CSN8233LK-80.J=
PG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Vertical Leather =
Magnetic Button Pouch"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"73" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $24.99 <br>
        <font color=3D"#ff0000">Blow Out Price: <b>$9.95</b> (save =
60%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN331090LK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
    <tr valign=3D"top" bgcolor=3D"#99cc99">=20
      <td colspan=3D"2" height=3D"9"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">8.=20
        Nokia 8260/8290 Data Cable</font></b></font></td>
      <td colspan=3D"2" height=3D"9"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">16.=20
        Nokia 8260/8290 Vertical Leather Magnetic Button =
Pouch</font></b></font></td>
    </tr>
    <tr valign=3D"top">=20
      <td width=3D"78" height=3D"73">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN56K-80.JPG"=
 width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Data Cable"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td width=3D"305" height=3D"73" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $79.99<br>
        <font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
75%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01DKN8233K"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
      <td height=3D"73" width=3D"70">=20
        <div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     ><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CSN8233LK-80.J=
PG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Vertical Leather =
Magnetic Button Pouch"><br>
          <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
      </td>
      <td height=3D"73" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
        Price: $24.99 <br>
        <font color=3D"#ff0000">Blow Out Price: <b>$9.95</b> (save =
60%)</font></font><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     >More=20
        Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&amp=
;pf%5Fid=3DOS01CSN8233LK"=20
     ><br>
        <font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
        <font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
        Shipping</font></a></td>
    </tr>
  </table>
</div>
</body>

------=_NextPart_000_BB8B0_01C12FE6.47186850--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 08:12:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22201
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 08:12:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00388;
	Wed, 29 Aug 2001 08:11:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00350
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 08:11:23 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22002
	for <midcom@ietf.org>; Wed, 29 Aug 2001 08:10:03 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7TCApg07699
	for <midcom@ietf.org>; Wed, 29 Aug 2001 13:10:51 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 29 Aug 2001 13:10:39 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RPYZ0HCM>; Wed, 29 Aug 2001 13:10:27 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445204@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        midcom mail-list <midcom@ietf.org>
Subject: RE: [midcom] more requirements deletions
Date: Wed, 29 Aug 2001 13:10:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C13083.A59A81E0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C13083.A59A81E0
Content-Type: text/plain;
	charset="iso-8859-1"

I agree that certain requirements needs more clarification:

R75: looks like in case a flow is no longer traversing the same Middle Box,
the Midcom Agent needs to be able to put the same states on another Middle
Box. From a midcom perspective I see this as a requirement where we could
request a Middle box to use certain addresses for the binds to be allocated
so that the networked end parties still send media to the previous ports and
addresses.
I don't know if we have already covered this requirement, I remember that we
had a discussion on the mailing list on the subject

R45: It seemed to me as a vendor could use proprietary functions. right?
this falls more under extensibility. or is it an owner ship (since we are
talking of attributes this seems to be a function support)
If it means extensibility, let's deleted there are other requirements
handling that

R68: does it mean that the protocol should use integrity check mechanism
(either embedded or from a transport layer) to preserve the content of the
message? or does it mean that we need to store the message in memory in case
the other end didn't get the message?
For both interpretations this is not a protocol requirement (we could use
the transport layer to have the integrity check), and the memory is
implementation related issue; to be dumped.

Cedric

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com]
Sent: Monday, August 27, 2001 10:56 PM
To: midcom mail-list
Subject: [midcom] more requirements deletions


Hi all,

I have a few more items I think we ought to consider removing or combining.

R23: Isn't this marketing? or just plain motherhood & apple pie?

R75: I'm not sure exactly what this means, but it sounds like a requirement
on the middlebox and the midcom agents to figure out that the routing has
changed and make necessary changes to existing pin-hole rules. How does this
affect the protocol? I propose we remove this requirement.

R45: Does anybody know what this means? It should be clarified or deleted.

R39+R63: These 2 need to be combined since they are basically talking about
response codes. The initial phrase in R63 "To enable management systems to
interact with the Midcom environment" is not needed. The real reason for
useful failure codes is to allow the midcom agent to do something reasonable
in response to the failure.

R68: Do we have new text for this yet?

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com




_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C13083.A59A81E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] more requirements deletions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree that certain requirements needs more =
clarification:</FONT>
</P>

<P><FONT SIZE=3D2>R75: looks like in case a flow is no longer =
traversing the same Middle Box, the Midcom Agent needs to be able to =
put the same states on another Middle Box. From a midcom perspective I =
see this as a requirement where we could request a Middle box to use =
certain addresses for the binds to be allocated so that the networked =
end parties still send media to the previous ports and =
addresses.</FONT></P>

<P><FONT SIZE=3D2>I don't know if we have already covered this =
requirement, I remember that we had a discussion on the mailing list on =
the subject</FONT></P>

<P><FONT SIZE=3D2>R45: It seemed to me as a vendor could use =
proprietary functions. right? this falls more under extensibility. or =
is it an owner ship (since we are talking of attributes this seems to =
be a function support)</FONT></P>

<P><FONT SIZE=3D2>If it means extensibility, let's deleted there are =
other requirements handling that</FONT>
</P>

<P><FONT SIZE=3D2>R68: does it mean that the protocol should use =
integrity check mechanism (either embedded or from a transport layer) =
to preserve the content of the message? or does it mean that we need to =
store the message in memory in case the other end didn't get the =
message?</FONT></P>

<P><FONT SIZE=3D2>For both interpretations this is not a protocol =
requirement (we could use the transport layer to have the integrity =
check), and the memory is implementation related issue; to be =
dumped.</FONT></P>

<P><FONT SIZE=3D2>Cedric</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bob Penfield [<A =
HREF=3D"mailto:bpenfield@acmepacket.com">mailto:bpenfield@acmepacket.com=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 27, 2001 10:56 PM</FONT>
<BR><FONT SIZE=3D2>To: midcom mail-list</FONT>
<BR><FONT SIZE=3D2>Subject: [midcom] more requirements deletions</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi all,</FONT>
</P>

<P><FONT SIZE=3D2>I have a few more items I think we ought to consider =
removing or combining.</FONT>
</P>

<P><FONT SIZE=3D2>R23: Isn't this marketing? or just plain motherhood =
&amp; apple pie?</FONT>
</P>

<P><FONT SIZE=3D2>R75: I'm not sure exactly what this means, but it =
sounds like a requirement</FONT>
<BR><FONT SIZE=3D2>on the middlebox and the midcom agents to figure out =
that the routing has</FONT>
<BR><FONT SIZE=3D2>changed and make necessary changes to existing =
pin-hole rules. How does this</FONT>
<BR><FONT SIZE=3D2>affect the protocol? I propose we remove this =
requirement.</FONT>
</P>

<P><FONT SIZE=3D2>R45: Does anybody know what this means? It should be =
clarified or deleted.</FONT>
</P>

<P><FONT SIZE=3D2>R39+R63: These 2 need to be combined since they are =
basically talking about</FONT>
<BR><FONT SIZE=3D2>response codes. The initial phrase in R63 &quot;To =
enable management systems to</FONT>
<BR><FONT SIZE=3D2>interact with the Midcom environment&quot; is not =
needed. The real reason for</FONT>
<BR><FONT SIZE=3D2>useful failure codes is to allow the midcom agent to =
do something reasonable</FONT>
<BR><FONT SIZE=3D2>in response to the failure.</FONT>
</P>

<P><FONT SIZE=3D2>R68: Do we have new text for this yet?</FONT>
</P>

<P><FONT SIZE=3D2>(-:bob</FONT>
</P>

<P><FONT SIZE=3D2>Robert F. Penfield</FONT>
<BR><FONT SIZE=3D2>Chief Software Architect</FONT>
<BR><FONT SIZE=3D2>Acme Packet, Inc.</FONT>
<BR><FONT SIZE=3D2>130 New Boston Street</FONT>
<BR><FONT SIZE=3D2>Woburn, MA 01801</FONT>
<BR><FONT SIZE=3D2>bpenfield@acmepacket.com</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>midcom mailing list</FONT>
<BR><FONT SIZE=3D2>midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13083.A59A81E0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 11:06:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00361
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 11:06:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05435;
	Wed, 29 Aug 2001 11:01:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05405
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 11:01:20 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00178
	for <midcom@ietf.org>; Wed, 29 Aug 2001 10:59:59 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7TEwnV24398
	for <midcom@ietf.org>; Wed, 29 Aug 2001 07:58:54 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-287.cisco.com [10.21.65.31])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABK17887;
	Wed, 29 Aug 2001 07:59:57 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010829110041.00a4a740@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 29 Aug 2001 11:01:36 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] R5 deleted
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Requirement R5 from Scott's list of open requirements is deleted.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 11:18:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00821
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 11:18:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05734;
	Wed, 29 Aug 2001 11:14:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05707
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 11:14:12 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00590
	for <midcom@ietf.org>; Wed, 29 Aug 2001 11:12:51 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7TFDfl09172
	for <midcom@ietf.org>; Wed, 29 Aug 2001 08:13:41 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn1-100.cisco.com [10.21.96.100])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAN06230;
	Wed, 29 Aug 2001 08:13:41 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 29 Aug 2001 11:13:40 -0400
Date: Wed, 29 Aug 2001 11:13:40 -0400
From: Scott Brim <swb@employees.org>
To: midcom@ietf.org
Subject: Re: [midcom] Proposed R83,R84, RTP+RTCP port numbers
Message-ID: <20010829111340.C1532@SBRIM-W2K>
Mail-Followup-To: Scott Brim <swb@employees.org>, midcom@ietf.org
References: <F66A04C29AD9034A8205949AD0C90104A3E6C6@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F66A04C29AD9034A8205949AD0C90104A3E6C6@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>; from huitema@windows.microsoft.com on Thu, Aug 23, 2001 at 02:30:46PM -0700
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

These are now in the bullet list which I hope will be released today.
Just waiting for a consensus statement from Melinda.

..Scott

Christian Huitema schrieb am Thu, Aug 23, 2001 02:30:46PM -0700:
> OK. Also, s/external/internal/ once on last line. (my typo)
> 
> > From: Scott Brim [mailto:sbrim@cisco.com]
> > 
> > Friendly amendment: s/MIDCOM server/middlebox/.  OK?
> > 
> > Christian Huitema schrieb am Thu, Aug 23, 2001 01:56:24PM -0700:
> > > In order to accommodate RTP and RTCP "oddity" and "sequence"
> > > requirements, I propose that we add the following requirements:
> > >
> > > R83: When the MIDCOM server performs a port mapping function, the
> > > protocol should allow the MIDCOM agent to request that the external
> > port
> > > number have the same oddity as the internal port.
> > >
> > > R84: When the MIDCOM server performs a port mapping function, the
> > > protocol should allow the MIDCOM agent to request that a consecutive
> > > range of external port numbers be mapped to consecutive external
> > ports.

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 11:28:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01190
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 11:28:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06040;
	Wed, 29 Aug 2001 11:26:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06012
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 11:26:31 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01102
	for <midcom@ietf.org>; Wed, 29 Aug 2001 11:25:08 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7TFQJH05319;
	Wed, 29 Aug 2001 08:26:19 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-287.cisco.com [10.21.65.31])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABK18543;
	Wed, 29 Aug 2001 08:25:51 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010829112337.00a56aa0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 29 Aug 2001 11:27:30 -0400
To: Scott Brim <swb@employees.org>, midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] Proposed R83,R84, RTP+RTCP port numbers
In-Reply-To: <20010829111340.C1532@SBRIM-W2K>
References: <F66A04C29AD9034A8205949AD0C90104A3E6C6@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
 <F66A04C29AD9034A8205949AD0C90104A3E6C6@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 11:13 AM 8/29/01 -0400, Scott Brim wrote:

>> > > R83: When the MIDCOM server performs a port mapping function, the
>> > > protocol should allow the MIDCOM agent to request that the external
>> > port
>> > > number have the same oddity as the internal port.
>
>> > > R84: When the MIDCOM server performs a port mapping function, the
>> > > protocol should allow the MIDCOM agent to request that a consecutive
>> > > range of external port numbers be mapped to consecutive external
>> > ports.

With the caveat that there has been no discussion, there doesn't seem to 
be any objection and we appear to have consensus on these additions.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 11:39:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01453
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 11:39:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06668;
	Wed, 29 Aug 2001 11:39:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06638
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 11:39:09 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01407
	for <midcom@ietf.org>; Wed, 29 Aug 2001 11:37:48 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7TFcvH15739
	for <midcom@ietf.org>; Wed, 29 Aug 2001 08:38:58 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-287.cisco.com [10.21.65.31])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABK18907;
	Wed, 29 Aug 2001 08:38:36 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010829113041.00a4ea20@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 29 Aug 2001 11:40:15 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Items currently under consideration
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

These are the requirements we're currently trying to close:

From http://www.employees.org/~swb/midreqs/midcom-reqs-bullets-010821.txt

R23: Delete?
        The Midcom Protocol MUST enable the Middlebox and any associated
        Midcom Agents to establish known and stable state.  This must
        include the case of power failure, or other failure, where the
        protocol must ensure that any resources used by a failed element
        can be released.

R75: Delete?
        The Midcom Protocol must produce robust operation even when
        routing changes such that traffic from a particular end system
        passes through a different middlebox.  

R45: Clarify or delete?
        It MUST be possible for the attributes associated with a
        Pinhole-Descriptor to be specific to a given Middlebox or MIDCOM
        Agent.

R39, R63: Combine?
        (R39) A Midcom Agent MUST be able to determine whether a request was
        successful or not.
        (R63) To enable management systems to interact with the Midcom
        environment, the protocol MUST include failure reasons that
        allow the Midcom Agent behaviour to be modified as a result of
        the information contained in the reason.  Failure reasons need
        to be chosen such that they do not make an attack on security
        easier.

R79,80: Both need more discussion, someone will need to propose new text
        (R79) If a particular ruleset is created multiple times, it must be
        deleted the same number of times.
        (R80) If two rulesets overlap, and one is deleted, the overlapping
        area must not be deleted until the other is deleted.


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 12:04:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02112
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 12:04:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07106;
	Wed, 29 Aug 2001 11:58:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07075
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 11:58:48 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02006
	for <midcom@ietf.org>; Wed, 29 Aug 2001 11:57:27 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7TFuOV26851
	for <midcom@ietf.org>; Wed, 29 Aug 2001 08:56:24 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn1-100.cisco.com [10.21.96.100])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAO00271;
	Wed, 29 Aug 2001 08:58:14 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 29 Aug 2001 11:58:14 -0400
Date: Wed, 29 Aug 2001 11:58:14 -0400
From: Scott Brim <swb@employees.org>
To: midcom@ietf.org
Message-ID: <20010829115814.H1532@SBRIM-W2K>
Mail-Followup-To: Scott Brim <swb@employees.org>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [midcom] new bullets as of 08/29
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

An August 29th version of the requirements bullets is available at
<http://www.employees.org/~swb/midcom.html>.  Not much has changed -- R5
has been deleted, R83 and R84 have been accepted.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 14:14:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04985
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 14:14:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11340;
	Wed, 29 Aug 2001 14:12:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11311
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 14:12:40 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04937
	for <midcom@ietf.org>; Wed, 29 Aug 2001 14:11:20 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA03467
	for <midcom@ietf.org>; Wed, 29 Aug 2001 13:11:08 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Wed, 29 Aug 2001 13:10:03 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RZ9CDA1Z>; Wed, 29 Aug 2001 11:08:46 -0700
Message-ID: <A7895B732354D311A4770008C791841A0146B80A@zsc4c014.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>,
        "'midcom@ietf.org'" <midcom@ietf.org>
Subject: RE: [midcom] Items currently under consideration
Date: Wed, 29 Aug 2001 11:08:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C130B5.A236F8D0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C130B5.A236F8D0
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, August 29, 2001 8:40 AM
> To: midcom@ietf.org
> Subject: [midcom] Items currently under consideration
> 
> 
> These are the requirements we're currently trying to close:
> 
> From 
> http://www.employees.org/~swb/midreqs/midcom-reqs-bullets-010821.txt
> 
> R23: Delete?
>         The Midcom Protocol MUST enable the Middlebox and any 
> associated
>         Midcom Agents to establish known and stable state.  This must
>         include the case of power failure, or other failure, where the
>         protocol must ensure that any resources used by a 
> failed element
>         can be released.
> 
> R75: Delete?
>         The Midcom Protocol must produce robust operation even when
>         routing changes such that traffic from a particular end system
>         passes through a different middlebox. 

Hello,

You do not need a routing change for the traffic to pass through different
MBs. How about ECMP? Or assymetric routing with BGP? Or MPLS? We already
have very common topologies in use today that makes traffic take different
paths.

IMO this should be rephrased to:

The MIDCOM protocol must produce robust operation even when ingress traffic
and/or egress traffic from a particular end system passes through different
MBs. 

regards,

-RP
 

------_=_NextPart_001_01C130B5.A236F8D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Items currently under consideration</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 29, 2001 8:40 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Items currently under =
consideration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; These are the requirements we're currently =
trying to close:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; From </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.employees.org/~swb/midreqs/midcom-reqs-bullets-010821=
.txt" =
TARGET=3D"_blank">http://www.employees.org/~swb/midreqs/midcom-reqs-bull=
ets-010821.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R23: Delete?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The Midcom Protocol MUST enable the Middlebox and any </FONT>
<BR><FONT SIZE=3D2>&gt; associated</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Midcom Agents to establish known and stable state.&nbsp; This =
must</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
include the case of power failure, or other failure, where the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
protocol must ensure that any resources used by a </FONT>
<BR><FONT SIZE=3D2>&gt; failed element</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
can be released.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R75: Delete?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The Midcom Protocol must produce robust operation even when</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
routing changes such that traffic from a particular end system</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
passes through a different middlebox. </FONT>
</P>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>You do not need a routing change for the traffic to =
pass through different MBs. How about ECMP? Or assymetric routing with =
BGP? Or MPLS? We already have very common topologies in use today that =
makes traffic take different paths.</FONT></P>

<P><FONT SIZE=3D2>IMO this should be rephrased to:</FONT>
</P>

<P><FONT SIZE=3D2>The MIDCOM protocol must produce robust operation =
even when ingress traffic and/or egress traffic from a particular end =
system passes through different MBs. </FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>-RP</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C130B5.A236F8D0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 14:21:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05176
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 14:21:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11583;
	Wed, 29 Aug 2001 14:20:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11554
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 14:20:43 -0400 (EDT)
Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05122
	for <midcom@ietf.org>; Wed, 29 Aug 2001 14:19:22 -0400 (EDT)
Received: from 157.54.9.100 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Aug 2001 11:20:04 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 29 Aug 2001 11:20:09 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 29 Aug 2001 11:20:04 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 29 Aug 2001 11:19:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [midcom] R79/80
Date: Wed, 29 Aug 2001 11:19:41 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BF35@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [midcom] R79/80
Thread-Index: AcEv+afGMligWbgBTUW6Iyd29GbOzwAupiQQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Melinda Shore" <mshore@cisco.com>, <midcom@ietf.org>
X-OriginalArrivalTime: 29 Aug 2001 18:19:42.0160 (UTC) FILETIME=[2C305D00:01C130B7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA11555
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

I believe we should certainly delete R79 -- it looks at a poor attempt
to specific way to solve the R23 requirement. A definitive possibility
is to have "intrinsic" rule identifiers such as:
	Internal IP, External IP, Protocol, Internal Port, External Port
Example of identifiers could be:
 (a) 10.0.0.2; 64.5.6.7; UDP; 3045; 7089
 (b) 10.0.0.2; *; UDP; 3045; *
 (c) *; 64.5.6.7; UDP; *; 7089
The beauty of any "intrinsic" identification is that there cannot be any
ambiguity about the removal of rules: if I remove "10.0.0.2; *; UDP;
3045; *" I remove rule (b), but I definitely leave rule (a) alone. This
removes any requirement for rule 79: if I attempt to remove "10.0.0.2;
*; UDP; 3045; *" and I am authorized, it is removed, and I need exactly
one transaction. The current R80 actually specifies the opposite of what
we want: when the most specific rule is removed, we just need to apply
the default behavior specified by the overlapping rule.

Indeed, some rules will overlap, which implies a rewriting of R80:
 
	R83: It must be possible to deterministically predict the
behavior
	of the firewall in the presence of overlapping rules.

I am tempted to add a requirement that "in the presence of overlapping
rules, the firewall must apply the most specific rules that matches the
filtered packet", but this requires that we define a global ordering
relation between rules. Take the three examples above. We can be easily
convinced that (a) is more specific than either (b) or (c), but what
about the relative order of (b) and (c)? Any convention there is going
to be arbitrary. If I had a choice, I would say that the rule is defined
by the ordered list
 <interior IP> <protocol> <interior port> <exterior IP> <exterior port>
which would rule that (b) is more specific than (c). But this is clearly
an arbitrary choice.

-- Christian Huitema 
	

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, August 28, 2001 12:16 PM
> To: midcom@ietf.org
> Subject: [midcom] R79/80
> 
> Next question:
> 
> R79/80 - kill or keep?  It's related to the question of ownership
> but isn't the same.  R79 says:
> 
> "If a particular ruleset is created multiple times, it must be
> deleted the same number of times"
> 
> and R80 says:
> 
> "If two rulesets overlap, and one is deleted, the overlapping
> area must not be deleted until the other is deleted."
> 
> If we keep R80 we need to do something about defining "overlap."
> I believe that it's not currently addressed elsewhere in our
> documents.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 14:31:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05451
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 14:31:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11799;
	Wed, 29 Aug 2001 14:27:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11770
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 14:27:31 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05288
	for <midcom@ietf.org>; Wed, 29 Aug 2001 14:26:10 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7TIR4l19035;
	Wed, 29 Aug 2001 11:27:04 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7TIQxX04018;
	Wed, 29 Aug 2001 11:26:59 -0700 (PDT)
Message-ID: <3B8D33F3.AF18B978@cisco.com>
Date: Wed, 29 Aug 2001 11:26:59 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
Subject: Re: [midcom] R79/80
References: <F66A04C29AD9034A8205949AD0C9010418BF35@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

What Christian wrote is fine with me.
--
Eliot Lear
lear@cisco.com

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 14:42:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05820
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 14:42:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12286;
	Wed, 29 Aug 2001 14:38:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12257
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 14:38:13 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05647
	for <midcom@ietf.org>; Wed, 29 Aug 2001 14:36:52 -0400 (EDT)
Received: from 157.54.9.104 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Aug 2001 11:37:31 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 29 Aug 2001 11:37:31 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 29 Aug 2001 11:37:29 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 29 Aug 2001 11:37:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [midcom] Items currently under consideration
Date: Wed, 29 Aug 2001 11:37:06 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010418BF36@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [midcom] Items currently under consideration
Thread-Index: AcEwsba1vC6fi98rRd+S4dEkrNBuvwABc7xA
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Melinda Shore" <mshore@cisco.com>, <midcom@ietf.org>
X-OriginalArrivalTime: 29 Aug 2001 18:37:07.0245 (UTC) FILETIME=[9B1BADD0:01C130B9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA12258
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

Keep R23 -- hey, it is accepted already! It supercedes a number of silly
requirements that would pop up otherwise.

I have mixed feelings on R75. A possibility to satisfy it is to have the
option in Midcom to carry "full mappings". Suppose I want a stable
pinhole between 10.0.0.2:3456 and 64.5.6.7:8901. A possibility is for
the midcom box (10.0.0.1, 128.9.10.11) to allocate two mappings, ask
10.0.0.1 to send packets to the address "10.0.0.1:2345", and ask
64.5.6.7 to send packets to "128.9.10.11:1213". This guarantees that the
midcom box will be in the way of the communication even if the routing
changes. (It also guarantees fate sharing between the communication and
the midcom box, but that is another issue.)

Delete R45. It is way too vague, and probably wrong anyhow. Assuming
that the Midcom protocol operates on a set of rules, then the rules are
in all cases specific to the Midcom server on which they are creates.
Assuming that rules are actually identified by an intrinsic spec such as
a five tuple, then there cannot be two rules applying to the same tuple,
which means that there can only be one attribute set for any given rule.


Accept both 39 and 63. 39 is already agreed; 63 is just sound design.

Delete 79 and 80 (see separate e-mail.)

-- Christian Huitema

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, August 29, 2001 8:40 AM
> To: midcom@ietf.org
> Subject: [midcom] Items currently under consideration
> 
> These are the requirements we're currently trying to close:
> 
> From http://www.employees.org/~swb/midreqs/midcom-reqs-bullets-
> 010821.txt
> 
> R23: Delete?
>         The Midcom Protocol MUST enable the Middlebox and any
> associated
>         Midcom Agents to establish known and stable state.  This must
>         include the case of power failure, or other failure, where the
>         protocol must ensure that any resources used by a failed
> element
>         can be released.
> 
> R75: Delete?
>         The Midcom Protocol must produce robust operation even when
>         routing changes such that traffic from a particular end system
>         passes through a different middlebox.
> 
> R45: Clarify or delete?
>         It MUST be possible for the attributes associated with a
>         Pinhole-Descriptor to be specific to a given Middlebox or
> MIDCOM
>         Agent.
> 
> R39, R63: Combine?
>         (R39) A Midcom Agent MUST be able to determine whether a
> request was
>         successful or not.
>         (R63) To enable management systems to interact with the Midcom
>         environment, the protocol MUST include failure reasons that
>         allow the Midcom Agent behaviour to be modified as a result of
>         the information contained in the reason.  Failure reasons need
>         to be chosen such that they do not make an attack on security
>         easier.
> 
> R79,80: Both need more discussion, someone will need to propose new
> text
>         (R79) If a particular ruleset is created multiple times, it
> must be
>         deleted the same number of times.
>         (R80) If two rulesets overlap, and one is deleted, the
> overlapping
>         area must not be deleted until the other is deleted.
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 15:09:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06503
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 15:09:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13070;
	Wed, 29 Aug 2001 15:08:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13042
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 15:08:35 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06430
	for <midcom@ietf.org>; Wed, 29 Aug 2001 15:07:14 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA28736
	for <midcom@ietf.org>; Wed, 29 Aug 2001 14:07:59 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 29 Aug 2001 14:05:57 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RPSX6ZLR>; Wed, 29 Aug 2001 14:05:10 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF93@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] R79/80
Date: Wed, 29 Aug 2001 14:05:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C130BD.8394BE00"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C130BD.8394BE00
Content-Type: text/plain;
	charset="iso-8859-1"


The problem is here is that we first need a clear definition of ruleset.
From some of the previous discussions, a ruleset was defined as  <flow
identifier & action>. Given this, can anybody specify examples under which
the same ruleset will be created multiple times (R79)?

R80 - I can think of cases when rulesets can overlap --> either when two
actions share the same flow id or when two flow ids share the same action
(one flow id may be a subset of the other). By definition, these are two
different overlapping rulesets. In both cases, the internal operations of
the MB should guarantee that when one ruleset is deleted, the other is not.
All it needs for the protocol is to specify the ruleset unambigously. 

So, I think both requirements should be deleted.

Sanjoy


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, August 28, 2001 2:16 PM
> To: midcom@ietf.org
> Subject: [midcom] R79/80
> 
> 
> Next question:
> 
> R79/80 - kill or keep?  It's related to the question of ownership
> but isn't the same.  R79 says:
> 
> "If a particular ruleset is created multiple times, it must be
> deleted the same number of times"
> 
> and R80 says:
> 
> "If two rulesets overlap, and one is deleted, the overlapping
> area must not be deleted until the other is deleted."
> 
> If we keep R80 we need to do something about defining "overlap."
> I believe that it's not currently addressed elsewhere in our 
> documents.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 

------_=_NextPart_001_01C130BD.8394BE00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] R79/80</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>The problem is here is that we first need a clear =
definition of ruleset. From some of the previous discussions, a ruleset =
was defined as&nbsp; &lt;flow identifier &amp; action&gt;. Given this, =
can anybody specify examples under which the same ruleset will be =
created multiple times (R79)?</FONT></P>

<P><FONT SIZE=3D2>R80 - I can think of cases when rulesets can overlap =
--&gt; either when two actions share the same flow id or when two flow =
ids share the same action (one flow id may be a subset of the other). =
By definition, these are two different overlapping rulesets. In both =
cases, the internal operations of the MB should guarantee that when one =
ruleset is deleted, the other is not. All it needs for the protocol is =
to specify the ruleset unambigously. </FONT></P>

<P><FONT SIZE=3D2>So, I think both requirements should be =
deleted.</FONT>
</P>

<P><FONT SIZE=3D2>Sanjoy</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 28, 2001 2:16 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] R79/80</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Next question:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R79/80 - kill or keep?&nbsp; It's related to =
the question of ownership</FONT>
<BR><FONT SIZE=3D2>&gt; but isn't the same.&nbsp; R79 says:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;If a particular ruleset is created =
multiple times, it must be</FONT>
<BR><FONT SIZE=3D2>&gt; deleted the same number of times&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; and R80 says:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;If two rulesets overlap, and one is =
deleted, the overlapping</FONT>
<BR><FONT SIZE=3D2>&gt; area must not be deleted until the other is =
deleted.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If we keep R80 we need to do something about =
defining &quot;overlap.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; I believe that it's not currently addressed =
elsewhere in our </FONT>
<BR><FONT SIZE=3D2>&gt; documents.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C130BD.8394BE00--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 17:36:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11021
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:36:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19464;
	Wed, 29 Aug 2001 17:35:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19436
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 17:35:36 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10990
	for <midcom@ietf.org>; Wed, 29 Aug 2001 17:34:13 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA27005
	for <midcom@ietf.org>; Wed, 29 Aug 2001 16:35:03 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 29 Aug 2001 16:34:59 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RPSX68ZG>; Wed, 29 Aug 2001 16:34:12 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430317FF94@crchy271.us.nortel.com>
From: "Sanjoy Sen" <sanjoy@nortelnetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, midcom@ietf.org
Subject: RE: [midcom] Items currently under consideration
Date: Wed, 29 Aug 2001 16:34:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C130D2.556DA900"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C130D2.556DA900
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, August 29, 2001 10:40 AM
> To: midcom@ietf.org
> Subject: [midcom] Items currently under consideration
> 
> 
> R23: Delete?
>         The Midcom Protocol MUST enable the Middlebox and any 
> associated
>         Midcom Agents to establish known and stable state.  This must
>         include the case of power failure, or other failure, where the
>         protocol must ensure that any resources used by a 
> failed element
>         can be released.

   I think the first part (sentence) is important & should remain. This
emphasises the need for
state synchronization/update between the MB & the MA. If there're any state
changes in the MB, this should be promptly reported to the MA & vice-versa.
However, we may try to merge R31 & R23.
 
> 
> R75: Delete?
>         The Midcom Protocol must produce robust operation even when
>         routing changes such that traffic from a particular end system
>         passes through a different middlebox.

Delete
  
> 
> R45: Clarify or delete?
>         It MUST be possible for the attributes associated with a
>         Pinhole-Descriptor to be specific to a given 
> Middlebox or MIDCOM
>         Agent.

Please clarify. Is this talking about vendor-specific extensions?

> 
> R39, R63: Combine?
>         (R39) A Midcom Agent MUST be able to determine 
> whether a request was
>         successful or not.
>         (R63) To enable management systems to interact with the Midcom
>         environment, the protocol MUST include failure reasons that
>         allow the Midcom Agent behaviour to be modified as a result of
>         the information contained in the reason.  Failure reasons need
>         to be chosen such that they do not make an attack on security
>         easier.
> 

Keep separate. I think R63 is extending R39 and saying "tell me something
more". R63 is also saying that the MA should be able to change its behavior
based on certain responses - this implies that we will need to have rules on
client & server to generate reason codes & react based on the reason codes. 

------_=_NextPart_001_01C130D2.556DA900
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] Items currently under consideration</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 29, 2001 10:40 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] Items currently under =
consideration</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R23: Delete?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The Midcom Protocol MUST enable the Middlebox and any </FONT>
<BR><FONT SIZE=3D2>&gt; associated</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Midcom Agents to establish known and stable state.&nbsp; This =
must</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
include the case of power failure, or other failure, where the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
protocol must ensure that any resources used by a </FONT>
<BR><FONT SIZE=3D2>&gt; failed element</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
can be released.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; I think the first part (sentence) is =
important &amp; should remain. This emphasises the need for</FONT>
<BR><FONT SIZE=3D2>state synchronization/update between the MB &amp; =
the MA. If there're any state changes in the MB, this should be =
promptly reported to the MA &amp; vice-versa. However, we may try to =
merge R31 &amp; R23.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R75: Delete?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The Midcom Protocol must produce robust operation even when</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
routing changes such that traffic from a particular end system</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
passes through a different middlebox.</FONT>
</P>

<P><FONT SIZE=3D2>Delete</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R45: Clarify or delete?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
It MUST be possible for the attributes associated with a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pinhole-Descriptor to be specific to a given </FONT>
<BR><FONT SIZE=3D2>&gt; Middlebox or MIDCOM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Agent.</FONT>
</P>

<P><FONT SIZE=3D2>Please clarify. Is this talking about vendor-specific =
extensions?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R39, R63: Combine?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(R39) A Midcom Agent MUST be able to determine </FONT>
<BR><FONT SIZE=3D2>&gt; whether a request was</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
successful or not.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(R63) To enable management systems to interact with the Midcom</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
environment, the protocol MUST include failure reasons that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
allow the Midcom Agent behaviour to be modified as a result of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the information contained in the reason.&nbsp; Failure reasons =
need</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
to be chosen such that they do not make an attack on security</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
easier.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Keep separate. I think R63 is extending R39 and =
saying &quot;tell me something more&quot;. R63 is also saying that the =
MA should be able to change its behavior based on certain responses - =
this implies that we will need to have rules on client &amp; server to =
generate reason codes &amp; react based on the reason codes. =
</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C130D2.556DA900--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 17:52:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11552
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:52:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19911;
	Wed, 29 Aug 2001 17:51:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19880
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 17:51:31 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11325
	for <midcom@ietf.org>; Wed, 29 Aug 2001 17:50:10 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id OAA12244;
	Wed, 29 Aug 2001 14:51:29 -0700 (PDT)
Message-Id: <200108292151.OAA12244@nemo.corp.equinix.com>
Subject: Re: [midcom] R79/80
To: lear@cisco.com
Date: Wed, 29 Aug 2001 14:51:29 -0700 (PDT)
Cc: midcom@ietf.org
In-Reply-To: <3B8C242F.C7991A7@cisco.com> from "Eliot Lear" at Aug 28, 2001 04:07:27 PM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


> What's going on that a MIDCOM agent would make such a wildcard request as
> described above?  It's not helping an application at that point.  It's
> essentially granting any access to a host.  Big difference.  

I've seen deployments in which "VPN Termination" devices were placed
in a DMZ, with a secondary pass through a firewall from there.  In a
world in which MIDCOM existed, you might well see someone signal from
such a device to an agent a request to allow an authenticated host or
an authenticated subnet, depending on the termination.  Having both
types of request (one a direct authentication to the midcom agent,
say, and the other via a "termination device") also doesn't seem all
that unlikely.  

I'm also not certain that there is that big a difference between a
request to a host/port pair and a covering subnet/port set is that
different from the example I gave above.  Imagine a configuration in
which I say, in essence, "Allow that non-managed host to use the SMTP
port to talk to my managed host's SMTP port" then another rule says
"Allow non-managed hosts from this range of addresses to use their
SMTP port to talk to my managed host's SMTP port".

In any case, there is nothing logically or morally wrong with a
wildcard request, so the ability to handle it well seems reasonable.

>So what if a
> port were mentioned in each request?  That way one could argue that MIDCOM
> is now helping the application.  Well if that's the case, while it's not
> reasonable to expect midcom agents for two completely different
> applications to coordinate, it is quite reasonable to expect two midcom
> agents for the SAME application to coordinate.

The discovery of one agent of the other in order to coordinate with it
seems *way* out of scope for this group.  If it coordinates with other
agents, it seems likely it must do so through the MIDCOM box through
the type of error condition you've already described.


> 
> > This does mean we require different behavior for "Withdraw 'allow from
> > 128.102.33/24'" and "Deny from 128.102.33/24", but I think that's okay.
> 
> Hold the phone on this one.  Let's come back to it.
> 
> Regards,
> 
> Eliot
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 18:03:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11920
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:03:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26491;
	Wed, 29 Aug 2001 18:01:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26456
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 18:01:00 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11833
	for <midcom@ietf.org>; Wed, 29 Aug 2001 17:59:40 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id PAA12548;
	Wed, 29 Aug 2001 15:01:00 -0700 (PDT)
Message-Id: <200108292201.PAA12548@nemo.corp.equinix.com>
Subject: Re: [midcom] R79/80
To: huitema@windows.microsoft.com (Christian Huitema)
Date: Wed, 29 Aug 2001 15:00:59 -0700 (PDT)
Cc: midcom@ietf.org
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010418BF35@win-msg-02.wingroup.windeploy.ntdev.microsoft.com> from "Christian Huitema" at Aug 29, 2001 11:19:41 AM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> Indeed, some rules will overlap, which implies a rewriting of R80:
>  
> 	R83: It must be possible to deterministically predict the
> behavior
> 	of the firewall in the presence of overlapping rules.

I agree.  If you know how the firewall will act in the presence
of overlapping rules, you can have the agents and applications
behave in ways that can achieve specific desired results.  
			regards,
				Ted Hardie

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Wed Aug 29 18:15:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12128
	for <midcom-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:15:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26591;
	Wed, 29 Aug 2001 18:02:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26511
	for <midcom@ns.ietf.org>; Wed, 29 Aug 2001 18:02:41 -0400 (EDT)
Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11870
	for <midcom@ietf.org>; Wed, 29 Aug 2001 18:01:20 -0400 (EDT)
From: hardie@equinix.com
Received: (from hardie@localhost)
	by nemo.corp.equinix.com (8.9.3/8.9.3) id PAA12649
	for midcom@ietf.org; Wed, 29 Aug 2001 15:02:41 -0700 (PDT)
Message-Id: <200108292202.PAA12649@nemo.corp.equinix.com>
Subject: Re: [midcom] R79/80
To: midcom@ietf.org
Date: Wed, 29 Aug 2001 15:02:41 -0700 (PDT)
In-Reply-To: <200108292151.OAA12244@nemo.corp.equinix.com> from "hardie@equinix.com" at Aug 29, 2001 02:51:29 PM
Reply-to: hardie@equinix.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Ignore this; I hadn't seen Christian's message when I wrote
it, and I think his requirement as written handles what i
think we need.
			thanks,
				Ted
> 
> 
> > What's going on that a MIDCOM agent would make such a wildcard request as
> > described above?  It's not helping an application at that point.  It's
> > essentially granting any access to a host.  Big difference.  
> 
> I've seen deployments in which "VPN Termination" devices were placed
> in a DMZ, with a secondary pass through a firewall from there.  In a
> world in which MIDCOM existed, you might well see someone signal from
> such a device to an agent a request to allow an authenticated host or
> an authenticated subnet, depending on the termination.  Having both
> types of request (one a direct authentication to the midcom agent,
> say, and the other via a "termination device") also doesn't seem all
> that unlikely.  
> 
> I'm also not certain that there is that big a difference between a
> request to a host/port pair and a covering subnet/port set is that
> different from the example I gave above.  Imagine a configuration in
> which I say, in essence, "Allow that non-managed host to use the SMTP
> port to talk to my managed host's SMTP port" then another rule says
> "Allow non-managed hosts from this range of addresses to use their
> SMTP port to talk to my managed host's SMTP port".
> 
> In any case, there is nothing logically or morally wrong with a
> wildcard request, so the ability to handle it well seems reasonable.
> 
> >So what if a
> > port were mentioned in each request?  That way one could argue that MIDCOM
> > is now helping the application.  Well if that's the case, while it's not
> > reasonable to expect midcom agents for two completely different
> > applications to coordinate, it is quite reasonable to expect two midcom
> > agents for the SAME application to coordinate.
> 
> The discovery of one agent of the other in order to coordinate with it
> seems *way* out of scope for this group.  If it coordinates with other
> agents, it seems likely it must do so through the MIDCOM box through
> the type of error condition you've already described.
> 
> 
> > 
> > > This does mean we require different behavior for "Withdraw 'allow from
> > > 128.102.33/24'" and "Deny from 128.102.33/24", but I think that's okay.
> > 
> > Hold the phone on this one.  Let's come back to it.
> > 
> > Regards,
> > 
> > Eliot
> > 
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www1.ietf.org/mailman/listinfo/midcom
> > 
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
> 


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 10:51:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18836
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 10:51:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29787;
	Thu, 30 Aug 2001 10:46:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29748
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 10:46:51 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18748
	for <midcom@ietf.org>; Thu, 30 Aug 2001 10:45:31 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7UEkMg06256
	for <midcom@ietf.org>; Thu, 30 Aug 2001 15:46:22 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Thu, 30 Aug 2001 15:46:13 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <R7G0V9KW>; Thu, 30 Aug 2001 15:46:02 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445213@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "Midcom IETF (E-mail)" <midcom@ietf.org>
Subject: RE: [midcom] R79/80
Date: Thu, 30 Aug 2001 15:46:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C13162.8A54E4E0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C13162.8A54E4E0
Content-Type: text/plain;
	charset="iso-8859-1"

R79 should be taken out, an error should be generated if an agent is
requesting a resource that is already allocated.
Maybe the requirement should be allow a state to be transferred to another
agent. This is already covered in R59. 
so R79 should be deleted
R80- this is not a protocol issue. Should be deleted
Cedric
 
 
-----Original Message-----
From: Sen, Sanjoy [NGB:B602:EXCH] 
Sent: Wednesday, August 29, 2001 9:05 PM
To: 'Melinda Shore'; midcom@ietf.org
Subject: RE: [midcom] R79/80




The problem is here is that we first need a clear definition of ruleset.
From some of the previous discussions, a ruleset was defined as  <flow
identifier & action>. Given this, can anybody specify examples under which
the same ruleset will be created multiple times (R79)?
R80 - I can think of cases when rulesets can overlap --> either when two
actions share the same flow id or when two flow ids share the same action
(one flow id may be a subset of the other). By definition, these are two
different overlapping rulesets. In both cases, the internal operations of
the MB should guarantee that when one ruleset is deleted, the other is not.
All it needs for the protocol is to specify the ruleset unambigously. 
So, I think both requirements should be deleted. 
Sanjoy 


> -----Original Message----- 
> From: Melinda Shore [mailto:mshore@cisco.com] 
> Sent: Tuesday, August 28, 2001 2:16 PM 
> To: midcom@ietf.org 
> Subject: [midcom] R79/80 
> 
> 
> Next question: 
> 
> R79/80 - kill or keep?  It's related to the question of ownership 
> but isn't the same.  R79 says: 
> 
> "If a particular ruleset is created multiple times, it must be 
> deleted the same number of times" 
> 
> and R80 says: 
> 
> "If two rulesets overlap, and one is deleted, the overlapping 
> area must not be deleted until the other is deleted." 
> 
> If we keep R80 we need to do something about defining "overlap." 
> I believe that it's not currently addressed elsewhere in our 
> documents. 
> 
> Melinda 
> 
> 
> 
> _______________________________________________ 
> midcom mailing list 
> midcom@ietf.org 
> http://www1.ietf.org/mailman/listinfo/midcom 
> 

------_=_NextPart_001_01C13162.8A54E4E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [midcom] R79/80</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>R79 should be taken out, an error should be generated =
if an agent is requesting a resource that is already allocated.</FONT>
<BR><FONT SIZE=3D2>Maybe the requirement should be allow a state to be =
transferred to another agent. This is already covered in R59. </FONT>
<BR><FONT SIZE=3D2>so R79 should be deleted</FONT>
<BR><FONT SIZE=3D2>R80- this is not a protocol issue. Should be =
deleted</FONT>
<BR><FONT SIZE=3D2>Cedric</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Sen, Sanjoy [NGB:B602:EXCH] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 29, 2001 9:05 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Melinda Shore'; midcom@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [midcom] R79/80</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>The problem is here is that we first need a clear =
definition of ruleset. From some of the previous discussions, a ruleset =
was defined as&nbsp; &lt;flow identifier &amp; action&gt;. Given this, =
can anybody specify examples under which the same ruleset will be =
created multiple times (R79)?</FONT></P>

<P><FONT SIZE=3D2>R80 - I can think of cases when rulesets can overlap =
--&gt; either when two actions share the same flow id or when two flow =
ids share the same action (one flow id may be a subset of the other). =
By definition, these are two different overlapping rulesets. In both =
cases, the internal operations of the MB should guarantee that when one =
ruleset is deleted, the other is not. All it needs for the protocol is =
to specify the ruleset unambigously. </FONT></P>

<P><FONT SIZE=3D2>So, I think both requirements should be deleted. =
</FONT>
<BR><FONT SIZE=3D2>Sanjoy </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Melinda Shore [<A =
HREF=3D"mailto:mshore@cisco.com">mailto:mshore@cisco.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 28, 2001 2:16 PM </FONT>
<BR><FONT SIZE=3D2>&gt; To: midcom@ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [midcom] R79/80 </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Next question: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; R79/80 - kill or keep?&nbsp; It's related to =
the question of ownership </FONT>
<BR><FONT SIZE=3D2>&gt; but isn't the same.&nbsp; R79 says: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;If a particular ruleset is created =
multiple times, it must be </FONT>
<BR><FONT SIZE=3D2>&gt; deleted the same number of times&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; and R80 says: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;If two rulesets overlap, and one is =
deleted, the overlapping </FONT>
<BR><FONT SIZE=3D2>&gt; area must not be deleted until the other is =
deleted.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If we keep R80 we need to do something about =
defining &quot;overlap.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; I believe that it's not currently addressed =
elsewhere in our </FONT>
<BR><FONT SIZE=3D2>&gt; documents. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Melinda </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; _______________________________________________ =
</FONT>
<BR><FONT SIZE=3D2>&gt; midcom mailing list </FONT>
<BR><FONT SIZE=3D2>&gt; midcom@ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/midcom" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/midcom</A> =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13162.8A54E4E0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 12:40:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21354
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 12:40:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03368;
	Thu, 30 Aug 2001 12:35:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03327
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 12:35:42 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21232
	for <midcom@ietf.org>; Thu, 30 Aug 2001 12:34:23 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7UGZVv13985
	for <midcom@ietf.org>; Thu, 30 Aug 2001 09:35:31 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp161.cisco.com [10.21.64.161])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABK56528;
	Thu, 30 Aug 2001 09:35:00 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010830123302.00a4f5c0@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 30 Aug 2001 12:36:33 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] R79/R80 - current status
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

As things currently stand, there's consensus to delete R79.
There's a proposal to replace the text in R80 with the following:

"It must be possible to deterministically predict the
behavior the firewall in the presence of overlapping rules."

Right now there's no specific dissent (several people agree
that R80 should be deleted but haven't addressed replacement
text), so if you object please speak up.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 13:08:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22117
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:08:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04146;
	Thu, 30 Aug 2001 13:07:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04117
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 13:07:22 -0400 (EDT)
Received: from web14305.mail.yahoo.com (web14305.mail.yahoo.com [216.136.173.81])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22047
	for <midcom@ietf.org>; Thu, 30 Aug 2001 13:06:03 -0400 (EDT)
Message-ID: <20010830170723.44459.qmail@web14305.mail.yahoo.com>
Received: from [207.164.4.32] by web14305.mail.yahoo.com via HTTP; Thu, 30 Aug 2001 13:07:23 EDT
Date: Thu, 30 Aug 2001 13:07:23 -0400 (EDT)
From: Abdallah Rayhan <ar_rayhan@yahoo.ca>
Subject: Re: [midcom] R79/R80 - current status
To: Melinda Shore <mshore@cisco.com>, midcom@ietf.org
In-Reply-To: <5.1.0.14.0.20010830123302.00a4f5c0@mira-sjc5-4.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

--- Melinda Shore <mshore@cisco.com> wrote:
> As things currently stand, there's consensus to delete R79.
> There's a proposal to replace the text in R80 with the following:
> 
> "It must be possible to deterministically predict the
> behavior the firewall in the presence of overlapping rules."
 
This statement defines the behavior of the firewall instead
of the midcom protocol. I propose the following text instead:

"It is possible for descriptors, defining filtering and/or NAT 
rules, to overlap when requests from the same (various) agent(s) 
are formulated. It SHOULD be possible to deterministically
discern the outcome of processing the new descriptors in 
conjunction with what previously being accommodated by the 
middlebox being delete, add or modify request operation." 

I am using "SHOULD" because it is possible to have a stupid 
request that does not make sense in the context of application
or the request. Otherwise, reject the request.

regards
Abdallah

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 13:09:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22128
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:09:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03716;
	Thu, 30 Aug 2001 12:59:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03685
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 12:59:56 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21920
	for <midcom@ietf.org>; Thu, 30 Aug 2001 12:58:36 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA24204;
        Thu, 30 Aug 2001 12:59:46 -0400 (EDT)
Message-Id: <200108301659.MAA24204@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: Melinda Shore <mshore@cisco.com>
cc: midcom@ietf.org
Subject: Re: [midcom] R79/R80 - current status 
In-reply-to: Your message of "Thu, 30 Aug 2001 12:36:33 EDT."
             <5.1.0.14.0.20010830123302.00a4f5c0@mira-sjc5-4.cisco.com> 
Date: Thu, 30 Aug 2001 12:59:46 -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

> As things currently stand, there's consensus to delete R79.
> There's a proposal to replace the text in R80 with the following:
> 
> "It must be possible to deterministically predict the
> behavior the firewall in the presence of overlapping rules."
> 
> Right now there's no specific dissent (several people agree
> that R80 should be deleted but haven't addressed replacement
> text), so if you object please speak up.

this might seem picky, but it seems like you want to be more specific.

in particular, seems like you want to be able to predict the behavior of 
the firewall entirely by looking at the rules, without having to know any
specifics about the firewall implementation.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 13:11:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22191
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:11:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04233;
	Thu, 30 Aug 2001 13:10:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04202
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 13:10:55 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22140
	for <midcom@ietf.org>; Thu, 30 Aug 2001 13:09:36 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7UHAap12160
	for <midcom@ietf.org>; Thu, 30 Aug 2001 10:10:36 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn2-95.cisco.com [10.21.112.95])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAP13419;
	Thu, 30 Aug 2001 10:10:24 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 30 Aug 2001 13:10:25 -0400
Date: Thu, 30 Aug 2001 13:10:25 -0400
From: Scott Brim <swb@employees.org>
To: midcom@ietf.org
Subject: Re: [midcom] R79/R80 - current status
Message-ID: <20010830131024.D1408@SBRIM-W2K>
Reply-To: help@employees.org
Mail-Followup-To: Scott Brim <swb@employees.org>, midcom@ietf.org
References: <5.1.0.14.0.20010830123302.00a4f5c0@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010830123302.00a4f5c0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Thu, Aug 30, 2001 at 12:36:33PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Melinda Shore schrieb am Thu, Aug 30, 2001 12:36:33PM -0400:
> As things currently stand, there's consensus to delete R79.

And there will be some non-fatal response to an attempt to install a
duplicate ruleset.  Could someone please provide the replacement
requirement saying so?

> There's a proposal to replace the text in R80 with the following:
> 
> "It must be possible to deterministically predict the
> behavior the firewall in the presence of overlapping rules."
> 
> Right now there's no specific dissent (several people agree
> that R80 should be deleted but haven't addressed replacement
> text), so if you object please speak up.

OK with me.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 13:14:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22262
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:14:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04391;
	Thu, 30 Aug 2001 13:14:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04360
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 13:14:00 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB22238
	for <midcom@ietf.org>; Thu, 30 Aug 2001 13:12:41 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A459BCDF0212; Thu, 30 Aug 2001 13:14:01 -0400
Message-ID: <000d01c13177$01598dc0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "midcom mail-list" <midcom@ietf.org>
Date: Thu, 30 Aug 2001 13:12:53 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [midcom] draft-penfield-midcom-realms-00.txt
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,

I have submitted my "contest of champions" Internet-Draft to the IETF. Until
it is posted/announced, it can be accessed at the URL below.

Title : MIDCOM Topology Using Realms
Author : Bob Penfield
Filename : draft-penfield-midcom-realms-00.txt
Pages : 8
Date : 30-Aug-01

At the 51st IETF meeting in London, there was much disagreement in
 the MIDCOM working group about the need for topology information in
 the MIDCOM requirements. It was decided that there should be a
 "contest of champions" in which interested parties write drafts
 describing their solution to the problem.

 This document presents a proposal for the inclusion of minimal
 topological information in the MIDCOM protocol by the use of
 abstract realms.

http://www.acmepacket.com/internetdrafts/draft-penfield-midcom-realms-00.txt

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com





_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 13:14:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22275
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:14:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04349;
	Thu, 30 Aug 2001 13:13:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04318
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 13:13:53 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22229
	for <midcom@ietf.org>; Thu, 30 Aug 2001 13:12:34 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7UHDO800893
	for <midcom@ietf.org>; Thu, 30 Aug 2001 10:13:24 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn2-95.cisco.com [10.21.112.95])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAP13492;
	Thu, 30 Aug 2001 10:13:20 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 30 Aug 2001 13:13:21 -0400
Date: Thu, 30 Aug 2001 13:13:21 -0400
From: Scott Brim <swb@employees.org>
To: midcom@ietf.org
Subject: Re: [midcom] R79/R80 - current status
Message-ID: <20010830131321.A540@SBRIM-W2K>
Mail-Followup-To: Scott Brim <swb@employees.org>, midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Please do NOT reply to my previous message - I accidentally stuck in a
reply-to header line, and a number of people are going to be confused if
you actually do reply.

If you are going to reply, reply to this one instead.

..Scott (who plays with mail agents too much)


Melinda Shore schrieb am Thu, Aug 30, 2001 12:36:33PM -0400:
> As things currently stand, there's consensus to delete R79.

And there will be some non-fatal response to an attempt to install a
duplicate ruleset.  Could someone please provide the replacement
requirement saying so?

> There's a proposal to replace the text in R80 with the following:
> 
> "It must be possible to deterministically predict the
> behavior the firewall in the presence of overlapping rules."
> 
> Right now there's no specific dissent (several people agree
> that R80 should be deleted but haven't addressed replacement
> text), so if you object please speak up.

OK with me.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Thu Aug 30 13:57:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23472
	for <midcom-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:57:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05031;
	Thu, 30 Aug 2001 13:41:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05000
	for <midcom@ns.ietf.org>; Thu, 30 Aug 2001 13:40:59 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22851
	for <midcom@ietf.org>; Thu, 30 Aug 2001 13:39:39 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7UHeX826457
	for <midcom@ietf.org>; Thu, 30 Aug 2001 10:40:33 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn2-95.cisco.com [10.21.112.95])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAP14137;
	Thu, 30 Aug 2001 10:40:27 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 30 Aug 2001 13:40:27 -0400
Date: Thu, 30 Aug 2001 13:40:27 -0400
From: Scott Brim <swb@employees.org>
To: midcom@ietf.org
Subject: Re: [midcom] R79/R80 - current status
Message-ID: <20010830134027.A1784@SBRIM-W2K>
Mail-Followup-To: Scott Brim <swb@employees.org>, midcom@ietf.org
References: <5.1.0.14.0.20010830123302.00a4f5c0@mira-sjc5-4.cisco.com> <20010830170723.44459.qmail@web14305.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010830170723.44459.qmail@web14305.mail.yahoo.com>; from ar_rayhan@yahoo.ca on Thu, Aug 30, 2001 at 01:07:23PM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Abdallah Rayhan schrieb am Thu, Aug 30, 2001 01:07:23PM -0400:
> --- Melinda Shore <mshore@cisco.com> wrote:
> > As things currently stand, there's consensus to delete R79.
> > There's a proposal to replace the text in R80 with the following:
> > 
> > "It must be possible to deterministically predict the
> > behavior the firewall in the presence of overlapping rules."
>  
> This statement defines the behavior of the firewall instead
> of the midcom protocol. I propose the following text instead:
> 
> "It is possible for descriptors, defining filtering and/or NAT 
> rules, to overlap when requests from the same (various) agent(s) 
> are formulated. It SHOULD be possible to deterministically
> discern the outcome of processing the new descriptors in 
> conjunction with what previously being accommodated by the 
> middlebox being delete, add or modify request operation." 
> 
> I am using "SHOULD" because it is possible to have a stupid 
> request that does not make sense in the context of application
> or the request. Otherwise, reject the request.

This confuses me.  I understand the short version (and I think it is
about the protocol -- since what we're putting a requirement on is
predictability of the result of a protocol exchange).  Your version is
long to start with, introduces terms we don't have clear definitions for
(e.g. "descriptor"), uses SHOULD where I really think a MUST is required
(any stupid request should be trashed -- only an acceptable overlapping
rule is relevant) ... and then I get lost in the uses of "being" near
the end.  Did you leave a couple of words out?

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 31 07:04:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28236
	for <midcom-archive@odin.ietf.org>; Fri, 31 Aug 2001 07:04:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08251;
	Fri, 31 Aug 2001 07:00:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08221
	for <midcom@ns.ietf.org>; Fri, 31 Aug 2001 07:00:49 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27993;
	Fri, 31 Aug 2001 06:59:27 -0400 (EDT)
Message-Id: <200108311059.GAA27993@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: midcom@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 31 Aug 2001 06:59:27 -0400
Subject: [midcom] I-D ACTION:draft-penfield-midcom-realms-00.txt
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: MIDCOM Topology Using Realms
	Author(s)	: B. Penfield
	Filename	: draft-penfield-midcom-realms-00.txt
	Pages		: 8
	Date		: 30-Aug-01
	
At the 51st IETF meeting in London, there was much disagreement in 
the MIDCOM working group about the need for topology information in 
the MIDCOM requirements. It was decided that there should be a 
'contest of champions' in which interested parties write drafts 
describing their solution to the problem. 
This document presents a proposal for the inclusion of minimal 
topological information in the MIDCOM protocol by the use of 
abstract realms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-penfield-midcom-realms-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-penfield-midcom-realms-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-penfield-midcom-realms-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010830140904.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-penfield-midcom-realms-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-penfield-midcom-realms-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010830140904.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 31 11:45:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08242
	for <midcom-archive@odin.ietf.org>; Fri, 31 Aug 2001 11:45:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15558;
	Fri, 31 Aug 2001 11:45:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15527
	for <midcom@ns.ietf.org>; Fri, 31 Aug 2001 11:45:06 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08154
	for <midcom@ietf.org>; Fri, 31 Aug 2001 11:43:43 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7VFgfn04698
	for <midcom@ietf.org>; Fri, 31 Aug 2001 08:42:41 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp215.cisco.com [10.21.64.215])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABQ01006;
	Fri, 31 Aug 2001 08:44:12 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 31 Aug 2001 11:45:50 -0400
To: midcom@ietf.org
From: Melinda Shore <mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] R80
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

The text in R80 has been replaced with the following, which has
the agreement of the working group:

"It must be possible to deterministically predict the
behavior of the firewall in the presence of overlapping rules."

This may end up being revisited when the next version of the 
requirements document comes out, per Keith's comments about
specificity.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 31 12:38:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09851
	for <midcom-archive@odin.ietf.org>; Fri, 31 Aug 2001 12:38:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18728;
	Fri, 31 Aug 2001 12:38:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18697
	for <midcom@ns.ietf.org>; Fri, 31 Aug 2001 12:37:59 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09800
	for <midcom@ietf.org>; Fri, 31 Aug 2001 12:36:38 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7VGbSg11209
	for <midcom@ietf.org>; Fri, 31 Aug 2001 17:37:28 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 31 Aug 2001 17:37:10 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <R3T0FR8A>;
          Fri, 31 Aug 2001 17:37:07 +0100
Message-ID: <9154CB41F208D5118DD200508BE39C30445228@zjguc006.europe.nortel.com>
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "Midcom IETF (E-mail)" <midcom@ietf.org>
Date: Fri, 31 Aug 2001 17:37:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1323B.3878E1B0"
Subject: [midcom] Network topology draft
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C1323B.3878E1B0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1323B.3878E1B0"


------_=_NextPart_001_01C1323B.3878E1B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
I have submitted a network topology draft, I'm sending it in attach since it
will probably be announced late today or on Monday morning.
Cheers 
Cedric
 <<draft-aoun-midcom-agent-information-00.txt>> 

------_=_NextPart_001_01C1323B.3878E1B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Network topology draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I have submitted a network topology =
draft, I'm sending it in attach since it will probably be announced =
late today or on Monday morning.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cedric</FONT>
<BR><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;draft-aoun-midcom-agent-information-00.txt&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1323B.3878E1B0--

------_=_NextPart_000_01C1323B.3878E1B0
Content-Type: text/plain;
	name="draft-aoun-midcom-agent-information-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-aoun-midcom-agent-information-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

                                   =20
   MIDCOM Working Group                                            =
C.Aoun
   Internet Draft                                                   =
S.Sen
   Category: Informational                                Nortel =
Networks
   Expires on February 2001                                   August =
2001=20
                                        =20
                                             =20
                     =20
                    Required Information in Midcom Agents=20
       =20
                  <draft-aoun-midcom-agent-information-00.txt>=20
    =20
   Status of this Memo
=20
   This document is an Internet-Draft and is in full conformance=20
   with all provisions of Section 10 of RFC2026.=20
   Internet-Drafts are working documents of the Internet Engineering =20
   Task Force (IETF), its areas, and its working groups.  Note that     =
 =20
   other groups may also distribute working documents as Internet-=20
   Drafts.=20
   Internet-Drafts are draft documents valid for a maximum of six =20
   months and may be updated, replaced, or obsoleted by other documents =
=20
   at any time.  It is inappropriate to use Internet-Drafts as =20
   reference material or to cite them other than as "work in progress." =

   The list of current Internet-Drafts can be accessed at=20
   =20
        http://www.ietf.org/ietf/1id-abstracts.txt=20
   =20
   The list of Internet-Draft Shadow Directories can be accessed at=20
   =20
   =20
        http://www.ietf.org/shadow.html
                                       =20
    =20
Abstract=20
      =20
   This draft is part of a gladiator contest within the MIDCOM WG to=20
   determine what network topology information is needed at the Midcom =
agent.=20
   =20
   By taking out application awareness from Middle Boxes in the=20
   networks, and keeping this application knowledge in the application=20
   devices (the Midcom Agents); sufficient information needs to be put=20
   in the Midcom Agent to allow them to fulfill their responsibility.=20
   =20
   =20
    =20
    =20
   Table of Contents=20
   Abstract...........................................................1 =

   1 Introduction.....................................................2 =

   2 Conventions used in this document................................2 =

   3 Used Terminology in the draft....................................2 =

   4 Middle Box examples and Midcom requirements......................2 =

   4.1 Middle Boxes connected to two address realms...................3 =

=20


Internet Draft  Required information in Midcom Agents      August 2001=20

   4.2 Middle Boxes connected networks having overlapped addresses....5 =

   4.3  Multi-homed Middleboxes acting as media proxies...............6 =

   5 Summary..........................................................6 =

   6 References.......................................................6 =

   7 Acknowledgments..................................................7 =

   8 Author's Address.................................................7 =

   9 Intellectual Property Statement..................................7 =

   10 Full Copyright Statement........................................8 =

   =20
=20
=20
1  Introduction
=20
   The Midcom Agent (MA) should have sufficient information to request=20
   the Middle Box to open pinholes or perform NAT binds or other=20
   specific actions on packet flows.=20
   =20
   This draft presents several types of Middle Boxes that could be=20
   deployed in networks and the type of information that a MA needs=20
   to have to perform it's tasks properly.=20
   =20
2   Conventions used in this document =20
       =20
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =
=20
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in =20
    this document are to be interpreted as described in RFC-2119. =20
   =20
3  Used Terminology in the draft=20
=20
   If : an interface, it could be logical (ATM VC, FR DLCI, PPP=20
   variants, IPSEC tunnel...) or physical.=20
   =20
   Overlapped address networks: Networks having overlapping addresses=20
   =20
   Loopback address: Address that is not linked to an interface=20
   =20
4  Middle Box examples and Midcom requirements=20
=20
   This section describes several Middle Boxes (MB) that are deployed=20
   in networks:=20
   - Middle Box connected to two address realms (that don't have=20
   overlapped addresses).=20
   - Middle Box connected to networks having overlapped addresses.=20
   - Multi-homed Middle Box acting as a media proxy.=20
   =20
   The first category include the residential and enterprise Middle=20
   Boxes, the second includes the Provider Provisioned Middle Boxes or=20
   other Middle Boxes interfacing networks that have overlapped=20
   addresses and the third includes, for example, RTP Proxies that are=20
   commonly used to allow VoIP media to pass through a firewall which=20
   does not have application awareness nor supporting Midcom=20
=20


Aoun, Sen       Informational - Expires February 2002         [Page 2]
Internet Draft  Required information in Midcom Agents      August 2001  =
  =20
   =20
4.1  Middle Boxes connected to two address realms=20
=20
   =20
   ++++++++++++++++++++  =20
   + Customer     If1 +  =20
   + network  +++++---+       o o o o o o         +++++++++++++++++++=20
   +          +MB1+If2+-------o           o       +Telephony Service+=20
   +   If5----+++++   +      oThe Internet o------+ Provider        + =20
   + If4-----/   +    +       o o o o o o o       + ++++            +=20
   +       If3---+    +                           + +MA+            +=20
    ++++++++++++++++++                            + ++++            +=20
                                                  +++++++++++++++++++=20
   =20
   This example covers Middle Boxes that can have two (or more)=20
   interfaces and connected to 2 address realms (the=20
   enterprise realm and the public realm).=20
   The example MB has 5 interfaces. 3 of the interfaces (could be=20
   one in case of a 2 interfaces MB)are used to connect internal hosts=20
   (if3,4,5) and 2 interfaces (could just be one in case of 2 interface =

   Middle Box)are used to connect to the customer's ISP (if1,2). =20
   =20
   This MB is similar to all existing MB implementations, in that MB=20
   packet filtering profiles are bounded to interfaces.=20
   In the case of the NAT function, the profile is unique to the MB.=20
   For packet filters, 2 profiles may exist: one for the egress and one =
for=20
   ingress.=20
   =20
   =20
   We shall not consider other networks (the model will still be=20
   unchanged) since the purpose of the draft is to determine what=20
   information the Midcom Agent requires to allow particular flows to=20
   traverse a Middle Box.=20
   =20
   Primary things the Midcom Agent needs to know when it needs to ask a =

   particular MB to apply certain tasks on a flow: =20
   -Which MB the application flows will be traversing, this is=20
   currently out of scope of the MIDCOM WG=20
   -How to address the MB (loopback address or another reachable=20
   address)=20
   -Provide a matching or filter expression to enable the MB to=20
   identify the flow=20
   -Which tasks or queries to execute (Open a pinhole, get a BIND ...)=20
   =20
=20










Aoun, Sen       Informational - Expires February 2002         [Page 3]
Internet Draft  Required information in Midcom Agents      August 2001=20

   What about the interface and the direction?=20
   The direction information is relevant to the direction of the=20
   packets on the interfaces (coming in or going out of the interface). =
=20
   =20
   When the MA will send the Midcom message, it will contain a flow=20
   matching expression and the action to apply to the flow. The MB will =

   know which profile to update (i.e. which interface is traversed and=20
   which direction).=20
   The direction is implied by the source and destination contained in=20
   the flow matching expression.=20
   =20
   The routing software could determine based on the routing table,=20
   which interface the packets may traverse; the rule will then be=20
   added to the proper MB function profile.=20
   If the packet might traverse several interfaces the rule will be set =

   on all the related profiles.=20
   There is a potential ambiguity when the source of the flow is not=20
   known.=20
   Typically this is the case of VoIP applications where the receiver=20
   is known but not the sender (initially since not included in the=20
   SDP).=20
   In this case, all packet filter profiles need to be appended with=20
   the new rule (including packet filters that are bounded to if3,4=20
   &5).=20
   Alternatively an optional parameter within the matching expression=20
   could be used to express the directionality of the flow.=20
   As an example:=20
   -WAN could mean that the flow is from devices external to the=20
   network (i.e. limiting the packet filter profiles to the ingress=20
   ones of If1 & If2)=20
   -LAN could mean that the flow is from devices internal to the=20
   network (i.e. limiting the packet filter profiles to the ones of =20
     if3,4,5)=20
   =20
   The usage of "LAN" could address certain enterprise networks where=20
   packet filters are introduced between certain departments (case=20
   where packet filter profiles on internal interfaces require to be=20
   updated with new rule set).=20
=20















Aoun, Sen       Informational - Expires February 2002         [Page 4]
Internet Draft  Required information in Midcom Agents      August 2001=20
   =20
   =20
4.2  Middle Boxes connected networks having overlapped addresses=20
   =20
   Provider provisioned middle boxes addresses subscribers that have=20
   outsourced their Middle Box services to their Internet Service=20
   Providers (ISP).=20
   =20
   This example shows 2 customer networks that are provided:=20
     - The Internet connectivity service by the same ISP=20
     - Their telephony service by either the same or different=20
   Telephony Service Provider (TSP) =20
   =20
   +++++++++++++              +++++++++++++=20
   +           +         If1  +ISP        +=20
   +Cust A     +--------------+--++++++   +  =20
   + 10/8      +         If2  +  + MB1+   + If3   o  o  o o=20
   +++++++++++++          ----+--+    +---+----o            o=20
                         /    +  ++++++   +\   =20
                        /     +++++++++++++ \  o Internet   o=20
                       /                 If4 \-           o =20
                      /                         o o o o o   =20
   ++++++++++        /                            +    =20
   +        +       /                             +    =20
   +Cust B  +-------                              +=20
   + 10/8   +                                +++++++++++++=20
   ++++++++++                                +TSP        +  =20
                                             + ++++      +       =20
                                             + +MA+      +  =20
                                             + ++++      +  =20
                                             +++++++++++++=20
   =20
   The main difference between the previous example and this one is=20
   that the physical MB, is subdivided into several logical MBs.=20
   Each logical MB has it's own interfaces and MB function profiles.
=09
   The logical MBs need to be addressed with separate identifiers.
   This is separate from the loop address which was discussed =
previously.
	=20
   To communicate with the logical MB, the MA will require to use the =
logical    =20
   MB's identifier within the Midcom protocol.=20
   =20
   =20
   There is potentially another variant in which even the logical=20
   Middle Box could be connected to "overlapped addresses" networks.=20
   =20
   In this case, the Midcom Agent will need to inform the Middle Box=20
   about the address's realm (either source or destination)of the=20
   specified flow.=20
   =20
=20


Aoun, Sen       Informational - Expires February 2002         [Page 5]
Internet Draft  Required information in Midcom Agents      August 2001=20

   Both Middle Box identifier and the realm identifier should be=20
   optional parameters in the Midcom protocol.=20
   =20
   Apart from the previous, the information required for the MA and=20
   provided to the MB via the Midcom protocol is similar to 3.1=20
   =20
4.3  Multi-homed Middleboxes acting as media proxies=20
=20
=20
   +++++++++++++              +++++++++++++=20
   +           +         If1  +ISP        +=20
   + A         +--------------+--++++++   +  =20
   + private   +         If2  +  + MB1+   + If3   o  o  o o=20
   +++++++++++++          ----+--+    +---+----o            o=20
                         /    +  ++++++   +\   =20
                        /     +++++++++++++ \  o Internet   o=20
                       /        /If5    If4  \-           o =20
                      /
                               /                o o o o o   =20
   ++++++++++        /        /                        =20
   +   B    +       /    ++++++++++                              =20
   +private +-------     +   C    +               =20
   ++++++++++            +private +               =20
                         ++++++++++=20
=20
=20
   This case can be considered a special case of the scenario depicted=20
   in Section 4.2. The MB1 in the above figure is a multi-homed RTP=20
   Proxy (which terminates an RTP session in one interface and=20
   initiates a new one from the other interface). Assume that networks=20
   A, B and C contain private IP addresses, which overlap. To allow a=20
   VoIP session through the Proxy, we need allocation of either two=20
   private IP addresses (if a call is made between networks A, B or C), =

   or a private IP address and a public IP address (if a call is made=20
   between an endpoint in networks A/B/C and an endpoint in the public=20
   Internet). In this case the Agent needs to specify the interface (or =

   realm) through which the media will traverse the MB in order to make =

   the MB assign IP addresses and perform proper binding of the RTP=20
   media with the interface.  =20
   =20
   =20
5  Summary=20
   The main issue to resolve while deploying Midcom enabled Middle=20
   Boxes will be on providing the MB presence on the path of the flows=20
   to the MAs.=20
   Manual configuration will be a BIG operational burden on the=20
   application service providers, and will not  be the most common=20
   solution (ref  [DSCVRYCA]).=20
   Extending the syntax to allow the MA to address properly a MB=20
   (logical or physical) or to provide a proper flow filtering=20
   expression is not a complicated issue.=20
   The Middle Box discovery is still a key piece of the puzzle. =20
   =20
6  References
=20

Aoun, Sen       Informational - Expires February 2002         [Page 6]

        =20
      =20
     [MDCMFRWK]P.Srisuresh,J.Kuthan, J.Rosenberg," MIDCOM Architecture=20
               & Framework",=20
               Internet draft, draft-ietf-midcom-framework-03.txt=20
                =20
     [MDCMREQ] R.Swale, P.Mart, P.Sijben, " Middlebox Control (MIDCOM)=20
               Protocol Architecture and Requirements",=20
               Internet draft, draft-ietf-midcom- requirements-02.txt=20
     [DSCVRYCA] C.Aoun, " Network topology considerations in =20
                the MIDCOM Architectural framework",=20
                Internet draft, draft-aoun-midcom-network-00.txt =20
     =20
               =20
   =20
7  Acknowledgments  =20
   The author would like to thank the following people for their useful =
=20
   comments and suggestions related to this draft: Louis-Nicolas Hamer, =


   Julian Mitchell, Mick O'Doherty and others in Nortel Networks.
                                                      =20
8  Author's Address=20

   Cedric Aoun=20
   Nortel Networks=20
   33 Quai Paul Doumer=20
   Paris La Defense=20
   92415 Courbevoie Cedex=20
   France=20
   Email: cedric.aoun@nortelnetworks.com=20
 =20
   Sanjoy Sen =20
   Nortel Networks   =20
   2375 N. Glenville Drive, Building B, =20
   Richardson, TX-75082=20
   USA  =20
   E-mail: sanjoy@nortelnetworks.com=20
9  Intellectual Property Statement=20
   =20
   The IETF takes no position regarding the validity or scope of any=20
   intellectual property or other rights that might be claimed to=20
   pertain to the implementation or use of the technology described in=20
   this document or the extent to which any license under such rights=20
   might or might not be available; neither does it represent that it=20
   has made any effort to identify any such rights.  Information on the =

   IETF's procedures with respect to rights in standards-track and=20
   standards-related documentation can be found in BCP-11.  Copies of=20
   claims of rights made available for publication and any assurances=20
   of licenses to be made available, or the result of an attempt made=20
   to obtain a general license or permission for the use of such=20
   proprietary rights by implementors or users of this specification=20
   can be obtained from the IETF Secretariat.=20
     =20
   The IETF invites any interested party to bring to its attention any=20
   copyrights, patents or patent applications, or other proprietary=20
Aoun, Sen       Informational - Expires February 2002         [Page 7]
 Internet Draft  Required information in Midcom Agents      August 2001 =

  =20
   rights which may cover technology that may be required to practice=20
   this standard.  Please address the information to the IETF Executive =

   Director.=20
   =20
  =20
10 Full Copyright Statement
                           =20
   Copyright (C) The Internet Society (2000).  All Rights Reserved.=20
      =20
   This document and translations of it may be copied and furnished to=20
   others, and derivative works that comment on or otherwise explain it =

   or assist in its implementation may be prepared, copied, published=20
   and distributed, in whole or in part, without restriction of any=20
   kind, provided that the above copyright notice and this paragraph=20
   are included on all such copies and derivative works.  However, this =

   document itself may not be modified in any way, such as by removing=20
   the copyright notice or references to the Internet Society or other=20
   Internet organizations, except as needed for the purpose of=20
   developing Internet standards in which case the procedures for=20
   copyrights defined in the Internet Standards process must be=20
   followed, or as required to translate it into languages other than=20
   English.  The limited permissions granted above are perpetual and=20
   will not be revoked by the Internet Society or its successors or=20
   assigns.  This document and the information contained=20
   herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND=20
   THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,=20
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT=20
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR=20
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20
   =20
   PARTICULAR PURPOSE."=20
 =20
=20
=20



















Aoun, Sen       Informational - Expires February 2002         [Page 8]

------_=_NextPart_000_01C1323B.3878E1B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 31 12:49:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10094
	for <midcom-archive@odin.ietf.org>; Fri, 31 Aug 2001 12:49:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18890;
	Fri, 31 Aug 2001 12:46:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18859
	for <midcom@ns.ietf.org>; Fri, 31 Aug 2001 12:46:20 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10005
	for <midcom@ietf.org>; Fri, 31 Aug 2001 12:44:59 -0400 (EDT)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7VGjxp04228;
	Fri, 31 Aug 2001 09:45:59 -0700 (PDT)
Received: from SBRIM-W2K (sjc-vpn2-58.cisco.com [10.21.112.58])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAQ07223;
	Fri, 31 Aug 2001 09:45:47 -0700 (PDT)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 31 Aug 2001 12:45:51 -0400
Date: Fri, 31 Aug 2001 12:45:51 -0400
From: Scott Brim <swb@employees.org>
To: Melinda Shore <mshore@cisco.com>
Cc: midcom@ietf.org
Subject: Re: [midcom] R80
Message-ID: <20010831124550.G1560@SBRIM-W2K>
Mail-Followup-To: Scott Brim <swb@employees.org>,
	Melinda Shore <mshore@cisco.com>, midcom@ietf.org
References: <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Fri, Aug 31, 2001 at 11:45:50AM -0400
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

Melinda Shore schrieb am Fri, Aug 31, 2001 11:45:50AM -0400:
> The text in R80 has been replaced with the following, which has
> the agreement of the working group:
> 
> "It must be possible to deterministically predict the
> behavior of the firewall in the presence of overlapping rules."
> 
> This may end up being revisited when the next version of the 
> requirements document comes out, per Keith's comments about
> specificity.

OK if I change 'firewall' to 'middlebox'?

_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 31 13:15:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10964
	for <midcom-archive@odin.ietf.org>; Fri, 31 Aug 2001 13:15:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19499;
	Fri, 31 Aug 2001 13:05:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19468
	for <midcom@ns.ietf.org>; Fri, 31 Aug 2001 13:05:26 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10521
	for <midcom@ietf.org>; Fri, 31 Aug 2001 13:04:04 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7VH56p17778;
	Fri, 31 Aug 2001 10:05:06 -0700 (PDT)
Received: from spandex.cisco.com (sjc-vpn-tmp215.cisco.com [10.21.64.215])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ABQ04084;
	Fri, 31 Aug 2001 10:04:25 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010831130546.00a6c570@mira-sjc5-4.cisco.com>
X-Sender: mshore@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 31 Aug 2001 13:06:02 -0400
To: Scott Brim <swb@employees.org>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] R80
Cc: midcom@ietf.org
In-Reply-To: <20010831124550.G1560@SBRIM-W2K>
References: <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com>
 <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

At 12:45 PM 8/31/01 -0400, Scott Brim wrote:
>OK if I change 'firewall' to 'middlebox'? 

Please do!

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom


From midcom-admin@ietf.org  Fri Aug 31 16:40:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15629
	for <midcom-archive@odin.ietf.org>; Fri, 31 Aug 2001 16:40:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24020;
	Fri, 31 Aug 2001 16:40:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23991
	for <midcom@ns.ietf.org>; Fri, 31 Aug 2001 16:40:06 -0400 (EDT)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15609
	for <midcom@ietf.org>; Fri, 31 Aug 2001 16:38:42 -0400 (EDT)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP id D5A068251
	for <midcom@ietf.org>; Fri, 31 Aug 2001 15:40:04 -0500 (CDT)
Received: from localhost (amolitor@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id PAA27028
	for <midcom@ietf.org>; Fri, 31 Aug 2001 15:40:04 -0500 (CDT)
X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs
Date: Fri, 31 Aug 2001 15:40:04 -0500 (CDT)
From: Andrew Molitor <amolitor@visi.com>
To: midcom@ietf.org
Message-ID: <Pine.GSO.4.21.0108311538420.26567-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [midcom] Draft Submitted -
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

	I have just sent draft-molitor-midbox-telephony-topology-00.txt,
"Topology Considerations for IP Telephony MIDCOM Agents" in which I natter
away at some length about directionality considerations for middleboxes
and IP telephony.

	Hopefully I have not botched anything, and it will make its
way into the relevant places in the fullness of time.

		Andrew



_______________________________________________
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom