From mailnull@www1.ietf.org Tue Oct 1 05:29:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03779 for ; Tue, 1 Oct 2002 05:29:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g919UUf13728 for midcom-archive@odin.ietf.org; Tue, 1 Oct 2002 05:30:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g919TBv13471; Tue, 1 Oct 2002 05:29:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g919S6v13388 for ; Tue, 1 Oct 2002 05:28:06 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03719 for ; Tue, 1 Oct 2002 05:26:06 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g919RXU01610; Tue, 1 Oct 2002 11:27:34 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 37C056786D; Tue, 1 Oct 2002 11:27:31 +0200 (CEST) Date: Tue, 01 Oct 2002 11:27:30 +0200 From: Juergen Quittek To: Tom-PT Taylor , midcom@ietf.org Cc: "'Martin Stiemerling'" Message-ID: <11099660.1033471650@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA000400DCDC@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA000400DCDC@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Midcom Semantics: Reserve vs. Address-Bind Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, We see our approach rather as a one-step approach with a rare exception. In most cases just the integrated (second) step of binding and enabling is required. Only for very special scenarios, where the agent has insufficient information, the (first) reservation step is required. You split the actions required into two steps that are always reqired. In contrary, we split the actions into one that is usually sufficient and one that is only required additionally in rather rare special cases where the agent lacks sufficient information for just performing a single step. You say you belive that in case of twice-NAT, three steps would be required with our approach in some cases. We tried hard to find such a case, but we did not find any. Could you give us an example where our approach would require three steps? Juergen -- Tom-PT Taylor wrote on 30 September 2002 20:21 -0400: > In my analysis of Midcom semantics as presented in > draft-taylor-midcom-semgen-00.txt, I separate rule instantiation into two > phases: address binding and flow enabling. In > draft-stiemerling-midcom-semantics-02.txt the separation instead is into > address reservation and flow enabling. I have to ask the Working Group: > which is a more realistic view of Middlebox operation? > > Just to show the difference: according to my analysis, setting up a combined > NAT-firewall operation is done in two steps: > > (1) Provide the "actual" source and destination address-ports (one or the > other may be "ANY"), and request a binding. The middlebox will return the > intermediate source and destination addresses associated with the binding. > In the twice-NAT case both of these will correspond to interfaces on the > middlebox itself. Otherwise at least one will be the same as the actual > source or destination respectively. > > (2) Request that a flow be enabled for packets with the given actual source > and intermediate destination, mapping the matching packets to the > intermediate source and actual destination. > > These two steps are the same regardless of whether we are dealing with an > incoming or outgoing flow, and regardless of whether we are dealing with > pure firewall, NAT-firewall, or twice NAT and firewall. > > As Juergen and Martin see it, the first step is to reserve addresses and > ports on a given side of the middlebox. If they are needed on both sides > (and I believe that is so for twice-NAT), then two reservation requests are > made. > > Their second step is then to request a flow and binding. The basic > difference is that they do not supply any information in the first step > other than what they need reserved. It strikes me that this deprives the > middlebox of the opportunity to apply policy to address-port reservation > based on source or destination. The question is whether this matters. > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 1 10:51:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20553 for ; Tue, 1 Oct 2002 10:51:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91Eqk504340 for midcom-archive@odin.ietf.org; Tue, 1 Oct 2002 10:52:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91ElGv04067; Tue, 1 Oct 2002 10:47:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Ekxv04031 for ; Tue, 1 Oct 2002 10:46:59 -0400 Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20293 for ; Tue, 1 Oct 2002 10:44:58 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91Ek9b07763; Tue, 1 Oct 2002 10:46:09 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Oct 2002 10:46:13 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DCE4@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , midcom@ietf.org Cc: "'Martin Stiemerling'" Subject: RE: [midcom] Re: Midcom Semantics: Reserve vs. Address-Bind Date: Tue, 1 Oct 2002 10:46:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26959.458124D4" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C26959.458124D4 Content-Type: text/plain It's a little ironic that my initial analysis called for a single step, but I was convinced otherwise by considerations you raised. I agree that you can do everything in a single step if you have all the informatiopn policy requires at that point, but I don't think this affects the core of my observation on the difference between our approaches. The real difference still lies in the matter of simple address reservation versus reservation of address bindings. I ask again: does the difference matter? My approach gives the middlebox slightly more information on which to base its decision. On the question of when two different address reservations are needed: consider a situation where twice-NAT is in use because the interior and exterior address spaces overlap. Then as I understand it, taking outgoing packets as an example, the internal endpoint needs an intermediate destination at the middlebox which the latter mapps to the final destination when it passes the packet. At the same time, the middlebox must map the internal endpoint address as source to a new source address on the middlebox itself. Thus to enable this flow you need to reserve one address-port on each side of the middlebox. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Tuesday, October 01, 2002 5:28 AM > To: Taylor, Tom-PT [CAR:B602:EXCH]; midcom@ietf.org > Cc: 'Martin Stiemerling' > Subject: [midcom] Re: Midcom Semantics: Reserve vs. Address-Bind > > > Tom, > > We see our approach rather as a one-step approach with a rare > exception. In most cases just the integrated (second) step of > binding and enabling is required. Only for very special > scenarios, where the agent has insufficient information, the > (first) reservation step is required. > > You split the actions required into two steps that are always > reqired. In contrary, we split the actions into one that is > usually sufficient and one that is only required additionally > in rather rare special cases where the agent lacks sufficient > information for just performing a single step. > > You say you belive that in case of twice-NAT, three steps > would be required with our approach in some cases. We tried > hard to find such a case, but we did not find any. Could you > give us an example where our approach would require three steps? > > Juergen > > > -- Tom-PT Taylor wrote on 30 September 2002 20:21 -0400: > > > In my analysis of Midcom semantics as presented in > > draft-taylor-midcom-semgen-00.txt, I separate rule > instantiation into > > two > > phases: address binding and flow enabling. In > > draft-stiemerling-midcom-semantics-02.txt the separation > instead is into > > address reservation and flow enabling. I have to ask the > Working Group: > > which is a more realistic view of Middlebox operation? > > > > Just to show the difference: according to my analysis, setting up a > > combined NAT-firewall operation is done in two steps: > > > > (1) Provide the "actual" source and destination > address-ports (one or > > the other may be "ANY"), and request a binding. The middlebox will > > return the intermediate source and destination addresses associated > > with the binding. In the twice-NAT case both of these will > correspond > > to interfaces on the middlebox itself. Otherwise at least > one will be > > the same as the actual source or destination respectively. > > > > (2) Request that a flow be enabled for packets with the > given actual > > source and intermediate destination, mapping the matching > packets to > > the intermediate source and actual destination. > > > > These two steps are the same regardless of whether we are > dealing with > > an incoming or outgoing flow, and regardless of whether we > are dealing > > with pure firewall, NAT-firewall, or twice NAT and firewall. > > > > As Juergen and Martin see it, the first step is to reserve > addresses > > and ports on a given side of the middlebox. If they are needed on > > both sides (and I believe that is so for twice-NAT), then two > > reservation requests are made. > > > > Their second step is then to request a flow and binding. The basic > > difference is that they do not supply any information in the first > > step other than what they need reserved. It strikes me that this > > deprives the middlebox of the opportunity to apply policy to > > address-port reservation based on source or destination. > The question > > is whether this matters. > > > > Tom Taylor > > taylor@nortelnetworks.com > > Ph. +1 613 736 0961 (ESN 396 1490) > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C26959.458124D4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: Midcom Semantics: Reserve vs. = Address-Bind

It's a little ironic that my initial analysis called = for a single step, but I was convinced otherwise by considerations you = raised.  I agree that you can do everything in a single step if = you have all the informatiopn policy requires at that point, but I = don't think this affects the core of my observation on the difference = between our approaches.  The real difference still lies in the = matter of simple address reservation versus reservation of address = bindings.  I ask again: does the difference matter?  My = approach gives the middlebox slightly more information on which to base = its decision.

On the question of when two different address = reservations are needed: consider a situation where twice-NAT is in use = because the interior and exterior address spaces overlap.  Then as = I understand it, taking outgoing packets as an example, the internal = endpoint needs an intermediate destination at the middlebox which the = latter mapps to the final destination when it passes the packet.  = At the same time, the middlebox must map the internal endpoint address = as source to a new source address on the middlebox itself.  Thus = to enable this flow you need to reserve one address-port on each side = of the middlebox.

> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] =
> Sent: Tuesday, October 01, 2002 5:28 AM
> To: Taylor, Tom-PT [CAR:B602:EXCH]; = midcom@ietf.org
> Cc: 'Martin Stiemerling'
> Subject: [midcom] Re: Midcom Semantics: Reserve = vs. Address-Bind
>
>
> Tom,
>
> We see our approach rather as a one-step = approach with a rare
> exception. In most cases just the integrated = (second) step of
> binding and enabling is required. Only for very = special
> scenarios, where the agent has insufficient = information, the
> (first) reservation step is required.
>
> You split the actions required into two steps = that are always
> reqired. In contrary, we split the actions into = one that is
> usually sufficient and one that is only = required additionally
> in rather rare special cases where the agent = lacks sufficient
> information for just performing a single = step.
>
> You say you belive that in case of twice-NAT, = three steps
> would be required with our approach in some = cases. We tried
> hard to find such a case, but we did not find = any. Could you
> give us an example where our approach would = require three steps?
>
>     Juergen
>
>
> -- Tom-PT Taylor wrote on 30 September 2002 = 20:21 -0400:
>
> > In my analysis of Midcom semantics as = presented in
> > draft-taylor-midcom-semgen-00.txt, I = separate rule
> instantiation into
> > two
> > phases: address binding and flow = enabling.  In
> > draft-stiemerling-midcom-semantics-02.txt = the separation
> instead is into
> > address reservation and flow = enabling.  I have to ask the
> Working Group:
> > which is a more realistic view of = Middlebox operation?
> >
> > Just to show the difference: according to = my analysis, setting up a
> > combined NAT-firewall operation is done in = two steps:
> >
> > (1) Provide the "actual" source = and destination
> address-ports (one or
> > the other may be "ANY"), and = request a binding.  The middlebox will
> > return the intermediate source and = destination addresses associated
> > with the binding. In the twice-NAT case = both of these will
> correspond
> > to interfaces on the middlebox = itself.  Otherwise at least
> one will be
> > the same as the actual source or = destination respectively.
> >
> > (2) Request that a flow be enabled for = packets with the
> given actual
> > source and intermediate destination, = mapping the matching
> packets to
> > the intermediate source and actual = destination.
> >
> > These two steps are the same regardless of = whether we are
> dealing with
> > an incoming or outgoing flow, and = regardless of whether we
> are dealing
> > with pure firewall, NAT-firewall, or twice = NAT and firewall.
> >
> > As Juergen and Martin see it, the first = step is to reserve
> addresses
> > and ports on a given side of the = middlebox.  If they are needed on
> > both sides (and I believe that is so for = twice-NAT), then two
> > reservation requests are made.
> >
> > Their second step is then to request a = flow and binding.  The basic
> > difference is that they do not supply any = information in the first
> > step other than what they need = reserved.  It strikes me that this
> > deprives the middlebox of the opportunity = to apply policy to
> > address-port reservation based on source = or destination. 
> The question
> > is whether this matters.
> >
> > Tom Taylor
> > taylor@nortelnetworks.com
> > Ph. +1 613 736 0961 (ESN 396 1490)
> >
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C26959.458124D4-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 4 09:22:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02810 for ; Fri, 4 Oct 2002 09:22:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94DO8f06887 for midcom-archive@odin.ietf.org; Fri, 4 Oct 2002 09:24:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94DMUv06803; Fri, 4 Oct 2002 09:22:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94DLSv06767 for ; Fri, 4 Oct 2002 09:21:28 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02729 for ; Fri, 4 Oct 2002 09:19:25 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g94DLOIm029379 for ; Fri, 4 Oct 2002 06:21:24 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC10111; Fri, 4 Oct 2002 06:16:22 -0700 (PDT) Message-Id: <200210041316.AAC10111@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 04 Oct 2002 09:21:23 -0400 Subject: [midcom] Semantics document proposal Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We need to get serious about making progress on the semantics document. Here's the proposal that the authors of the several existing drafts have agreed to: we will use Juergen Quittek et al.'s draft as the basis for the working group document, and because Tom Taylor has developed so much of the content he will continue on as co-author. Unless there are objections from the working group, the next version of the draft will be posted as a working group document. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 7 18:34:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08712 for ; Mon, 7 Oct 2002 18:34:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g97MZqU14359 for midcom-archive@odin.ietf.org; Mon, 7 Oct 2002 18:35:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97MViv14262; Mon, 7 Oct 2002 18:31:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97MU6v14211 for ; Mon, 7 Oct 2002 18:30:06 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08557 for ; Mon, 7 Oct 2002 18:27:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g97MTpaW008292 for ; Mon, 7 Oct 2002 15:29:51 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD13302; Mon, 7 Oct 2002 15:24:58 -0700 (PDT) Message-Id: <200210072224.AAD13302@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 07 Oct 2002 18:29:57 -0400 Subject: [midcom] Evaluation document update Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As the protocol evaluation document underwent IESG review they found a number of serious errors in the SNMP evaluation, so the draft is being sent back to the working group for correction. Fortunately we have a volunteer with deep SNMP expertise who has offered to help us out. The revised draft will need to go through working group last call again. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 8 08:54:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10054 for ; Tue, 8 Oct 2002 08:54:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98CtnE01860 for midcom-archive@odin.ietf.org; Tue, 8 Oct 2002 08:55:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98CpIv01771; Tue, 8 Oct 2002 08:51:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98CoJv01746 for ; Tue, 8 Oct 2002 08:50:19 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09565 for ; Tue, 8 Oct 2002 08:48:11 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g98CoGot014422 for ; Tue, 8 Oct 2002 05:50:16 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD30501; Tue, 8 Oct 2002 05:45:15 -0700 (PDT) Message-Id: <200210081245.AAD30501@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 08 Oct 2002 08:50:14 -0400 Subject: [midcom] Scott Bradner: draft-ietf-midcom-protocol-eval Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Scott Brim asked that the comments we received be forwarded. I've excerpted the meat of the discussion. Melinda ------- Forwarded Message The analysis done for SNMP has a large amount of cut-and-paste, with the same answers given for multiple questions, and little detail about how much work would be involved, or the nature of the extensions (MIBs) needed. There are places where obvious aspects of SNMP are overlooked, and other places where the potential difficulties of using SNMP are not mentioned. SNMPv1 is obviously a bad choice for configuring MIDCOM elements that provide network security, yet the bulk of the analysis describes how SNMPv1, v2c, and v3 might be used. The only version of SNMP that would be suitable for this purpose is SNMPv3. The analysis should focus on SNMPv3 and not discuss how to use SNMPv1. I object to the "however" clause in section 1.1.1; the fact that SNMP is not widely used for configuration should not be a factor unless there are stated reasons why SNMP is not widely used that impact the evaluation. The fact is SNMP is seldom used for configuration mainly because SNMPv1 doesn't have security, and as a result most standard mibs don't contain configuration objects. If MIDCOM creates a mib with configuration objects and uses SNMPv3 as the protocol, this should be fine for configuration purposes. The fact that SNMPv3 must be used comes across as a negative since it is raised in a "however" clause, but the need to support IPSec isn't raised as a "however" for the other protocols. I think these comments inadvertently color the analysis; I don't think it's a good start for an unbiased evaluation. I greatly appreciate the effort Juergen put into the analysis, and regret that nobody else in the SNMP community came forward to do this, but the resulting analysis paints a false picture of SNMP. Note that I am not complaining that SNMP didn't "win" or anything; I merely want the MIDCOM WG to have accurate information to use in making their judgements, and the information presented in this document is sometimes misleading or inaccurate. I am willing to help update the analysis to improve the accuracy of the information. Some examples of analysis that I feel are inadequate: The SNMP Approach Appendix A is pure boilerplate copied from the O&M Area web site. This appendix does not discuss the type of work that would need to be done to make SNMP a suitable candidate. Compare that to the other appendices. Appendix B discusses the possible need for an ALG, extensions to the control protocol, and application support, among other things. Appendix C discusses the need to define a Middlebox Termination type, the possible need to seperate policies and filters from the Termination type, and behavioral rules to permit multiple agents to share policy management. Appendix D discusses an IPFilterRule and the information that would be needed, evaluation order rules, and so on. Appendix A provides no analysis at this level of detail. At a minimum, Appendix A should describe probable MIB table abstractions and the objects in the tables, such as the need for a session table, and the need for attributes of a session including authentication association (maybe the SNMPv3 securityname), lifetime, and so on. For sending asynchronous messages, the SNMPv3 target mib and related mibs should be populated, but this isn't mentioned. For coordinating multiple SNMP managers, advisory locking can be used, such as the snmpTargetSpinLock in RFC2573, or policies could be associated with ownerStrings ala RMON, or Snmpconf mechanisms could be used. None of these are mentioned. The introductory material on SNMP discusses how the terminology is different - - including PDPs and PEPs. One approach to using SNMP to configure MIDCOM would be to use SnmpConf - SNMP for Configuration, which is designed explicitly to do policy management consistent with the PDP/PEP Policy architecture and it uses comparable terminology. The Snmpconf approach would be much closer to the MIDCOM architecture and the architectures of the other candidate protocols, and explicitly deals with issues such as ruleset groupings, policy conflicts, capability negotiation/discovery, and so on, than the typical use of SNMP management for monitoring. Specific concerns: 1.1.3 - I find "replies to requests are signaled by the Middlebox (SNMP agent) by modifying the managed objects" an odd way to describe the way SNMP works. For every processed request message, there is an associated response message that indicates success or failure and the reason for failure. See also comments below. 2.1.1 - I'm not sure I agree that "associations are established" unless SNMPv3 users with shared secrets qualifies. I would like to better understand whether MIDCOM associations have special characteristics that differ from SNMPv3 users and shared secrets. The analysis doesn't get into this at all. 2.1.4 - SNMP is silent about the outcome of multiple requests being presented simultaneously. The SNMP protocol does not explicitly include any support for this. There are a number of mechanisms used in mibs, such as advisory locking and ownerstrings, but none are required or enforced by the protocol. 2.1.5 - SNMP operates on a message-by-message basis, with independent managers and agents, with no sessions or session associations. There is little sense of shared state. My impression is that the requirement is looking for state recovery. SNMP does not support this except that the manager can poll the agent to determine its state. SysUpTime can help to identify when a reboot has occurred so the manager knows to reread the agent's mib. 2.1.6 - Status is mentioned in three different contexts in the other responses: a response to the status of a particular request (available as a response message in SNMP), asynchronous notifications (traps/informs), and queries (polling). The analysis only mentions one type - polling. 2.1.7 - "INFORMS are perhaps more desirable" - there is an assertion here, but no explanation of why an Inform may be preferred over a trap. SNMPv1 is not applicable to the desired purpose. 2.1.8 - "The encryption method is specified in RFC2574" and "can authenticate themselves with one of two authentication methods" totally ignores SNMPv3's very deliberate design to support multiple types of encryption and authentication. The standard configuration defines one encryption and two authentication mechansisms, but SNMPv3 is capable of supporting more than those. I would hate to see the WG select another protocol because it supported more security mechanisms. 2.1.10 - SNMP contains a Response-PDU that is sent to indicate the success or failure of a SET-Request PDU; there is no need to poll the device or to have a device send a trap to communicate the success or failure of a request. 2.1.11 - in practice, there is little in the way of version interworking capability discovery as described in the analysis. Any objects that declare capability support are mib-specific. Generally a manager must poke and prod an agent to determine which mibs have been implemented and which objects have been implemented, and whether they have been fully implemented. Regarding version interworking, SNMP separates the protocol messaging version and the data schemas. Message version coexistence is explicitly described in RFC2576 "coexistence between SNMPv1, v2c, and v3", but most "updates" to SNMP are updated mib modules. RFC2578-80 define the rules for updating mib modules. These are not mentioned in the analysis. 2.1.12 - the SNMP protocol and most SNMP mibs do not have any explicit features to guarantee that two requests do not overlap and conflict. The only guaranteed atomicity in SNMP is for a SET command, and it asserts only that the application of the attributes within a single SET request will be modified "as if simultaneously." Snmpconf has mechanisms to coordinate overlap in rules to achieve a deterministic behavior. I do not believe that either SNMP or Snmpconf preclude the possibility of nondeterministic behavior. and so on. For these reasons, I would like to see the SNMP information in this document updated prior to publication as an RFC. - -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: donderdag 3 oktober 2002 18:56 To: 'Wijnen, Bert (Bert)' Subject: RE: draft-ietf-midcom-protocol-eval-05.txt Hi Bert, I will continue to review the document. I don't know if we would come out any worse in the scoring. I did note that some places where P+ was assigned to SNMP because a MIB needed to be developed, was compared to other protocols that got a T, even though additional message AVTs or whatever needed to be added. Either way, a content-specific data model (or schema) needed to be developed to get the support required. I am less concerned with how we score than that we be properly analyzed. As you are well aware, an assertion made in an RFC can set precedent that others will reference in the future. I don't want to see Juergen, or anybody else, conclude that SNMP is not applicable to a particular problem, and have that set the precedent that SNMP is inappropriate for a whole class of related problems. I point out the folklore that TCP is reliable while UDP is not, so SNMP should use TCP arguments continue to circulate for reason of reliability. My feeling is that while it may not be important to this particular contest, it could be very important to future contests. I would be more willing to see SNMP simply eliminated from the contest and all mention of SNMP removed from the documents than to have SNMP inaccurately characterized in the documents. If they're ging to put SNMP in the documents, then the analysis should be done accurately. - -----Original Message----- I'm about half-way through. I believe there are a few points where the analysis is actually wrong. I point out section 2.1.10 and 2.1.12. For the most part, my concern is that Juergen may not be identifying places where SNMP may not be appropriate or could be difficult to apply because of the difference in architecture. SNMP has a different conceptual architecture than MIDCOM, Diameter, COPS, and other session-based protocols. The requirements have been framed in terms of the MIDCOM architecture, so requirements like "lifetime extension" and "termination of session" don't quite apply, but can be emulated via mibs. I think that needs to be explained a bit more than has been done, and where a mib emulation is required, I think the nature of data required in the mib should be mentioned, e.g. a session table needs to be created to manage the emulated sessions; lifetime would need to be specified in the session definition (row), and could be extended as needed, and so on. Many of his assertions are only assertions, and don't have any meat to them. For example, in 2.2.1 compare Juergen's response to that for other protocols, which discuss how the requirement is met. I will offer to help MIDCOM update the SNMP portion of this document if you'd like, and if Juergen and the chairs have no objection. I obviously know the SNMP quite well; I just need to understand the MIDCOM architecture, requirements, and terminology. I have monitored MIDCOM in the past, and have read many of their docs, so I just need to make sure I understand the requirements fully. Having monitored Diameter and COPS will also help to "grok" the requirements. dbh - -----Original Message----- The single largest problem I have with the document is that the whole SNMP analysis starts out with the assertion that SNMP is used mainly for monitoring, not configuration. Starting out the "applicability" document with an assertion like this obviously biases all subsequent analysis. I had an interesting comment from somebody recently that related to something else, but seems applicable here. An engineer needed to know whether to build a bridge across a river, so he stood at the river where the bridge would be built. He concluded that no bridge was needed because nobody crossed the river at that point; they all went 10 miles down the river to cross at the bridge there instead. ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 8 12:38:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21032 for ; Tue, 8 Oct 2002 12:38:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98Gdr115931 for midcom-archive@odin.ietf.org; Tue, 8 Oct 2002 12:39:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Gd1v15905; Tue, 8 Oct 2002 12:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Gasv15297 for ; Tue, 8 Oct 2002 12:36:54 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20843 for ; Tue, 8 Oct 2002 12:34:45 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g98GanIm009152 for ; Tue, 8 Oct 2002 09:36:49 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD36406; Tue, 8 Oct 2002 09:31:49 -0700 (PDT) Message-Id: <200210081631.AAD36406@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 08 Oct 2002 12:36:47 -0400 Subject: [midcom] Upcoming meeting Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As you're undoubtedly aware, there's an IETF meeting in November. We have relatively little on our plate at the moment, so I've requested a one-hour slot, and the two things (aside from a general status report) that will get agenda time are an update on the protocol evaluation document and discussion of the semantics document. I'm also going try to figure out whether or not there's anything that we need to do on SPAN during the meeting. Is there anything else that requires discussion in Atlanta? Also, tough times are making it more difficult to travel, and some people who are interested in participating may not be able to attend. Are there people who will not be there who are *definitely* interested in participating remotely? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 9 10:48:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20361 for ; Wed, 9 Oct 2002 10:48:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99EoNh27147 for midcom-archive@odin.ietf.org; Wed, 9 Oct 2002 10:50:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99EkEv26995; Wed, 9 Oct 2002 10:46:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99EjTv26956 for ; Wed, 9 Oct 2002 10:45:29 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20171 for ; Wed, 9 Oct 2002 10:43:18 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g99EjHaW023975 for ; Wed, 9 Oct 2002 07:45:17 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD71904; Wed, 9 Oct 2002 07:40:25 -0700 (PDT) Message-Id: <200210091440.AAD71904@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 09 Oct 2002 10:45:23 -0400 Subject: [midcom] SPAN proposal Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Despite Pete's heroic efforts and several pieces of email from one or two interested parties, we've failed to make any progress at all on SPAN. SPAN was intended to provide a short-lived, temporary work-around until midcom becomes available, and it's now looking like midcom may be complete before SPAN (in any event, as things now stand we would almost certainly not be able to complete SPAN before late 2003). An additional problem is that by definition SPAN provides a mechanism for users to circumvent local firewall policy. All in all the situation does not look promising. I'd like to propose that rather than continuing to allow SPAN to die a lingering death we drop it from our deliverables. Feedback, please. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 9 12:14:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23813 for ; Wed, 9 Oct 2002 12:14:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99GG9X00916 for midcom-archive@odin.ietf.org; Wed, 9 Oct 2002 12:16:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99GC9v00774; Wed, 9 Oct 2002 12:12:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99GBXv00753 for ; Wed, 9 Oct 2002 12:11:33 -0400 Received: from gadolinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23607 for ; Wed, 9 Oct 2002 12:09:23 -0400 (EDT) Received: from host213-122-175-183.in-addr.btopenworld.com ([213.122.175.183] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 17zJQk-0004fo-00; Wed, 09 Oct 2002 17:11:27 +0100 Message-ID: <00a601c26fae$829fd260$0200000a@tkw> From: "Pete Cordell" To: , "Melinda Shore" References: <200210091440.AAD71904@mira-sjc5-4.cisco.com> Subject: Re: [midcom] SPAN proposal Date: Wed, 9 Oct 2002 17:10:13 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Melinda, I'm afraid I've been quiet for a while because I was putting together a document on existing techniques that could be used as an alternative to a custom built SPAN protocol. I've just sent this to the drafts editor, and hopefully it will appear in the next few days. Although there's a few potential candidates (L2TP, IPsec, IP over IP, RSIP and Teredo (v4)), none of them so far seem to meet the needs of SPAN. I think SPAN is still worth working on for a number of reasons. Firstly, your implication is that Midcom will be finished in 2003. I'm afraid I'm not that optimistic. The evaluation document didn't pick a clear winner, nor does it provide a mandate for developing a custom protocol. There is probably many months of work to decide what to do, and then there is the specific protocol work (whether SNMP MIBs etc, or custom protocol) to be done. Midcom's history would suggest this won't take place as fast as we would like. Secondly, even when Midcom does become available, it will have to work its way into vendor builds, and then be enabled by customers. This will represent another couple of years. Additionally, all this is exacerbated by the current economic situation that you mentioned. People are putting less effort into standards work, and less effort into development. Customers are being more careful about what they invest in. This will further push out the timescales of a Midcom protocol. On the other hand, SPAN-A, with a few changes could be used almost immediately. Where possible it uses off-the-shelf technology, and (except for TLS which you can get open source) is very simple. Maybe it's more appropriate to publish it as an experimental or informational RFC, but I think making it available would be a great service to the community. Finally, you mention the firewall issue. What would enable SPAN to work through an unmodified firewall basically amounts to a slack set of firewall rules. While such rules have been common in the past, such things have been progressively tightened up over the years. Indeed, there is no need for such rules to be there, and they really shouldn't be there. (In today's virus infested world there's a very strong case for removing them irrespective of whether SPAN exists.) The main benefit of having a standard is that there will only be one such solution, rather than half a dozen, and vendors can block it out-the-box. I therefore suggest that we carry on on a parallel development path as we have been doing (although hopefully a bit faster!). Pete. ----- Original Message ----- From: "Melinda Shore" To: Sent: 09 October 2002 15:45 Subject: [midcom] SPAN proposal > Despite Pete's heroic efforts and several pieces of email > from one or two interested parties, we've failed to make any > progress at all on SPAN. SPAN was intended to provide a > short-lived, temporary work-around until midcom becomes > available, and it's now looking like midcom may be complete > before SPAN (in any event, as things now stand we would > almost certainly not be able to complete SPAN before late > 2003). An additional problem is that by definition SPAN > provides a mechanism for users to circumvent local firewall > policy. > > All in all the situation does not look promising. I'd like > to propose that rather than continuing to allow SPAN to die > a lingering death we drop it from our deliverables. > Feedback, please. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 9 12:18:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23985 for ; Wed, 9 Oct 2002 12:18:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99GJdq01195 for midcom-archive@odin.ietf.org; Wed, 9 Oct 2002 12:19:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99GJ3v01150; Wed, 9 Oct 2002 12:19:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99GINv01101 for ; Wed, 9 Oct 2002 12:18:23 -0400 Received: from mailhost.chi1.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23921 for ; Wed, 9 Oct 2002 12:16:13 -0400 (EDT) Received: from repligate ([67.36.181.100]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021009161817.FHWH14448.mailhost.chi1.ameritech.net@repligate>; Wed, 9 Oct 2002 11:18:17 -0500 Message-ID: <02da01c26faf$8629ee10$0100a8c0@repligate> From: "Jim Fleming" To: "Pete Cordell" , , "Melinda Shore" References: <200210091440.AAD71904@mira-sjc5-4.cisco.com> <00a601c26fae$829fd260$0200000a@tkw> Subject: Re: [midcom] SPAN proposal Date: Wed, 9 Oct 2002 11:18:35 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Pete Cordell" > > Secondly, even when Midcom does become available, it will have to work its > way into vendor builds, and then be enabled by customers. This will > represent another couple of years. > > Additionally, all this is exacerbated by the current economic situation that > you mentioned. People are putting less effort into standards work, and less > effort into development. Customers are being more careful about what they > invest in. This will further push out the timescales of a Midcom protocol. > People may be investing in things that work...with their existing investments... 128-bit DNS AAAA Record Flag Day Formats 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt IPv8 0QQQQGGGSSSSSSSS[32-bits][Port] IPv16 0QQQQGGGSSSSSSSS[32-bits][Port] 1WWWWWWWSSSSSSSS[32-bits][Port] ==== Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://www.ietf.com http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 11 07:33:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17035 for ; Fri, 11 Oct 2002 07:33:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BBYnU19693 for midcom-archive@odin.ietf.org; Fri, 11 Oct 2002 07:34:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBUPv19476; Fri, 11 Oct 2002 07:30:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBT7v19394 for ; Fri, 11 Oct 2002 07:29:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16564; Fri, 11 Oct 2002 07:26:58 -0400 (EDT) Message-Id: <200210111126.HAA16564@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, 11 Oct 2002 07:26:58 -0400 Subject: [midcom] I-D ACTION:draft-cordell-midcom-span-alt-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Alternative Solutions for a SPAN Deliverable Author(s) : P. Cordell Filename : draft-cordell-midcom-span-alt-00.txt Pages : 6 Date : 2002-10-10 This document presents and discusses alternatives to developing a custom solution for the pre-midcom SPAN deliverable (SPAN = Simple Protocol for Augmenting NATs). Such alternatives consist of protocols or techniques that have already been standardised or will soon be standardised. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-alt-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-cordell-midcom-span-alt-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-cordell-midcom-span-alt-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: <2002-10-10140616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cordell-midcom-span-alt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cordell-midcom-span-alt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-10140616.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 11 11:16:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25193 for ; Fri, 11 Oct 2002 11:16:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BFIY231779 for midcom-archive@odin.ietf.org; Fri, 11 Oct 2002 11:18:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BFERv31669; Fri, 11 Oct 2002 11:14:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BFD9v31631 for ; Fri, 11 Oct 2002 11:13:10 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24974 for ; Fri, 11 Oct 2002 11:10:58 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9BFD5ot001297 for ; Fri, 11 Oct 2002 08:13:05 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAE52163; Fri, 11 Oct 2002 08:08:07 -0700 (PDT) Message-Id: <200210111508.AAE52163@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 11 Oct 2002 11:13:04 -0400 Subject: [midcom] SPAN Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As things currently stand we've had only one argument in favor of continuing work on SPAN. Does anybody else feel strongly? And, if so, are there people who are willing to become actively involved in working with Pete on finishing it up? Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 11 11:54:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26202 for ; Fri, 11 Oct 2002 11:54:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BFuEK00952 for midcom-archive@odin.ietf.org; Fri, 11 Oct 2002 11:56:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BFtEv00923; Fri, 11 Oct 2002 11:55:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BFsbv00897 for ; Fri, 11 Oct 2002 11:54:37 -0400 Received: from protactinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26078 for ; Fri, 11 Oct 2002 11:52:20 -0400 (EDT) Received: from host213-1-163-244.in-addr.btopenworld.com ([213.1.163.244] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #8) id 18027O-0006EK-00 for midcom@ietf.org; Fri, 11 Oct 2002 16:54:26 +0100 Message-ID: <00c701c2713e$4da0f3a0$0200000a@tkw> From: "Pete Cordell" To: Date: Fri, 11 Oct 2002 16:15:26 +0100 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] SPAN Alternatives Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear All, The draft I mentioned on SPAN alternatives is now out. I consider that this is work in progress, and there is no conclusion in the document yet. However, with the analysis so far it doesn't appear that there is a good alternative to a custom SPAN solution that uses only existing protocols. Further input on this would be welcomed though. The document as it is at the moment is at: http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-alt-00.txt It is very short and not intended as a tutorial on the various techniques, and so should be an easy read. Regards, Pete. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 14 07:26:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14714 for ; Mon, 14 Oct 2002 07:26:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EBRwR25524 for midcom-archive@odin.ietf.org; Mon, 14 Oct 2002 07:27:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBQYv25489; Mon, 14 Oct 2002 07:26:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBPjv25464 for ; Mon, 14 Oct 2002 07:25:45 -0400 Received: from gadolinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14481 for ; Mon, 14 Oct 2002 07:23:28 -0400 (EDT) Received: from host213-122-29-55.in-addr.btopenworld.com ([213.122.29.55] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 1813GQ-0001Eq-00; Mon, 14 Oct 2002 12:19:59 +0100 Message-ID: <005f01c27373$a3ef56c0$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" , References: <200210111508.AAE52163@mira-sjc5-4.cisco.com> Subject: Re: [midcom] SPAN Date: Mon, 14 Oct 2002 11:44:34 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I forgot to mention in my last post that one of the big benefits of a SPAN solution is that it provides support for TCP. SIP is becoming more TCP oriented (although there are other ways to do it with UDP and STUN) so it would be nice for that, but it's almost essential for H.323. As such, it's a problem that needs to be solved. (What's the case for IM? - I haven't been following that so well. There's also SIP content indirection being worked on which may benefit from TCP support.) Pete. ----- Original Message ----- From: "Melinda Shore" To: Sent: 11 October 2002 16:13 Subject: [midcom] SPAN > As things currently stand we've had only one argument in > favor of continuing work on SPAN. Does anybody else feel > strongly? And, if so, are there people who are willing to > become actively involved in working with Pete on finishing > it up? > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 14 07:33:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14939 for ; Mon, 14 Oct 2002 07:33:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EBZSn25787 for midcom-archive@odin.ietf.org; Mon, 14 Oct 2002 07:35:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBY3v25707; Mon, 14 Oct 2002 07:34:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBX0v25647 for ; Mon, 14 Oct 2002 07:33:00 -0400 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14823 for ; Mon, 14 Oct 2002 07:30:47 -0400 (EDT) Received: from jeongcheol ([203.255.254.88]) (authenticated) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g9EBLba27617 for ; Mon, 14 Oct 2002 20:21:37 +0900 Message-ID: <006c01c27375$2dbe76a0$58feffcb@jeongcheol> From: "jclee" To: Date: Mon, 14 Oct 2002 20:30:59 +0900 Organization: =?ks_c_5601-1987?B?xMTHu8XNxeu9xb3H?= MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0068_01C273C0.9B30B1D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [midcom] unsubscribe Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C273C0.9B30B1D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0069_01C273C0.9B30B1D0" ------=_NextPart_001_0069_01C273C0.9B30B1D0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 uvG+7iDA1sC9dW5zdWJzY3JpYmUgZGlzY3VzcyBqY2xlZUBjY2wuY251LmFjLmtyDQoNCg== ------=_NextPart_001_0069_01C273C0.9B30B1D0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRSBpZD1yaWRUaXRsZT668b7uIMDWwL08L1RJVExFPjxC QVNFIA0KaHJlZj0iZmlsZTovL0M6XFByb2dyYW0gRmlsZXNcQ29tbW9uIEZpbGVzXE1pY3Jvc29m dCBTaGFyZWRcU3RhdGlvbmVyeVwiPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxTVFlMRT5CT0RZIHsN CglNQVJHSU4tVE9QOiAyNXB4OyBGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTi1MRUZUOiAyNXB4OyBD T0xPUjogIzAwMDAwMDsgRk9OVC1GQU1JTFk6ILG8uLIsIEhlbHZldGljYQ0KfQ0KUC5tc29Ob3Jt YWwgew0KCU1BUkdJTi1UT1A6IDBweDsgRk9OVC1TSVpFOiAxMHB0OyBNQVJHSU4tTEVGVDogMHB4 OyBDT0xPUjogI2ZmZmZjYzsgRk9OVC1GQU1JTFk6IEhlbHZldGljYSwgIlRpbWVzIE5ldyBSb21h biINCn0NCkxJLm1zb05vcm1hbCB7DQoJTUFSR0lOLVRPUDogMHB4OyBGT05ULVNJWkU6IDEwcHQ7 IE1BUkdJTi1MRUZUOiAwcHg7IENPTE9SOiAjZmZmZmNjOyBGT05ULUZBTUlMWTogSGVsdmV0aWNh LCAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBpZD1yaWRCb2R5 IGJnQ29sb3I9I2ZmZmZmZiANCmJhY2tncm91bmQ9Y2lkOjAwNjcwMWMyNzM3NSQyYjM1ZjcwMCQ1 OGZlZmZjYkBqZW9uZ2NoZW9sPg0KPERJVj51bnN1YnNjcmliZSBkaXNjdXNzIGpjbGVlQGNjbC5j bnUuYWMua3I8L0RJVj4NCjxQPiZuYnNwOzwvUD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_001_0069_01C273C0.9B30B1D0-- ------=_NextPart_000_0068_01C273C0.9B30B1D0 Content-Type: image/gif; name="=?ks_c_5601-1987?B?uenB9iC56LDmLmdpZg==?=" Content-Transfer-Encoding: base64 Content-ID: <006701c27375$2b35f700$58feffcb@jeongcheol> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------=_NextPart_000_0068_01C273C0.9B30B1D0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 14 19:38:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05676 for ; Mon, 14 Oct 2002 19:38:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ENeAs32215 for midcom-archive@odin.ietf.org; Mon, 14 Oct 2002 19:40:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ENdOv32160; Mon, 14 Oct 2002 19:39:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ENcMv32131 for ; Mon, 14 Oct 2002 19:38:22 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05632 for ; Mon, 14 Oct 2002 19:36:05 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9ENcEot012816 for ; Mon, 14 Oct 2002 16:38:14 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF27922; Mon, 14 Oct 2002 16:33:17 -0700 (PDT) Message-Id: <200210142333.AAF27922@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 14 Oct 2002 19:38:12 -0400 Subject: [midcom] SPAN status Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Since I sent out the query last week the only person who's piped up in favor of continuing the work was Pete. In the face of this level of ennui I'm afraid we're going to have to delete the work item. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 15 05:23:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24485 for ; Tue, 15 Oct 2002 05:23:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9F9PP602565 for midcom-archive@odin.ietf.org; Tue, 15 Oct 2002 05:25:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F9Odv02521; Tue, 15 Oct 2002 05:24:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F9NSv02445 for ; Tue, 15 Oct 2002 05:23:28 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24441 for ; Tue, 15 Oct 2002 05:21:18 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9F9N6Y01384; Tue, 15 Oct 2002 11:23:07 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C28906BB01; Tue, 15 Oct 2002 11:23:05 +0200 (CEST) Date: Tue, 15 Oct 2002 11:23:06 +0200 From: Juergen Quittek To: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Upcoming meeting Message-ID: <5959349.1034680986@[192.168.102.164]> In-Reply-To: <200210081631.AAD36406@mira-sjc5-4.cisco.com> References: <200210081631.AAD36406@mira-sjc5-4.cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, I agree that discussing updates of the evaluation document and the midcom semantics probably fit into one hour. But aren't we going to have a discussion on the protocol selection itself? The evaluation document does not say "Protocol X is the best choice". There is still a decision to be made that is probably not too easy. I thought we would have a discussion on the protocol selection in Atlanta and I do not expect this something that fits into one hour together with the other two issues. Do you plan to schedule this discussion for the March IETF meeting in San Francisco? Juergen -- Melinda Shore wrote on 08 October 2002 12:36 -0400: > As you're undoubtedly aware, there's an IETF meeting in > November. We have relatively little on our plate at the > moment, so I've requested a one-hour slot, and the two > things (aside from a general status report) that will get > agenda time are an update on the protocol evaluation > document and discussion of the semantics document. I'm also > going try to figure out whether or not there's anything that > we need to do on SPAN during the meeting. Is there anything > else that requires discussion in Atlanta? > > Also, tough times are making it more difficult to travel, > and some people who are interested in participating may not > be able to attend. Are there people who will not be there > who are *definitely* interested in participating remotely? > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 15 07:34:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26835 for ; Tue, 15 Oct 2002 07:34:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FBaEf08586 for midcom-archive@odin.ietf.org; Tue, 15 Oct 2002 07:36:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FBYWv08491; Tue, 15 Oct 2002 07:34:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FBXYv08459 for ; Tue, 15 Oct 2002 07:33:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26632; Tue, 15 Oct 2002 07:31:21 -0400 (EDT) Message-Id: <200210151131.HAA26632@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: Tue, 15 Oct 2002 07:31:21 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-03.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : STUN - Simple Traversal of UDP Through Network Address Translators Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Filename : draft-ietf-midcom-stun-03.txt Pages : 43 Date : 2002-10-14 Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-stun-03.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-stun-03.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: <2002-10-14142317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-14142317.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 15 08:30:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28690 for ; Tue, 15 Oct 2002 08:30:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCWKW11556 for midcom-archive@odin.ietf.org; Tue, 15 Oct 2002 08:32:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCSJv11371; Tue, 15 Oct 2002 08:28:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCRav11330 for ; Tue, 15 Oct 2002 08:27:36 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28555 for ; Tue, 15 Oct 2002 08:25:23 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9FCRRot015031; Tue, 15 Oct 2002 05:27:27 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF41303; Tue, 15 Oct 2002 05:22:30 -0700 (PDT) Message-Id: <200210151222.AAF41303@mira-sjc5-4.cisco.com> To: Juergen Quittek cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Upcoming meeting In-Reply-To: Message from Juergen Quittek of "Tue, 15 Oct 2002 11:23:06 +0200." <5959349.1034680986@[192.168.102.164]> Date: Tue, 15 Oct 2002 08:27:25 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > But aren't we going to have a discussion on the protocol > selection itself? We won't, for several reasons. The first is that the document is still under heavy revision in response to comments from the IESG, and unfortunately isn't yet stable enough to be used as a solid platform from which to launch a meaningful discussion. The other and arguably more signifant reason is that it hasn't been discussed on the mailing list. The expectation is that meeting time will not be spent on anything that hasn't been discussed on the mailing list first, and that it will be used to help us resolve existing issues that would benefit from face-to-face discussion. We may spend some time talking about process, but not content. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 15 08:49:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29379 for ; Tue, 15 Oct 2002 08:49:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCpHa12887 for midcom-archive@odin.ietf.org; Tue, 15 Oct 2002 08:51:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FClNv12731; Tue, 15 Oct 2002 08:47:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCjvv12665 for ; Tue, 15 Oct 2002 08:45:57 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29161 for ; Tue, 15 Oct 2002 08:43:44 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9FCjgY08665; Tue, 15 Oct 2002 14:45:42 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6C04F6BD2A; Tue, 15 Oct 2002 14:45:41 +0200 (CEST) Date: Tue, 15 Oct 2002 14:45:41 +0200 From: Juergen Quittek To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Upcoming meeting Message-ID: <18114276.1034693141@[192.168.102.164]> In-Reply-To: <200210151222.AAF41303@mira-sjc5-4.cisco.com> References: <200210151222.AAF41303@mira-sjc5-4.cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, -- Melinda Shore wrote on 15 October 2002 08:27 -0400: >> But aren't we going to have a discussion on the protocol >> selection itself? > > We won't, for several reasons. The first is that the > document is still under heavy revision in response to > comments from the IESG, and unfortunately isn't yet stable > enough to be used as a solid platform from which to launch a > meaningful discussion. The other and arguably more > signifant reason is that it hasn't been discussed on the > mailing list. The expectation is that meeting time will not Do you have a rough idea on when to initiate such a discussion on the mailing list? I think that the evaluation document is already pretty stable. The "heavy" revisions concern SNMP only. And from what I've seen in Davids comments, there are some changes in the general considerations on SNMP, and there are changes arguing 'why' a requirement is met. But I do not expect any change in the T,P+,P,F rating of SNMP (maybe with one exception). I agree that we should not finally decide on the protocol before the evaluation I-D passed the IESG. But with the current version I do not see a good reason for further delaying the discussion. Juergen > be spent on anything that hasn't been discussed on the > mailing list first, and that it will be used to help us > resolve existing issues that would benefit from face-to-face > discussion. > > We may spend some time talking about process, but not > content. > > Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 15 14:15:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10250 for ; Tue, 15 Oct 2002 14:15:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FIH7D31499 for midcom-archive@odin.ietf.org; Tue, 15 Oct 2002 14:17:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIGKv31479; Tue, 15 Oct 2002 14:16:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIFcv31444 for ; Tue, 15 Oct 2002 14:15:38 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10192 for ; Tue, 15 Oct 2002 14:13:22 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9FIFWIm016362 for ; Tue, 15 Oct 2002 11:15:32 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF51772; Tue, 15 Oct 2002 11:10:36 -0700 (PDT) Message-Id: <200210151810.AAF51772@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 15 Oct 2002 14:15:31 -0400 Subject: [midcom] IETF meeting Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We are *tentatively* scheduled to meet Tuesday, 19 November from 1415-1315. The schedule may change, so please do not make travel plans based on how we're currently scheduled. Also meeting at that time are: INT atommib AToM MIB WG OPS dnsop Domain Name Server Operations WG RTG udlr UniDirectional Link Routing WG SEC krb-wg Kerberos WG SUB sub-ip SUB-IP Area Meeting As I mentioned in an earlier note, we do not use meeting time to introduce new subjects or material - it needs to have been discussed on the mailing list first. Right now the only thing under discussion is the semantics document, so if there are any issues with that particular document that you feel need resolution please raise them on the mailing list. In addition to an update on current status we will most likely be discussing, *briefly*, how we'll be moving forward with the protocol. We will NOT be discussing the protocol itself. Please let me know if there's anything I've missed. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 16 05:48:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23163 for ; Wed, 16 Oct 2002 05:48:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9G9oYI23262 for midcom-archive@odin.ietf.org; Wed, 16 Oct 2002 05:50:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G9ikv23077; Wed, 16 Oct 2002 05:44:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G9YWv22248 for ; Wed, 16 Oct 2002 05:34:32 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22927 for ; Wed, 16 Oct 2002 05:31:53 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9G8x7Y41287 for ; Wed, 16 Oct 2002 10:59:07 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A1E976C2C3 for ; Wed, 16 Oct 2002 10:58:56 +0200 (CEST) Date: Wed, 16 Oct 2002 11:06:25 +0200 From: Juergen Quittek To: midcom@ietf.org Message-ID: <2408032.1034766385@[192.168.102.164]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Protocol selection procedure Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Maybe I'm too impatient, but I want to get an idea how we are going to select the midcom protocol. We have our requirements, we have an almost completed evaluation of five protocols, and we are getting towards an idea of the semantics of the protocol. This is apparently sufficient preparation for starting to think about the decision process. Unfortunately, the evaluation did not identify a clearly superior candidate, but found that there are several ones that are suited. This positive finding (we do have a choice!) should not become a negative one by blocking progress because we do not know how to decide. So, how to go on? Shall we refine our seelection criteria? Shall we prioritize them? Are there already clear preference for one of the protocols? Shall we wait until some of the candidates have died? ;-) We are not the only working group that was requested by the IESG to select a protocol. Does anyone have experieces from other WGs handling similar protocol decisions? Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 16 05:52:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23239 for ; Wed, 16 Oct 2002 05:52:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9G9rpd23492 for midcom-archive@odin.ietf.org; Wed, 16 Oct 2002 05:53:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G9r4v23429; Wed, 16 Oct 2002 05:53:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G9q8v23385 for ; Wed, 16 Oct 2002 05:52:08 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23204 for ; Wed, 16 Oct 2002 05:49:57 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9G9q5Y46480 for ; Wed, 16 Oct 2002 11:52:06 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2B3086C2F3 for ; Wed, 16 Oct 2002 11:52:05 +0200 (CEST) Message-ID: <3DAD36C3.8050405@ccrle.nec.de> Date: Wed, 16 Oct 2002 11:52:03 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Protocol evaluation -- any experience from the past Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm currently asking myself how we should proceed in the protocol evaluation. The I-D has been finished so far and it is under review, but how to continue the discussion (which will at least contain some religious attributes :). Is anybody aware of a similar protocol evaluation done before in a WG of the IETF? What was the botton line of evaluation process? Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 16 08:09:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26185 for ; Wed, 16 Oct 2002 08:09:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GCAxP30779 for midcom-archive@odin.ietf.org; Wed, 16 Oct 2002 08:10:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GC7Yv30696; Wed, 16 Oct 2002 08:07:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GC6Ev30089 for ; Wed, 16 Oct 2002 08:06:14 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25986 for ; Wed, 16 Oct 2002 08:04:01 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9GC5oot008486; Wed, 16 Oct 2002 05:05:50 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF80078; Wed, 16 Oct 2002 05:00:55 -0700 (PDT) Message-Id: <200210161200.AAF80078@mira-sjc5-4.cisco.com> To: Juergen Quittek cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Protocol selection procedure In-Reply-To: Message from Juergen Quittek of "Wed, 16 Oct 2002 11:06:25 +0200." <2408032.1034766385@[192.168.102.164]> Date: Wed, 16 Oct 2002 08:05:49 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Because this process has the potential to be singularly unproductive, I've been talking with our ADs about how they think we should go about it. Those discussions are not finished, which is part of the reason that we haven't begun the discussion on the mailing list. At a minimum, the first step will be to eliminate any obviously weak candidates. Another working group which evaluated a number of protocols and selected one is AAA. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 16 08:46:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27439 for ; Wed, 16 Oct 2002 08:46:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GCmfZ32515 for midcom-archive@odin.ietf.org; Wed, 16 Oct 2002 08:48:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GCm9v32501; Wed, 16 Oct 2002 08:48:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GCaBv31577 for ; Wed, 16 Oct 2002 08:36:11 -0400 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27098 for ; Wed, 16 Oct 2002 08:33:58 -0400 (EDT) Received: from jku07.fokus.fraunhofer.de (port-212-202-171-89.reverse.qdsl-home.de [212.202.171.89]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g9GCZxn07440; Wed, 16 Oct 2002 14:35:59 +0200 Message-Id: <5.1.0.14.0.20021016142414.03d71ea0@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Oct 2002 14:35:56 +0200 To: Juergen Quittek , midcom@ietf.org From: Jiri Kuthan Subject: Re: [midcom] Protocol selection procedure In-Reply-To: <2408032.1034766385@[192.168.102.164]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:06 AM 10/16/2002, Juergen Quittek wrote: >Hi all, > >Maybe I'm too impatient, but I want to get an idea how we are >going to select the midcom protocol. > >We have our requirements, we have an almost completed evaluation >of five protocols, and we are getting towards an idea of the >semantics of the protocol. This is apparently sufficient preparation >for starting to think about the decision process. > >Unfortunately, the evaluation did not identify a clearly superior >candidate, but found that there are several ones that are suited. I actually think this protocol shopping is a bug in strategy. With some effort very many protocols may be tweaked to make requirements happy, each having some cons and prons. The result seems questionnable -- after two years of advocating why one's pet better than someone else's, we may easily end up with a suboptimal protocol. I would not be surprised to see too big complexity, because of reusing a protocol for too many purposes. I saw few simple proposals on the table and would prefer going ahead with them. Simplicity is good and actually should be boldly stated as R0. -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 16 11:36:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03622 for ; Wed, 16 Oct 2002 11:36:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GFboC10773 for midcom-archive@odin.ietf.org; Wed, 16 Oct 2002 11:37:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFbFv10573; Wed, 16 Oct 2002 11:37:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFasv10175 for ; Wed, 16 Oct 2002 11:36:54 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03601 for ; Wed, 16 Oct 2002 11:34:40 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9GFamcl004734 for ; Wed, 16 Oct 2002 08:36:48 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF84334; Wed, 16 Oct 2002 08:31:54 -0700 (PDT) Message-Id: <200210161531.AAF84334@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 16 Oct 2002 11:36:48 -0400 Subject: [midcom] Poll Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Let's start thinking about eliminating unsuitable midcom protocol candidates. Is there one protocol that you consider a particularly bad match? (answers of "all of them" will receive all the respect they're due). By the numbers, RSIP has the lowest number of matches to our requirements - do you feel that that is a reflection of RSIP being *actually* less suitable than the others, or are there some intangibles that haven't been accounted for as part of the evaluation process? Comments to the mailing list, please. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 16 13:15:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06220 for ; Wed, 16 Oct 2002 13:15:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GHGkL16092 for midcom-archive@odin.ietf.org; Wed, 16 Oct 2002 13:16:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GHEHv16009; Wed, 16 Oct 2002 13:14:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GGOPv12998 for ; Wed, 16 Oct 2002 12:24:25 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04725 for ; Wed, 16 Oct 2002 12:22:11 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9GGO9xH025400; Wed, 16 Oct 2002 09:24:09 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-142-114.cisco.com [128.107.142.114]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id AAI81389; Wed, 16 Oct 2002 09:24:33 -0700 (PDT) From: "Cullen Jennings" To: "Jonathan Rosenberg" Cc: Date: Wed, 16 Oct 2002 09:24:08 -0700 Message-ID: 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.50.4807.1700 In-Reply-To: <200210151131.HAA26632@ietf.org> Content-Transfer-Encoding: 7bit Subject: [midcom] Few trivial details with draft-ietf-midcom-stun-03 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Section 11.2, first sentence. Would be nice to make it very clear that the length is just the length of the Value portion of the attribute and does not include the 4 bytes that form the Type and Length. Section 11.2.7, second sentence. With the addition of the USERNAME, this is no longer the sole attribute in a shared secret response. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 04:05:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03342 for ; Thu, 17 Oct 2002 04:05:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H87HL05469 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 04:07:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H85Tv05052; Thu, 17 Oct 2002 04:05:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H84mv05018 for ; Thu, 17 Oct 2002 04:04:48 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03316 for ; Thu, 17 Oct 2002 04:02:25 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9H84bY88372 for ; Thu, 17 Oct 2002 10:04:37 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 268E860719 for ; Thu, 17 Oct 2002 10:04:36 +0200 (CEST) Message-ID: <3DAE70D5.8050403@ccrle.nec.de> Date: Thu, 17 Oct 2002 10:12:05 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Evaluation: RSIP (tunneling) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In section 1.2.4 of the protocol evaluation doc it is mentioned that RSIP uses tunnels to give hosts behind a middlebox access to public network (the cited text is below). As far as I see this requires that the hosts have a modified IP stack, in order to support RSIP. I see this as unsuitable for a MIDCOM solution, because I would like to use my five years old hardware SIP phone behind a packet filter. I see no way to modify the IP stack of my phone. The text cited below talks only about NATs, but what about pure packet filters? In packet filter case I don't need a tunnel at all, that's just plain overhead! Furthermore I see a architectural difference between RSIP and the midcom approach. The MIDCOM agent is not involved in the data transmission, but the RISP is involved. For me RSIP imposes to many obstacles in order to be a MIDCOM protocol. Martin +++ "RSIP with tunneling, has the advantage that the public realm IP addresses and port numbers are known to the private realm host application, thus no translation is needed for protocols such as SDP, the FTP control protocol, RTSP, SMIL, etc.. However, this does require that an RSIP server and a tunneling protocol be implemented in the middlebox and an RSIP client and the tunneling protocol be implemented in the private realm host. The host modifications can generally be made without modification to the host application or requiring the implementation of a host application agent. This is viewed as a significant advantage over NAT (Network Address Translation)." -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 04:27:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03588 for ; Thu, 17 Oct 2002 04:27:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H8TPS06302 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 04:29:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8S5v06264; Thu, 17 Oct 2002 04:28:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8Rjv06242 for ; Thu, 17 Oct 2002 04:27:45 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03576 for ; Thu, 17 Oct 2002 04:25:21 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9H8RXY89472 for ; Thu, 17 Oct 2002 10:27:33 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A1516679B8 for ; Thu, 17 Oct 2002 10:27:32 +0200 (CEST) Message-ID: <3DAE7635.9040702@ccrle.nec.de> Date: Thu, 17 Oct 2002 10:35:01 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Evalutation: SNMP Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the MIDCOM case SNMP has to be used as a configuration protocol. But SNMP is now for 20 years onstage, but it hasn't used too many times for configuration of devices. So I don't see the point of why MIDCOM should use SNMP for middlebox configuration? Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 04:33:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03718 for ; Thu, 17 Oct 2002 04:33:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H8Zne06553 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 04:35:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8XNv06453; Thu, 17 Oct 2002 04:33:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8Wbv06400 for ; Thu, 17 Oct 2002 04:32:37 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03615 for ; Thu, 17 Oct 2002 04:30:13 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9H8WIY90038; Thu, 17 Oct 2002 10:32:18 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E43DE6C5DE; Thu, 17 Oct 2002 10:32:16 +0200 (CEST) Message-ID: <3DAE7753.5080704@ccrle.nec.de> Date: Thu, 17 Oct 2002 10:39:47 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan Cc: midcom@ietf.org Subject: Re: [midcom] Protocol selection procedure References: <5.1.0.14.0.20021016142414.03d71ea0@mailhost.fokus.gmd.de> 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [...] > I actually think this protocol shopping is a bug in strategy. With > some effort very many protocols may be tweaked to make requirements Protocol shopping takes a lot of time for sure, but it may be good to take a look around to existing protocols. The point is that it is impossible to tweak a protocol to fit with the requirements and framework unless you break the existing protocol (and then it isn't anymore the actual existing protocol). But it is possible to tweak the evaluation of a protocol versus requirements and framework, so that the protocol seems to be suitable. > happy, each having some cons and prons. The result seems questionnable > -- after two years of advocating why one's pet better than someone else's, > we may easily end up with a suboptimal protocol. I would not be surprised > to see too big complexity, because of reusing a protocol for too many > purposes. Agreed, that we have to be careful, otherwise we really end up with a suboptimal or even worse with a non-working protocol. > > I saw few simple proposals on the table and would prefer going ahead with > them. Simplicity is good and actually should be boldly stated as R0. I would prefer as well a simple protocol! Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 04:37:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03792 for ; Thu, 17 Oct 2002 04:37:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H8dIR07250 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 04:39:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8c2v07201; Thu, 17 Oct 2002 04:38:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8bqv07185 for ; Thu, 17 Oct 2002 04:37:52 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03751 for ; Thu, 17 Oct 2002 04:35:29 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9H8bfY90567 for ; Thu, 17 Oct 2002 10:37:41 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 478DE56286 for ; Thu, 17 Oct 2002 10:37:39 +0200 (CEST) Message-ID: <3DAE7895.5040506@ccrle.nec.de> Date: Thu, 17 Oct 2002 10:45:09 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Evaluation: COPS and session initialisation Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just a poll about the working group opinion: The MIDCOM framework and requirements say that the agent initiates the session to the middlebox. But in the COPS/COPS-PR case the way is vice versa: The middlebox initiates the session to the agent. I see this a as major difference in the particular architecture. How does the working group feel about this. Is this just a minore point or a real concern. Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 07:46:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06921 for ; Thu, 17 Oct 2002 07:46:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HBm3o16667 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 07:48:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HBhCv16485; Thu, 17 Oct 2002 07:43:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HBguv16459 for ; Thu, 17 Oct 2002 07:42:56 -0400 Received: from zctfs063.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06778 for ; Thu, 17 Oct 2002 07:40:42 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HBgd819801; Thu, 17 Oct 2002 13:42:40 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 13:42:38 +0200 Message-ID: From: "Cedric Aoun" To: "'Martin Stiemerling'" , midcom@ietf.org Subject: RE: [midcom] Evaluation: RSIP (tunneling) Date: Thu, 17 Oct 2002 13:42:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C275D2.4B6F5B6A" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C275D2.4B6F5B6A Content-Type: text/plain; charset="iso-8859-1" In addition to the tunnel burden, I would like to remind the WG about RSIP's extensibility model vs other evaluated protocols. RSIP's extensibility to meet MIDCOM's requirements requires more effort than using the package/PIB/MIB model used by the other evaluated protocols. My vote is to eliminate RSIP in this round of discussions Cedric -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: 17 October 2002 10:12 To: midcom@ietf.org Subject: [midcom] Evaluation: RSIP (tunneling) In section 1.2.4 of the protocol evaluation doc it is mentioned that RSIP uses tunnels to give hosts behind a middlebox access to public network (the cited text is below). As far as I see this requires that the hosts have a modified IP stack, in order to support RSIP. I see this as unsuitable for a MIDCOM solution, because I would like to use my five years old hardware SIP phone behind a packet filter. I see no way to modify the IP stack of my phone. The text cited below talks only about NATs, but what about pure packet filters? In packet filter case I don't need a tunnel at all, that's just plain overhead! Furthermore I see a architectural difference between RSIP and the midcom approach. The MIDCOM agent is not involved in the data transmission, but the RISP is involved. For me RSIP imposes to many obstacles in order to be a MIDCOM protocol. Martin +++ "RSIP with tunneling, has the advantage that the public realm IP addresses and port numbers are known to the private realm host application, thus no translation is needed for protocols such as SDP, the FTP control protocol, RTSP, SMIL, etc.. However, this does require that an RSIP server and a tunneling protocol be implemented in the middlebox and an RSIP client and the tunneling protocol be implemented in the private realm host. The host modifications can generally be made without modification to the host application or requiring the implementation of a host application agent. This is viewed as a significant advantage over NAT (Network Address Translation)." -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C275D2.4B6F5B6A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Evaluation: RSIP (tunneling)

In addition to the tunnel burden, I would like to = remind the WG about
RSIP's extensibility model vs other evaluated = protocols.
RSIP's extensibility to meet MIDCOM's requirements = requires more effort than
using the package/PIB/MIB model used by the other = evaluated protocols.

My vote is to eliminate RSIP in this round of = discussions
Cedric

-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: 17 October 2002 10:12
To: midcom@ietf.org
Subject: [midcom] Evaluation: RSIP = (tunneling)


In section 1.2.4 of the protocol evaluation doc it is = mentioned that
RSIP uses tunnels to give hosts behind a middlebox = access to public
network (the cited text is below). As far as I see = this requires that
the hosts have a modified IP stack, in order to = support RSIP. I see this
as unsuitable for a MIDCOM solution, because I would = like to use my five
years old hardware SIP phone behind a packet filter. = I see no way to
modify the IP stack of my phone.

The text cited below talks only about NATs, but what = about pure packet
filters? In packet filter case I don't need a tunnel = at all, that's just
plain overhead! Furthermore I see a architectural = difference between
RSIP and the midcom approach. The MIDCOM agent is = not involved in the
data transmission, but the RISP is involved.

For me RSIP imposes to many obstacles in order to be = a MIDCOM protocol.

Martin

+++
"RSIP with tunneling, has the advantage that = the public realm IP
addresses and port numbers are known to the private = realm host
application, thus no translation is needed for = protocols such as
SDP, the FTP control protocol, RTSP, SMIL, etc.. = However, this does
require that an RSIP server and a tunneling protocol = be implemented
in the middlebox and an RSIP client and the = tunneling protocol be
implemented in the private realm host. The host = modifications can
generally be made without modification to the host = application or
requiring the implementation of a host application = agent. This is
viewed as a significant advantage over NAT (Network = Address
Translation)."

--
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  = Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________=
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C275D2.4B6F5B6A-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 10:56:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13754 for ; Thu, 17 Oct 2002 10:56:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HEwp629362 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 10:58:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HErSv29019; Thu, 17 Oct 2002 10:53:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HEZuv27526 for ; Thu, 17 Oct 2002 10:35:56 -0400 Received: from EXECDSL.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12872 for ; Thu, 17 Oct 2002 10:33:41 -0400 (EDT) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 3863635; Thu, 17 Oct 2002 10:35:53 -0400 Message-Id: <5.1.0.14.0.20021017103224.018acea8@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Oct 2002 10:34:57 -0400 To: Martin Stiemerling , midcom@ietf.org From: "Joel M. Halpern" Subject: Re: [midcom] Evalutation: SNMP In-Reply-To: <3DAE7635.9040702@ccrle.nec.de> 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , While it is true that SNMP is not used by network operators for configuration (or some statement close enough to taht for our purposes) that does not mean that SNMP has not been used for configuration, or should not be used for configuration. I know of several enterprise routers over the years that were strictly configured with SNMP. I know of several enterprise operational systems that manage and configure routers using SNMP. While I am doubtful for other reasons as to whether SNMP is the right answer for MIDCOM, I would certainly not rule it out. In many ways it is the best developed and tested solution available. Yours, Joel M. Halpern At 10:35 AM 10/17/2002 +0200, Martin Stiemerling wrote: >In the MIDCOM case SNMP has to be used as a configuration protocol. But >SNMP is now for 20 years onstage, but it hasn't used too many times for >configuration of devices. >So I don't see the point of why MIDCOM should use SNMP for middlebox >configuration? > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 11:29:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14612 for ; Thu, 17 Oct 2002 11:29:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HFVNA31503 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 11:31:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HFUCv31423; Thu, 17 Oct 2002 11:30:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HFThv31372 for ; Thu, 17 Oct 2002 11:29:43 -0400 Received: from mail2.microsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14554 for ; Thu, 17 Oct 2002 11:27:27 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 08:29:33 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Oct 2002 08:29:26 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 08:29:26 -0700 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 08:29:25 -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(6.0.3663.0); Thu, 17 Oct 2002 08:29:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Evaluation: RSIP (tunneling) Date: Thu, 17 Oct 2002 08:29:28 -0700 Message-ID: Thread-Topic: [midcom] Evaluation: RSIP (tunneling) Thread-Index: AcJ106xQFcUmUs6MSkCSqQyesCmHQAAHNuKw From: "Christian Huitema" To: "Cedric Aoun" , "Martin Stiemerling" Cc: X-OriginalArrivalTime: 17 Oct 2002 15:29:25.0701 (UTC) FILETIME=[F9B8EF50:01C275F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9HFTiv31373 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree with Cedric and Martin on this point. RSIP does not seem at all to be a good match to the problem. -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Thursday, October 17, 2002 4:43 AM To: 'Martin Stiemerling'; midcom@ietf.org Subject: RE: [midcom] Evaluation: RSIP (tunneling) In addition to the tunnel burden, I would like to remind the WG about RSIP's extensibility model vs other evaluated protocols. RSIP's extensibility to meet MIDCOM's requirements requires more effort than using the package/PIB/MIB model used by the other evaluated protocols. My vote is to eliminate RSIP in this round of discussions Cedric -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: 17 October 2002 10:12 To: midcom@ietf.org Subject: [midcom] Evaluation: RSIP (tunneling) In section 1.2.4 of the protocol evaluation doc it is mentioned that RSIP uses tunnels to give hosts behind a middlebox access to public network (the cited text is below). As far as I see this requires that the hosts have a modified IP stack, in order to support RSIP. I see this as unsuitable for a MIDCOM solution, because I would like to use my five years old hardware SIP phone behind a packet filter. I see no way to modify the IP stack of my phone. The text cited below talks only about NATs, but what about pure packet filters? In packet filter case I don't need a tunnel at all, that's just plain overhead! Furthermore I see a architectural difference between RSIP and the midcom approach. The MIDCOM agent is not involved in the data transmission, but the RISP is involved. For me RSIP imposes to many obstacles in order to be a MIDCOM protocol. Martin +++ "RSIP with tunneling, has the advantage that the public realm IP addresses and port numbers are known to the private realm host application, thus no translation is needed for protocols such as SDP, the FTP control protocol, RTSP, SMIL, etc.. However, this does require that an RSIP server and a tunneling protocol be implemented in the middlebox and an RSIP client and the tunneling protocol be implemented in the private realm host. The host modifications can generally be made without modification to the host application or requiring the implementation of a host application agent. This is viewed as a significant advantage over NAT (Network Address Translation)." -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 11:35:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14869 for ; Thu, 17 Oct 2002 11:35:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HFc9s32495 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 11:38:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HFb4v31997; Thu, 17 Oct 2002 11:37:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HFaGv31835 for ; Thu, 17 Oct 2002 11:36:16 -0400 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14823 for ; Thu, 17 Oct 2002 11:33:59 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HFZxY18781; Thu, 17 Oct 2002 11:35:59 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 11:36:00 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387FCB@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Christian Huitema'" , "Cedric Aoun" , Martin Stiemerling Cc: midcom@ietf.org Subject: RE: [midcom] Evaluation: RSIP (tunneling) Date: Thu, 17 Oct 2002 11:35:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C275F2.E3F91022" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C275F2.E3F91022 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Melinda started a poll, so here is my input: I also agree with Martin, Cedric and Christian - RSIP is not a good = match IMHO for all the reasons stated in the conclusion of the comparison draft. "The RSIP extension mechanism has the largest impact=20 on the existing protocol and is based upon defining the necessary=20 new parameters. " "In addition,=20 RSIP requires additions/extensions to meet several of the=20 requirements. RSIP would also require several framework elements to = be added to the MIDCOM framework as identified in section 1.2.3. " Cheers, L-N -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 Sent: Thursday, October 17, 2002 11:29 AM To: Aoun, Cedric [GOLF:MA01:EXCH]; Martin Stiemerling Cc: midcom@ietf.org Subject: RE: [midcom] Evaluation: RSIP (tunneling) I agree with Cedric and Martin on this point. RSIP does not seem at all = to be a good match to the problem.=20 -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com]=20 Sent: Thursday, October 17, 2002 4:43 AM To: 'Martin Stiemerling'; midcom@ietf.org Subject: RE: [midcom] Evaluation: RSIP (tunneling) In addition to the tunnel burden, I would like to remind the WG about=20 RSIP's extensibility model vs other evaluated protocols.=20 RSIP's extensibility to meet MIDCOM's requirements requires more effort = than using the package/PIB/MIB model used by the other evaluated protocols.=20 My vote is to eliminate RSIP in this round of discussions=20 Cedric=20 -----Original Message-----=20 From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de]=20 Sent: 17 October 2002 10:12=20 To: midcom@ietf.org=20 Subject: [midcom] Evaluation: RSIP (tunneling)=20 In section 1.2.4 of the protocol evaluation doc it is mentioned that=20 RSIP uses tunnels to give hosts behind a middlebox access to public=20 network (the cited text is below). As far as I see this requires that=20 the hosts have a modified IP stack, in order to support RSIP. I see = this=20 as unsuitable for a MIDCOM solution, because I would like to use my = five=20 years old hardware SIP phone behind a packet filter. I see no way to=20 modify the IP stack of my phone.=20 The text cited below talks only about NATs, but what about pure packet=20 filters? In packet filter case I don't need a tunnel at all, that's = just=20 plain overhead! Furthermore I see a architectural difference between=20 RSIP and the midcom approach. The MIDCOM agent is not involved in the=20 data transmission, but the RISP is involved.=20 For me RSIP imposes to many obstacles in order to be a MIDCOM protocol. = Martin=20 +++=20 "RSIP with tunneling, has the advantage that the public realm IP=20 addresses and port numbers are known to the private realm host=20 application, thus no translation is needed for protocols such as=20 SDP, the FTP control protocol, RTSP, SMIL, etc.. However, this does=20 require that an RSIP server and a tunneling protocol be implemented=20 in the middlebox and an RSIP client and the tunneling protocol be=20 implemented in the private realm host. The host modifications can=20 generally be made without modification to the host application or=20 requiring the implementation of a host application agent. This is=20 viewed as a significant advantage over NAT (Network Address=20 Translation)."=20 --=20 Martin Stiemerling=20 NEC Europe Ltd. -- Network Laboratories=A0 Stiemerling@ccrle.nec.de=20 IPv4: http://www.ccrle.nec.de=A0 IPv6: http://www.ipv6.ccrle.nec.de=20 _______________________________________________=20 midcom mailing list=20 midcom@ietf.org=20 https://www1.ietf.org/mailman/listinfo/midcom=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C275F2.E3F91022 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Evaluation: RSIP (tunneling)

Melinda started a poll, so here is my input:

I also agree with Martin, Cedric and Christian - RSIP = is not a good match IMHO for
all the reasons stated in the conclusion of the = comparison draft.
"The RSIP extension mechanism has the largest = impact
    on the existing protocol and is = based upon defining the necessary
    new parameters. "
"In addition,
    RSIP requires = additions/extensions to meet several of the
    requirements. RSIP would also = require several framework elements to
    be added to the MIDCOM framework = as identified in section 1.2.3. "

Cheers,

L-N


-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: Thursday, October 17, 2002 11:29 AM
To: Aoun, Cedric [GOLF:MA01:EXCH]; Martin = Stiemerling
Cc: midcom@ietf.org
Subject: RE: [midcom] Evaluation: RSIP = (tunneling)


I agree with Cedric and Martin on this point. RSIP = does not seem at all to be a good match to the problem.

-----Original Message-----
From: Cedric Aoun [mailto:cedric.aoun@nortel= networks.com]
Sent: Thursday, October 17, 2002 4:43 AM
To: 'Martin Stiemerling'; midcom@ietf.org
Subject: RE: [midcom] Evaluation: RSIP = (tunneling)

In addition to the tunnel burden, I would like to = remind the WG about
RSIP's extensibility model vs other evaluated = protocols.
RSIP's extensibility to meet MIDCOM's requirements = requires more effort than
using the package/PIB/MIB model used by the other = evaluated protocols.
My vote is to eliminate RSIP in this round of = discussions
Cedric
-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: 17 October 2002 10:12
To: midcom@ietf.org
Subject: [midcom] Evaluation: RSIP (tunneling) =

In section 1.2.4 of the protocol evaluation doc it is = mentioned that
RSIP uses tunnels to give hosts behind a middlebox = access to public
network (the cited text is below). As far as I see = this requires that
the hosts have a modified IP stack, in order to = support RSIP. I see this
as unsuitable for a MIDCOM solution, because I would = like to use my five
years old hardware SIP phone behind a packet filter. = I see no way to
modify the IP stack of my phone.
The text cited below talks only about NATs, but what = about pure packet
filters? In packet filter case I don't need a tunnel = at all, that's just
plain overhead! Furthermore I see a architectural = difference between
RSIP and the midcom approach. The MIDCOM agent is = not involved in the
data transmission, but the RISP is involved.
For me RSIP imposes to many obstacles in order to be = a MIDCOM protocol.
Martin
+++
"RSIP with tunneling, has the advantage that = the public realm IP
addresses and port numbers are known to the private = realm host
application, thus no translation is needed for = protocols such as
SDP, the FTP control protocol, RTSP, SMIL, etc.. = However, this does
require that an RSIP server and a tunneling protocol = be implemented
in the middlebox and an RSIP client and the = tunneling protocol be
implemented in the private realm host. The host = modifications can
generally be made without modification to the host = application or
requiring the implementation of a host application = agent. This is
viewed as a significant advantage over NAT (Network = Address
Translation)."
--
Martin Stiemerling
NEC Europe Ltd. -- Network Laboratories=A0 = Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de=A0 IPv6: http://www.ipv6.ccrle.nec.de
_______________________________________________ =
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom =
_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C275F2.E3F91022-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 12:13:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16011 for ; Thu, 17 Oct 2002 12:13:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HGFmZ02545 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 12:15:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGE8v02458; Thu, 17 Oct 2002 12:14:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGDBv02433 for ; Thu, 17 Oct 2002 12:13:11 -0400 Received: from zctfs063.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15893 for ; Thu, 17 Oct 2002 12:10:54 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HGCx800051; Thu, 17 Oct 2002 18:12:59 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 18:12:58 +0200 Message-ID: From: "Cedric Aoun" To: "'Martin.Stiemerling@ccrle.nec.de'" Cc: "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Date: Thu, 17 Oct 2002 18:12:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C275F6.88518F2A" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C275F6.88518F2A Content-Type: text/plain; charset="iso-8859-1" Martin, I think we discussed several times the "session" on the mailing list. We never closed this on the list, I'm still hoping we could close this at some point. What do we mean by session? There is a relation between the Middlebox and the Midcom agent, this relation consists of: -Establishing trust and authorization levels -Establishing a security association -This relation could have a real identifier or a pseudo one based on the Midcom agent or Middlebox identity; this could be used for hand-overs or for softstate cleaning in case the Midcom agent goes down. This relation doesn't really need to have a direction for its establishment, I suggest that we take it out of the directionality of the relation from the requirements document. In addition COPS-PR could be used in the context of in path signaling for authorization policy purposes. As some of the Middleboxes will support both in path signaling (the NSIS WG delivery) and the MIDCOM off path protocol COPS-PR has the best position to be the MIDCOM protocol. Cedric -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: 17 October 2002 10:45 To: midcom@ietf.org Subject: [midcom] Evaluation: COPS and session initialisation Just a poll about the working group opinion: The MIDCOM framework and requirements say that the agent initiates the session to the middlebox. But in the COPS/COPS-PR case the way is vice versa: The middlebox initiates the session to the agent. I see this a as major difference in the particular architecture. How does the working group feel about this. Is this just a minore point or a real concern. Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C275F6.88518F2A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Evaluation: COPS and session initialisation

Martin,

I think we discussed several times the = "session" on the mailing list.
We never closed this on the list, I'm still hoping = we could close this at some point.
What do we mean by session?

There is a relation between the Middlebox and the = Midcom agent, this relation consists of:
-Establishing trust and authorization levels
-Establishing a security association
-This relation could have a real identifier or a = pseudo one based on the Midcom agent or Middlebox identity; this could = be  used for hand-overs or for softstate cleaning in case the = Midcom agent goes down.

This relation doesn't really need to have a direction = for its establishment, I suggest that we take it out of the = directionality of the relation from the requirements = document.

In addition COPS-PR could be used in the context of = in path signaling for authorization policy purposes.
As some of the Middleboxes will support both in path = signaling (the NSIS WG delivery) and the MIDCOM off path protocol = COPS-PR has the best position to be the MIDCOM protocol.

Cedric

-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: 17 October 2002 10:45
To: midcom@ietf.org
Subject: [midcom] Evaluation: COPS and session = initialisation


Just a poll about the working group opinion:
The MIDCOM framework and requirements say that the = agent initiates the
session to the middlebox. But in the COPS/COPS-PR = case the way is vice
versa: The middlebox initiates the session to the = agent.

I see this a as major difference in the particular = architecture. How
does the working group feel about this. Is this just = a minore point or a
real concern.

Martin

--
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  = Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C275F6.88518F2A-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 13:17:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18400 for ; Thu, 17 Oct 2002 13:17:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HHJUB06234 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 13:19:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHI9v06168; Thu, 17 Oct 2002 13:18:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHHDv06124 for ; Thu, 17 Oct 2002 13:17:13 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18328 for ; Thu, 17 Oct 2002 13:14:58 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9HHH9Y18105; Thu, 17 Oct 2002 19:17:09 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 47DEB6C9BC; Thu, 17 Oct 2002 19:17:08 +0200 (CEST) Date: Thu, 17 Oct 2002 19:17:07 +0200 From: Juergen Quittek To: Cedric Aoun Cc: "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Message-ID: <35725370.1034882227@[192.168.102.164]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Cedric, -- Cedric Aoun wrote on 17 October 2002 18:12 +0200: > Martin, > > I think we discussed several times the "session" on the mailing list. > We never closed this on the list, I'm still hoping we could close this at > some point. > What do we mean by session? > > There is a relation between the Middlebox and the Midcom agent, this > relation consists of: > -Establishing trust and authorization levels > -Establishing a security association > -This relation could have a real identifier or a pseudo one based on the > Midcom agent or Middlebox identity; this could be used for hand-overs or > for softstate cleaning in case the Midcom agent goes down. > > This relation doesn't really need to have a direction for its establishment, > I suggest that we take it out of the directionality of the relation from the > requirements document. I disagree. Consider the ideas of dynamic service creation. NAT and firewall are basic components of a network infrastructure. Services and corresponding midcom agents have a more dynamic character. If you add a service, you do not necessarily want to reconfigure the middlebox by telling: "There is a new agent. Please establish a connection!". Contrarily, for the service setup it is desirable just to configure the agent telling it to which middlebox(es) it has to establish associations. The same applies to service removal. How would a middlebox behave if you just disable a service including the agent. Would it continuously poll the agent, because it cannot operate without? The situation is different for the agent. It probably will find it hard to operate if the middlebox goes down, particularly if its the only box connecting inner side and outer side. In this case it makes sense that the agent regularly polls if the middlebox is up again. An extreme case also is supported much better when the agent establishes connection: With the agent initiating the assiciation, the midcom protocol can be used by each terminal that wants to communicate across a middlebox to configure the box by itself. This becomes impractical if the association is established in the other direction. > In addition COPS-PR could be used in the context of in path signaling for > authorization policy purposes. > As some of the Middleboxes will support both in path signaling (the NSIS WG > delivery) and the MIDCOM off path protocol COPS-PR has the best position to > be the MIDCOM protocol. Would be great if we could identify one protocol that has the best position! But I do not see your point. If COPS-PR is good for and used for authorization then why is it automatically a good midcom protocol? SNMP is good for and used for monitoring. Also it is implemented on almost all boxes. Still this is no reason for me to consider SNMP as well positioned. Juergen > > Cedric > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: 17 October 2002 10:45 > To: midcom@ietf.org > Subject: [midcom] Evaluation: COPS and session initialisation > > > Just a poll about the working group opinion: > The MIDCOM framework and requirements say that the agent initiates the > session to the middlebox. But in the COPS/COPS-PR case the way is vice > versa: The middlebox initiates the session to the agent. > > I see this a as major difference in the particular architecture. How > does the working group feel about this. Is this just a minore point or a > real concern. > > Martin > > -- > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 13:20:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18515 for ; Thu, 17 Oct 2002 13:20:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HHN5H06409 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 13:23:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHJ2v06206; Thu, 17 Oct 2002 13:19:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HHIjv06190 for ; Thu, 17 Oct 2002 13:18:45 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18383 for ; Thu, 17 Oct 2002 13:16:30 -0400 (EDT) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9HHIeot011744 for ; Thu, 17 Oct 2002 10:18:41 -0700 (PDT) Received: from localhost.localdomain (dhcp-128-107-212-177.cisco.com [128.107.212.177]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.0-GA) with ESMTP id ABR40346; Thu, 17 Oct 2002 10:18:40 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 500) id BC2C77F5AC; Thu, 17 Oct 2002 06:18:39 -0700 (PDT) Date: Thu, 17 Oct 2002 06:18:39 -0700 From: Scott W Brim To: midcom@ietf.org Subject: Re: [midcom] Evaluation: COPS and session initialisation Message-ID: <20021017061839.F1472@localhost.localdomain> Mail-Followup-To: Scott W Brim , midcom@ietf.org References: <3DAE7895.5040506@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DAE7895.5040506@ccrle.nec.de>; from Martin.Stiemerling@ccrle.nec.de on Thu, Oct 17, 2002 at 10:45:09AM +0200 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, Oct 17, 2002 10:45:09AM +0200, Martin Stiemerling allegedly wrote: > Just a poll about the working group opinion: > The MIDCOM framework and requirements say that the agent initiates the > session to the middlebox. But in the COPS/COPS-PR case the way is vice > versa: The middlebox initiates the session to the agent. > > I see this a as major difference in the particular architecture. How > does the working group feel about this. Is this just a minore point or a > real concern. IMHO the COPS/COPS-PR case is expressed wrong. I see no reason why the Midcom agent can't initiate the COPS relationship. It's the one that knows what needs to be installed in the middlebox. I believe the issue that confused the COPS model was that the middlebox is speaking to a policy server, and thus it "must" be the COPS PDP. Not true -- those "policy" relationships are completely independent. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 17 16:31:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25119 for ; Thu, 17 Oct 2002 16:31:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HKXfC17777 for midcom-archive@odin.ietf.org; Thu, 17 Oct 2002 16:33:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HKTOv17574; Thu, 17 Oct 2002 16:29:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HKSjv17547 for ; Thu, 17 Oct 2002 16:28:45 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24893 for ; Thu, 17 Oct 2002 16:26:27 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9HKSUY20980; Thu, 17 Oct 2002 22:28:30 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.32] (unknown [192.168.102.32]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 447736CA92; Thu, 17 Oct 2002 22:28:28 +0200 (CEST) Date: Thu, 17 Oct 2002 22:28:26 +0200 From: Juergen Quittek To: Scott W Brim , midcom@ietf.org Subject: Re: [midcom] Evaluation: COPS and session initialisation Message-ID: <1658925.1034893705@[192.168.102.32]> In-Reply-To: <20021017061839.F1472@localhost.localdomain> References: <20021017061839.F1472@localhost.localdomain> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Scott, -- Scott W Brim wrote on 17 October 2002 06:18 -0700: > On Thu, Oct 17, 2002 10:45:09AM +0200, Martin Stiemerling allegedly wrote: >> Just a poll about the working group opinion: >> The MIDCOM framework and requirements say that the agent initiates the >> session to the middlebox. But in the COPS/COPS-PR case the way is vice >> versa: The middlebox initiates the session to the agent. >> >> I see this a as major difference in the particular architecture. How >> does the working group feel about this. Is this just a minore point or a >> real concern. > > IMHO the COPS/COPS-PR case is expressed wrong. I see no reason why the > Midcom agent can't initiate the COPS relationship. It's the one that > knows what needs to be installed in the middlebox. I believe the issue > that confused the COPS model was that the middlebox is speaking to a > policy server, and thus it "must" be the COPS PDP. Not true -- those > "policy" relationships are completely independent. Please correct me if I'm wrong: So far, I understood that in the COPS model, the peer receiving configuration is the one that initiates the connection. For midcom, this would be the middlebox. Juergen > > ...Scott > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 09:55:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26534 for ; Fri, 18 Oct 2002 09:55:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IDvFv17140 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 09:57:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDtTv17091; Fri, 18 Oct 2002 09:55:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDs3v17018 for ; Fri, 18 Oct 2002 09:54:03 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26400 for ; Fri, 18 Oct 2002 09:51:48 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9IDrxY49199; Fri, 18 Oct 2002 15:53:59 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8E4245C85E; Fri, 18 Oct 2002 15:53:58 +0200 (CEST) Message-ID: <3DB013E6.9050205@ccrle.nec.de> Date: Fri, 18 Oct 2002 16:00:06 +0200 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: "Joel M. Halpern" Cc: midcom@ietf.org Subject: Re: [midcom] Evalutation: SNMP References: <5.1.0.14.0.20021017103224.018acea8@mail.stevecrocker.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Joel, Joel M. Halpern wrote: > While it is true that SNMP is not used by network operators for > configuration (or some statement close enough to taht for our purposes) > that does not mean that SNMP has not been used for configuration, or > should not be used for configuration. > > I know of several enterprise routers over the years that were strictly > configured with SNMP. I know of several enterprise operational systems > that manage and configure routers using SNMP. While I am doubtful for > other reasons as to whether SNMP is the right answer for MIDCOM, I would What are the other reasons? Can you talk about them more specifc. > certainly not rule it out. In many ways it is the best developed and > tested solution available. Compared with the other possibilites it is for sure the best developed and tested solution. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 14:20:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05374 for ; Fri, 18 Oct 2002 14:20:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IILvG00781 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 14:21:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IIITv00639; Fri, 18 Oct 2002 14:18:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IIH4v00598 for ; Fri, 18 Oct 2002 14:17:04 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05257 for ; Fri, 18 Oct 2002 14:14:45 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9IIGvxF018781 for ; Fri, 18 Oct 2002 11:16:58 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG68770; Fri, 18 Oct 2002 11:12:04 -0700 (PDT) Message-Id: <200210181812.AAG68770@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 18 Oct 2002 14:16:57 -0400 Subject: [midcom] RSIP decision Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Given how RSIP came out in the evaluation and that there's no support for keeping it in consideration for the midcom protocol, the WG consensus is that it's no longer a candidate. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 14:54:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06958 for ; Fri, 18 Oct 2002 14:54:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IIuh602660 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 14:56:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IIr9v02419; Fri, 18 Oct 2002 14:53:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IIlHv02231 for ; Fri, 18 Oct 2002 14:47:17 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06557 for ; Fri, 18 Oct 2002 14:45:00 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9IIl9Y61366; Fri, 18 Oct 2002 20:47:09 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A01526AA9F; Fri, 18 Oct 2002 20:47:07 +0200 (CEST) Message-ID: <3DB0572B.4090401@ccrle.nec.de> Date: Fri, 18 Oct 2002 20:47:07 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott W Brim Cc: midcom@ietf.org Subject: Re: [midcom] Evaluation: COPS and session initialisation References: <3DAE7895.5040506@ccrle.nec.de> <20021017061839.F1472@localhost.localdomain> 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Scott, > > IMHO the COPS/COPS-PR case is expressed wrong. I see no reason why the > Midcom agent can't initiate the COPS relationship. It's the one that > knows what needs to be installed in the middlebox. I believe the issue > that confused the COPS model was that the middlebox is speaking to a > policy server, and thus it "must" be the COPS PDP. Not true -- those > "policy" relationships are completely independent. I agree that there may be some confusion about this point. But I see the difference between the PDP to consult on policy decissions and the COPS(-PR) PDP very clear. For the initiation of the session/relationship: As far as I know is it the PEP the one who intiates the COPS session. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 14:55:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06972 for ; Fri, 18 Oct 2002 14:55:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IIum602677 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 14:56:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IIr7v02404; Fri, 18 Oct 2002 14:53:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IIi9v02115 for ; Fri, 18 Oct 2002 14:44:09 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06485 for ; Fri, 18 Oct 2002 14:41:51 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9IIi3Y61324; Fri, 18 Oct 2002 20:44:03 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B3EED6AA9F; Fri, 18 Oct 2002 20:44:01 +0200 (CEST) Message-ID: <3DB05671.8090205@ccrle.nec.de> Date: Fri, 18 Oct 2002 20:44:01 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cedric Aoun Cc: "'midcom@ietf.org'" Subject: Re: [midcom] Evaluation: COPS and session initialisation References: 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I think we discussed several times the "session" on the mailing list. > We never closed this on the list, I'm still hoping we could close this > at some point. > What do we mean by session? > > There is a relation between the Middlebox and the Midcom agent, this > relation consists of: > -Establishing trust and authorization levels > -Establishing a security association > -This relation could have a real identifier or a pseudo one based on the > Midcom agent or Middlebox identity; this could be used for hand-overs > or for softstate cleaning in case the Midcom agent goes down. Agreed. > > This relation doesn't really need to have a direction for its > establishment, I suggest that we take it out of the directionality of > the relation from the requirements document. The relationsship is from the framework document, section 4. "MIDCOM protocol": "MIDCOM shall be a client-server protocol, initiated by the agent." Section 6.2. "Registration and deregistration of MIDCOM agents" says: "MIDCOM agent profile may be pre-configured on a middlebox. Subsequent to that, the agent may choose to initiate a MIDCOM session prior to any data traffic." I always read "initiated" by the agent, that implies for me the agent starts the communication with the middlebox. We are definitely too late for deleting this directional component, because it is in our framework RFC. Another point for not initiating the communication by the middlebox, the above mentioned hand-off between agents. Imaging you have three SIP proxies, two of them as a fall-back. All three are pre-configured to the middlebox. The primary, or in duty, SIP server has a server crash, now the third SIP server takes over. How should the middlebox know that the third SIP server is the one in charge and not the second? The middlebox has to know something about the failover mechanism. Furhtermore it has to maintain to all proxies a connection at any time, that's polling! Martin > > In addition COPS-PR could be used in the context of in path signaling > for authorization policy purposes. > As some of the Middleboxes will support both in path signaling (the NSIS > WG delivery) and the MIDCOM off path protocol COPS-PR has the best > position to be the MIDCOM protocol. > > Cedric > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: 17 October 2002 10:45 > To: midcom@ietf.org > Subject: [midcom] Evaluation: COPS and session initialisation > > > Just a poll about the working group opinion: > The MIDCOM framework and requirements say that the agent initiates the > session to the middlebox. But in the COPS/COPS-PR case the way is vice > versa: The middlebox initiates the session to the agent. > > I see this a as major difference in the particular architecture. How > does the working group feel about this. Is this just a minore point or a > real concern. > > Martin > > -- > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 15:24:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07697 for ; Fri, 18 Oct 2002 15:24:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IJPwH04177 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 15:25:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJPIv04166; Fri, 18 Oct 2002 15:25:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJOav04124 for ; Fri, 18 Oct 2002 15:24:36 -0400 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07622 for ; Fri, 18 Oct 2002 15:22:19 -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 g9IJMCu29498 for ; Fri, 18 Oct 2002 15:22:12 -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 g9IJMCI29482 for ; Fri, 18 Oct 2002 15:22:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C276DB.FAFFD6C2" Date: Fri, 18 Oct 2002 13:24:30 -0600 Message-ID: Thread-Topic: Assigning media ports with Midcom-unaware NAT/Firewall Traversal Thread-Index: AcJ22/rmKLbGnZnSSweg1O/Y0bqCaQ== From: "Stukas, Michael T (Mike)" To: , , , Subject: [midcom] Assigning media ports with Midcom-unaware NAT/Firewall Traversal Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C276DB.FAFFD6C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sanjoy, Patrick and Sean, I was reading your draft and had a = question to how the RTP ports were being assigned for a given caller. I = was under the impression that when the signaling proxy received an = INVITE from a calling client that it would use the control protocol to = communicate with the RTP proxy to retreive assigned ports for the caller = to send its RTP packets to. Part of the process to identify the correct = user with the correct ports was to have the signaling proxy pass to the = RTP proxy the NAT address of the calling client. The RTP proxy would = then assign ports for the caller and callee and pass the information = back to the signaling proxy to be sent to the caller in a response = message. The problem I see is that if the NAT is a symmetrical NAT then = the NATed address that the signaling proxy sees would be different that = what the media proxy would see when the client sends the RTP packets to = establish a media path. This assumption is based on the STUN I-D that = describes the behavior of a symmetrical NAT. Could you please clarify = this part of the operation within your proposed solution. Also, can you = clarify if there is a difference between NAPT and Symmetric NAT. I know = they both translate address plus port and only accept responses from = add|port that a message was already sent to...but the question comes in = if Symmetric uses a different mapping if a source sends to a different = destination. I have not been able to get a clear resolution on a = difference between NAPT and Symmetric. =20 I also have not seen much comments on this solution since the = conversations with STUN and FANTOM at the end of last year. Any = comments on its current status. Has a proposed name been defined yet? I = am working on my Master's Thesis evaluating different traversal = solutions and would any feedback you could provide. Thanks very much, ~Mike=20 Mike Stukas AVAYA Corporation System Verification 303.538.4740 stukas@avaya.com ------_=_NextPart_001_01C276DB.FAFFD6C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assigning media ports with Midcom-unaware NAT/Firewall = Traversal

Sanjoy, Patrick and Sean,

I was reading your draft = <draft-sen-midcom-fw-nat-01.txt> and had a question to how the RTP = ports were being assigned for a given caller.  I was under the = impression that when the signaling proxy received an INVITE from a = calling client that it would use the control protocol to communicate = with the RTP proxy to retreive assigned ports for the caller to send its = RTP packets to. Part of the process to identify the correct user with = the correct ports was to have the signaling proxy pass to the RTP proxy = the NAT address of the calling client.  The RTP proxy would then = assign ports for the caller and callee and pass the information back to = the signaling proxy to be sent to the caller in a response = message.  The problem I see is that if the NAT is a symmetrical NAT = then the NATed address that the signaling proxy sees would be different = that what the media proxy would see when the client sends the RTP = packets to establish a media path.  This assumption is based on the = STUN I-D that describes the behavior of a symmetrical NAT.  Could = you please clarify this part of the operation within your proposed = solution.  Also, can you clarify if there is a difference between = NAPT and Symmetric NAT.  I know they both translate address plus = port and only accept responses from add|port that a message was already = sent to...but the question comes in if Symmetric uses a different = mapping if a source sends to a different destination. I have not been = able to get a clear resolution on a difference between NAPT and = Symmetric. 

I also have not seen much comments on = this solution since the conversations with STUN and FANTOM at the end of = last year.  Any comments on its current status. Has a proposed name = been defined yet?  I am working on my Master's Thesis evaluating = different traversal solutions and would any feedback you could = provide.

Thanks very much,

~Mike

Mike Stukas
AVAYA = Corporation
System Verification
303.538.4740
stukas@avaya.com

------_=_NextPart_001_01C276DB.FAFFD6C2-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 15:34:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07972 for ; Fri, 18 Oct 2002 15:34:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IJads04517 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 15:36:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJa5v04491; Fri, 18 Oct 2002 15:36:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJZPv04448 for ; Fri, 18 Oct 2002 15:35:25 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07935 for ; Fri, 18 Oct 2002 15:33:07 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9IJZHxF015685; Fri, 18 Oct 2002 12:35:17 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG72358; Fri, 18 Oct 2002 12:30:23 -0700 (PDT) Message-Id: <200210181930.AAG72358@mira-sjc5-4.cisco.com> To: "Stukas, Michael T (Mike)" cc: midcom@ietf.org, sanjoy@nortelnetworks.com, pats@nortelnetworks.com, march@nortelnetworks.com From: Melinda Shore Subject: Re: [midcom] Assigning media ports with Midcom-unaware NAT/Firewall Traversal In-Reply-To: Message from "Stukas, Michael T (Mike)" of "Fri, 18 Oct 2002 13:24:30 MDT." Date: Fri, 18 Oct 2002 15:35:16 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > I was reading your draft > and had a question to how the RTP ports were being > assigned for a given caller. This draft is not a midcom work item and is best discussed in direct communication with the authors. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 15:49:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08244 for ; Fri, 18 Oct 2002 15:49:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IJonf05506 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 15:50:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJl5v05416; Fri, 18 Oct 2002 15:47:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJknv05402 for ; Fri, 18 Oct 2002 15:46:49 -0400 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08174 for ; Fri, 18 Oct 2002 15:44:31 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9IJkEK13369; Fri, 18 Oct 2002 15:46:15 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 15:46:15 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DDD2@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , Scott W Brim , "Cedric Aoun" Cc: midcom@ietf.org Subject: RE: [midcom] Evaluation: COPS and session initialisation Date: Fri, 18 Oct 2002 15:46:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I shouldn't say this without looking over the protocol in detail, but would it make a real difference if the other end (non-PEP) did the initiation? Megaco, for instance, won't work properly if the MGC does the initiation. In the Megaco case, what might work would be to add a new request to the protocol (at least on semantic terms) that the MGC issues to ask the MG to connect with it. The main problem is to get the associated trust model right. So, how does this compare with the COPS-PR situation? > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Friday, October 18, 2002 2:47 PM > To: Scott W Brim > Cc: midcom@ietf.org > Subject: Re: [midcom] Evaluation: COPS and session initialisation > > > Scott, > > > > > IMHO the COPS/COPS-PR case is expressed wrong. I see no reason why > > the Midcom agent can't initiate the COPS relationship. > It's the one > > that knows what needs to be installed in the middlebox. I > believe the > > issue that confused the COPS model was that the middlebox > is speaking > > to a policy server, and thus it "must" be the COPS PDP. > Not true -- > > those "policy" relationships are completely independent. > > I agree that there may be some confusion about this point. > But I see the > difference between the PDP to consult on policy decissions and the > COPS(-PR) PDP very clear. > For the initiation of the session/relationship: > As far as I know is it the PEP the one who intiates the COPS session. > > Martin > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 15:55:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08335 for ; Fri, 18 Oct 2002 15:55:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IJvfH05746 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 15:57:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJvEv05719; Fri, 18 Oct 2002 15:57:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IJtGv05616 for ; Fri, 18 Oct 2002 15:55:16 -0400 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08298 for ; Fri, 18 Oct 2002 15:52:58 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9IJstK14052; Fri, 18 Oct 2002 15:54:55 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 15:54:55 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DDD3@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , "Stukas, Michael T (Mike)" Cc: midcom@ietf.org, "Patrick Sollee" , "Sean March" Subject: RE: [midcom] Assigning media ports with Midcom-unaware NAT/Firewa ll Traversal Date: Fri, 18 Oct 2002 15:54:47 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , How ungenerous of you! I don't think I've ever seen quite that level of restriction on a list before. Certainly in the early days of Megaco I had to ask the odd person to respect the charter and not keep agitating for us to work on a different architecture, but since then we have welcomed discussion on any Megaco-related topic, even though our official work items are few in number. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, October 18, 2002 3:35 PM > To: Stukas, Michael T (Mike) > Cc: midcom@ietf.org; sanjoy@nortelnetworks.com; Sollee, > Patrick [NGC:B601:EXCH]; March, Sean [NGC:B672:EXCH] > Subject: Re: [midcom] Assigning media ports with > Midcom-unaware NAT/Firewall Traversal > > > > I was reading your draft > > and had a question to how the RTP ports were being > > assigned for a given caller. > > This draft is not a midcom work item and is best discussed > in direct communication with the authors. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 16:15:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08725 for ; Fri, 18 Oct 2002 16:15:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IKGtQ07008 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 16:16:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IKD7v06905; Fri, 18 Oct 2002 16:13:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IKCjv06889 for ; Fri, 18 Oct 2002 16:12:45 -0400 Received: from geode.he.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08613 for ; Fri, 18 Oct 2002 16:10:26 -0400 (EDT) Received: (from hardie@localhost) by geode.he.net (8.8.6/8.8.2) id NAA29819; Fri, 18 Oct 2002 13:12:30 -0700 Message-Id: <200210182012.NAA29819@geode.he.net> Subject: Re: [midcom] Assigning media ports with Midcom-unaware NAT/Firewa To: taylor@nortelnetworks.com (Tom-PT Taylor) Date: Fri, 18 Oct 2002 13:12:29 -0700 (PDT) Cc: midcom@ietf.org In-Reply-To: <4D79C746863DD51197690002A52CDA000400DDD3@zcard0kc.ca.nortel.com> from "Tom-PT Taylor" at Oct 18, 2002 03:54:47 PM From: Ted Hardie Reply-to: Ted.Hardie@nominum.com X-Mailer: ELM [version 2.5 PL1] 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Funny, it looked to me like useful advice. Having a conversation with a group of people who have not necessarily read a spec seems very likely to have a poor signal-to-noise ratio compared to talking to the spec's authors. regards, Ted Hardie > > How ungenerous of you! I don't think I've ever seen quite that level of > restriction on a list before. Certainly in the early days of Megaco I had > to ask the odd person to respect the charter and not keep agitating for us > to work on a different architecture, but since then we have welcomed > discussion on any Megaco-related topic, even though our official work items > are few in number. > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Friday, October 18, 2002 3:35 PM > > To: Stukas, Michael T (Mike) > > Cc: midcom@ietf.org; sanjoy@nortelnetworks.com; Sollee, > > Patrick [NGC:B601:EXCH]; March, Sean [NGC:B672:EXCH] > > Subject: Re: [midcom] Assigning media ports with > > Midcom-unaware NAT/Firewall Traversal > > > > > > > I was reading your draft > > > and had a question to how the RTP ports were being > > > assigned for a given caller. > > > > This draft is not a midcom work item and is best discussed > > in direct communication with the authors. > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 18 16:27:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09045 for ; Fri, 18 Oct 2002 16:27:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IKSq307602 for midcom-archive@odin.ietf.org; Fri, 18 Oct 2002 16:28:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IKSAv07562; Fri, 18 Oct 2002 16:28:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IKRSv07501 for ; Fri, 18 Oct 2002 16:27:28 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08962 for ; Fri, 18 Oct 2002 16:25:09 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9IKRKot018281; Fri, 18 Oct 2002 13:27:20 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG74561; Fri, 18 Oct 2002 13:22:25 -0700 (PDT) Message-Id: <200210182022.AAG74561@mira-sjc5-4.cisco.com> To: "Tom-PT Taylor" cc: "Stukas, Michael T (Mike)" , midcom@ietf.org, "Patrick Sollee" , "Sean March" From: Melinda Shore Subject: Re: [midcom] Assigning media ports with Midcom-unaware NAT/Firewa ll Traversal In-Reply-To: Message from "Tom-PT Taylor" of "Fri, 18 Oct 2002 15:54:47 EDT." <4D79C746863DD51197690002A52CDA000400DDD3@zcard0kc.ca.nortel.com> Date: Fri, 18 Oct 2002 16:27:18 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > How ungenerous of you! I don't think I've ever seen quite that level of > restriction on a list before. Tom, The solution outlined in that draft, as well as the solution outlined in the Davies draft, were considered, discussed, and rejected in favor of STUN. Furthermore, this was a request to re-open that discussion in order to support a school project, not to support IETF work. I'm sorry you found it harsh and I apologize for the tone, but the discussion itself really does not belong on the midcom mailing list. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 21 15:18:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11896 for ; Mon, 21 Oct 2002 15:18:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LJKVX17392 for midcom-archive@odin.ietf.org; Mon, 21 Oct 2002 15:20:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJJav17139; Mon, 21 Oct 2002 15:19:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LJCxv16759 for ; Mon, 21 Oct 2002 15:12:59 -0400 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11256 for ; Mon, 21 Oct 2002 15:10:39 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9LJCet19959; Mon, 21 Oct 2002 15:12:41 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TWX0LJZV; Mon, 21 Oct 2002 15:12:40 -0400 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TSNC868M; Mon, 21 Oct 2002 15:11:50 -0400 Message-Id: <5.0.0.25.0.20021021143800.037691a0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 21 Oct 2002 15:08:58 -0400 To: Martin Stiemerling From: Kwok Ho Chan Subject: Re: [midcom] Evaluation: COPS and session initialisation Cc: "Cedric Aoun" , "'midcom@ietf.org'" , Kwok Ho Chan In-Reply-To: <3DB05671.8090205@ccrle.nec.de> References: 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Martin, All: I will try to answer your question. As we have already identified in the protocol evaluation document, "COPS does not meet the directionality part of the requirement. The definition of COPS allows a PEP (Middlebox) to establish communication with a PDP (MIDCOM Agent)." But, we added the following explanations: "However, nothing explicitly prohibits a PDP from establishing communication with a PEP. The PEP could have local policies dictating what action to take when it is contacted by an unknown PDP. These actions, defined in the local policies, would ensure the proper establishment of an authorized association. " Once the COPS connection is open, it is perfectly within the COPS protocol for the PDP to send unsolicited decisions to the PEP (for example the midcom agent sending an open pinhole decision to the middlebox. Also to address the fail over points you made below. The PEP (Middlebox) can have local policy indicating the order by which it will contact the PDPs (MIDCOM Agents). This local policy can actually be installed by the primary SIP server (in the example you gave), indicating if communication is lost between it (the primary SIP server) and the Middlebox, the Middlebox MUST contact the THIRD SIP server as the highest priority back-up SIP server, then the SECOND SIP server if the both the PRIMARY/FIRST SIP server and the THIRD SIP server is not available to provide the required services. Notice the fail over is totally deterministic and also controlled by Policy of the controlling domain. Also only a single connection between a Middlebox and a MIDCOM Agent is maintain at any given time, the one that is being used. Also lets say the PRIMARY SIP server degrades/dies/off-load its service gracefully (you can also view this as part of load balancing between multiple SIP servers), the PRIMARY SIP server can REDIRECT the Middlebox to get its service from a specific other SIP server, in the example you gave below, this should be the THIRD SIP server. This is done without any interruption to the functionality the Middlebox is providing. This is how COPS is intent to be used without any modification to the current RFCs. With the above, one may take a step back and think: "Is the directional requirement really 'required' ?? Or is it the FUNCTIONALITY that is really 'required' ??" I have shown how COPS satisfy the fail over and high availability FUNCTIONALITIES without talking about the directional 'requirement'. Hope I have clarify some of the points raised. -- Kwok Ho Chan -- At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >>I think we discussed several times the "session" on the mailing list. >>We never closed this on the list, I'm still hoping we could close this at >>some point. >>What do we mean by session? >>There is a relation between the Middlebox and the Midcom agent, this >>relation consists of: >>-Establishing trust and authorization levels >>-Establishing a security association >>-This relation could have a real identifier or a pseudo one based on the >>Midcom agent or Middlebox identity; this could be used for hand-overs or >>for softstate cleaning in case the Midcom agent goes down. > >Agreed. > >>This relation doesn't really need to have a direction for its >>establishment, I suggest that we take it out of the directionality of the >>relation from the requirements document. > >The relationsship is from the framework document, section 4. "MIDCOM >protocol": "MIDCOM shall be a client-server protocol, initiated by the >agent." >Section 6.2. "Registration and deregistration of MIDCOM agents" says: >"MIDCOM agent profile may be pre-configured on a middlebox. >Subsequent to that, the agent may choose to initiate a MIDCOM session >prior to any data traffic." > >I always read "initiated" by the agent, that implies for me the agent >starts the communication with the middlebox. We are definitely too late >for deleting this directional component, because it is in our framework RFC. > >Another point for not initiating the communication by the middlebox, the >above mentioned hand-off between agents. Imaging you have three SIP >proxies, two of them as a fall-back. All three are pre-configured to the >middlebox. The primary, or in duty, SIP server has a server crash, now the >third SIP server takes over. How should the middlebox know that the third >SIP server is the one in charge and not the second? The middlebox has to >know something about the failover mechanism. Furhtermore it has to >maintain to all proxies a connection at any time, that's polling! > >Martin > >>In addition COPS-PR could be used in the context of in path signaling for >>authorization policy purposes. >>As some of the Middleboxes will support both in path signaling (the NSIS >>WG delivery) and the MIDCOM off path protocol COPS-PR has the best >>position to be the MIDCOM protocol. >>Cedric >>-----Original Message----- >>From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >>Sent: 17 October 2002 10:45 >>To: midcom@ietf.org >>Subject: [midcom] Evaluation: COPS and session initialisation >> >>Just a poll about the working group opinion: >>The MIDCOM framework and requirements say that the agent initiates the >>session to the middlebox. But in the COPS/COPS-PR case the way is vice >>versa: The middlebox initiates the session to the agent. >>I see this a as major difference in the particular architecture. How >>does the working group feel about this. Is this just a minore point or a >>real concern. >>Martin >>-- Martin Stiemerling >>NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >>IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>https://www1.ietf.org/mailman/listinfo/midcom > > > >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 21 16:27:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14053 for ; Mon, 21 Oct 2002 16:27:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LKSuI21411 for midcom-archive@odin.ietf.org; Mon, 21 Oct 2002 16:28:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKSIv21384; Mon, 21 Oct 2002 16:28:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKRLv21354 for ; Mon, 21 Oct 2002 16:27:21 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14010 for ; Mon, 21 Oct 2002 16:24:59 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9LKREY51072; Mon, 21 Oct 2002 22:27:14 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.32] (unknown [192.168.102.32]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6324C6194C; Mon, 21 Oct 2002 22:27:10 +0200 (CEST) Date: Mon, 21 Oct 2002 22:27:08 +0200 From: Juergen Quittek To: Kwok Ho Chan , Martin Stiemerling Cc: Cedric Aoun , "'midcom@ietf.org'" Subject: Re: [midcom] Evaluation: COPS and session initialisation Message-ID: <2440599.1035239227@[192.168.102.32]> In-Reply-To: <5.0.0.25.0.20021021143800.037691a0@zbl6c002.corpeast.baynetworks.com> References: <5.0.0.25.0.20021021143800.037691a0@zbl6c002.corpeast.baynetworks.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kwok, -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: > Martin, All: > I will try to answer your question. As we have already identified in the protocol evaluation document, > "COPS does not meet the directionality part of the requirement. The definition of COPS > allows a PEP (Middlebox) to establish communication with a PDP (MIDCOM Agent)." > But, we added the following explanations: > "However, nothing explicitly prohibits a PDP from establishing communication with a > PEP. The PEP could have local policies dictating what action to take when it is > contacted by an unknown PDP. These actions, defined in the local policies, would > ensure the proper establishment of an authorized association. " Yes, I think this is exactly the point. You can create a framework, for example using policies, for initiating the association between middlebox and agent. You also can use a new Midcom Session Initiation Protocol to be used by the agent for telling the middlebox: "Please contact me for establishing a midcom session". The question is, whether this would be a good choice considering operational issues. I see service installation, modification and removal to be much more dynamic than middlebox installation, modification and removal. Therefore, I consider it an operational disadvantage having to configure the middlebox each time a service is installed, is modified (changes the failover sequence), or is removed. Juergen > Once the COPS connection is open, it is perfectly within the COPS protocol for > the PDP to send unsolicited decisions to the PEP (for example the midcom agent > sending an open pinhole decision to the middlebox. > > Also to address the fail over points you made below. > The PEP (Middlebox) can have local policy indicating the order by which it will > contact the PDPs (MIDCOM Agents). This local policy can actually be installed > by the primary SIP server (in the example you gave), indicating if communication > is lost between it (the primary SIP server) and the Middlebox, the Middlebox MUST > contact the THIRD SIP server as the highest priority back-up SIP server, then > the SECOND SIP server if the both the PRIMARY/FIRST SIP server and the > THIRD SIP server is not available to provide the required services. > Notice the fail over is totally deterministic and also controlled by Policy of the > controlling domain. > > Also only a single connection between a Middlebox and a MIDCOM Agent > is maintain at any given time, the one that is being used. > > Also lets say the PRIMARY SIP server degrades/dies/off-load its service > gracefully (you can also view this as part of load balancing between > multiple SIP servers), the PRIMARY SIP server can REDIRECT the > Middlebox to get its service from a specific other SIP server, in the > example you gave below, this should be the THIRD SIP server. > This is done without any interruption to the functionality the Middlebox > is providing. > > This is how COPS is intent to be used without any modification to the current RFCs. > > With the above, one may take a step back and think: > "Is the directional requirement really 'required' ?? Or is it the FUNCTIONALITY that is > really 'required' ??" > > I have shown how COPS satisfy the fail over and high availability FUNCTIONALITIES > without talking about the directional 'requirement'. > > Hope I have clarify some of the points raised. > > -- Kwok Ho Chan -- > > > > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >>> I think we discussed several times the "session" on the mailing list. >>> We never closed this on the list, I'm still hoping we could close this at >>> some point. >>> What do we mean by session? >>> There is a relation between the Middlebox and the Midcom agent, this >>> relation consists of: >>> -Establishing trust and authorization levels >>> -Establishing a security association >>> -This relation could have a real identifier or a pseudo one based on the >>> Midcom agent or Middlebox identity; this could be used for hand-overs or >>> for softstate cleaning in case the Midcom agent goes down. >> >> Agreed. >> >>> This relation doesn't really need to have a direction for its >>> establishment, I suggest that we take it out of the directionality of the >>> relation from the requirements document. >> >> The relationsship is from the framework document, section 4. "MIDCOM >> protocol": "MIDCOM shall be a client-server protocol, initiated by the >> agent." >> Section 6.2. "Registration and deregistration of MIDCOM agents" says: >> "MIDCOM agent profile may be pre-configured on a middlebox. >> Subsequent to that, the agent may choose to initiate a MIDCOM session >> prior to any data traffic." >> >> I always read "initiated" by the agent, that implies for me the agent >> starts the communication with the middlebox. We are definitely too late >> for deleting this directional component, because it is in our framework RFC. >> >> Another point for not initiating the communication by the middlebox, the >> above mentioned hand-off between agents. Imaging you have three SIP >> proxies, two of them as a fall-back. All three are pre-configured to the >> middlebox. The primary, or in duty, SIP server has a server crash, now the >> third SIP server takes over. How should the middlebox know that the third >> SIP server is the one in charge and not the second? The middlebox has to >> know something about the failover mechanism. Furhtermore it has to >> maintain to all proxies a connection at any time, that's polling! >> >> Martin >> >>> In addition COPS-PR could be used in the context of in path signaling for >>> authorization policy purposes. >>> As some of the Middleboxes will support both in path signaling (the NSIS >>> WG delivery) and the MIDCOM off path protocol COPS-PR has the best >>> position to be the MIDCOM protocol. >>> Cedric >>> -----Original Message----- >>> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >>> Sent: 17 October 2002 10:45 >>> To: midcom@ietf.org >>> Subject: [midcom] Evaluation: COPS and session initialisation >>> >>> Just a poll about the working group opinion: >>> The MIDCOM framework and requirements say that the agent initiates the >>> session to the middlebox. But in the COPS/COPS-PR case the way is vice >>> versa: The middlebox initiates the session to the agent. >>> I see this a as major difference in the particular architecture. How >>> does the working group feel about this. Is this just a minore point or a >>> real concern. >>> Martin >>> -- Martin Stiemerling >>> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >>> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de >>> _______________________________________________ >>> midcom mailing list >>> midcom@ietf.org >>> https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> -- >> Martin Stiemerling >> >> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 21 17:09:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15656 for ; Mon, 21 Oct 2002 17:09:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LLAw624618 for midcom-archive@odin.ietf.org; Mon, 21 Oct 2002 17:10:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LL74v23969; Mon, 21 Oct 2002 17:07:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LL6cv23910 for ; Mon, 21 Oct 2002 17:06:38 -0400 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15563 for ; Mon, 21 Oct 2002 17:04:16 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9LL6Nt29841; Mon, 21 Oct 2002 17:06:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Oct 2002 17:06:24 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DDF4@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , "Kwok-Ho Chan" , Martin Stiemerling Cc: "Cedric Aoun" , "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Date: Mon, 21 Oct 2002 17:06:23 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , "Configuration" is just a word. If you said "administration" I would be more worried, because that implies cost. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Monday, October 21, 2002 4:27 PM > To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling > Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' > Subject: Re: [midcom] Evaluation: COPS and session initialisation > > > Kwok, > > -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: > > > Martin, All: > > I will try to answer your question. As we have already > identified in the protocol evaluation document, > > "COPS does not meet the directionality part of the > requirement. The definition of COPS > > allows a PEP (Middlebox) to establish communication with a PDP > > (MIDCOM Agent)." But, we added the following explanations: > > "However, nothing explicitly prohibits a PDP from > establishing communication with a > > PEP. The PEP could have local policies dictating what > action to take when it is > > contacted by an unknown PDP. These actions, defined in > the local policies, would > > ensure the proper establishment of an authorized association. " > > Yes, I think this is exactly the point. You can create a > framework, for example using policies, for initiating the > association between middlebox and agent. You also can use a > new Midcom Session Initiation Protocol to be used by the > agent for telling the middlebox: "Please contact me for > establishing a midcom session". > > The question is, whether this would be a good choice > considering operational issues. I see service installation, > modification and removal to be much more dynamic than > middlebox installation, modification and removal. Therefore, > I consider it an operational disadvantage having to configure > the middlebox each time a service is installed, is modified > (changes the failover sequence), or is removed. > > Juergen > > > > Once the COPS connection is open, it is perfectly within the COPS > > protocol for the PDP to send unsolicited decisions to the PEP (for > > example the midcom agent sending an open pinhole decision to the > > middlebox. > > > > Also to address the fail over points you made below. > > The PEP (Middlebox) can have local policy indicating the order by > > which it will contact the PDPs (MIDCOM Agents). This local > policy can > > actually be installed by the primary SIP server (in the example you > > gave), indicating if communication is lost between it (the > primary SIP > > server) and the Middlebox, the Middlebox MUST contact the THIRD SIP > > server as the highest priority back-up SIP server, then the > SECOND SIP > > server if the both the PRIMARY/FIRST SIP server and the THIRD SIP > > server is not available to provide the required services. > Notice the > > fail over is totally deterministic and also controlled by Policy of > > the controlling domain. > > > > Also only a single connection between a Middlebox and a > MIDCOM Agent > > is maintain at any given time, the one that is being used. > > > > Also lets say the PRIMARY SIP server degrades/dies/off-load its > > service gracefully (you can also view this as part of load > balancing > > between multiple SIP servers), the PRIMARY SIP server can > REDIRECT the > > Middlebox to get its service from a specific other SIP > server, in the > > example you gave below, this should be the THIRD SIP > server. This is > > done without any interruption to the functionality the Middlebox is > > providing. > > > > This is how COPS is intent to be used without any > modification to the > > current RFCs. > > > > With the above, one may take a step back and think: > > "Is the directional requirement really 'required' ?? Or is it the > > FUNCTIONALITY that is really 'required' ??" > > > > I have shown how COPS satisfy the fail over and high availability > > FUNCTIONALITIES without talking about the directional 'requirement'. > > > > Hope I have clarify some of the points raised. > > > > -- Kwok Ho Chan -- > > > > > > > > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: > >>> I think we discussed several times the "session" on the mailing > >>> list. We never closed this on the list, I'm still hoping we could > >>> close this at some point. What do we mean by session? > >>> There is a relation between the Middlebox and the Midcom > agent, this > >>> relation consists of: > >>> -Establishing trust and authorization levels > >>> -Establishing a security association > >>> -This relation could have a real identifier or a pseudo > one based on the > >>> Midcom agent or Middlebox identity; this could be used > for hand-overs or > >>> for softstate cleaning in case the Midcom agent goes down. > >> > >> Agreed. > >> > >>> This relation doesn't really need to have a direction for its > >>> establishment, I suggest that we take it out of the > directionality > >>> of the relation from the requirements document. > >> > >> The relationsship is from the framework document, section > 4. "MIDCOM > >> protocol": "MIDCOM shall be a client-server protocol, initiated by > >> the agent." Section 6.2. "Registration and deregistration > of MIDCOM > >> agents" says: "MIDCOM agent profile may be pre-configured on a > >> middlebox. Subsequent to that, the agent may choose to initiate a > >> MIDCOM session prior to any data traffic." > >> > >> I always read "initiated" by the agent, that implies for > me the agent > >> starts the communication with the middlebox. We are definitely too > >> late for deleting this directional component, because it is in our > >> framework RFC. > >> > >> Another point for not initiating the communication by the > middlebox, > >> the above mentioned hand-off between agents. Imaging you > have three > >> SIP proxies, two of them as a fall-back. All three are > pre-configured > >> to the middlebox. The primary, or in duty, SIP server has a server > >> crash, now the third SIP server takes over. How should the > middlebox > >> know that the third SIP server is the one in charge and not the > >> second? The middlebox has to know something about the failover > >> mechanism. Furhtermore it has to maintain to all proxies a > connection > >> at any time, that's polling! > >> > >> Martin > >> > >>> In addition COPS-PR could be used in the context of in path > >>> signaling for authorization policy purposes. As some of the > >>> Middleboxes will support both in path signaling (the NSIS WG > >>> delivery) and the MIDCOM off path protocol COPS-PR has the best > >>> position to be the MIDCOM protocol. Cedric > >>> -----Original Message----- > >>> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > >>> Sent: 17 October 2002 10:45 > >>> To: midcom@ietf.org > >>> Subject: [midcom] Evaluation: COPS and session initialisation > >>> > >>> Just a poll about the working group opinion: > >>> The MIDCOM framework and requirements say that the agent > initiates > >>> the session to the middlebox. But in the COPS/COPS-PR > case the way > >>> is vice > >>> versa: The middlebox initiates the session to the agent. > >>> I see this a as major difference in the particular > architecture. How > >>> does the working group feel about this. Is this just a > minore point or a > >>> real concern. > >>> Martin > >>> -- Martin Stiemerling > >>> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > >>> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > >>> _______________________________________________ > >>> midcom mailing list > >>> midcom@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/midcom > >> > >> > >> > >> -- > >> Martin Stiemerling > >> > >> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > >> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > >> > >> _______________________________________________ > >> midcom mailing list > >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 21 18:07:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17006 for ; Mon, 21 Oct 2002 18:07:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LM9Dl27431 for midcom-archive@odin.ietf.org; Mon, 21 Oct 2002 18:09:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LM5Gv26804; Mon, 21 Oct 2002 18:05:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LM4hv26772 for ; Mon, 21 Oct 2002 18:04:43 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16909 for ; Mon, 21 Oct 2002 18:02:21 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9LM4ZY52232; Tue, 22 Oct 2002 00:04:35 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.32] (unknown [192.168.102.32]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B01776199C; Tue, 22 Oct 2002 00:04:30 +0200 (CEST) Date: Tue, 22 Oct 2002 00:04:27 +0200 From: Juergen Quittek To: Tom-PT Taylor , Kwok-Ho Chan , Martin Stiemerling Cc: Cedric Aoun , "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Message-ID: <8280747.1035245067@[192.168.102.32]> In-Reply-To: <4D79C746863DD51197690002A52CDA000400DDF4@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA000400DDF4@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, I'm not sure how "administration" is exactly defined, but if you don't provide some additional non-midcom support for automatically configuring the midbox with the list of agents to establish connections to, then the administrator might need to configure the the middlebox manually. This becomes extramely entertaining, if you disable a service, let's say IP telephony for asome hours for maintenance. How would after maintenence hours the middlebox learn that the agent is up again and that a new session should be established. I hope not by manual interaction between middlebox and administrator. Juergen -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: > "Configuration" is just a word. If you said "administration" I would be > more worried, because that implies cost. > >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Monday, October 21, 2002 4:27 PM >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >> Subject: Re: [midcom] Evaluation: COPS and session initialisation >> >> >> Kwok, >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: >> >> > Martin, All: >> > I will try to answer your question. As we have already >> identified in the protocol evaluation document, >> > "COPS does not meet the directionality part of the >> requirement. The definition of COPS >> > allows a PEP (Middlebox) to establish communication with a PDP >> > (MIDCOM Agent)." But, we added the following explanations: >> > "However, nothing explicitly prohibits a PDP from >> establishing communication with a >> > PEP. The PEP could have local policies dictating what >> action to take when it is >> > contacted by an unknown PDP. These actions, defined in >> the local policies, would >> > ensure the proper establishment of an authorized association. " >> >> Yes, I think this is exactly the point. You can create a >> framework, for example using policies, for initiating the >> association between middlebox and agent. You also can use a >> new Midcom Session Initiation Protocol to be used by the >> agent for telling the middlebox: "Please contact me for >> establishing a midcom session". >> >> The question is, whether this would be a good choice >> considering operational issues. I see service installation, >> modification and removal to be much more dynamic than >> middlebox installation, modification and removal. Therefore, >> I consider it an operational disadvantage having to configure >> the middlebox each time a service is installed, is modified >> (changes the failover sequence), or is removed. >> >> Juergen >> >> >> > Once the COPS connection is open, it is perfectly within the COPS >> > protocol for the PDP to send unsolicited decisions to the PEP (for >> > example the midcom agent sending an open pinhole decision to the >> > middlebox. >> > >> > Also to address the fail over points you made below. >> > The PEP (Middlebox) can have local policy indicating the order by >> > which it will contact the PDPs (MIDCOM Agents). This local >> policy can >> > actually be installed by the primary SIP server (in the example you >> > gave), indicating if communication is lost between it (the >> primary SIP >> > server) and the Middlebox, the Middlebox MUST contact the THIRD SIP >> > server as the highest priority back-up SIP server, then the >> SECOND SIP >> > server if the both the PRIMARY/FIRST SIP server and the THIRD SIP >> > server is not available to provide the required services. >> Notice the >> > fail over is totally deterministic and also controlled by Policy of >> > the controlling domain. >> > >> > Also only a single connection between a Middlebox and a >> MIDCOM Agent >> > is maintain at any given time, the one that is being used. >> > >> > Also lets say the PRIMARY SIP server degrades/dies/off-load its >> > service gracefully (you can also view this as part of load >> balancing >> > between multiple SIP servers), the PRIMARY SIP server can >> REDIRECT the >> > Middlebox to get its service from a specific other SIP >> server, in the >> > example you gave below, this should be the THIRD SIP >> server. This is >> > done without any interruption to the functionality the Middlebox is >> > providing. >> > >> > This is how COPS is intent to be used without any >> modification to the >> > current RFCs. >> > >> > With the above, one may take a step back and think: >> > "Is the directional requirement really 'required' ?? Or is it the >> > FUNCTIONALITY that is really 'required' ??" >> > >> > I have shown how COPS satisfy the fail over and high availability >> > FUNCTIONALITIES without talking about the directional 'requirement'. >> > >> > Hope I have clarify some of the points raised. >> > >> > -- Kwok Ho Chan -- >> > >> > >> > >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >> >>> I think we discussed several times the "session" on the mailing >> >>> list. We never closed this on the list, I'm still hoping we could >> >>> close this at some point. What do we mean by session? >> >>> There is a relation between the Middlebox and the Midcom >> agent, this >> >>> relation consists of: >> >>> -Establishing trust and authorization levels >> >>> -Establishing a security association >> >>> -This relation could have a real identifier or a pseudo >> one based on the >> >>> Midcom agent or Middlebox identity; this could be used >> for hand-overs or >> >>> for softstate cleaning in case the Midcom agent goes down. >> >> >> >> Agreed. >> >> >> >>> This relation doesn't really need to have a direction for its >> >>> establishment, I suggest that we take it out of the >> directionality >> >>> of the relation from the requirements document. >> >> >> >> The relationsship is from the framework document, section >> 4. "MIDCOM >> >> protocol": "MIDCOM shall be a client-server protocol, initiated by >> >> the agent." Section 6.2. "Registration and deregistration >> of MIDCOM >> >> agents" says: "MIDCOM agent profile may be pre-configured on a >> >> middlebox. Subsequent to that, the agent may choose to initiate a >> >> MIDCOM session prior to any data traffic." >> >> >> >> I always read "initiated" by the agent, that implies for >> me the agent >> >> starts the communication with the middlebox. We are definitely too >> >> late for deleting this directional component, because it is in our >> >> framework RFC. >> >> >> >> Another point for not initiating the communication by the >> middlebox, >> >> the above mentioned hand-off between agents. Imaging you >> have three >> >> SIP proxies, two of them as a fall-back. All three are >> pre-configured >> >> to the middlebox. The primary, or in duty, SIP server has a server >> >> crash, now the third SIP server takes over. How should the >> middlebox >> >> know that the third SIP server is the one in charge and not the >> >> second? The middlebox has to know something about the failover >> >> mechanism. Furhtermore it has to maintain to all proxies a >> connection >> >> at any time, that's polling! >> >> >> >> Martin >> >> >> >>> In addition COPS-PR could be used in the context of in path >> >>> signaling for authorization policy purposes. As some of the >> >>> Middleboxes will support both in path signaling (the NSIS WG >> >>> delivery) and the MIDCOM off path protocol COPS-PR has the best >> >>> position to be the MIDCOM protocol. Cedric >> >>> -----Original Message----- >> >>> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >> >>> Sent: 17 October 2002 10:45 >> >>> To: midcom@ietf.org >> >>> Subject: [midcom] Evaluation: COPS and session initialisation >> >>> >> >>> Just a poll about the working group opinion: >> >>> The MIDCOM framework and requirements say that the agent >> initiates >> >>> the session to the middlebox. But in the COPS/COPS-PR >> case the way >> >>> is vice >> >>> versa: The middlebox initiates the session to the agent. >> >>> I see this a as major difference in the particular >> architecture. How >> >>> does the working group feel about this. Is this just a >> minore point or a >> >>> real concern. >> >>> Martin >> >>> -- Martin Stiemerling >> >>> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >> >>> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de >> >>> _______________________________________________ >> >>> midcom mailing list >> >>> midcom@ietf.org >> >>> https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> >> >> >> -- >> >> Martin Stiemerling >> >> >> >> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >> >> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de >> >> >> >> _______________________________________________ >> >> midcom mailing list >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >> > >> > _______________________________________________ >> > midcom mailing list >> > midcom@ietf.org >> > https://www1.ietf.org/mailman/listinfo/midcom >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 21 18:20:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17292 for ; Mon, 21 Oct 2002 18:20:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LMMiv27895 for midcom-archive@odin.ietf.org; Mon, 21 Oct 2002 18:22:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LMM9v27880; Mon, 21 Oct 2002 18:22:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LMLNv27859 for ; Mon, 21 Oct 2002 18:21:23 -0400 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17265 for ; Mon, 21 Oct 2002 18:19:02 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9LML7B04045; Mon, 21 Oct 2002 18:21:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Oct 2002 18:21:08 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DDF9@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , "Kwok-Ho Chan" , Martin Stiemerling Cc: "Cedric Aoun" , "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Date: Mon, 21 Oct 2002 18:21:06 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I think we are agreed on the basic requirement: establishment and takedown of MIDCOM sessions must not require manual intervention or maintenance outage of the equipment. There is the policy aspect of MIDCOM session and failover management as described in the framework, but I don't think that is what we are discussing here. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Monday, October 21, 2002 6:04 PM > To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho > [BL60:470:EXCH]; Martin Stiemerling > Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' > Subject: RE: [midcom] Evaluation: COPS and session initialisation > > > Tom, > > I'm not sure how "administration" is exactly defined, but > if you don't provide some additional non-midcom support > for automatically configuring the midbox with the list of > agents to establish connections to, then the administrator > might need to configure the the middlebox manually. > > This becomes extramely entertaining, if you disable a > service, let's say IP telephony for asome hours for > maintenance. How would after maintenence hours the middlebox > learn that the agent is up again and that a new session > should be established. I hope not by manual interaction > between middlebox and administrator. > > Juergen > > > -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: > > > "Configuration" is just a word. If you said > "administration" I would > > be more worried, because that implies cost. > > > >> -----Original Message----- > >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >> Sent: Monday, October 21, 2002 4:27 PM > >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling > >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' > >> Subject: Re: [midcom] Evaluation: COPS and session initialisation > >> > >> > >> Kwok, > >> > >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: > >> > >> > Martin, All: > >> > I will try to answer your question. As we have already > >> identified in the protocol evaluation document, > >> > "COPS does not meet the directionality part of the > >> requirement. The definition of COPS > >> > allows a PEP (Middlebox) to establish communication > with a PDP > >> > (MIDCOM Agent)." But, we added the following explanations: > >> > "However, nothing explicitly prohibits a PDP from > >> establishing communication with a > >> > PEP. The PEP could have local policies dictating what > >> action to take when it is > >> > contacted by an unknown PDP. These actions, defined in > >> the local policies, would > >> > ensure the proper establishment of an authorized > association. " > >> > >> Yes, I think this is exactly the point. You can create a > framework, > >> for example using policies, for initiating the association between > >> middlebox and agent. You also can use a new Midcom Session > Initiation > >> Protocol to be used by the agent for telling the > middlebox: "Please > >> contact me for establishing a midcom session". > >> > >> The question is, whether this would be a good choice considering > >> operational issues. I see service installation, modification and > >> removal to be much more dynamic than middlebox installation, > >> modification and removal. Therefore, I consider it an operational > >> disadvantage having to configure the middlebox each time a > service is > >> installed, is modified (changes the failover sequence), or is > >> removed. > >> > >> Juergen > >> > >> > >> > Once the COPS connection is open, it is perfectly within > the COPS > >> > protocol for the PDP to send unsolicited decisions to > the PEP (for > >> > example the midcom agent sending an open pinhole decision to the > >> > middlebox. > >> > > >> > Also to address the fail over points you made below. > >> > The PEP (Middlebox) can have local policy indicating the > order by > >> > which it will contact the PDPs (MIDCOM Agents). This local > >> policy can > >> > actually be installed by the primary SIP server (in the > example you > >> > gave), indicating if communication is lost between it (the > >> primary SIP > >> > server) and the Middlebox, the Middlebox MUST contact > the THIRD SIP > >> > server as the highest priority back-up SIP server, then the > >> SECOND SIP > >> > server if the both the PRIMARY/FIRST SIP server and the > THIRD SIP > >> > server is not available to provide the required services. > >> Notice the > >> > fail over is totally deterministic and also controlled > by Policy of > >> > the controlling domain. > >> > > >> > Also only a single connection between a Middlebox and a > >> MIDCOM Agent > >> > is maintain at any given time, the one that is being used. > >> > > >> > Also lets say the PRIMARY SIP server degrades/dies/off-load its > >> > service gracefully (you can also view this as part of load > >> balancing > >> > between multiple SIP servers), the PRIMARY SIP server can > >> REDIRECT the > >> > Middlebox to get its service from a specific other SIP > >> server, in the > >> > example you gave below, this should be the THIRD SIP > >> server. This is > >> > done without any interruption to the functionality the > Middlebox is > >> > providing. > >> > > >> > This is how COPS is intent to be used without any > >> modification to the > >> > current RFCs. > >> > > >> > With the above, one may take a step back and think: > >> > "Is the directional requirement really 'required' ?? Or > is it the > >> > FUNCTIONALITY that is really 'required' ??" > >> > > >> > I have shown how COPS satisfy the fail over and high > availability > >> > FUNCTIONALITIES without talking about the directional > >> > 'requirement'. > >> > > >> > Hope I have clarify some of the points raised. > >> > > >> > -- Kwok Ho Chan -- > >> > > >> > > >> > > >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: > >> >>> I think we discussed several times the "session" on > the mailing > >> >>> list. We never closed this on the list, I'm still > hoping we could > >> >>> close this at some point. What do we mean by session? > There is a > >> >>> relation between the Middlebox and the Midcom > >> agent, this > >> >>> relation consists of: > >> >>> -Establishing trust and authorization levels -Establishing a > >> >>> security association -This relation could have a real > identifier > >> >>> or a pseudo > >> one based on the > >> >>> Midcom agent or Middlebox identity; this could be used > >> for hand-overs or > >> >>> for softstate cleaning in case the Midcom agent goes down. > >> >> > >> >> Agreed. > >> >> > >> >>> This relation doesn't really need to have a direction for its > >> >>> establishment, I suggest that we take it out of the > >> directionality > >> >>> of the relation from the requirements document. > >> >> > >> >> The relationsship is from the framework document, section > >> 4. "MIDCOM > >> >> protocol": "MIDCOM shall be a client-server protocol, > initiated by > >> >> the agent." Section 6.2. "Registration and deregistration > >> of MIDCOM > >> >> agents" says: "MIDCOM agent profile may be pre-configured on a > >> >> middlebox. Subsequent to that, the agent may choose to > initiate a > >> >> MIDCOM session prior to any data traffic." > >> >> > >> >> I always read "initiated" by the agent, that implies for > >> me the agent > >> >> starts the communication with the middlebox. We are > definitely too > >> >> late for deleting this directional component, because > it is in our > >> >> framework RFC. > >> >> > >> >> Another point for not initiating the communication by the > >> middlebox, > >> >> the above mentioned hand-off between agents. Imaging you > >> have three > >> >> SIP proxies, two of them as a fall-back. All three are > >> pre-configured > >> >> to the middlebox. The primary, or in duty, SIP server > has a server > >> >> crash, now the third SIP server takes over. How should the > >> middlebox > >> >> know that the third SIP server is the one in charge and not the > >> >> second? The middlebox has to know something about the failover > >> >> mechanism. Furhtermore it has to maintain to all proxies a > >> connection > >> >> at any time, that's polling! > >> >> > >> >> Martin > >> >> > >> >>> In addition COPS-PR could be used in the context of in path > >> >>> signaling for authorization policy purposes. As some of the > >> >>> Middleboxes will support both in path signaling (the NSIS WG > >> >>> delivery) and the MIDCOM off path protocol COPS-PR has > the best > >> >>> position to be the MIDCOM protocol. Cedric -----Original > >> >>> Message----- > >> >>> From: Martin Stiemerling > [mailto:Martin.Stiemerling@ccrle.nec.de] > >> >>> Sent: 17 October 2002 10:45 > >> >>> To: midcom@ietf.org > >> >>> Subject: [midcom] Evaluation: COPS and session initialisation > >> >>> > >> >>> Just a poll about the working group opinion: > >> >>> The MIDCOM framework and requirements say that the agent > >> initiates > >> >>> the session to the middlebox. But in the COPS/COPS-PR > >> case the way > >> >>> is vice > >> >>> versa: The middlebox initiates the session to the agent. I see > >> >>> this a as major difference in the particular > >> architecture. How > >> >>> does the working group feel about this. Is this just a > >> minore point or a > >> >>> real concern. > >> >>> Martin > >> >>> -- Martin Stiemerling > >> >>> NEC Europe Ltd. -- Network Laboratories > Stiemerling@ccrle.nec.de > >> >>> IPv4: http://www.ccrle.nec.de IPv6: > http://www.ipv6.ccrle.nec.de > >> >>> > _______________________________________________ > >> >>> midcom mailing list > >> >>> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom > >> >> > >> >> > >> >> > >> >> -- > >> >> Martin Stiemerling > >> >> > >> >> NEC Europe Ltd. -- Network Laboratories > Stiemerling@ccrle.nec.de > >> >> IPv4: http://www.ccrle.nec.de IPv6: > http://www.ipv6.ccrle.nec.de > >> >> > >> >> > _______________________________________________ > >> >> midcom mailing list > >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom > >> > > >> > _______________________________________________ > >> > midcom mailing list > >> > midcom@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/midcom > >> > >> > >> _______________________________________________ > >> midcom mailing list > >> midcom@ietf.org > >> https://www1.ietf.org/mailman/listinfo/midcom > >> > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 03:50:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07989 for ; Tue, 22 Oct 2002 03:50:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9M7qTX27967 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 03:52:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M7dUv27374; Tue, 22 Oct 2002 03:39:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M7cjv27335 for ; Tue, 22 Oct 2002 03:38:45 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07828 for ; Tue, 22 Oct 2002 03:36:17 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9M7cWY60898; Tue, 22 Oct 2002 09:38:32 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8638161B8A; Tue, 22 Oct 2002 09:38:28 +0200 (CEST) Date: Tue, 22 Oct 2002 09:38:31 +0200 From: Juergen Quittek To: Tom-PT Taylor , Kwok-Ho Chan , Martin Stiemerling Cc: Cedric Aoun , "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Message-ID: <1229297.1035279511@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA000400DDF9@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA000400DDF9@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, -- Tom-PT Taylor wrote on 21 October 2002 18:21 -0400: > I think we are agreed on the basic requirement: establishment and takedown > of MIDCOM sessions must not require manual intervention or maintenance > outage of the equipment. There is the policy aspect of MIDCOM session and > failover management as described in the framework, but I don't think that is > what we are discussing here. The point I could not understand so far, is how to meet this requirement (without additional support from additional protocols) when the middlebox (and not the agent) is the party that requests opening a midcom session. Juergen >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Monday, October 21, 2002 6:04 PM >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho >> [BL60:470:EXCH]; Martin Stiemerling >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >> Subject: RE: [midcom] Evaluation: COPS and session initialisation >> >> >> Tom, >> >> I'm not sure how "administration" is exactly defined, but >> if you don't provide some additional non-midcom support >> for automatically configuring the midbox with the list of >> agents to establish connections to, then the administrator >> might need to configure the the middlebox manually. >> >> This becomes extramely entertaining, if you disable a >> service, let's say IP telephony for asome hours for >> maintenance. How would after maintenence hours the middlebox >> learn that the agent is up again and that a new session >> should be established. I hope not by manual interaction >> between middlebox and administrator. >> >> Juergen >> >> >> -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: >> >> > "Configuration" is just a word. If you said >> "administration" I would >> > be more worried, because that implies cost. >> > >> >> -----Original Message----- >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >> Sent: Monday, October 21, 2002 4:27 PM >> >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >> >> Subject: Re: [midcom] Evaluation: COPS and session initialisation >> >> >> >> >> >> Kwok, >> >> >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: >> >> >> >> > Martin, All: >> >> > I will try to answer your question. As we have already >> >> identified in the protocol evaluation document, >> >> > "COPS does not meet the directionality part of the >> >> requirement. The definition of COPS >> >> > allows a PEP (Middlebox) to establish communication >> with a PDP >> >> > (MIDCOM Agent)." But, we added the following explanations: >> >> > "However, nothing explicitly prohibits a PDP from >> >> establishing communication with a >> >> > PEP. The PEP could have local policies dictating what >> >> action to take when it is >> >> > contacted by an unknown PDP. These actions, defined in >> >> the local policies, would >> >> > ensure the proper establishment of an authorized >> association. " >> >> >> >> Yes, I think this is exactly the point. You can create a >> framework, >> >> for example using policies, for initiating the association between >> >> middlebox and agent. You also can use a new Midcom Session >> Initiation >> >> Protocol to be used by the agent for telling the >> middlebox: "Please >> >> contact me for establishing a midcom session". >> >> >> >> The question is, whether this would be a good choice considering >> >> operational issues. I see service installation, modification and >> >> removal to be much more dynamic than middlebox installation, >> >> modification and removal. Therefore, I consider it an operational >> >> disadvantage having to configure the middlebox each time a >> service is >> >> installed, is modified (changes the failover sequence), or is >> >> removed. >> >> >> >> Juergen >> >> >> >> >> >> > Once the COPS connection is open, it is perfectly within >> the COPS >> >> > protocol for the PDP to send unsolicited decisions to >> the PEP (for >> >> > example the midcom agent sending an open pinhole decision to the >> >> > middlebox. >> >> > >> >> > Also to address the fail over points you made below. >> >> > The PEP (Middlebox) can have local policy indicating the >> order by >> >> > which it will contact the PDPs (MIDCOM Agents). This local >> >> policy can >> >> > actually be installed by the primary SIP server (in the >> example you >> >> > gave), indicating if communication is lost between it (the >> >> primary SIP >> >> > server) and the Middlebox, the Middlebox MUST contact >> the THIRD SIP >> >> > server as the highest priority back-up SIP server, then the >> >> SECOND SIP >> >> > server if the both the PRIMARY/FIRST SIP server and the >> THIRD SIP >> >> > server is not available to provide the required services. >> >> Notice the >> >> > fail over is totally deterministic and also controlled >> by Policy of >> >> > the controlling domain. >> >> > >> >> > Also only a single connection between a Middlebox and a >> >> MIDCOM Agent >> >> > is maintain at any given time, the one that is being used. >> >> > >> >> > Also lets say the PRIMARY SIP server degrades/dies/off-load its >> >> > service gracefully (you can also view this as part of load >> >> balancing >> >> > between multiple SIP servers), the PRIMARY SIP server can >> >> REDIRECT the >> >> > Middlebox to get its service from a specific other SIP >> >> server, in the >> >> > example you gave below, this should be the THIRD SIP >> >> server. This is >> >> > done without any interruption to the functionality the >> Middlebox is >> >> > providing. >> >> > >> >> > This is how COPS is intent to be used without any >> >> modification to the >> >> > current RFCs. >> >> > >> >> > With the above, one may take a step back and think: >> >> > "Is the directional requirement really 'required' ?? Or >> is it the >> >> > FUNCTIONALITY that is really 'required' ??" >> >> > >> >> > I have shown how COPS satisfy the fail over and high >> availability >> >> > FUNCTIONALITIES without talking about the directional >> >> > 'requirement'. >> >> > >> >> > Hope I have clarify some of the points raised. >> >> > >> >> > -- Kwok Ho Chan -- >> >> > >> >> > >> >> > >> >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >> >> >>> I think we discussed several times the "session" on >> the mailing >> >> >>> list. We never closed this on the list, I'm still >> hoping we could >> >> >>> close this at some point. What do we mean by session? >> There is a >> >> >>> relation between the Middlebox and the Midcom >> >> agent, this >> >> >>> relation consists of: >> >> >>> -Establishing trust and authorization levels -Establishing a >> >> >>> security association -This relation could have a real >> identifier >> >> >>> or a pseudo >> >> one based on the >> >> >>> Midcom agent or Middlebox identity; this could be used >> >> for hand-overs or >> >> >>> for softstate cleaning in case the Midcom agent goes down. >> >> >> >> >> >> Agreed. >> >> >> >> >> >>> This relation doesn't really need to have a direction for its >> >> >>> establishment, I suggest that we take it out of the >> >> directionality >> >> >>> of the relation from the requirements document. >> >> >> >> >> >> The relationsship is from the framework document, section >> >> 4. "MIDCOM >> >> >> protocol": "MIDCOM shall be a client-server protocol, >> initiated by >> >> >> the agent." Section 6.2. "Registration and deregistration >> >> of MIDCOM >> >> >> agents" says: "MIDCOM agent profile may be pre-configured on a >> >> >> middlebox. Subsequent to that, the agent may choose to >> initiate a >> >> >> MIDCOM session prior to any data traffic." >> >> >> >> >> >> I always read "initiated" by the agent, that implies for >> >> me the agent >> >> >> starts the communication with the middlebox. We are >> definitely too >> >> >> late for deleting this directional component, because >> it is in our >> >> >> framework RFC. >> >> >> >> >> >> Another point for not initiating the communication by the >> >> middlebox, >> >> >> the above mentioned hand-off between agents. Imaging you >> >> have three >> >> >> SIP proxies, two of them as a fall-back. All three are >> >> pre-configured >> >> >> to the middlebox. The primary, or in duty, SIP server >> has a server >> >> >> crash, now the third SIP server takes over. How should the >> >> middlebox >> >> >> know that the third SIP server is the one in charge and not the >> >> >> second? The middlebox has to know something about the failover >> >> >> mechanism. Furhtermore it has to maintain to all proxies a >> >> connection >> >> >> at any time, that's polling! >> >> >> >> >> >> Martin >> >> >> >> >> >>> In addition COPS-PR could be used in the context of in path >> >> >>> signaling for authorization policy purposes. As some of the >> >> >>> Middleboxes will support both in path signaling (the NSIS WG >> >> >>> delivery) and the MIDCOM off path protocol COPS-PR has >> the best >> >> >>> position to be the MIDCOM protocol. Cedric -----Original >> >> >>> Message----- >> >> >>> From: Martin Stiemerling >> [mailto:Martin.Stiemerling@ccrle.nec.de] >> >> >>> Sent: 17 October 2002 10:45 >> >> >>> To: midcom@ietf.org >> >> >>> Subject: [midcom] Evaluation: COPS and session initialisation >> >> >>> >> >> >>> Just a poll about the working group opinion: >> >> >>> The MIDCOM framework and requirements say that the agent >> >> initiates >> >> >>> the session to the middlebox. But in the COPS/COPS-PR >> >> case the way >> >> >>> is vice >> >> >>> versa: The middlebox initiates the session to the agent. I see >> >> >>> this a as major difference in the particular >> >> architecture. How >> >> >>> does the working group feel about this. Is this just a >> >> minore point or a >> >> >>> real concern. >> >> >>> Martin >> >> >>> -- Martin Stiemerling >> >> >>> NEC Europe Ltd. -- Network Laboratories >> Stiemerling@ccrle.nec.de >> >> >>> IPv4: http://www.ccrle.nec.de IPv6: >> http://www.ipv6.ccrle.nec.de >> >> >>> >> _______________________________________________ >> >> >>> midcom mailing list >> >> >>> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Martin Stiemerling >> >> >> >> >> >> NEC Europe Ltd. -- Network Laboratories >> Stiemerling@ccrle.nec.de >> >> >> IPv4: http://www.ccrle.nec.de IPv6: >> http://www.ipv6.ccrle.nec.de >> >> >> >> >> >> >> _______________________________________________ >> >> >> midcom mailing list >> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >> >> > >> >> > _______________________________________________ >> >> > midcom mailing list >> >> > midcom@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> >> _______________________________________________ >> >> midcom mailing list >> >> midcom@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 05:37:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09844 for ; Tue, 22 Oct 2002 05:37:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9M9d0C01936 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 05:39:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M9cDv01916; Tue, 22 Oct 2002 05:38:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M9bHv01753 for ; Tue, 22 Oct 2002 05:37:17 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09830 for ; Tue, 22 Oct 2002 05:34:59 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9M9bFY67885; Tue, 22 Oct 2002 11:37:15 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3E9CE59C12; Tue, 22 Oct 2002 11:37:14 +0200 (CEST) Message-ID: <3DB51DD0.8050409@ccrle.nec.de> Date: Tue, 22 Oct 2002 11:43:44 +0200 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Kwok Ho Chan Cc: Cedric Aoun , "'midcom@ietf.org'" Subject: Re: [midcom] Evaluation: COPS and session initialisation References: <5.0.0.25.0.20021021143800.037691a0@zbl6c002.corpeast.baynetworks.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Kwok, first of all thank you for the clarification! But are you talking about COPS or COPS-PR in your email? Please find my further comments inline. Kwok Ho Chan wrote: > Martin, All: > I will try to answer your question. As we have already identified in the > protocol evaluation document, > "COPS does not meet the directionality part of the requirement. The > definition of COPS > allows a PEP (Middlebox) to establish communication with a PDP > (MIDCOM Agent)." > But, we added the following explanations: > "However, nothing explicitly prohibits a PDP from establishing > communication with a > PEP. The PEP could have local policies dictating what action to take > when it is > contacted by an unknown PDP. These actions, defined in the local > policies, would > ensure the proper establishment of an authorized association. " > > Once the COPS connection is open, it is perfectly within the COPS > protocol for Here is the point: an open COPS connection. How does the COPS PEP know when to open the connection? I see that the agent only knows the point of time when it needs to be connected to the middlebox. > the PDP to send unsolicited decisions to the PEP (for example the midcom > agent > sending an open pinhole decision to the middlebox. [...] > Also lets say the PRIMARY SIP server degrades/dies/off-load its service > gracefully (you can also view this as part of load balancing between > multiple SIP servers), the PRIMARY SIP server can REDIRECT the > Middlebox to get its service from a specific other SIP server, in the > example you gave below, this should be the THIRD SIP server. > This is done without any interruption to the functionality the Middlebox > is providing. > > This is how COPS is intent to be used without any modification to the > current RFCs. OK ,I see that COPS (or do mean COPS-PR?) can fulfil these requirements. > > With the above, one may take a step back and think: > "Is the directional requirement really 'required' ?? Or is it the > FUNCTIONALITY that is > really 'required' ??" We need the functionality that the agent determines its needs about being connected to the middlebox. Martin > > I have shown how COPS satisfy the fail over and high availability > FUNCTIONALITIES > without talking about the directional 'requirement'. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 08:52:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14565 for ; Tue, 22 Oct 2002 08:52:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MCrws11695 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 08:53:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MCqKv11625; Tue, 22 Oct 2002 08:52:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MCpTv11585 for ; Tue, 22 Oct 2002 08:51:29 -0400 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14428 for ; Tue, 22 Oct 2002 08:49:10 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MCpH919724; Tue, 22 Oct 2002 08:51:17 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 08:51:17 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DDFC@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , "Kwok-Ho Chan" , Martin Stiemerling Cc: "Cedric Aoun" , "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Date: Tue, 22 Oct 2002 08:51:14 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I think the proposal is that the agent be the one to initiate the session, as per the requirements, even if it contradicts the COPS-PR design philosophy. The confusion arises because, as I read Kwok-Ho's note, the first half says this is possible but then the second half goes on to discuss the arrangement you have been expressing concerns about. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Tuesday, October 22, 2002 3:39 AM > To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho > [BL60:470:EXCH]; Martin Stiemerling > Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' > Subject: RE: [midcom] Evaluation: COPS and session initialisation > > > Tom, > > -- Tom-PT Taylor wrote on 21 October 2002 18:21 -0400: > > I think we are agreed on the basic requirement: establishment and > > takedown of MIDCOM sessions must not require manual intervention or > > maintenance outage of the equipment. There is the policy aspect of > > MIDCOM session and failover management as described in the > framework, > > but I don't think that is what we are discussing here. > > The point I could not understand so far, is how to meet this > requirement (without additional support from additional > protocols) when the middlebox (and not the agent) is the > party that requests opening a midcom session. > > Juergen > > > >> -----Original Message----- > >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >> Sent: Monday, October 21, 2002 6:04 PM > >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH]; > >> Martin Stiemerling > >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' > >> Subject: RE: [midcom] Evaluation: COPS and session initialisation > >> > >> > >> Tom, > >> > >> I'm not sure how "administration" is exactly defined, but > >> if you don't provide some additional non-midcom support > >> for automatically configuring the midbox with the list of > agents to > >> establish connections to, then the administrator might need to > >> configure the the middlebox manually. > >> > >> This becomes extramely entertaining, if you disable a > service, let's > >> say IP telephony for asome hours for maintenance. How would after > >> maintenence hours the middlebox learn that the agent is up > again and > >> that a new session should be established. I hope not by manual > >> interaction between middlebox and administrator. > >> > >> Juergen > >> > >> > >> -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: > >> > >> > "Configuration" is just a word. If you said > >> "administration" I would > >> > be more worried, because that implies cost. > >> > > >> >> -----Original Message----- > >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >> >> Sent: Monday, October 21, 2002 4:27 PM > >> >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling > >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' > >> >> Subject: Re: [midcom] Evaluation: COPS and session > initialisation > >> >> > >> >> > >> >> Kwok, > >> >> > >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: > >> >> > >> >> > Martin, All: > >> >> > I will try to answer your question. As we have already > >> >> identified in the protocol evaluation document, > >> >> > "COPS does not meet the directionality part of the > >> >> requirement. The definition of COPS > >> >> > allows a PEP (Middlebox) to establish communication > >> with a PDP > >> >> > (MIDCOM Agent)." But, we added the following explanations: > >> >> > "However, nothing explicitly prohibits a PDP from > >> >> establishing communication with a > >> >> > PEP. The PEP could have local policies dictating what > >> >> action to take when it is > >> >> > contacted by an unknown PDP. These actions, defined in > >> >> the local policies, would > >> >> > ensure the proper establishment of an authorized > >> association. " > >> >> > >> >> Yes, I think this is exactly the point. You can create a > >> framework, > >> >> for example using policies, for initiating the > association between > >> >> middlebox and agent. You also can use a new Midcom Session > >> Initiation > >> >> Protocol to be used by the agent for telling the > >> middlebox: "Please > >> >> contact me for establishing a midcom session". > >> >> > >> >> The question is, whether this would be a good choice > considering > >> >> operational issues. I see service installation, > modification and > >> >> removal to be much more dynamic than middlebox installation, > >> >> modification and removal. Therefore, I consider it an > operational > >> >> disadvantage having to configure the middlebox each time a > >> service is > >> >> installed, is modified (changes the failover sequence), or is > >> >> removed. > >> >> > >> >> Juergen > >> >> > >> >> > >> >> > Once the COPS connection is open, it is perfectly within > >> the COPS > >> >> > protocol for the PDP to send unsolicited decisions to > >> the PEP (for > >> >> > example the midcom agent sending an open pinhole > decision to the > >> >> > middlebox. > >> >> > > >> >> > Also to address the fail over points you made below. The PEP > >> >> > (Middlebox) can have local policy indicating the > >> order by > >> >> > which it will contact the PDPs (MIDCOM Agents). This local > >> >> policy can > >> >> > actually be installed by the primary SIP server (in the > >> example you > >> >> > gave), indicating if communication is lost between it (the > >> >> primary SIP > >> >> > server) and the Middlebox, the Middlebox MUST contact > >> the THIRD SIP > >> >> > server as the highest priority back-up SIP server, then the > >> >> SECOND SIP > >> >> > server if the both the PRIMARY/FIRST SIP server and the > >> THIRD SIP > >> >> > server is not available to provide the required services. > >> >> Notice the > >> >> > fail over is totally deterministic and also controlled > >> by Policy of > >> >> > the controlling domain. > >> >> > > >> >> > Also only a single connection between a Middlebox and a > >> >> MIDCOM Agent > >> >> > is maintain at any given time, the one that is being used. > >> >> > > >> >> > Also lets say the PRIMARY SIP server > degrades/dies/off-load its > >> >> > service gracefully (you can also view this as part of load > >> >> balancing > >> >> > between multiple SIP servers), the PRIMARY SIP server can > >> >> REDIRECT the > >> >> > Middlebox to get its service from a specific other SIP > >> >> server, in the > >> >> > example you gave below, this should be the THIRD SIP > >> >> server. This is > >> >> > done without any interruption to the functionality the > >> Middlebox is > >> >> > providing. > >> >> > > >> >> > This is how COPS is intent to be used without any > >> >> modification to the > >> >> > current RFCs. > >> >> > > >> >> > With the above, one may take a step back and think: > >> >> > "Is the directional requirement really 'required' ?? Or > >> is it the > >> >> > FUNCTIONALITY that is really 'required' ??" > >> >> > > >> >> > I have shown how COPS satisfy the fail over and high > >> availability > >> >> > FUNCTIONALITIES without talking about the directional > >> >> > 'requirement'. > >> >> > > >> >> > Hope I have clarify some of the points raised. > >> >> > > >> >> > -- Kwok Ho Chan -- > >> >> > > >> >> > > >> >> > > >> >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: > >> >> >>> I think we discussed several times the "session" on > >> the mailing > >> >> >>> list. We never closed this on the list, I'm still > >> hoping we could > >> >> >>> close this at some point. What do we mean by session? > >> There is a > >> >> >>> relation between the Middlebox and the Midcom > >> >> agent, this > >> >> >>> relation consists of: > >> >> >>> -Establishing trust and authorization levels > -Establishing a > >> >> >>> security association -This relation could have a real > >> identifier > >> >> >>> or a pseudo > >> >> one based on the > >> >> >>> Midcom agent or Middlebox identity; this could be used > >> >> for hand-overs or > >> >> >>> for softstate cleaning in case the Midcom agent goes down. > >> >> >> > >> >> >> Agreed. > >> >> >> > >> >> >>> This relation doesn't really need to have a > direction for its > >> >> >>> establishment, I suggest that we take it out of the > >> >> directionality > >> >> >>> of the relation from the requirements document. > >> >> >> > >> >> >> The relationsship is from the framework document, section > >> >> 4. "MIDCOM > >> >> >> protocol": "MIDCOM shall be a client-server protocol, > >> initiated by > >> >> >> the agent." Section 6.2. "Registration and deregistration > >> >> of MIDCOM > >> >> >> agents" says: "MIDCOM agent profile may be > pre-configured on a > >> >> >> middlebox. Subsequent to that, the agent may choose to > >> initiate a > >> >> >> MIDCOM session prior to any data traffic." > >> >> >> > >> >> >> I always read "initiated" by the agent, that implies for > >> >> me the agent > >> >> >> starts the communication with the middlebox. We are > >> definitely too > >> >> >> late for deleting this directional component, because > >> it is in our > >> >> >> framework RFC. > >> >> >> > >> >> >> Another point for not initiating the communication by the > >> >> middlebox, > >> >> >> the above mentioned hand-off between agents. Imaging you > >> >> have three > >> >> >> SIP proxies, two of them as a fall-back. All three are > >> >> pre-configured > >> >> >> to the middlebox. The primary, or in duty, SIP server > >> has a server > >> >> >> crash, now the third SIP server takes over. How should the > >> >> middlebox > >> >> >> know that the third SIP server is the one in charge > and not the > >> >> >> second? The middlebox has to know something about > the failover > >> >> >> mechanism. Furhtermore it has to maintain to all proxies a > >> >> connection > >> >> >> at any time, that's polling! > >> >> >> > >> >> >> Martin > >> >> >> > >> >> >>> In addition COPS-PR could be used in the context of in path > >> >> >>> signaling for authorization policy purposes. As some of the > >> >> >>> Middleboxes will support both in path signaling (the NSIS WG > >> >> >>> delivery) and the MIDCOM off path protocol COPS-PR has > >> the best > >> >> >>> position to be the MIDCOM protocol. Cedric -----Original > >> >> >>> Message----- > >> >> >>> From: Martin Stiemerling > >> [mailto:Martin.Stiemerling@ccrle.nec.de] > >> >> >>> Sent: 17 October 2002 10:45 > >> >> >>> To: midcom@ietf.org > >> >> >>> Subject: [midcom] Evaluation: COPS and session > initialisation > >> >> >>> > >> >> >>> Just a poll about the working group opinion: > >> >> >>> The MIDCOM framework and requirements say that the agent > >> >> initiates > >> >> >>> the session to the middlebox. But in the COPS/COPS-PR > >> >> case the way > >> >> >>> is vice > >> >> >>> versa: The middlebox initiates the session to the > agent. I see > >> >> >>> this a as major difference in the particular > >> >> architecture. How > >> >> >>> does the working group feel about this. Is this just a > >> >> minore point or a > >> >> >>> real concern. > >> >> >>> Martin > >> >> >>> -- Martin Stiemerling > >> >> >>> NEC Europe Ltd. -- Network Laboratories > >> Stiemerling@ccrle.nec.de > >> >> >>> IPv4: http://www.ccrle.nec.de IPv6: > >> http://www.ipv6.ccrle.nec.de > >> >> >>> > >> _______________________________________________ > >> >> >>> midcom mailing list > >> >> >>> midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > >> >> >> > >> >> > >> > >> >> >> > >> >> >> -- > >> >> >> Martin Stiemerling > >> >> >> > >> >> >> NEC Europe Ltd. -- Network Laboratories > >> Stiemerling@ccrle.nec.de > >> >> >> IPv4: http://www.ccrle.nec.de IPv6: > >> http://www.ipv6.ccrle.nec.de > >> >> >> > >> >> >> > >> _______________________________________________ > >> >> >> midcom mailing list > >> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom > >> >> > > >> >> > _______________________________________________ > >> >> > midcom mailing list > >> >> > midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom > >> >> > >> >> > >> >> _______________________________________________ > >> >> midcom mailing list > >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom > >> >> > >> > >> > >> > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 09:50:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17355 for ; Tue, 22 Oct 2002 09:50:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MDqlh15162 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 09:52:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MDq9v15141; Tue, 22 Oct 2002 09:52:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MDpIv15107 for ; Tue, 22 Oct 2002 09:51:18 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17298 for ; Tue, 22 Oct 2002 09:48:57 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9MDpBY81024; Tue, 22 Oct 2002 15:51:12 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B4E4561EA1; Tue, 22 Oct 2002 15:51:09 +0200 (CEST) Date: Tue, 22 Oct 2002 15:51:09 +0200 From: Juergen Quittek To: Tom-PT Taylor , Kwok-Ho Chan , Martin Stiemerling Cc: Cedric Aoun , "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Message-ID: <23587747.1035301869@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA000400DDFC@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA000400DDFC@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kwok, Has this unconventional usage of COPS-PR already been discussed earier in the COPS-PR community? Or was the idea developed just for meeting the midcom requirements? Juergen -- Tom-PT Taylor wrote on 22 October 2002 08:51 -0400: > I think the proposal is that the agent be the one to initiate the session, > as per the requirements, even if it contradicts the COPS-PR design > philosophy. The confusion arises because, as I read Kwok-Ho's note, the > first half says this is possible but then the second half goes on to discuss > the arrangement you have been expressing concerns about. >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Tuesday, October 22, 2002 3:39 AM >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho >> [BL60:470:EXCH]; Martin Stiemerling >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >> Subject: RE: [midcom] Evaluation: COPS and session initialisation >> >> >> Tom, >> >> -- Tom-PT Taylor wrote on 21 October 2002 18:21 -0400: >> > I think we are agreed on the basic requirement: establishment and >> > takedown of MIDCOM sessions must not require manual intervention or >> > maintenance outage of the equipment. There is the policy aspect of >> > MIDCOM session and failover management as described in the >> framework, >> > but I don't think that is what we are discussing here. >> >> The point I could not understand so far, is how to meet this >> requirement (without additional support from additional >> protocols) when the middlebox (and not the agent) is the >> party that requests opening a midcom session. >> >> Juergen >> >> >> >> -----Original Message----- >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >> Sent: Monday, October 21, 2002 6:04 PM >> >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH]; >> >> Martin Stiemerling >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >> >> Subject: RE: [midcom] Evaluation: COPS and session initialisation >> >> >> >> >> >> Tom, >> >> >> >> I'm not sure how "administration" is exactly defined, but >> >> if you don't provide some additional non-midcom support >> >> for automatically configuring the midbox with the list of >> agents to >> >> establish connections to, then the administrator might need to >> >> configure the the middlebox manually. >> >> >> >> This becomes extramely entertaining, if you disable a >> service, let's >> >> say IP telephony for asome hours for maintenance. How would after >> >> maintenence hours the middlebox learn that the agent is up >> again and >> >> that a new session should be established. I hope not by manual >> >> interaction between middlebox and administrator. >> >> >> >> Juergen >> >> >> >> >> >> -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: >> >> >> >> > "Configuration" is just a word. If you said >> >> "administration" I would >> >> > be more worried, because that implies cost. >> >> > >> >> >> -----Original Message----- >> >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >> >> Sent: Monday, October 21, 2002 4:27 PM >> >> >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling >> >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >> >> >> Subject: Re: [midcom] Evaluation: COPS and session >> initialisation >> >> >> >> >> >> >> >> >> Kwok, >> >> >> >> >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: >> >> >> >> >> >> > Martin, All: >> >> >> > I will try to answer your question. As we have already >> >> >> identified in the protocol evaluation document, >> >> >> > "COPS does not meet the directionality part of the >> >> >> requirement. The definition of COPS >> >> >> > allows a PEP (Middlebox) to establish communication >> >> with a PDP >> >> >> > (MIDCOM Agent)." But, we added the following explanations: >> >> >> > "However, nothing explicitly prohibits a PDP from >> >> >> establishing communication with a >> >> >> > PEP. The PEP could have local policies dictating what >> >> >> action to take when it is >> >> >> > contacted by an unknown PDP. These actions, defined in >> >> >> the local policies, would >> >> >> > ensure the proper establishment of an authorized >> >> association. " >> >> >> >> >> >> Yes, I think this is exactly the point. You can create a >> >> framework, >> >> >> for example using policies, for initiating the >> association between >> >> >> middlebox and agent. You also can use a new Midcom Session >> >> Initiation >> >> >> Protocol to be used by the agent for telling the >> >> middlebox: "Please >> >> >> contact me for establishing a midcom session". >> >> >> >> >> >> The question is, whether this would be a good choice >> considering >> >> >> operational issues. I see service installation, >> modification and >> >> >> removal to be much more dynamic than middlebox installation, >> >> >> modification and removal. Therefore, I consider it an >> operational >> >> >> disadvantage having to configure the middlebox each time a >> >> service is >> >> >> installed, is modified (changes the failover sequence), or is >> >> >> removed. >> >> >> >> >> >> Juergen >> >> >> >> >> >> >> >> >> > Once the COPS connection is open, it is perfectly within >> >> the COPS >> >> >> > protocol for the PDP to send unsolicited decisions to >> >> the PEP (for >> >> >> > example the midcom agent sending an open pinhole >> decision to the >> >> >> > middlebox. >> >> >> > >> >> >> > Also to address the fail over points you made below. The PEP >> >> >> > (Middlebox) can have local policy indicating the >> >> order by >> >> >> > which it will contact the PDPs (MIDCOM Agents). This local >> >> >> policy can >> >> >> > actually be installed by the primary SIP server (in the >> >> example you >> >> >> > gave), indicating if communication is lost between it (the >> >> >> primary SIP >> >> >> > server) and the Middlebox, the Middlebox MUST contact >> >> the THIRD SIP >> >> >> > server as the highest priority back-up SIP server, then the >> >> >> SECOND SIP >> >> >> > server if the both the PRIMARY/FIRST SIP server and the >> >> THIRD SIP >> >> >> > server is not available to provide the required services. >> >> >> Notice the >> >> >> > fail over is totally deterministic and also controlled >> >> by Policy of >> >> >> > the controlling domain. >> >> >> > >> >> >> > Also only a single connection between a Middlebox and a >> >> >> MIDCOM Agent >> >> >> > is maintain at any given time, the one that is being used. >> >> >> > >> >> >> > Also lets say the PRIMARY SIP server >> degrades/dies/off-load its >> >> >> > service gracefully (you can also view this as part of load >> >> >> balancing >> >> >> > between multiple SIP servers), the PRIMARY SIP server can >> >> >> REDIRECT the >> >> >> > Middlebox to get its service from a specific other SIP >> >> >> server, in the >> >> >> > example you gave below, this should be the THIRD SIP >> >> >> server. This is >> >> >> > done without any interruption to the functionality the >> >> Middlebox is >> >> >> > providing. >> >> >> > >> >> >> > This is how COPS is intent to be used without any >> >> >> modification to the >> >> >> > current RFCs. >> >> >> > >> >> >> > With the above, one may take a step back and think: >> >> >> > "Is the directional requirement really 'required' ?? Or >> >> is it the >> >> >> > FUNCTIONALITY that is really 'required' ??" >> >> >> > >> >> >> > I have shown how COPS satisfy the fail over and high >> >> availability >> >> >> > FUNCTIONALITIES without talking about the directional >> >> >> > 'requirement'. >> >> >> > >> >> >> > Hope I have clarify some of the points raised. >> >> >> > >> >> >> > -- Kwok Ho Chan -- >> >> >> > >> >> >> > >> >> >> > >> >> >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >> >> >> >>> I think we discussed several times the "session" on >> >> the mailing >> >> >> >>> list. We never closed this on the list, I'm still >> >> hoping we could >> >> >> >>> close this at some point. What do we mean by session? >> >> There is a >> >> >> >>> relation between the Middlebox and the Midcom >> >> >> agent, this >> >> >> >>> relation consists of: >> >> >> >>> -Establishing trust and authorization levels >> -Establishing a >> >> >> >>> security association -This relation could have a real >> >> identifier >> >> >> >>> or a pseudo >> >> >> one based on the >> >> >> >>> Midcom agent or Middlebox identity; this could be used >> >> >> for hand-overs or >> >> >> >>> for softstate cleaning in case the Midcom agent goes down. >> >> >> >> >> >> >> >> Agreed. >> >> >> >> >> >> >> >>> This relation doesn't really need to have a >> direction for its >> >> >> >>> establishment, I suggest that we take it out of the >> >> >> directionality >> >> >> >>> of the relation from the requirements document. >> >> >> >> >> >> >> >> The relationsship is from the framework document, section >> >> >> 4. "MIDCOM >> >> >> >> protocol": "MIDCOM shall be a client-server protocol, >> >> initiated by >> >> >> >> the agent." Section 6.2. "Registration and deregistration >> >> >> of MIDCOM >> >> >> >> agents" says: "MIDCOM agent profile may be >> pre-configured on a >> >> >> >> middlebox. Subsequent to that, the agent may choose to >> >> initiate a >> >> >> >> MIDCOM session prior to any data traffic." >> >> >> >> >> >> >> >> I always read "initiated" by the agent, that implies for >> >> >> me the agent >> >> >> >> starts the communication with the middlebox. We are >> >> definitely too >> >> >> >> late for deleting this directional component, because >> >> it is in our >> >> >> >> framework RFC. >> >> >> >> >> >> >> >> Another point for not initiating the communication by the >> >> >> middlebox, >> >> >> >> the above mentioned hand-off between agents. Imaging you >> >> >> have three >> >> >> >> SIP proxies, two of them as a fall-back. All three are >> >> >> pre-configured >> >> >> >> to the middlebox. The primary, or in duty, SIP server >> >> has a server >> >> >> >> crash, now the third SIP server takes over. How should the >> >> >> middlebox >> >> >> >> know that the third SIP server is the one in charge >> and not the >> >> >> >> second? The middlebox has to know something about >> the failover >> >> >> >> mechanism. Furhtermore it has to maintain to all proxies a >> >> >> connection >> >> >> >> at any time, that's polling! >> >> >> >> >> >> >> >> Martin >> >> >> >> >> >> >> >>> In addition COPS-PR could be used in the context of in path >> >> >> >>> signaling for authorization policy purposes. As some of the >> >> >> >>> Middleboxes will support both in path signaling (the NSIS WG >> >> >> >>> delivery) and the MIDCOM off path protocol COPS-PR has >> >> the best >> >> >> >>> position to be the MIDCOM protocol. Cedric -----Original >> >> >> >>> Message----- >> >> >> >>> From: Martin Stiemerling >> >> [mailto:Martin.Stiemerling@ccrle.nec.de] >> >> >> >>> Sent: 17 October 2002 10:45 >> >> >> >>> To: midcom@ietf.org >> >> >> >>> Subject: [midcom] Evaluation: COPS and session >> initialisation >> >> >> >>> >> >> >> >>> Just a poll about the working group opinion: >> >> >> >>> The MIDCOM framework and requirements say that the agent >> >> >> initiates >> >> >> >>> the session to the middlebox. But in the COPS/COPS-PR >> >> >> case the way >> >> >> >>> is vice >> >> >> >>> versa: The middlebox initiates the session to the >> agent. I see >> >> >> >>> this a as major difference in the particular >> >> >> architecture. How >> >> >> >>> does the working group feel about this. Is this just a >> >> >> minore point or a >> >> >> >>> real concern. >> >> >> >>> Martin >> >> >> >>> -- Martin Stiemerling >> >> >> >>> NEC Europe Ltd. -- Network Laboratories >> >> Stiemerling@ccrle.nec.de >> >> >> >>> IPv4: http://www.ccrle.nec.de IPv6: >> >> http://www.ipv6.ccrle.nec.de >> >> >> >>> >> >> _______________________________________________ >> >> >> >>> midcom mailing list >> >> >> >>> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Martin Stiemerling >> >> >> >> >> >> >> >> NEC Europe Ltd. -- Network Laboratories >> >> Stiemerling@ccrle.nec.de >> >> >> >> IPv4: http://www.ccrle.nec.de IPv6: >> >> http://www.ipv6.ccrle.nec.de >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> midcom mailing list >> >> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >> >> >> > >> >> >> > _______________________________________________ >> >> >> > midcom mailing list >> >> >> > midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> midcom mailing list >> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 11:08:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21045 for ; Tue, 22 Oct 2002 11:08:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MF9sF19571 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 11:09:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MF9Hv19558; Tue, 22 Oct 2002 11:09:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MF8mv19514 for ; Tue, 22 Oct 2002 11:08:48 -0400 Received: from dnsmx2pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20950 for ; Tue, 22 Oct 2002 11:06:20 -0400 (EDT) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA29947 for ; Tue, 22 Oct 2002 11:06:52 -0400 (EDT) To: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Tue, 22 Oct 2002 11:09:01 -0400 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 10/22/2002 11:06:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN shared secret requests Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Section 8.2 of draft-ietf-midcom-stun-02.txt describes how to handle shared secret requests over TLS. Is there a specific port that the STUN server is going to communicate with the client over TLS? Based on the draft, the default port for TCP and UDP connections is 3478. Binding TCP and UDP on one port is feasible, but how TLS sockets will bind? Can we bind TCP (clear text), TLS and UDP on one port? Thanks for your help in advance. Peter Thermos _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 11:40:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22663 for ; Tue, 22 Oct 2002 11:40:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MFfxJ21318 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 11:41:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MFc9v21185; Tue, 22 Oct 2002 11:38:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MFb3v20600 for ; Tue, 22 Oct 2002 11:37:03 -0400 Received: from dnsmx1rrc.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22411 for ; Tue, 22 Oct 2002 11:34:43 -0400 (EDT) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA18445 for ; Tue, 22 Oct 2002 11:36:48 -0400 (EDT) To: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Tue, 22 Oct 2002 11:38:56 -0400 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 10/22/2002 11:36:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN-obtaining a Shared Secret- Verbiage Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Section 9.2 page 16 of draft-ietf-midcom-stun-02.txt paragraph 2, states "The client MUST authorize the server". Authorization is associated with privileges and ability to perform a specific task based on your access profile. I do not see why the STUN client should be required to "authorize" any server responses. I believe the author(s) in this case mean "Authenticate" or "Verify" the server's response. So the sentence should read, "The client MUST authenticate the server." If I miss something please let me know. Peter T. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 12:23:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24799 for ; Tue, 22 Oct 2002 12:23:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MGPLf23988 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 12:25:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MGLKv23856; Tue, 22 Oct 2002 12:21:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MGKKv23827 for ; Tue, 22 Oct 2002 12:20:20 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24585 for ; Tue, 22 Oct 2002 12:17:58 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9MGKDY88341; Tue, 22 Oct 2002 18:20:13 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BF6CF14AE6; Tue, 22 Oct 2002 18:20:12 +0200 (CEST) Message-ID: <3DB57C9B.4050205@ccrle.nec.de> Date: Tue, 22 Oct 2002 18:28:11 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" Cc: midcom@ietf.org Subject: Re: [midcom] STUN shared secret requests References: 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Panayiotis A. Thermos wrote: > Section 8.2 of draft-ietf-midcom-stun-02.txt describes how to handle > shared secret requests over TLS. > Is there a specific port that the STUN server is going to communicate > with the client over TLS? > > Based on the draft, the default port for TCP and UDP > connections is 3478. Binding TCP and UDP on one port > is feasible, but how TLS sockets will bind? > > Can we bind TCP (clear text), TLS and UDP on one port? TLS/SSL runs over TCP. So if you use a TCP socket, you open first the TCP socket and afterwards run TLS/SSL over/through it, i.e. no need to bind TLS to a socket. Martin > > Thanks for your help in advance. > > Peter Thermos > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 12:28:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24943 for ; Tue, 22 Oct 2002 12:28:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MGUUQ24123 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 12:30:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MGQ8v24033; Tue, 22 Oct 2002 12:26:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MGPZv24005 for ; Tue, 22 Oct 2002 12:25:35 -0400 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24777 for ; Tue, 22 Oct 2002 12:23:13 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MGPLH09845; Tue, 22 Oct 2002 12:25:21 -0400 (EDT) Received: from zbl6c002.us.nortel.com ([132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TWX0LPYR; Tue, 22 Oct 2002 12:25:21 -0400 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TSNC88A5; Tue, 22 Oct 2002 12:25:19 -0400 Message-Id: <5.0.0.25.0.20021022121528.042286f0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 22 Oct 2002 12:22:34 -0400 To: Juergen Quittek From: Kwok Ho Chan Subject: RE: [midcom] Evaluation: COPS and session initialisation Cc: "Tom-PT Taylor" , "Kwok-Ho Chan" , Martin Stiemerling , "Cedric Aoun" , "'midcom@ietf.org'" In-Reply-To: <23587747.1035301869@[192.168.102.164]> References: <4D79C746863DD51197690002A52CDA000400DDFC@zcard0kc.ca.nortel.com> <4D79C746863DD51197690002A52CDA000400DDFC@zcard0kc.ca.nortel.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Juergen, All: We are not talking about unconventional usage of COPS or COPS-PR. I am not indicating any change to the current COPS and COPS-PR RFCs. I am organizing the points made in other E-Mails on this thread and try to provide some more clarafication. Thanks! -- Kwok -- At 03:51 PM 10/22/02 +0200, Juergen Quittek wrote: >Kwok, > >Has this unconventional usage of COPS-PR already been discussed earier >in the COPS-PR community? Or was the idea developed just for meeting >the midcom requirements? > > Juergen > > >-- Tom-PT Taylor wrote on 22 October 2002 08:51 -0400: > >>I think the proposal is that the agent be the one to initiate the session, >>as per the requirements, even if it contradicts the COPS-PR design >>philosophy. The confusion arises because, as I read Kwok-Ho's note, the >>first half says this is possible but then the second half goes on to discuss >>the arrangement you have been expressing concerns about. > > >>>-----Original Message----- >>>From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>Sent: Tuesday, October 22, 2002 3:39 AM >>>To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho >>>[BL60:470:EXCH]; Martin Stiemerling >>>Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>>Subject: RE: [midcom] Evaluation: COPS and session initialisation >>> >>> >>>Tom, >>> >>>-- Tom-PT Taylor wrote on 21 October 2002 18:21 -0400: >>> > I think we are agreed on the basic requirement: establishment and >>> > takedown of MIDCOM sessions must not require manual intervention or >>> > maintenance outage of the equipment. There is the policy aspect of >>> > MIDCOM session and failover management as described in the >>>framework, >>> > but I don't think that is what we are discussing here. >>> >>>The point I could not understand so far, is how to meet this >>>requirement (without additional support from additional >>>protocols) when the middlebox (and not the agent) is the >>>party that requests opening a midcom session. >>> >>> Juergen >>> >>> >>> >> -----Original Message----- >>> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>> >> Sent: Monday, October 21, 2002 6:04 PM >>> >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH]; >>> >> Martin Stiemerling >>> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>> >> Subject: RE: [midcom] Evaluation: COPS and session initialisation >>> >> >>> >> >>> >> Tom, >>> >> >>> >> I'm not sure how "administration" is exactly defined, but >>> >> if you don't provide some additional non-midcom support >>> >> for automatically configuring the midbox with the list of >>>agents to >>> >> establish connections to, then the administrator might need to >>> >> configure the the middlebox manually. >>> >> >>> >> This becomes extramely entertaining, if you disable a >>>service, let's >>> >> say IP telephony for asome hours for maintenance. How would after >>> >> maintenence hours the middlebox learn that the agent is up >>>again and >>> >> that a new session should be established. I hope not by manual >>> >> interaction between middlebox and administrator. >>> >> >>> >> Juergen >>> >> >>> >> >>> >> -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: >>> >> >>> >> > "Configuration" is just a word. If you said >>> >> "administration" I would >>> >> > be more worried, because that implies cost. >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>> >> >> Sent: Monday, October 21, 2002 4:27 PM >>> >> >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling >>> >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>> >> >> Subject: Re: [midcom] Evaluation: COPS and session >>>initialisation >>> >> >> >>> >> >> >>> >> >> Kwok, >>> >> >> >>> >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: >>> >> >> >>> >> >> > Martin, All: >>> >> >> > I will try to answer your question. As we have already >>> >> >> identified in the protocol evaluation document, >>> >> >> > "COPS does not meet the directionality part of the >>> >> >> requirement. The definition of COPS >>> >> >> > allows a PEP (Middlebox) to establish communication >>> >> with a PDP >>> >> >> > (MIDCOM Agent)." But, we added the following explanations: >>> >> >> > "However, nothing explicitly prohibits a PDP from >>> >> >> establishing communication with a >>> >> >> > PEP. The PEP could have local policies dictating what >>> >> >> action to take when it is >>> >> >> > contacted by an unknown PDP. These actions, defined in >>> >> >> the local policies, would >>> >> >> > ensure the proper establishment of an authorized >>> >> association. " >>> >> >> >>> >> >> Yes, I think this is exactly the point. You can create a >>> >> framework, >>> >> >> for example using policies, for initiating the >>>association between >>> >> >> middlebox and agent. You also can use a new Midcom Session >>> >> Initiation >>> >> >> Protocol to be used by the agent for telling the >>> >> middlebox: "Please >>> >> >> contact me for establishing a midcom session". >>> >> >> >>> >> >> The question is, whether this would be a good choice >>>considering >>> >> >> operational issues. I see service installation, >>>modification and >>> >> >> removal to be much more dynamic than middlebox installation, >>> >> >> modification and removal. Therefore, I consider it an >>>operational >>> >> >> disadvantage having to configure the middlebox each time a >>> >> service is >>> >> >> installed, is modified (changes the failover sequence), or is >>> >> >> removed. >>> >> >> >>> >> >> Juergen >>> >> >> >>> >> >> >>> >> >> > Once the COPS connection is open, it is perfectly within >>> >> the COPS >>> >> >> > protocol for the PDP to send unsolicited decisions to >>> >> the PEP (for >>> >> >> > example the midcom agent sending an open pinhole >>>decision to the >>> >> >> > middlebox. >>> >> >> > >>> >> >> > Also to address the fail over points you made below. The PEP >>> >> >> > (Middlebox) can have local policy indicating the >>> >> order by >>> >> >> > which it will contact the PDPs (MIDCOM Agents). This local >>> >> >> policy can >>> >> >> > actually be installed by the primary SIP server (in the >>> >> example you >>> >> >> > gave), indicating if communication is lost between it (the >>> >> >> primary SIP >>> >> >> > server) and the Middlebox, the Middlebox MUST contact >>> >> the THIRD SIP >>> >> >> > server as the highest priority back-up SIP server, then the >>> >> >> SECOND SIP >>> >> >> > server if the both the PRIMARY/FIRST SIP server and the >>> >> THIRD SIP >>> >> >> > server is not available to provide the required services. >>> >> >> Notice the >>> >> >> > fail over is totally deterministic and also controlled >>> >> by Policy of >>> >> >> > the controlling domain. >>> >> >> > >>> >> >> > Also only a single connection between a Middlebox and a >>> >> >> MIDCOM Agent >>> >> >> > is maintain at any given time, the one that is being used. >>> >> >> > >>> >> >> > Also lets say the PRIMARY SIP server >>>degrades/dies/off-load its >>> >> >> > service gracefully (you can also view this as part of load >>> >> >> balancing >>> >> >> > between multiple SIP servers), the PRIMARY SIP server can >>> >> >> REDIRECT the >>> >> >> > Middlebox to get its service from a specific other SIP >>> >> >> server, in the >>> >> >> > example you gave below, this should be the THIRD SIP >>> >> >> server. This is >>> >> >> > done without any interruption to the functionality the >>> >> Middlebox is >>> >> >> > providing. >>> >> >> > >>> >> >> > This is how COPS is intent to be used without any >>> >> >> modification to the >>> >> >> > current RFCs. >>> >> >> > >>> >> >> > With the above, one may take a step back and think: >>> >> >> > "Is the directional requirement really 'required' ?? Or >>> >> is it the >>> >> >> > FUNCTIONALITY that is really 'required' ??" >>> >> >> > >>> >> >> > I have shown how COPS satisfy the fail over and high >>> >> availability >>> >> >> > FUNCTIONALITIES without talking about the directional >>> >> >> > 'requirement'. >>> >> >> > >>> >> >> > Hope I have clarify some of the points raised. >>> >> >> > >>> >> >> > -- Kwok Ho Chan -- >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >>> >> >> >>> I think we discussed several times the "session" on >>> >> the mailing >>> >> >> >>> list. We never closed this on the list, I'm still >>> >> hoping we could >>> >> >> >>> close this at some point. What do we mean by session? >>> >> There is a >>> >> >> >>> relation between the Middlebox and the Midcom >>> >> >> agent, this >>> >> >> >>> relation consists of: >>> >> >> >>> -Establishing trust and authorization levels >>>-Establishing a >>> >> >> >>> security association -This relation could have a real >>> >> identifier >>> >> >> >>> or a pseudo >>> >> >> one based on the >>> >> >> >>> Midcom agent or Middlebox identity; this could be used >>> >> >> for hand-overs or >>> >> >> >>> for softstate cleaning in case the Midcom agent goes down. >>> >> >> >> >>> >> >> >> Agreed. >>> >> >> >> >>> >> >> >>> This relation doesn't really need to have a >>>direction for its >>> >> >> >>> establishment, I suggest that we take it out of the >>> >> >> directionality >>> >> >> >>> of the relation from the requirements document. >>> >> >> >> >>> >> >> >> The relationsship is from the framework document, section >>> >> >> 4. "MIDCOM >>> >> >> >> protocol": "MIDCOM shall be a client-server protocol, >>> >> initiated by >>> >> >> >> the agent." Section 6.2. "Registration and deregistration >>> >> >> of MIDCOM >>> >> >> >> agents" says: "MIDCOM agent profile may be >>>pre-configured on a >>> >> >> >> middlebox. Subsequent to that, the agent may choose to >>> >> initiate a >>> >> >> >> MIDCOM session prior to any data traffic." >>> >> >> >> >>> >> >> >> I always read "initiated" by the agent, that implies for >>> >> >> me the agent >>> >> >> >> starts the communication with the middlebox. We are >>> >> definitely too >>> >> >> >> late for deleting this directional component, because >>> >> it is in our >>> >> >> >> framework RFC. >>> >> >> >> >>> >> >> >> Another point for not initiating the communication by the >>> >> >> middlebox, >>> >> >> >> the above mentioned hand-off between agents. Imaging you >>> >> >> have three >>> >> >> >> SIP proxies, two of them as a fall-back. All three are >>> >> >> pre-configured >>> >> >> >> to the middlebox. The primary, or in duty, SIP server >>> >> has a server >>> >> >> >> crash, now the third SIP server takes over. How should the >>> >> >> middlebox >>> >> >> >> know that the third SIP server is the one in charge >>>and not the >>> >> >> >> second? The middlebox has to know something about >>>the failover >>> >> >> >> mechanism. Furhtermore it has to maintain to all proxies a >>> >> >> connection >>> >> >> >> at any time, that's polling! >>> >> >> >> >>> >> >> >> Martin >>> >> >> >> >>> >> >> >>> In addition COPS-PR could be used in the context of in path >>> >> >> >>> signaling for authorization policy purposes. As some of the >>> >> >> >>> Middleboxes will support both in path signaling (the NSIS WG >>> >> >> >>> delivery) and the MIDCOM off path protocol COPS-PR has >>> >> the best >>> >> >> >>> position to be the MIDCOM protocol. Cedric -----Original >>> >> >> >>> Message----- >>> >> >> >>> From: Martin Stiemerling >>> >> [mailto:Martin.Stiemerling@ccrle.nec.de] >>> >> >> >>> Sent: 17 October 2002 10:45 >>> >> >> >>> To: midcom@ietf.org >>> >> >> >>> Subject: [midcom] Evaluation: COPS and session >>>initialisation >>> >> >> >>> >>> >> >> >>> Just a poll about the working group opinion: >>> >> >> >>> The MIDCOM framework and requirements say that the agent >>> >> >> initiates >>> >> >> >>> the session to the middlebox. But in the COPS/COPS-PR >>> >> >> case the way >>> >> >> >>> is vice >>> >> >> >>> versa: The middlebox initiates the session to the >>>agent. I see >>> >> >> >>> this a as major difference in the particular >>> >> >> architecture. How >>> >> >> >>> does the working group feel about this. Is this just a >>> >> >> minore point or a >>> >> >> >>> real concern. >>> >> >> >>> Martin >>> >> >> >>> -- Martin Stiemerling >>> >> >> >>> NEC Europe Ltd. -- Network Laboratories >>> >> Stiemerling@ccrle.nec.de >>> >> >> >>> IPv4: http://www.ccrle.nec.de IPv6: >>> >> http://www.ipv6.ccrle.nec.de >>> >> >> >>> >>> >> _______________________________________________ >>> >> >> >>> midcom mailing list >>> >> >> >>> midcom@ietf.org >>>https://www1.ietf.org/mailman/listinfo/midcom >>> >> >> >> >>> >> >> >>> >> >>> >> >> >> >>> >> >> >> -- >>> >> >> >> Martin Stiemerling >>> >> >> >> >>> >> >> >> NEC Europe Ltd. -- Network Laboratories >>> >> Stiemerling@ccrle.nec.de >>> >> >> >> IPv4: http://www.ccrle.nec.de IPv6: >>> >> http://www.ipv6.ccrle.nec.de >>> >> >> >> >>> >> >> >> >>> >> _______________________________________________ >>> >> >> >> midcom mailing list >>> >> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>> >> >> > >>> >> >> > _______________________________________________ >>> >> >> > midcom mailing list >>> >> >> > midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>> >> >> >>> >> >> >>> >> >> _______________________________________________ >>> >> >> midcom mailing list >>> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>> >> >> >>> >> >>> >> >>> >> >>> >>> > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 22 14:10:19 2002 Received: from www1.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 ; Tue, 22 Oct 2002 14:10:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MIC8N29611 for midcom-archive@odin.ietf.org; Tue, 22 Oct 2002 14:12:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MIBFv29585; Tue, 22 Oct 2002 14:11:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MIAPv29555 for ; Tue, 22 Oct 2002 14:10:25 -0400 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28659 for ; Tue, 22 Oct 2002 14:08:03 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MIA5H28881; Tue, 22 Oct 2002 14:10:05 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 14:10:05 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DE08@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" Cc: midcom@ietf.org Date: Tue, 22 Oct 2002 14:10:05 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Sorry Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , A belated apology for speaking up as I did. Looks like you had good reasons for your call. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, October 18, 2002 4:27 PM > To: Taylor, Tom-PT [CAR:B602:EXCH] > Cc: Stukas, Michael T (Mike); midcom@ietf.org; Sollee, > Patrick [NGC:B601:EXCH]; March, Sean [NGC:B672:EXCH] > Subject: Re: [midcom] Assigning media ports with > Midcom-unaware NAT/Firewa ll Traversal > > > > How ungenerous of you! I don't think I've ever seen quite > that level > > of restriction on a list before. > > Tom, > > The solution outlined in that draft, as well as the solution > outlined in the Davies draft, were considered, discussed, and > rejected in favor of STUN. Furthermore, this was a request > to re-open that discussion in order to support a school > project, not to support IETF work. I'm sorry you found it > harsh and I apologize for the tone, but the discussion itself > really does not belong on the midcom mailing list. > > Melinda > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 23 01:18:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15543 for ; Wed, 23 Oct 2002 01:18:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9N5KlV29355 for midcom-archive@odin.ietf.org; Wed, 23 Oct 2002 01:20:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N5GZv29236; Wed, 23 Oct 2002 01:16:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N5FLv29216 for ; Wed, 23 Oct 2002 01:15:21 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15513 for ; Wed, 23 Oct 2002 01:12:54 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9N5F8cn009003; Tue, 22 Oct 2002 22:15:09 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id AAM24087; Tue, 22 Oct 2002 22:15:35 -0700 (PDT) From: "Cullen Jennings" To: "Melinda Shore" , Subject: RE: [midcom] SPAN status Date: Tue, 22 Oct 2002 22:15:42 -0700 Message-ID: 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 V6.00.2600.0000 In-Reply-To: <200210142333.AAF27922@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, I'm confused on the question of what we are deleting. Are we deleting SPAN which was to my understanding the name of an output of a design team which has somewhat died? Or are we deleting tying to find a pre-midcom relay based solution for the cases where STUN will not work? I had though you meant the earlier but realized now that you might mean the later. Thanks, Cullen > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Monday, October 14, 2002 4:38 PM > To: midcom@ietf.org > Subject: [midcom] SPAN status > > > Since I sent out the query last week the only person who's > piped up in favor of continuing the work was Pete. In the > face of this level of ennui I'm afraid we're going to have > to delete the work item. > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 23 14:40:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29265 for ; Wed, 23 Oct 2002 14:40:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9NIgDK16881 for midcom-archive@odin.ietf.org; Wed, 23 Oct 2002 14:42:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NIfYv16852; Wed, 23 Oct 2002 14:41:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NIeIv16751 for ; Wed, 23 Oct 2002 14:40:18 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29155 for ; Wed, 23 Oct 2002 14:37:56 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NIe9cl002020; Wed, 23 Oct 2002 11:40:09 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI11817; Wed, 23 Oct 2002 11:35:20 -0700 (PDT) Message-Id: <200210231835.AAI11817@mira-sjc5-4.cisco.com> To: "Cullen Jennings" cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] SPAN status In-Reply-To: Message from "Cullen Jennings" of "Tue, 22 Oct 2002 22:15:42 PDT." Date: Wed, 23 Oct 2002 14:40:10 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Are we deleting SPAN which was to my understanding the name of an output of > a design team which has somewhat died? Or are we deleting tying to find a > pre-midcom relay based solution for the cases where STUN will not work? The latter. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 24 17:32:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24442 for ; Thu, 24 Oct 2002 17:32:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OLYlb12868 for midcom-archive@odin.ietf.org; Thu, 24 Oct 2002 17:34:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OLXfv12839; Thu, 24 Oct 2002 17:33:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OLWpv12807 for ; Thu, 24 Oct 2002 17:32:51 -0400 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24385 for ; Thu, 24 Oct 2002 17:30:25 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9OLWYl21768; Thu, 24 Oct 2002 17:32:34 -0400 (EDT) Received: from zbl6c002.us.nortel.com ([132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TWX0MCR5; Thu, 24 Oct 2002 17:32:33 -0400 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TSNC9ANY; Thu, 24 Oct 2002 17:32:32 -0400 Message-Id: <5.0.0.25.0.20021024152138.03024ae0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 24 Oct 2002 17:29:21 -0400 To: Kwok Ho Chan From: Kwok Ho Chan Subject: RE: [midcom] Evaluation: COPS and session initialisation Cc: Juergen Quittek , "Tom-PT Taylor" , "Kwok-Ho Chan" , Martin Stiemerling , "Cedric Aoun" , "'midcom@ietf.org'" In-Reply-To: <5.0.0.25.0.20021022121528.042286f0@zbl6c002.corpeast.bayne tworks.com> References: <23587747.1035301869@[192.168.102.164]> <4D79C746863DD51197690002A52CDA000400DDFC@zcard0kc.ca.nortel.com> <4D79C746863DD51197690002A52CDA000400DDFC@zcard0kc.ca.nortel.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Juergen, Martin, all: Based on the previous E-Mail messages on this thread, I have summarized the concerns into the following points: 1. (Re-)Configuring the Middlebox everytime a dynamic (service) change occurs. With the assumption that for every (re-)configuration, the communication between the MIDCOM Agent and Middlebox needs to be establish anew. 2. It is the MIDCOM Agent that knows when service/resource/assistance is needed of the Middlebox. In another word, it is the MIDCOM Agent that receives the trigger/event indicating service requirement. Because of this, how can the architecture of having Middlebox (PEP) contacting MIDCOM (PDP) works? And these two concerns contributes to the directional requirements of MIDCOM. Let me try to explain by laying out the operational scenario when COPS is used. (in this E-Mail you can replace COPS with COPS-PR if you like) 1. Middlebox boots up, knowing it needs to establish communication with a MIDCOM Agent, at this time a default MIDCOM Agent. It uses a default MIDCOM Agent address for a specific domain or uses some kind of service lookup capability (think of "MIDCOM_Agent" translate to a specific address). This will allow a Middlebox initiated TCP connection to be established. 2. The MIDCOM Agent the Middlebox contacted can be the correct MIDCOM Agent and it will accept the TCP connection request. Or it may not be the correct MIDCOM Agent, at which it will "redirect" the Middlebox to contact the correct MIDCOM Agent. This can be used for load balancing between multiple MIDCOM Agents as I have indicated in earlier E-Mail. Notice the established TCP connection between the Middlebox and MIDCOM Agent is a long-lived TCP connection, to be used for all subsequent communication, static or dynamic. COPS use one and only one TCP connection between the Middlebox and the MIDCOM Agent, established only once. The COPS connection is establish over this TCP connection, with Middlebox sending its capability to the MIDCOM Agent. You can view this capability notification as a registration of Middlebox to the MIDCOM Agent indicating "I am here and I can provide these services/resources, let me know what I can do to help when necessary." 3. When the MIDCOM Agent detected a trigger/event indicating it need some services/resources from some Middlebox, it will have a list of services/resources on specific Middleboxes that the specific MIDCOM Agent have at its disposal. The MIDCOM Agent at this time communicate to the Middlebox over the already established TCP and COPS connection to allocate the Middlebox's services/resources as necessary. You can view this as configuration/re-configuration/provisioning. I view this as what it is functionally doing: allocating resource/service when and where it is needed. The notion of static/dynamic is relative, and the mechanism here is more effective, efficient the more dynamic the interaction becomes. Hence this addresses the dynamic-ness concern from the E-Mail thread. Notice the communication between the MIDCOM Agent and Middlebox is transactional and state-full. So any transactional success/failure/ resource_used is known immediately, no polling required. This provides efficient resource usage across the administrative domain (think about load balancing across multiple Middleboxes). 4. For operating a network, there should be "policies" on what is the correct action to take when parts of the network experience outage, problem, etc. There should also be "policies" on when and how maintenance is done. These "policies" can be carried out by human or be automated. The choose is up to the owner of the network. When COPS is used, these "policies" can be pre-installed at the MIDCOM Agent and/or Middlebox prior to the actual outage/problem/maintenance event occurs. For example, after the Middlebox established the communication with the MIDCOM Agent, the MIDCOM Agent can indicate the administrative domain's "policies" if the Middlebox loose communication with the MIDCOM Agent (these "policies" may indicate the Middlebox should contact a list of back-up MIDCOM Agents in a specific prioritized order). There can also be "policies" for partial or full failure of the Middlebox. For the MIDCOM Agent maintenance issue in the E-Mail thread, there can be "policies" on when the Middlebox should try to contact the MIDCOM Agent again with a specific frequency, indicated to the Middlebox by the MIDCOM Agent before the MIDCOM Agent goes into maintenance mode. But I would much prefer to use a graceful method of redirecting the Middlebox to back-up MIDCOM Agents during the primary MIDCOM Agent maintenance period and have the back-up MIDCOM Agent redirect the Middlebox back to the primary MIDCOM Agent when necessary. Notice this is all deterministic and under control. 5. When the Middlebox needs to be shut-down (or it fails), the MIDCOM Agent knows immediately (within the limit of keep-alive messages), no polling is needed to see if the services/resources provided by a Middlebox is available to the MIDCOM Agent. With the above explanation, I have indicated that there are two levels of interaction: 1. Communication Establishment. For COPS, it is initiated by the Middlebox. 2. MIDCOM Functional Event Flow. For both MIDCOM and COPS, it is from MIDCOM Agent to Middlebox. IMHO, I believe the MIDCOM Requirement cares about the "MIDCOM Functional Event Flow" direction, NOT the "Communication Establishment" direction. Hence COPS meet this requirement fully with the above explanation. Please provide the need to have the "Communication Establishment" directional requirement reasoning if you think otherwise. I hope I have resolved the concerns indicated by this E-Mail thread, and please let me know if I haven't. Thank you! -- Kwok -- At 12:22 PM 10/22/02 -0400, Kwok Ho Chan wrote: >Juergen, All: >We are not talking about unconventional usage of COPS or COPS-PR. >I am not indicating any change to the current COPS and COPS-PR RFCs. > >I am organizing the points made in other E-Mails on this thread and try to >provide some more clarafication. >Thanks! >-- Kwok -- > > >At 03:51 PM 10/22/02 +0200, Juergen Quittek wrote: >>Kwok, >> >>Has this unconventional usage of COPS-PR already been discussed earier >>in the COPS-PR community? Or was the idea developed just for meeting >>the midcom requirements? >> >> Juergen >> >> >>-- Tom-PT Taylor wrote on 22 October 2002 08:51 -0400: >> >>>I think the proposal is that the agent be the one to initiate the session, >>>as per the requirements, even if it contradicts the COPS-PR design >>>philosophy. The confusion arises because, as I read Kwok-Ho's note, the >>>first half says this is possible but then the second half goes on to discuss >>>the arrangement you have been expressing concerns about. >> >> >>>>-----Original Message----- >>>>From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>>Sent: Tuesday, October 22, 2002 3:39 AM >>>>To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho >>>>[BL60:470:EXCH]; Martin Stiemerling >>>>Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>>>Subject: RE: [midcom] Evaluation: COPS and session initialisation >>>> >>>> >>>>Tom, >>>> >>>>-- Tom-PT Taylor wrote on 21 October 2002 18:21 -0400: >>>> > I think we are agreed on the basic requirement: establishment and >>>> > takedown of MIDCOM sessions must not require manual intervention or >>>> > maintenance outage of the equipment. There is the policy aspect of >>>> > MIDCOM session and failover management as described in the >>>>framework, >>>> > but I don't think that is what we are discussing here. >>>> >>>>The point I could not understand so far, is how to meet this >>>>requirement (without additional support from additional >>>>protocols) when the middlebox (and not the agent) is the >>>>party that requests opening a midcom session. >>>> >>>> Juergen >>>> >>>> >>>> >> -----Original Message----- >>>> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>> >> Sent: Monday, October 21, 2002 6:04 PM >>>> >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH]; >>>> >> Martin Stiemerling >>>> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>>> >> Subject: RE: [midcom] Evaluation: COPS and session initialisation >>>> >> >>>> >> >>>> >> Tom, >>>> >> >>>> >> I'm not sure how "administration" is exactly defined, but >>>> >> if you don't provide some additional non-midcom support >>>> >> for automatically configuring the midbox with the list of >>>>agents to >>>> >> establish connections to, then the administrator might need to >>>> >> configure the the middlebox manually. >>>> >> >>>> >> This becomes extramely entertaining, if you disable a >>>>service, let's >>>> >> say IP telephony for asome hours for maintenance. How would after >>>> >> maintenence hours the middlebox learn that the agent is up >>>>again and >>>> >> that a new session should be established. I hope not by manual >>>> >> interaction between middlebox and administrator. >>>> >> >>>> >> Juergen >>>> >> >>>> >> >>>> >> -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: >>>> >> >>>> >> > "Configuration" is just a word. If you said >>>> >> "administration" I would >>>> >> > be more worried, because that implies cost. >>>> >> > >>>> >> >> -----Original Message----- >>>> >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>> >> >> Sent: Monday, October 21, 2002 4:27 PM >>>> >> >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling >>>> >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>>> >> >> Subject: Re: [midcom] Evaluation: COPS and session >>>>initialisation >>>> >> >> >>>> >> >> >>>> >> >> Kwok, >>>> >> >> >>>> >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: >>>> >> >> >>>> >> >> > Martin, All: >>>> >> >> > I will try to answer your question. As we have already >>>> >> >> identified in the protocol evaluation document, >>>> >> >> > "COPS does not meet the directionality part of the >>>> >> >> requirement. The definition of COPS >>>> >> >> > allows a PEP (Middlebox) to establish communication >>>> >> with a PDP >>>> >> >> > (MIDCOM Agent)." But, we added the following explanations: >>>> >> >> > "However, nothing explicitly prohibits a PDP from >>>> >> >> establishing communication with a >>>> >> >> > PEP. The PEP could have local policies dictating what >>>> >> >> action to take when it is >>>> >> >> > contacted by an unknown PDP. These actions, defined in >>>> >> >> the local policies, would >>>> >> >> > ensure the proper establishment of an authorized >>>> >> association. " >>>> >> >> >>>> >> >> Yes, I think this is exactly the point. You can create a >>>> >> framework, >>>> >> >> for example using policies, for initiating the >>>>association between >>>> >> >> middlebox and agent. You also can use a new Midcom Session >>>> >> Initiation >>>> >> >> Protocol to be used by the agent for telling the >>>> >> middlebox: "Please >>>> >> >> contact me for establishing a midcom session". >>>> >> >> >>>> >> >> The question is, whether this would be a good choice >>>>considering >>>> >> >> operational issues. I see service installation, >>>>modification and >>>> >> >> removal to be much more dynamic than middlebox installation, >>>> >> >> modification and removal. Therefore, I consider it an >>>>operational >>>> >> >> disadvantage having to configure the middlebox each time a >>>> >> service is >>>> >> >> installed, is modified (changes the failover sequence), or is >>>> >> >> removed. >>>> >> >> >>>> >> >> Juergen >>>> >> >> >>>> >> >> >>>> >> >> > Once the COPS connection is open, it is perfectly within >>>> >> the COPS >>>> >> >> > protocol for the PDP to send unsolicited decisions to >>>> >> the PEP (for >>>> >> >> > example the midcom agent sending an open pinhole >>>>decision to the >>>> >> >> > middlebox. >>>> >> >> > >>>> >> >> > Also to address the fail over points you made below. The PEP >>>> >> >> > (Middlebox) can have local policy indicating the >>>> >> order by >>>> >> >> > which it will contact the PDPs (MIDCOM Agents). This local >>>> >> >> policy can >>>> >> >> > actually be installed by the primary SIP server (in the >>>> >> example you >>>> >> >> > gave), indicating if communication is lost between it (the >>>> >> >> primary SIP >>>> >> >> > server) and the Middlebox, the Middlebox MUST contact >>>> >> the THIRD SIP >>>> >> >> > server as the highest priority back-up SIP server, then the >>>> >> >> SECOND SIP >>>> >> >> > server if the both the PRIMARY/FIRST SIP server and the >>>> >> THIRD SIP >>>> >> >> > server is not available to provide the required services. >>>> >> >> Notice the >>>> >> >> > fail over is totally deterministic and also controlled >>>> >> by Policy of >>>> >> >> > the controlling domain. >>>> >> >> > >>>> >> >> > Also only a single connection between a Middlebox and a >>>> >> >> MIDCOM Agent >>>> >> >> > is maintain at any given time, the one that is being used. >>>> >> >> > >>>> >> >> > Also lets say the PRIMARY SIP server >>>>degrades/dies/off-load its >>>> >> >> > service gracefully (you can also view this as part of load >>>> >> >> balancing >>>> >> >> > between multiple SIP servers), the PRIMARY SIP server can >>>> >> >> REDIRECT the >>>> >> >> > Middlebox to get its service from a specific other SIP >>>> >> >> server, in the >>>> >> >> > example you gave below, this should be the THIRD SIP >>>> >> >> server. This is >>>> >> >> > done without any interruption to the functionality the >>>> >> Middlebox is >>>> >> >> > providing. >>>> >> >> > >>>> >> >> > This is how COPS is intent to be used without any >>>> >> >> modification to the >>>> >> >> > current RFCs. >>>> >> >> > >>>> >> >> > With the above, one may take a step back and think: >>>> >> >> > "Is the directional requirement really 'required' ?? Or >>>> >> is it the >>>> >> >> > FUNCTIONALITY that is really 'required' ??" >>>> >> >> > >>>> >> >> > I have shown how COPS satisfy the fail over and high >>>> >> availability >>>> >> >> > FUNCTIONALITIES without talking about the directional >>>> >> >> > 'requirement'. >>>> >> >> > >>>> >> >> > Hope I have clarify some of the points raised. >>>> >> >> > >>>> >> >> > -- Kwok Ho Chan -- >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >>>> >> >> >>> I think we discussed several times the "session" on >>>> >> the mailing >>>> >> >> >>> list. We never closed this on the list, I'm still >>>> >> hoping we could >>>> >> >> >>> close this at some point. What do we mean by session? >>>> >> There is a >>>> >> >> >>> relation between the Middlebox and the Midcom >>>> >> >> agent, this >>>> >> >> >>> relation consists of: >>>> >> >> >>> -Establishing trust and authorization levels >>>>-Establishing a >>>> >> >> >>> security association -This relation could have a real >>>> >> identifier >>>> >> >> >>> or a pseudo >>>> >> >> one based on the >>>> >> >> >>> Midcom agent or Middlebox identity; this could be used >>>> >> >> for hand-overs or >>>> >> >> >>> for softstate cleaning in case the Midcom agent goes down. >>>> >> >> >> >>>> >> >> >> Agreed. >>>> >> >> >> >>>> >> >> >>> This relation doesn't really need to have a >>>>direction for its >>>> >> >> >>> establishment, I suggest that we take it out of the >>>> >> >> directionality >>>> >> >> >>> of the relation from the requirements document. >>>> >> >> >> >>>> >> >> >> The relationsship is from the framework document, section >>>> >> >> 4. "MIDCOM >>>> >> >> >> protocol": "MIDCOM shall be a client-server protocol, >>>> >> initiated by >>>> >> >> >> the agent." Section 6.2. "Registration and deregistration >>>> >> >> of MIDCOM >>>> >> >> >> agents" says: "MIDCOM agent profile may be >>>>pre-configured on a >>>> >> >> >> middlebox. Subsequent to that, the agent may choose to >>>> >> initiate a >>>> >> >> >> MIDCOM session prior to any data traffic." >>>> >> >> >> >>>> >> >> >> I always read "initiated" by the agent, that implies for >>>> >> >> me the agent >>>> >> >> >> starts the communication with the middlebox. We are >>>> >> definitely too >>>> >> >> >> late for deleting this directional component, because >>>> >> it is in our >>>> >> >> >> framework RFC. >>>> >> >> >> >>>> >> >> >> Another point for not initiating the communication by the >>>> >> >> middlebox, >>>> >> >> >> the above mentioned hand-off between agents. Imaging you >>>> >> >> have three >>>> >> >> >> SIP proxies, two of them as a fall-back. All three are >>>> >> >> pre-configured >>>> >> >> >> to the middlebox. The primary, or in duty, SIP server >>>> >> has a server >>>> >> >> >> crash, now the third SIP server takes over. How should the >>>> >> >> middlebox >>>> >> >> >> know that the third SIP server is the one in charge >>>>and not the >>>> >> >> >> second? The middlebox has to know something about >>>>the failover >>>> >> >> >> mechanism. Furhtermore it has to maintain to all proxies a >>>> >> >> connection >>>> >> >> >> at any time, that's polling! >>>> >> >> >> >>>> >> >> >> Martin >>>> >> >> >> >>>> >> >> >>> In addition COPS-PR could be used in the context of in path >>>> >> >> >>> signaling for authorization policy purposes. As some of the >>>> >> >> >>> Middleboxes will support both in path signaling (the NSIS WG >>>> >> >> >>> delivery) and the MIDCOM off path protocol COPS-PR has >>>> >> the best >>>> >> >> >>> position to be the MIDCOM protocol. Cedric -----Original >>>> >> >> >>> Message----- >>>> >> >> >>> From: Martin Stiemerling >>>> >> [mailto:Martin.Stiemerling@ccrle.nec.de] >>>> >> >> >>> Sent: 17 October 2002 10:45 >>>> >> >> >>> To: midcom@ietf.org >>>> >> >> >>> Subject: [midcom] Evaluation: COPS and session >>>>initialisation >>>> >> >> >>> >>>> >> >> >>> Just a poll about the working group opinion: >>>> >> >> >>> The MIDCOM framework and requirements say that the agent >>>> >> >> initiates >>>> >> >> >>> the session to the middlebox. But in the COPS/COPS-PR >>>> >> >> case the way >>>> >> >> >>> is vice >>>> >> >> >>> versa: The middlebox initiates the session to the >>>>agent. I see >>>> >> >> >>> this a as major difference in the particular >>>> >> >> architecture. How >>>> >> >> >>> does the working group feel about this. Is this just a >>>> >> >> minore point or a >>>> >> >> >>> real concern. >>>> >> >> >>> Martin >>>> >> >> >>> -- Martin Stiemerling >>>> >> >> >>> NEC Europe Ltd. -- Network Laboratories >>>> >> Stiemerling@ccrle.nec.de >>>> >> >> >>> IPv4: http://www.ccrle.nec.de IPv6: >>>> >> http://www.ipv6.ccrle.nec.de >>>> >> >> >>> >>>> >> _______________________________________________ >>>> >> >> >>> midcom mailing list >>>> >> >> >>> midcom@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/midcom >>>> >> >> >> >>>> >> >> >>>> >> >>>> >> >> >> >>>> >> >> >> -- >>>> >> >> >> Martin Stiemerling >>>> >> >> >> >>>> >> >> >> NEC Europe Ltd. -- Network Laboratories >>>> >> Stiemerling@ccrle.nec.de >>>> >> >> >> IPv4: http://www.ccrle.nec.de IPv6: >>>> >> http://www.ipv6.ccrle.nec.de >>>> >> >> >> >>>> >> >> >> >>>> >> _______________________________________________ >>>> >> >> >> midcom mailing list >>>> >> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>>> >> >> > >>>> >> >> > _______________________________________________ >>>> >> >> > midcom mailing list >>>> >> >> > midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>>> >> >> >>>> >> >> >>>> >> >> _______________________________________________ >>>> >> >> midcom mailing list >>>> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>>> >> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Oct 25 11:18:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28042 for ; Fri, 25 Oct 2002 11:18:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PFKL410586 for midcom-archive@odin.ietf.org; Fri, 25 Oct 2002 11:20:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PFHLv10431; Fri, 25 Oct 2002 11:17:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PFGjv10400 for ; Fri, 25 Oct 2002 11:16:45 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27842 for ; Fri, 25 Oct 2002 11:14:22 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9PFGdY14537; Fri, 25 Oct 2002 17:16:39 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E6D8D703E2; Fri, 25 Oct 2002 17:16:33 +0200 (CEST) Date: Fri, 25 Oct 2002 17:16:34 +0200 From: Juergen Quittek To: Kwok Ho Chan Cc: Tom-PT Taylor , Martin Stiemerling , Cedric Aoun , "'midcom@ietf.org'" Subject: RE: [midcom] Evaluation: COPS and session initialisation Message-ID: <17430643.1035566194@[192.168.102.164]> In-Reply-To: <5.0.0.25.0.20021024152138.03024ae0@zbl6c002.corpeast.baynetworks.com> References: <5.0.0.25.0.20021024152138.03024ae0@zbl6c002.corpeast.baynetworks.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kwok, -- Kwok Ho Chan wrote on 24 October 2002 17:29 -0400: > Juergen, Martin, all: > Based on the previous E-Mail messages on this thread, I have summarized > the concerns into the following points: > > 1. (Re-)Configuring the Middlebox everytime a dynamic (service) change occurs. > With the assumption that for every (re-)configuration, the communication > between the MIDCOM Agent and Middlebox needs to be establish anew. > > 2. It is the MIDCOM Agent that knows when service/resource/assistance is > needed of the Middlebox. In another word, it is the MIDCOM Agent that > receives the trigger/event indicating service requirement. > Because of this, how can the architecture of having Middlebox (PEP) > contacting MIDCOM (PDP) works? Full agreement on both items. > And these two concerns contributes to the directional requirements of MIDCOM. > > Let me try to explain by laying out the operational scenario when COPS is used. > (in this E-Mail you can replace COPS with COPS-PR if you like) > > 1. Middlebox boots up, knowing it needs to establish communication with > a MIDCOM Agent, at this time a default MIDCOM Agent. It uses a default > MIDCOM Agent address for a specific domain or uses some kind of service > lookup capability (think of "MIDCOM_Agent" translate to a specific address). > This will allow a Middlebox initiated TCP connection to be established. I think here is the reason why we find it so hard to agree further: The NAT across which I'm sending this message had its last reboot on Thu Dec 20 14:19:26 CET 2001. Since then, several services have been installed or removed in our network, but the NAT is not something you don't want to touch regularly. It is part of the mission-critical basic infrastructure. How would your be if you start with "1. Agent boots up, waiting for a middlebox to get aware of this fact and to eastablish communication."? If you install a network, you first establish basic connectivity including NAT and firewall. At the time these machine boot up, there might be no agent avaiable or just a subset of the agents that will (at some later point in time) need to control the middlebox. Then you start installing services on top of the basic infrastructure. If you set up - say - SIP-signalled IP telephony service, it would be simple to configure the SIP server (you have to configue it anyway) to connect to the middlebox and use midcom for enabling outgoing and incoming calls. Then you might want to set up a non-SIP video conferencing service and repeat the steps you made for SIP configuration. In both cases, it appears to be a disadvantage, if you also had to re-configure the middlebox telling it the address of the new agent. > > 2. The MIDCOM Agent the Middlebox contacted can be the correct MIDCOM > Agent and it will accept the TCP connection request. Or it may not be > the correct MIDCOM Agent, at which it will "redirect" the Middlebox to Do you suggest an agent re-direct to become part of the midcom protocol? > contact the correct MIDCOM Agent. This can be used for load balancing > between multiple MIDCOM Agents as I have indicated in earlier E-Mail. > > Notice the established TCP connection between the Middlebox and MIDCOM > Agent is a long-lived TCP connection, to be used for all subsequent > communication, static or dynamic. COPS use one and only one TCP > connection between the Middlebox and the MIDCOM Agent, established > only once. So, you should not reboot the middlebox, when installing a new service that uses an additional service specific midcom agent! > The COPS connection is establish over this TCP connection, with Middlebox > sending its capability to the MIDCOM Agent. You can view this capability > notification as a registration of Middlebox to the MIDCOM Agent indicating > "I am here and I can provide these services/resources, let me know what > I can do to help when necessary." This sounds great, but it would make more sense if you multicast your service offer, like route advertisements. Then a new agent could receive this and reply: "Hey, I'm new. Please establish a TCP connection to my IP address 1.2.3.4." ;-) > 3. When the MIDCOM Agent detected a trigger/event indicating it need some > services/resources from some Middlebox, it will have a list of services/resources > on specific Middleboxes that the specific MIDCOM Agent have at its disposal. > The MIDCOM Agent at this time communicate to the Middlebox over the > already established TCP and COPS connection to allocate the Middlebox's > services/resources as necessary. This seems to be just the very basic MIDCOM usage scenario. Or are you distinguishing two different agents, the general one and the "specific" one? > You can view this as configuration/re-configuration/provisioning. I view this > as what it is functionally doing: allocating resource/service when and where > it is needed. The notion of static/dynamic is relative, and the mechanism > here is more effective, efficient the more dynamic the interaction becomes. Yes, this is exactly what the midcom protocol should be used for? > Hence this addresses the dynamic-ness concern from the E-Mail thread. I do not understand at all. > Notice the communication between the MIDCOM Agent and Middlebox > is transactional and state-full. So any transactional success/failure/ > resource_used is known immediately, no polling required. This provides > efficient resource usage across the administrative domain (think about load > balancing across multiple Middleboxes). I think we know this well from the protocol evaluation. > 4. For operating a network, there should be "policies" on what is the correct > action to take when parts of the network experience outage, problem, etc. > There should also be "policies" on when and how maintenance is done. > These "policies" can be carried out by human or be automated. The > choose is up to the owner of the network. I think for each netwrok there "are" policies. Sometime they exist just in the head of the administrators, sometime they are written in English, sometime they might be implemented in a convetional network management programm, sometime they are coded in a policy definition language of a policy-based management system. > When COPS is used, these "policies" can be pre-installed at the MIDCOM > Agent and/or Middlebox prior to the actual outage/problem/maintenance > event occurs. For example, after the Middlebox established the communication > with the MIDCOM Agent, the MIDCOM Agent can indicate the administrative > domain's "policies" if the Middlebox loose communication with the MIDCOM > Agent (these "policies" may indicate the Middlebox should contact a list > of back-up MIDCOM Agents in a specific prioritized order). There can also > be "policies" for partial or full failure of the Middlebox. For the MIDCOM Agent > maintenance issue in the E-Mail thread, there can be "policies" on when the > Middlebox should try to contact the MIDCOM Agent again with a specific > frequency, indicated to the Middlebox by the MIDCOM Agent before the > MIDCOM Agent goes into maintenance mode. But I would much prefer to use > a graceful method of redirecting the Middlebox to back-up MIDCOM Agents > during the primary MIDCOM Agent maintenance period and have the back-up > MIDCOM Agent redirect the Middlebox back to the primary MIDCOM Agent > when necessary. Notice this is all deterministic and under control. I am not sure, I fully understand this: Are you saying that there should be one (master) agent that does midcom configuration, but at the same time, using the same authenticated connection also does the higher level policy-configuration of the middlebox? This master agent then would tell the middlebox to connect to other middleboxes new installed middleboxes of which the middlebox had no knowledge, so far. Then the middlebox connects to this other agent. Essentially you are saying: It is no problem that COPS connects from middlebox to agent, because if you use COPS anyway for managing your network, then you can use to tell the middlebox (with non-Midcom means) to which agents to connect. So COPS for Midcom is no problem, if you use COPS also for Middlebox administration. This sounds like a Microsoft marketing strategy ;-) What if you don't want to use COPS for middlebox administration, because you already use Linux? > 5. When the Middlebox needs to be shut-down (or it fails), the MIDCOM Agent > knows immediately (within the limit of keep-alive messages), no polling is > needed to see if the services/resources provided by a Middlebox is available > to the MIDCOM Agent. What, if the agent needs to be shut down and boots up some time later. According to my experience (see my second comment), this is the much more frequently occuring event. > > With the above explanation, I have indicated that there are two levels > of interaction: > 1. Communication Establishment. > For COPS, it is initiated by the Middlebox. > 2. MIDCOM Functional Event Flow. > For both MIDCOM and COPS, it is from MIDCOM Agent to Middlebox. If I got you right, this holds only if you use COPS also for administrating the middlebox. > IMHO, I believe the MIDCOM Requirement cares about the "MIDCOM Functional > Event Flow" direction, NOT the "Communication Establishment" direction. > Hence COPS meet this requirement fully with the above explanation. > > Please provide the need to have the "Communication Establishment" directional > requirement reasoning if you think otherwise. > > I hope I have resolved the concerns indicated by this E-Mail thread, and please > let me know if I haven't. I still have the operational concerns I had before. But I thank you very much for explaining your issue in such a detail. Juergen > > Thank you! > -- Kwok -- > > > > > At 12:22 PM 10/22/02 -0400, Kwok Ho Chan wrote: >> Juergen, All: >> We are not talking about unconventional usage of COPS or COPS-PR. >> I am not indicating any change to the current COPS and COPS-PR RFCs. >> >> I am organizing the points made in other E-Mails on this thread and try to >> provide some more clarafication. >> Thanks! >> -- Kwok -- >> >> >> At 03:51 PM 10/22/02 +0200, Juergen Quittek wrote: >>> Kwok, >>> >>> Has this unconventional usage of COPS-PR already been discussed earier >>> in the COPS-PR community? Or was the idea developed just for meeting >>> the midcom requirements? >>> >>> Juergen >>> >>> >>> -- Tom-PT Taylor wrote on 22 October 2002 08:51 -0400: >>> >>>> I think the proposal is that the agent be the one to initiate the session, >>>> as per the requirements, even if it contradicts the COPS-PR design >>>> philosophy. The confusion arises because, as I read Kwok-Ho's note, the >>>> first half says this is possible but then the second half goes on to discuss >>>> the arrangement you have been expressing concerns about. >>> >>> >>>>> -----Original Message----- >>>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>>> Sent: Tuesday, October 22, 2002 3:39 AM >>>>> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho >>>>> [BL60:470:EXCH]; Martin Stiemerling >>>>> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>>>> Subject: RE: [midcom] Evaluation: COPS and session initialisation >>>>> >>>>> >>>>> Tom, >>>>> >>>>> -- Tom-PT Taylor wrote on 21 October 2002 18:21 -0400: >>>>> > I think we are agreed on the basic requirement: establishment and >>>>> > takedown of MIDCOM sessions must not require manual intervention or >>>>> > maintenance outage of the equipment. There is the policy aspect of >>>>> > MIDCOM session and failover management as described in the >>>>> framework, >>>>> > but I don't think that is what we are discussing here. >>>>> >>>>> The point I could not understand so far, is how to meet this >>>>> requirement (without additional support from additional >>>>> protocols) when the middlebox (and not the agent) is the >>>>> party that requests opening a midcom session. >>>>> >>>>> Juergen >>>>> >>>>> >>>>> >> -----Original Message----- >>>>> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>>> >> Sent: Monday, October 21, 2002 6:04 PM >>>>> >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH]; >>>>> >> Martin Stiemerling >>>>> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>>>> >> Subject: RE: [midcom] Evaluation: COPS and session initialisation >>>>> >> >>>>> >> >>>>> >> Tom, >>>>> >> >>>>> >> I'm not sure how "administration" is exactly defined, but >>>>> >> if you don't provide some additional non-midcom support >>>>> >> for automatically configuring the midbox with the list of >>>>> agents to >>>>> >> establish connections to, then the administrator might need to >>>>> >> configure the the middlebox manually. >>>>> >> >>>>> >> This becomes extramely entertaining, if you disable a >>>>> service, let's >>>>> >> say IP telephony for asome hours for maintenance. How would after >>>>> >> maintenence hours the middlebox learn that the agent is up >>>>> again and >>>>> >> that a new session should be established. I hope not by manual >>>>> >> interaction between middlebox and administrator. >>>>> >> >>>>> >> Juergen >>>>> >> >>>>> >> >>>>> >> -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400: >>>>> >> >>>>> >> > "Configuration" is just a word. If you said >>>>> >> "administration" I would >>>>> >> > be more worried, because that implies cost. >>>>> >> > >>>>> >> >> -----Original Message----- >>>>> >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>>> >> >> Sent: Monday, October 21, 2002 4:27 PM >>>>> >> >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling >>>>> >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; 'midcom@ietf.org' >>>>> >> >> Subject: Re: [midcom] Evaluation: COPS and session >>>>> initialisation >>>>> >> >> >>>>> >> >> >>>>> >> >> Kwok, >>>>> >> >> >>>>> >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400: >>>>> >> >> >>>>> >> >> > Martin, All: >>>>> >> >> > I will try to answer your question. As we have already >>>>> >> >> identified in the protocol evaluation document, >>>>> >> >> > "COPS does not meet the directionality part of the >>>>> >> >> requirement. The definition of COPS >>>>> >> >> > allows a PEP (Middlebox) to establish communication >>>>> >> with a PDP >>>>> >> >> > (MIDCOM Agent)." But, we added the following explanations: >>>>> >> >> > "However, nothing explicitly prohibits a PDP from >>>>> >> >> establishing communication with a >>>>> >> >> > PEP. The PEP could have local policies dictating what >>>>> >> >> action to take when it is >>>>> >> >> > contacted by an unknown PDP. These actions, defined in >>>>> >> >> the local policies, would >>>>> >> >> > ensure the proper establishment of an authorized >>>>> >> association. " >>>>> >> >> >>>>> >> >> Yes, I think this is exactly the point. You can create a >>>>> >> framework, >>>>> >> >> for example using policies, for initiating the >>>>> association between >>>>> >> >> middlebox and agent. You also can use a new Midcom Session >>>>> >> Initiation >>>>> >> >> Protocol to be used by the agent for telling the >>>>> >> middlebox: "Please >>>>> >> >> contact me for establishing a midcom session". >>>>> >> >> >>>>> >> >> The question is, whether this would be a good choice >>>>> considering >>>>> >> >> operational issues. I see service installation, >>>>> modification and >>>>> >> >> removal to be much more dynamic than middlebox installation, >>>>> >> >> modification and removal. Therefore, I consider it an >>>>> operational >>>>> >> >> disadvantage having to configure the middlebox each time a >>>>> >> service is >>>>> >> >> installed, is modified (changes the failover sequence), or is >>>>> >> >> removed. >>>>> >> >> >>>>> >> >> Juergen >>>>> >> >> >>>>> >> >> >>>>> >> >> > Once the COPS connection is open, it is perfectly within >>>>> >> the COPS >>>>> >> >> > protocol for the PDP to send unsolicited decisions to >>>>> >> the PEP (for >>>>> >> >> > example the midcom agent sending an open pinhole >>>>> decision to the >>>>> >> >> > middlebox. >>>>> >> >> > >>>>> >> >> > Also to address the fail over points you made below. The PEP >>>>> >> >> > (Middlebox) can have local policy indicating the >>>>> >> order by >>>>> >> >> > which it will contact the PDPs (MIDCOM Agents). This local >>>>> >> >> policy can >>>>> >> >> > actually be installed by the primary SIP server (in the >>>>> >> example you >>>>> >> >> > gave), indicating if communication is lost between it (the >>>>> >> >> primary SIP >>>>> >> >> > server) and the Middlebox, the Middlebox MUST contact >>>>> >> the THIRD SIP >>>>> >> >> > server as the highest priority back-up SIP server, then the >>>>> >> >> SECOND SIP >>>>> >> >> > server if the both the PRIMARY/FIRST SIP server and the >>>>> >> THIRD SIP >>>>> >> >> > server is not available to provide the required services. >>>>> >> >> Notice the >>>>> >> >> > fail over is totally deterministic and also controlled >>>>> >> by Policy of >>>>> >> >> > the controlling domain. >>>>> >> >> > >>>>> >> >> > Also only a single connection between a Middlebox and a >>>>> >> >> MIDCOM Agent >>>>> >> >> > is maintain at any given time, the one that is being used. >>>>> >> >> > >>>>> >> >> > Also lets say the PRIMARY SIP server >>>>> degrades/dies/off-load its >>>>> >> >> > service gracefully (you can also view this as part of load >>>>> >> >> balancing >>>>> >> >> > between multiple SIP servers), the PRIMARY SIP server can >>>>> >> >> REDIRECT the >>>>> >> >> > Middlebox to get its service from a specific other SIP >>>>> >> >> server, in the >>>>> >> >> > example you gave below, this should be the THIRD SIP >>>>> >> >> server. This is >>>>> >> >> > done without any interruption to the functionality the >>>>> >> Middlebox is >>>>> >> >> > providing. >>>>> >> >> > >>>>> >> >> > This is how COPS is intent to be used without any >>>>> >> >> modification to the >>>>> >> >> > current RFCs. >>>>> >> >> > >>>>> >> >> > With the above, one may take a step back and think: >>>>> >> >> > "Is the directional requirement really 'required' ?? Or >>>>> >> is it the >>>>> >> >> > FUNCTIONALITY that is really 'required' ??" >>>>> >> >> > >>>>> >> >> > I have shown how COPS satisfy the fail over and high >>>>> >> availability >>>>> >> >> > FUNCTIONALITIES without talking about the directional >>>>> >> >> > 'requirement'. >>>>> >> >> > >>>>> >> >> > Hope I have clarify some of the points raised. >>>>> >> >> > >>>>> >> >> > -- Kwok Ho Chan -- >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote: >>>>> >> >> >>> I think we discussed several times the "session" on >>>>> >> the mailing >>>>> >> >> >>> list. We never closed this on the list, I'm still >>>>> >> hoping we could >>>>> >> >> >>> close this at some point. What do we mean by session? >>>>> >> There is a >>>>> >> >> >>> relation between the Middlebox and the Midcom >>>>> >> >> agent, this >>>>> >> >> >>> relation consists of: >>>>> >> >> >>> -Establishing trust and authorization levels >>>>> -Establishing a >>>>> >> >> >>> security association -This relation could have a real >>>>> >> identifier >>>>> >> >> >>> or a pseudo >>>>> >> >> one based on the >>>>> >> >> >>> Midcom agent or Middlebox identity; this could be used >>>>> >> >> for hand-overs or >>>>> >> >> >>> for softstate cleaning in case the Midcom agent goes down. >>>>> >> >> >> >>>>> >> >> >> Agreed. >>>>> >> >> >> >>>>> >> >> >>> This relation doesn't really need to have a >>>>> direction for its >>>>> >> >> >>> establishment, I suggest that we take it out of the >>>>> >> >> directionality >>>>> >> >> >>> of the relation from the requirements document. >>>>> >> >> >> >>>>> >> >> >> The relationsship is from the framework document, section >>>>> >> >> 4. "MIDCOM >>>>> >> >> >> protocol": "MIDCOM shall be a client-server protocol, >>>>> >> initiated by >>>>> >> >> >> the agent." Section 6.2. "Registration and deregistration >>>>> >> >> of MIDCOM >>>>> >> >> >> agents" says: "MIDCOM agent profile may be >>>>> pre-configured on a >>>>> >> >> >> middlebox. Subsequent to that, the agent may choose to >>>>> >> initiate a >>>>> >> >> >> MIDCOM session prior to any data traffic." >>>>> >> >> >> >>>>> >> >> >> I always read "initiated" by the agent, that implies for >>>>> >> >> me the agent >>>>> >> >> >> starts the communication with the middlebox. We are >>>>> >> definitely too >>>>> >> >> >> late for deleting this directional component, because >>>>> >> it is in our >>>>> >> >> >> framework RFC. >>>>> >> >> >> >>>>> >> >> >> Another point for not initiating the communication by the >>>>> >> >> middlebox, >>>>> >> >> >> the above mentioned hand-off between agents. Imaging you >>>>> >> >> have three >>>>> >> >> >> SIP proxies, two of them as a fall-back. All three are >>>>> >> >> pre-configured >>>>> >> >> >> to the middlebox. The primary, or in duty, SIP server >>>>> >> has a server >>>>> >> >> >> crash, now the third SIP server takes over. How should the >>>>> >> >> middlebox >>>>> >> >> >> know that the third SIP server is the one in charge >>>>> and not the >>>>> >> >> >> second? The middlebox has to know something about >>>>> the failover >>>>> >> >> >> mechanism. Furhtermore it has to maintain to all proxies a >>>>> >> >> connection >>>>> >> >> >> at any time, that's polling! >>>>> >> >> >> >>>>> >> >> >> Martin >>>>> >> >> >> >>>>> >> >> >>> In addition COPS-PR could be used in the context of in path >>>>> >> >> >>> signaling for authorization policy purposes. As some of the >>>>> >> >> >>> Middleboxes will support both in path signaling (the NSIS WG >>>>> >> >> >>> delivery) and the MIDCOM off path protocol COPS-PR has >>>>> >> the best >>>>> >> >> >>> position to be the MIDCOM protocol. Cedric -----Original >>>>> >> >> >>> Message----- >>>>> >> >> >>> From: Martin Stiemerling >>>>> >> [mailto:Martin.Stiemerling@ccrle.nec.de] >>>>> >> >> >>> Sent: 17 October 2002 10:45 >>>>> >> >> >>> To: midcom@ietf.org >>>>> >> >> >>> Subject: [midcom] Evaluation: COPS and session >>>>> initialisation >>>>> >> >> >>> >>>>> >> >> >>> Just a poll about the working group opinion: >>>>> >> >> >>> The MIDCOM framework and requirements say that the agent >>>>> >> >> initiates >>>>> >> >> >>> the session to the middlebox. But in the COPS/COPS-PR >>>>> >> >> case the way >>>>> >> >> >>> is vice >>>>> >> >> >>> versa: The middlebox initiates the session to the >>>>> agent. I see >>>>> >> >> >>> this a as major difference in the particular >>>>> >> >> architecture. How >>>>> >> >> >>> does the working group feel about this. Is this just a >>>>> >> >> minore point or a >>>>> >> >> >>> real concern. >>>>> >> >> >>> Martin >>>>> >> >> >>> -- Martin Stiemerling >>>>> >> >> >>> NEC Europe Ltd. -- Network Laboratories >>>>> >> Stiemerling@ccrle.nec.de >>>>> >> >> >>> IPv4: http://www.ccrle.nec.de IPv6: >>>>> >> http://www.ipv6.ccrle.nec.de >>>>> >> >> >>> >>>>> >> _______________________________________________ >>>>> >> >> >>> midcom mailing list >>>>> >> >> >>> midcom@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/midcom >>>>> >> >> >> >>>>> >> >> >>>>> >> >>>>> >> >> >> >>>>> >> >> >> -- >>>>> >> >> >> Martin Stiemerling >>>>> >> >> >> >>>>> >> >> >> NEC Europe Ltd. -- Network Laboratories >>>>> >> Stiemerling@ccrle.nec.de >>>>> >> >> >> IPv4: http://www.ccrle.nec.de IPv6: >>>>> >> http://www.ipv6.ccrle.nec.de >>>>> >> >> >> >>>>> >> >> >> >>>>> >> _______________________________________________ >>>>> >> >> >> midcom mailing list >>>>> >> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>>>> >> >> > >>>>> >> >> > _______________________________________________ >>>>> >> >> > midcom mailing list >>>>> >> >> > midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>>>> >> >> >>>>> >> >> >>>>> >> >> _______________________________________________ >>>>> >> >> midcom mailing list >>>>> >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >>>>> >> >> >>>>> >> >>>>> >> >>>>> >> >>>>> > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 01:38:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18890 for ; Mon, 28 Oct 2002 01:37:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9S6dxt26920 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 01:39:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S6Zpv26203; Mon, 28 Oct 2002 01:35:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S6Yfv26168 for ; Mon, 28 Oct 2002 01:34:41 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18779 for ; Mon, 28 Oct 2002 01:32:07 -0500 (EST) Received: from kishanmgcl1255 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H4O00JWNI6B1I@mta0.huawei.com> for midcom@ietf.org; Mon, 28 Oct 2002 14:32:39 +0800 (CST) Date: Mon, 28 Oct 2002 12:07:05 +0530 From: arjun To: midcom@ietf.org Message-id: <00fb01c27e4c$701d2e10$4c03120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_eycC4SG4lfunUE6UatzjBQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [midcom] SIP interface problem Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_eycC4SG4lfunUE6UatzjBQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi We have starte working on MIDCOM recently.After going throgh the RFC 3304 I have some basic doubts | | | | | | | | | | | | | | | | | | | | | | | | | | | --Boundary_(ID_eycC4SG4lfunUE6UatzjBQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi
 
We have starte working on MIDCOM recently.After going throgh the RFC 3304 I have some basic doubts
 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
 
 
               
 
 
--Boundary_(ID_eycC4SG4lfunUE6UatzjBQ)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 01:55:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19347 for ; Mon, 28 Oct 2002 01:55:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9S6vYv27622 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 01:57:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S6r8v27417; Mon, 28 Oct 2002 01:53:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S6qLv27379 for ; Mon, 28 Oct 2002 01:52:21 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19203 for ; Mon, 28 Oct 2002 01:49:45 -0500 (EST) Received: from kishanmgcl1255 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H4O00JHGIZL67@mta0.huawei.com> for midcom@ietf.org; Mon, 28 Oct 2002 14:50:18 +0800 (CST) Date: Mon, 28 Oct 2002 12:24:39 +0530 From: arjun To: midcom@ietf.org Message-id: <015d01c27e4e$e6782ea0$4c03120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_ZypUL1M1cGPXoYH0MW1i5A)" X-Priority: 3 X-MSMail-priority: Normal Subject: [midcom] Fw: SIP interface problem Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_ZypUL1M1cGPXoYH0MW1i5A) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi I have sent the incomplete message by mistake. Sorry for the mistake.I will send the complete request little while later.Sorry once again Thank you Arjun ----- Original Message ----- From: arjun To: midcom@ietf.org Sent: Monday, October 28, 2002 12:07 PM Subject: SIP interface problem Hi We have starte working on MIDCOM recently.After going throgh the RFC 3304 I have some basic doubts | | | | | | | | | | | | | | | | | | | | | | | | | | | --Boundary_(ID_ZypUL1M1cGPXoYH0MW1i5A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi
 
I have sent the incomplete message by mistake. Sorry for the mistake.I will send the complete request little while later.Sorry once again
 
Thank you
 
Arjun
----- Original Message -----
From: arjun
Sent: Monday, October 28, 2002 12:07 PM
Subject: SIP interface problem

Hi
 
We have starte working on MIDCOM recently.After going throgh the RFC 3304 I have some basic doubts
 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
|                                                            |                                               | 
 
 
               
 
 
--Boundary_(ID_ZypUL1M1cGPXoYH0MW1i5A)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 10:27:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13921 for ; Mon, 28 Oct 2002 10:27:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SFT0i29602 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 10:29:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SFPDv29484; Mon, 28 Oct 2002 10:25:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SFOfv29451 for ; Mon, 28 Oct 2002 10:24:41 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13685 for ; Mon, 28 Oct 2002 10:22:16 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SFOYgM001060 for ; Mon, 28 Oct 2002 07:24:34 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK30460; Mon, 28 Oct 2002 07:19:47 -0800 (PST) Message-Id: <200210281519.AAK30460@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 28 Oct 2002 10:24:35 -0500 Subject: [midcom] Text conferencing in Atlanta Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We have the potential to do text conferencing during the meeting in Atlanta, which can allow people who are not present to participate in the meeting in real time. Are there people who either 1) will NOT be travelling to Atlanta or 2) MUST be in another session at the same time but who would like to participate in the midcom meeting? As things currently stand we are scheduled to meet at 1415-1315 on Tuesday, 19 November, and meeting at the same time are: INT atommib AToM MIB WG OPS dnsop Domain Name Server Operations WG RTG udlr UniDirectional Link Routing WG SEC krb-wg Kerberos WG SEC syslog Security Issues in Network Event Logging WG Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 10:46:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15162 for ; Mon, 28 Oct 2002 10:46:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SFmcD31035 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 10:48:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SFm7v31004; Mon, 28 Oct 2002 10:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SFk2v30909 for ; Mon, 28 Oct 2002 10:46:02 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14890 for ; Mon, 28 Oct 2002 10:43:37 -0500 (EST) 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 g9SFhcg11137 for ; Mon, 28 Oct 2002 10:43:38 -0500 (EST) 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 g9SFhbC11120 for ; Mon, 28 Oct 2002 10:43:37 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SPAN status X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 28 Oct 2002 08:45:57 -0700 Message-ID: Thread-Topic: [midcom] SPAN status Thread-Index: AcJ6xY4b9OeTNeSERSStqUDmWtv7KAD0z78A From: "Stukas, Michael T (Mike)" To: "Melinda Shore" , "Cullen Jennings" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9SFk2v30910 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Sorry If I am a thread behind but what is the status of TURN? Has it ceased as well? Mike Stukas -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, October 23, 2002 12:40 PM To: Cullen Jennings Cc: midcom@ietf.org Subject: Re: [midcom] SPAN status > Are we deleting SPAN which was to my understanding the name of an output of > a design team which has somewhat died? Or are we deleting tying to find a > pre-midcom relay based solution for the cases where STUN will not work? The latter. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 11:24:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17037 for ; Mon, 28 Oct 2002 11:24:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SGQ6m00599 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 11:26:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SGM9v00514; Mon, 28 Oct 2002 11:22:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SGLEv00480 for ; Mon, 28 Oct 2002 11:21:14 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16770 for ; Mon, 28 Oct 2002 11:18:49 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SGL9PP029994 for ; Mon, 28 Oct 2002 08:21:09 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK32143; Mon, 28 Oct 2002 08:16:20 -0800 (PST) Message-Id: <200210281616.AAK32143@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 28 Oct 2002 11:21:03 -0500 Subject: [midcom] COPS discussion Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Does anybody feel we have not reached agreement on the COPS directionality question? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 11:54:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18541 for ; Mon, 28 Oct 2002 11:54:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SGujH02623 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 11:56:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SGtTv02566; Mon, 28 Oct 2002 11:55:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SGsOv02445 for ; Mon, 28 Oct 2002 11:54:24 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18360 for ; Mon, 28 Oct 2002 11:51:59 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9SGs8u03363; Mon, 28 Oct 2002 11:54:09 -0500 (EST) Received: from zbl6c002.us.nortel.com ([132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TWX0M3SB; Mon, 28 Oct 2002 11:54:08 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TSNC9C5R; Mon, 28 Oct 2002 11:53:18 -0500 Message-Id: <5.0.0.25.0.20021028115010.035ef180@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 28 Oct 2002 11:52:08 -0500 To: Melinda Shore From: Kwok Ho Chan Subject: Re: [midcom] COPS discussion Cc: midcom@ietf.org In-Reply-To: <200210281616.AAK32143@mira-sjc5-4.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , There are still discussions to have to come to better understands on this topic. Hence I feel we have NOT reach agreement on the COPS directionality question. -- Kwok -- At 11:21 AM 10/28/02 -0500, Melinda Shore wrote: >Does anybody feel we have not reached agreement on the COPS >directionality question? > >Melinda >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 12:31:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20006 for ; Mon, 28 Oct 2002 12:31:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SHXhm05274 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 12:33:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SHXCv05205; Mon, 28 Oct 2002 12:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SHWTv05151 for ; Mon, 28 Oct 2002 12:32:29 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19895 for ; Mon, 28 Oct 2002 12:30:03 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9SHWOot021407; Mon, 28 Oct 2002 09:32:24 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK34768; Mon, 28 Oct 2002 09:27:31 -0800 (PST) Message-Id: <200210281727.AAK34768@mira-sjc5-4.cisco.com> To: Kwok Ho Chan cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] COPS discussion In-Reply-To: Message from Kwok Ho Chan of "Mon, 28 Oct 2002 11:52:08 EST." <5.0.0.25.0.20021028115010.035ef180@zbl6c002.corpeast.baynetworks.com> Date: Mon, 28 Oct 2002 12:32:18 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > There are still discussions to have to come to better understands > on this topic. > Hence I feel we have NOT reach agreement on the COPS > directionality question. Can you identify specifically which issues need more discussion and then resolution? Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 15:40:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28886 for ; Mon, 28 Oct 2002 15:40:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SKgoY16635 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 15:42:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SKd7v16510; Mon, 28 Oct 2002 15:39:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SKc7v16456 for ; Mon, 28 Oct 2002 15:38:07 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28732 for ; Mon, 28 Oct 2002 15:35:40 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9SKbiY04764; Mon, 28 Oct 2002 21:37:44 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 6A932713E9; Mon, 28 Oct 2002 21:37:37 +0100 (CET) Cc: midcom@ietf.org X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 From: "Juergen Quittek" MIME-Version: 1.0 subject: Re: [midcom] COPS discussion To: "Melinda Shore" , "Kwok Ho Chan" Organization: NEC Europe Ltd. content-type: text/plain; charset="iso-8859-1" date: Mon, 28 Oct 2002 21:37:37 +0100 content-transfer-encoding: 7bit Message-Id: <20021028203737.6A932713E9@imap.heidelberg.ccrle.nec.de> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, -- Melinda Shore wrote on 28 October 2002 12:32 -0500: >> There are still discussions to have to come to better understands >> on this topic. >> Hence I feel we have NOT reach agreement on the COPS >> directionality question. > > Can you identify specifically which issues need more > discussion and then resolution? The issue is the one Kwok, Tom, Martin, myself, and some more guys on the mailing list have been discussing recently: Is directionality of establishing a midcom connection relevant or irrelevant? I try to summarize the current point of the discussion: With COPS-PR, the middlebox establishes the connection with the agent. - Juergen: This is bad, because we don't want to reconfigure the middlebox each time we add, modify, or remove a service that includes a midcom agent. - Kwok: This is no problem at all, because if we are using COPS-PR anyway, we can also use it for telling the middebox to which agent to connect next. Kwok, I might not have stated your position correctly. Please correct me, If I am wrong. Also I apologize for all other positions I ignored. Supporters of other positions, please speak up. Juergen > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 16:33:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00884 for ; Mon, 28 Oct 2002 16:33:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SLZk818893 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 16:35:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SLZFv18851; Mon, 28 Oct 2002 16:35:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SLY1v18821 for ; Mon, 28 Oct 2002 16:34:01 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00826 for ; Mon, 28 Oct 2002 16:31:34 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9SLXRh02184; Mon, 28 Oct 2002 16:33:28 -0500 (EST) Received: from zbl6c002.us.nortel.com ([132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TWX0MR6B; Mon, 28 Oct 2002 16:33:27 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TSNC9DMM; Mon, 28 Oct 2002 16:32:37 -0500 Message-Id: <5.0.0.25.0.20021028154732.035358b0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 28 Oct 2002 16:31:01 -0500 To: "Juergen Quittek" From: Kwok Ho Chan Subject: Re: [midcom] COPS discussion Cc: "Melinda Shore" , "Kwok-Ho Chan" , midcom@ietf.org In-Reply-To: <20021028203737.6A932713E9@imap.heidelberg.ccrle.nec.de> 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Juergen, Melinda, all: I think we have NOT agreed on the functional requirement when the Directional aspect is further detailed as follows: >With the above explanation, I have indicated that there are two levels >of interaction: >1. Communication Establishment. > For COPS, it is initiated by the Middlebox. >2. MIDCOM Functional Event Flow. > For both MIDCOM and COPS, it is from MIDCOM Agent to Middlebox. And Juergen INCORRECTLY stated Kwok's position. I have described in details how it would work in our E-Mail discussions and I believe there are still issues with regard to the importance of each of the two points above. -- Kwok -- At 09:37 PM 10/28/02 +0100, Juergen Quittek wrote: >Melinda, > >-- Melinda Shore wrote on 28 October 2002 12:32 -0500: > > >> There are still discussions to have to come to better understands > >> on this topic. > >> Hence I feel we have NOT reach agreement on the COPS > >> directionality question. > > > > Can you identify specifically which issues need more > > discussion and then resolution? > >The issue is the one Kwok, Tom, Martin, myself, and some more >guys on the mailing list have been discussing recently: > > Is directionality of establishing a midcom connection > relevant or irrelevant? > >I try to summarize the current point of the discussion: > >With COPS-PR, the middlebox establishes the connection with the agent. > >- Juergen: This is bad, because we don't want to reconfigure the > middlebox each time we add, modify, or remove a service > that includes a midcom agent. > >- Kwok: This is no problem at all, because if we are using COPS-PR > anyway, we can also use it for telling the middebox to > which agent to connect next. > >Kwok, I might not have stated your position correctly. Please >correct me, If I am wrong. Also I apologize for all other >positions I ignored. Supporters of other positions, please >speak up. > > Juergen > > > Thanks, > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > >-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Oct 28 17:29:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02406 for ; Mon, 28 Oct 2002 17:29:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SMVex21957 for midcom-archive@odin.ietf.org; Mon, 28 Oct 2002 17:31:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SMVGv21936; Mon, 28 Oct 2002 17:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SMUiv21895 for ; Mon, 28 Oct 2002 17:30:44 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02366 for ; Mon, 28 Oct 2002 17:28:16 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9SMUUot025686; Mon, 28 Oct 2002 14:30:31 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK49184; Mon, 28 Oct 2002 14:25:40 -0800 (PST) Message-Id: <200210282225.AAK49184@mira-sjc5-4.cisco.com> To: Kwok Ho Chan cc: "Juergen Quittek" , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] COPS discussion In-Reply-To: Message from Kwok Ho Chan of "Mon, 28 Oct 2002 16:31:01 EST." <5.0.0.25.0.20021028154732.035358b0@zbl6c002.corpeast.baynetworks.com> Date: Mon, 28 Oct 2002 17:30:28 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > >1. Communication Establishment. > > For COPS, it is initiated by the Middlebox. I think you may be misinterpreting the requirements when you say, as you did in another message, that the "communication establishment" directionality requirement is satisfied. Requirement 2.1.1 in RFC 3304 says "The Midcom protocol must enable a Midcom agent requiring the services of a middlebox to establish an authorized association between itself and the middlebox," which I think is pretty clear that the association must be initiated by the agent, not the middlebox. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Oct 29 03:36:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25023 for ; Tue, 29 Oct 2002 03:36:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9T8cwe29458 for midcom-archive@odin.ietf.org; Tue, 29 Oct 2002 03:38:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T8c3v29430; Tue, 29 Oct 2002 03:38:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T8aiv28781 for ; Tue, 29 Oct 2002 03:36:44 -0500 Received: from rhenium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24979 for ; Tue, 29 Oct 2002 03:34:04 -0500 (EST) Received: from host213-122-2-168.in-addr.btopenworld.com ([213.122.2.168] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 186RrE-0002iN-00; Tue, 29 Oct 2002 08:36:16 +0000 Message-ID: <005601c27f26$49e626e0$0200000a@tkw> From: "Pete Cordell" To: "Stukas, Michael T \(Mike\)" Cc: References: Subject: Re: [midcom] SPAN status Date: Tue, 29 Oct 2002 08:36:11 -0000 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 'fraid so. SPAN was intended to be a consensus version of all the various proposals in this space including TURN. Pete. ----- Original Message ----- From: "Stukas, Michael T (Mike)" To: "Melinda Shore" ; "Cullen Jennings" Cc: Sent: 28 October 2002 15:45 Subject: RE: [midcom] SPAN status > Sorry If I am a thread behind but what is the status of TURN? Has it ceased as well? > > Mike Stukas > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, October 23, 2002 12:40 PM > To: Cullen Jennings > Cc: midcom@ietf.org > Subject: Re: [midcom] SPAN status > > > > Are we deleting SPAN which was to my understanding the name of an output of > > a design team which has somewhat died? Or are we deleting tying to find a > > pre-midcom relay based solution for the cases where STUN will not work? > > The latter. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 30 15:50:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10675 for ; Wed, 30 Oct 2002 15:50:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UKqLl01380 for midcom-archive@odin.ietf.org; Wed, 30 Oct 2002 15:52:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UKmVv01219; Wed, 30 Oct 2002 15:48:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UKlmv01169 for ; Wed, 30 Oct 2002 15:47:48 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10369 for ; Wed, 30 Oct 2002 15:45:19 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9UKlcgM008438 for ; Wed, 30 Oct 2002 12:47:38 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAL28264; Wed, 30 Oct 2002 12:42:51 -0800 (PST) Message-Id: <200210302042.AAL28264@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 30 Oct 2002 15:47:38 -0500 Subject: [midcom] COPS in the eval document Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I'd like to propose that we let the existing text in 2.1.1 stand as is. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Oct 30 17:15:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15617 for ; Wed, 30 Oct 2002 17:15:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UMHte07118 for midcom-archive@odin.ietf.org; Wed, 30 Oct 2002 17:17:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UME9v06898; Wed, 30 Oct 2002 17:14:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UMD5v06868 for ; Wed, 30 Oct 2002 17:13:05 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15354 for ; Wed, 30 Oct 2002 17:10:36 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9UMClE01705; Wed, 30 Oct 2002 17:12:47 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TWX0NB50; Wed, 30 Oct 2002 17:12:46 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TSNC9GDQ; Wed, 30 Oct 2002 17:12:46 -0500 Message-Id: <5.0.0.25.0.20021030170331.02af9bf0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 30 Oct 2002 17:11:34 -0500 To: Melinda Shore From: Kwok Ho Chan Subject: Re: [midcom] COPS in the eval document Cc: midcom@ietf.org In-Reply-To: <200210302042.AAL28264@mira-sjc5-4.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Agree. -- Kwok -- At 03:47 PM 10/30/02 -0500, Melinda Shore wrote: >I'd like to propose that we let the existing text in 2.1.1 >stand as is. > >Melinda >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 31 12:08:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01647 for ; Thu, 31 Oct 2002 12:08:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VHA7113819 for midcom-archive@odin.ietf.org; Thu, 31 Oct 2002 12:10:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VH6Pv13057; Thu, 31 Oct 2002 12:06:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VH5hv13006 for ; Thu, 31 Oct 2002 12:05:43 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01357 for ; Thu, 31 Oct 2002 12:03:15 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9VH5HY22604; Thu, 31 Oct 2002 18:05:17 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F033672B7C; Thu, 31 Oct 2002 18:05:00 +0100 (CET) Date: Thu, 31 Oct 2002 18:05:01 +0100 From: Juergen Quittek To: Kwok Ho Chan , Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] COPS in the eval document Message-ID: <36392219.1036087501@[192.168.102.164]> In-Reply-To: <5.0.0.25.0.20021030170331.02af9bf0@zbl6c002.corpeast.baynetworks.com> References: <5.0.0.25.0.20021030170331.02af9bf0@zbl6c002.corpeast.baynetworks.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That's also fine with me. Actually, the discussion was not about whether or not COPS-PR meets requirement 2.1.1. partially or not. I think we all agree on the partial compliance. The discussion was about whether or not this is partial compliance is a "no problem" partial match or a "big problem" partial match. So far, we did not discuss how the evaluation will result into a recommendation which protocol(s) to use for IPFIX. For some requirements, it might be essential having full compliancy, for some partial might be fine. I'm afraid that there is still a lot of discussion ahead of us, before we can turn the item level evaluation into a protcol recommendation. Juergen -- Kwok Ho Chan wrote on 30 October 2002 17:11 -0500: > Agree. > -- Kwok -- > > > At 03:47 PM 10/30/02 -0500, Melinda Shore wrote: >> I'd like to propose that we let the existing text in 2.1.1 >> stand as is. >> >> Melinda >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 31 12:13:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01847 for ; Thu, 31 Oct 2002 12:13:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VHFYu14075 for midcom-archive@odin.ietf.org; Thu, 31 Oct 2002 12:15:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHF6v14002; Thu, 31 Oct 2002 12:15:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHE6v13952 for ; Thu, 31 Oct 2002 12:14:06 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01785 for ; Thu, 31 Oct 2002 12:11:38 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VHDnxF017113; Thu, 31 Oct 2002 09:13:49 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAM02461; Thu, 31 Oct 2002 09:09:07 -0800 (PST) Message-Id: <200210311709.AAM02461@mira-sjc5-4.cisco.com> To: Juergen Quittek cc: Kwok Ho Chan , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] COPS in the eval document In-Reply-To: Message from Juergen Quittek of "Thu, 31 Oct 2002 18:05:01 +0100." <36392219.1036087501@[192.168.102.164]> Date: Thu, 31 Oct 2002 12:13:53 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > I'm afraid that there is still a lot of discussion ahead > of us, before we can turn the item level evaluation into > a protcol recommendation. Of course but we need to make sure that we really understand the document. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 31 12:23:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02379 for ; Thu, 31 Oct 2002 12:23:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VHPe014647 for midcom-archive@odin.ietf.org; Thu, 31 Oct 2002 12:25:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHM4v14385; Thu, 31 Oct 2002 12:22:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHI9v14191 for ; Thu, 31 Oct 2002 12:18:09 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01969 for ; Thu, 31 Oct 2002 12:15:42 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VHI1gM023866 for ; Thu, 31 Oct 2002 09:18:01 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAM02633; Thu, 31 Oct 2002 09:13:17 -0800 (PST) Message-Id: <200210311713.AAM02633@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 31 Oct 2002 12:18:03 -0500 Subject: [midcom] *Non-binding* straw poll: two questions Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I'd like to get a sense of the working group on two questions. The results of this straw poll are not binding - THIS IS NOT A WORKING GROUP DECISION POLL. If you haven't read the evaluation document please don't respond. 1) Please identify any of the three remaining protocols that you feel are unsuitable for use as a midcom protocol (you may name more than one). 2) Please identify which of the three protocols you think best fits the midcom framework and requirements documents, as described in the evaluation draft. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 31 12:58:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04756 for ; Thu, 31 Oct 2002 12:58:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VI01g17419 for midcom-archive@odin.ietf.org; Thu, 31 Oct 2002 13:00:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHx7v17356; Thu, 31 Oct 2002 12:59:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VHwXv17315 for ; Thu, 31 Oct 2002 12:58:33 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04613 for ; Thu, 31 Oct 2002 12:56:05 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VHwMxH022581 for ; Thu, 31 Oct 2002 09:58:22 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAM04649; Thu, 31 Oct 2002 09:53:33 -0800 (PST) Message-Id: <200210311753.AAM04649@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 31 Oct 2002 12:58:16 -0500 Subject: [midcom] Straw poll - my goof Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , There are *four* remaining protocols - RSIP has been eliminated. If you've read the evaluation draft and followed the discussion you know what the four other protocols are. Apologies, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 31 13:09:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05504 for ; Thu, 31 Oct 2002 13:09:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VIB0818839 for midcom-archive@odin.ietf.org; Thu, 31 Oct 2002 13:11:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIA6v18767; Thu, 31 Oct 2002 13:10:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VI9Dv18668 for ; Thu, 31 Oct 2002 13:09:13 -0500 Received: from EXECDSL.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05349 for ; Thu, 31 Oct 2002 13:06:45 -0500 (EST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 3911354 for midcom@ietf.org; Thu, 31 Oct 2002 13:09:08 -0500 Message-Id: <5.1.0.14.0.20021031130432.026abe00@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 13:08:31 -0500 To: midcom@ietf.org From: "Joel M. Halpern" Subject: Re: [midcom] *Non-binding* straw poll: two questions In-Reply-To: <200210311713.AAM02633@mira-sjc5-4.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Reviewing the draft, understanding that this is not binding [and a bunch of other caveats to be fair...] 1) I believe all four remaining protocols can meet the MIDCOM requirements. However, I feel that the issue of who establishes the connection, while it can be dealt with, is an important facet of MIDCOM operation. Therefore, I would say that MegaCo and COPS are less suitable. (If pushed, I would say unsuitable, which is what the question actually asks.) 2) Based on the information in the evaluation document (plus gut feel) I think that we will be slightly better off using Diameter for the basis of the MIDCOM operation. But it is a very close call. Yours, Joel At 12:18 PM 10/31/2002 -0500, Melinda Shore wrote: >I'd like to get a sense of the working group on two >questions. The results of this straw poll are not binding - >THIS IS NOT A WORKING GROUP DECISION POLL. If you haven't >read the evaluation document please don't respond. > >1) Please identify any of the three remaining protocols that >you feel are unsuitable for use as a midcom protocol (you >may name more than one). > >2) Please identify which of the three protocols you think >best fits the midcom framework and requirements documents, >as described in the evaluation draft. > >Melinda >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Oct 31 23:59:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27173 for ; Thu, 31 Oct 2002 23:59:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA150Ii21806 for midcom-archive@odin.ietf.org; Fri, 1 Nov 2002 00:00:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA14xTv21572; Thu, 31 Oct 2002 23:59:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA14wvv21557 for ; Thu, 31 Oct 2002 23:58:57 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27126 for ; Thu, 31 Oct 2002 23:56:23 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gA14wkY32704; Fri, 1 Nov 2002 05:58:46 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (dialup-209.245.230.188.Dial1.Dallas1.Level3.net [209.245.230.188]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.3/8.12.3) with ESMTP id gA16CBab004749; Fri, 1 Nov 2002 06:12:13 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) X-Authentication-Warning: ftp.ccrle.nec.de: Host dialup-209.245.230.188.Dial1.Dallas1.Level3.net [209.245.230.188] claimed to be ccrle.nec.de Message-ID: <3DC20991.9010002@ccrle.nec.de> Date: Fri, 01 Nov 2002 05:56:49 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org Subject: Re: [midcom] COPS in the eval document References: <200210302042.AAL28264@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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree as well! Melinda Shore wrote: >I'd like to propose that we let the existing text in 2.1.1 >stand as is. > >Melinda >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom