From mailnull@www1.ietf.org Sun Dec 1 00:57: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 AAA20791 for ; Sun, 1 Dec 2002 00:57:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB15xYX09218 for midcom-archive@odin.ietf.org; Sun, 1 Dec 2002 00:59: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 gB15thv09135; Sun, 1 Dec 2002 00:55:43 -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 gB15t0v09113 for ; Sun, 1 Dec 2002 00:55:00 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20731 for ; Sun, 1 Dec 2002 00:52:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB15srYH009828; Sun, 1 Dec 2002 00:54:53 -0500 (EST) Message-ID: <3DE9A42A.7080608@dynamicsoft.com> Date: Sun, 01 Dec 2002 00:54:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: midcom@ietf.org Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures 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 Nope, nothing more. But it makes sense to me that it provides a way to guarantee unique usernames without relying on IP address uniqueness. -Jonathan R. Cullen Jennings wrote: > Did our esteemed colleague, Mr. Bellovin, provide any insight on purpose of > the prefix? > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 3 12:13: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 MAA03714 for ; Tue, 3 Dec 2002 12:13:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HG4s28396 for midcom-archive@odin.ietf.org; Tue, 3 Dec 2002 12:16:04 -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 gB3HFTv28318; Tue, 3 Dec 2002 12:15: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 gB3HElv28232 for ; Tue, 3 Dec 2002 12:14:47 -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 MAA03573 for ; Tue, 3 Dec 2002 12:11:53 -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 gB3HEfF03954; Tue, 3 Dec 2002 18:14:41 +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 039577C849; Tue, 3 Dec 2002 18:12:43 +0100 (CET) Date: Tue, 03 Dec 2002 18:12:43 +0100 From: Juergen Quittek To: Jerome Moisand , midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read Message-ID: <20486067.1038939163@[192.168.102.164]> In-Reply-To: <001001c29628$08d796c0$8482accf@cable.rcn.com> References: <001001c29628$08d796c0$8482accf@cable.rcn.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 Jerome, -- Jerome Moisand wrote on 27 November 2002 10:16 -0500: > Juergen, > > I was just saying that choosing SNMPv3 because it's "widely deployed" isn't > a convincing argument at all. That's correct. > I was not making a case for choosing this protocol or against it, I do see > multiple Pros & Cons for SNMPv3 (and the others). Agreed. > I just wanted to express the opinion that we shouldn't shortcut the > decision-making process. I would like to shortcut it, but only with good arguments. > (see below a few more details for clarification, but not really adding much > to my points). > > Tx > Jerome > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Jerome Moisand" > Cc: ; "Melinda Shore" > Sent: Wednesday, November 27, 2002 9:31 AM > Subject: Re: [midcom] Midcom proposal: please read > > >> Hi Jerome, >> >> I am also not sure whether or not SNMP would be a good choice for >> MIDCOM. But your arguments confused me. Do you want to say "everything >> else would be better? Or do you see a good candidate, you would >> prefer? >> >> Please see some more comments inline. > > => and my answers > >> >> Juergen >> >> > Hello, >> > >> > I'm new to this list, so apologies in advance if I might repeat what > other >> > people already stated. >> > >> > If I remember well, the main point made during the midcom session about >> > shorcutting the protocol selection process was that SNMP is way more > widely >> > implemented than other protocol candidates. >> > >> > I am not sure to see the value of this point. >> > >> > First, SNMP is definitely widely implemented, but essentially for > monitoring >> > purposes (alarms & stats). It seems a big stretch to say that SNMP is > widely >> > implemented for provisioning & for authorization, where protocols like > CLI >> >> Yes, CLI is really most widely implemented as configuration protocol. >> But this is not at all a protocol (maybe it is 1000 protocols :-). > > => I facetiously referred to CLI as a protocol, knowing well that many > people will balk at this terminology! ;-) > => Yes, we're in complete agreement here. > >> > and Radius are by far the most widely deployed. Also SNMPv1 and to a > lesser >> > extent SNMPv2 are widely used, but it also seems a big stretch to say > that >> > SNMPv3 is widely implemented. Just look at the largest router > manufacturer >> > general strategy in this respect... >> > >> > Second, the fact that a protocol is widely implemented doesn't make it >> > suitable for all purposes. Both Diameter and COPS have been designed to >> >> First you compare SNMPv3 to CLI and say its much less widely used. This >> is completely right, but not useful at all. Now you compare it to COPS >> and Diameter. Compared to Diameter (and probably also COPS), SNMPv3 is >> indeed widely used. > > => everything is relative, but all in all, none of the proposed candidates > (SNMPv3 for provisioning, Diameter, COPS) is widely used yet, far from it. > By either Network Elements, or OSS systems. Or let's say, not to a point > where it should become a significant factor in our decision-making. These > three protocols clearly remain to be proven on the field. This is only my > perception, of course (probably tainted by the fact that I know well Service > Providers environments, but less enterprise networking). Maybe there is an argument, that SNMP is the protocol which is most likely to be implemented on a managed box anyway. And in the future, I expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3. > >> > allow better processing for transaction-oriented policy decisions (which > is >> > exactly what midcom is about, I believe). Both protocols were intended > to >> > address such situations that SNMP and Radius were not good at. If it > were >> >> Please exlain! How is COPS addressing the "mutliple clients configuring >> a single server while addressing the same (kind of) resources)" situation? >> I would say: not at all. > > => this is another thread of discussion. I did hear Melinda express > reservations on this point, but this deserves a separate e-mail thread. I'll > come back on this, as well as the transaction aspect of midcom (where I > think SNMPv3 has a big issue). > > => maybe somebody would be kind enough to copy & paste some previous e-mail > thread on this topic, and forward it to me? Just to not making you guys > repeat yourselves? I'll do so. >> > not the case, why did IETF spend so much time working on these two new >> > protocols? Also note that the mere fact that these protocols have been >> > recently defined makes it obvious that they are not yet widely > implemented. >> > So? Should we never use next-gen protocols on this basis? I don't > believe >> > so. >> >> I cannot follow your argument. We are using a lot of very recent > protocols, >> but do we have to choose them always, just because the are new? If COPS-PR >> is not even widely used in it's original domain, policy-based > configuration, >> yet, then why should I already consider using it for other purposes for > which >> it was not really designed. The situation would certainly be different, if >> COPS was already implemented widely for policy-based configuration of > devices. >> But since it is not (and I personally see it coming soon, why should I > choose >> it? Because it is 'next-gen'? > > => funny the way you took the direct negation of my statement! You're saying > we should NOT *always* use recent protocols just because they are recent. I > was just saying that we should NOT *always* use old protocols (or new > flavors of an old protocol) just because they are 'old' (hence 'proven') and > have been widely used for a completly different application (e.g. > monitoring). Well, both statements are fair, I believe! agreed. > => maybe I don't fully understand yet what midcom is about, but I do see > this as a dynamic policy management problem with transactional properties. > So it only seems natural to look at policy management protocols. Which the > group rightfully did, without jumping to hasty conclusions. All this sounds > fair to me. But suddenly shortcutting such process based on a very debatable > point, that, I have to disagree with. > >> > >> > Bottomline: I wouldn't understand why such a "decision shortcut" would > be >> > used on the basis of this "wide implementation" argument, which doesn't > seem >> > (to me) to hold much water. I believe the "midcom" group needs to find a >> > better rationale (and process) for making such decision. >> >> On this point, I fully agree with you! > > => hey, we did agree on a couple of things, great! ;-) > >> > >> > Tx >> > Jerome Moisand (Juniper Networks) >> > >> > > Melinda Shore wrote: >> > > >> > > > There was a proposal made during the midcom session at the >> > > > IETF meeting to shortcut the protocol selection process and >> > > > just go with SNMPv3 as the midcom protocol. Consistent with >> > > > IETF process, this is a decision to be made on the mailing >> > > > list. I'd like to come to a decision within the next week >> > > > or so (Thursday is Thanksgiving in the US and many people >> > > > may be away this week). >> > > > >> > > > 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 >> > >> -- > > _______________________________________________ > 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 Dec 3 17:34: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 RAA22870 for ; Tue, 3 Dec 2002 17:34:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Mb8622137 for midcom-archive@odin.ietf.org; Tue, 3 Dec 2002 17:37:08 -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 gB3MXIv21766; Tue, 3 Dec 2002 17:33:18 -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 gB3MWnv21742 for ; Tue, 3 Dec 2002 17:32:49 -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 RAA22684 for ; Tue, 3 Dec 2002 17:29:53 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB3MWfLW019105 for ; Tue, 3 Dec 2002 14:32:41 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABC15312; Tue, 3 Dec 2002 14:32:40 -0800 (PST) Message-Id: <200212032232.ABC15312@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Midcom proposal: please read In-Reply-To: Message from Melinda Shore of "Mon, 25 Nov 2002 08:48:20 EST." <200211251342.AAY06880@mira-sjc5-4.cisco.com> Date: Tue, 03 Dec 2002 17:32:40 -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: , It looks like there's sufficient objection to the proposal to just go ahead now with SNMPv3 as the midcom protocol. Because of that we do need to forge ahead with the protocol selection process, and at this point I'd like to discuss removing COPS from contention. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 3 21:48: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 VAA00619 for ; Tue, 3 Dec 2002 21:48:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB42oix05122 for midcom-archive@odin.ietf.org; Tue, 3 Dec 2002 21:50:44 -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 gB42oHv05110; Tue, 3 Dec 2002 21:50:18 -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 gB42njv05056 for ; Tue, 3 Dec 2002 21:49:45 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00561 for ; Tue, 3 Dec 2002 21:46:45 -0500 (EST) Received: from r70036 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H6K00HV4QEOEC@mta1.huawei.com> for midcom@ietf.org; Wed, 04 Dec 2002 10:47:12 +0800 (CST) Date: Wed, 04 Dec 2002 10:52:30 +0800 From: Rajeev K R To: midcom@ietf.org Message-id: <002501c29b40$301c79e0$8d084d0a@r70036> 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: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <001001c29628$08d796c0$8482accf@cable.rcn.com> <20486067.1038939163@[192.168.102.164]> Content-Transfer-Encoding: 7BIT Subject: [midcom] PRR support 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, The example flow shown in draft-ietf-midcom-semantics-00.txt requires a PRR. But PRR is optional for a middle box. So how can the MIDCOM agent realise this call if the middlebox does not support PRR ? (In case this is already answered in the list please forward me some of the relevant mails...) Regards, Rajeev _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Dec 4 04:43: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 EAA03993 for ; Wed, 4 Dec 2002 04:43:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB49jsI04635 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 04:45:54 -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 gB49jIv04591; Wed, 4 Dec 2002 04:45:18 -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 gB49ixv04567 for ; Wed, 4 Dec 2002 04:44:59 -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 EAA03965 for ; Wed, 4 Dec 2002 04:41:56 -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 gB49ibF22292; Wed, 4 Dec 2002 10:44:37 +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 0FB0A7C8BD; Wed, 4 Dec 2002 10:42:36 +0100 (CET) Date: Wed, 04 Dec 2002 10:42:35 +0100 From: Juergen Quittek To: Rajeev K R , midcom@ietf.org Subject: Re: [midcom] PRR support Message-ID: <6481890.1038998555@[192.168.102.164]> In-Reply-To: <002501c29b40$301c79e0$8d084d0a@r70036> References: <002501c29b40$301c79e0$8d084d0a@r70036> 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 Rajeev, Thank you for reading the draft and commenting it! Yes, you are right, the example would not work without PRR. It was intentionally chosen to (also) show the need for PRR. However, there are many scenarios that work well with just PER. Therefore, we labeled PRR as optional. But the reasons for this decision are not very strong. Do you suggest to move PRR from optional to mandatory? Juergen -- Rajeev K R wrote on 04 December 2002 10:52 +0800: > Hi, > > The example flow shown in draft-ietf-midcom-semantics-00.txt requires a PRR. > But PRR is optional for a middle box. > So how can the MIDCOM agent realise this call if the middlebox does not > support PRR ? > > (In case this is already answered in the list please forward me some of the > relevant mails...) > > Regards, > Rajeev > > > _______________________________________________ > 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 Dec 4 07:33: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 HAA07574 for ; Wed, 4 Dec 2002 07:33:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4CZiQ13545 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 07:35:44 -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 gB4CZFv13531; Wed, 4 Dec 2002 07: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 gB4CYmv13508 for ; Wed, 4 Dec 2002 07:34:48 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07549 for ; Wed, 4 Dec 2002 07:31:55 -0500 (EST) Received: from r70036 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H6L004ZHHIXVW@mta0.huawei.com> for midcom@ietf.org; Wed, 04 Dec 2002 20:32:58 +0800 (CST) Date: Wed, 04 Dec 2002 20:37:35 +0800 From: Rajeev K R Subject: Re: [midcom] PRR support To: Juergen Quittek , midcom@ietf.org Message-id: <001301c29b91$ec526060$8d084d0a@r70036> 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: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002501c29b40$301c79e0$8d084d0a@r70036> <6481890.1038998555@[192.168.102.164]> 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 Juergen, Thanks for the response. In the example, the requirement from the midcom agent is that it should get an outside-IP address of the NAT to include in the SDP in the INVITE to be sent to user B. So it issues a PRR and get an outside-IP address reserved from NAT. As per the draft, this is required because if the call agent does not know the IP address of user B. Infect it knows the call signalling address of user B to which it should send the INVITE, but there is no guarantee that this IP address will be used for media transmission. So if PRR is not supported by the middle box this can be solved like this: The midcom agent first issue a PER with whatever IP address of user B as it knows and create a rule. use the outside-IP in the PER response to modify the SDP and send it out. When the 200 OK comes from user B , if the IP address in SDP is same as the call signalling address there is no issue. But if it is different, the call agent has to delete the existing rule and create a new rule with this IP address(remember-there is no way to modify a rule). But this flow does not seems very logical. You are creating a rule with some IP address which you are not very sure of, and later modifying the whole thing. This scenario is possible in case of media servers etc. which may use multiple network interfaces. I am looking forward for any other solution that you guys might have. So if we do not have PRR support, it makes the call flow possibly more complex. For me it looks like PRR is a very logical way of starting up :- where you do not know much about the external entity and you start with reserving one outside-IP address in NAT and then creating rules around that. > Do you suggest to move PRR from optional to mandatory? Yes. I do. From my experience, the more "optional" items you have, the more complex the protocol becomes :) Regards, Rajeev ----- Original Message ----- From: "Juergen Quittek" To: "Rajeev K R" ; Sent: Wednesday, December 04, 2002 5:42 PM Subject: Re: [midcom] PRR support > Rajeev, > > Thank you for reading the draft and commenting it! > > Yes, you are right, the example would not work without PRR. > It was intentionally chosen to (also) show the need for PRR. > > However, there are many scenarios that work well with just PER. > Therefore, we labeled PRR as optional. But the reasons for this > decision are not very strong. > > Do you suggest to move PRR from optional to mandatory? > > Juergen > > > -- Rajeev K R wrote on 04 December 2002 10:52 +0800: > > > Hi, > > > > The example flow shown in draft-ietf-midcom-semantics-00.txt requires a PRR. > > But PRR is optional for a middle box. > > So how can the MIDCOM agent realise this call if the middlebox does not > > support PRR ? > > > > (In case this is already answered in the list please forward me some of the > > relevant mails...) > > > > Regards, > > Rajeev > > > > > > _______________________________________________ > > 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 Dec 4 10:03:37 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 KAA14895 for ; Wed, 4 Dec 2002 10:03:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4F5xr23129 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 10:05: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 gB4F2Ev22972; Wed, 4 Dec 2002 10:02:14 -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 gB4F1gv22946 for ; Wed, 4 Dec 2002 10:01:42 -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 JAA14558 for ; Wed, 4 Dec 2002 09:58:48 -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 gB4F1LF43667; Wed, 4 Dec 2002 16:01:21 +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 6402C67DE6; Wed, 4 Dec 2002 15:59:19 +0100 (CET) Date: Wed, 04 Dec 2002 15:59:19 +0100 From: Juergen Quittek To: Rajeev K R , midcom@ietf.org Subject: Semantics issue #8: PRR mandatory? (was: Re: [midcom] PRR support) Message-ID: <25485476.1039017559@[192.168.102.164]> In-Reply-To: <001301c29b91$ec526060$8d084d0a@r70036> References: <001301c29b91$ec526060$8d084d0a@r70036> 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 Rajeev, You propose to move the PRR transaction from optional to mandatory. I am not very determined whether to do this or not. Maybe there are more opinions out there? Let's discuss it as semantics issue #8: Summary: The PRR transaction reserves addresses at a middlebox without creating a pinhole or address binding. This is required for some typical SIP signaling scenarios. However, there are many scenarios where PRR is not necessary. Currently is is labeled in the semnatics document as an optional transaction. Therefore, some middleboxes may not work well in some SIP signalling scenarios. Proposal by Rajeev: move the PRR transaction from optional to mandatory Advantage: All SIP scenarios studied so far would work. Disadvantage: Implementation might be hard (or impossible?) for some NATs. Juergen Rajeev, please see some more commens in line below. -- Rajeev K R wrote on 04 December 2002 20:37 +0800: > Hi Juergen, > Thanks for the response. > > In the example, the requirement from the midcom agent is that it should get > an outside-IP address of the > NAT to include in the SDP in the INVITE to be sent to user B. > > So it issues a PRR and get an outside-IP address reserved from NAT. As per > the draft, this is required because if the call agent does not know the IP > address of user B. Infect it knows the call signalling address of user B to > which it should send the INVITE, but there is no guarantee that this IP > address will be used for media transmission. In general, this is not the address of B's terminal, but the address of the SIP server where B is registered. > So if PRR is not supported by the middle box this can be solved like this: > The midcom agent first issue a PER with whatever IP address of user B as it > knows and create a rule. use the outside-IP in the PER response to modify > the SDP and send it out. When the 200 OK comes from user B , if the IP > address in SDP is same as the call signalling address there is no issue. But > if it is different, the call agent has to delete the existing rule and > create a new rule with this IP address(remember-there is no way to modify a > rule). > But this flow does not seems very logical. You are creating a rule with some > IP address which you are not very sure of, and later modifying the whole > thing. This scenario is possible in case of media servers etc. which may use > multiple network interfaces. > I am looking forward for any other solution that you guys might have. We don't have another one. The solution is offering PRR. > So if we do not have PRR support, it makes the call flow possibly more > complex. > For me it looks like PRR is a very logical way of starting up :- where you > do not know much about the external entity and you start with reserving one > outside-IP address in NAT and then creating rules around that. > >> Do you suggest to move PRR from optional to mandatory? > Yes. I do. > > From my experience, the more "optional" items you have, the more complex the > protocol becomes :) > > Regards, > Rajeev > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Rajeev K R" ; > Sent: Wednesday, December 04, 2002 5:42 PM > Subject: Re: [midcom] PRR support > > >> Rajeev, >> >> Thank you for reading the draft and commenting it! >> >> Yes, you are right, the example would not work without PRR. >> It was intentionally chosen to (also) show the need for PRR. >> >> However, there are many scenarios that work well with just PER. >> Therefore, we labeled PRR as optional. But the reasons for this >> decision are not very strong. >> >> Do you suggest to move PRR from optional to mandatory? >> >> Juergen >> >> >> -- Rajeev K R wrote on 04 December 2002 10:52 +0800: >> >> > Hi, >> > >> > The example flow shown in draft-ietf-midcom-semantics-00.txt requires a > PRR. >> > But PRR is optional for a middle box. >> > So how can the MIDCOM agent realise this call if the middlebox does not >> > support PRR ? >> > >> > (In case this is already answered in the list please forward me some of > the >> > relevant mails...) >> > >> > Regards, >> > Rajeev >> > >> > >> > _______________________________________________ >> > 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 Dec 4 18:34: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 SAA10348 for ; Wed, 4 Dec 2002 18:34:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4NbG530235 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 18:37:16 -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 gB4NaUv29671; Wed, 4 Dec 2002 18:36:30 -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 gB4NZdv29643 for ; Wed, 4 Dec 2002 18:35:39 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10253 for ; Wed, 4 Dec 2002 18:32:42 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 18:35:31 -0500 Message-ID: <5001C86452603F41820378E167091F07EED955@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'midcom@ietf.org'" Subject: RE: [midcom] framework models, related architectures and protocol controversy Date: Wed, 4 Dec 2002 18:34:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Melinda, yes, I don't disagree with you, scenarios where a middlebox of some sort would have to be dynamically provisioned for a given TCP/RTP session are making VERY SPECIFIC assumptions about the IP topology. It looks to me that the only realistic scenarios are at a domain boundary, typically the point where a service provider provides IP services (e.g. a WAN uplink). Then, either on the service user side (e.g. a NAT/FW CPE device) or on the service provider side (e.g. a BRAS device), the topology is constrained enough that such scenario makes sense. This being said, such specific scenarios are so important to both service users and service providers that I believe it's really the pain working on such middlebox/dynamic-session-management stories. And as I pointed out, the whole picture involves filtering, NATting, firewalling and Qos differentiation. As to scaling, I hear the concern, but I'm not sure to entirely agree with you. There are solutions nowadays which can scale pretty well by the appropriate combinations of hardware & software. Finally, on the "protocol controversy" wording, I apologize if my wording was a bit too aggressive. I have to say I'm a bit tired of the endless discussion between SNMP, Diameter, COPS across multiple IETF work groups. I tend to believe that all these protocols have a role to play, and we'd better be flexible, and define MIBs, PIBs and Diameter attributes for multiple functional areas (ok, when this makes "reasonable" sense, of course, which is hard to define!), instead of spending too much time arguing in an often religious way. I hope that I'll not get a flame on this hopefully neutral statement... ;-) Ok, all this philosophy aside, I vote for Megaco for Midcom. Nah, just kidding. Tx Jerome > One of the unfortunate things that's happened in the IETF > over the past years is the drift away from architectural > frameworks that are idiomatic to IP - i.e. they interwork > with IP, particularly routing and topology, really, really > poorly. I personally think that midcom is one of these, but > even if we were to go to end-to-end, on-path signaling > there's a need to have application endpoints (or proxies, > another can of worms) communicate directly with various > sorts of individual middleboxes which may not be on a data > path (or cannot be "known" to be on one). > > The notion of having devices in the network make > determinations and push those out to the endpoints has the > smell of Bell about it. It's typically not something that > will work well in IP networks, where making network elements > visible to application endpoints can create a host of > problems, ranging from lack of robustness to inter-layer > duplication of function to inability to scale with the > number of endpoints. > > By the way, I don't think there is an "ongoing protocol > controversy." There's been very little discussion at all. > If there's lack of progress it's because of lack of input, > not because participants in the working group are at > loggerheads. > > 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 Dec 4 20:22: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 UAA13766 for ; Wed, 4 Dec 2002 20:22:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB51Ouj04181 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 20:24:56 -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 gB51LFv04086; Wed, 4 Dec 2002 20:21:17 -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 gB51KZv04052 for ; Wed, 4 Dec 2002 20:20:35 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13689 for ; Wed, 4 Dec 2002 20:17:35 -0500 (EST) Received: from r70036 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H6M009NBGZ1AS@mta0.huawei.com> for midcom@ietf.org; Thu, 05 Dec 2002 09:18:37 +0800 (CST) Date: Thu, 05 Dec 2002 09:23:16 +0800 From: Rajeev K R Subject: Re: Semantics issue #8: PRR mandatory? (was: Re: [midcom] PRR support) To: Juergen Quittek , midcom@ietf.org Message-id: <004501c29bfc$e307fa90$8d084d0a@r70036> 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: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <001301c29b91$ec526060$8d084d0a@r70036> <25485476.1039017559@[192.168.102.164]> 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 Juergen, Please see my comments inline, Rajeev ----- Original Message ----- From: "Juergen Quittek" To: "Rajeev K R" ; Sent: Wednesday, December 04, 2002 10:59 PM Subject: Semantics issue #8: PRR mandatory? (was: Re: [midcom] PRR support) > Rajeev, > > You propose to move the PRR transaction from optional to mandatory. > I am not very determined whether to do this or not. > Maybe there are more opinions out there? > Let's discuss it as semantics issue #8: > > Summary: The PRR transaction reserves addresses at a middlebox without > creating a pinhole or address binding. This is required for some typical > SIP signaling scenarios. However, there are many scenarios where PRR > is not necessary. Currently is is labeled in the semnatics document as > an optional transaction. Therefore, some middleboxes may not work well > in some SIP signalling scenarios. > The example taken was SIP. But the same situation would be there for H323, MGCP or Megaco. So let us take it as an issue not specific to SIP, but related to all VOIP protocols. > Proposal by Rajeev: move the PRR transaction from optional to mandatory > > Advantage: All SIP scenarios studied so far would work. > Disadvantage: Implementation might be hard (or impossible?) for some NATs. > > Juergen > > Rajeev, please see some more commens in line below. > > > -- Rajeev K R wrote on 04 December 2002 20:37 +0800: > > > Hi Juergen, > > Thanks for the response. > > > > In the example, the requirement from the midcom agent is that it should get > > an outside-IP address of the > > NAT to include in the SDP in the INVITE to be sent to user B. > > > > So it issues a PRR and get an outside-IP address reserved from NAT. As per > > the draft, this is required because if the call agent does not know the IP > > address of user B. Infect it knows the call signalling address of user B to > > which it should send the INVITE, but there is no guarantee that this IP > > address will be used for media transmission. > > In general, this is not the address of B's terminal, > but the address of the SIP server where B is registered. > > > So if PRR is not supported by the middle box this can be solved like this: > > The midcom agent first issue a PER with whatever IP address of user B as it > > knows and create a rule. use the outside-IP in the PER response to modify > > the SDP and send it out. When the 200 OK comes from user B , if the IP > > address in SDP is same as the call signalling address there is no issue. But > > if it is different, the call agent has to delete the existing rule and > > create a new rule with this IP address(remember-there is no way to modify a > > rule). > > But this flow does not seems very logical. You are creating a rule with some > > IP address which you are not very sure of, and later modifying the whole > > thing. This scenario is possible in case of media servers etc. which may use > > multiple network interfaces. > > I am looking forward for any other solution that you guys might have. > > We don't have another one. The solution is offering PRR. > > > So if we do not have PRR support, it makes the call flow possibly more > > complex. > > For me it looks like PRR is a very logical way of starting up :- where you > > do not know much about the external entity and you start with reserving one > > outside-IP address in NAT and then creating rules around that. > > > >> Do you suggest to move PRR from optional to mandatory? > > Yes. I do. > > > > From my experience, the more "optional" items you have, the more complex the > > protocol becomes :) > > > > Regards, > > Rajeev > > > > ----- Original Message ----- > > From: "Juergen Quittek" > > To: "Rajeev K R" ; > > Sent: Wednesday, December 04, 2002 5:42 PM > > Subject: Re: [midcom] PRR support > > > > > >> Rajeev, > >> > >> Thank you for reading the draft and commenting it! > >> > >> Yes, you are right, the example would not work without PRR. > >> It was intentionally chosen to (also) show the need for PRR. > >> > >> However, there are many scenarios that work well with just PER. > >> Therefore, we labeled PRR as optional. But the reasons for this > >> decision are not very strong. > >> > >> Do you suggest to move PRR from optional to mandatory? > >> > >> Juergen > >> > >> > >> -- Rajeev K R wrote on 04 December 2002 10:52 +0800: > >> > >> > Hi, > >> > > >> > The example flow shown in draft-ietf-midcom-semantics-00.txt requires a > > PRR. > >> > But PRR is optional for a middle box. > >> > So how can the MIDCOM agent realise this call if the middlebox does not > >> > support PRR ? > >> > > >> > (In case this is already answered in the list please forward me some of > > the > >> > relevant mails...) > >> > > >> > Regards, > >> > Rajeev > >> > > >> > > >> > _______________________________________________ > >> > 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 Dec 4 22:30:26 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 WAA17571 for ; Wed, 4 Dec 2002 22:30:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB53Wt611591 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 22:32: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 gB53TGv11486; Wed, 4 Dec 2002 22:29: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 gB53SEv11457 for ; Wed, 4 Dec 2002 22:28:14 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17429 for ; Wed, 4 Dec 2002 22:25:13 -0500 (EST) Received: from m19684 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H6M009J3MVQAS@mta0.huawei.com> for midcom@ietf.org; Thu, 05 Dec 2002 11:26:16 +0800 (CST) Date: Thu, 05 Dec 2002 11:29:01 +0800 From: Miao Fuyou Subject: RE: [midcom] Midcom proposal: please read In-reply-to: <20486067.1038939163@[192.168.102.164]> To: midcom@ietf.org Message-id: <000001c29c0e$74ad8800$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB53SFv11458 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 If we consider SNMP overall£¨regardless v1, v2 or v3£©as a protocol, I believe nobody would disagree that it's a widely deployed one. Actually v3 shares so many features with v1 or v2, which are definitely widely deployed. What is more, the philosophy and primary architecture behide them are leave unchanged when it evolved. So, I think we should evaluate the effect of v1/v2 popularity to v3 intead of v3 alone. BTW, I am new to the WG, the sentences above don't imply any preference. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, December 04, 2002 1:13 AM To: Jerome Moisand; midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read Jerome, -- Jerome Moisand wrote on 27 November 2002 10:16 -0500: > Juergen, > > I was just saying that choosing SNMPv3 because it's "widely deployed" > isn't a convincing argument at all. That's correct. > I was not making a case for choosing this protocol or against it, I do > see multiple Pros & Cons for SNMPv3 (and the others). Agreed. > I just wanted to express the opinion that we shouldn't shortcut the > decision-making process. I would like to shortcut it, but only with good arguments. > (see below a few more details for clarification, but not really adding > much to my points). > > Tx > Jerome > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Jerome Moisand" > Cc: ; "Melinda Shore" > Sent: Wednesday, November 27, 2002 9:31 AM > Subject: Re: [midcom] Midcom proposal: please read > > >> Hi Jerome, >> >> I am also not sure whether or not SNMP would be a good choice for >> MIDCOM. But your arguments confused me. Do you want to say >> "everything else would be better? Or do you see a good candidate, you >> would prefer? >> >> Please see some more comments inline. > > => and my answers > >> >> Juergen >> >> > Hello, >> > >> > I'm new to this list, so apologies in advance if I might repeat >> > what > other >> > people already stated. >> > >> > If I remember well, the main point made during the midcom session >> > about shorcutting the protocol selection process was that SNMP is >> > way more > widely >> > implemented than other protocol candidates. >> > >> > I am not sure to see the value of this point. >> > >> > First, SNMP is definitely widely implemented, but essentially for > monitoring >> > purposes (alarms & stats). It seems a big stretch to say that SNMP >> > is > widely >> > implemented for provisioning & for authorization, where protocols >> > like > CLI >> >> Yes, CLI is really most widely implemented as configuration protocol. >> But this is not at all a protocol (maybe it is 1000 protocols :-). > > => I facetiously referred to CLI as a protocol, knowing well that many > people will balk at this terminology! ;-) => Yes, we're in complete > agreement here. > >> > and Radius are by far the most widely deployed. Also SNMPv1 and to >> > a > lesser >> > extent SNMPv2 are widely used, but it also seems a big stretch to >> > say > that >> > SNMPv3 is widely implemented. Just look at the largest router > manufacturer >> > general strategy in this respect... >> > >> > Second, the fact that a protocol is widely implemented doesn't make >> > it suitable for all purposes. Both Diameter and COPS have been >> > designed to >> >> First you compare SNMPv3 to CLI and say its much less widely used. >> This is completely right, but not useful at all. Now you compare it >> to COPS and Diameter. Compared to Diameter (and probably also COPS), >> SNMPv3 is indeed widely used. > > => everything is relative, but all in all, none of the proposed > candidates (SNMPv3 for provisioning, Diameter, COPS) is widely used > yet, far from it. By either Network Elements, or OSS systems. Or let's > say, not to a point where it should become a significant factor in our > decision-making. These three protocols clearly remain to be proven on > the field. This is only my perception, of course (probably tainted by > the fact that I know well Service Providers environments, but less > enterprise networking). Maybe there is an argument, that SNMP is the protocol which is most likely to be implemented on a managed box anyway. And in the future, I expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3. > >> > allow better processing for transaction-oriented policy decisions >> > (which > is >> > exactly what midcom is about, I believe). Both protocols were >> > intended > to >> > address such situations that SNMP and Radius were not good at. If >> > it > were >> >> Please exlain! How is COPS addressing the "mutliple clients >> configuring a single server while addressing the same (kind of) >> resources)" situation? I would say: not at all. > > => this is another thread of discussion. I did hear Melinda express > reservations on this point, but this deserves a separate e-mail > thread. I'll come back on this, as well as the transaction aspect of > midcom (where I think SNMPv3 has a big issue). > > => maybe somebody would be kind enough to copy & paste some previous > e-mail thread on this topic, and forward it to me? Just to not making > you guys repeat yourselves? I'll do so. >> > not the case, why did IETF spend so much time working on these two >> > new protocols? Also note that the mere fact that these protocols >> > have been recently defined makes it obvious that they are not yet >> > widely > implemented. >> > So? Should we never use next-gen protocols on this basis? I don't > believe >> > so. >> >> I cannot follow your argument. We are using a lot of very recent > protocols, >> but do we have to choose them always, just because the are new? If >> COPS-PR is not even widely used in it's original domain, policy-based > configuration, >> yet, then why should I already consider using it for other purposes >> for > which >> it was not really designed. The situation would certainly be >> different, if COPS was already implemented widely for policy-based >> configuration of > devices. >> But since it is not (and I personally see it coming soon, why should >> I > choose >> it? Because it is 'next-gen'? > > => funny the way you took the direct negation of my statement! You're > saying we should NOT *always* use recent protocols just because they > are recent. I was just saying that we should NOT *always* use old > protocols (or new flavors of an old protocol) just because they are > 'old' (hence 'proven') and have been widely used for a completly > different application (e.g. monitoring). Well, both statements are > fair, I believe! agreed. > => maybe I don't fully understand yet what midcom is about, but I do > see this as a dynamic policy management problem with transactional > properties. So it only seems natural to look at policy management > protocols. Which the group rightfully did, without jumping to hasty > conclusions. All this sounds fair to me. But suddenly shortcutting > such process based on a very debatable point, that, I have to disagree > with. > >> > >> > Bottomline: I wouldn't understand why such a "decision shortcut" >> > would > be >> > used on the basis of this "wide implementation" argument, which >> > doesn't > seem >> > (to me) to hold much water. I believe the "midcom" group needs to >> > find a better rationale (and process) for making such decision. >> >> On this point, I fully agree with you! > > => hey, we did agree on a couple of things, great! ;-) > >> > >> > Tx >> > Jerome Moisand (Juniper Networks) >> > >> > > Melinda Shore wrote: >> > > >> > > > There was a proposal made during the midcom session at the IETF >> > > > meeting to shortcut the protocol selection process and just go >> > > > with SNMPv3 as the midcom protocol. Consistent with IETF >> > > > process, this is a decision to be made on the mailing list. >> > > > I'd like to come to a decision within the next week or so >> > > > (Thursday is Thanksgiving in the US and many people may be away >> > > > this week). >> > > > >> > > > 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 >> > >> -- > > _______________________________________________ > 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 Dec 4 22:45: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 WAA18366 for ; Wed, 4 Dec 2002 22:45:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB53la912754 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 22:47:36 -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 gB53l8v12746; Wed, 4 Dec 2002 22:47: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 gB53kbv12718 for ; Wed, 4 Dec 2002 22:46:37 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18353 for ; Wed, 4 Dec 2002 22:43:36 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H6M00JE7NT5JB@firewall.wcom.com> for midcom@ietf.org; Thu, 05 Dec 2002 03:46:17 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H6M00501NT43E@dgismtp05.wcomnet.com>; Thu, 05 Dec 2002 03:46:16 +0000 (GMT) Received: from ws041v4569 ([166.50.112.142]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H6M0045ZNT25O@dgismtp05.wcomnet.com>; Thu, 05 Dec 2002 03:46:16 +0000 (GMT) Date: Wed, 04 Dec 2002 21:46:29 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] Midcom proposal: please read In-reply-to: <000001c29c0e$74ad8800$2e426e0a@HUAWEI.COM> To: "'Miao Fuyou'" , midcom@ietf.org Message-id: <001601c29c10$e58edc70$9a00a8c0@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-2022-jp Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB53kbv12719 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 Hi all, sorry I'm late on the thread as usual, I agree with SNMP v3 as a potential protocol for this purpose but am not sure that I agree with the comments about popularity of the earlier versions ot v3 mentioned below, since I am concerned with security of midcom implemtation wrt the choice between v1/v2 and v3. I don$B!G(Bt think that the first two are valid for reasons of message integrity of the protocol signaling. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Miao Fuyou Sent: Wednesday, December 04, 2002 9:29 PM To: midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read If we consider SNMP overall$B!J(Bregardless v1, v2 or v3$B!K(Bas a protocol, I believe nobody would disagree that it's a widely deployed one. Actually v3 shares so many features with v1 or v2, which are definitely widely deployed. What is more, the philosophy and primary architecture behide them are leave unchanged when it evolved. So, I think we should evaluate the effect of v1/v2 popularity to v3 intead of v3 alone. BTW, I am new to the WG, the sentences above don't imply any preference. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, December 04, 2002 1:13 AM To: Jerome Moisand; midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read Jerome, -- Jerome Moisand wrote on 27 November 2002 10:16 -0500: > Juergen, > > I was just saying that choosing SNMPv3 because it's "widely deployed" > isn't a convincing argument at all. That's correct. > I was not making a case for choosing this protocol or against it, I do > see multiple Pros & Cons for SNMPv3 (and the others). Agreed. > I just wanted to express the opinion that we shouldn't shortcut the > decision-making process. I would like to shortcut it, but only with good arguments. > (see below a few more details for clarification, but not really adding > much to my points). > > Tx > Jerome > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Jerome Moisand" > Cc: ; "Melinda Shore" > Sent: Wednesday, November 27, 2002 9:31 AM > Subject: Re: [midcom] Midcom proposal: please read > > >> Hi Jerome, >> >> I am also not sure whether or not SNMP would be a good choice for >> MIDCOM. But your arguments confused me. Do you want to say >> "everything else would be better? Or do you see a good candidate, you >> would prefer? >> >> Please see some more comments inline. > > => and my answers > >> >> Juergen >> >> > Hello, >> > >> > I'm new to this list, so apologies in advance if I might repeat >> > what > other >> > people already stated. >> > >> > If I remember well, the main point made during the midcom session >> > about shorcutting the protocol selection process was that SNMP is >> > way more > widely >> > implemented than other protocol candidates. >> > >> > I am not sure to see the value of this point. >> > >> > First, SNMP is definitely widely implemented, but essentially for > monitoring >> > purposes (alarms & stats). It seems a big stretch to say that SNMP >> > is > widely >> > implemented for provisioning & for authorization, where protocols >> > like > CLI >> >> Yes, CLI is really most widely implemented as configuration protocol. >> But this is not at all a protocol (maybe it is 1000 protocols :-). > > => I facetiously referred to CLI as a protocol, knowing well that many > people will balk at this terminology! ;-) => Yes, we're in complete > agreement here. > >> > and Radius are by far the most widely deployed. Also SNMPv1 and to >> > a > lesser >> > extent SNMPv2 are widely used, but it also seems a big stretch to >> > say > that >> > SNMPv3 is widely implemented. Just look at the largest router > manufacturer >> > general strategy in this respect... >> > >> > Second, the fact that a protocol is widely implemented doesn't make >> > it suitable for all purposes. Both Diameter and COPS have been >> > designed to >> >> First you compare SNMPv3 to CLI and say its much less widely used. >> This is completely right, but not useful at all. Now you compare it >> to COPS and Diameter. Compared to Diameter (and probably also COPS), >> SNMPv3 is indeed widely used. > > => everything is relative, but all in all, none of the proposed > candidates (SNMPv3 for provisioning, Diameter, COPS) is widely used > yet, far from it. By either Network Elements, or OSS systems. Or let's > say, not to a point where it should become a significant factor in our > decision-making. These three protocols clearly remain to be proven on > the field. This is only my perception, of course (probably tainted by > the fact that I know well Service Providers environments, but less > enterprise networking). Maybe there is an argument, that SNMP is the protocol which is most likely to be implemented on a managed box anyway. And in the future, I expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3. > >> > allow better processing for transaction-oriented policy decisions >> > (which > is >> > exactly what midcom is about, I believe). Both protocols were >> > intended > to >> > address such situations that SNMP and Radius were not good at. If >> > it > were >> >> Please exlain! How is COPS addressing the "mutliple clients >> configuring a single server while addressing the same (kind of) >> resources)" situation? I would say: not at all. > > => this is another thread of discussion. I did hear Melinda express > reservations on this point, but this deserves a separate e-mail > thread. I'll come back on this, as well as the transaction aspect of > midcom (where I think SNMPv3 has a big issue). > > => maybe somebody would be kind enough to copy & paste some previous > e-mail thread on this topic, and forward it to me? Just to not making > you guys repeat yourselves? I'll do so. >> > not the case, why did IETF spend so much time working on these two >> > new protocols? Also note that the mere fact that these protocols >> > have been recently defined makes it obvious that they are not yet >> > widely > implemented. >> > So? Should we never use next-gen protocols on this basis? I don't > believe >> > so. >> >> I cannot follow your argument. We are using a lot of very recent > protocols, >> but do we have to choose them always, just because the are new? If >> COPS-PR is not even widely used in it's original domain, policy-based > configuration, >> yet, then why should I already consider using it for other purposes >> for > which >> it was not really designed. The situation would certainly be >> different, if COPS was already implemented widely for policy-based >> configuration of > devices. >> But since it is not (and I personally see it coming soon, why should >> I > choose >> it? Because it is 'next-gen'? > > => funny the way you took the direct negation of my statement! You're > saying we should NOT *always* use recent protocols just because they > are recent. I was just saying that we should NOT *always* use old > protocols (or new flavors of an old protocol) just because they are > 'old' (hence 'proven') and have been widely used for a completly > different application (e.g. monitoring). Well, both statements are > fair, I believe! agreed. > => maybe I don't fully understand yet what midcom is about, but I do > see this as a dynamic policy management problem with transactional > properties. So it only seems natural to look at policy management > protocols. Which the group rightfully did, without jumping to hasty > conclusions. All this sounds fair to me. But suddenly shortcutting > such process based on a very debatable point, that, I have to disagree > with. > >> > >> > Bottomline: I wouldn't understand why such a "decision shortcut" >> > would > be >> > used on the basis of this "wide implementation" argument, which >> > doesn't > seem >> > (to me) to hold much water. I believe the "midcom" group needs to >> > find a better rationale (and process) for making such decision. >> >> On this point, I fully agree with you! > > => hey, we did agree on a couple of things, great! ;-) > >> > >> > Tx >> > Jerome Moisand (Juniper Networks) >> > >> > > Melinda Shore wrote: >> > > >> > > > There was a proposal made during the midcom session at the IETF >> > > > meeting to shortcut the protocol selection process and just go >> > > > with SNMPv3 as the midcom protocol. Consistent with IETF >> > > > process, this is a decision to be made on the mailing list. >> > > > I'd like to come to a decision within the next week or so >> > > > (Thursday is Thanksgiving in the US and many people may be away >> > > > this week). >> > > > >> > > > 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 >> > >> -- > > _______________________________________________ > 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 Wed Dec 4 22:54: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 WAA18623 for ; Wed, 4 Dec 2002 22:54:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB53ujK13035 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 22: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 gB53r6v12882; Wed, 4 Dec 2002 22:53: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 gB53qcv12858 for ; Wed, 4 Dec 2002 22:52:38 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18465 for ; Wed, 4 Dec 2002 22:49:35 -0500 (EST) Received: from m19684 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H6M009P8O0IAS@mta0.huawei.com> for midcom@ietf.org; Thu, 05 Dec 2002 11:50:44 +0800 (CST) Date: Thu, 05 Dec 2002 11:53:29 +0800 From: Miao Fuyou Subject: RE: [midcom] Midcom proposal: please read In-reply-to: <001601c29c10$e58edc70$9a00a8c0@ws041v4569> To: "'Christopher A. Martin'" Cc: midcom@ietf.org Message-id: <000101c29c11$df81d480$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB53qcv12859 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 Hi, Chris I don't mean v1 or v2 can adapt midcom context, but please consider: if a developer is familiar with v1/v2 he/she can understand SNMPv3 easily, which will help midcom implementation. Regards Miao -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Thursday, December 05, 2002 11:46 AM To: 'Miao Fuyou'; midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read Hi all, sorry I'm late on the thread as usual, I agree with SNMP v3 as a potential protocol for this purpose but am not sure that I agree with the comments about popularity of the earlier versions ot v3 mentioned below, since I am concerned with security of midcom implemtation wrt the choice between v1/v2 and v3. I don¡¯t think that the first two are valid for reasons of message integrity of the protocol signaling. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Miao Fuyou Sent: Wednesday, December 04, 2002 9:29 PM To: midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read If we consider SNMP overall£¨regardless v1, v2 or v3£©as a protocol, I believe nobody would disagree that it's a widely deployed one. Actually v3 shares so many features with v1 or v2, which are definitely widely deployed. What is more, the philosophy and primary architecture behide them are leave unchanged when it evolved. So, I think we should evaluate the effect of v1/v2 popularity to v3 intead of v3 alone. BTW, I am new to the WG, the sentences above don't imply any preference. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, December 04, 2002 1:13 AM To: Jerome Moisand; midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read Jerome, -- Jerome Moisand wrote on 27 November 2002 10:16 -0500: > Juergen, > > I was just saying that choosing SNMPv3 because it's "widely deployed" > isn't a convincing argument at all. That's correct. > I was not making a case for choosing this protocol or against it, I do > see multiple Pros & Cons for SNMPv3 (and the others). Agreed. > I just wanted to express the opinion that we shouldn't shortcut the > decision-making process. I would like to shortcut it, but only with good arguments. > (see below a few more details for clarification, but not really adding > much to my points). > > Tx > Jerome > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Jerome Moisand" > Cc: ; "Melinda Shore" > Sent: Wednesday, November 27, 2002 9:31 AM > Subject: Re: [midcom] Midcom proposal: please read > > >> Hi Jerome, >> >> I am also not sure whether or not SNMP would be a good choice for >> MIDCOM. But your arguments confused me. Do you want to say >> "everything else would be better? Or do you see a good candidate, you >> would prefer? >> >> Please see some more comments inline. > > => and my answers > >> >> Juergen >> >> > Hello, >> > >> > I'm new to this list, so apologies in advance if I might repeat >> > what > other >> > people already stated. >> > >> > If I remember well, the main point made during the midcom session >> > about shorcutting the protocol selection process was that SNMP is >> > way more > widely >> > implemented than other protocol candidates. >> > >> > I am not sure to see the value of this point. >> > >> > First, SNMP is definitely widely implemented, but essentially for > monitoring >> > purposes (alarms & stats). It seems a big stretch to say that SNMP >> > is > widely >> > implemented for provisioning & for authorization, where protocols >> > like > CLI >> >> Yes, CLI is really most widely implemented as configuration protocol. >> But this is not at all a protocol (maybe it is 1000 protocols :-). > > => I facetiously referred to CLI as a protocol, knowing well that many > people will balk at this terminology! ;-) => Yes, we're in complete > agreement here. > >> > and Radius are by far the most widely deployed. Also SNMPv1 and to >> > a > lesser >> > extent SNMPv2 are widely used, but it also seems a big stretch to >> > say > that >> > SNMPv3 is widely implemented. Just look at the largest router > manufacturer >> > general strategy in this respect... >> > >> > Second, the fact that a protocol is widely implemented doesn't make >> > it suitable for all purposes. Both Diameter and COPS have been >> > designed to >> >> First you compare SNMPv3 to CLI and say its much less widely used. >> This is completely right, but not useful at all. Now you compare it >> to COPS and Diameter. Compared to Diameter (and probably also COPS), >> SNMPv3 is indeed widely used. > > => everything is relative, but all in all, none of the proposed > candidates (SNMPv3 for provisioning, Diameter, COPS) is widely used > yet, far from it. By either Network Elements, or OSS systems. Or let's > say, not to a point where it should become a significant factor in our > decision-making. These three protocols clearly remain to be proven on > the field. This is only my perception, of course (probably tainted by > the fact that I know well Service Providers environments, but less > enterprise networking). Maybe there is an argument, that SNMP is the protocol which is most likely to be implemented on a managed box anyway. And in the future, I expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3. > >> > allow better processing for transaction-oriented policy decisions >> > (which > is >> > exactly what midcom is about, I believe). Both protocols were >> > intended > to >> > address such situations that SNMP and Radius were not good at. If >> > it > were >> >> Please exlain! How is COPS addressing the "mutliple clients >> configuring a single server while addressing the same (kind of) >> resources)" situation? I would say: not at all. > > => this is another thread of discussion. I did hear Melinda express > reservations on this point, but this deserves a separate e-mail > thread. I'll come back on this, as well as the transaction aspect of > midcom (where I think SNMPv3 has a big issue). > > => maybe somebody would be kind enough to copy & paste some previous > e-mail thread on this topic, and forward it to me? Just to not making > you guys repeat yourselves? I'll do so. >> > not the case, why did IETF spend so much time working on these two >> > new protocols? Also note that the mere fact that these protocols >> > have been recently defined makes it obvious that they are not yet >> > widely > implemented. >> > So? Should we never use next-gen protocols on this basis? I don't > believe >> > so. >> >> I cannot follow your argument. We are using a lot of very recent > protocols, >> but do we have to choose them always, just because the are new? If >> COPS-PR is not even widely used in it's original domain, policy-based > configuration, >> yet, then why should I already consider using it for other purposes >> for > which >> it was not really designed. The situation would certainly be >> different, if COPS was already implemented widely for policy-based >> configuration of > devices. >> But since it is not (and I personally see it coming soon, why should >> I > choose >> it? Because it is 'next-gen'? > > => funny the way you took the direct negation of my statement! You're > saying we should NOT *always* use recent protocols just because they > are recent. I was just saying that we should NOT *always* use old > protocols (or new flavors of an old protocol) just because they are > 'old' (hence 'proven') and have been widely used for a completly > different application (e.g. monitoring). Well, both statements are > fair, I believe! agreed. > => maybe I don't fully understand yet what midcom is about, but I do > see this as a dynamic policy management problem with transactional > properties. So it only seems natural to look at policy management > protocols. Which the group rightfully did, without jumping to hasty > conclusions. All this sounds fair to me. But suddenly shortcutting > such process based on a very debatable point, that, I have to disagree > with. > >> > >> > Bottomline: I wouldn't understand why such a "decision shortcut" >> > would > be >> > used on the basis of this "wide implementation" argument, which >> > doesn't > seem >> > (to me) to hold much water. I believe the "midcom" group needs to >> > find a better rationale (and process) for making such decision. >> >> On this point, I fully agree with you! > > => hey, we did agree on a couple of things, great! ;-) > >> > >> > Tx >> > Jerome Moisand (Juniper Networks) >> > >> > > Melinda Shore wrote: >> > > >> > > > There was a proposal made during the midcom session at the IETF >> > > > meeting to shortcut the protocol selection process and just go >> > > > with SNMPv3 as the midcom protocol. Consistent with IETF >> > > > process, this is a decision to be made on the mailing list. >> > > > I'd like to come to a decision within the next week or so >> > > > (Thursday is Thanksgiving in the US and many people may be away >> > > > this week). >> > > > >> > > > 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 >> > >> -- > > _______________________________________________ > 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 Wed Dec 4 23:25: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 XAA19333 for ; Wed, 4 Dec 2002 23:25:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB54S4x14808 for midcom-archive@odin.ietf.org; Wed, 4 Dec 2002 23:28:04 -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 gB54NFv14612; Wed, 4 Dec 2002 23:23: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 gB54MBv14588 for ; Wed, 4 Dec 2002 23:22:11 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19169 for ; Wed, 4 Dec 2002 23:19:10 -0500 (EST) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H6M00L5PPGEZ7@firewall.wcom.com> for midcom@ietf.org; Thu, 05 Dec 2002 04:21:50 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H6M00101PGDBO@dgismtp02.wcomnet.com>; Thu, 05 Dec 2002 04:21:50 +0000 (GMT) Received: from ws041v4569 ([166.50.112.142]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H6M00113PGC5Q@dgismtp02.wcomnet.com>; Thu, 05 Dec 2002 04:21:49 +0000 (GMT) Date: Wed, 04 Dec 2002 22:22:02 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] Midcom proposal: please read In-reply-to: <000101c29c11$df81d480$2e426e0a@HUAWEI.COM> To: "'Miao Fuyou'" Cc: midcom@ietf.org Message-id: <000201c29c15$dcec86d0$9a00a8c0@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-2022-jp Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB54MBv14589 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 Ahh, totally agree, wont feel foreign at all to many individuals. :^) Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Miao Fuyou Sent: Wednesday, December 04, 2002 9:53 PM To: 'Christopher A. Martin' Cc: midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read Hi, Chris I don't mean v1 or v2 can adapt midcom context, but please consider: if a developer is familiar with v1/v2 he/she can understand SNMPv3 easily, which will help midcom implementation. Regards Miao -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Thursday, December 05, 2002 11:46 AM To: 'Miao Fuyou'; midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read Hi all, sorry I'm late on the thread as usual, I agree with SNMP v3 as a potential protocol for this purpose but am not sure that I agree with the comments about popularity of the earlier versions ot v3 mentioned below, since I am concerned with security of midcom implemtation wrt the choice between v1/v2 and v3. I don$B!G(Bt think that the first two are valid for reasons of message integrity of the protocol signaling. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Miao Fuyou Sent: Wednesday, December 04, 2002 9:29 PM To: midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read If we consider SNMP overall$B!J(Bregardless v1, v2 or v3$B!K(Bas a protocol, I believe nobody would disagree that it's a widely deployed one. Actually v3 shares so many features with v1 or v2, which are definitely widely deployed. What is more, the philosophy and primary architecture behide them are leave unchanged when it evolved. So, I think we should evaluate the effect of v1/v2 popularity to v3 intead of v3 alone. BTW, I am new to the WG, the sentences above don't imply any preference. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, December 04, 2002 1:13 AM To: Jerome Moisand; midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read Jerome, -- Jerome Moisand wrote on 27 November 2002 10:16 -0500: > Juergen, > > I was just saying that choosing SNMPv3 because it's "widely deployed" > isn't a convincing argument at all. That's correct. > I was not making a case for choosing this protocol or against it, I do > see multiple Pros & Cons for SNMPv3 (and the others). Agreed. > I just wanted to express the opinion that we shouldn't shortcut the > decision-making process. I would like to shortcut it, but only with good arguments. > (see below a few more details for clarification, but not really adding > much to my points). > > Tx > Jerome > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Jerome Moisand" > Cc: ; "Melinda Shore" > Sent: Wednesday, November 27, 2002 9:31 AM > Subject: Re: [midcom] Midcom proposal: please read > > >> Hi Jerome, >> >> I am also not sure whether or not SNMP would be a good choice for >> MIDCOM. But your arguments confused me. Do you want to say >> "everything else would be better? Or do you see a good candidate, you >> would prefer? >> >> Please see some more comments inline. > > => and my answers > >> >> Juergen >> >> > Hello, >> > >> > I'm new to this list, so apologies in advance if I might repeat >> > what > other >> > people already stated. >> > >> > If I remember well, the main point made during the midcom session >> > about shorcutting the protocol selection process was that SNMP is >> > way more > widely >> > implemented than other protocol candidates. >> > >> > I am not sure to see the value of this point. >> > >> > First, SNMP is definitely widely implemented, but essentially for > monitoring >> > purposes (alarms & stats). It seems a big stretch to say that SNMP >> > is > widely >> > implemented for provisioning & for authorization, where protocols >> > like > CLI >> >> Yes, CLI is really most widely implemented as configuration protocol. >> But this is not at all a protocol (maybe it is 1000 protocols :-). > > => I facetiously referred to CLI as a protocol, knowing well that many > people will balk at this terminology! ;-) => Yes, we're in complete > agreement here. > >> > and Radius are by far the most widely deployed. Also SNMPv1 and to >> > a > lesser >> > extent SNMPv2 are widely used, but it also seems a big stretch to >> > say > that >> > SNMPv3 is widely implemented. Just look at the largest router > manufacturer >> > general strategy in this respect... >> > >> > Second, the fact that a protocol is widely implemented doesn't make >> > it suitable for all purposes. Both Diameter and COPS have been >> > designed to >> >> First you compare SNMPv3 to CLI and say its much less widely used. >> This is completely right, but not useful at all. Now you compare it >> to COPS and Diameter. Compared to Diameter (and probably also COPS), >> SNMPv3 is indeed widely used. > > => everything is relative, but all in all, none of the proposed > candidates (SNMPv3 for provisioning, Diameter, COPS) is widely used > yet, far from it. By either Network Elements, or OSS systems. Or let's > say, not to a point where it should become a significant factor in our > decision-making. These three protocols clearly remain to be proven on > the field. This is only my perception, of course (probably tainted by > the fact that I know well Service Providers environments, but less > enterprise networking). Maybe there is an argument, that SNMP is the protocol which is most likely to be implemented on a managed box anyway. And in the future, I expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3. > >> > allow better processing for transaction-oriented policy decisions >> > (which > is >> > exactly what midcom is about, I believe). Both protocols were >> > intended > to >> > address such situations that SNMP and Radius were not good at. If >> > it > were >> >> Please exlain! How is COPS addressing the "mutliple clients >> configuring a single server while addressing the same (kind of) >> resources)" situation? I would say: not at all. > > => this is another thread of discussion. I did hear Melinda express > reservations on this point, but this deserves a separate e-mail > thread. I'll come back on this, as well as the transaction aspect of > midcom (where I think SNMPv3 has a big issue). > > => maybe somebody would be kind enough to copy & paste some previous > e-mail thread on this topic, and forward it to me? Just to not making > you guys repeat yourselves? I'll do so. >> > not the case, why did IETF spend so much time working on these two >> > new protocols? Also note that the mere fact that these protocols >> > have been recently defined makes it obvious that they are not yet >> > widely > implemented. >> > So? Should we never use next-gen protocols on this basis? I don't > believe >> > so. >> >> I cannot follow your argument. We are using a lot of very recent > protocols, >> but do we have to choose them always, just because the are new? If >> COPS-PR is not even widely used in it's original domain, policy-based > configuration, >> yet, then why should I already consider using it for other purposes >> for > which >> it was not really designed. The situation would certainly be >> different, if COPS was already implemented widely for policy-based >> configuration of > devices. >> But since it is not (and I personally see it coming soon, why should >> I > choose >> it? Because it is 'next-gen'? > > => funny the way you took the direct negation of my statement! You're > saying we should NOT *always* use recent protocols just because they > are recent. I was just saying that we should NOT *always* use old > protocols (or new flavors of an old protocol) just because they are > 'old' (hence 'proven') and have been widely used for a completly > different application (e.g. monitoring). Well, both statements are > fair, I believe! agreed. > => maybe I don't fully understand yet what midcom is about, but I do > see this as a dynamic policy management problem with transactional > properties. So it only seems natural to look at policy management > protocols. Which the group rightfully did, without jumping to hasty > conclusions. All this sounds fair to me. But suddenly shortcutting > such process based on a very debatable point, that, I have to disagree > with. > >> > >> > Bottomline: I wouldn't understand why such a "decision shortcut" >> > would > be >> > used on the basis of this "wide implementation" argument, which >> > doesn't > seem >> > (to me) to hold much water. I believe the "midcom" group needs to >> > find a better rationale (and process) for making such decision. >> >> On this point, I fully agree with you! > > => hey, we did agree on a couple of things, great! ;-) > >> > >> > Tx >> > Jerome Moisand (Juniper Networks) >> > >> > > Melinda Shore wrote: >> > > >> > > > There was a proposal made during the midcom session at the IETF >> > > > meeting to shortcut the protocol selection process and just go >> > > > with SNMPv3 as the midcom protocol. Consistent with IETF >> > > > process, this is a decision to be made on the mailing list. >> > > > I'd like to come to a decision within the next week or so >> > > > (Thursday is Thanksgiving in the US and many people may be away >> > > > this week). >> > > > >> > > > 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 >> > >> -- > > _______________________________________________ > 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 03:54:26 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 DAA04563 for ; Thu, 5 Dec 2002 03:54:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB58uu906471 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 03:56:56 -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 gB58rKv06426; Thu, 5 Dec 2002 03:53:20 -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 gB58qKv06406 for ; Thu, 5 Dec 2002 03:52:20 -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 DAA04511 for ; Thu, 5 Dec 2002 03:49:18 -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 gB58q8F73180; Thu, 5 Dec 2002 09:52:08 +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 9FC3F7C4BF; Thu, 5 Dec 2002 09:50:04 +0100 (CET) Date: Thu, 05 Dec 2002 09:50:06 +0100 From: Juergen Quittek To: "Moisand, Jerome" , "'midcom@ietf.org'" Subject: RE: [midcom] framework models, related architectures and protocol controversy Message-ID: <1889997.1039081806@[192.168.102.164]> In-Reply-To: <5001C86452603F41820378E167091F07EED955@email1.unispherenetworks.com> References: <5001C86452603F41820378E167091F07EED955@email1.unispherenetworks.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 Jerome, -- Moisand, Jerome wrote on 04 December 2002 18:34 -0500: > > Melinda, > > yes, I don't disagree with you, scenarios where a middlebox of some sort > would have to be dynamically provisioned for a given TCP/RTP session are > making VERY SPECIFIC assumptions about the IP topology. It looks to me that I'd like to clarify this "very specific" you used. The way I see it, the assumption is quite simple: The the set of agents involved in provisioning a given session needs to be aware of all relevant middleboxes that need to be configured for provisioning the session. The awareness may be shared in a way that each involved agent is only aware of a subset of the relevant middleboxes. I agree that this does not match the general idea behind the Internet architecture. It is much closer to telco-style architectures. Juergen > the only realistic scenarios are at a domain boundary, typically the point > where a service provider provides IP services (e.g. a WAN uplink). Then, > either on the service user side (e.g. a NAT/FW CPE device) or on the service > provider side (e.g. a BRAS device), the topology is constrained enough that > such scenario makes sense. > > This being said, such specific scenarios are so important to both service > users and service providers that I believe it's really the pain working on > such middlebox/dynamic-session-management stories. And as I pointed out, the > whole picture involves filtering, NATting, firewalling and Qos > differentiation. > > As to scaling, I hear the concern, but I'm not sure to entirely agree with > you. There are solutions nowadays which can scale pretty well by the > appropriate combinations of hardware & software. > > Finally, on the "protocol controversy" wording, I apologize if my wording > was a bit too aggressive. I have to say I'm a bit tired of the endless > discussion between SNMP, Diameter, COPS across multiple IETF work groups. I > tend to believe that all these protocols have a role to play, and we'd > better be flexible, and define MIBs, PIBs and Diameter attributes for > multiple functional areas (ok, when this makes "reasonable" sense, of > course, which is hard to define!), instead of spending too much time arguing > in an often religious way. I hope that I'll not get a flame on this > hopefully neutral statement... ;-) > > Ok, all this philosophy aside, I vote for Megaco for Midcom. Nah, just > kidding. > > Tx > Jerome > >> One of the unfortunate things that's happened in the IETF >> over the past years is the drift away from architectural >> frameworks that are idiomatic to IP - i.e. they interwork >> with IP, particularly routing and topology, really, really >> poorly. I personally think that midcom is one of these, but >> even if we were to go to end-to-end, on-path signaling >> there's a need to have application endpoints (or proxies, >> another can of worms) communicate directly with various >> sorts of individual middleboxes which may not be on a data >> path (or cannot be "known" to be on one). >> >> The notion of having devices in the network make >> determinations and push those out to the endpoints has the >> smell of Bell about it. It's typically not something that >> will work well in IP networks, where making network elements >> visible to application endpoints can create a host of >> problems, ranging from lack of robustness to inter-layer >> duplication of function to inability to scale with the >> number of endpoints. >> >> By the way, I don't think there is an "ongoing protocol >> controversy." There's been very little discussion at all. >> If there's lack of progress it's because of lack of input, >> not because participants in the working group are at >> loggerheads. >> >> 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 Dec 5 08:16:28 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 IAA10188 for ; Thu, 5 Dec 2002 08:16:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DIou21485 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 08:18: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 gB5DF9v21300; Thu, 5 Dec 2002 08:15: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 gB5DC6v21195 for ; Thu, 5 Dec 2002 08:12:06 -0500 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 IAA10040 for ; Thu, 5 Dec 2002 08:09:09 -0500 (EST) 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 gB5DBZL06949; Thu, 5 Dec 2002 14:11:35 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 14:11:33 +0100 Message-ID: From: "Cedric Aoun" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read Date: Thu, 5 Dec 2002 14:11:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29C5F.D568120E" 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_01C29C5F.D568120E Content-Type: text/plain; charset="iso-8859-1" I think it would be useful for the WG if we compare both COPS-PR and SNMPv3 against the current protocol semantics document, motherhood requirements such as operations/maintenance, performance and applicability to network scenarios. This was not done in any of the protocol evaluations as all the authors were mandated to evaluate against the protocol requirements and framework documents. The comparison will help in deciding how to move forward. Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: 03 December 2002 23:33 To: midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read It looks like there's sufficient objection to the proposal to just go ahead now with SNMPv3 as the midcom protocol. Because of that we do need to forge ahead with the protocol selection process, and at this point I'd like to discuss removing COPS from contention. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C29C5F.D568120E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Midcom proposal: please read

I think it would be useful for the WG if we compare = both COPS-PR and SNMPv3 against the current protocol semantics = document, motherhood requirements such as operations/maintenance, = performance and applicability to network scenarios.

This was not done in any of the protocol evaluations = as all the authors were mandated to evaluate against the protocol = requirements and framework documents.

The comparison will help in deciding how to move = forward.
Cedric


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: 03 December 2002 23:33
To: midcom@ietf.org
Subject: Re: [midcom] Midcom proposal: please read =


It looks like there's sufficient objection to the = proposal
to just go ahead now with SNMPv3 as the midcom = protocol.
Because of that we do need to forge ahead with the = protocol
selection process, and at this point I'd like to = discuss
removing COPS from contention.

Thanks,

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

------_=_NextPart_001_01C29C5F.D568120E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 08:38: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 IAA10766 for ; Thu, 5 Dec 2002 08:38:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Dehk23248 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 08:40: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 gB5Db5v22685; Thu, 5 Dec 2002 08:37:05 -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 gB5DaXv22480 for ; Thu, 5 Dec 2002 08:36: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 IAA10677 for ; Thu, 5 Dec 2002 08:33:40 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB5DaB0J028451; Thu, 5 Dec 2002 05:36:11 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD08859; Thu, 5 Dec 2002 05:36:29 -0800 (PST) Message-Id: <200212051336.ABD08859@mira-sjc5-c.cisco.com> To: "Cedric Aoun" cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Midcom proposal: please read In-Reply-To: Message from "Cedric Aoun" of "Thu, 05 Dec 2002 14:11:34 +0100." Date: Thu, 05 Dec 2002 08:36: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: , > I think it would be useful for the WG if we compare both > COPS-PR and SNMPv3 against the current protocol semantics > document, motherhood requirements such as > operations/maintenance, performance and applicability to > network scenarios. This was not done in any of the > protocol evaluations as all the authors were mandated to > evaluate against the protocol requirements and framework > documents. The comparison will help in deciding how to > move forward. I don't think that's appropriate right now. COPS and megaco are the two lowest-scoring protocols in the evaluation document, and COPS has serious problems with the suitability of its provisioning model. As things currently stand, the only people who have made serious objections to removing COPS from the list of candidate protocols are the authors of the COPS evaluation and I don't think that's sufficient. If possible I'd really like to see the working group come to agreement SOON to remove both COPS and megaco from consideration. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 09:15: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 JAA12184 for ; Thu, 5 Dec 2002 09:15:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EHad25871 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 09:17:36 -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 gB5EE4v25693; Thu, 5 Dec 2002 09:14: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 gB5EDtv25674 for ; Thu, 5 Dec 2002 09:13:55 -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 JAA12020 for ; Thu, 5 Dec 2002 09:11:01 -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 gB5EDhF89537; Thu, 5 Dec 2002 15:13:43 +0100 (CET) (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 64B657B93B; Thu, 5 Dec 2002 15:11:38 +0100 (CET) Message-ID: <3DEF5E6A.3000400@ccrle.nec.de> Date: Thu, 05 Dec 2002 15:10:50 +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] Midcom proposal: please read References: <200212051336.ABD08859@mira-sjc5-c.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 Melinda Shore wrote: [...] > > If possible I'd really like to see the working group come to > agreement SOON to remove both COPS and megaco from > consideration. Fine with me to remove COPS and MEGACO from the list of possible MIDCOM candidates. > > 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 Dec 5 09:26: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 JAA12916 for ; Thu, 5 Dec 2002 09:26:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5ESj926671 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 09:28: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 gB5ESBv26642; Thu, 5 Dec 2002 09:28:11 -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 gB5ERqv26617 for ; Thu, 5 Dec 2002 09:27:52 -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 JAA12832 for ; Thu, 5 Dec 2002 09:24:58 -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 gB5ERnF90439; Thu, 5 Dec 2002 15:27:49 +0100 (CET) (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 AE80E5F4D0; Thu, 5 Dec 2002 15:25:44 +0100 (CET) Message-ID: <3DEF6197.100@ccrle.nec.de> Date: Thu, 05 Dec 2002 15:24:23 +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: snmpv3@lists.tislabs.com Cc: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 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 [please keep me in the recipient list, since I'm not subscribed to snmvp3 list] Hi, as you may have heard: the MIDCOM WG is currently doing a protocol evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is amongst these candidates (diameter, cops(-pr), megaco). Would you strongly recommend to use SNMPv3 as the MIDCOM protocol without having a bad feeling? Actually there are only a few pro and cons discussed so far. Thanks in advance Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 09: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 JAA12930 for ; Thu, 5 Dec 2002 09:27:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5ETRH26739 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 09:29:27 -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 gB5ET1v26711; Thu, 5 Dec 2002 09:29:01 -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 gB5ES5v26630 for ; Thu, 5 Dec 2002 09:28:05 -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 JAA12835 for ; Thu, 5 Dec 2002 09:25:11 -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 gB5ERpF90445; Thu, 5 Dec 2002 15:27:51 +0100 (CET) (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 A130B5F4D0; Thu, 5 Dec 2002 15:25:46 +0100 (CET) Message-ID: <3DEF6199.1030109@ccrle.nec.de> Date: Thu, 05 Dec 2002 15:24:25 +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] Midcom proposal: please read References: <200212032232.ABC15312@mira-sjc5-c.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 Melinda, I would prefer to hear some opinions from the SNMP community about SNMPv3 as MIDCOM protocol. A point for SNMPv3 would be the NAT MIB if it is applicable. Martin Melinda Shore wrote: > It looks like there's sufficient objection to the proposal > to just go ahead now with SNMPv3 as the midcom protocol. > Because of that we do need to forge ahead with the protocol > selection process, and at this point I'd like to discuss > removing COPS from contention. > > 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 Thu Dec 5 09:43: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 JAA13966 for ; Thu, 5 Dec 2002 09:43:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EjY928633 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 09:45: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 gB5Ej8v28618; Thu, 5 Dec 2002 09:45: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 gB5Egrv28293 for ; Thu, 5 Dec 2002 09:42:53 -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 JAA13707 for ; Thu, 5 Dec 2002 09:39:59 -0500 (EST) 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 gB5Egfq02780; Thu, 5 Dec 2002 09:42:41 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 09:42:42 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DFEA@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , midcom@ietf.org Subject: RE: [midcom] Semantics #1: PRR behaviour Date: Thu, 5 Dec 2002 09:42:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29C6C.8C949E0A" 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_01C29C6C.8C949E0A Content-Type: text/plain Two weeks later ... finally able to reply. The semantics are simpler in my view if both sides are allocated when needed. That way the Agent doesn't need to know the FW/NAT configuration in advance, and can simply ask for the necessary addresses if any to be reserved. > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Tuesday, November 19, 2002 6:55 PM > To: midcom@ietf.org > Subject: [midcom] Semantics #1: PRR behaviour > > > The semantics propose currently that PRR does > > - outside address/port allocation for a traditional NAT > - outside and inside address/port allocation for a twice NAT. > > But it is really needed to allocate both sides of a twice NAT > during a > PRR transaction or is it sufficient enough to just allocate > the outside > address/port? > > The semantics could be simplified if only the outside > address/port is > allocated (indepent of middlebox type). Or do you see a > scenario where > both sides must be allocated during the PRR transaction? > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C29C6C.8C949E0A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Semantics #1: PRR behaviour

Two weeks later ... finally able to reply.

The semantics are simpler in my view if both sides = are allocated when needed.  That way the Agent doesn't need to = know the FW/NAT configuration in advance, and can simply ask for the = necessary addresses if any to be reserved.

> -----Original Message-----
> From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
> Sent: Tuesday, November 19, 2002 6:55 PM
> To: midcom@ietf.org
> Subject: [midcom] Semantics #1: PRR = behaviour
>
>
> The semantics propose currently that PRR = does
>
> - outside address/port allocation for a = traditional NAT
> - outside and inside address/port allocation = for a twice NAT.
>
> But it is really needed to allocate both sides = of a twice NAT
> during a
> PRR transaction or is it sufficient enough to = just allocate
> the outside
> address/port?
>
> The semantics could be simplified if only the = outside
> address/port  is
> allocated (indepent of middlebox type). Or do = you see a
> scenario where
> both sides must be allocated during the PRR = transaction?
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C29C6C.8C949E0A-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 09:47: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 JAA14250 for ; Thu, 5 Dec 2002 09:47:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EnVX29005 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 09:49:31 -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 gB5En4v28980; Thu, 5 Dec 2002 09:49: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 gB5Em5v28935 for ; Thu, 5 Dec 2002 09:48:05 -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 JAA14157 for ; Thu, 5 Dec 2002 09:45:12 -0500 (EST) 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 gB5Elsk29585; Thu, 5 Dec 2002 09:47:54 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 09:47:55 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DFEB@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , midcom@ietf.org Subject: RE: [midcom] Semantics #4: Return values in PER Date: Thu, 5 Dec 2002 09:47:54 -0500 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: , Good question, though I suspect it's just one of those things we decide on and move ahead. I've always assumed that it doesn't matter if the Agent learns the MB type in the reply. My issue has always been not requiring the MA to know the MB type in advance. I figure this simplifies the MA logic. > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Tuesday, November 19, 2002 7:08 PM > To: midcom@ietf.org > Subject: [midcom] Semantics #4: Return values in PER > > > What to return in PER transaction reply if inside and/or outside > address/port are not allocated? > Examples: middlebox is packet filter (no inside or outside > address/port) > or traditional NAT (only outside address/port). > > First choice: Return emtpy/none marker. This has the impact that the > middlebox type is no longer transparent to the agent, i.e. > the agent has > to care what type of middlebox it is using > > Second choice: Return external and/or internal endpoint > addresses/port > if appropriate. > > > > _______________________________________________ > 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 Dec 5 09:47: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 JAA14278 for ; Thu, 5 Dec 2002 09:47:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EnjF29039 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 09:49: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 gB5Ek4v28738; Thu, 5 Dec 2002 09:46: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 gB5Eisv28443 for ; Thu, 5 Dec 2002 09:44:54 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13876 for ; Thu, 5 Dec 2002 09:42:00 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB5Ein309323; Thu, 5 Dec 2002 06:44:50 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB5Ej1727602; Thu, 5 Dec 2002 08:45:02 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 08:44:48 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB31@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Christopher A. Martin'" , "'Miao Fuyou'" , midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read Date: Thu, 5 Dec 2002 08:44:45 -0600 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: , Just to clarify, as the Protocol evaluation stands for MIDCOM, it is only SNMPv3 that is being considered (based upon the recent -06 version). Mary -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Wednesday, December 04, 2002 9:46 PM To: 'Miao Fuyou'; midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read Hi all, sorry I'm late on the thread as usual, I agree with SNMP v3 as a potential protocol for this purpose but am not sure that I agree with the comments about popularity of the earlier versions ot v3 mentioned below, since I am concerned with security of midcom implemtation wrt the choice between v1/v2 and v3. I don$B!G(Jt think that the first two are valid for reasons of message integrity of the protocol signaling. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Miao Fuyou Sent: Wednesday, December 04, 2002 9:29 PM To: midcom@ietf.org Subject: RE: [midcom] Midcom proposal: please read If we consider SNMP overall$B!J(Jregardless v1, v2 or v3$B!K(Jas a protocol, I believe nobody would disagree that it's a widely deployed one. Actually v3 shares so many features with v1 or v2, which are definitely widely deployed. What is more, the philosophy and primary architecture behide them are leave unchanged when it evolved. So, I think we should evaluate the effect of v1/v2 popularity to v3 intead of v3 alone. BTW, I am new to the WG, the sentences above don't imply any preference. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, December 04, 2002 1:13 AM To: Jerome Moisand; midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read Jerome, -- Jerome Moisand wrote on 27 November 2002 10:16 -0500: > Juergen, > > I was just saying that choosing SNMPv3 because it's "widely deployed" > isn't a convincing argument at all. That's correct. > I was not making a case for choosing this protocol or against it, I do > see multiple Pros & Cons for SNMPv3 (and the others). Agreed. > I just wanted to express the opinion that we shouldn't shortcut the > decision-making process. I would like to shortcut it, but only with good arguments. > (see below a few more details for clarification, but not really adding > much to my points). > > Tx > Jerome > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Jerome Moisand" > Cc: ; "Melinda Shore" > Sent: Wednesday, November 27, 2002 9:31 AM > Subject: Re: [midcom] Midcom proposal: please read > > >> Hi Jerome, >> >> I am also not sure whether or not SNMP would be a good choice for >> MIDCOM. But your arguments confused me. Do you want to say >> "everything else would be better? Or do you see a good candidate, you >> would prefer? >> >> Please see some more comments inline. > > => and my answers > >> >> Juergen >> >> > Hello, >> > >> > I'm new to this list, so apologies in advance if I might repeat >> > what > other >> > people already stated. >> > >> > If I remember well, the main point made during the midcom session >> > about shorcutting the protocol selection process was that SNMP is >> > way more > widely >> > implemented than other protocol candidates. >> > >> > I am not sure to see the value of this point. >> > >> > First, SNMP is definitely widely implemented, but essentially for > monitoring >> > purposes (alarms & stats). It seems a big stretch to say that SNMP >> > is > widely >> > implemented for provisioning & for authorization, where protocols >> > like > CLI >> >> Yes, CLI is really most widely implemented as configuration protocol. >> But this is not at all a protocol (maybe it is 1000 protocols :-). > > => I facetiously referred to CLI as a protocol, knowing well that many > people will balk at this terminology! ;-) => Yes, we're in complete > agreement here. > >> > and Radius are by far the most widely deployed. Also SNMPv1 and to >> > a > lesser >> > extent SNMPv2 are widely used, but it also seems a big stretch to >> > say > that >> > SNMPv3 is widely implemented. Just look at the largest router > manufacturer >> > general strategy in this respect... >> > >> > Second, the fact that a protocol is widely implemented doesn't make >> > it suitable for all purposes. Both Diameter and COPS have been >> > designed to >> >> First you compare SNMPv3 to CLI and say its much less widely used. >> This is completely right, but not useful at all. Now you compare it >> to COPS and Diameter. Compared to Diameter (and probably also COPS), >> SNMPv3 is indeed widely used. > > => everything is relative, but all in all, none of the proposed > candidates (SNMPv3 for provisioning, Diameter, COPS) is widely used > yet, far from it. By either Network Elements, or OSS systems. Or let's > say, not to a point where it should become a significant factor in our > decision-making. These three protocols clearly remain to be proven on > the field. This is only my perception, of course (probably tainted by > the fact that I know well Service Providers environments, but less > enterprise networking). Maybe there is an argument, that SNMP is the protocol which is most likely to be implemented on a managed box anyway. And in the future, I expect SNMPv1 and SNMPv2c to be replaced step by step by SNMPv3. > >> > allow better processing for transaction-oriented policy decisions >> > (which > is >> > exactly what midcom is about, I believe). Both protocols were >> > intended > to >> > address such situations that SNMP and Radius were not good at. If >> > it > were >> >> Please exlain! How is COPS addressing the "mutliple clients >> configuring a single server while addressing the same (kind of) >> resources)" situation? I would say: not at all. > > => this is another thread of discussion. I did hear Melinda express > reservations on this point, but this deserves a separate e-mail > thread. I'll come back on this, as well as the transaction aspect of > midcom (where I think SNMPv3 has a big issue). > > => maybe somebody would be kind enough to copy & paste some previous > e-mail thread on this topic, and forward it to me? Just to not making > you guys repeat yourselves? I'll do so. >> > not the case, why did IETF spend so much time working on these two >> > new protocols? Also note that the mere fact that these protocols >> > have been recently defined makes it obvious that they are not yet >> > widely > implemented. >> > So? Should we never use next-gen protocols on this basis? I don't > believe >> > so. >> >> I cannot follow your argument. We are using a lot of very recent > protocols, >> but do we have to choose them always, just because the are new? If >> COPS-PR is not even widely used in it's original domain, policy-based > configuration, >> yet, then why should I already consider using it for other purposes >> for > which >> it was not really designed. The situation would certainly be >> different, if COPS was already implemented widely for policy-based >> configuration of > devices. >> But since it is not (and I personally see it coming soon, why should >> I > choose >> it? Because it is 'next-gen'? > > => funny the way you took the direct negation of my statement! You're > saying we should NOT *always* use recent protocols just because they > are recent. I was just saying that we should NOT *always* use old > protocols (or new flavors of an old protocol) just because they are > 'old' (hence 'proven') and have been widely used for a completly > different application (e.g. monitoring). Well, both statements are > fair, I believe! agreed. > => maybe I don't fully understand yet what midcom is about, but I do > see this as a dynamic policy management problem with transactional > properties. So it only seems natural to look at policy management > protocols. Which the group rightfully did, without jumping to hasty > conclusions. All this sounds fair to me. But suddenly shortcutting > such process based on a very debatable point, that, I have to disagree > with. > >> > >> > Bottomline: I wouldn't understand why such a "decision shortcut" >> > would > be >> > used on the basis of this "wide implementation" argument, which >> > doesn't > seem >> > (to me) to hold much water. I believe the "midcom" group needs to >> > find a better rationale (and process) for making such decision. >> >> On this point, I fully agree with you! > > => hey, we did agree on a couple of things, great! ;-) > >> > >> > Tx >> > Jerome Moisand (Juniper Networks) >> > >> > > Melinda Shore wrote: >> > > >> > > > There was a proposal made during the midcom session at the IETF >> > > > meeting to shortcut the protocol selection process and just go >> > > > with SNMPv3 as the midcom protocol. Consistent with IETF >> > > > process, this is a decision to be made on the mailing list. >> > > > I'd like to come to a decision within the next week or so >> > > > (Thursday is Thanksgiving in the US and many people may be away >> > > > this week). >> > > > >> > > > 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 >> > >> -- > > _______________________________________________ > 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 09:51: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 JAA14496 for ; Thu, 5 Dec 2002 09:51:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5ErV929253 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 09:53:31 -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 gB5Eo4v29071; Thu, 5 Dec 2002 09:50: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 gB5Endv29035 for ; Thu, 5 Dec 2002 09:49:39 -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 JAA14194 for ; Thu, 5 Dec 2002 09:46:45 -0500 (EST) 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 gB5EnSq03675; Thu, 5 Dec 2002 09:49:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 09:49:29 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DFEC@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , midcom@ietf.org Subject: RE: [midcom] Semantics #5: Split PER transaction Date: Thu, 5 Dec 2002 09:49:28 -0500 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: , Since these are semantics we're talking about, that might be a good idea: separate operations reflecting the different state transitions involved. > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Tuesday, November 19, 2002 7:08 PM > To: midcom@ietf.org > Subject: [midcom] Semantics #5: Split PER transaction > > > Currently the state transitions in the policy rule state machine from > - PRID UNUSED to ENABLED > - RESERVED to ENABLED > 'using' the same PER transaction. > If you take a look into the semantics draft you will > recognize that the > PER for the RESERVED to ENABLED transition doesn't need all the > parameters as the PER for UNUSED to ENABLED does need. > So it would make sense to separate them both into two different > transactions: > PER1 for RESERVED to ENABLED > PER2 for PRID UNUSED to ENABLED > (The names PER1 and PER2 are just for the first clarification!) > > This would significantly simplify the semantics for the PER > transaction. > > _______________________________________________ > 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 Dec 5 10:07:27 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 KAA15158 for ; Thu, 5 Dec 2002 10:07:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5F9oE30614 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 10:09: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 gB5F66v29913; Thu, 5 Dec 2002 10:06: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 gB5F5kv29890 for ; Thu, 5 Dec 2002 10:05:46 -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 KAA15002 for ; Thu, 5 Dec 2002 10:02:52 -0500 (EST) 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 gB5F5Zq11122; Thu, 5 Dec 2002 10:05:35 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 10:05:36 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DFED@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , midcom@ietf.org Subject: RE: [midcom] Semantics #7: Capability exchange on Session Establi shment Date: Thu, 5 Dec 2002 10:05:33 -0500 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: , Basically the possible values for the capability entries should constrain in clearly mapped fashion the possible transactions, parameters, and ranges of parameter values that can be used in the subsequent session. These cover most of it. I expect policy items are a separate matter which shouldn't be dealt with here. In place of a "type of middlebox" parameter, I'd prefer one or more parameters that spell out more directly the individual functions involved. The one function I can think of right now is "Number of addresses mapped", which could be zero, one, or two. > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Tuesday, November 19, 2002 7:15 PM > To: midcom@ietf.org > Subject: [midcom] Semantics #7: Capability exchange on > Session Establishment > > > Currently the semantics document proposes these capabilitiy > information: > - Type of middlebox > - IP address wildcard support > - Port wildcard support > - supported IP versions > - supported optional transactions > - policy rule persistency > - maximum policy rule lifetime > - name of the default group > > Do you see any other capabilities that should be announced? > > > _______________________________________________ > 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 Dec 5 10:24: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 KAA16031 for ; Thu, 5 Dec 2002 10:24:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5FRDU31495 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 10:27:13 -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 gB5FN9v31288; Thu, 5 Dec 2002 10:23: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 gB5FHpv31034 for ; Thu, 5 Dec 2002 10:17:51 -0500 Received: from agitator.ibr.cs.tu-bs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15581 for ; Thu, 5 Dec 2002 10:14:58 -0500 (EST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gB5FHing005516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 5 Dec 2002 16:17:44 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gB5FHiAa013131 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 5 Dec 2002 16:17:44 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gB5FHiSY013128; Thu, 5 Dec 2002 16:17:44 +0100 Date: Thu, 5 Dec 2002 16:17:44 +0100 Message-Id: <200212051517.gB5FHiSY013128@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Martin.Stiemerling@ccrle.nec.de CC: snmpv3@lists.tislabs.com, midcom@ietf.org In-reply-to: <3DEF6197.100@ccrle.nec.de> (message from Martin Stiemerling on Thu, 05 Dec 2002 15:24:23 +0100) References: <3DEF6197.100@ccrle.nec.de> Subject: [midcom] Re: SNMPv3 as MIDCOM protocol: Opinions? 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 Stiemerling writes: Martin> as you may have heard: the MIDCOM WG is currently doing a Martin> protocol evaluation which protocol to use as the MIDCOM Martin> protocol. SNMPv3 is amongst these candidates (diameter, Martin> cops(-pr), megaco). Would you strongly recommend to use Martin> SNMPv3 as the MIDCOM protocol without having a bad feeling? Feeling is one dimension in a multi-dimensional space. And we all know that SNMP has a reputation which is kind of special. Anyway, it usually makes sense to also look at the functional requirements and the features offered by a protocol if you are not completely driven by feelings. Are the MIDCOM requirements spelled out somewhere? /js -- Juergen Schoenwaelder _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 11:50: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 LAA19158 for ; Thu, 5 Dec 2002 11:50:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Gqnn05168 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 11:52:49 -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 gB5Gq2v05136; Thu, 5 Dec 2002 11:52:02 -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 gB5GnOv04971 for ; Thu, 5 Dec 2002 11:49:24 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19042 for ; Thu, 5 Dec 2002 11:46:29 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB5GnJP05312 for ; Thu, 5 Dec 2002 11:49:19 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 17:49:18 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , Martin.Stiemerling@ccrle.nec.de Cc: snmpv3@lists.tislabs.com, midcom@ietf.org Date: Thu, 5 Dec 2002 17:49:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? 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 believe so: RFC3304 Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: donderdag 5 december 2002 16:18 > To: Martin.Stiemerling@ccrle.nec.de > Cc: snmpv3@lists.tislabs.com; midcom@ietf.org > Subject: Re: SNMPv3 as MIDCOM protocol: Opinions? > > > > >>>>> Martin Stiemerling writes: > > Martin> as you may have heard: the MIDCOM WG is currently doing a > Martin> protocol evaluation which protocol to use as the MIDCOM > Martin> protocol. SNMPv3 is amongst these candidates (diameter, > Martin> cops(-pr), megaco). Would you strongly recommend to use > Martin> SNMPv3 as the MIDCOM protocol without having a bad feeling? > > Feeling is one dimension in a multi-dimensional space. And we all know > that SNMP has a reputation which is kind of special. > > Anyway, it usually makes sense to also look at the functional > requirements and the features offered by a protocol if you are not > completely driven by feelings. Are the MIDCOM requirements spelled out > somewhere? > > /js > > -- > Juergen Schoenwaelder > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 11:50: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 LAA19179 for ; Thu, 5 Dec 2002 11:50:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5GrFR05186 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 11:53:15 -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 gB5Gn7v04957; Thu, 5 Dec 2002 11:49: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 gB5Glhv04872 for ; Thu, 5 Dec 2002 11:47:43 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19004 for ; Thu, 5 Dec 2002 11:44:47 -0500 (EST) Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id gB5GlYf03121; Thu, 5 Dec 2002 08:47:34 -0800 To: midcom@ietf.org From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Thu, 05 Dec 2002 08:47:34 -0800 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] notification of work that may help 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've been glancing over the rfc3304.txt and draft-ietf-midcom-protocol-eval-06.txt documents and thought you probably should be aware of some existing work within the IETF that may help you out (you'll likely need to build upon it, but you can use it as a good starting point). I haven't read either document cover to cover, so forgive me if I say something out of line. Much of these two documents discusses the need for required policy rules for packet filtering. There has been a lot of work in this area within the ip-security-policy (ipsp) working group. Specifically, I'm one of the authors of the IPSEC-POLICY-MIB which is a document that closely aligns with your work and you might consider looking at. For example, the following requirement: 2.2.8. The Midcom protocol must be able to carry filtering rules, including but not limited to the 5-tuple, from the midcom agent to the middlebox. By "5-tuple", we refer to the standard tuple. Other filtering elements may be carried, as well. and the associated comments about SNMP in the evaluation document: 2.2.8 Transport of filtering rules SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+ SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementation of a MIB module to meet the semantics of this requirement. These are filled in part or in total by the IPSEC-POLICY-MIB. (Don't let the "IPSEC" in the name confuse you. It's not IPSEC-specific). The IPSEC-POLICY-MIB can be divided into 2 parts: a policy rules section for processing packets using rules, filters, and actions. The other 2/3rds of the MIB is devoted to IPsec specific actions (start an SA, start an IKE transaction, ...). There is a very deliberate delineation between the packet processing portion of the MIB and the IPsec specific actions. Specifically, the packet processing rules are really just a firewall configuration section (there are standard actions for "drop packet" and "accept packet" as well). There are numerous filtering mechanisms in place within the MIB, such as the ipHeaderFilterTable which directly meets the 2.2.8 requirement above and the timeFilterTable which may meet other of your requirements. The MIB is deliberately very extensible, and new filters and actions can be defined in external documents so that if you wanted to base your work on it's packet and rule processing system but needed some extra filters, it would be easy to do so. All of this work is in alignment with the policy models being developed within the Policy Framework working group, the IPSP WG, and the DMTF. I mention this because it looks like you refer to parts of these data models in your documents at times. Finally, there is also a IPSEC-POLICY-PIB for COPS also being published in the IPSP working group. I don't know if it is extensible and reusable as the MIB as I haven't given it a review lately. We designed the MIB to be a generic firewall configuration engine, but I don't know if the PIB authors had the same goal. There is also a working reference-release implementation for the MIB on linux, as well as a manager that should run on just about any platform. See http://net-policy.sourceforge.net/ for details on that particular project. -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 12:07: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 MAA19966 for ; Thu, 5 Dec 2002 12:07:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5H9Yn07031 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 12:09: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 gB5H95v06995; Thu, 5 Dec 2002 12:09:05 -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 gB5GtOv05310 for ; Thu, 5 Dec 2002 11:55:24 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19263 for ; Thu, 5 Dec 2002 11:52:29 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA16328 for ; Thu, 5 Dec 2002 12:07:28 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma016267; Thu, 5 Dec 02 12:06:29 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Thu, 05 Dec 2002 11:54:25 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 5 Dec 2002 11:54:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 5 Dec 2002 11:54:24 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA075902@NHROCMBX1.ets.enterasys.com> Thread-Topic: SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKcd3gasIwE3Qb4ShKmRbUmu45JugABdorg From: "Harrington, David" To: "Juergen Schoenwaelder" , Cc: , X-OriginalArrivalTime: 05 Dec 2002 16:54:25.0077 (UTC) FILETIME=[F76DB650:01C29C7E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5GtOv05311 Subject: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? 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 Hi, Message #1: As SNMPv3 co-chair. Let me inform the SNMPv3 working about the fact that SNMP has been proposed as a candidate for the Middlebox Communications protocol. This has been mentioned on the mailing list in the past. RFC3303 and 3304 describe the MIDCOM architecture and requirements. The evaluation is being done against a checklist of requirements specified in RFC3304. An evaluation of SNMPv3 versus MIDCOM requirements, done by Juergen Quittek and I, can be found in draft-ietf-midcom-protocol-eval-06.txt. Juergen did an earlier evaluation of SNMP (all versions) in draft-quittek-midcom-snmp-eval-00.txt It would be helpful if the people in the WG reviewed the requirements and analyses and contributed any comments to the process. --- David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: Thursday, December 05, 2002 10:18 AM > To: Martin.Stiemerling@ccrle.nec.de > Cc: snmpv3@lists.tislabs.com; midcom@ietf.org > Subject: Re: SNMPv3 as MIDCOM protocol: Opinions? > > > > >>>>> Martin Stiemerling writes: > > Martin> as you may have heard: the MIDCOM WG is currently doing a > Martin> protocol evaluation which protocol to use as the MIDCOM > Martin> protocol. SNMPv3 is amongst these candidates (diameter, > Martin> cops(-pr), megaco). Would you strongly recommend to use > Martin> SNMPv3 as the MIDCOM protocol without having a bad feeling? > > Feeling is one dimension in a multi-dimensional space. And we all know > that SNMP has a reputation which is kind of special. > > Anyway, it usually makes sense to also look at the functional > requirements and the features offered by a protocol if you are not > completely driven by feelings. Are the MIDCOM requirements spelled out > somewhere? > > /js > > -- > Juergen Schoenwaelder > > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 13:01: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 NAA21593 for ; Thu, 5 Dec 2002 13:01:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5I48N10433 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 13:04:08 -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 gB5I0Bv10211; Thu, 5 Dec 2002 13:00:11 -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 gB5HxHv10135 for ; Thu, 5 Dec 2002 12:59:17 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21428 for ; Thu, 5 Dec 2002 12:56:23 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA19866 for ; Thu, 5 Dec 2002 13:11:20 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma019830; Thu, 5 Dec 02 13:10:45 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Thu, 05 Dec 2002 12:58:46 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 5 Dec 2002 12:58:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 5 Dec 2002 12:58:46 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA075903@NHROCMBX1.ets.enterasys.com> Thread-Topic: SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKcck0J/0p4QVteSqm/sATuWL8DewADMayA From: "Harrington, David" To: "Martin Stiemerling" , Cc: X-OriginalArrivalTime: 05 Dec 2002 17:58:46.0608 (UTC) FILETIME=[F5149500:01C29C87] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5HxHv10136 Subject: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? 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 Hi, Message #2: as an evaluator of SNMPv3 based on the MIDCOM requirements. In performing the evaluation, SNMPv3 scored very well, but I'd like to comment on the evaluation process. It is my feeling that the MIDCOM requirements need work. There are many requirements that are ambiguous, and there are many requirements that have been written to favor a specific type of solution (not a particular candidate, but a particular approach, which favors some protocol designs). I don't believe this was done to influence the results, I think the persons writing the requirements had a solution in mind, and phrased the questions according to their view of the problems. I'm not sayingg this becasue I feel that SNMPv3 could have done better with a different set of requirements; SNMPv3 may have done better or it may have done worse with a different set of requirements. As it is, I do not feel that the appropriateness of SNMPv3 or any of the other protocols to the problem was really addressed in the evaluation. I suspect that is why Martin has sent this question to the SNMPv3 mailing list. I suspect that Martin believes SNMPv3 may or may not be an appropriate choice, but that the evaluation doesn't provide enough information, or the right information, to make this determination. I recommend the MIDCOM WG rethink their requirements document. It may be necessary to rethink portions of the architecture as well. dbh > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Thursday, December 05, 2002 9:24 AM > To: snmpv3@lists.tislabs.com > Cc: midcom@ietf.org > Subject: SNMPv3 as MIDCOM protocol: Opinions? > > > [please keep me in the recipient list, since I'm not subscribed to > snmvp3 list] > > Hi, > > as you may have heard: the MIDCOM WG is currently doing a protocol > evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is > amongst these candidates (diameter, cops(-pr), megaco). > Would you strongly recommend to use SNMPv3 as the MIDCOM protocol > without having a bad feeling? Actually there are only a few > pro and cons > discussed so far. > > Thanks in advance > Martin > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 13:26: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 NAA22530 for ; Thu, 5 Dec 2002 13:26:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5IT0o12451 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 13: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 gB5IPOv12259; Thu, 5 Dec 2002 13:25:24 -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 gB5IMOv12124 for ; Thu, 5 Dec 2002 13:22:24 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22283 for ; Thu, 5 Dec 2002 13:19:30 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 13:22:19 -0500 Message-ID: <5001C86452603F41820378E167091F07EED96A@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'Harrington, David'" , Martin Stiemerling , snmpv3@lists.tislabs.com, midcom@ietf.org Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Thu, 5 Dec 2002 13:21:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I was hesitating to make a similar statement, fearing of being disruptive, but I do share the very exact same feeling. Also, Melinda, may I suggest that inquiries be posted to all relevant IETF WGs (e.g. aaa/diameter, rap/cops, ipsp)? Cheers, Jerome -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: Thursday, December 05, 2002 12:59 PM To: Martin Stiemerling; snmpv3@lists.tislabs.com Cc: midcom@ietf.org Subject: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Hi, Message #2: as an evaluator of SNMPv3 based on the MIDCOM requirements. In performing the evaluation, SNMPv3 scored very well, but I'd like to comment on the evaluation process. It is my feeling that the MIDCOM requirements need work. There are many requirements that are ambiguous, and there are many requirements that have been written to favor a specific type of solution (not a particular candidate, but a particular approach, which favors some protocol designs). I don't believe this was done to influence the results, I think the persons writing the requirements had a solution in mind, and phrased the questions according to their view of the problems. I'm not sayingg this becasue I feel that SNMPv3 could have done better with a different set of requirements; SNMPv3 may have done better or it may have done worse with a different set of requirements. As it is, I do not feel that the appropriateness of SNMPv3 or any of the other protocols to the problem was really addressed in the evaluation. I suspect that is why Martin has sent this question to the SNMPv3 mailing list. I suspect that Martin believes SNMPv3 may or may not be an appropriate choice, but that the evaluation doesn't provide enough information, or the right information, to make this determination. I recommend the MIDCOM WG rethink their requirements document. It may be necessary to rethink portions of the architecture as well. dbh > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Thursday, December 05, 2002 9:24 AM > To: snmpv3@lists.tislabs.com > Cc: midcom@ietf.org > Subject: SNMPv3 as MIDCOM protocol: Opinions? > > > [please keep me in the recipient list, since I'm not subscribed to > snmvp3 list] > > Hi, > > as you may have heard: the MIDCOM WG is currently doing a protocol > evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is > amongst these candidates (diameter, cops(-pr), megaco). > Would you strongly recommend to use SNMPv3 as the MIDCOM protocol > without having a bad feeling? Actually there are only a few > pro and cons > discussed so far. > > Thanks in advance > 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 Thu Dec 5 13:41:42 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 NAA23083 for ; Thu, 5 Dec 2002 13:41:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Ii6013773 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 13:44: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 gB5Ie4v13622; Thu, 5 Dec 2002 13:40: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 gB5Idhv13576 for ; Thu, 5 Dec 2002 13:39:43 -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 NAA22927 for ; Thu, 5 Dec 2002 13:36:48 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5IdPK0014068; Thu, 5 Dec 2002 10:39:25 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD22241; Thu, 5 Dec 2002 10:39:24 -0800 (PST) Message-Id: <200212051839.ABD22241@mira-sjc5-c.cisco.com> To: "Moisand, Jerome" cc: "'Harrington, David'" , Martin Stiemerling , snmpv3@lists.tislabs.com, midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? In-Reply-To: Message from "Moisand, Jerome" of "Thu, 05 Dec 2002 13:21:51 EST." <5001C86452603F41820378E167091F07EED96A@email1.unispherenetworks.com> Date: Thu, 05 Dec 2002 13:39:24 -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 was hesitating to make a similar statement, fearing of being disruptive, > but I do share the very exact same feeling. The decision to revise the documents needs to be based on the identification of *specific* problems with them rather than a general sense that something is not quite right. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 13:54: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 NAA23570 for ; Thu, 5 Dec 2002 13:54:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5IvH514325 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 13:57:17 -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 gB5IrEv14112; Thu, 5 Dec 2002 13:53:14 -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 gB5IqPv14087 for ; Thu, 5 Dec 2002 13:52:25 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23318 for ; Thu, 5 Dec 2002 13:49:31 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 13:52:20 -0500 Message-ID: <5001C86452603F41820378E167091F07EED971@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'Melinda Shore'" Cc: "'Harrington, David'" , Martin Stiemerling , snmpv3@lists.tislabs.com, midcom@ietf.org Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Thu, 5 Dec 2002 13:52:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sure, Melinda, you're absolutely right. Well, to start with, please look again to my recent e-mail about the three types of policy management architecture I listed. Correct me if I'm wrong, but only one of them appears to be envisioned in the existing midcom requirements/proposed-architecture. The two other ones (with a stateful policy server, trigerred by either a signaling mechanism ala RSVP/NSIS, or by an application layer interaction) do not seem to be addressed, or seem to be excluded by some requirements which I find somewhat debatable, specifically: <> I see this as a fairly major issue, I don't believe we should restrict ourselves, and exclude policy management architectures which have been promoted by IETF in the context of the "rap" effort for several years. And just to clear up the water, I'm certainly not excluding either other architectures which, I believe, have NOT been envisioned by the "rap" group. Tx Jerome -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Thursday, December 05, 2002 1:39 PM To: Moisand, Jerome Cc: 'Harrington, David'; Martin Stiemerling; snmpv3@lists.tislabs.com; midcom@ietf.org Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? > I was hesitating to make a similar statement, fearing of being disruptive, > but I do share the very exact same feeling. The decision to revise the documents needs to be based on the identification of *specific* problems with them rather than a general sense that something is not quite right. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 13:59: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 NAA23813 for ; Thu, 5 Dec 2002 13:59:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5J2Dj14648 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 14:02:13 -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 gB5J18v14582; Thu, 5 Dec 2002 14:01: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 gB5J0Mv14526 for ; Thu, 5 Dec 2002 14:00:22 -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 NAA23675 for ; Thu, 5 Dec 2002 13:57:27 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB5J05LW023665; Thu, 5 Dec 2002 11:00:05 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD23981; Thu, 5 Dec 2002 11:00:03 -0800 (PST) Message-Id: <200212051900.ABD23981@mira-sjc5-c.cisco.com> To: "Moisand, Jerome" cc: "'Harrington, David'" , Martin Stiemerling , snmpv3@lists.tislabs.com, midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? In-Reply-To: Message from "Moisand, Jerome" of "Thu, 05 Dec 2002 13:52:16 EST." <5001C86452603F41820378E167091F07EED971@email1.unispherenetworks.com> Date: Thu, 05 Dec 2002 14:00:03 -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: , > Well, to start with, please look again to my recent e-mail about the three > types of policy management architecture I listed. Correct me if I'm wrong, > but only one of them appears to be envisioned in the existing midcom > requirements/proposed-architecture. Policy management is orthogonal to the midcom protocol. We assume that there's a policy component but we're not specifying it. What's envisioned is that there is one, but the questions of where it's located, what policy decisions are negotiated, and specifically what it will look like are completely outside the scope of the current set of deliverables. > < than one Midcom agent simultaneously.>> > > I see this as a fairly major issue, I don't believe we should restrict > ourselves, and exclude policy management architectures which have been > promoted by IETF in the context of the "rap" effort for several years. I doubt very much that you'd have luck finding *one* participant who thinks it sufficient to have a middlebox that's only capable of communicating with one agent. In the context of VoIP applications, as well as many others, it is absolutely mandatory that more than one agent be able to send requests to a middlebox. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 14:34:42 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 OAA25121 for ; Thu, 5 Dec 2002 14:34:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Jb6U17102 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 14:37: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 gB5JaCv16871; Thu, 5 Dec 2002 14:36: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 gB5JZhv16844 for ; Thu, 5 Dec 2002 14:35:43 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25088 for ; Thu, 5 Dec 2002 14:32:48 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 14:35:38 -0500 Message-ID: <5001C86452603F41820378E167091F07EED977@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'Melinda Shore'" Cc: "'Harrington, David'" , Martin Stiemerling , snmpv3@lists.tislabs.com, midcom@ietf.org Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Thu, 5 Dec 2002 14:35:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Please, see inline comments below. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Thursday, December 05, 2002 2:00 PM To: Moisand, Jerome Cc: 'Harrington, David'; Martin Stiemerling; snmpv3@lists.tislabs.com; midcom@ietf.org Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? > Well, to start with, please look again to my recent e-mail about the three > types of policy management architecture I listed. Correct me if I'm wrong, > but only one of them appears to be envisioned in the existing midcom > requirements/proposed-architecture. Policy management is orthogonal to the midcom protocol. We assume that there's a policy component but we're not specifying it. What's envisioned is that there is one, but the questions of where it's located, what policy decisions are negotiated, and specifically what it will look like are completely outside the scope of the current set of deliverables. => well, this is kind of the whole point. The architecture currently specified acts in the way you described, of course. And I have nothing against it, on the contrary! I'm just saying that there are other policy-oriented architectures, following the framework defined by the "rap" group (and used by the "diffserv" and "ipsp" groups) which would reach the same "fundamental goals" for managing middleboxes, using a dynamic policy protocol in-between. And I believe we should not exclude such architectures. > < than one Midcom agent simultaneously.>> > > I see this as a fairly major issue, I don't believe we should restrict > ourselves, and exclude policy management architectures which have been > promoted by IETF in the context of the "rap" effort for several years. I doubt very much that you'd have luck finding *one* participant who thinks it sufficient to have a middlebox that's only capable of communicating with one agent. In the context of VoIP applications, as well as many others, it is absolutely mandatory that more than one agent be able to send requests to a middlebox. => well, if you're making the assumption that a stateless SIP proxy should be the "midcom agent" and should directly interact with the middlebox, you're absolutely right. Which is precisely the reason for which I do like the architecture being proposed as one possible legitimate construct. => But I fear this assumption is too restrictive. Why should the SIP proxy be the component speaking with the middlebox? You may have more complex software architectures, where multiple SIP proxies will speak to a single policy decision point (aka policy server), which is in charge of a given set of middleboxes. Or stateful SIP proxies also acting as policy servers. Etc. The "rap" framework explains pretty well how to make this scale and be very resilient (e.g. strong transaction semantics, plus strong failover properties). Then we have only one middlebox agent speaking to a given middlebox at a given point in time. And I don't see anything wrong about that. As one possible architecture among others. => again, I apologize for possibly being disruptive and making such statements quite late in the process, but well, I can't help it! ;-) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 14:51: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 OAA25495 for ; Thu, 5 Dec 2002 14:51:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5JsCB17996 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 14:54:12 -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 gB5JoCv17856; Thu, 5 Dec 2002 14:50: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 gB5Jnpv17831 for ; Thu, 5 Dec 2002 14:49:51 -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 OAA25368 for ; Thu, 5 Dec 2002 14:46:55 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB5JnV0R022774; Thu, 5 Dec 2002 11:49:31 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD27578; Thu, 5 Dec 2002 11:49:31 -0800 (PST) Message-Id: <200212051949.ABD27578@mira-sjc5-c.cisco.com> To: "Moisand, Jerome" cc: "'Harrington, David'" , Martin Stiemerling , snmpv3@lists.tislabs.com, midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? In-Reply-To: Message from "Moisand, Jerome" of "Thu, 05 Dec 2002 14:35:23 EST." <5001C86452603F41820378E167091F07EED977@email1.unispherenetworks.com> Date: Thu, 05 Dec 2002 14:49:31 -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: , > => well, this is kind of the whole point. The architecture currently > specified acts in the way you described, of course. And I have nothing > against it, on the contrary! I'm just saying that there are other > policy-oriented architectures, following the framework defined by the "rap" > group (and used by the "diffserv" and "ipsp" groups) which would reach the > same "fundamental goals" for managing middleboxes, using a dynamic policy > protocol in-between. And I believe we should not exclude such architectures. Those architectures certainly are not excluded by the current midcom framework. We did have to constrain the problem space, however, lest we become one of those working groups who never produces anything (which is where we're currently headed, BTW). > => well, if you're making the assumption that a stateless SIP proxy should > be the "midcom agent" and should directly interact with the middlebox, > you're absolutely right. We don't make that assumption. We assume that any endpoint or other device can make a request of a middlebox. By restricting it to a single agent we'd either have something that didn't work for telephony applications (the ones driving the work, incidentally), or something that wouldn't scale at all. In the latter case we'd effectively be moving the midcom protocol to running from the endpoint to an agent and a policy protocol between the agent and the middlebox, and I gather that's what you're arguing for. That's not a good architecture in an environment in which you've potentially got tens of thousands of endpoints. If you're going to propose architectural changes you've got to be specific about what you want to do and why it's an improvement over what we've got now. The rap work would not apply, I think, because the policy decisions are being driven up by network events. We're trying to make requests of the network based on application events. We're also trying to restore end-to-end function in the face of funky disruptive devices. I don't think you've made a particularly compelling argument for changing our architecture, and unless you can do so we really do need to move on. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 16:45:56 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 QAA01484 for ; Thu, 5 Dec 2002 16:45:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5LmMq25146 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 16:48:22 -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 gB5LlEv25111; Thu, 5 Dec 2002 16:47:14 -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 gB5Lk4v25067 for ; Thu, 5 Dec 2002 16:46:04 -0500 Received: from mailman.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01420 for ; Thu, 5 Dec 2002 16:43:07 -0500 (EST) Received: from [171.71.119.161] by mailman.cisco.com (171.70.144.185) with ESMTP; 05 Dec 2002 07:05:42 +0000 Message-ID: <3DEFC915.7040906@cisco.com> Date: Thu, 05 Dec 2002 13:45:57 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Moisand, Jerome" CC: "'Melinda Shore'" , "'Harrington, David'" , Martin Stiemerling , snmpv3@lists.tislabs.com, midcom@ietf.org Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? References: <5001C86452603F41820378E167091F07EED977@email1.unispherenetworks.com> In-Reply-To: <5001C86452603F41820378E167091F07EED977@email1.unispherenetworks.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 Moisand, Jerome wrote: > => well, this is kind of the whole point. The architecture currently > specified acts in the way you described, of course. And I have nothing > against it, on the contrary! I'm just saying that there are other > policy-oriented architectures, following the framework defined by the "rap" > group (and used by the "diffserv" and "ipsp" groups) which would reach the > same "fundamental goals" for managing middleboxes, using a dynamic policy > protocol in-between. And I believe we should not exclude such architectures. Could you demonstrate how other architectures are excluded? If your architecture requires only one agent, then the current design should handle it. Remember, we're not talking about a protocol between the middlebox and policy server. That we leave to others. However, there needs to be a way for a single device to make a singular request to a middle box without the need for an intermediary. That's a charter requirement. Eliot _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 17:38: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 RAA03347 for ; Thu, 5 Dec 2002 17:38:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Mf1O29317 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 17:41: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 gB5Me6v29254; Thu, 5 Dec 2002 17:40: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 gB5MaHv28468 for ; Thu, 5 Dec 2002 17:36:17 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03178 for ; Thu, 5 Dec 2002 17:33:19 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gB5MY7l17300 for ; Thu, 5 Dec 2002 22:34:07 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gB5MSf626467 for ; Thu, 5 Dec 2002 22:28:41 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002120514312017101 for ; Thu, 05 Dec 2002 14:31:21 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 14:33:03 -0800 Message-ID: From: "Durham, David" To: "'midcom@ietf.org'" Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Thu, 5 Dec 2002 14:32:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Given the information collected during the IAB nm-ws from operators showing that SNMP isn't used for configuring much of anything, I would strongly object to removing COPS-PR from consideration. The directionality of connection establishment for COPS-PR is easily circumvented by running a dual mode PEP/PDP at the middlebox. Also, IPSP functionality, DiffServ, Access Control, and Framework PIBs are all there at the wgs disposal. It seems to me to be the perfect match. -Dave PS. Where is XML over HTTP or BEEP in the consideration? That's the direction the nm-community seems to be going these days. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 18:21: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 SAA04710 for ; Thu, 5 Dec 2002 18:21:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5NOBK32095 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 18:24:11 -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 gB5NNCv32022; Thu, 5 Dec 2002 18:23: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 gB5NMov32008 for ; Thu, 5 Dec 2002 18:22:50 -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 SAA04651 for ; Thu, 5 Dec 2002 18:19:51 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB5NMgLW000936 for ; Thu, 5 Dec 2002 15:22:42 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD41513; Thu, 5 Dec 2002 15:22:41 -0800 (PST) Message-Id: <200212052322.ABD41513@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 05 Dec 2002 18:22:41 -0500 Subject: [midcom] Trying again ... 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're not making any progress on this and really need to get serious over the coming few weeks. If there's objection to removing megaco from consideration by people other than the authors of the megaco evaluation, please speak up. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 19:29: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 TAA06525 for ; Thu, 5 Dec 2002 19:29:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB60WLC02976 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 19:32: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 gB60VEv02829; Thu, 5 Dec 2002 19:31:14 -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 gB60Ubv02790 for ; Thu, 5 Dec 2002 19:30:37 -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 TAA06419 for ; Thu, 5 Dec 2002 19:27:40 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB60UA0J009299; Thu, 5 Dec 2002 16:30:10 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD45815; Thu, 5 Dec 2002 16:30:29 -0800 (PST) Message-Id: <200212060030.ABD45815@mira-sjc5-c.cisco.com> To: "Durham, David" cc: "'midcom@ietf.org'" From: Melinda Shore Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? In-Reply-To: Message from "Durham, David" of "Thu, 05 Dec 2002 14:32:56 PST." Date: Thu, 05 Dec 2002 19: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: , > Given the information collected during the IAB nm-ws from operators showing > that SNMP isn't used for configuring much of anything, I would strongly > object to removing COPS-PR from consideration. The directionality of > connection establishment for COPS-PR is easily circumvented by running a > dual mode PEP/PDP at the middlebox. Also, IPSP functionality, DiffServ, > Access Control, and Framework PIBs are all there at the wgs disposal. It > seems to me to be the perfect match. I just double-checked this, and the current IESG policy is to publish PIBs *only* as Informational RFCs. People involved with midcom efforts to date may not be aware that PIBs are not published as IETF standards. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 20:28: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 UAA08492 for ; Thu, 5 Dec 2002 20:28:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB61UUS06309 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 20:30:30 -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 gB61TNv06232; Thu, 5 Dec 2002 20:29:23 -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 gB61SIv06202 for ; Thu, 5 Dec 2002 20:28:18 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08449 for ; Thu, 5 Dec 2002 20:25:20 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id UAA09441 for ; Thu, 5 Dec 2002 20:40:19 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma009436; Thu, 5 Dec 02 20:39:52 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Thu, 05 Dec 2002 20:28:01 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 5 Dec 2002 20:28:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 5 Dec 2002 20:28:00 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA075905@NHROCMBX1.ets.enterasys.com> Thread-Topic: SNMPv3 Thread-Index: AcKcxsSI+p2tx8+GSwGU3tbscU4u5g== From: "Harrington, David" To: X-OriginalArrivalTime: 06 Dec 2002 01:28:00.0920 (UTC) FILETIME=[B71A3180:01C29CC6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB61SIv06203 Subject: [midcom] SNMPv3 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 Hi, I just joined the midcom mailing list to review the discussions, and find some points that need clarification. I have preceded my comments with dbh: Juergen posted the following: I think for most MIDCOM transactions it would not be a problem to fit all parameters into a single PDU. But the SNMP spec saying that the order in which the sets are executed is not deterministic, makes it hard to 1. create a row for a new policy, 2. fill all objects of the row, and 3. set the row to be active (or enabled) with a single PDU. Rather, I think three PDUs are required for this. However, you can still provide atomicity, by having not impact at all on the middlebox behavior after step 1 and 2 and then enabling the policy int the atomic step 3. You can even add to the semantics of step 3 that the entire row will be deleted, if step 3 fails. Juergen dbh: That is incorrect. The CreateAndGo status for RowStatus allows these steps to be processed in one SET request. See RFC2579. dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 5 21:44: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 VAA10853 for ; Thu, 5 Dec 2002 21:44:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB62kSJ11224 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 21:46:28 -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 gB62gCv11119; Thu, 5 Dec 2002 21:42:14 -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 gB62fVv11076 for ; Thu, 5 Dec 2002 21:41:31 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10764 for ; Thu, 5 Dec 2002 21:38:31 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gB62dIN20537 for ; Fri, 6 Dec 2002 02:39:18 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gB62hlF20910 for ; Fri, 6 Dec 2002 02:43:47 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002120518414520284 for ; Thu, 05 Dec 2002 18:41:45 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 18:41:21 -0800 Message-ID: From: "Hahn, Scott" To: Melinda Shore , "Durham, David" Cc: "'midcom@ietf.org'" Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Thu, 5 Dec 2002 18:41:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , One clarification. The COPS and COPS-PR protocols are published as *standard track* RFCs. The PIBs which are effectively the data models that define the data for specific functions (e.g. diffserv) are currently being standardized as informational. The protocol evaluation draft documents the value of the protocol which again, is standard track. -Scott > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, December 05, 2002 4:30 PM > To: Durham, David > Cc: 'midcom@ietf.org' > Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? > > > > Given the information collected during the IAB nm-ws from operators > > showing that SNMP isn't used for configuring much of > anything, I would > > strongly object to removing COPS-PR from consideration. The > > directionality of connection establishment for COPS-PR is easily > > circumvented by running a dual mode PEP/PDP at the middlebox. Also, > > IPSP functionality, DiffServ, Access Control, and Framework > PIBs are > > all there at the wgs disposal. It seems to me to be the > perfect match. > > I just double-checked this, and the current IESG policy is > to publish PIBs *only* as Informational RFCs. People > involved with midcom efforts to date may not be aware that > PIBs are not published as IETF standards. > > 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 Dec 5 23:17: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 XAA13252 for ; Thu, 5 Dec 2002 23:17:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB64Jp016559 for midcom-archive@odin.ietf.org; Thu, 5 Dec 2002 23:19:51 -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 gB64FGv16398; Thu, 5 Dec 2002 23:15: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 gB64Etv16362 for ; Thu, 5 Dec 2002 23:14:55 -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 XAA13120 for ; Thu, 5 Dec 2002 23:11:55 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB64Ei0R024080; Thu, 5 Dec 2002 20:14:44 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD55146; Thu, 5 Dec 2002 20:14:44 -0800 (PST) Message-Id: <200212060414.ABD55146@mira-sjc5-c.cisco.com> To: "Hahn, Scott" cc: "Durham, David" , "'midcom@ietf.org'" From: Melinda Shore Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? In-Reply-To: Message from "Hahn, Scott" of "Thu, 05 Dec 2002 18:41:19 PST." Date: Thu, 05 Dec 2002 23:14:44 -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: , Right, but a midcom PIB would not be a standard. It would be published as informational. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 01:50: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 BAA16929 for ; Fri, 6 Dec 2002 01:50:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB66r7C24831 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 01:53: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 gB66qCv24816; Fri, 6 Dec 2002 01:52: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 gB66p8v24794 for ; Fri, 6 Dec 2002 01:51:08 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16894 for ; Fri, 6 Dec 2002 01:48:07 -0500 (EST) Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id gB66ofl16971; Thu, 5 Dec 2002 22:50:41 -0800 To: "Durham, David" Cc: "'midcom@ietf.org'" Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? References: From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Thu, 05 Dec 2002 22:50:41 -0800 In-Reply-To: ("Durham, David"'s message of "Thu, 5 Dec 2002 14:32:56 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) 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: , >>>>> On Thu, 5 Dec 2002 14:32:56 -0800 , "Durham, David" said: David> Given the information collected during the IAB nm-ws from David> operators showing that SNMP isn't used for configuring much of David> anything, I would strongly object to removing COPS-PR from David> consideration. Well, if we took what they told us they did use for configuration then we'd have to standardize an expect script. -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 01:52:20 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 BAA16970 for ; Fri, 6 Dec 2002 01:52:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB66soF24899 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 01:54: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 gB66s1v24871; Fri, 6 Dec 2002 01:54:01 -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 gB66rJv24854 for ; Fri, 6 Dec 2002 01:53:19 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16927 for ; Fri, 6 Dec 2002 01:50:18 -0500 (EST) Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id gB66qmp16974; Thu, 5 Dec 2002 22:52:48 -0800 To: "Harrington, David" Cc: Subject: Re: [midcom] SNMPv3 References: <6D745637A7E0F94DA070743C55CDA9BA075905@NHROCMBX1.ets.enterasys.com> From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Thu, 05 Dec 2002 22:52:47 -0800 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA075905@NHROCMBX1.ets.enterasys.com> ("Harrington, David"'s message of "Thu, 5 Dec 2002 20:28:00 -0500") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) 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: , >>>>> On Thu, 5 Dec 2002 20:28:00 -0500, "Harrington, David" said: Juergen> I think for most MIDCOM transactions it would not be a problem to Juergen> fit all parameters into a single PDU. But the SNMP spec saying Juergen> that the order in which the sets are executed is not Juergen> deterministic, FYI, the EOS working group is producing a document with SNMP write transactions which do support transactional ordering if desired. IE, within the new write PDU you can delete a row and replace it with new contents in the same operation by ordering the transaction. -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 04:47:29 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 EAA00287 for ; Fri, 6 Dec 2002 04:47:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB69o1312645 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 04:50: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 gB69kKv12503; Fri, 6 Dec 2002 04:46:20 -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 gB69jqv12478 for ; Fri, 6 Dec 2002 04:45:52 -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 EAA00167 for ; Fri, 6 Dec 2002 04:42:49 -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 gB69jcF29113; Fri, 6 Dec 2002 10:45:38 +0100 (CET) (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 A2B8060160; Fri, 6 Dec 2002 10:43:30 +0100 (CET) Message-ID: <3DF07145.2070803@ccrle.nec.de> Date: Fri, 06 Dec 2002 10:43:33 +0100 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: Juergen Schoenwaelder Cc: snmpv3@lists.tislabs.com, midcom@ietf.org References: <3DEF6197.100@ccrle.nec.de> <200212051517.gB5FHiSY013128@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: SNMPv3 as MIDCOM protocol: Opinions? 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 Juergen, Juergen Schoenwaelder wrote: >>>>>>Martin Stiemerling writes: >>>>> > > Martin> as you may have heard: the MIDCOM WG is currently doing a > Martin> protocol evaluation which protocol to use as the MIDCOM > Martin> protocol. SNMPv3 is amongst these candidates (diameter, > Martin> cops(-pr), megaco). Would you strongly recommend to use > Martin> SNMPv3 as the MIDCOM protocol without having a bad feeling? > > Feeling is one dimension in a multi-dimensional space. And we all know > that SNMP has a reputation which is kind of special. > > Anyway, it usually makes sense to also look at the functional > requirements and the features offered by a protocol if you are not > completely driven by feelings. Are the MIDCOM requirements spelled out > somewhere? Yes, they are: http://www.ietf.org/rfc/rfc3303.txt (architecture und framework) http://www.ietf.org/rfc/rfc3304.txt (requirements) The actual protocol evaluation is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-06.txt Thanks in advance Martin > > /js > -- ************************************************ NEW ADDRESS EFFECTIVE DECEMBER 23RD Kurfuersten-Anlage 34, 69115 Heidelberg, Germany phone, fax and email remain unchanged ************************************************ 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 Dec 6 07:56: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 HAA04307 for ; Fri, 6 Dec 2002 07:56:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Cwu821771 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 07:58:56 -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 gB6CtIv21663; Fri, 6 Dec 2002 07:55:18 -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 gB6Cs6v21601 for ; Fri, 6 Dec 2002 07:54:06 -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 HAA04173 for ; Fri, 6 Dec 2002 07:51:12 -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 gB6CrqF37795; Fri, 6 Dec 2002 13:53:53 +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 5E97F76696; Fri, 6 Dec 2002 13:51:45 +0100 (CET) Date: Fri, 06 Dec 2002 13:51:45 +0100 From: Juergen Quittek To: "Harrington, David" , midcom@ietf.org Subject: Re: [midcom] SNMPv3 Message-ID: <20890508.1039182705@[192.168.102.164]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA075905@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA075905@NHROCMBX1.ets.enterasys.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 David, -- Harrington, David wrote on 05 December 2002 20:28 -0500: > Hi, > > I just joined the midcom mailing list to review the discussions, and find some points that need clarification. I have preceded my comments with dbh: > > Juergen posted the following: > > I think for most MIDCOM transactions it would not be a problem to > fit all parameters into a single PDU. But the SNMP spec saying > that the order in which the sets are executed is not deterministic, > makes it hard to > 1. create a row for a new policy, > 2. fill all objects of the row, and > 3. set the row to be active (or enabled) > with a single PDU. Rather, I think three PDUs are required for > this. However, you can still provide atomicity, by having not impact > at all on the middlebox behavior after step 1 and 2 and then enabling > the policy int the atomic step 3. You can even add to the semantics > of step 3 that the entire row will be deleted, if step 3 fails. > > Juergen > > dbh: That is incorrect. The CreateAndGo status for RowStatus allows these steps to be processed in one SET request. See RFC2579. > When I wrote the statement above, I was aware of the CreateAndGo value for RowStatus. Yet, for two reasons I wrote the statement: 1. I did not consider this as an inter-operable feature of SNMP. Is it? I thought (so far) that the order in which multiple set operations within one PDU are processed is not determined (i.e. it is implementation specific). So, if you had 'set row status' and 'set object within the row' in one PDU, this would be fine if you start with 'set row status', but it would fail if you start with the other set operation, because the row does not yet exist. Only if the SNMP manager (the Midcom agent) knows about the implemented order in which set operations are executed at the SNMP agent (middlebox), the one PDU solution would work always well. But maybe I'm completely wrong and you can tell me where this problem is solved in the SNMPv3 standard track RFCs. 2. The discussion above is about Midcom transactions. Creating the row (by CreateAndGo or otherwise) is a pre-requisite for filling the objects in the row with values. Therefore, logically, the row creation must be performed before set actions on these objects can be performed. But then, setting the row to active must not happen before all other objects in the row are set properly, because setting it to active would request the middlebox to open the pinhole and/or address binding specified by the row. So, if I use create and go it the create part must be executed by the SNMP agent before setting the other objects of the row, while setting the row to active must - in the Midom case - be executed after setting the other objects of the row. Maybe I'm an ignorant, but even after reading the 8K description of RowStatus in RFC2579, I cannot clearly tell whether the behavior I described is the one that RFC2579 requires. Again, I would be happy if you could teach me why I'm wrong. Juergen > dbh > > David Harrington > Network Management Architect > Office of the CTO > Enterasys Networks > > _______________________________________________ > 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 Dec 6 08:03: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 IAA04561 for ; Fri, 6 Dec 2002 08:03:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6D5VR22032 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 08:05:31 -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 gB6D24v21932; Fri, 6 Dec 2002 08:02: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 gB6D18v21894 for ; Fri, 6 Dec 2002 08:01:08 -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 HAA04345 for ; Fri, 6 Dec 2002 07:58:14 -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 gB6D0xF38201; Fri, 6 Dec 2002 14:00:59 +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 3FF697D099; Fri, 6 Dec 2002 13:58:51 +0100 (CET) Date: Fri, 06 Dec 2002 13:58:51 +0100 From: Juergen Quittek To: Wes Hardaker , "Harrington, David" Cc: midcom@ietf.org Subject: Re: [midcom] SNMPv3 Message-ID: <21316531.1039183131@[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 Wes, -- Wes Hardaker wrote on 05 December 2002 22:52 -0800: >>>>>> On Thu, 5 Dec 2002 20:28:00 -0500, "Harrington, David" said: > > Juergen> I think for most MIDCOM transactions it would not be a problem to > Juergen> fit all parameters into a single PDU. But the SNMP spec saying > Juergen> that the order in which the sets are executed is not > Juergen> deterministic, > > FYI, the EOS working group is producing a document with SNMP write > transactions which do support transactional ordering if desired. IE, > within the new write PDU you can delete a row and replace it with new > contents in the same operation by ordering the transaction. Can you give me a reference to this document? I could not find it on the EOS charter page. Thank you, Juergen > > -- > Wes Hardaker > Network Associates Laboratories > _______________________________________________ > 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 Dec 6 08:07: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 IAA04663 for ; Fri, 6 Dec 2002 08:07:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6D9Ut22793 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 08:09:30 -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 gB6D63v22084; Fri, 6 Dec 2002 08:06: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 gB6D5Dv22015 for ; Fri, 6 Dec 2002 08:05:13 -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 IAA04536 for ; Fri, 6 Dec 2002 08:02:19 -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 gB6D5AF38488; Fri, 6 Dec 2002 14:05:10 +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 5A5756689F; Fri, 6 Dec 2002 14:03:02 +0100 (CET) Date: Fri, 06 Dec 2002 14:03:02 +0100 From: Juergen Quittek To: "Durham, David" , "'midcom@ietf.org'" Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Message-ID: <21567302.1039183382@[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 David, -- Durham, David wrote on 05 December 2002 14:32 -0800: > Given the information collected during the IAB nm-ws from operators showing > that SNMP isn't used for configuring much of anything, I would strongly > object to removing COPS-PR from consideration. The directionality of > connection establishment for COPS-PR is easily circumvented by running a > dual mode PEP/PDP at the middlebox. Also, IPSP functionality, DiffServ, Could you elaborate how this dual mode solution works? We are discussing solutions for some time already with Cedric and Kwok. So far there we did not discuss a solution that I would call "easy". Juergen > Access Control, and Framework PIBs are all there at the wgs disposal. It > seems to me to be the perfect match. > > -Dave > > PS. Where is XML over HTTP or BEEP in the consideration? That's the > direction the nm-community seems to be going these days. > _______________________________________________ > 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 Dec 6 08:23: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 IAA05125 for ; Fri, 6 Dec 2002 08:23:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6DPYu23498 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 08:25: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 gB6DP5v23460; Fri, 6 Dec 2002 08:25:05 -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 gB6DOHv23432 for ; Fri, 6 Dec 2002 08:24:17 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05077 for ; Fri, 6 Dec 2002 08:21:23 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gB6DMaAq011556 for midcom@ietf.org; Fri, 6 Dec 2002 08:22:36 -0500 (EST) Date: Fri, 6 Dec 2002 08:22:36 -0500 (EST) From: Scott Bradner Message-Id: <200212061322.gB6DMaAq011556@newdev.harvard.edu> To: midcom@ietf.org Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? 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 the information collected during the IAB nm-ws from operators showing > that SNMP isn't used for configuring much of anything, I would strongly > object to removing COPS-PR from consideration. I think the wrong mesage is being understood here - it is not that operators don't use SNMP per se - its that operators do not use any configuration protocol of this type - they use command line and expect scripts i.e., there is no indication that the operators who do not use SNMP would be interested in using COPS-PR COPS-PR and SNMP should be discussed on their merits not on what operators may or may not do with SNMP (or COPS-PR) Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 09:41:29 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 JAA07904 for ; Fri, 6 Dec 2002 09:41:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6EhrC28683 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 09:43:53 -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 gB6EeIv28525; Fri, 6 Dec 2002 09:40:18 -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 gB6Ed6v28431 for ; Fri, 6 Dec 2002 09:39:06 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07771 for ; Fri, 6 Dec 2002 09:36:11 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6Ecx309244; Fri, 6 Dec 2002 06:39:00 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6EdB712942; Fri, 6 Dec 2002 08:39:12 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 08:38:58 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB40@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Durham, David'" , "'midcom@ietf.org'" Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 08:38:55 -0600 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: , Dave, With Regards to your PS: >PS. Where is XML over HTTP or BEEP in the consideration? That's the >direction the nm-community seems to be going these days. As stated in the protocol evaluation document, only the protocols put forth at the time this process began (March/April timeframe) were considered. There were no volunteers for the evaluation to inclue XML over HTTP or BEEP, thus they're out of scope for this discussion. Regards, Mary. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 10:10: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 KAA09322 for ; Fri, 6 Dec 2002 10:10:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FCVo30949 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 10:12:31 -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 gB6FC8v30941; Fri, 6 Dec 2002 10:12: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 gB6FBKv30911 for ; Fri, 6 Dec 2002 10:11:20 -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 KAA09268 for ; Fri, 6 Dec 2002 10:08:25 -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 gB6FBGF47137; Fri, 6 Dec 2002 16:11:16 +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 5C5286FC07; Fri, 6 Dec 2002 16:09:08 +0100 (CET) Date: Fri, 06 Dec 2002 16:09:08 +0100 From: Juergen Quittek To: Mary Barnes , "'Durham, David'" , "'midcom@ietf.org'" Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Message-ID: <29133281.1039190948@[192.168.102.164]> In-Reply-To: <1B54FA3A2709D51195C800508BF9386A05A7CB40@zrc2c000.us.nortel.com> References: <1B54FA3A2709D51195C800508BF9386A05A7CB40@zrc2c000.us.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 Mary, -- Mary Barnes wrote on 06 December 2002 08:38 -0600: > Dave, > > With Regards to your PS: >> PS. Where is XML over HTTP or BEEP in the consideration? That's the >> direction the nm-community seems to be going these days. > > As stated in the protocol evaluation document, only the protocols put forth > at the time this process began (March/April timeframe) were considered. > There were no volunteers for the evaluation to inclue XML over HTTP or BEEP, > thus they're out of scope for this discussion. So, you say even if someone showed that XML over HTTPS is the perfect solution, the working group would ignore it? Juergen > > Regards, > Mary. > > > _______________________________________________ > 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 Dec 6 10:30: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 KAA10285 for ; Fri, 6 Dec 2002 10:30:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FWPI31653 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 10:32:25 -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 gB6FV6v31595; Fri, 6 Dec 2002 10:31: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 gB6FUXv31557 for ; Fri, 6 Dec 2002 10:30:33 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10162 for ; Fri, 6 Dec 2002 10:27:36 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6FUO325848; Fri, 6 Dec 2002 07:30:24 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6FUZ729343; Fri, 6 Dec 2002 09:30:36 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 09:30:22 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB42@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Juergen Quittek'" , "'Durham, David'" , "'midcom@ietf.org'" Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 09:30:20 -0600 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: , Juergen, I should let Melinda respond, but I'll at least reply as to how I understand the process and current charter (along with some of my own opinions). My understanding is that the WG must first come to consensus that none of the protocols that have been evaluated are suitable before we can move to the next step. Realistically when we started the process, we could only cover the protocols for which we had volunteers to do the evaluation. Start of my opinions: If you're suggesting we go through another round of evaluating existing protocol proposals, then I'd have to disagree as I don't think we've honestly accomplished much over the past 9 months except to prove that there are a wide range of opinions and views on which protocol best fits the problem domain. We don't have any metrics by which to exclude any of the protocols other than the (hopefully) educated opinions and WG concensus. Unless we define and prioritize some metrics for making a selection or some of the given protocol defenders just give up, I can't see us ever agreeing to selecting one of the 4 remaining protocols, although I think we'd get the least objections to the removal of megaco from consideration. My opinion is that we're never going to agree that only one of the remaining protocols is suitable as there appear to be very strong supporters for at least 2 of them. The current charter states that "In the unlikely case that one is not found to be suitable, the working group will undertake development of a new protocol." Perhaps we need to discuss amending the charter to deal with the case that one or more are found to be suitable, but not ideal. They have all shortcomings and issues, which we've endlessly debated as to whether they're minor or major, with applicability to the MIDCOM framework and/or requirements. Mary. -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Friday, December 06, 2002 9:09 AM To: Barnes, Mary [NGC:B602:EXCH]; 'Durham, David'; 'midcom@ietf.org' Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Mary, -- Mary Barnes wrote on 06 December 2002 08:38 -0600: > Dave, > > With Regards to your PS: >> PS. Where is XML over HTTP or BEEP in the consideration? That's the >> direction the nm-community seems to be going these days. > > As stated in the protocol evaluation document, only the protocols put forth > at the time this process began (March/April timeframe) were considered. > There were no volunteers for the evaluation to inclue XML over HTTP or BEEP, > thus they're out of scope for this discussion. So, you say even if someone showed that XML over HTTPS is the perfect solution, the working group would ignore it? Juergen > > Regards, > Mary. > > > _______________________________________________ > 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 Dec 6 10:34: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 KAA10505 for ; Fri, 6 Dec 2002 10:34:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FaVw31890 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 10:36:31 -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 gB6FX3v31711; Fri, 6 Dec 2002 10:33: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 gB6FWxv31691 for ; Fri, 6 Dec 2002 10:32:59 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10299 for ; Fri, 6 Dec 2002 10:30:04 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 10:32:55 -0500 Message-ID: <5001C86452603F41820378E167091F07EED985@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'midcom@ietf.org'" Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 10:31:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I think I made that clear in previous e-mails, but just for clarity sake... As an individual NOT being one of the authors of the COPS evaluation, I agree with Dave and strongly object to remove COPS/COPS-PR from consideration. Personally, in addition to the various points emphasized in the protocol assessment document and the (excellent) point made by Dave, my main line of reasoning is to think to a bigger picture, and to add that we should: a) not exclude the stateful-policy-server-oriented architectures that I mentioned before (either driven by off-path signaling -ala SIP- or by in-path signaling -ala RSVP/NSIS-) b) allow the dynamic setting of middlebox rules to include not only nat/fw rules, but also Diffserv/QoS rules (for which COPS/COPS-PR and the PIBs mentioned by Dave can be leveraged on) This being said, I also think that allowing COPS as a possible answer does not necessarily imply to exclude other solutions which certainly have their own distinct value (e.g. SNMPv3). Tx Jerome -----Original Message----- From: Durham, David [mailto:david.durham@intel.com] Sent: Thursday, December 05, 2002 5:33 PM To: 'midcom@ietf.org' Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Given the information collected during the IAB nm-ws from operators showing that SNMP isn't used for configuring much of anything, I would strongly object to removing COPS-PR from consideration. The directionality of connection establishment for COPS-PR is easily circumvented by running a dual mode PEP/PDP at the middlebox. Also, IPSP functionality, DiffServ, Access Control, and Framework PIBs are all there at the wgs disposal. It seems to me to be the perfect match. -Dave _______________________________________________ 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 Dec 6 10:36:17 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 KAA10650 for ; Fri, 6 Dec 2002 10:36:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FcgB00332 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 10:38:42 -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 gB6FcLv00304; Fri, 6 Dec 2002 10:38:21 -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 gB6Faiv31906 for ; Fri, 6 Dec 2002 10:36:44 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10499 for ; Fri, 6 Dec 2002 10:33:48 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA04234 for ; Fri, 6 Dec 2002 10:48:49 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma004205; Fri, 6 Dec 02 10:48:29 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 06 Dec 2002 10:36:37 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 10:36:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 Date: Fri, 6 Dec 2002 10:36:37 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA075908@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 Thread-Index: AcKdJpyHTF5ae9E4T52B1PVTOACMzAAE+7eg From: "Harrington, David" To: X-OriginalArrivalTime: 06 Dec 2002 15:36:37.0627 (UTC) FILETIME=[43D31CB0:01C29D3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6Faiv31907 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 Hi Juergen, SETs are done "as if simultaneous", so creating the row, filling the values, and activating the row can all occur in one CreateAndGo operation. I have worked on applications that used CreateAndGo to create, fill, and activate rows with no problem across multiple vendors' devices. Implementations of RowStatus are required to support CreateAndGo OR CreateAndWait or both. As a result, some implementations do not support the CreateAndGo option or the CreateAndWait option. Typically, a subroutine is developed that tries the CreateAndGo approach first, and if that fails, then the CreateAndWait option is used. You correctly pointed out that a multi-PDU transaction would have no impact until the row was made active, using the CreateAndWait/Active settings of RowStatus. dbh > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Friday, December 06, 2002 7:52 AM > To: Harrington, David; midcom@ietf.org > Subject: Re: [midcom] SNMPv3 > > > David, > > -- Harrington, David wrote on 05 December 2002 20:28 -0500: > > > Hi, > > > > I just joined the midcom mailing list to review the > discussions, and find some points that need clarification. I > have preceded my comments with dbh: > > > > Juergen posted the following: > > > > I think for most MIDCOM transactions it would not be a problem to > > fit all parameters into a single PDU. But the SNMP spec saying > > that the order in which the sets are executed is not deterministic, > > makes it hard to > > 1. create a row for a new policy, > > 2. fill all objects of the row, and > > 3. set the row to be active (or enabled) > > with a single PDU. Rather, I think three PDUs are required for > > this. However, you can still provide atomicity, by having not impact > > at all on the middlebox behavior after step 1 and 2 and > then enabling > > the policy int the atomic step 3. You can even add to the semantics > > of step 3 that the entire row will be deleted, if step 3 fails. > > > > Juergen > > > > dbh: That is incorrect. The CreateAndGo status for > RowStatus allows these steps to be processed in one SET > request. See RFC2579. > > > > When I wrote the statement above, I was aware of the > CreateAndGo value for > RowStatus. Yet, for two reasons I wrote the statement: > > 1. I did not consider this as an inter-operable feature of > SNMP. Is it? > I thought (so far) that the order in which multiple set operations > within one PDU are processed is not determined (i.e. it is > implementation specific). So, if you had 'set row status' and 'set > object within the row' in one PDU, this would be fine if you start > with 'set row status', but it would fail if you start with > the other > set operation, because the row does not yet exist. Only if the > SNMP manager (the Midcom agent) knows about the implemented order > in which set operations are executed at the SNMP agent (middlebox), > the one PDU solution would work always well. > But maybe I'm completely wrong and you can tell me where this > problem is solved in the SNMPv3 standard track RFCs. > > 2. The discussion above is about Midcom transactions. Creating the row > (by CreateAndGo or otherwise) is a pre-requisite for filling the > objects in the row with values. Therefore, logically, the > row creation > must be performed before set actions on these objects can > be performed. > But then, setting the row to active must not happen before > all other > objects in the row are set properly, because setting it to active > would request the middlebox to open the pinhole and/or > address binding > specified by the row. So, if I use create and go it the > create part > must be executed by the SNMP agent before setting the > other objects of > the row, while setting the row to active must - in the Midom case - > be executed after setting the other objects of the row. > Maybe I'm an > ignorant, but even after reading the 8K description of RowStatus in > RFC2579, I cannot clearly tell whether the behavior I > described is the > one that RFC2579 requires. Again, I would be happy if you could > teach me why I'm wrong. > > Juergen > > > > dbh > > > > David Harrington > > Network Management Architect > > Office of the CTO > > Enterasys Networks > > > > _______________________________________________ > > 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 Dec 6 10:46: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 KAA11177 for ; Fri, 6 Dec 2002 10:46:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Fmg900893 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 10:48:42 -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 gB6Fm8v00878; Fri, 6 Dec 2002 10:48: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 gB6Flxv00855 for ; Fri, 6 Dec 2002 10:47:59 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11132 for ; Fri, 6 Dec 2002 10:45:03 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 6 Dec 2002 10:47:55 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2485C3@zoe.office.snowshore.com> Thread-Topic: H.248 for midcom? Not. Thread-Index: AcKdMFwMS26HPPqaSn6P3hz3GgLU6w== From: "Eric Burger" To: "IETF Midcom (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6Flxv00856 Subject: [midcom] H.248 for midcom? Not. 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 Reviewing the MIDCOM protocol evaluation document, I had some questions about the H.248 (megaco) analysis. Requirement 2.1.3, "Middlebox can relate to multiple Agents", refers to the ability for a set of agents to manipulate (in H.248 parlance) the same end-point. It is true, as described in the document, that one can partition a media gateway into multiple virtual media gateways (VMG). By design, H.248 restricts a one-to-one association between a VMG and an agent. In addition, AFAIK the standard H.248 model has no possibility for VMG's to have the same end-points. This is an architectural feature of H.248. Even if you "extended" H.248 to allow the same ephemeral end-point to be addressed by two VMG's, it would, by definition, have different names. Thus, I do not understand how H.248 could possibly meet this requirement. In fact, the response to Requirement 2.1.4 highlights this issue. H.248 is deterministic in the face of multiple requests because it cannot have them. Requirement 2.1.12: The biggest leap of faith is the proposal of a MIDCOM Ruleset Package. If we stuck with the H.248 master-slave model, I would expect rule processing to occur at the MGC (agent). I can't envision how to implement a rule set end-point entity. It seems to be rather foreign to the whole H.248 framework. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 10:46: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 KAA11199 for ; Fri, 6 Dec 2002 10:46:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FnIM00953 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 10:49: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 gB6Fn2v00945; Fri, 6 Dec 2002 10:49:02 -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 gB6Fm1v00868 for ; Fri, 6 Dec 2002 10:48:01 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11143 for ; Fri, 6 Dec 2002 10:45:06 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 6 Dec 2002 10:47:58 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2485C5@zoe.office.snowshore.com> Thread-Topic: Time for a Time-Out? Thread-Index: AcKdM2nD2yYa/6HoQrqclBCeFFE9qw== From: "Eric Burger" To: "IETF Midcom (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6Fm1v00869 Subject: [midcom] Time for a Time-Out? 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'm taking off my IETF hat for a moment and putting on my corporate hat (you know, the one that pays the bills). H.248 would be the easiest protocol for me to implement. For a midcom-like box, it should scale well. Unfortunately (see my posting on H.248), I don't see how it can meet the midcom requirements. SNMPv3 requires a lot of CPU processing. I can put lots of CPUs into my box. That means choosing SNMPv3 would put me at a competitive advantage. It just seems to be the wrong thing to do. I don't know about COPS et. al. I'm sure everything has a fatal flaw. Last time I looked, the IETF is the organization that does protocols. Why do we have this aversion to creating a protocol? Because of marketplace realities, I have to build a proprietary protocol to make something that works and scales. Now let's look at midcom and progress to date. It has been over a year, and the work group really hasn't produced anything of substance. There is still discussion on the list about the requirements. At the rate we're going, I don't expect that we will produce anything in the coming year, either. My modest proposal: let's bounce the whole problem to the IRTF, where we can probe the theory, get some working implementations, and do some bake-offs. Then we can come back to the IETF to polish it off. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 10:50: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 KAA11303 for ; Fri, 6 Dec 2002 10:50:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FqTE01036 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 10:52:29 -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 gB6Fn1v00926; Fri, 6 Dec 2002 10:49:01 -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 gB6Fm0v00864 for ; Fri, 6 Dec 2002 10:48:00 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11136 for ; Fri, 6 Dec 2002 10:45:05 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 10:47:56 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2485C4@zoe.office.snowshore.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKca3xXCLC/v784Q+CMbpsgNxfaMAAxS28A From: "Eric Burger" To: "Martin Stiemerling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6Fm0v00865 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 My bad feeling? Performance. I can see SNMPv3 working for a residential or SOHO gateway, where there will be a few transactions per day. I might be able to see SNMPv3 working for a small enterprise gateway, where there will be a few transaction per hour. I can't imagine using SNMPv3 SETs for a large enterprise or inter-service provider gateway, where there will be a number of transactions per minute. We've done the math, and you need a LOT of processing power to support such a rate. > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Thursday, December 05, 2002 9:24 AM > To: snmpv3@lists.tislabs.com > Cc: midcom@ietf.org > Subject: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > [please keep me in the recipient list, since I'm not subscribed to > snmvp3 list] > > Hi, > > as you may have heard: the MIDCOM WG is currently doing a protocol > evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is > amongst these candidates (diameter, cops(-pr), megaco). > Would you strongly recommend to use SNMPv3 as the MIDCOM protocol > without having a bad feeling? Actually there are only a few > pro and cons > discussed so far. > > Thanks in advance > Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 11:23: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 LAA12522 for ; Fri, 6 Dec 2002 11:23:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6GPRN03148 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 11:25:27 -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 gB6GORv03098; Fri, 6 Dec 2002 11:24:27 -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 gB6GNrv03060 for ; Fri, 6 Dec 2002 11:23:53 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12462 for ; Fri, 6 Dec 2002 11:20:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB6GNoYH013215; Fri, 6 Dec 2002 11:23:50 -0500 (EST) Message-ID: <3DF0CF13.60102@dynamicsoft.com> Date: Fri, 06 Dec 2002 11:23:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "IETF Midcom (E-mail)" Subject: Re: [midcom] Time for a Time-Out? References: <4A3384433CE2AB46A63468CB207E209D2485C5@zoe.office.snowshore.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've personally been silent on all of this stuff for quite some time. To be honest, that is primarily due to my frustration at the general lack of progress and amazing circuitousness (is that a word) of the path we have taken to completion of this work. Some responses inline. Eric Burger wrote: > Last time I looked, the IETF is the organization that does protocols. > Why do we have this aversion to creating a protocol? Because of > marketplace realities, I have to build a proprietary protocol to make > something that works and scales. > > Now let's look at midcom and progress to date. It has been over a > year, Oh, much longer than that. I recall the foglamps bof meeting in Adelaide in March 2000, which is almost three years ago. Most groups produce real protocols in faster than three years after their bof. > and the work group really hasn't produced anything of > substance. There is still discussion on the list about the > requirements. At the rate we're going, I don't expect that we will > produce anything in the coming year, either. I agree. I think it is time for a change in direction. Right now, we are on a path to fail. There are folks in each protocol camp who will clearly not budge. There is also, I think, a good contingent (myself included) who would rather build a new, simple-as-possible protocol for the task at hand. There is also a large contingent that is tired and no longer cares. Indeed, the participation in list discussion has dropped tremendously since this evaluation process began. Where is everyone? I would like to propose that the group consider some radical actions at this point. Short of that, we will probbaly fail to produce anything at all. I do not know what the right thing is, but here are some ideas: 1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new protocol people all develop their own protocols. Make the semantics doc a mandatory thing, so that each protocol must provide the semantics described there, and show a mapping. THis is akin to the CPIM approach. THen, let the market pick a winner. Three is better than zero, I guess. 2. Shut down: Just give up. Close the group. This interface remains proprietary. We have things like TURN, ALGs and eventually nsis, which is (I think) the right answer. Of course nsis is probably 5 years away from useful deployment. 3. Move to IRTF: As Eric suggests. 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and we do that (seems unlikely but I throw it out for consideration). 5. New protocol: do a new one from scratch. Other ideas? I would favor approach 5 first, then 1, then 4, then 2, then 3. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 11:30:39 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 LAA12795 for ; Fri, 6 Dec 2002 11:30:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6GX4x03530 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 11:33:04 -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 gB6GW8v03487; Fri, 6 Dec 2002 11:32: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 gB6GVBv03440 for ; Fri, 6 Dec 2002 11:31:11 -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 LAA12691 for ; Fri, 6 Dec 2002 11:28:15 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB6GV50R022598; Fri, 6 Dec 2002 08:31:05 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD70621; Fri, 6 Dec 2002 08:31:04 -0800 (PST) Message-Id: <200212061631.ABD70621@mira-sjc5-c.cisco.com> To: "Eric Burger" cc: "IETF Midcom (E-mail)" From: Melinda Shore Subject: Re: [midcom] Time for a Time-Out? In-Reply-To: Message from "Eric Burger" of "Fri, 06 Dec 2002 10:47:58 EST." <4A3384433CE2AB46A63468CB207E209D2485C5@zoe.office.snowshore.com> Date: Fri, 06 Dec 2002 11:31:04 -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: , > My modest proposal: let's bounce the whole problem to the > IRTF, where we can probe the theory, get some working > implementations, and do some bake-offs. Then we can come > back to the IETF to polish it off. I think there's a broader context here and that's that this is an instance of off-path signaling, which is getting more attention these days for better or worse (mostly the latter). There's been some agitation from a subset of people interested in QoS for the IETF to take on off-path QoS signaling, and it may be worthwhile to kick all of it out to the IRTF to develop a better understanding of some of the issues (and I think there's a tendency for off-path signaling advocates, including us, to be glib about some problems that are actually extremely difficult, like routing and topology). That said, there's a real problem to be solved here, and there's some real-world implementation experience in the form of Aravox's (RIP) product and UPnP. Although I do believe there are better ways to solve this problem I also recognize that there are environments in which this *is* the right answer, and I think the only really hard part is the process of selecting a protocol. It is my fondest but likely fruitless hope that people will *not* see this as an opportunity to try to rally some additional support for their otherwise largely unpopular protocols, but rather understand that we have a problem to solve and that we need to choose the most suitable tools to do so. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 11:36:37 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 LAA13054 for ; Fri, 6 Dec 2002 11:36:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Gd2704436 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 11:39:02 -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 gB6Gc6v04375; Fri, 6 Dec 2002 11:38: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 gB6GbJv04180 for ; Fri, 6 Dec 2002 11:37:19 -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 LAA12905 for ; Fri, 6 Dec 2002 11:34:23 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6Gb7K0008994; Fri, 6 Dec 2002 08:37:07 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD70885; Fri, 6 Dec 2002 08:37:05 -0800 (PST) Message-Id: <200212061637.ABD70885@mira-sjc5-c.cisco.com> To: Jonathan Rosenberg cc: Eric Burger , "IETF Midcom (E-mail)" From: Melinda Shore Subject: Re: [midcom] Time for a Time-Out? In-Reply-To: Message from Jonathan Rosenberg of "Fri, 06 Dec 2002 11:23:47 EST." <3DF0CF13.60102@dynamicsoft.com> Date: Fri, 06 Dec 2002 11:37:04 -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: , > 5. New protocol: do a new one from scratch. > > Other ideas? I would favor approach 5 first, then 1, then 4, then 2, > then 3. I can think of at least four existing "from scratch" midcom protcols, and I don't see the process of sorting through them as being any easier than sorting through COPS, SNMP, megaco, and Diameter. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 11:41: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 LAA13272 for ; Fri, 6 Dec 2002 11:41:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Gi8b04726 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 11:44:08 -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 gB6GhDv04697; Fri, 6 Dec 2002 11:43: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 gB6GgZv04643 for ; Fri, 6 Dec 2002 11:42:35 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13181 for ; Fri, 6 Dec 2002 11:39:38 -0500 (EST) Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id gB6GgL602977; Fri, 6 Dec 2002 08:42:21 -0800 To: Juergen Quittek Cc: "Harrington, David" , midcom@ietf.org Subject: Re: [midcom] SNMPv3 References: <21316531.1039183131@[192.168.102.164]> From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Fri, 06 Dec 2002 08:42:21 -0800 In-Reply-To: <21316531.1039183131@[192.168.102.164]> (Juergen Quittek's message of "Fri, 06 Dec 2002 13:58:51 +0100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) 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: , >>>>> On Fri, 06 Dec 2002 13:58:51 +0100, Juergen Quittek said: Juergen> Can you give me a reference to this document? Juergen> I could not find it on the EOS charter page. The draft hasn't been officially published as a WG item, but will be in the next couple of weeks (the end of next week if I'm lucky). In the mean time, here is a copy of the draft that was discussed at the EOS meeting in Atlanta: http://eos.hardakers.net/draft-hardaker-eos-oops-02pre.txt I'm particularly interested in people's thoughts on the write operations contained within, as I haven't gotten much feedback on the subject (I've gotten a lot on the get operations). I can tell you that the write semantics contained in the document are in line with what you've expressed a need for. Warning: document far from complete but should be better when it's first published as a WG item. The PDU structures have changed slightly as well since then, but the concepts are still t same. -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 11:52:21 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 LAA13586 for ; Fri, 6 Dec 2002 11:52:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6GskG05222 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 11:54: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 gB6Gp9v05005; Fri, 6 Dec 2002 11:51: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 gB6GkZv04846 for ; Fri, 6 Dec 2002 11:46:35 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13350 for ; Fri, 6 Dec 2002 11:43:38 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6GkRw20316; Fri, 6 Dec 2002 08:46:27 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6GkdR22983; Fri, 6 Dec 2002 10:46:39 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 10:46:26 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB45@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Jonathan Rosenberg'" , Eric Burger Cc: "IETF Midcom (E-mail)" Subject: RE: [midcom] Time for a Time-Out? Date: Fri, 6 Dec 2002 10:46:25 -0600 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: , Per my response to the SNMP thread earlier this morning, I can't say that I disagree with Jonathan's views and my prioritization of his suggestions for ideas on going forward would be similar. I would put 1 (let the market decide) or 5 (new protocol) first. However, I would think 2 (leave it proprietary) would be preferable to 4 (dictated by IESG), since I would think alot of existing 2's are some variation on the proposed 1s or the new protocols (5s). Option 3 (IRTF) might have been a good choice coming out of the foglamps bof, but I think it's way too late for that or we could do 3, obviously in parallel with 2. Mary. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, December 06, 2002 10:24 AM To: Eric Burger Cc: IETF Midcom (E-mail) Subject: Re: [midcom] Time for a Time-Out? I've personally been silent on all of this stuff for quite some time. To be honest, that is primarily due to my frustration at the general lack of progress and amazing circuitousness (is that a word) of the path we have taken to completion of this work. Some responses inline. Eric Burger wrote: > Last time I looked, the IETF is the organization that does protocols. > Why do we have this aversion to creating a protocol? Because of > marketplace realities, I have to build a proprietary protocol to make > something that works and scales. > > Now let's look at midcom and progress to date. It has been over a > year, Oh, much longer than that. I recall the foglamps bof meeting in Adelaide in March 2000, which is almost three years ago. Most groups produce real protocols in faster than three years after their bof. > and the work group really hasn't produced anything of > substance. There is still discussion on the list about the > requirements. At the rate we're going, I don't expect that we will > produce anything in the coming year, either. I agree. I think it is time for a change in direction. Right now, we are on a path to fail. There are folks in each protocol camp who will clearly not budge. There is also, I think, a good contingent (myself included) who would rather build a new, simple-as-possible protocol for the task at hand. There is also a large contingent that is tired and no longer cares. Indeed, the participation in list discussion has dropped tremendously since this evaluation process began. Where is everyone? I would like to propose that the group consider some radical actions at this point. Short of that, we will probbaly fail to produce anything at all. I do not know what the right thing is, but here are some ideas: 1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new protocol people all develop their own protocols. Make the semantics doc a mandatory thing, so that each protocol must provide the semantics described there, and show a mapping. THis is akin to the CPIM approach. THen, let the market pick a winner. Three is better than zero, I guess. 2. Shut down: Just give up. Close the group. This interface remains proprietary. We have things like TURN, ALGs and eventually nsis, which is (I think) the right answer. Of course nsis is probably 5 years away from useful deployment. 3. Move to IRTF: As Eric suggests. 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and we do that (seems unlikely but I throw it out for consideration). 5. New protocol: do a new one from scratch. Other ideas? I would favor approach 5 first, then 1, then 4, then 2, then 3. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 Dec 6 12:17: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 MAA14445 for ; Fri, 6 Dec 2002 12:17:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6HJYr07291 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 12:19: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 gB6HFWv07073; Fri, 6 Dec 2002 12:15:32 -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 gB6HCkv06917 for ; Fri, 6 Dec 2002 12:12:46 -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 MAA14188 for ; Fri, 6 Dec 2002 12:09:50 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB6HCF0J002169; Fri, 6 Dec 2002 09:12:15 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD72727; Fri, 6 Dec 2002 09:12:33 -0800 (PST) Message-Id: <200212061712.ABD72727@mira-sjc5-c.cisco.com> To: Juergen Quittek cc: Mary Barnes , "'Durham, David'" , "'midcom@ietf.org'" From: Melinda Shore Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? In-Reply-To: Message from Juergen Quittek of "Fri, 06 Dec 2002 16:09:08 +0100." <29133281.1039190948@[192.168.102.164]> Date: Fri, 06 Dec 2002 12:12:33 -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: , > So, you say even if someone showed that XML over HTTPS is the perfect > solution, the working group would ignore it? No - we absolutely don't value/privilege process over technical soundness. However, we do need to push on ahead if we're going to get our work done, and I'm hoping against hope that people will start showing greater willingness to compromise. Each of us needs to think hard about what the consequences would be for the working group (not our employers) if midcom were to select a protocol other than the one we individually favor. Consensus-based decision making simply does not work - at all - in the face of inflexibility and rigidity on the part of participants. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 13:05: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 NAA16988 for ; Fri, 6 Dec 2002 13:05:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6I81V10721 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 13:08: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 gB6I5Tv10009; Fri, 6 Dec 2002 13:05: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 gB6I4dv09961 for ; Fri, 6 Dec 2002 13:04:39 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16754 for ; Fri, 6 Dec 2002 13:01:41 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gB6HxlJ01130 for ; Fri, 6 Dec 2002 17:59:47 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gB6I6wJ18984 for ; Fri, 6 Dec 2002 18:06:58 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002120610052511159 for ; Fri, 06 Dec 2002 10:05:25 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 10:04:33 -0800 Message-ID: From: "Durham, David" To: midcom@ietf.org Subject: RE: [midcom] SNMPv3 Date: Fri, 6 Dec 2002 10:04:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I don't think we want to imply that a new (yet non-existent) version of SNMP is required to meet the midcom requirements. -Dave > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > Warning: document far from complete but should be better when it's > first published as a WG item. The PDU structures have changed > slightly as well since then, but the concepts are still t same. > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 13:08: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 NAA17139 for ; Fri, 6 Dec 2002 13:08:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6IBCT10839 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 13:11:12 -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 gB6I7Dv10517; Fri, 6 Dec 2002 13:07: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 gB6I6Zv10058 for ; Fri, 6 Dec 2002 13:06:35 -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 NAA16851 for ; Fri, 6 Dec 2002 13:03:38 -0500 (EST) 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 gB6I6NM07759; Fri, 6 Dec 2002 13:06:23 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 13:06:23 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DFFA@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Eric Burger'" , "IETF Midcom (E-mail)" Subject: RE: [midcom] H.248 for midcom? Not. Date: Fri, 6 Dec 2002 13:06:20 -0500 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: , Well ... This is just for conversation: I've never been terribly happy with the distortions required to the Megaco model to make it work for midcom. On the other hand, Megaco is not a pure master/slave protocol, so your final words bother me a bit. The fact the MG is the boss when it comes to starting up the control association is actually one of Megaco's black marks in this application. The problems with the Megaco model are clear, and I summarize them here as a review in the light of the new information provided by the semantics work. According to the semantics we have established, the life of a Policy Rule is independent of the life of the Midcom session in which it was created. Since the Midcom session is identified with the Megaco control association, the modelling of Policy Rules in Megaco terms has to allow for such independent existence. The Midcom requirement to allow multiple agents to have access to the same Policy Rule has no explicit constraint, as far as I can recall. Our semantics treat this as a matter of transactional exclusion on the one hand and policy on the other. What is missing is any statement that the owner of the Policy Rule has to have terminated its session before another Agent can have access to the rule. I'm not proposing to add such a statement here. But the implication for Megaco is that a Policy Rule cannot be identified directly with either a Termination or a Context. We (the Megaco authors) have finessed this by positing a resource layer, manipulated by properties of terminations created for that purpose. The fact is that the resources (i.e. Policy Rules) are a new architectural element, actually orthogonal to anything else Megaco offers. IF the missing constraint described in the previous paragraph were added, a Policy Rule could be identified straightforwardly with a specific Megaco Termination. At that point, I think you would find that the fit with Megaco is pretty good, but of course, there would be a lot of excess baggage. The problem with the direction of session initiation would remain. > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Friday, December 06, 2002 10:48 AM > To: IETF Midcom (E-mail) > Subject: [midcom] H.248 for midcom? Not. > > > Reviewing the MIDCOM protocol evaluation document, I had some > questions about the H.248 (megaco) analysis. > > Requirement 2.1.3, "Middlebox can relate to multiple Agents", > refers to the ability for a set of agents to manipulate (in > H.248 parlance) the same end-point. It is true, as described > in the document, that one can partition a media gateway into > multiple virtual media gateways (VMG). By design, H.248 > restricts a one-to-one association between a VMG and an > agent. In addition, AFAIK the standard H.248 model has no > possibility for VMG's to have the same end-points. This is > an architectural feature of H.248. Even if you "extended" > H.248 to allow the same ephemeral end-point to be addressed > by two VMG's, it would, by definition, have different names. > Thus, I do not understand how H.248 could possibly meet this > requirement. > > In fact, the response to Requirement 2.1.4 highlights this > issue. H.248 is deterministic in the face of multiple > requests because it cannot have them. > > Requirement 2.1.12: > The biggest leap of faith is the proposal of a MIDCOM Ruleset > Package. If we stuck with the H.248 master-slave model, I > would expect rule processing to occur at the MGC (agent). I > can't envision how to implement a rule set end-point entity. > It seems to be rather foreign to the whole H.248 framework. > _______________________________________________ > 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 Dec 6 13:18: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 NAA17568 for ; Fri, 6 Dec 2002 13:18:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6IKwq11221 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 13:20: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 gB6IK5v11173; Fri, 6 Dec 2002 13:20:05 -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 gB6IJAv11102 for ; Fri, 6 Dec 2002 13:19:10 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17471 for ; Fri, 6 Dec 2002 13:16:12 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gB6IH1528184 for ; Fri, 6 Dec 2002 18:17:01 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gB6IHHm26168 for ; Fri, 6 Dec 2002 18:17:18 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002120610151503421 for ; Fri, 06 Dec 2002 10:15:15 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 10:14:52 -0800 Message-ID: From: "Durham, David" To: "'Melinda Shore'" Cc: "IETF Midcom (E-mail)" Subject: RE: [midcom] Time for a Time-Out? Date: Fri, 6 Dec 2002 10:14:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Melinda, I think you should find some resolve in noting that PIBs and MIBs are much more alike than different. It's really just a protocol issue, I think the wg would be safe on the data model front with either COPS-PR or SNMP (a two for one?). In the case of megaco & diameter, however, the data models are fundamentally different. -Dave > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, December 06, 2002 8:37 AM > To: Jonathan Rosenberg > Cc: Eric Burger; IETF Midcom (E-mail) > Subject: Re: [midcom] Time for a Time-Out? > > > > 5. New protocol: do a new one from scratch. > > > > Other ideas? I would favor approach 5 first, then 1, then > 4, then 2, > > then 3. > > I can think of at least four existing "from scratch" midcom > protcols, and I don't see the process of sorting through > them as being any easier than sorting through COPS, SNMP, > megaco, and Diameter. > > 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 Dec 6 13:29:17 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 NAA18141 for ; Fri, 6 Dec 2002 13:29:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6IVi911789 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 13:31:44 -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 gB6IS6v11617; Fri, 6 Dec 2002 13:28: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 gB6IRRv11592 for ; Fri, 6 Dec 2002 13:27:27 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17883 for ; Fri, 6 Dec 2002 13:24:29 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA16856 for ; Fri, 6 Dec 2002 13:39:29 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma016760; Fri, 6 Dec 02 13:38:26 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 06 Dec 2002 13:26:31 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 13:26:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 13:26:29 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA07590D@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKdS5g5N6z3kdKqTMGcA77cGYAO1QAA3sfA From: "Harrington, David" To: Cc: "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 06 Dec 2002 18:26:31.0072 (UTC) FILETIME=[FF976200:01C29D54] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6IRRv11593 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 Hi, Let me respond as an evaluator, as SNMPv3 WG author/co-chair, and as a vendor. As an evaluator, I did not come into the evaluation process as a proponent of a protocol solution. I entered the process because I was asked by the O&M AD to verify that the document was factually accurate, and I found that there were some factual inaccuracies in the representation of SNMP capabilities. As an evaluator, I care that SNMPv3 is factually represented in this evaluation, but I don't care whether SNMPv3 is chosen as the MIDCOM protocol. As an author of SNMPv3, and co-chair of SNMPv3 WG, obviously it is always nice to see one's protocol chosen, so I cannot claim complete impartiality. But I also do not see MIDCOM as ever becoming the "killer app" that will help justify SNMP as a standard protocol. SNMPv3 is already full standard, and SNMP is already well justified for its troubleshooting and monitoring functionality, and arguably for its ability to create and modify configurations of specific functionality. So from this perspective I don't care if SNMPv3 becomes the MIDCOM protocol, and I don't think anybody else in the SNMPv3 community cares a great deal either (I am copying this message to the SNMPv3 WG so anybody who disagrees can respond). As a vendor, I don't care and I do care. My company produces network equipment that includes firewalls and NAT and IDS functionality, and other features that could benefit from a standard MIDCOM solution. As a vendor, we have no requirement that we use what this WG selects as the MIDCOM protocol, but if the IETF produces a useful standard that does not cost us much to support, we will likely implement the standard. I think it unlikely the market cares which is selected; our customers merely want us to produce something that solves their problems. So for those reasons, I do not care whether SNMPv3 becomes the MIDCOM protocol. The issue to a vendor is largely one of cost of implementation. We already support SNMPv3 and RADIUS, and we will probably support Diameter as an upgrade to RADIUS if our customers demand it (which so far they do not). Enterasys will probably never support COPS/PR or MEGACO. We already need to deal with the difficulties of balancing security across SNMPv3 and RADIUS (and other protocols), and the problems of balancing security across multiple protocols are significant. Adding an unnecessary protocol to our mix, and addressing the resulting combinatorial security concerns, would be very expensive. We would need to pass on those costs to our customers, who would prefer not to suffer price increases and not to have to learn new protocols to manage their networks when existing protocols could have been used. Therefore, as a vendor, I would much rather see the WG select a protocol that I already need to support and secure anyway, since it would make delivering product easier, and! would not cause price increases in our products. For those reasons, I would favor SNMPv3 first, and Diameter second. David Harrington Network Management Architect Office of the CTO Enterasys Networks > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, December 06, 2002 12:13 PM > To: Juergen Quittek > Cc: Mary Barnes; 'Durham, David'; 'midcom@ietf.org' > Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? > > > > So, you say even if someone showed that XML over HTTPS is > the perfect > > solution, the working group would ignore it? > > No - we absolutely don't value/privilege process over > technical soundness. However, we do need to push on ahead > if we're going to get our work done, and I'm hoping against > hope that people will start showing greater willingness to > compromise. Each of us needs to think hard about what the > consequences would be for the working group (not our > employers) if midcom were to select a protocol other than > the one we individually favor. Consensus-based decision > making simply does not work - at all - in the face of > inflexibility and rigidity on the part of participants. > > 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 Dec 6 13:37: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 NAA18581 for ; Fri, 6 Dec 2002 13:37:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6IeHg12677 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 13:40:17 -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 gB6IaKv11984; Fri, 6 Dec 2002 13:36:20 -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 gB6IZkv11960 for ; Fri, 6 Dec 2002 13:35:46 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18394 for ; Fri, 6 Dec 2002 13:32:48 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA17288 for ; Fri, 6 Dec 2002 13:47:48 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma017264; Fri, 6 Dec 02 13:47:38 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 06 Dec 2002 13:35:48 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 13:35:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 Date: Fri, 6 Dec 2002 13:35:47 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA07590E@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 Thread-Index: AcKdUpAL14T+WB2BRk2VJgdUfWnJOAAAtcKQ From: "Harrington, David" To: X-OriginalArrivalTime: 06 Dec 2002 18:35:48.0072 (UTC) FILETIME=[4B96D680:01C29D56] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6IZkv11961 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 Hi, I concur with David's observation. SNMPv3 is the protocol submitted for consideration, and it is submitted on the basis that no modifications to the protocol would be required. The EOS PDU structures are an extension to the protocol and are not part of the SNMPv3 submission. The only changes required for SNMPv3 support would be the development of appropriate MIBs. dbh > -----Original Message----- > From: Durham, David [mailto:david.durham@intel.com] > Sent: Friday, December 06, 2002 1:04 PM > To: midcom@ietf.org > Subject: RE: [midcom] SNMPv3 > > > I don't think we want to imply that a new (yet non-existent) > version of SNMP > is required to meet the midcom requirements. > > -Dave > > > -----Original Message----- > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > > > Warning: document far from complete but should be better when it's > > first published as a WG item. The PDU structures have changed > > slightly as well since then, but the concepts are still t same. > > > _______________________________________________ > 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 Dec 6 13:42: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 NAA18793 for ; Fri, 6 Dec 2002 13:42:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Ij3Z12837 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 13:45:03 -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 gB6IiCv12789; Fri, 6 Dec 2002 13:44: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 gB6Ihqv12773 for ; Fri, 6 Dec 2002 13:43:52 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18714 for ; Fri, 6 Dec 2002 13:40:54 -0500 (EST) Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id gB6Ihej03658; Fri, 6 Dec 2002 10:43:40 -0800 To: "Durham, David" Cc: midcom@ietf.org Subject: Re: [midcom] SNMPv3 References: From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Fri, 06 Dec 2002 10:43:40 -0800 In-Reply-To: ("Durham, David"'s message of "Fri, 6 Dec 2002 10:04:27 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) 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: , >>>>> On Fri, 6 Dec 2002 10:04:27 -0800 , "Durham, David" said: David> I don't think we want to imply that a new (yet non-existent) David> version of SNMP is required to meet the midcom requirements. Wasn't trying to say that we did. It's clear from the discussion that the requirements can be met, just not as optimally (hence the P+), from the existing PDUs. New ones would only provide greater benefit. -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 14:29: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 OAA20887 for ; Fri, 6 Dec 2002 14:29:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6JVQ815070 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 14:31:26 -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 gB6JUIv14996; Fri, 6 Dec 2002 14:30:18 -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 gB6JTjv14968 for ; Fri, 6 Dec 2002 14:29:45 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20745 for ; Fri, 6 Dec 2002 14:26:48 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 14:29:38 -0500 Message-ID: <5001C86452603F41820378E167091F07EED990@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "IETF Midcom (E-mail)" Subject: RE: [midcom] Time for a Time-Out? Date: Fri, 6 Dec 2002 14:28:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Jonathan, thanks for the reset & suggested approaches. Great idea. My view: 1. seems the way to go to me. Let people volunteer to extend existing SNMP-MIB & COPS-PIBs & Diameter-attributes to add NAT/FW rules (if missing from existing ipsp work). Or define new xIBs. If no volunteer for one protocol, well, be it. Maybe request at least reps from two companies/organizations as authors, just as a minimal check of industry support. Last but not least, allow maximum flexibility in architectures by helping a diverse approach. 2. don't think we should give up, this work is definitely useful. This being said, I'm wondering if this work would not benefit from being regrouped with some other IETF activities (e.g. ipsp and/or nsis). 3. seems even more circuitous than what happened in the past, isn't it? ;-) 4. er... I have reservations about a dictatorial process... 5. sounds to me that we suffer from having too many candidates as opposed to not enough. So I'm not sure why we'd reinvent the wheel. Also I can't reemphasize enough the importance of the "be part and be consistent with a bigger picture" goal, which implies to reuse some existing protocol infrastructure and benefit from existing information models. Tx Jerome -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, December 06, 2002 11:24 AM To: Eric Burger Cc: IETF Midcom (E-mail) Subject: Re: [midcom] Time for a Time-Out? [...] 1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new protocol people all develop their own protocols. Make the semantics doc a mandatory thing, so that each protocol must provide the semantics described there, and show a mapping. THis is akin to the CPIM approach. THen, let the market pick a winner. Three is better than zero, I guess. 2. Shut down: Just give up. Close the group. This interface remains proprietary. We have things like TURN, ALGs and eventually nsis, which is (I think) the right answer. Of course nsis is probably 5 years away from useful deployment. 3. Move to IRTF: As Eric suggests. 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and we do that (seems unlikely but I throw it out for consideration). 5. New protocol: do a new one from scratch. Other ideas? I would favor approach 5 first, then 1, then 4, then 2, then 3. -Jonathan R. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 15:24: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 PAA23011 for ; Fri, 6 Dec 2002 15:24:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6KQSe18456 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 15:26:28 -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 gB6KQ5v18407; Fri, 6 Dec 2002 15:26:05 -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 gB6KOav18331 for ; Fri, 6 Dec 2002 15:24:36 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22922 for ; Fri, 6 Dec 2002 15:21:39 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA27650 for ; Fri, 6 Dec 2002 15:36:38 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma027628; Fri, 6 Dec 02 15:35:43 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 06 Dec 2002 15:23:43 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 15:23:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 15:23:42 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA07590F@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKca3xXCLC/v784Q+CMbpsgNxfaMAAxS28AAAzR8/A= From: "Harrington, David" To: "Eric Burger" , "Martin Stiemerling" Cc: X-OriginalArrivalTime: 06 Dec 2002 20:23:43.0025 (UTC) FILETIME=[5EF64210:01C29D65] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6KOav18332 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 Hi Eric, You've done the math; can you share the math with us? I'd like to see the data to back up your assertion. Did you do comparable trials with the other protocols, whose data you could share? That data could be very valuable for the evaluation process. The amount of CPU processing will be dependent on a large number of variables, such as how many varbinds, which varbinds, what types of changes are being requested in the underlying implementation, which security model and mechanisms you choose, how many entries are in the tables you need to perform lookup on, implementation decisions about lookup algorithms, and so on. I'd be interested in seeing how much of the overhead is in the SNMP and how much is related to the non-SNMP aspects of the transactions and I'd like to see data for the other candidates as well, so we have real data to work with. dbh > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Friday, December 06, 2002 10:48 AM > To: Martin Stiemerling > Cc: midcom@ietf.org > Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > My bad feeling? Performance. > > I can see SNMPv3 working for a residential or SOHO gateway, > where there will be a few transactions per day. > > I might be able to see SNMPv3 working for a small enterprise > gateway, where there will be a few transaction per hour. > > I can't imagine using SNMPv3 SETs for a large enterprise or > inter-service provider gateway, where there will be a number > of transactions per minute. We've done the math, and you > need a LOT of processing power to support such a rate. > > > -----Original Message----- > > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > > Sent: Thursday, December 05, 2002 9:24 AM > > To: snmpv3@lists.tislabs.com > > Cc: midcom@ietf.org > > Subject: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > > > > [please keep me in the recipient list, since I'm not subscribed to > > snmvp3 list] > > > > Hi, > > > > as you may have heard: the MIDCOM WG is currently doing a protocol > > evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is > > amongst these candidates (diameter, cops(-pr), megaco). > > Would you strongly recommend to use SNMPv3 as the MIDCOM protocol > > without having a bad feeling? Actually there are only a few > > pro and cons > > discussed so far. > > > > Thanks in advance > > 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 Dec 6 16:14: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 QAA24652 for ; Fri, 6 Dec 2002 16:14:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6LGYM21358 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 16:16: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 gB6LFhv21290; Fri, 6 Dec 2002 16:15:43 -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 gB6LEpv21224 for ; Fri, 6 Dec 2002 16:14:51 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24573 for ; Fri, 6 Dec 2002 16:11:53 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 16:14:43 -0500 Message-ID: <5001C86452603F41820378E167091F07EED9A2@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'midcom@ietf.org'" Subject: RE: [midcom] framework models, related architectures , etc Date: Fri, 6 Dec 2002 16:12:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Juergen, yes, I absolutely agree with you. Practically speaking, I tend to believe the most typical scenario is a WAN uplink and a middlebox (and related agent) on either side (CPE gear used by enterprise or Edge Router used by Telco). Or an uplink between an access provider and an ISP. Then the topology is constrained enough that this "awareness" you mentioned is easy to achieve. And such "specific" scenario is rather common, to say the least (we all love broadband, don't we? ;-) I can see a couple of other scenarios with some reality on the field, but they are more contorted. Of course, they will all share the property you described. If somebody has another pretty common scenario in mind, I'm interested to be educated! This being said, I do agree with what Melinda stated in another e-mail. When promoting the use of "off-path" signaling and then an application endpoint/proxy of some sort pushing some policy rule on some "middlebox" on the data path, one can sometimes forget about the difficulty to locate the proper middlebox to act on. This only works for specific scenarios & topologies. Yet I continue to believe these scenarios are important enough that it's definitely worth the effort to develop good mechanisms for it. Tx Jerome -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Thursday, December 05, 2002 3:50 AM To: Moisand, Jerome; 'midcom@ietf.org' Subject: RE: [midcom] framework models, related architectures and protocol controversy Jerome, -- Moisand, Jerome wrote on 04 December 2002 18:34 -0500: > > Melinda, > > yes, I don't disagree with you, scenarios where a middlebox of some sort > would have to be dynamically provisioned for a given TCP/RTP session are > making VERY SPECIFIC assumptions about the IP topology. It looks to me that I'd like to clarify this "very specific" you used. The way I see it, the assumption is quite simple: The the set of agents involved in provisioning a given session needs to be aware of all relevant middleboxes that need to be configured for provisioning the session. The awareness may be shared in a way that each involved agent is only aware of a subset of the relevant middleboxes. I agree that this does not match the general idea behind the Internet architecture. It is much closer to telco-style architectures. Juergen > the only realistic scenarios are at a domain boundary, typically the point > where a service provider provides IP services (e.g. a WAN uplink). Then, > either on the service user side (e.g. a NAT/FW CPE device) or on the service > provider side (e.g. a BRAS device), the topology is constrained enough that > such scenario makes sense. > > This being said, such specific scenarios are so important to both service > users and service providers that I believe it's really the pain working on > such middlebox/dynamic-session-management stories. And as I pointed out, the > whole picture involves filtering, NATting, firewalling and Qos > differentiation. > > As to scaling, I hear the concern, but I'm not sure to entirely agree with > you. There are solutions nowadays which can scale pretty well by the > appropriate combinations of hardware & software. > > Finally, on the "protocol controversy" wording, I apologize if my wording > was a bit too aggressive. I have to say I'm a bit tired of the endless > discussion between SNMP, Diameter, COPS across multiple IETF work groups. I > tend to believe that all these protocols have a role to play, and we'd > better be flexible, and define MIBs, PIBs and Diameter attributes for > multiple functional areas (ok, when this makes "reasonable" sense, of > course, which is hard to define!), instead of spending too much time arguing > in an often religious way. I hope that I'll not get a flame on this > hopefully neutral statement... ;-) > > Ok, all this philosophy aside, I vote for Megaco for Midcom. Nah, just > kidding. > > Tx > Jerome > >> One of the unfortunate things that's happened in the IETF >> over the past years is the drift away from architectural >> frameworks that are idiomatic to IP - i.e. they interwork >> with IP, particularly routing and topology, really, really >> poorly. I personally think that midcom is one of these, but >> even if we were to go to end-to-end, on-path signaling >> there's a need to have application endpoints (or proxies, >> another can of worms) communicate directly with various >> sorts of individual middleboxes which may not be on a data >> path (or cannot be "known" to be on one). >> >> The notion of having devices in the network make >> determinations and push those out to the endpoints has the >> smell of Bell about it. It's typically not something that >> will work well in IP networks, where making network elements >> visible to application endpoints can create a host of >> problems, ranging from lack of robustness to inter-layer >> duplication of function to inability to scale with the >> number of endpoints. >> >> By the way, I don't think there is an "ongoing protocol >> controversy." There's been very little discussion at all. >> If there's lack of progress it's because of lack of input, >> not because participants in the working group are at >> loggerheads. >> >> 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 Dec 6 16:30: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 QAA25617 for ; Fri, 6 Dec 2002 16:30:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6LXAu22177 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 16:33:10 -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 gB6LT7v21971; Fri, 6 Dec 2002 16:29: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 gB6LS6v21930 for ; Fri, 6 Dec 2002 16:28:06 -0500 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 QAA25464 for ; Fri, 6 Dec 2002 16:25:07 -0500 (EST) Received: (from hardie@localhost) by geode.he.net (8.8.6/8.8.2) id NAA01441; Fri, 6 Dec 2002 13:27:54 -0800 Message-Id: <200212062127.NAA01441@geode.he.net> Subject: Re: [midcom] Time for a Time-Out? To: mshore@cisco.com (Melinda Shore) Date: Fri, 6 Dec 2002 13:27:54 -0800 (PST) Cc: eburger@snowshore.com (Eric Burger), midcom@ietf.org ("IETF Midcom (E-mail)") In-Reply-To: <200212061631.ABD70621@mira-sjc5-c.cisco.com> from "Melinda Shore" at Dec 06, 2002 11:31:04 AM 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 Melinda writes: > I think there's a broader context here and that's that this > is an instance of off-path signaling, which is getting more > attention these days for better or worse (mostly the > latter). There's been some agitation from a subset of > people interested in QoS for the IETF to take on off-path > QoS signaling, and it may be worthwhile to kick all of it > out to the IRTF to develop a better understanding of some of > the issues (and I think there's a tendency for off-path > signaling advocates, including us, to be glib about some > problems that are actually extremely difficult, like routing > and topology). I agree that there is a broader context here, and that this work forces us to think about some problems in routing and topology which are very difficult. I'm not sure that kicking the larger question to the IRTF helps that, though, as it tends to make a bounded problem unbounded. As it is, the group has a difficult, bounded problem; making it a difficult, unbounded problem seems unlikely to help us make progress. > That said, there's a real problem to be solved here, and > there's some real-world implementation experience in the > form of Aravox's (RIP) product and UPnP. Although I do > believe there are better ways to solve this problem I also > recognize that there are environments in which this *is* the > right answer, and I think the only really hard part is the > process of selecting a protocol. If narrowing the focus of the solution to those environments where this is the right answer is possible, it seems like a good idea. It may also help us when making the decision on which protocol fits the environment best. Note that I really do mean "environment" here, not just problem statement. If there is a clear match between the tools used in the environments where this is applicable and one of the protocols under consideration, likely success in deployment seems like a strong factor to consider. To put it another way, if the candidate protocols have about the same number of positives and negatives, pick the one which the operations community seems most likely to be able to use. >It is my fondest but > likely fruitless hope that people will *not* see this as an > opportunity to try to rally some additional support for their > otherwise largely unpopular protocols, but rather understand > that we have a problem to solve and that we need to choose > the most suitable tools to do so. > > Melinda And it is my fond (and hopefully not fruitless) hope that you do not give up. We have some scary short term hacks out there which should be superseded by a more considered approach. Giving up on the considered approach dooms us to live with those hacks far longer than we would like. best regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 16:51:17 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 QAA26260 for ; Fri, 6 Dec 2002 16:51:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Lrjs23461 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 16:53: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 gB6LoAv23375; Fri, 6 Dec 2002 16:50:10 -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 gB6Ln9v23336 for ; Fri, 6 Dec 2002 16:49:09 -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 QAA26121 for ; Fri, 6 Dec 2002 16:46:11 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6Ln2K0021931 for ; Fri, 6 Dec 2002 13:49:02 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD90906; Fri, 6 Dec 2002 13:49:01 -0800 (PST) Message-Id: <200212062149.ABD90906@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 06 Dec 2002 16:49:00 -0500 Subject: [midcom] megaco 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 is general agreement to remove megaco from consideration as the midcom protocol, which leaves us with COPS, Diameter, and SNMPv3. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 17:11: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 RAA27128 for ; Fri, 6 Dec 2002 17:11:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6MDqi25259 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 17:13:52 -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 gB6MA6v25169; Fri, 6 Dec 2002 17:10: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 gB6M9lv25138 for ; Fri, 6 Dec 2002 17:09:47 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27029 for ; Fri, 6 Dec 2002 17:06:48 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA03094 for ; Fri, 6 Dec 2002 17:21:49 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma003083; Fri, 6 Dec 02 17:21:28 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 06 Dec 2002 17:09:36 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 17:09:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 17:09:36 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA256F02@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKdcX6uPQ/l/TzGTDik9G1xpBFCkgAArCWg From: "Harrington, David" To: X-OriginalArrivalTime: 06 Dec 2002 22:09:36.0681 (UTC) FILETIME=[2A093990:01C29D74] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6M9lv25139 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 -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Friday, December 06, 2002 4:50 PM To: Chris Elliott Cc: Wijnen, Bert (Bert); Harrington, David; Snmpv3@Lists.Tislabs.Com (E-mail) Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? I think you can factor out crypto of any stripe because it's a requirement regardless of which layer you implement it at. That said: assuming the number of round trips is identical for SNMP vs other contenders, this "too expensive" argument strikes me as yet another rehash of the ASN.1/ABNF crusades. Is it that time of year again? Mike Chris Elliott writes: > I think we need to define what we're talking about here. > > SNMPv3 noAuthNoPriv shouldn't be any more expensive than any other > version, but obviously doesn't give you any increased security. > > AuthNoPriv will be somewhat more expensive, but my experience (no, I > haven't benchmarked it) is that the cost is relatively low and is "good > enough" security for many environments. > > AuthPriv will be the most expensive and I agree that, without > support for hardware encryption (and I don't know of anyone that has > implemented that--does anyone?) will be quite expensive. > > It would be very interesting to benchmark the three on a representative > sample of equipment. I'd love to do this, but my current load, combined > with the conditions here now (no power at home or work, working off of > laptop battery and recharging in the car, and dialup access only, with no > schedule for power restoration yet) make it difficult to predict if I > could get to this anytime soon. > > Chris. > > On Fri, 6 Dec 2002, Wijnen, Bert (Bert) wrote: > > > I don;t have the stats, but remembering the implementation I did > > a few years back, I see no problem with a number of transactions > > per minute. Many SETs per second might become problematic, > > depending on the complexity of the SETs and what a SET > > would cause in underlying work and such. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Harrington, David [mailto:dbh@enterasys.com] > > > Sent: vrijdag 6 december 2002 21:10 > > > To: Snmpv3@Lists.Tislabs.Com (E-mail) > > > Subject: FW: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > > > > > > > Hi, > > > > > > Does anybody have any stats regarding the processing power > > > required for SNMPv3? > > > > > > dbh > > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: Friday, December 06, 2002 10:48 AM > > > To: Martin Stiemerling > > > Cc: midcom@ietf.org > > > Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > > > > > > > My bad feeling? Performance. > > > > > > I can see SNMPv3 working for a residential or SOHO gateway, > > > where there will be a few transactions per day. > > > > > > I might be able to see SNMPv3 working for a small enterprise > > > gateway, where there will be a few transaction per hour. > > > > > > I can't imagine using SNMPv3 SETs for a large enterprise or > > > inter-service provider gateway, where there will be a number > > > of transactions per minute. We've done the math, and you > > > need a LOT of processing power to support such a rate. > > > > > > > -----Original Message----- > > > > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > > > > Sent: Thursday, December 05, 2002 9:24 AM > > > > To: snmpv3@lists.tislabs.com > > > > Cc: midcom@ietf.org > > > > Subject: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > > > > > > > > > > [please keep me in the recipient list, since I'm not subscribed to > > > > snmvp3 list] > > > > > > > > Hi, > > > > > > > > as you may have heard: the MIDCOM WG is currently doing a protocol > > > > evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is > > > > amongst these candidates (diameter, cops(-pr), megaco). > > > > Would you strongly recommend to use SNMPv3 as the MIDCOM protocol > > > > without having a bad feeling? Actually there are only a few > > > > pro and cons > > > > discussed so far. > > > > > > > > Thanks in advance > > > > Martin > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > https://www1.ietf.org/mailman/listinfo/midcom > > > > > > > Chris Elliott CCIE# 2013 | | > Customer Diagnostic Engineer ||| ||| > RTP, NC, USA ||||| ||||| > 919-392-2146 .:|||||||||:|||||||||:. > chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 17:11:26 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 RAA27142 for ; Fri, 6 Dec 2002 17:11:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6MDsJ25271 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 17:13:54 -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 gB6MA9v25184; Fri, 6 Dec 2002 17:10: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 gB6M9lv25142 for ; Fri, 6 Dec 2002 17:09:47 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27031 for ; Fri, 6 Dec 2002 17:06:48 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA03090 for ; Fri, 6 Dec 2002 17:21:49 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma003081; Fri, 6 Dec 02 17:21:15 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 06 Dec 2002 17:09:23 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 17:09:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 6 Dec 2002 17:09:23 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA256F01@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKdbpK8WZ42gyXLTDaKoGdG7ERWsgABZO2Q From: "Harrington, David" To: X-OriginalArrivalTime: 06 Dec 2002 22:09:23.0212 (UTC) FILETIME=[220204C0:01C29D74] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB6M9lv25143 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 -----Original Message----- From: Chris Elliott [mailto:chelliot@cisco.com] Sent: Friday, December 06, 2002 4:29 PM To: Wijnen, Bert (Bert) Cc: Harrington, David; Snmpv3@Lists.Tislabs.Com (E-mail) Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? I think we need to define what we're talking about here. SNMPv3 noAuthNoPriv shouldn't be any more expensive than any other version, but obviously doesn't give you any increased security. AuthNoPriv will be somewhat more expensive, but my experience (no, I haven't benchmarked it) is that the cost is relatively low and is "good enough" security for many environments. AuthPriv will be the most expensive and I agree that, without support for hardware encryption (and I don't know of anyone that has implemented that--does anyone?) will be quite expensive. It would be very interesting to benchmark the three on a representative sample of equipment. I'd love to do this, but my current load, combined with the conditions here now (no power at home or work, working off of laptop battery and recharging in the car, and dialup access only, with no schedule for power restoration yet) make it difficult to predict if I could get to this anytime soon. Chris. On Fri, 6 Dec 2002, Wijnen, Bert (Bert) wrote: > I don;t have the stats, but remembering the implementation I did > a few years back, I see no problem with a number of transactions > per minute. Many SETs per second might become problematic, > depending on the complexity of the SETs and what a SET > would cause in underlying work and such. > > Thanks, > Bert > > > -----Original Message----- > > From: Harrington, David [mailto:dbh@enterasys.com] > > Sent: vrijdag 6 december 2002 21:10 > > To: Snmpv3@Lists.Tislabs.Com (E-mail) > > Subject: FW: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > > > > Hi, > > > > Does anybody have any stats regarding the processing power > > required for SNMPv3? > > > > dbh > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Friday, December 06, 2002 10:48 AM > > To: Martin Stiemerling > > Cc: midcom@ietf.org > > Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > > > > My bad feeling? Performance. > > > > I can see SNMPv3 working for a residential or SOHO gateway, > > where there will be a few transactions per day. > > > > I might be able to see SNMPv3 working for a small enterprise > > gateway, where there will be a few transaction per hour. > > > > I can't imagine using SNMPv3 SETs for a large enterprise or > > inter-service provider gateway, where there will be a number > > of transactions per minute. We've done the math, and you > > need a LOT of processing power to support such a rate. > > > > > -----Original Message----- > > > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > > > Sent: Thursday, December 05, 2002 9:24 AM > > > To: snmpv3@lists.tislabs.com > > > Cc: midcom@ietf.org > > > Subject: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > > > > > > > [please keep me in the recipient list, since I'm not subscribed to > > > snmvp3 list] > > > > > > Hi, > > > > > > as you may have heard: the MIDCOM WG is currently doing a protocol > > > evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is > > > amongst these candidates (diameter, cops(-pr), megaco). > > > Would you strongly recommend to use SNMPv3 as the MIDCOM protocol > > > without having a bad feeling? Actually there are only a few > > > pro and cons > > > discussed so far. > > > > > > Thanks in advance > > > Martin > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA ||||| ||||| 919-392-2146 .:|||||||||:|||||||||:. chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 17:12: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 RAA27167 for ; Fri, 6 Dec 2002 17:12:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6MEXG25297 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 17:14:33 -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 gB6MB2v25210; Fri, 6 Dec 2002 17:11:02 -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 gB6MAJv25191 for ; Fri, 6 Dec 2002 17:10:19 -0500 Received: from mailman.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27056 for ; Fri, 6 Dec 2002 17:07:20 -0500 (EST) Received: from [10.21.97.22] by mailman.cisco.com (171.70.144.185) with ESMTP; 06 Dec 2002 07:30:31 +0000 Message-ID: <3DF12042.8050704@cisco.com> Date: Fri, 06 Dec 2002 14:10:10 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org Subject: Re: [midcom] megaco References: <200212062149.ABD90906@mira-sjc5-c.cisco.com> In-Reply-To: <200212062149.ABD90906@mira-sjc5-c.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 COPS requires a TCP connection between the agent and the middlebox. That's not appropriate for potentially *every* device on a large network. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 17:18: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 RAA27330 for ; Fri, 6 Dec 2002 17:18:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6MKcT25563 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 17:20: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 gB6MH5v25410; Fri, 6 Dec 2002 17:17:05 -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 gB6MGav25379 for ; Fri, 6 Dec 2002 17:16:36 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27234 for ; Fri, 6 Dec 2002 17:13:37 -0500 (EST) Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id gB6MGNq02525; Fri, 6 Dec 2002 14:16:23 -0800 To: "Harrington, David" Cc: Subject: Re: [midcom] SNMPv3 References: <6D745637A7E0F94DA070743C55CDA9BA07590E@NHROCMBX1.ets.enterasys.com> From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Fri, 06 Dec 2002 14:16:23 -0800 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA07590E@NHROCMBX1.ets.enterasys.com> ("Harrington, David"'s message of "Fri, 6 Dec 2002 13:35:47 -0500") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) 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: , >>>>> On Fri, 6 Dec 2002 13:35:47 -0500, "Harrington, David" said: David> SNMPv3 is the protocol submitted for consideration, and it is David> submitted on the basis that no modifications to the protocol David> would be required. The EOS PDU structures are an extension to David> the protocol and are not part of the SNMPv3 submission. Sorry for confusing people by my post. I was in no way trying to say that people should depend on future extensions. The point was that, according to the analysis doc, SNMP rates the best (I can't say I agree or disagree with it, as I haven't read the entire document; I'm basing this statement on the summary). However, the less-than-ideal aspects of the protocol may be further improved automatically by future improvements to the protocol, which to me makes it look more attractive. Certainly you must make a decision based on what is available today and not what may happen in the future. A clear picture of the future still helps, however. [Why is it I'm always misunderstood lately. I think I need to get more sleep in order to write more clearly stated messages] -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 18:25: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 SAA00191 for ; Fri, 6 Dec 2002 18:25:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6NSFl29704 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 18:28:15 -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 gB6NOcv29512; Fri, 6 Dec 2002 18:24:38 -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 gB6N7lv28861 for ; Fri, 6 Dec 2002 18:07:47 -0500 Received: from vmmr6.verisignmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29371 for ; Fri, 6 Dec 2002 18:04:47 -0500 (EST) Received: from vmms6.verisignmail.com (vmms6.verisignmail.com [10.166.0.148]) by vmmr6.verisignmail.com (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id PNY21032; Fri, 6 Dec 2002 18:07:33 -0500 (EST) Received: from BOB.AppliedSNMP.com (pcp830034pcs.nrockv01.md.comcast.net [68.50.129.39]) by vmms6.verisignmail.com (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id PQV90720; Fri, 6 Dec 2002 18:07:32 -0500 (EST) Message-Id: <5.1.0.14.2.20021206175119.02020ce8@mail.AppliedSNMP.com> X-Sender: Bob.Natale@AppliedSNMP.com@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Dec 2002 18:11:56 -0500 To: Melinda Shore From: Bob Natale Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Cc: snmpv3@lists.tislabs.com, midcom@ietf.org In-Reply-To: <200212051839.ABD22241@mira-sjc5-c.cisco.com> References: <5001C86452603F41820378E167091F07EED96A@email1.unispherenetworks.com> 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 12/5/2002:01:39 PM, Melinda Shore wrote: Hi Melinda, >> I was hesitating to make a similar statement, fearing of being disruptive, >> but I do share the very exact same feeling. > >The decision to revise the documents needs to be based on >the identification of *specific* problems with them rather >than a general sense that something is not quite right. Yeah, in general I agree with your position...but I've got a very general doubt about the specific problem (as I see it) of IETF protocol-efforts like AAA (which I followed for a while) and Midcom (which I have not followed much since its very early days) ending up by asking the question "Now, what protocol should be this protocol?" and especially when one of the (evidently) conceivable answers to that question is thought to be "SNMP". SNMP[v3] is the Internet standard management protocol (or words to that effect). Other IETF protocols should be designed with manageability by SNMPv3 in mind, including current era carrier-grade MIB support. That is, if SNMPv3 is to be *the* protocol for protocol X, then what is the added value of protocol X? If protocol X is not SNMPv3 (which is always true except for one value of X) but cannot be managed by SNMPv3, then the IETF process is flawed in some way (and needs to be fixed). So, maybe all I am saying here is that I am really clueless. If so, I will look forward to being clued in. Thanks, BobN _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 6 19:36: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 TAA03188 for ; Fri, 6 Dec 2002 19:36:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB70ca401531 for midcom-archive@odin.ietf.org; Fri, 6 Dec 2002 19:38:36 -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 gB70cAv01510; Fri, 6 Dec 2002 19:38:10 -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 gB70bNv01373 for ; Fri, 6 Dec 2002 19:37:24 -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 TAA03073 for ; Fri, 6 Dec 2002 19:34:23 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB70asjS019649; Fri, 6 Dec 2002 16:36:54 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABE01633; Fri, 6 Dec 2002 16:37:12 -0800 (PST) Message-Id: <200212070037.ABE01633@mira-sjc5-c.cisco.com> To: Bob Natale cc: snmpv3@lists.tislabs.com, midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? In-Reply-To: Message from Bob Natale of "Fri, 06 Dec 2002 18:11:56 EST." <5.1.0.14.2.20021206175119.02020ce8@mail.AppliedSNMP.com> Date: Fri, 06 Dec 2002 19:37:11 -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: , > SNMP[v3] is the Internet standard management protocol (or > words to that effect). Other IETF protocols should be > designed with manageability by SNMPv3 in mind, including > current era carrier-grade MIB support. Those were among the arguments that Christian presented in the Atlanta meeting when he asked that we skip the lengthy decision process and choose SNMPv3 now. When we took it to the mailing list there were sufficient objections that we couldn't do it. That's a decision that can be revisited at any time and I'd be happy to do so. In the post to which you're responding I'm asking people to get specific about architectural issues. The midcom requirements and framework documents have been finished for quite some time. They went through a lengthy development process, went through WG last call, went through IESG review, went through IETF last call, went through the RFC editor's process, and were published as RFCs. There's been plenty of opportunity for input before now. It could very well be the case that either or both contain some fatal flaw and need revision, but if that's the case the arguments for doing so have to be substantive and specific - "That's not the way I see it" won't cut it, and that's about the level of objection that we're getting. I should also point out that if the argument is that the current framework is unsuitable for one of the protocols, it's probably actually the case that the protocol isn't suitable for the framework. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Dec 7 00:37: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 AAA09907 for ; Sat, 7 Dec 2002 00:37:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB75e5214872 for midcom-archive@odin.ietf.org; Sat, 7 Dec 2002 00:40:05 -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 gB75aRv14091; Sat, 7 Dec 2002 00:36:27 -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 gB75Zmv14068 for ; Sat, 7 Dec 2002 00:35:48 -0500 Received: from web40411.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09795 for ; Sat, 7 Dec 2002 00:32:45 -0500 (EST) Message-ID: <20021207053537.30902.qmail@web40411.mail.yahoo.com> Received: from [12.234.140.126] by web40411.mail.yahoo.com via HTTP; Fri, 06 Dec 2002 21:35:37 PST Date: Fri, 6 Dec 2002 21:35:37 -0800 (PST) From: Pyda Srisuresh Subject: RE: [midcom] SNMPv3 To: midcom@ietf.org Cc: srisuresh@yahoo.com In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA07590E@NHROCMBX1.ets.enterasys.com> 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: , Folks, Sorry to chime in somewhat late on this thread. I suggest we select SNMP as the MIDCOM protocol. Here is why. 1. I have not heard any firm argument that SNMP does not meet the requirement to be a MIDCOM protocol. That SNMPv3 is CPU intensive and hence not suitable for large scale enterprises/ISPs is an argument against security - not against SNMP per se, IMHO. Vendors may choose to go with hardware-based security solution (or) simply go with SNMPv2. That operators don't use SNMP per se is also not a valid argument against SNMP - because operators probably do not use any standard configuration protocol. They probably use vendor proprietary CLI, for whatever reason. Most vendors have a CLI for their devices, irrespective of whether they support SNMP, COPS etc. on the devices. As for the question of MIBs - There in fact is a NATMIB draft (draft-ietf-nat-natmib-05.txt) which was posted to this WG approximately 2 months ago. Developing a MIB for the firewall should be straight forward. 2. Selecting SNMP as the protocol of choice for MIDCOM does not mean we should exclude all other protocols that provide the same funtionality. Middlebox Device vendors and their customers are the ultimate judges of what protocol will become the defacto standard. Selection of a protocol by the IETF does not mean that vendors would adapt the protocol right away. If multiple protocol proposals are made along the way, the protocol that is most deployed will end up being the defacto standard. Only the protocol(s) with some real-world relevance will be embraced by the users. cheers, suresh --- "Harrington, David" wrote: > Hi, > > I concur with David's observation. > > SNMPv3 is the protocol submitted for consideration, and it is submitted on > the basis that no modifications to the protocol would be required. The EOS > PDU structures are an extension to the protocol and are not part of the > SNMPv3 submission. > > The only changes required for SNMPv3 support would be the development of > appropriate MIBs. > > dbh > > > > -----Original Message----- > > From: Durham, David [mailto:david.durham@intel.com] > > Sent: Friday, December 06, 2002 1:04 PM > > To: midcom@ietf.org > > Subject: RE: [midcom] SNMPv3 > > > > > > I don't think we want to imply that a new (yet non-existent) > > version of SNMP > > is required to meet the midcom requirements. > > > > -Dave > > > > > -----Original Message----- > > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > > > > > Warning: document far from complete but should be better when it's > > > first published as a WG item. The PDU structures have changed > > > slightly as well since then, but the concepts are still t same. > > > > > _______________________________________________ > > 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 Sat Dec 7 10:44:42 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 KAA00301 for ; Sat, 7 Dec 2002 10:44:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB7Fl6f18785 for midcom-archive@odin.ietf.org; Sat, 7 Dec 2002 10:47: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 gB7FbGv18488; Sat, 7 Dec 2002 10:37: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 gB7FaOv17910 for ; Sat, 7 Dec 2002 10:36:24 -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 KAA00043 for ; Sat, 7 Dec 2002 10:33:29 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB7FaKFp010104 for ; Sat, 7 Dec 2002 07:36:20 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABE15942; Sat, 7 Dec 2002 07:36:19 -0800 (PST) Message-Id: <200212071536.ABE15942@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Sat, 07 Dec 2002 10:36:19 -0500 Subject: [midcom] Moving forward with protocol selection 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've successfully eliminated two of the candidate protocols (RSIP and megaco) from consideration as the midcom protcol, but we're clearly not going to be able to make further progress as things currently stand. Therefore, the process going forward is going to be this: 1) we're going to go through the remaining protocols in the order they're ranked in the evaluation document (1 SNMPv3, 2 Diameter, 3 COPS) 2) we're going to stop when we find one that can do the job 3) people who object to the selection of that protocol *MUST* demonstrate clearly that the protocol cannot meet the midcom requirements and framework I've cleared this with the AD who's overseeing the working group. We're starting with SNMPv3, which is ranked first in the evaluation document. Anybody who has a technical description of why SNMPv3 cannot meet the needs of the midcom protocol should post that description. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 04:13: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 EAA02712 for ; Mon, 9 Dec 2002 04:13:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB99GRQ20328 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 04:16:27 -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 gB99CXv20115; Mon, 9 Dec 2002 04:12:33 -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 gB99B3v20060 for ; Mon, 9 Dec 2002 04:11:03 -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 EAA02561 for ; Mon, 9 Dec 2002 04:07:59 -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 gB99AiF21243; Mon, 9 Dec 2002 10:10:44 +0100 (CET) (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 D4FB02ED1D; Mon, 9 Dec 2002 10:08:27 +0100 (CET) Message-ID: <3DF45D95.2090807@ccrle.nec.de> Date: Mon, 09 Dec 2002 10:08:37 +0100 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: "Harrington, David" Cc: snmpv3@lists.tislabs.com, midcom@ietf.org References: <6D745637A7E0F94DA070743C55CDA9BA075903@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: SNMPv3 as MIDCOM protocol: Opinions? 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, after starting the discussion, I'm a little behind with reading all messages. Harrington, David wrote: > Hi, > > Message #2: as an evaluator of SNMPv3 based on the MIDCOM requirements. > > In performing the evaluation, SNMPv3 scored very well, but I'd like to comment on the evaluation process. > > It is my feeling that the MIDCOM requirements need work. Unfortunately we're already done with the requirements. The need for having a MIDCOM protocol is big and I see no time left for delaying the MIDCOM protocol. > > There are many requirements that are ambiguous, and there are many requirements that have been written to favor a specific type of solution (not a particular candidate, but a particular approach, which favors some protocol designs). I don't believe this was done to influence the results, I think the persons writing the requirements had a solution in mind, and phrased the questions according to their view of the problems. Yep. > > I'm not sayingg this becasue I feel that SNMPv3 could have done better with a different set of requirements; SNMPv3 may have done better or it may have done worse with a different set of requirements. As it is, I do not feel that the appropriateness of SNMPv3 or any of the other protocols to the problem was really addressed in the evaluation. > > I suspect that is why Martin has sent this question to the SNMPv3 mailing list. I suspect that Martin believes SNMPv3 may or may not be an appropriate choice, but that the evaluation doesn't provide enough information, or the right information, to make this determination. The evaluation says only that mechanism x of protocol z fits to the midcom in a particular point. The keyword is 'particular'. It doesn't say anything about the whole protocol fits to midcom. This is indeed the reason for my request to the snmp list and I happy to see a lot of responses. Thanks! > > I recommend the MIDCOM WG rethink their requirements document. It may be necessary to rethink portions of the architecture as well. As said, these two things are done, we have to be ready with the protocol soon and the requirements and framework are alright for our problem space. Martin -- ************************************************ NEW ADDRESS EFFECTIVE DECEMBER 23RD Kurfuersten-Anlage 34, 69115 Heidelberg, Germany phone, fax and email remain unchanged ************************************************ 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 Mon Dec 9 04:17: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 EAA02816 for ; Mon, 9 Dec 2002 04:17:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB99KS420495 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 04:20:28 -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 gB99K8v20474; Mon, 9 Dec 2002 04:20: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 gB99Jiv20423 for ; Mon, 9 Dec 2002 04:19:44 -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 EAA02807 for ; Mon, 9 Dec 2002 04:16: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 gB99JWF21950; Mon, 9 Dec 2002 10:19:32 +0100 (CET) (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 0603712C69; Mon, 9 Dec 2002 10:17:16 +0100 (CET) Message-ID: <3DF45FA5.6050605@ccrle.nec.de> Date: Mon, 09 Dec 2002 10:17:25 +0100 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: Eric Burger Cc: "IETF Midcom (E-mail)" Subject: Re: [midcom] H.248 for midcom? Not. References: <4A3384433CE2AB46A63468CB207E209D2485C3@zoe.office.snowshore.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 Eric, thanks for the clarification! This helped a lot. Martin Eric Burger wrote: > Reviewing the MIDCOM protocol evaluation document, I had some questions about the H.248 (megaco) analysis. > > Requirement 2.1.3, "Middlebox can relate to multiple Agents", refers to the ability for a set of agents to manipulate (in H.248 parlance) the same end-point. It is true, as described in the document, that one can partition a media gateway into multiple virtual media gateways (VMG). By design, H.248 restricts a one-to-one association between a VMG and an agent. In addition, AFAIK the standard H.248 model has no possibility for VMG's to have the same end-points. This is an architectural feature of H.248. Even if you "extended" H.248 to allow the same ephemeral end-point to be addressed by two VMG's, it would, by definition, have different names. Thus, I do not understand how H.248 could possibly meet this requirement. > > In fact, the response to Requirement 2.1.4 highlights this issue. H.248 is deterministic in the face of multiple requests because it cannot have them. > > Requirement 2.1.12: > The biggest leap of faith is the proposal of a MIDCOM Ruleset Package. If we stuck with the H.248 master-slave model, I would expect rule processing to occur at the MGC (agent). I can't envision how to implement a rule set end-point entity. It seems to be rather foreign to the whole H.248 framework. > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- ************************************************ NEW ADDRESS EFFECTIVE DECEMBER 23RD Kurfuersten-Anlage 34, 69115 Heidelberg, Germany phone, fax and email remain unchanged ************************************************ 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 Mon Dec 9 04:21: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 EAA02878 for ; Mon, 9 Dec 2002 04:21:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB99ONp20642 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 04:24:23 -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 gB99O2v20634; Mon, 9 Dec 2002 04:24:02 -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 gB99Ncv20613 for ; Mon, 9 Dec 2002 04:23:38 -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 EAA02848 for ; Mon, 9 Dec 2002 04:20:34 -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 gB99N5F22323; Mon, 9 Dec 2002 10:23:06 +0100 (CET) (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 BFBB879BDF; Mon, 9 Dec 2002 10:20:48 +0100 (CET) Message-ID: <3DF4607A.4090409@ccrle.nec.de> Date: Mon, 09 Dec 2002 10:20:58 +0100 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: Melinda Shore Cc: Jonathan Rosenberg , Eric Burger , "IETF Midcom (E-mail)" Subject: Re: [midcom] Time for a Time-Out? References: <200212061637.ABD70885@mira-sjc5-c.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 Melinda Shore wrote: >>5. New protocol: do a new one from scratch. >> >>Other ideas? I would favor approach 5 first, then 1, then 4, then 2, >>then 3. > > > I can think of at least four existing "from scratch" midcom Take SIMCO ;-). It does fit the semantics to 100%. Cheers Martin > protcols, and I don't see the process of sorting through > them as being any easier than sorting through COPS, SNMP, > megaco, and Diameter. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- ************************************************ NEW ADDRESS EFFECTIVE DECEMBER 23RD Kurfuersten-Anlage 34, 69115 Heidelberg, Germany phone, fax and email remain unchanged ************************************************ 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 Mon Dec 9 05:12: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 FAA03765 for ; Mon, 9 Dec 2002 05:12:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9AF8F23293 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 05:15:08 -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 gB9AEZv23259; Mon, 9 Dec 2002 05:14:35 -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 gB9ADnv23227 for ; Mon, 9 Dec 2002 05:13:49 -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 FAA03742 for ; Mon, 9 Dec 2002 05:10:53 -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 gB9ADUF25677; Mon, 9 Dec 2002 11:13:30 +0100 (CET) (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 9D5D1742C8; Mon, 9 Dec 2002 11:11:14 +0100 (CET) Message-ID: <3DF46C4B.50407@ccrle.nec.de> Date: Mon, 09 Dec 2002 11:11:23 +0100 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: Jonathan Rosenberg Cc: Eric Burger , "IETF Midcom (E-mail)" Subject: Re: [midcom] Time for a Time-Out? References: <4A3384433CE2AB46A63468CB207E209D2485C5@zoe.office.snowshore.com> <3DF0CF13.60102@dynamicsoft.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 Jonathan Rosenberg wrote: > I've personally been silent on all of this stuff for quite some time. To > be honest, that is primarily due to my frustration at the general lack > of progress and amazing circuitousness (is that a word) of the path we > have taken to completion of this work. Jonathan, there has been some progress on this stuff in the last few months, take a look into the semantics. But since a lot of people are staying quiet instead of saying their opinion, we do not have any big progress. Some people take care about driving the evaluation process and the semantics, and they would be happy about even more comments! Out of the favorite list I don't like 2, 3 and 4. With 5 I'm fine (lets go with an XML-encoded SIMCO), but we have to face the reality that we have first to evaluate extisting protocols (I think this is mandatory by the ADs?). Martin > > Some responses inline. > > Eric Burger wrote: > > > Last time I looked, the IETF is the organization that does protocols. > > Why do we have this aversion to creating a protocol? Because of > > marketplace realities, I have to build a proprietary protocol to make > > something that works and scales. > > > > Now let's look at midcom and progress to date. It has been over a > > year, > > Oh, much longer than that. I recall the foglamps bof meeting in Adelaide > in March 2000, which is almost three years ago. Most groups produce real > protocols in faster than three years after their bof. > > > and the work group really hasn't produced anything of > > substance. There is still discussion on the list about the > > requirements. At the rate we're going, I don't expect that we will > > produce anything in the coming year, either. > > I agree. > > I think it is time for a change in direction. Right now, we are on a > path to fail. There are folks in each protocol camp who will clearly not > budge. There is also, I think, a good contingent (myself included) who > would rather build a new, simple-as-possible protocol for the task at > hand. There is also a large contingent that is tired and no longer > cares. Indeed, the participation in list discussion has dropped > tremendously since this evaluation process began. Where is everyone? > > I would like to propose that the group consider some radical actions at > this point. Short of that, we will probbaly fail to produce anything at > all. > > I do not know what the right thing is, but here are some ideas: > > 1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new > protocol people all develop their own protocols. Make the semantics doc > a mandatory thing, so that each protocol must provide the semantics > described there, and show a mapping. THis is akin to the CPIM approach. > THen, let the market pick a winner. Three is better than zero, I guess. > > 2. Shut down: Just give up. Close the group. This interface remains > proprietary. We have things like TURN, ALGs and eventually nsis, which > is (I think) the right answer. Of course nsis is probably 5 years away > from useful deployment. > > 3. Move to IRTF: As Eric suggests. > > 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and we > do that (seems unlikely but I throw it out for consideration). > > 5. New protocol: do a new one from scratch. > > Other ideas? I would favor approach 5 first, then 1, then 4, then 2, > then 3. > > -Jonathan R. > -- ************************************************ NEW ADDRESS EFFECTIVE DECEMBER 23RD Kurfuersten-Anlage 34, 69115 Heidelberg, Germany phone, fax and email remain unchanged ************************************************ 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 Mon Dec 9 05:20:21 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 FAA04029 for ; Mon, 9 Dec 2002 05:20:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9AMio23528 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 05:22:44 -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 gB9AJ2v23414; Mon, 9 Dec 2002 05:19:02 -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 gB9AI2v23366 for ; Mon, 9 Dec 2002 05:18:02 -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 FAA03802 for ; Mon, 9 Dec 2002 05:15:08 -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 gB9AHqF25777; Mon, 9 Dec 2002 11:17:52 +0100 (CET) (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 C460A2ED1D; Mon, 9 Dec 2002 11:15:35 +0100 (CET) Message-ID: <3DF46D50.90607@ccrle.nec.de> Date: Mon, 09 Dec 2002 11:15:44 +0100 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: Eliot Lear Cc: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] megaco References: <200212062149.ABD90906@mira-sjc5-c.cisco.com> <3DF12042.8050704@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 Eliot Lear wrote: > COPS requires a TCP connection between the agent and the middlebox. > That's not appropriate for potentially *every* device on a large network. Elliot, can you be more specific? I don't see the point. Martin > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- ************************************************ NEW ADDRESS EFFECTIVE DECEMBER 23RD Kurfuersten-Anlage 34, 69115 Heidelberg, Germany phone, fax and email remain unchanged ************************************************ 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 Mon Dec 9 09:06:37 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 JAA09947 for ; Mon, 9 Dec 2002 09:06:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9E93t04028 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 09:09:03 -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 gB9E8bv03978; Mon, 9 Dec 2002 09:08:37 -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 gB9E70v03273 for ; Mon, 9 Dec 2002 09:07:00 -0500 Received: from mailman.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09845 for ; Mon, 9 Dec 2002 09:04:03 -0500 (EST) Received: from [64.100.160.211] by mailman.cisco.com (171.70.144.185) with ESMTP; 09 Dec 2002 06:07:43 +0000 Message-ID: <3DF4A381.7060706@cisco.com> Date: Mon, 09 Dec 2002 06:06:57 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling CC: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] megaco References: <200212062149.ABD90906@mira-sjc5-c.cisco.com> <3DF12042.8050704@cisco.com> <3DF46D50.90607@ccrle.nec.de> In-Reply-To: <3DF46D50.90607@ccrle.nec.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 Martin, Given that Melinda has put in place a framework for closure, and that framework calls for comments about SNMP only, I'll hold off until we get to COPS-PR. Eliot _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 09:39: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 JAA11144 for ; Mon, 9 Dec 2002 09:39:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9EgJ505902 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 09:42:19 -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 gB9Efnv05883; Mon, 9 Dec 2002 09:41:49 -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 gB9EeHv05846 for ; Mon, 9 Dec 2002 09:40:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11090 for ; Mon, 9 Dec 2002 09:37:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9EeGYH014310 for ; Mon, 9 Dec 2002 09:40:16 -0500 (EST) Message-ID: <3DF4AB4C.9050203@dynamicsoft.com> Date: Mon, 09 Dec 2002 09:40:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 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] STUN extensibility 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 Folks, I was in the process of updating STUN based on list consensus on the issues raised by IESG. Many of them surrounded STUN extensibility. While working through the draft, I noted there were some additional issues (new message types can be defined, but no backwards compatibility negotiation defined). I think its worth getting agreement on a specific extensibility strategy and then making everything consistent with that. Generally, I think we have minimal need for extensibility. We should focus on simplicity, and not make this as complex or powerful as SIPs capabilities. There are several things which are potentially extensible: * new message types * new flags * new attributes * new error codes * new address families We really don't need built in extensibility and backwards compatibility for all of these. I believe that new attributes are the primary area where we want to make sure we can be extensible. I do not believe we need new message types or new flags (after all, anything you can do with a flag you could also do with a new attribute). So, I would like to reverse our decision on flags (open issue #3) and simply declare them non-extensible. Also, there is text which states that message types can be added by standards track RFCs, and I would like to remove that text too. That leaves attributes, error codes and address families. For attributes, I believe that the current text plus the proposed resolution to open issue #2 (for which there were no comments) is sufficient. That is, extensions documented in standards track RFCs can define new attributes, and we will add the 420/Unsupported mechanism as proposed. For error codes, I believe the text as it stands is fine (unknown error codes are treated like the x00 request). The only thing to add is that new codes can be defined in standards track RFCs. For address families, I believe we had consensus to remove support for new address families (only v4 is defined), but to keep the existing syntax which has an explicit family. [I will make a side note that I've recently been working on IPv4/IPv6 transition mechanisms which can benefit from STUN and would require v6 addresses, but we can always deal with that by revving stun if needed]. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 12:10: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 MAA19085 for ; Mon, 9 Dec 2002 12:10:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9HCbn16536 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 12:12:37 -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 gB9HC5v16508; Mon, 9 Dec 2002 12:12:05 -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 gB9HBiv16491 for ; Mon, 9 Dec 2002 12:11:44 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19040 for ; Mon, 9 Dec 2002 12:08:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9HBfYH014420; Mon, 9 Dec 2002 12:11:41 -0500 (EST) Message-ID: <3DF4CECA.7060306@dynamicsoft.com> Date: Mon, 09 Dec 2002 12:11:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: midcom@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: 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 Apologies here too for the lengthy delay in responding to this: Cullen Jennings wrote: > 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. There is text a few paragraphs down which says that: > The length refers to the length of the value element, expressed as an > unsigned integral number of bytes. You also mentioned: > > Section 11.2.7, second sentence. With the addition of the USERNAME, this is > no longer the sole attribute in a shared secret response. > Good catch! Fixed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 12:10: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 MAA19098 for ; Mon, 9 Dec 2002 12:10:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9HCmU16548 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 12:12:48 -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 gB9H9Dv16397; Mon, 9 Dec 2002 12:09: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 gB9H8Av16332 for ; Mon, 9 Dec 2002 12:08:10 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18831 for ; Mon, 9 Dec 2002 12:05:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9H84YH014408; Mon, 9 Dec 2002 12:08:04 -0500 (EST) Message-ID: <3DF4CDF1.6080800@dynamicsoft.com> Date: Mon, 09 Dec 2002 12:08:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN issues - Processing Binding Response clarification 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 Sorry I never responded to this. Response inline. Panayiotis A. Thermos wrote: > Greetings to all. > > I apologize if this has been discussed before. > > The draft states the following (section 9.4-Processing Binding Responses, > page 18, third paragraph ) > > " If the response is a Binding Response, the client SHOULD check the > response for a MESSAGE-INTEGRITY attribute. If not present, and the > client placed a MESSAGE-INTEGRITY attribute into the request, it MUST > discard the response." > > In the case where the client sends a binding "change-IP" and "change-port" > request with a MESSAGE-INTEGRITY > attribute, the server (e.g. server A) will forward the request to another > STUN server (e.g. server B) which in turn will > respond to the client's request. That particular methodology was found problematic and was removed from the spec several revisions back. >The later server (B) may not include a > MESSAGE-INTEGRITY attribute in it's response > thus the client will discard the response. And even if server B includes a > MESSAGE-INTEGRITY attribute, it will be wrong > and thus the client will discard the response. Right, precisely the kind of reason why this method for implementing change IP has been removed. The spec details a different approach now, in Section 8.1. > > Perhaps the draft should incorporate that STUN server A should notify > server B not to calculate its own SHA1 but use > server's A MESSAGE-INTEGRITY attribute instead in this case. The > notifications can be done through the FLAGS attribute > (e.g. a re-use attribute flag "REUSE-ATTRIBUTE" with value > "MESSAGE-INTEGRITY"). As above, since this mechanism has been removed, there is no need for these changes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 12:37:21 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 MAA20310 for ; Mon, 9 Dec 2002 12:37:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Hdmi18519 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 12:39:48 -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 gB9Hd4v18485; Mon, 9 Dec 2002 12:39: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 gB9HcPv18412 for ; Mon, 9 Dec 2002 12:38:25 -0500 Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20197 for ; Mon, 9 Dec 2002 12:35:27 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA26227; Mon, 9 Dec 2002 12:37:35 -0500 (EST) Subject: Re: [midcom] STUN issues - Processing Binding Response clarification To: Jonathan Rosenberg Cc: midcom@ietf.org, "Panayiotis A. Thermos" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Mon, 9 Dec 2002 12:41:14 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 12/09/2002 12:37:36 PM 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: , Jonathan thanks for the reply, my comments were based on the following version http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt which I assume is the latest draft, unless I missed the announcement of newer drafts. If so, which one is the latest one, and how I can keep track of the new releases? Although I believe I follow the mailing list closely, I haven't seen any announcements for new versions. Unless they were communicated over another channel. Thanks again for your time and help. Jonathan Rosenberg To: "Panayiotis A. Thermos" Thermos/Telcordia) Subject: Re: [midcom] STUN issues - Processing Binding 12/09/2002 Response clarification 12:08 PM Sorry I never responded to this. Response inline. Panayiotis A. Thermos wrote: > Greetings to all. > > I apologize if this has been discussed before. > > The draft states the following (section 9.4-Processing Binding Responses, > page 18, third paragraph ) > > " If the response is a Binding Response, the client SHOULD check the > response for a MESSAGE-INTEGRITY attribute. If not present, and the > client placed a MESSAGE-INTEGRITY attribute into the request, it MUST > discard the response." > > In the case where the client sends a binding "change-IP" and "change-port" > request with a MESSAGE-INTEGRITY > attribute, the server (e.g. server A) will forward the request to another > STUN server (e.g. server B) which in turn will > respond to the client's request. That particular methodology was found problematic and was removed from the spec several revisions back. >The later server (B) may not include a > MESSAGE-INTEGRITY attribute in it's response > thus the client will discard the response. And even if server B includes a > MESSAGE-INTEGRITY attribute, it will be wrong > and thus the client will discard the response. Right, precisely the kind of reason why this method for implementing change IP has been removed. The spec details a different approach now, in Section 8.1. > > Perhaps the draft should incorporate that STUN server A should notify > server B not to calculate its own SHA1 but use > server's A MESSAGE-INTEGRITY attribute instead in this case. The > notifications can be done through the FLAGS attribute > (e.g. a re-use attribute flag "REUSE-ATTRIBUTE" with value > "MESSAGE-INTEGRITY"). As above, since this mechanism has been removed, there is no need for these changes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 12:44: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 MAA20816 for ; Mon, 9 Dec 2002 12:44:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Hkwv18929 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 12:46: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 gB9HhGv18694; Mon, 9 Dec 2002 12:43: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 gB9Hg7v18662 for ; Mon, 9 Dec 2002 12:42:07 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20519 for ; Mon, 9 Dec 2002 12:39:08 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9HftYH014434; Mon, 9 Dec 2002 12:41:55 -0500 (EST) Message-ID: <3DF4D5DF.5060907@dynamicsoft.com> Date: Mon, 09 Dec 2002 12:41:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN issues - Processing Binding Response clarification 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: > Jonathan thanks for the reply, > > my comments were based on the following version > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt > which I assume is the latest draft, unless I missed the announcement > of newer drafts. -03 is the current one. I am finishing up -04 right now. However, the usage of a second server for sending the response was removed as of draft-ietf-midcom-00. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 13:11:32 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 NAA22553 for ; Mon, 9 Dec 2002 13:11:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9IE0h20714 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 13:14: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 gB9IAAv20535; Mon, 9 Dec 2002 13:10:10 -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 gB9I9mv20491 for ; Mon, 9 Dec 2002 13:09:48 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22299 for ; Mon, 9 Dec 2002 13:06:48 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA19611 for ; Mon, 9 Dec 2002 13:21:50 -0500 (EST) Received: from unknown(134.141.77.91) by ctron-dnm.enterasys.com via smap (4.1) id xma019591; Mon, 9 Dec 02 13:21:48 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG1.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Mon, 09 Dec 2002 13:09:58 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 9 Dec 2002 13:09:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Mon, 9 Dec 2002 13:09:55 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA256F0B@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKfrSt60m3NY/naSEy5ahk+rYGf1QAAKhRw From: "Harrington, David" To: X-OriginalArrivalTime: 09 Dec 2002 18:09:56.0810 (UTC) FILETIME=[2E344AA0:01C29FAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB9I9mv20492 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 Another note on SNMPv3 performance. Apparently BMC has had no problems with SETs except due to implementation choices in a master/subagent implementation. dbh -----Original Message----- From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] Sent: Friday, December 06, 2002 8:31 PM To: snmpv3@lists.tislabs.com Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Hi - > Message-ID: > From: "Wijnen, Bert (Bert)" > To: "Harrington, David" , > "Snmpv3@Lists.Tislabs.Com (E-mail)" > Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > Date: Fri, 6 Dec 2002 22:05:55 +0100 > > I don;t have the stats, but remembering the implementation I did > a few years back, I see no problem with a number of transactions > per minute. Many SETs per second might become problematic, > depending on the complexity of the SETs and what a SET > would cause in underlying work and such. ... My recollection from several years ago was that for single-varbbind requests in a noAuth/noPriv configuration, we were geting about 100 per second on ancient hardware using SMUX, and proportionately less (due to greater overhead) with AgentX. YMMV, but I have to agree with Bert that SET throughput has not been an issue in general. There are two specific cases where I HAVE seen it become an issue: 1) high latency (due to long links or processing time) subagents 2) incorrect SMUX/Agentx connection TCP options. (TCP_NODELAY is especially important) Some packet exchange patterns would cause "stalls" while one side or the other was waiting to put more into an output buffer. Flow patterns like ><> ><> or ><<>< ><<>< were particularly prone. setsockopt() fixed this permanently. (Thanks Bobby Krupczak!) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 14:08: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 OAA25571 for ; Mon, 9 Dec 2002 14:08:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9JAUG24631 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 14:10:30 -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 gB9J6tv23783; Mon, 9 Dec 2002 14:06:55 -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 gB9J5lv23705 for ; Mon, 9 Dec 2002 14:05:47 -0500 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 OAA25202 for ; Mon, 9 Dec 2002 14:02:47 -0500 (EST) 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 OAA21956; Mon, 9 Dec 2002 14:05:00 -0500 (EST) Subject: Re: [midcom] STUN issues - Processing Binding Response clarification To: Jonathan Rosenberg Cc: midcom@ietf.org, "Panayiotis A. Thermos" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Mon, 9 Dec 2002 14:08:35 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 12/09/2002 02:05:00 PM 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: , Ok, you mean that responses that are generated by "CHANGE-IP" and "CHANGE-PORT" requests are sent by the same host (given that the host has two network interfaces). Peter Jonathan Rosenberg To: "Panayiotis A. Thermos" Thermos/Telcordia) Subject: Re: [midcom] STUN issues - Processing Binding 12/09/2002 Response clarification 12:41 PM Panayiotis A. Thermos wrote: > Jonathan thanks for the reply, > > my comments were based on the following version > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt > which I assume is the latest draft, unless I missed the announcement > of newer drafts. -03 is the current one. I am finishing up -04 right now. However, the usage of a second server for sending the response was removed as of draft-ietf-midcom-00. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 14:52:28 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 OAA28035 for ; Mon, 9 Dec 2002 14:52:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Jsuc27777 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 14:54:56 -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 gB9JkFv27518; Mon, 9 Dec 2002 14:46: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 gB9Jjxv27504 for ; Mon, 9 Dec 2002 14:45:59 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27534 for ; Mon, 9 Dec 2002 14:43:00 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9JjmYH014482; Mon, 9 Dec 2002 14:45:48 -0500 (EST) Message-ID: <3DF4F2E9.3070209@dynamicsoft.com> Date: Mon, 09 Dec 2002 14:45:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN issues - Processing Binding Response clarification 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 Yes. -Jonathan R. Panayiotis A. Thermos wrote: > Ok, > you mean that responses that are generated by "CHANGE-IP" and "CHANGE-PORT" > requests are sent by the same host (given that the host has two network > interfaces). > > Peter > > > > > > Jonathan > Rosenberg To: "Panayiotis A. Thermos" > csoft.com> Thermos/Telcordia) > Subject: Re: [midcom] STUN issues - Processing Binding > 12/09/2002 Response clarification > 12:41 PM > > > > > > > > > > Panayiotis A. Thermos wrote: > >>Jonathan thanks for the reply, >> >>my comments were based on the following version >>http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt >>which I assume is the latest draft, unless I missed the announcement >>of newer drafts. > > > -03 is the current one. I am finishing up -04 right now. However, the > usage of a second server for sending the response was removed as of > draft-ietf-midcom-00. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 16:31:15 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 QAA03115 for ; Mon, 9 Dec 2002 16:31:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9LXhJ00897 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 16: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 gB9LXEv00886; Mon, 9 Dec 2002 16:33:14 -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 gB9LWvv00813 for ; Mon, 9 Dec 2002 16:32:57 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03037 for ; Mon, 9 Dec 2002 16:29:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9LWrYH014528 for ; Mon, 9 Dec 2002 16:32:53 -0500 (EST) Message-ID: <3DF50C02.2000700@dynamicsoft.com> Date: Mon, 09 Dec 2002 16:32:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 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] updated STUN I-D 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 Folks, I've just submitted an updated STUN spec based on IESG comments. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-midcom-stun-04.txt Here are the changes: * changed usage of client certs from MAY to MUST NOT [Bellovin] * changed response code structure to align with SIP and HTTP. Note that this required the introduction of three response codes (430-432) not used by SIP or HTTP. Recommended reason phrases were defined. * added back shared secret error response code, which can occur if a shared secret request contains an unknown mandatory attribute. * added 420 response code, to handle unknown attributes. Also added an UNKNOWN-ATTRIBUTES attribute for responses with error code 420. * added 500 and 600 response code * more concise details on handling of unknown attributes in clients and servers * explicit statement that only ietf standards track RFCs can define STUN extensions. * removed statement about extensibility of message types * removed extensibility of flags * removed discard flag * added reference to RFC 791 on how to encode STUN messages on the wire (standard network byte ordering) * specified that lengths of shared secrets, passwords, and reason phrases needed to be multiples of 4 bytes to guarantee word alignment of the protocol. * changed the name of the FLAGS attribute to CHANGE-REQUEST, since the only flags left were to change the IP/port, and extensibility was removed. * added the REFLECTED-FROM attribute, and specified that it MUST be present in the response when the request contained a RESPONSE-ADDRESS. Specified that it MUST contain the source IP of the corresponding shared secret request. Specified handling when no usernames are used, or when the username is obtained in other ways. * Aadded non-normative text suggesting how to compute the username and passwords so that the required behavior for the attribute can be met statelessly. * removed v6 support -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 16:49: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 QAA04068 for ; Mon, 9 Dec 2002 16:49:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9LplL02270 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 16:51:47 -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 gB9Lm5v02096; Mon, 9 Dec 2002 16:48:05 -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 gB9LlWv02053 for ; Mon, 9 Dec 2002 16:47:32 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03881 for ; Mon, 9 Dec 2002 16:44:32 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id QAA05455 for ; Mon, 9 Dec 2002 16:59:34 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma005421; Mon, 9 Dec 02 16:58:40 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Mon, 09 Dec 2002 16:46:50 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 9 Dec 2002 16:46:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Mon, 9 Dec 2002 16:46:49 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA256F1D@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKfw6qGjHxDgoB6T+CW9lAu7kjiPwACIPMQ From: "Harrington, David" To: X-OriginalArrivalTime: 09 Dec 2002 21:46:49.0993 (UTC) FILETIME=[7AAA6F90:01C29FCC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB9LlWv02054 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 Another performance report on SNMPv3. This is in msgs/sec. dbh -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Monday, December 09, 2002 1:48 PM To: Randy Presuhn Cc: snmpv3@lists.tislabs.com Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? >>>>> On Fri, 6 Dec 2002 17:30:51 -0800 (PST), Randy Presuhn said: Randy> My recollection from several years ago was that for Randy> single-varbbind requests in a noAuth/noPriv configuration, we Randy> were geting about 100 per second on ancient hardware using Randy> SMUX, and proportionately less (due to greater overhead) with Randy> AgentX. Just for kicks, I ran 10000 requests of various kinds against the Net-SNMP stack (which is not a well optimized stack compared to the commercial vendors) and timed the results. This was on a 233 PIII laptop which was not idle by any means, so take the numbers with a grain of salt. MD5 and DES were used for auth and priv. sysContact.0 in the Master agent: GET GETNEXT SET AuthPriv 1277 1176 493 AuthNoPriv 1462 1475 514 SNMPv1/2c 3769 3467 675 sysContact.0 in a subagent: GET GETNEXT SET AuthPriv 772 596 304 AuthNoPriv 860 661 355 SNMPv1/2c 1461 1018 420 -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 9 20:59: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 UAA13262 for ; Mon, 9 Dec 2002 20:59:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA229Y16096 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 21:02:09 -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 gBA21iv16070; Mon, 9 Dec 2002 21:01:44 -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 gBA20sv16014 for ; Mon, 9 Dec 2002 21:00:54 -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 UAA13258 for ; Mon, 9 Dec 2002 20:57:51 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBA20bKv008426; Mon, 9 Dec 2002 18:00:37 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK64972; Mon, 9 Dec 2002 17:57:30 -0800 (PST) Date: Mon, 9 Dec 2002 18:00:58 -0800 Subject: Re: [midcom] Time for a Time-Out? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Eric Burger , "IETF Midcom (E-mail)" To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3DF0CF13.60102@dynamicsoft.com> Message-Id: <39A6BF0C-0BE3-11D7-8C59-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) 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 Jonathan, I agree 100% with your proposed order. If a new protocol fits the requirements.... The original justification for reusing an existing protocol was simplicity and speed. I don't think anyone, even the critics, thought that reusing an existing protocol would be so hard. thanks, -rohan On Friday, December 6, 2002, at 08:23 AM, Jonathan Rosenberg wrote: > I've personally been silent on all of this stuff for quite some time. > To be honest, that is primarily due to my frustration at the general > lack of progress and amazing circuitousness (is that a word) of the > path we have taken to completion of this work. > > Some responses inline. > > Eric Burger wrote: > > > Last time I looked, the IETF is the organization that does protocols. > > Why do we have this aversion to creating a protocol? Because of > > marketplace realities, I have to build a proprietary protocol to make > > something that works and scales. > > > > Now let's look at midcom and progress to date. It has been over a > > year, > > Oh, much longer than that. I recall the foglamps bof meeting in > Adelaide in March 2000, which is almost three years ago. Most groups > produce real protocols in faster than three years after their bof. > > > and the work group really hasn't produced anything of > > substance. There is still discussion on the list about the > > requirements. At the rate we're going, I don't expect that we will > > produce anything in the coming year, either. > > I agree. > > I think it is time for a change in direction. Right now, we are on a > path to fail. There are folks in each protocol camp who will clearly > not budge. There is also, I think, a good contingent (myself included) > who would rather build a new, simple-as-possible protocol for the task > at hand. There is also a large contingent that is tired and no longer > cares. Indeed, the participation in list discussion has dropped > tremendously since this evaluation process began. Where is everyone? > > I would like to propose that the group consider some radical actions > at this point. Short of that, we will probbaly fail to produce > anything at all. > > I do not know what the right thing is, but here are some ideas: > > 1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new > protocol people all develop their own protocols. Make the semantics > doc a mandatory thing, so that each protocol must provide the > semantics described there, and show a mapping. THis is akin to the > CPIM approach. THen, let the market pick a winner. Three is better > than zero, I guess. > > 2. Shut down: Just give up. Close the group. This interface remains > proprietary. We have things like TURN, ALGs and eventually nsis, which > is (I think) the right answer. Of course nsis is probably 5 years away > from useful deployment. > > 3. Move to IRTF: As Eric suggests. > > 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and > we do that (seems unlikely but I throw it out for consideration). > > 5. New protocol: do a new one from scratch. > > Other ideas? I would favor approach 5 first, then 1, then 4, then 2, > then 3. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 Dec 9 21:00: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 VAA13324 for ; Mon, 9 Dec 2002 21:00:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA23KZ16151 for midcom-archive@odin.ietf.org; Mon, 9 Dec 2002 21:03:20 -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 gBA232v16129; Mon, 9 Dec 2002 21:03:02 -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 gBA22gv16115 for ; Mon, 9 Dec 2002 21:02:42 -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 UAA13276 for ; Mon, 9 Dec 2002 20:59:39 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA22OFp021187; Mon, 9 Dec 2002 18:02:24 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK64985; Mon, 9 Dec 2002 17:59:18 -0800 (PST) Date: Mon, 9 Dec 2002 18:02:45 -0800 Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Juergen Quittek , Mary Barnes , "'Durham, David'" , "'midcom@ietf.org'" To: Melinda Shore From: Rohan Mahy In-Reply-To: <200212061712.ABD72727@mira-sjc5-c.cisco.com> Message-Id: <79C7E118-0BE3-11D7-8C59-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) 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 On Friday, December 6, 2002, at 09:12 AM, Melinda Shore wrote: [snip] > we absolutely don't value/privilege process over > technical soundness. However, we do need to push on ahead > if we're going to get our work done, and I'm hoping against > hope that people will start showing greater willingness to > compromise. Each of us needs to think hard about what the > consequences would be for the working group (not our > employers) if midcom were to select a protocol other than > the one we individually favor. Consensus-based decision > making simply does not work - at all - in the face of > inflexibility and rigidity on the part of participants. agree 100% thx, -r > 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 Dec 10 08:35: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 IAA05921 for ; Tue, 10 Dec 2002 08:35:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBADbVp29125 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 08:37:31 -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 gBADXYv28407; Tue, 10 Dec 2002 08:33:34 -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 gBADWDv28367 for ; Tue, 10 Dec 2002 08:32:13 -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 IAA05827 for ; Tue, 10 Dec 2002 08:29:15 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBADWAKv017245 for ; Tue, 10 Dec 2002 05:32:10 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF08081; Tue, 10 Dec 2002 05:32:09 -0800 (PST) Message-Id: <200212101332.ABF08081@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 10 Dec 2002 08:32:09 -0500 Subject: [midcom] Protocol decision reminder 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 remind everyone that we're now in the process of going through the protocols, as ranked in the protocol evaluation document, and determining one-by-one their suitability for use as the midcom protocol. If someone cannot come up with a technical argument for why SNMPv3 does not meet the midcom requirements and framework it will become the midcom protocol. If there are no such comments by the end of the week, SNMPv3 will become the midcom protocol. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 11:44: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 LAA12932 for ; Tue, 10 Dec 2002 11:44:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAGl7B11006 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 11:47: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 gBAGhNv10859; Tue, 10 Dec 2002 11:43:23 -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 gBAGgev10817 for ; Tue, 10 Dec 2002 11:42:40 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12760 for ; Tue, 10 Dec 2002 11:39:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.78]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBAGgbYH014862; Tue, 10 Dec 2002 11:42:38 -0500 (EST) Message-ID: <3DF6197A.202@dynamicsoft.com> Date: Tue, 10 Dec 2002 11:42:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder References: <200212101332.ABF08081@mira-sjc5-c.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 Well, I have a question. Has anyone gone through the semantics document in detail and analyzed whether or not the abstract protocol can be mapped into SNMP, and specifically, whether SMI is a sufficient data model for what we need to do? I am not saying it isn't, I am merely saying that we better be sure it is OK before selecting SNMP. To be honest, the requirements and framework, which form the basis of the evaluation, are really high level. The devil with midcom is in the details, which have received scant attention. I fear that we might make a choice and then find that some detailed operation we want to do cannot be accomplished. Thanks, Jonathan R. Melinda Shore wrote: > I'd like to remind everyone that we're now in the process of > going through the protocols, as ranked in the protocol > evaluation document, and determining one-by-one their > suitability for use as the midcom protocol. > > If someone cannot come up with a technical argument for why > SNMPv3 does not meet the midcom requirements and framework > it will become the midcom protocol. If there are no such > comments by the end of the week, SNMPv3 will become the > midcom protocol. > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 12:40:28 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 MAA15100 for ; Tue, 10 Dec 2002 12:40:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAHgug15245 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 12:42:56 -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 gBAHgHv15215; Tue, 10 Dec 2002 12:42:17 -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 gBAHepv15117 for ; Tue, 10 Dec 2002 12:40:51 -0500 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 MAA14944 for ; Tue, 10 Dec 2002 12:37:38 -0500 (EST) 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 gBAHe7914365; Tue, 10 Dec 2002 18:40:10 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 18:40:07 +0100 Message-ID: From: "Cedric Aoun" To: "'Jonathan Rosenberg'" , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] Protocol decision reminder Date: Tue, 10 Dec 2002 18:40:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A072.4903E786" 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_01C2A072.4903E786 Content-Type: text/plain; charset="iso-8859-1" Jonathan, I completely agree with you, that's the point I tried to raise last week. How can we proceed if we didn't evaluate SNMP against the protocol semantics? It is crucial that we evaluate SNMP against the semantics and the performance required by the different network scenarios (low end and high end devices). There could be other operational aspects to evaluate against as well. Cedric -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 10 December 2002 17:43 To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder Well, I have a question. Has anyone gone through the semantics document in detail and analyzed whether or not the abstract protocol can be mapped into SNMP, and specifically, whether SMI is a sufficient data model for what we need to do? I am not saying it isn't, I am merely saying that we better be sure it is OK before selecting SNMP. To be honest, the requirements and framework, which form the basis of the evaluation, are really high level. The devil with midcom is in the details, which have received scant attention. I fear that we might make a choice and then find that some detailed operation we want to do cannot be accomplished. Thanks, Jonathan R. Melinda Shore wrote: > I'd like to remind everyone that we're now in the process of > going through the protocols, as ranked in the protocol > evaluation document, and determining one-by-one their > suitability for use as the midcom protocol. > > If someone cannot come up with a technical argument for why > SNMPv3 does not meet the midcom requirements and framework > it will become the midcom protocol. If there are no such > comments by the end of the week, SNMPv3 will become the > midcom protocol. > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C2A072.4903E786 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Protocol decision reminder

Jonathan,
I completely agree with you, that's the point I = tried to raise last week.
How can we proceed if we didn't evaluate SNMP = against the protocol semantics?
It is crucial that we evaluate SNMP against the = semantics and the performance required by the different network = scenarios (low end and high end devices). There could be other = operational aspects to evaluate against as well.

Cedric

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: 10 December 2002 17:43
To: Melinda Shore
Cc: midcom@ietf.org
Subject: Re: [midcom] Protocol decision = reminder


Well, I have a question.

Has anyone gone through the semantics document in = detail and analyzed
whether or not the abstract protocol can be mapped = into SNMP, and
specifically, whether SMI is a sufficient data model = for what we need to
do? I am not saying it isn't, I am merely saying = that we better be sure
it is OK before selecting SNMP. To be honest, the = requirements and
framework, which form the basis of the evaluation, = are really high
level. The devil with midcom is in the details, = which have received
scant attention. I fear that we might make a choice = and then find that
some detailed operation we want to do cannot be = accomplished.

Thanks,
Jonathan R.

Melinda Shore wrote:
> I'd like to remind everyone that we're now in = the process of
> going through the protocols, as ranked in the = protocol
> evaluation document, and determining one-by-one = their
> suitability for use as the midcom = protocol. 
>
> If someone cannot come up with a technical = argument for why
> SNMPv3 does not meet the midcom requirements = and framework
> it will become the midcom protocol.  If = there are no such
> comments by the end of the week, SNMPv3 will = become the
> midcom protocol.
>
> Thanks,
>
> Melinda
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

--
Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
dynamicsoft        &nbs= p;           &nbs= p;            = East Hanover, NJ 07936
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

------_=_NextPart_001_01C2A072.4903E786-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 12:58:15 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 MAA15910 for ; Tue, 10 Dec 2002 12:58:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAI0hr16157 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 13:00: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 gBAI0Gv16125; Tue, 10 Dec 2002 13:00: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 gBAHxVv16075 for ; Tue, 10 Dec 2002 12:59:31 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15853 for ; Tue, 10 Dec 2002 12:56:32 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 12:59:26 -0500 Message-ID: <5001C86452603F41820378E167091F07EED9D9@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'Jonathan Rosenberg'" , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] Protocol decision reminder Date: Tue, 10 Dec 2002 12:58:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Seems the right thing to do. For all main protocol candidates. Assuming we can find some volunteers to work on a given protocol mapping (which is maybe a way in itself to further slim down the list). Frankly, I don't believe the ranking of the protocol evaluation document is terribly significant, given how close the main candidates were. Nor do I believe that we should necessarily select only one protocol. So I agree with Jonathan, such protocol mapping should be developed before jumping to any conclusion. Jerome -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, December 10, 2002 11:43 AM To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder Well, I have a question. Has anyone gone through the semantics document in detail and analyzed whether or not the abstract protocol can be mapped into SNMP, and specifically, whether SMI is a sufficient data model for what we need to do? I am not saying it isn't, I am merely saying that we better be sure it is OK before selecting SNMP. To be honest, the requirements and framework, which form the basis of the evaluation, are really high level. The devil with midcom is in the details, which have received scant attention. I fear that we might make a choice and then find that some detailed operation we want to do cannot be accomplished. Thanks, Jonathan R. Melinda Shore wrote: > I'd like to remind everyone that we're now in the process of > going through the protocols, as ranked in the protocol > evaluation document, and determining one-by-one their > suitability for use as the midcom protocol. > > If someone cannot come up with a technical argument for why > SNMPv3 does not meet the midcom requirements and framework > it will become the midcom protocol. If there are no such > comments by the end of the week, SNMPv3 will become the > midcom protocol. > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 Dec 10 13:00: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 NAA15990 for ; Tue, 10 Dec 2002 13:00:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAI2SU16278 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 13:02:28 -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 gBAI22v16244; Tue, 10 Dec 2002 13:02:02 -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 gBAI1cv16222 for ; Tue, 10 Dec 2002 13:01:38 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15926 for ; Tue, 10 Dec 2002 12:58:39 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA20612 for ; Tue, 10 Dec 2002 13:13:43 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma020561; Tue, 10 Dec 02 13:12:45 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 10 Dec 2002 13:00:54 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 13:00:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Protocol decision reminder Date: Tue, 10 Dec 2002 13:00:53 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892AB@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Protocol decision reminder Thread-Index: AcKga/06j4CmyKLURtmwiHOSVVP2rAAAVcGg From: "Harrington, David" To: X-OriginalArrivalTime: 10 Dec 2002 18:00:54.0125 (UTC) FILETIME=[1526E1D0:01C2A076] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBAI1cv16223 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 Hi, I have read the complete semantics document through, thinking about each requirement, and I believe SNMPv3 can achieve all the semantic requirements. I am now considering the requirements of the needed mibs, and existing mibs, such as the NAT MIB, that are already under development. I will observe that the semantics document approaches the problem in a particular way, with some implicit design decisions. If I were designing from scratch with the assumption of SNMPv3 as the protocol, I would make some different design decisions to improve the alignment with best current practices of SNMP MIB design. Some of the mibs would be rather inefficient if designed to match the identified semantics. I expect all the protocols reviewers will find that they might have made slightly different design decisions to optimize their protocol to create more efficient/effective designs that achieve the same ends. So my question is, after selecting a protocol, does the group intend to review the semantic model to align it with best current practices of the protocol chosen (without throwing out the original semantics document, or ignoring the purpose of the original semantic requirements)? dbh > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, December 10, 2002 11:43 AM > To: Melinda Shore > Cc: midcom@ietf.org > Subject: Re: [midcom] Protocol decision reminder > > > Well, I have a question. > > Has anyone gone through the semantics document in detail and analyzed > whether or not the abstract protocol can be mapped into SNMP, and > specifically, whether SMI is a sufficient data model for what > we need to > do? I am not saying it isn't, I am merely saying that we > better be sure > it is OK before selecting SNMP. To be honest, the requirements and > framework, which form the basis of the evaluation, are really high > level. The devil with midcom is in the details, which have received > scant attention. I fear that we might make a choice and then > find that > some detailed operation we want to do cannot be accomplished. > > Thanks, > Jonathan R. > > Melinda Shore wrote: > > I'd like to remind everyone that we're now in the process of > > going through the protocols, as ranked in the protocol > > evaluation document, and determining one-by-one their > > suitability for use as the midcom protocol. > > > > If someone cannot come up with a technical argument for why > > SNMPv3 does not meet the midcom requirements and framework > > it will become the midcom protocol. If there are no such > > comments by the end of the week, SNMPv3 will become the > > midcom protocol. > > > > Thanks, > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 Dec 10 13:05: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 NAA16154 for ; Tue, 10 Dec 2002 13:05:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAI8Nd17202 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 13:08:23 -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 gBAI83v17179; Tue, 10 Dec 2002 13:08: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 gBAI7Jv16955 for ; Tue, 10 Dec 2002 13:07:19 -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 NAA16098 for ; Tue, 10 Dec 2002 13:04:19 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAI77Fp023684; Tue, 10 Dec 2002 10:07:07 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF20358; Tue, 10 Dec 2002 10:07:06 -0800 (PST) Message-Id: <200212101807.ABF20358@mira-sjc5-c.cisco.com> To: "Cedric Aoun" cc: "'Jonathan Rosenberg'" , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Protocol decision reminder In-Reply-To: Message from "Cedric Aoun" of "Tue, 10 Dec 2002 18:40:07 +0100." Date: Tue, 10 Dec 2002 13:07:05 -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: , > It is crucial that we evaluate SNMP against the semantics and the > performance required by the different network scenarios (low end and high > end devices). There could be other operational aspects to evaluate against > as well. If there are specific problems they need to be raised on this mailing list. So far the only objections have been speculation that there might possibly be problems lurking out there somewhere, and we need for the discussion to be specific and productive. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 13:10:15 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 NAA16308 for ; Tue, 10 Dec 2002 13:10:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAIChG17455 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 13:12: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 gBAI91v17261; Tue, 10 Dec 2002 13:09:01 -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 gBAI8lv17226 for ; Tue, 10 Dec 2002 13:08:47 -0500 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 NAA16149 for ; Tue, 10 Dec 2002 13:05:47 -0500 (EST) 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 gBAI8A917836; Tue, 10 Dec 2002 19:08:11 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 19:08:10 +0100 Message-ID: From: "Cedric Aoun" To: Jonathan Rosenberg Cc: Eric Burger , "IETF Midcom (E-mail)" Subject: RE: [midcom] Time for a Time-Out? Date: Tue, 10 Dec 2002 19:08:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A077.179BE8E2" 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_01C2A077.179BE8E2 Content-Type: text/plain; charset="iso-8859-1" I agree with you. I know we're all tired of discussing this and not delivering a protocol since the Adelaide meeting (Summer 2000), but what's the point of delivering something if we find out later that it is not applicable (ref to the dictatorial option 4 that you have referenced below)? Here's my preferred ranking on moving forward options that you have stated below: 1,5,2,4 and finally 3 The protocol being elected from 1 might end up being tailored a bit (either MIB, PIB or other if it is a new protocol) so there is a step 6 actually to tailor it. In addition in case the WG is not aware, there seems to be a lot of effort in the IETF to move to XML for configuration, should we interpret this as using SNMPv3 for MIDCOM as a risk? Thanks Cedric > I've personally been silent on all of this stuff for quite some time. > To be honest, that is primarily due to my frustration at the general > lack of progress and amazing circuitousness (is that a word) of the > path we have taken to completion of this work. > > Some responses inline. > > Eric Burger wrote: > > > Last time I looked, the IETF is the organization that does protocols. > > Why do we have this aversion to creating a protocol? Because of > > marketplace realities, I have to build a proprietary protocol to make > > something that works and scales. > > > > Now let's look at midcom and progress to date. It has been over a > > year, > > Oh, much longer than that. I recall the foglamps bof meeting in > Adelaide in March 2000, which is almost three years ago. Most groups > produce real protocols in faster than three years after their bof. > > > and the work group really hasn't produced anything of > > substance. There is still discussion on the list about the > > requirements. At the rate we're going, I don't expect that we will > > produce anything in the coming year, either. > > I agree. > > I think it is time for a change in direction. Right now, we are on a > path to fail. There are folks in each protocol camp who will clearly > not budge. There is also, I think, a good contingent (myself included) > who would rather build a new, simple-as-possible protocol for the task > at hand. There is also a large contingent that is tired and no longer > cares. Indeed, the participation in list discussion has dropped > tremendously since this evaluation process began. Where is everyone? > > I would like to propose that the group consider some radical actions > at this point. Short of that, we will probbaly fail to produce > anything at all. > > I do not know what the right thing is, but here are some ideas: > > 1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new > protocol people all develop their own protocols. Make the semantics > doc a mandatory thing, so that each protocol must provide the > semantics described there, and show a mapping. THis is akin to the > CPIM approach. THen, let the market pick a winner. Three is better > than zero, I guess. > > 2. Shut down: Just give up. Close the group. This interface remains > proprietary. We have things like TURN, ALGs and eventually nsis, which > is (I think) the right answer. Of course nsis is probably 5 years away > from useful deployment. > > 3. Move to IRTF: As Eric suggests. > > 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and > we do that (seems unlikely but I throw it out for consideration). > > 5. New protocol: do a new one from scratch. > > Other ideas? I would favor approach 5 first, then 1, then 4, then 2, > then 3. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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_01C2A077.179BE8E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Time for a Time-Out?

I agree with you.

I know we're all tired of discussing this and not = delivering a protocol since the Adelaide meeting (Summer 2000), but = what's the point of delivering something if we find out later that it = is not applicable (ref to the dictatorial option 4 that you have = referenced below)?

Here's my preferred ranking on moving forward options = that you have stated below:
1,5,2,4 and finally 3

The protocol being elected from 1 might end up being = tailored a bit (either MIB, PIB or other if it is a new protocol) so = there is a step 6 actually to tailor it.

In addition in case the WG is not aware, there seems = to be a lot of effort in the IETF to move to XML for configuration, = should we interpret this as using SNMPv3 for MIDCOM as a = risk?

Thanks

Cedric


> I've personally been silent on all of this stuff = for quite some time.
> To  be honest, that is primarily due to my = frustration at the general
> lack of progress and amazing circuitousness (is = that a word) of the
> path we have taken to completion of this = work.
>
> Some responses inline.
>
> Eric Burger wrote:
>
> > Last time I looked, the IETF is the = organization that does protocols.
> > Why do we have this aversion to creating a = protocol?  Because of
> > marketplace realities, I have to build a = proprietary protocol to make
> > something that works and scales.
> >
> > Now let's look at midcom and progress to = date.  It has been over a
> > year,
>
> Oh, much longer than that. I recall the = foglamps bof meeting in
> Adelaide in March 2000, which is almost three = years ago. Most groups
> produce real protocols in faster than three = years after their bof.
>
> > and the work group really hasn't produced = anything of
> > substance.  There is still discussion = on the list about the
> > requirements.  At the rate we're = going, I don't expect that we will
> > produce anything in the coming year, = either.
>
> I agree.
>
> I think it is time for a change in direction. = Right now, we are on a
> path to fail. There are folks in each protocol = camp who will clearly
> not budge. There is also, I think, a good = contingent (myself included)
> who would rather build a new, = simple-as-possible protocol for the task
> at hand. There is also a large contingent that = is tired and no longer
> cares. Indeed, the participation in list = discussion has dropped
> tremendously since this evaluation process = began. Where is everyone?
>
> I would like to propose that the group consider = some radical actions
> at this point. Short of that, we will probbaly = fail to produce
> anything at all.
>
> I do not know what the right thing is, but here = are some ideas:
>
> 1. Parallelism, ala IMPP: Let the COPS people, = SNMP people, and new
> protocol people all develop their own = protocols. Make the semantics
> doc a mandatory thing, so that each protocol = must provide the
> semantics described there, and show a mapping. = THis is akin to the
> CPIM approach. THen, let the market pick a = winner. Three is better
> than zero, I guess.
>
> 2. Shut down: Just give up. Close the group. = This interface remains
> proprietary. We have things like TURN, ALGs and = eventually nsis, which
> is (I think) the right answer. Of course nsis = is probably 5 years away
> from useful deployment.
>
> 3. Move to IRTF: As Eric suggests.
>
> 4. Dictatorial Fiat: The IESG tells the group = to "use protocol X" and
> we do that (seems unlikely but I throw it out = for consideration).
>
> 5. New protocol: do a new one from = scratch.
>
> Other ideas? I would favor approach 5 first, = then 1, then 4, then 2,
> then 3.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> 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_01C2A077.179BE8E2-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 13:22: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 NAA16693 for ; Tue, 10 Dec 2002 13:22:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAIPLh18144 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 13:25: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 gBAILGv18046; Tue, 10 Dec 2002 13:21: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 gBAIKqv18014 for ; Tue, 10 Dec 2002 13:20:52 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16590 for ; Tue, 10 Dec 2002 13:17:52 -0500 (EST) Received: from [64.100.160.211] by halt-in.cisco.com (171.70.144.185) with ESMTP; 10 Dec 2002 10:21:14 +0000 Message-ID: <3DF6307B.1000301@cisco.com> Date: Tue, 10 Dec 2002 10:20:43 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder References: <6D745637A7E0F94DA070743C55CDA9BA4892AB@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA4892AB@NHROCMBX1.ets.enterasys.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 SNMP version 3's security model, while novel, does not provide for distributed *integrated* key/certificate management. There is no equivalent of Kerberos for SNMP users. Scalable authorization of requests is required. Eliot _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 13:32: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 NAA17031 for ; Tue, 10 Dec 2002 13:32:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAIYhI18686 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 13:34: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 gBAIYLv18661; Tue, 10 Dec 2002 13:34:21 -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 gBAIXCv18564 for ; Tue, 10 Dec 2002 13:33:12 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16935 for ; Tue, 10 Dec 2002 13:30:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.78]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBAIX9YH014909; Tue, 10 Dec 2002 13:33:09 -0500 (EST) Message-ID: <3DF6335E.4010208@dynamicsoft.com> Date: Tue, 10 Dec 2002 13:33:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Moisand, Jerome" CC: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder References: <5001C86452603F41820378E167091F07EED9D9@email1.unispherenetworks.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 just want to clarify my statements. I am not saying we need to actually write a mapping document before making a choice. Last thing we need is more process. We just need to be comfortable that the semantics document can be mapped to a MIB or a PIB. -Jonathan R. Moisand, Jerome wrote: > Seems the right thing to do. For all main protocol candidates. Assuming we > can find some volunteers to work on a given protocol mapping (which is maybe > a way in itself to further slim down the list). > > Frankly, I don't believe the ranking of the protocol evaluation document is > terribly significant, given how close the main candidates were. Nor do I > believe that we should necessarily select only one protocol. > > So I agree with Jonathan, such protocol mapping should be developed before > jumping to any conclusion. > > Jerome > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, December 10, 2002 11:43 AM > To: Melinda Shore > Cc: midcom@ietf.org > Subject: Re: [midcom] Protocol decision reminder > > > Well, I have a question. > > Has anyone gone through the semantics document in detail and analyzed > whether or not the abstract protocol can be mapped into SNMP, and > specifically, whether SMI is a sufficient data model for what we need to > do? I am not saying it isn't, I am merely saying that we better be sure > it is OK before selecting SNMP. To be honest, the requirements and > framework, which form the basis of the evaluation, are really high > level. The devil with midcom is in the details, which have received > scant attention. I fear that we might make a choice and then find that > some detailed operation we want to do cannot be accomplished. > > Thanks, > Jonathan R. > > Melinda Shore wrote: > >>I'd like to remind everyone that we're now in the process of >>going through the protocols, as ranked in the protocol >>evaluation document, and determining one-by-one their >>suitability for use as the midcom protocol. >> >>If someone cannot come up with a technical argument for why >>SNMPv3 does not meet the midcom requirements and framework >>it will become the midcom protocol. If there are no such >>comments by the end of the week, SNMPv3 will become the >>midcom protocol. >> >>Thanks, >> >>Melinda >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>https://www1.ietf.org/mailman/listinfo/midcom >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 13:32: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 NAA17030 for ; Tue, 10 Dec 2002 13:32:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAIYhT18677 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 13:34: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 gBAIV8v18443; Tue, 10 Dec 2002 13:31: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 gBAIUKv18388 for ; Tue, 10 Dec 2002 13:30:20 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16875 for ; Tue, 10 Dec 2002 13:27:20 -0500 (EST) Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-7.07) id A2B551CA0182; Tue, 10 Dec 2002 13:30:13 -0500 Message-ID: <004201c2a07a$25a379c0$2300000a@BPenfield> From: "Bob Penfield" To: "Harrington, David" , References: <6D745637A7E0F94DA070743C55CDA9BA256F1D@NHROCMBX1.ets.enterasys.com> Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Tue, 10 Dec 2002 13:29:59 -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.2720.3000 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 Are those numbers transactions per second? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Harrington, David" > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > Just for kicks, I ran 10000 requests of various kinds against the > Net-SNMP stack (which is not a well optimized stack compared to > the commercial vendors) and timed the results. This was on a 233 PIII > laptop which was not idle by any means, so take the numbers with a > grain of salt. MD5 and DES were used for auth and priv. > > sysContact.0 in the Master agent: > > GET GETNEXT SET > AuthPriv 1277 1176 493 > AuthNoPriv 1462 1475 514 > SNMPv1/2c 3769 3467 675 > > sysContact.0 in a subagent: > > GET GETNEXT SET > AuthPriv 772 596 304 > AuthNoPriv 860 661 355 > SNMPv1/2c 1461 1018 420 > > > -- > Wes Hardaker > Network Associates Laboratories > _______________________________________________ > 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 Dec 10 13:59: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 NAA17691 for ; Tue, 10 Dec 2002 13:59:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAJ1rV20626 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 14:01:53 -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 gBAIwAv20501; Tue, 10 Dec 2002 13:58:10 -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 gBAIvtv20475 for ; Tue, 10 Dec 2002 13:57:55 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17536 for ; Tue, 10 Dec 2002 13:54:56 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA24938 for ; Tue, 10 Dec 2002 14:10:01 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma024921; Tue, 10 Dec 02 14:09:26 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 10 Dec 2002 13:57:30 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 13:57:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Protocol decision reminder Date: Tue, 10 Dec 2002 13:57:29 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA256F28@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Protocol decision reminder Thread-Index: AcKgeO3H6XQ8LEDAQOeCjEvr/g5c1wABO8Ig From: "Harrington, David" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 10 Dec 2002 18:57:30.0062 (UTC) FILETIME=[FD49BEE0:01C2A07D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBAIvtv20476 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 Hi Eliot, Is this in response to something I said? dbh > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Tuesday, December 10, 2002 1:21 PM > To: Harrington, David > Cc: midcom@ietf.org > Subject: Re: [midcom] Protocol decision reminder > > > SNMP version 3's security model, while novel, does not provide for > distributed *integrated* key/certificate management. There is no > equivalent of Kerberos for SNMP users. Scalable authorization of > requests is required. > > Eliot > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 14:03: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 OAA17900 for ; Tue, 10 Dec 2002 14:03:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAJ5WJ20811 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 14:05:32 -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 gBAJ5Bv20757; Tue, 10 Dec 2002 14:05:11 -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 gBAJ4Xv20701 for ; Tue, 10 Dec 2002 14:04:33 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17843 for ; Tue, 10 Dec 2002 14:01:34 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA25487 for ; Tue, 10 Dec 2002 14:16:39 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma025455; Tue, 10 Dec 02 14:16:07 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 10 Dec 2002 14:04:15 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 14:04:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Tue, 10 Dec 2002 14:04:15 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA256F29@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKgej+70qnUg+yFSfyGwTP3HiZgHwABJglA From: "Harrington, David" To: "Bob Penfield" , X-OriginalArrivalTime: 10 Dec 2002 19:04:15.0625 (UTC) FILETIME=[EF05BF90:01C2A07E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBAJ4Yv20702 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 Wes posted yesterday stating that it was messages per second. dbh > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Tuesday, December 10, 2002 1:30 PM > To: Harrington, David; midcom@ietf.org > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > Are those numbers transactions per second? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Harrington, David" > > -----Original Message----- > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > > > Just for kicks, I ran 10000 requests of various kinds against the > > Net-SNMP stack (which is not a well optimized stack compared to > > the commercial vendors) and timed the results. This was on > a 233 PIII > > laptop which was not idle by any means, so take the numbers with a > > grain of salt. MD5 and DES were used for auth and priv. > > > > sysContact.0 in the Master agent: > > > > GET GETNEXT SET > > AuthPriv 1277 1176 493 > > AuthNoPriv 1462 1475 514 > > SNMPv1/2c 3769 3467 675 > > > > sysContact.0 in a subagent: > > > > GET GETNEXT SET > > AuthPriv 772 596 304 > > AuthNoPriv 860 661 355 > > SNMPv1/2c 1461 1018 420 > > > > > > -- > > Wes Hardaker > > Network Associates Laboratories > > _______________________________________________ > > 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 Dec 10 14:03: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 OAA17933 for ; Tue, 10 Dec 2002 14:03:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAJ6Qw20881 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 14:06:26 -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 gBAJ63v20859; Tue, 10 Dec 2002 14:06: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 gBAJ5gv20825 for ; Tue, 10 Dec 2002 14:05:42 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17898 for ; Tue, 10 Dec 2002 14:02:42 -0500 (EST) Received: from [64.100.160.211] by halt-in.cisco.com (171.70.144.185) with ESMTP; 10 Dec 2002 11:06:08 +0000 Message-ID: <3DF63B00.9050005@cisco.com> Date: Tue, 10 Dec 2002 11:05:36 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder References: <6D745637A7E0F94DA070743C55CDA9BA256F28@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA256F28@NHROCMBX1.ets.enterasys.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 Harrington, David wrote: > Hi Eliot, > > Is this in response to something I said? Generic comment about SNMP. Melinda asked for comments. I'm not sure SNMP meets MIDCOM requirements in their entirety. Is it close enough? That's an interesting question... Eliot _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 14:39:20 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 OAA18843 for ; Tue, 10 Dec 2002 14:39:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAJfnA23559 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 14:41:49 -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 gBAJf7v23536; Tue, 10 Dec 2002 14:41: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 gBAJekv23520 for ; Tue, 10 Dec 2002 14:40:46 -0500 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 OAA18823 for ; Tue, 10 Dec 2002 14:37:45 -0500 (EST) 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 gBAJeT921670; Tue, 10 Dec 2002 20:40:29 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 20:40:28 +0100 Message-ID: From: "Cedric Aoun" To: "'Harrington, David'" , Bob Penfield , midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Tue, 10 Dec 2002 20:40:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A083.FDD15B92" 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_01C2A083.FDD15B92 Content-Type: text/plain; charset="iso-8859-1" In order to comment on these performance figures we need to understand if in order to install a policy rule we need more than a pair of messages (set and set response), I don't know if we got closure on the command aggregation or not without any proprietary hacks (sorry got lost in all the threads). The figures could be more representative if we could use the NAT MIB and see how the figures are affected. Is it possible to get the figures on the MIDCOM agent side (SNMP manager)? The next step is to see how to match this to real application sessions per sec that people expect this protocol to deliver on their boxes. We might get some agreement on the expected performance by saying that 6 or 8 pairs of MIDCOM messages (a pair is made of a request and reply) are required (between policy rule installation and policy rule deletion), in an average hold time of 1 min (let's say this is the worst case) this takes us to 16 MIDCOM messages (SNMP messages? ref to my note above) per mins for every application session (VoIP session, RTSP etc ...). After that, everyone can see if SNMPv3 meets their performance expectation (obviously without doing any implementation hacks, we're talking of a standard SNMPv3 stack). Thanks Cedric -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: 10 December 2002 20:04 To: Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Wes posted yesterday stating that it was messages per second. dbh > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Tuesday, December 10, 2002 1:30 PM > To: Harrington, David; midcom@ietf.org > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > Are those numbers transactions per second? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Harrington, David" > > -----Original Message----- > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > > > Just for kicks, I ran 10000 requests of various kinds against the > > Net-SNMP stack (which is not a well optimized stack compared to > > the commercial vendors) and timed the results. This was on > a 233 PIII > > laptop which was not idle by any means, so take the numbers with a > > grain of salt. MD5 and DES were used for auth and priv. > > > > sysContact.0 in the Master agent: > > > > GET GETNEXT SET > > AuthPriv 1277 1176 493 > > AuthNoPriv 1462 1475 514 > > SNMPv1/2c 3769 3467 675 > > > > sysContact.0 in a subagent: > > > > GET GETNEXT SET > > AuthPriv 772 596 304 > > AuthNoPriv 860 661 355 > > SNMPv1/2c 1461 1018 420 > > > > > > -- > > Wes Hardaker > > Network Associates Laboratories > > _______________________________________________ > > 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_01C2A083.FDD15B92 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

In order to comment on these performance figures we = need to understand if in order to install a policy rule we need
more than a pair of messages (set and set response), = I don't know if we got closure on the command aggregation or not = without any proprietary hacks (sorry got lost in all the = threads).

The figures could be more representative if we could = use the NAT MIB and see how the figures are affected.

Is it possible to get the figures on the MIDCOM agent = side (SNMP manager)?

The next step is to see how to match this to real = application sessions per sec that people expect this protocol to = deliver on their boxes.

We might get some agreement on the expected = performance by saying that 6 or 8 pairs of MIDCOM messages (a pair is = made of a request and reply) are required (between policy rule = installation and policy rule deletion), in an average hold time of 1 = min (let's say this is the worst case) this takes us to 16 MIDCOM = messages (SNMP messages? ref to my note above) per mins for every = application session (VoIP session, RTSP etc ...).

After that, everyone can see if SNMPv3 meets their = performance expectation (obviously without doing any implementation = hacks, we're talking of a standard SNMPv3 stack).

Thanks
Cedric

 

-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: 10 December 2002 20:04
To: Bob Penfield; midcom@ietf.org
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: = Opinions?


Wes posted yesterday stating that it was messages per = second.

dbh

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
> Sent: Tuesday, December 10, 2002 1:30 PM
> To: Harrington, David; midcom@ietf.org
> Subject: Re: [midcom] SNMPv3 as MIDCOM = protocol: Opinions?
>
>
> Are those numbers transactions per second? =
>
> cheers,
> (-:bob
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
>
> ----- Original Message -----
> From: "Harrington, David" = <dbh@enterasys.com>
> > -----Original Message-----
> > From: Wes Hardaker [mailto:hardaker@tislabs.com]
> >
> > Just for kicks, I ran 10000 requests of = various kinds against the
> > Net-SNMP stack (which is not a well = optimized stack compared to
> > the commercial vendors) and timed the = results.  This was on
> a 233 PIII
> > laptop which was not idle by any means, so = take the numbers with a
> > grain of salt.  MD5 and DES were used = for auth and priv.
> >
> > sysContact.0 in the Master agent:
> >
> = >           &n= bsp;            = GET    GETNEXT    SET
> >   = AuthPriv          &nbs= p; 1277    1176       = 493
> >   = AuthNoPriv          = 1462    1475       = 514
> >   = SNMPv1/2c           = 3769    3467       = 675
> >
> > sysContact.0 in a subagent:
> >
> = >           &n= bsp;            = GET    GETNEXT    SET
> >   = AuthPriv          &nbs= p;  772     = 596       304
> >   = AuthNoPriv           = 860     661       = 355
> >   = SNMPv1/2c           = 1461    1018       = 420
> >
> >
> > --
> > Wes Hardaker
> > Network Associates Laboratories
> > = _______________________________________________
> > 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_01C2A083.FDD15B92-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 14:41: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 OAA18895 for ; Tue, 10 Dec 2002 14:41:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAJiQN23661 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 14:44:26 -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 gBAJi3v23651; Tue, 10 Dec 2002 14:44: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 gBAJh0v23618 for ; Tue, 10 Dec 2002 14:43:00 -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 OAA18860 for ; Tue, 10 Dec 2002 14:40:00 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAJgmFp029843; Tue, 10 Dec 2002 11:42:48 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF28507; Tue, 10 Dec 2002 11:42:47 -0800 (PST) Message-Id: <200212101942.ABF28507@mira-sjc5-c.cisco.com> To: Eliot Lear cc: "Harrington, David" , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Protocol decision reminder In-Reply-To: Message from Eliot Lear of "Tue, 10 Dec 2002 10:20:43 PST." <3DF6307B.1000301@cisco.com> Date: Tue, 10 Dec 2002 14:42:46 -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: , > SNMP version 3's security model, while novel, does not provide for > distributed *integrated* key/certificate management. There is no > equivalent of Kerberos for SNMP users. Scalable authorization of > requests is required. Could you go into more detail about what the issue is here? Although there's an appendix describing how to convert passwords into keys, RFC 2264 doesn't describe where the keys come from and certainly doesn't preclude the use of an external key management system. The limitation is that it doesn't provide a mechanism for the engines to tell each other what keying system they're using. But as the document is currently written I believe that I could use Kerberos without changing anything. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 15:15: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 PAA19714 for ; Tue, 10 Dec 2002 15:15:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAKHst25386 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 15:17:54 -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 gBAKHCv25368; Tue, 10 Dec 2002 15:17: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 gBAKGpv25347 for ; Tue, 10 Dec 2002 15:16:51 -0500 Received: from octavo.xs4all.nl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19707 for ; Tue, 10 Dec 2002 15:13:49 -0500 (EST) Received: from picopoint.com (unknown [192.168.0.1]) by octavo.xs4all.nl (Postfix) with ESMTP id 06BDF637CA for ; Tue, 10 Dec 2002 21:17:04 +0100 (CET) Message-ID: <3DF64B93.4020409@picopoint.com> Date: Tue, 10 Dec 2002 21:16:19 +0100 From: Paul Sijben User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Subject: RE: [midcom] H.248 for midcom? Not. 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 Although Tom ends the quoted message a bit negative I see this mail as quite positive. Tom, what you say you are missing is the multiple relationships. You can in fact get them is you want by creating a package. We (John and I) conceded on that point when we made MEGAGO _because_ we saw that you could add them easily. The package could depict ownership of the terminations and contexts and transfer it if you like. I am sorry but the excess baggage is just nonsense. If you look at the bits we only use and the bits that you need to send, they are identical. TIPHON's EMP usage shows that MEGACO is quite usefule here. I do agree that the (element) management mechanism of MEGACO is too much focussed on the residential gateway scenario. That is why I always conveniently forget about it for any other use and point to a decent management system to address that aspect of operations. Eric Burger's points are covered by this as well. Multiple relationships can be done by giving terminations and contexts an owner attribute. Having two owners for one Termination is a BAD idea anyway. But these comments come from the problem is with the way MIDCOM is written ruleset from the standpoint of a traditional router/firewall. You should not match a RULE to a Termination, you match a _flow_ with a termination. If you look at the flow of packets as identifying things, then it is clear that there is only one owner for a particular flow at a given time! Paul > From: "Tom-PT Taylor" > To: "'Eric Burger'" , > "IETF Midcom (E-mail)" > Subject: RE: [midcom] H.248 for midcom? Not. > Date: Fri, 6 Dec 2002 13:06:20 -0500 > > > Well ... > > This is just for conversation: I've never been terribly happy with the > distortions required to the Megaco model to make it work for midcom. On the > other hand, Megaco is not a pure master/slave protocol, so your final words > bother me a bit. The fact the MG is the boss when it comes to starting up > the control association is actually one of Megaco's black marks in this > application. > > The problems with the Megaco model are clear, and I summarize them here as a > review in the light of the new information provided by the semantics work. > > According to the semantics we have established, the life of a Policy Rule is > independent of the life of the Midcom session in which it was created. > Since the Midcom session is identified with the Megaco control association, > the modelling of Policy Rules in Megaco terms has to allow for such > independent existence. > > The Midcom requirement to allow multiple agents to have access to the same > Policy Rule has no explicit constraint, as far as I can recall. Our > semantics treat this as a matter of transactional exclusion on the one hand > and policy on the other. What is missing is any statement that the owner of > the Policy Rule has to have terminated its session before another Agent can > have access to the rule. I'm not proposing to add such a statement here. > But the implication for Megaco is that a Policy Rule cannot be identified > directly with either a Termination or a Context. We (the Megaco authors) > have finessed this by positing a resource layer, manipulated by properties > of terminations created for that purpose. The fact is that the resources > (i.e. Policy Rules) are a new architectural element, actually orthogonal to > anything else Megaco offers. > > IF the missing constraint described in the previous paragraph were added, a > Policy Rule could be identified straightforwardly with a specific Megaco > Termination. At that point, I think you would find that the fit with Megaco > is pretty good, but of course, there would be a lot of excess baggage. The > problem with the direction of session initiation would remain. > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Friday, December 06, 2002 10:48 AM > > To: IETF Midcom (E-mail) > > Subject: [midcom] H.248 for midcom? Not. > > > > > > Reviewing the MIDCOM protocol evaluation document, I had some > > questions about the H.248 (megaco) analysis. > > > > Requirement 2.1.3, "Middlebox can relate to multiple Agents", > > refers to the ability for a set of agents to manipulate (in > > H.248 parlance) the same end-point. It is true, as described > > in the document, that one can partition a media gateway into > > multiple virtual media gateways (VMG). By design, H.248 > > restricts a one-to-one association between a VMG and an > > agent. In addition, AFAIK the standard H.248 model has no > > possibility for VMG's to have the same end-points. This is > > an architectural feature of H.248. Even if you "extended" > > H.248 to allow the same ephemeral end-point to be addressed > > by two VMG's, it would, by definition, have different names. > > Thus, I do not understand how H.248 could possibly meet this > > requirement. > > > > In fact, the response to Requirement 2.1.4 highlights this > > issue. H.248 is deterministic in the face of multiple > > requests because it cannot have them. > > > > Requirement 2.1.12: > > The biggest leap of faith is the proposal of a MIDCOM Ruleset > > Package. If we stuck with the H.248 master-slave model, I > > would expect rule processing to occur at the MGC (agent). I > > can't envision how to implement a rule set end-point entity. > > It seems to be rather foreign to the whole H.248 framework. > > _______________________________________________ > > 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 -- Paul Sijben tel: +31205210321 Chief Technology Officer tel direct: +31205210333 Picopoint fax: +31205210320 Amsterdam mobile: +31629582154 the Netherlands http://www.picopoint.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 15:36: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 PAA20096 for ; Tue, 10 Dec 2002 15:36:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAKcf726747 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 15:38:41 -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 gBAKZ7v26047; Tue, 10 Dec 2002 15:35: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 gBAKXEv25957 for ; Tue, 10 Dec 2002 15:33:14 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19967 for ; Tue, 10 Dec 2002 15:30:13 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA03929 for ; Tue, 10 Dec 2002 15:45:18 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma003915; Tue, 10 Dec 02 15:44:58 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 10 Dec 2002 15:33:02 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 15:33:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Dec 2002 15:33:02 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892AC@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Protocol decision reminder Thread-Index: AcKgfzK0ZF5owkxXTPSkl0gVjtC8LwAAQIuQ From: "Harrington, David" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 10 Dec 2002 20:33:02.0674 (UTC) FILETIME=[5630EB20:01C2A08B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBAKXEv25958 Subject: [midcom] key distribution 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 Hi Eliot, I certainly concur that distributed integrated key distribution would be a nice thing for SNMPv3. Some proposals to use Diffie-Hellman key distribution for SNMPv3 have been published and implemented, but I do not consider them part of this evaluation. Some proposals to use Kerberos key distribution for SNMPv3 have been published and implemented, but I do not consider them part of this evaluation. I have had discussions about developing a security model for SNMPv3 that uses third-party authentication and authorization, but that also is not part of this evaluation. I searched RFCs 3303 and 3304 and the semantics draft and found no discussion of key distribution as a requirement. While key distribution is not part of this evaluation, I think it is a valid concern. Melinda will need to determine whether discussion in this forum is appropriate, or merely a distracting rathole. When it comes to security and network management, I paid a great deal of attention to the Security Area's meeting in Salt Lake City where they discussed the Security Requirements for Network Management protocols. In that meeting, they identified a number of requirements - message authentication, message encryption, message integrity-checking, data access-control (there might have been a fifth; I haven't found the minutes of that meeting) - and two elements that they considered were explicitly NOT requirements because they could be handled outside the protocol - data privacy policies and key distribution. In fact, they found that SNMPv3 met all the identified requirements, and there was discussion during that meeting, involving Jeff Schiller as a matter of fact, about the desirability of being able to distribute the keys using ASCII configuration scripts. So I question, based on this guidance from the Security Area, whether it needs to be integrated into the protocol. Any key distribution mechanism, Kerberos or ASCII scripts or Expect or XML, should be able to be used to distribute keys. Key distribution is not integrated into SNMPv3, except through the use of SNMPv3, by design. You mentioned that the SNMPv3 security model is novel. That's probably true; it is designed to meet certain requirements that most protocols do not need to meet. Most notably, the security was designed to operate standard-alone, in possibly broken networks, so security was assured even when external authentication/authorization servers could not be reached. dbh > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Tuesday, December 10, 2002 2:06 PM > To: Harrington, David > Cc: midcom@ietf.org > Subject: Re: [midcom] Protocol decision reminder > > > Harrington, David wrote: > > Hi Eliot, > > > > Is this in response to something I said? > > Generic comment about SNMP. Melinda asked for comments. I'm > not sure > SNMP meets MIDCOM requirements in their entirety. Is it > close enough? > That's an interesting question... > > Eliot > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 15:42: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 PAA20272 for ; Tue, 10 Dec 2002 15:42:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAKifs26959 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 15:44:41 -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 gBAKf7v26861; Tue, 10 Dec 2002 15:41: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 gBAKeUv26843 for ; Tue, 10 Dec 2002 15:40:30 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20166 for ; Tue, 10 Dec 2002 15:37:27 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA04298 for ; Tue, 10 Dec 2002 15:52:31 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma004256; Tue, 10 Dec 02 15:51:55 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 10 Dec 2002 15:40:04 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 15:40:04 -0500 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_01C2A08C.51860F90" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Tue, 10 Dec 2002 15:40:04 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892AD@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKghBPy5c7kbvIlQnm4MCie09gkuAAAOnwg From: "Harrington, David" To: X-OriginalArrivalTime: 10 Dec 2002 20:40:04.0534 (UTC) FILETIME=[51A3A560:01C2A08C] 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_01C2A08C.51860F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cedric, =20 I agree that the numbers don't say much without knowing what you're = measuring and what you're comparing to. =20 Are there specific requirements about the number of transactions per = minute that must be met to qualify? I didn't see any in the requirements = documents. Eric raised the issue the other day, saying that the = requireent was for a number of transactions per minute. Even if it took = multiple request/reply pairs to perform a transaction, at ~500 SET = messages per second I don't see that SNMPv3 would have a problem. =20 I fear that this is an unnecessary rathole. There are no identified = minimum requirements. There are no comparative numbers for the other = protocols available. The numbers by themselves are meaningless, except = to show that SNMPv3 throughput has not been found to be a problem in = other environments. =20 dbh =20 -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Tuesday, December 10, 2002 2:40 PM To: Harrington, David; Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? In order to comment on these performance figures we need to understand = if in order to install a policy rule we need=20 more than a pair of messages (set and set response), I don't know if we = got closure on the command aggregation or not without any proprietary = hacks (sorry got lost in all the threads). The figures could be more representative if we could use the NAT MIB and = see how the figures are affected.=20 Is it possible to get the figures on the MIDCOM agent side (SNMP = manager)?=20 The next step is to see how to match this to real application sessions = per sec that people expect this protocol to deliver on their boxes.=20 We might get some agreement on the expected performance by saying that 6 = or 8 pairs of MIDCOM messages (a pair is made of a request and reply) = are required (between policy rule installation and policy rule = deletion), in an average hold time of 1 min (let's say this is the worst = case) this takes us to 16 MIDCOM messages (SNMP messages? ref to my note = above) per mins for every application session (VoIP session, RTSP etc = ...).=20 After that, everyone can see if SNMPv3 meets their performance = expectation (obviously without doing any implementation hacks, we're = talking of a standard SNMPv3 stack). Thanks=20 Cedric=20 -----Original Message-----=20 From: Harrington, David [ mailto:dbh@enterasys.com]=20 Sent: 10 December 2002 20:04=20 To: Bob Penfield; midcom@ietf.org=20 Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?=20 Wes posted yesterday stating that it was messages per second.=20 dbh=20 > -----Original Message-----=20 > From: Bob Penfield [ mailto:bpenfield@acmepacket.com]=20 > Sent: Tuesday, December 10, 2002 1:30 PM=20 > To: Harrington, David; midcom@ietf.org=20 > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions?=20 >=20 >=20 > Are those numbers transactions per second?=20 >=20 > cheers,=20 > (-:bob=20 >=20 > Robert F. Penfield=20 > Chief Software Architect=20 > Acme Packet, Inc.=20 > 130 New Boston Street=20 > Woburn, MA 01801=20 > bpenfield@acmepacket.com=20 >=20 > ----- Original Message -----=20 > From: "Harrington, David" =20 > > -----Original Message-----=20 > > From: Wes Hardaker [ mailto:hardaker@tislabs.com]=20 > >=20 > > Just for kicks, I ran 10000 requests of various kinds against the=20 > > Net-SNMP stack (which is not a well optimized stack compared to=20 > > the commercial vendors) and timed the results. This was on=20 > a 233 PIII=20 > > laptop which was not idle by any means, so take the numbers with a=20 > > grain of salt. MD5 and DES were used for auth and priv.=20 > >=20 > > sysContact.0 in the Master agent:=20 > >=20 > > GET GETNEXT SET=20 > > AuthPriv 1277 1176 493=20 > > AuthNoPriv 1462 1475 514=20 > > SNMPv1/2c 3769 3467 675=20 > >=20 > > sysContact.0 in a subagent:=20 > >=20 > > GET GETNEXT SET=20 > > AuthPriv 772 596 304=20 > > AuthNoPriv 860 661 355=20 > > SNMPv1/2c 1461 1018 420=20 > >=20 > >=20 > > --=20 > > Wes Hardaker=20 > > Network Associates Laboratories=20 > > _______________________________________________=20 > > midcom mailing list=20 > > midcom@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/midcom=20 > >=20 >=20 >=20 _______________________________________________=20 midcom mailing list=20 midcom@ietf.org=20 https://www1.ietf.org/mailman/listinfo/midcom=20 ------_=_NextPart_001_01C2A08C.51860F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
Hi=20 Cedric,
 
I=20 agree that the numbers don't say much without knowing what you're = measuring and=20 what you're comparing to.
 
Are=20 there specific requirements about the number of transactions per minute = that=20 must be met to qualify? I didn't see any in the requirements documents. = Eric=20 raised the issue the other day, saying that the requireent was for a = number of=20 transactions per minute. Even if it took multiple request/reply pairs to = perform=20 a transaction, at ~500 SET messages per second I don't see that SNMPv3 = would=20 have a problem.
 
I fear that this is an = unnecessary rathole.=20 There are no identified minimum requirements. There are no comparative = numbers=20 for the other protocols available. The numbers by themselves are = meaningless,=20 except to show that SNMPv3 throughput has not been found to be a problem = in=20 other environments.
 
dbh
 
 -----Original = Message-----
From:=20 Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com]
Sent: = Tuesday,=20 December 10, 2002 2:40 PM
To: Harrington, David; Bob Penfield; = midcom@ietf.org
Subject: RE: [midcom] SNMPv3 as MIDCOM = protocol:=20 Opinions?

In order to comment on these performance figures we = need to=20 understand if in order to install a policy rule we need =
more than a pair of messages (set and set response), I don't = know if we=20 got closure on the command aggregation or not without any proprietary = hacks=20 (sorry got lost in all the threads).

The figures could be more representative if we could = use the=20 NAT MIB and see how the figures are affected.

Is it possible to get the figures on the MIDCOM = agent side=20 (SNMP manager)?

The next step is to see how to match this to real = application=20 sessions per sec that people expect this protocol to deliver on their = boxes.=20

We might get some agreement on the expected = performance by=20 saying that 6 or 8 pairs of MIDCOM messages (a pair is made of a = request and=20 reply) are required (between policy rule installation and policy rule=20 deletion), in an average hold time of 1 min (let's say this is the = worst case)=20 this takes us to 16 MIDCOM messages (SNMP messages? ref to my note = above) per=20 mins for every application session (VoIP session, RTSP etc ...). =

After that, everyone can see if SNMPv3 meets their = performance=20 expectation (obviously without doing any implementation hacks, we're = talking=20 of a standard SNMPv3 stack).

Thanks
Cedric

-----Original Message-----
From:=20 Harrington, David [mailto:dbh@enterasys.com] =
Sent: 10 December 2002 20:04
To: = Bob Penfield;=20 midcom@ietf.org
Subject: RE: [midcom] SNMPv3 = as MIDCOM=20 protocol: Opinions?


Wes posted yesterday stating that it was messages = per=20 second.

dbh

> -----Original Message-----
>=20 From: Bob Penfield [mailto:bpenfield@acmepacket.com<= /A>]=20
> Sent: Tuesday, December 10, 2002 1:30 = PM=20
> To: Harrington, David; midcom@ietf.org =
> Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: = Opinions?=20
>
> =
> Are those numbers transactions per second? =
>
> cheers,
>=20 (-:bob
>
> = Robert F.=20 Penfield
> Chief Software = Architect=20
> Acme Packet, Inc.
> 130 New=20 Boston Street
> Woburn, MA 01801 =
> bpenfield@acmepacket.com
>=20
> ----- Original Message ----- =
> From: "Harrington, David" = <dbh@enterasys.com>=20
> > -----Original Message----- =
> > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20
> >
> > Just = for kicks, I=20 ran 10000 requests of various kinds against the
>=20 > Net-SNMP stack (which is not a well optimized stack compared = to=20
> > the commercial vendors) and timed the=20 results.  This was on
> a 233 = PIII=20
> > laptop which was not idle by any means, = so take the=20 numbers with a
> > grain of = salt.  MD5 and=20 DES were used for auth and priv.
> >=20
> > sysContact.0 in the Master = agent:=20
> >
>=20 = >           &nb= sp;           =20 GET    GETNEXT    SET
> >  =20 = AuthPriv           = ;=20 1277    1176       = 493=20
> >  =20 AuthNoPriv         =20 1462    1475       = 514=20
> >  =20 SNMPv1/2c          =20 3769    3467       = 675=20
> >
> > = sysContact.0 in a=20 subagent:
> >
>=20 = >           &nb= sp;           =20 GET    GETNEXT    SET
> >  =20 = AuthPriv           = ; =20 772     596       = 304=20
> >  =20 AuthNoPriv           = 860     661       = 355=20
> >  =20 SNMPv1/2c          =20 1461    1018       = 420=20
> >
> > =
> > --
> > Wes = Hardaker=20
> > Network Associates Laboratories =
> > = _______________________________________________=20
> > midcom mailing list
>=20 > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom =
> >
> =
>
_______________________________________________ =
midcom mailing list
midcom@ietf.org=20
https://www1.ietf.org/mailman/listinfo/midcom =

------_=_NextPart_001_01C2A08C.51860F90-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 15:55:21 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 PAA20724 for ; Tue, 10 Dec 2002 15:55:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAKvqp27501 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 15:57:52 -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 gBAKvCv27474; Tue, 10 Dec 2002 15:57: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 gBAKutv27447 for ; Tue, 10 Dec 2002 15:56:55 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20691 for ; Tue, 10 Dec 2002 15:53:54 -0500 (EST) Received: from [64.100.160.211] by halt-in.cisco.com (171.70.144.185) with ESMTP; 10 Dec 2002 12:57:22 +0000 Message-ID: <3DF6550F.60400@cisco.com> Date: Tue, 10 Dec 2002 12:56:47 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: midcom@ietf.org References: <6D745637A7E0F94DA070743C55CDA9BA4892AC@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA4892AC@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: key distribution 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 A charter requirement is that we be able to handle the case where the end device can use MIDCOM. In order to do that realistically you will need an authentication infrastructure. If it's not listed in the RFC it is a mistake. I do not wish to rathole into whether SNMP's security model is sufficient for network management. My opinion is well known. However, the operating model and assumptions for network management protocols and user level access mechanisms is very different. On the one hand, one may well want a mechanism that cannot fail if other network services fail. On the other hand, we don't have that sort of operational environment here, and in fact, the architectural view we have allows for some sort of policy server for network services. ON ITS OWN SNMP fails currently to address the case where you need to authenticate large numbers of current users one finds at an enterprise or university, because the key distribution mechanism provided is orthagonal to what is used today for user authentication of network services. What does that today? Radius. The IETF presumably leans towards Diameter in the future. The same problems persist with either. Eliot ps; could you send a documentation pointer to Kerberos integration w/SNMP? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 17:13: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 RAA22750 for ; Tue, 10 Dec 2002 17:13:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAMG7E32480 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 17:16: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 gBAMCQv32326; Tue, 10 Dec 2002 17:12:26 -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 gBAMBgv32305 for ; Tue, 10 Dec 2002 17:11:42 -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 RAA22653 for ; Tue, 10 Dec 2002 17:08:40 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBAMBSFp005014; Tue, 10 Dec 2002 14:11:28 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK75920; Tue, 10 Dec 2002 14:08:22 -0800 (PST) Date: Tue, 10 Dec 2002 14:11:51 -0800 Subject: Re: [midcom] key distribution Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Eliot Lear" , To: "Harrington, David" From: Rohan Mahy In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA4892AC@NHROCMBX1.ets.enterasys.com> Message-Id: <6214A398-0C8C-11D7-8C59-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) 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 David, I believe that at least some rudimentary key management is necessary for MIDCOM. I agree that key management is not needed generically for SNMP, but if used as a MIDCOM protocol I think it becomes a requirement. I suspect this wasn't written down because most folks were envisioning using one or more other protocols where some type of key management is implied with the security mechanisms suggested for those protocols. thanks, -rohan On Tuesday, December 10, 2002, at 12:33 PM, Harrington, David wrote: > Hi Eliot, > > I certainly concur that distributed integrated key distribution would > be a nice thing for SNMPv3. Some proposals to use Diffie-Hellman key > distribution for SNMPv3 have been published and implemented, but I do > not consider them part of this evaluation. Some proposals to use > Kerberos key distribution for SNMPv3 have been published and > implemented, but I do not consider them part of this evaluation. I > have had discussions about developing a security model for SNMPv3 that > uses third-party authentication and authorization, but that also is > not part of this evaluation. > > I searched RFCs 3303 and 3304 and the semantics draft and found no > discussion of key distribution as a requirement. While key > distribution is not part of this evaluation, I think it is a valid > concern. Melinda will need to determine whether discussion in this > forum is appropriate, or merely a distracting rathole. > > When it comes to security and network management, I paid a great deal > of attention to the Security Area's meeting in Salt Lake City where > they discussed the Security Requirements for Network Management > protocols. In that meeting, they identified a number of requirements - > message authentication, message encryption, message > integrity-checking, data access-control (there might have been a > fifth; I haven't found the minutes of that meeting) - and two elements > that they considered were explicitly NOT requirements because they > could be handled outside the protocol - data privacy policies and key > distribution. In fact, they found that SNMPv3 met all the identified > requirements, and there was discussion during that meeting, involving > Jeff Schiller as a matter of fact, about the desirability of being > able to distribute the keys using ASCII configuration scripts. > > So I question, based on this guidance from the Security Area, whether > it needs to be integrated into the protocol. Any key distribution > mechanism, Kerberos or ASCII scripts or Expect or XML, should be able > to be used to distribute keys. Key distribution is not integrated into > SNMPv3, except through the use of SNMPv3, by design. > > You mentioned that the SNMPv3 security model is novel. That's probably > true; it is designed to meet certain requirements that most protocols > do not need to meet. Most notably, the security was designed to > operate standard-alone, in possibly broken networks, so security was > assured even when external authentication/authorization servers could > not be reached. > > dbh > > > >> -----Original Message----- >> From: Eliot Lear [mailto:lear@cisco.com] >> Sent: Tuesday, December 10, 2002 2:06 PM >> To: Harrington, David >> Cc: midcom@ietf.org >> Subject: Re: [midcom] Protocol decision reminder >> >> >> Harrington, David wrote: >>> Hi Eliot, >>> >>> Is this in response to something I said? >> >> Generic comment about SNMP. Melinda asked for comments. I'm >> not sure >> SNMP meets MIDCOM requirements in their entirety. Is it >> close enough? >> That's an interesting question... >> >> Eliot >> >> > _______________________________________________ > 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 Dec 10 17:32: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 RAA23228 for ; Tue, 10 Dec 2002 17:32:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAMYcO00741 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 17:34: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 gBAMUBv00603; Tue, 10 Dec 2002 17:30:11 -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 gBAMT7v00565 for ; Tue, 10 Dec 2002 17:29:07 -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 RAA23091 for ; Tue, 10 Dec 2002 17:26:06 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBAMSMjS025550; Tue, 10 Dec 2002 14:28:22 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF40704; Tue, 10 Dec 2002 14:28:43 -0800 (PST) Message-Id: <200212102228.ABF40704@mira-sjc5-c.cisco.com> To: Rohan Mahy cc: "Harrington, David" , "Eliot Lear" , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] key distribution In-Reply-To: Message from Rohan Mahy of "Tue, 10 Dec 2002 14:11:51 PST." <6214A398-0C8C-11D7-8C59-0003938AF740@cisco.com> Date: Tue, 10 Dec 2002 17:28:43 -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 think people need to be clearer about whether or not they think this is a show-stopper and why. Taking off my chair hat for a moment, I don't think it is - there *is* a mechanism for carrying keying material and a detailed description of the security mechanisms used by the protocol. Where the keys come from is outside the scope of the existing documents. The use of Kerberos or Radius could be described in a midcom document if the protocol is otherwise suitable. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 17:40: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 RAA23477 for ; Tue, 10 Dec 2002 17:40:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAMhB301812 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 17:43:11 -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 gBAMZ4v00774; Tue, 10 Dec 2002 17:35: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 gBAMY9v00728 for ; Tue, 10 Dec 2002 17:34:09 -0500 Received: from smtp011.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23220 for ; Tue, 10 Dec 2002 17:31:08 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Dec 2002 22:34:01 -0000 Reply-To: From: "Pyda Srisuresh" To: "Eliot Lear" , "Harrington, David" Cc: Subject: RE: [midcom] Re: key distribution Date: Tue, 10 Dec 2002 14:37:58 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3DF6550F.60400@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 Eliot, RFC 3303 does state explicitly that MIDCOM agent may reside on proxy servers, endhosts and application gateways. Yes, you are right about the requirement to run MIDCOM agents from end stations. Registration and authentication of MIDCOM agents is also a requirement. But, that does not meant the MIDCOM protocol has to be akin to an authentication protocol such as RADIUS or DIAMETER. You say, SNMP fails to address the case where you need to authenticate large numbers of current users. I don't see why authentication of large number of SNMP sessions from end users would be a problem on a middlebox. A Middlebox may very well choose RADIUS or DIAMETER to perform its authentication. Key distribution is orthogonal to the authentication process itself. Am I missing something Here? Cheers, suresh -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Eliot Lear Sent: Tuesday, December 10, 2002 12:57 PM To: Harrington, David Cc: midcom@ietf.org Subject: [midcom] Re: key distribution A charter requirement is that we be able to handle the case where the end device can use MIDCOM. In order to do that realistically you will need an authentication infrastructure. If it's not listed in the RFC it is a mistake. I do not wish to rathole into whether SNMP's security model is sufficient for network management. My opinion is well known. However, the operating model and assumptions for network management protocols and user level access mechanisms is very different. On the one hand, one may well want a mechanism that cannot fail if other network services fail. On the other hand, we don't have that sort of operational environment here, and in fact, the architectural view we have allows for some sort of policy server for network services. ON ITS OWN SNMP fails currently to address the case where you need to authenticate large numbers of current users one finds at an enterprise or university, because the key distribution mechanism provided is orthagonal to what is used today for user authentication of network services. What does that today? Radius. The IETF presumably leans towards Diameter in the future. The same problems persist with either. Eliot ps; could you send a documentation pointer to Kerberos integration w/SNMP? _______________________________________________ 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 Dec 10 17:49: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 RAA23723 for ; Tue, 10 Dec 2002 17:49:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAMpZq02196 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 17:51:35 -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 gBAMlqv02031; Tue, 10 Dec 2002 17:47:52 -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 gBAMimv01906 for ; Tue, 10 Dec 2002 17:44:48 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23538 for ; Tue, 10 Dec 2002 17:41:48 -0500 (EST) Received: from cisco.com (64.100.160.211) by halt-in.cisco.com with ESMTP; 10 Dec 2002 14:44:40 +0000 Message-Id: <1qcd67$j2i3@halt-in.cisco.com> Message-ID: <3DF66E58.2000009@cisco.com> Date: Tue, 10 Dec 2002 14:44:40 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: srisuresh@yahoo.com CC: "Harrington, David" , midcom@ietf.org Subject: Re: [midcom] Re: key distribution References: In-Reply-To: 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, Pyda Srisuresh wrote: > [snip] > Registration and authentication of MIDCOM agents is also a requirement. But, > that > does not meant the MIDCOM protocol has to be akin to an authentication > protocol > such as RADIUS or DIAMETER. And I entirely agree. I would say that the MIDCOM protocol should easily integrate with such mechanisms just as you described. My point is that SNMPv3 has NOT been demonstrated to do this, nor was the current USM engineered with this use in mind. Furthermore, the key localization mechanism in USM may well be defeated by use of Diameter and Radius. We could really do with a security person to comment more. I am not sure it's a showstopper, but we ought to consider it. Eliot _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 17:59:21 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 RAA24061 for ; Tue, 10 Dec 2002 17:59:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAN1pr02742 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 18:01:51 -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 gBAN1Gv02674; Tue, 10 Dec 2002 18:01: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 gBAMwYv02342 for ; Tue, 10 Dec 2002 17:58:34 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23895 for ; Tue, 10 Dec 2002 17:55:32 -0500 (EST) Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-7.07) id A192A8E027E; Tue, 10 Dec 2002 17:58:26 -0500 Message-ID: <007a01c2a09f$9d3ab5f0$2300000a@BPenfield> From: "Bob Penfield" To: "Harrington, David" , References: <6D745637A7E0F94DA070743C55CDA9BA4892AD@NHROCMBX1.ets.enterasys.com> Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Tue, 10 Dec 2002 17:58:11 -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.2720.3000 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 Assume a VOIP application using a middlebox handling a 1-Gigabit link. If you filled that link with G729-codec (8kbs/20ms samples) VOIP calls, you'd have 41,600 calls (using a bandwidth calculator I found on the web). If you assume a 3-minute call length, a continuously full 1-gigabit link would have a call rate of about 230 calls per second. At minimum, each call requires 2 transactions (open pinhole & close pinhole). That's 460 transactions per second. If it is a NAT box, and we might need to add a "reserve binding transaction", that's 690 transactions per second. If you had two 1-gigabit links, that's 1380 transactions per second. Hope that helps. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Harrington, David" To: Sent: Tuesday, December 10, 2002 3:40 PM Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Hi Cedric, I agree that the numbers don't say much without knowing what you're measuring and what you're comparing to. Are there specific requirements about the number of transactions per minute that must be met to qualify? I didn't see any in the requirements documents. Eric raised the issue the other day, saying that the requireent was for a number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that SNMPv3 would have a problem. I fear that this is an unnecessary rathole. There are no identified minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show that SNMPv3 throughput has not been found to be a problem in other environments. dbh -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Tuesday, December 10, 2002 2:40 PM To: Harrington, David; Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? In order to comment on these performance figures we need to understand if in order to install a policy rule we need more than a pair of messages (set and set response), I don't know if we got closure on the command aggregation or not without any proprietary hacks (sorry got lost in all the threads). The figures could be more representative if we could use the NAT MIB and see how the figures are affected. Is it possible to get the figures on the MIDCOM agent side (SNMP manager)? The next step is to see how to match this to real application sessions per sec that people expect this protocol to deliver on their boxes. We might get some agreement on the expected performance by saying that 6 or 8 pairs of MIDCOM messages (a pair is made of a request and reply) are required (between policy rule installation and policy rule deletion), in an average hold time of 1 min (let's say this is the worst case) this takes us to 16 MIDCOM messages (SNMP messages? ref to my note above) per mins for every application session (VoIP session, RTSP etc ...). After that, everyone can see if SNMPv3 meets their performance expectation (obviously without doing any implementation hacks, we're talking of a standard SNMPv3 stack). Thanks Cedric -----Original Message----- From: Harrington, David [ mailto:dbh@enterasys.com] Sent: 10 December 2002 20:04 To: Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Wes posted yesterday stating that it was messages per second. dbh > -----Original Message----- > From: Bob Penfield [ mailto:bpenfield@acmepacket.com] > Sent: Tuesday, December 10, 2002 1:30 PM > To: Harrington, David; midcom@ietf.org > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > Are those numbers transactions per second? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Harrington, David" > > -----Original Message----- > > From: Wes Hardaker [ mailto:hardaker@tislabs.com] > > > > Just for kicks, I ran 10000 requests of various kinds against the > > Net-SNMP stack (which is not a well optimized stack compared to > > the commercial vendors) and timed the results. This was on > a 233 PIII > > laptop which was not idle by any means, so take the numbers with a > > grain of salt. MD5 and DES were used for auth and priv. > > > > sysContact.0 in the Master agent: > > > > GET GETNEXT SET > > AuthPriv 1277 1176 493 > > AuthNoPriv 1462 1475 514 > > SNMPv1/2c 3769 3467 675 > > > > sysContact.0 in a subagent: > > > > GET GETNEXT SET > > AuthPriv 772 596 304 > > AuthNoPriv 860 661 355 > > SNMPv1/2c 1461 1018 420 > > > > > > -- > > Wes Hardaker > > Network Associates Laboratories > > _______________________________________________ > > 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 Dec 10 18:32: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 SAA24844 for ; Tue, 10 Dec 2002 18:32:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBANZ1g04731 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 18:35: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 gBANVCv04590; Tue, 10 Dec 2002 18:31: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 gBANUZv04551 for ; Tue, 10 Dec 2002 18:30:35 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24758 for ; Tue, 10 Dec 2002 18:27:33 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id SAA12008 for ; Tue, 10 Dec 2002 18:42:38 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma012004; Tue, 10 Dec 02 18:41:50 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 10 Dec 2002 18:29:58 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 18:29:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] key distribution Date: Tue, 10 Dec 2002 18:29:57 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892B0@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] key distribution Thread-Index: AcKgmSn4K8JtpI96SkqUgRMQ6JrGJwAARHQg From: "Harrington, David" To: X-OriginalArrivalTime: 10 Dec 2002 23:29:58.0080 (UTC) FILETIME=[0D775400:01C2A0A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBANUZv04552 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 Hi, Let me make sure everybody understands what is available for key management in SNMPv3, and where problems might arise. SNMPv3 provides standardized mechanisms for a user to change their own keys, and standardized mechanisms for administartors to change large numbers of users' keys, by making mibs available through which one can do these things. Obviously, with large numbers of keys, using a program to automate the process would be desirable. SNMPv3 does not provide a standardized mechanism for creating the initial keys for a "root" user. Once a root user has been established, all subsequent key updates and key distribution can be done using SNMP applications. RFC2786 defines a Diffie-Hellman mechanism for establishing "root" user keys. It is not part of the SNMPv3 standard. It is part of the DOCSIS standard and has been used successfully in the cable modem industry, according to the reports I've received as WG co-chair. Since RFC2786 is not part of the standard, I do not consider that part of this evaluation. As an alternative, implementors are free to use other key distribution mechanisms, such as Kerberos or ASCII scripts, and the underlying instrumentation in the SNMP-agent-hosting-device can automatically add support for various users to the SNMP MIBs that maintain the lists of users and their keys. This process can be automated, but it is not part of the SNMPv3 standard. To simplify key distribution, many vendors are authenticating the "applications" that send messages rather than the users using the applications. Many applications require a user to login to the application, possibly with a RADIUS tie-in, and then the application (say, HPOV's Node Manager) authenticates itself to the managed entity and performs SNMP transactions for the user. The USM model does not place any requirements on the granularity of the things called "users"; they do not need to be humans. The MIDCOM requirements do not seem to require that the authentication be directly manipulated in real-time by a human. It appears to me that the MIDCOM agent is an application that can be triggered by events other than user login, such as getting a communication from a SIP proxy. In this case, I do not think the authentication between the agent and middlebox is authenticating the human user, but rather the agent (application) identity and the middlebox identity. I see these as being likely to use preconfigured shared secrets. Eliot's point about SNMPv3 security being orthogonal to RADIUS security is absolutely on the money. RADIUS largely follows the challenge and response model of user authentication. Because SNMP has no concept of session, authentication is done on every message. That means there is no login screen with human real-time challenge and response (we'd certainly very quickly tire of logging in every time we send a message). In the standard SNMPv3 model, the agent and middlebox will need to have pre-configured shared secrets for every security principal (human user or application) that sends a message that needs to be authenticated. SNMPv3 is designed to be extensible, to be able to use different security models besides the standard USM security model. Any such extensions are not included in this evaluation. Adding another security model that uses shared keys would not be terribly difficult to do. Adding a security model that depends on third-party authentication could be done with more work. ***BUT***, adding a security model that depends on third party authentication, using a challenge and response algorithm will not work easily in the session-less environment of SNMPv3. I have had a number of discussions with SNMP experts about adding RADIUS support to SNMPv3, and there are major difficulties in doing so. If pre-configuration and updates of shared keys is acceptable to the MIDCOM design, then out-of-band key distribution should be fine with SNMPv3. If compatibility with human real-time challenge-and-response login is important to the MIDCOM design, then Diameter is a WAY WAY better choice than SNMPv3. dbh > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Tuesday, December 10, 2002 5:12 PM > To: Harrington, David > Cc: Eliot Lear; midcom@ietf.org > Subject: Re: [midcom] key distribution > > > Hi David, > > I believe that at least some rudimentary key management is necessary > for MIDCOM. I agree that key management is not needed > generically for > SNMP, but if used as a MIDCOM protocol I think it becomes a > requirement. I suspect this wasn't written down because most folks > were envisioning using one or more other protocols where some type of > key management is implied with the security mechanisms suggested for > those protocols. > > thanks, > -rohan > > > On Tuesday, December 10, 2002, at 12:33 PM, Harrington, David wrote: > > Hi Eliot, > > > > I certainly concur that distributed integrated key > distribution would > > be a nice thing for SNMPv3. Some proposals to use > Diffie-Hellman key > > distribution for SNMPv3 have been published and > implemented, but I do > > not consider them part of this evaluation. Some proposals to use > > Kerberos key distribution for SNMPv3 have been published and > > implemented, but I do not consider them part of this evaluation. I > > have had discussions about developing a security model for > SNMPv3 that > > uses third-party authentication and authorization, but that also is > > not part of this evaluation. > > > > I searched RFCs 3303 and 3304 and the semantics draft and found no > > discussion of key distribution as a requirement. While key > > distribution is not part of this evaluation, I think it is a valid > > concern. Melinda will need to determine whether discussion in this > > forum is appropriate, or merely a distracting rathole. > > > > When it comes to security and network management, I paid a > great deal > > of attention to the Security Area's meeting in Salt Lake City where > > they discussed the Security Requirements for Network Management > > protocols. In that meeting, they identified a number of > requirements - > > message authentication, message encryption, message > > integrity-checking, data access-control (there might have been a > > fifth; I haven't found the minutes of that meeting) - and > two elements > > that they considered were explicitly NOT requirements because they > > could be handled outside the protocol - data privacy > policies and key > > distribution. In fact, they found that SNMPv3 met all the > identified > > requirements, and there was discussion during that meeting, > involving > > Jeff Schiller as a matter of fact, about the desirability of being > > able to distribute the keys using ASCII configuration scripts. > > > > So I question, based on this guidance from the Security > Area, whether > > it needs to be integrated into the protocol. Any key distribution > > mechanism, Kerberos or ASCII scripts or Expect or XML, > should be able > > to be used to distribute keys. Key distribution is not > integrated into > > SNMPv3, except through the use of SNMPv3, by design. > > > > You mentioned that the SNMPv3 security model is novel. > That's probably > > true; it is designed to meet certain requirements that most > protocols > > do not need to meet. Most notably, the security was designed to > > operate standard-alone, in possibly broken networks, so > security was > > assured even when external authentication/authorization > servers could > > not be reached. > > > > dbh > > > > > > > >> -----Original Message----- > >> From: Eliot Lear [mailto:lear@cisco.com] > >> Sent: Tuesday, December 10, 2002 2:06 PM > >> To: Harrington, David > >> Cc: midcom@ietf.org > >> Subject: Re: [midcom] Protocol decision reminder > >> > >> > >> Harrington, David wrote: > >>> Hi Eliot, > >>> > >>> Is this in response to something I said? > >> > >> Generic comment about SNMP. Melinda asked for comments. I'm > >> not sure > >> SNMP meets MIDCOM requirements in their entirety. Is it > >> close enough? > >> That's an interesting question... > >> > >> Eliot > >> > >> > > _______________________________________________ > > 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 Dec 10 18:50: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 SAA25167 for ; Tue, 10 Dec 2002 18:50:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBANqgQ05920 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 18:52:42 -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 gBANn5v05834; Tue, 10 Dec 2002 18:49:05 -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 gBANmwv05820 for ; Tue, 10 Dec 2002 18:48:58 -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 SAA25110 for ; Tue, 10 Dec 2002 18:45:55 -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 gBANmeF05886; Wed, 11 Dec 2002 00:48:40 +0100 (CET) (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 7A6027DB50; Wed, 11 Dec 2002 00:46:18 +0100 (CET) Date: Wed, 11 Dec 2002 00:46:16 +0100 From: Juergen Quittek To: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder Message-ID: <16189629.1039567575@[192.168.102.32]> In-Reply-To: <200212101332.ABF08081@mira-sjc5-c.cisco.com> References: <200212101332.ABF08081@mira-sjc5-c.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 Looks like a busy day on the mailing list. Let's try to summarize the issues. So far, three arguments have been raised: 1. SNMPv3 might not match the semantics (that are under development 2. SNMPv3 performance migth be insufficient 3. SNMPv3 might interoperate well with key distribution infrastructures On 1: David checked the semantics and says it is implementable with SNMP although SNMP is not a perfect match. I think the reason is, that when chose a transaction model for defining the semantics we did customize it for SNMP (but had SNMP as one option in mind). Maybe we should adapt the model slightly in case the WG chooses SNMP. I don't think, this would be a big problem, but it might not be necessary at all. On 2: This is an interesting issue to investigate. There is no requirement on performance yet. Our first step could be specifying this requirement. However, the requirement discussion was closed some time before. Do we really want to open it again? On 3: Since Melinda explicitly asks for arguments why SNMPv3 does not meet the requirements: the user-based security model defined in RFC 2574 is explicitly defined to be open to other security mechanisms as the few ones described in the RFC. Can anyone explain, why this does not hold for one or the other particular key distribution infrastructure? Juergen -- Melinda Shore wrote on 10 December 2002 08:32 -0500: > I'd like to remind everyone that we're now in the process of > going through the protocols, as ranked in the protocol > evaluation document, and determining one-by-one their > suitability for use as the midcom protocol. > > If someone cannot come up with a technical argument for why > SNMPv3 does not meet the midcom requirements and framework > it will become the midcom protocol. If there are no such > comments by the end of the week, SNMPv3 will become the > midcom protocol. > > 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 Tue Dec 10 19:02:27 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 TAA25469 for ; Tue, 10 Dec 2002 19:02:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB04vX06304 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 19:04:57 -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 gBB047v06259; Tue, 10 Dec 2002 19:04: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 gBB040v06237 for ; Tue, 10 Dec 2002 19:04:00 -0500 Received: from smtp017.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25409 for ; Tue, 10 Dec 2002 19:00:56 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Dec 2002 00:03:49 -0000 Reply-To: From: "Pyda Srisuresh" To: , "Harrington, David" , Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Tue, 10 Dec 2002 16:07:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1D56_01C2A066.4757A5F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: 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_1D56_01C2A066.4757A5F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Resending… -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] Sent: Tuesday, December 10, 2002 3:04 PM To: Harrington, David; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? You are right. There is no minimum requirement on min. no. of transactions per se. However, it is clear that the protocol should have no inherent issues with scaling. Couple of questions. 1. I believe, security is the main distinction between v2 and v3 of SNMP. SNMPv3 is being suggested as the MIDCOM protocol because of it security suit. I believe, the trust level and the ensuing rev of SNMP should be the left to the choice of the customers/enterprises that house the middlebox, even as IETF recommends SNMPv3 as the preferred protocol choice. 2. Let us say, SNMP is chosen as the MIDCOM protocol of choice. Several host stations acting as MIDCOM agents could simultaneously be running as SNMP server applications, right. Are there any scaling issues with the middlebox interfacing with multiple SNMP servers simultaneously. How will the traps work in the multi-server scenario? Thanks. Cheers, suresh -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Harrington, David Sent: Tuesday, December 10, 2002 12:40 PM To: midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Hi Cedric, I agree that the numbers don't say much without knowing what you're measuring and what you're comparing to. Are there specific requirements about the number of transactions per minute that must be met to qualify? I didn't see any in the requirements documents. Eric raised the issue the other day, saying that the requireent was for a number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that SNMPv3 would have a problem. I fear that this is an unnecessary rathole. There are no identified minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show that SNMPv3 throughput has not been found to be a problem in other environments. dbh ------=_NextPart_000_1D56_01C2A066.4757A5F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

Resending…

 

-----Original Message-----
From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
Sent: Tuesday, December = 10, 2002 3:04 PM
To: Harrington, David; midcom@ietf.org
Subject: RE: [midcom] = SNMPv3 as MIDCOM protocol: Opinions?

 

You are right. There is no minimum requirement = on min. no. of transactions per se.

However, it is clear that the protocol should = have no inherent issues with scaling.

 

Couple of questions. =

 

1.       = I believe, security = is the main distinction between v2 and v3 of = SNMP.

SNMPv3 is being suggested as the MIDCOM = protocol because of it security suit.

 

I believe, the trust level and the ensuing rev = of SNMP should be the left to the

choice of the customers/enterprises that house = the middlebox, even as IETF

recommends SNMPv3 as the preferred protocol = choice.

 

2.       = Let us say, SNMP is = chosen as the MIDCOM protocol of choice.

Several host = stations acting as MIDCOM agents could simultaneously be =

running as SNMP = server applications, right.

 

Are there any = scaling issues with the middlebox interfacing with multiple =

SNMP servers simultaneously. How will the traps work in the multi-server scenario? =

 

Thanks.

 

Cheers,

suresh

 

 

 

 

-----Original Message-----
From: = midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On = Behalf Of Harrington, David
Sent: Tuesday, December = 10, 2002 12:40 PM
To: midcom@ietf.org
Subject: RE: [midcom] = SNMPv3 as MIDCOM protocol: Opinions?<= /p>

 <= /p>

Hi Cedric,

 <= /p>

I agree that the numbers don't say much without knowing what you're measuring = and what you're comparing to.

 <= /p>

Are there specific requirements about the number of transactions per minute = that must be met to qualify? I didn't see any in the requirements documents. = Eric raised the issue the other day, saying that the requireent was for a = number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that = SNMPv3 would have a problem.

 <= /p>

I fear that this is an unnecessary rathole. There are no identified = minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show = that SNMPv3 throughput has not been found to be a problem in other = environments.<= /p>

 <= /p>

dbh= <= /p>

  <= /p>

------=_NextPart_000_1D56_01C2A066.4757A5F0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 10 19:51: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 TAA26233 for ; Tue, 10 Dec 2002 19:51:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB0s4708956 for midcom-archive@odin.ietf.org; Tue, 10 Dec 2002 19:54:04 -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 gBB0rUv08924; Tue, 10 Dec 2002 19:53:30 -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 gBB0qIv08877 for ; Tue, 10 Dec 2002 19:52:18 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26217 for ; Tue, 10 Dec 2002 19:49:16 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id UAA14643 for ; Tue, 10 Dec 2002 20:04:19 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma014637; Tue, 10 Dec 02 20:03:34 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Tue, 10 Dec 2002 19:51:43 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Dec 2002 19:51:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Tue, 10 Dec 2002 19:51:42 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892B1@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKgqNpLg1kskHgaSdCdAxOO9w6fVAAAZRRw From: "Harrington, David" To: X-OriginalArrivalTime: 11 Dec 2002 00:51:43.0205 (UTC) FILETIME=[79260150:01C2A0AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBB0qIv08878 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 Hi, Comments inline (then I really need to do some $$$ work). -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] Sent: Tuesday, December 10, 2002 3:04 PM To: Harrington, David; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? You are right. There is no minimum requirement on min. no. of transactions per se. However, it is clear that the protocol should have no inherent issues with scaling. Couple of questions. 1. I believe, security is the main distinction between v2 and v3 of SNMP. SNMPv3 is being suggested as the MIDCOM protocol because of it security suit. I believe, the trust level and the ensuing rev of SNMP should be the left to the choice of the customers/enterprises that house the middlebox, even as IETF recommends SNMPv3 as the preferred protocol choice. dbh> The MIDCOM requirements call for security. SNMPv1 and SNMPv2c do not have security, therefore they would not meet the requirements. dbh> Could SNMP be secured in other ways? Possibly, but I wouldn't recommend it because the security would not be integrated with the data model, and could not provide access control for specific portions of the MIB. In MIDCOM, I beleive it is important that one agent be able to manage, say, the firewall functionality in the middlebox, while another agent is responsible for, say, the IDS functionality. You can do this division of labor using SNMPv3's VACM functionality. In SNMPv1 and SNMPv2c, you could implement the VACM MIB modules, but you lose the binding between the robustly-authenticated "user" and which types of functionality they have access to. 2. Let us say, SNMP is chosen as the MIDCOM protocol of choice. Several host stations acting as MIDCOM agents could simultaneously be running as SNMP server applications, right. Are there any scaling issues with the middlebox interfacing with multiple SNMP servers simultaneously? dbh> At some point, an implementation may encounter scaling problems. It depends primarily on the implementation. dbh> for background to my next point, let me explain SNMP typical functioning. SNMPv3 defines both ends as being entities, with basically the same types of potential functionality - processing requests or processing responses or processing traps. In SNMP, the request and the response typically carry the same PDU. In a GET request, an SNMP agent (the middlebox) would need to take the list, look up the attributes in its (virtual) database, and plug the data into the response message. Typically the managemetn application (the agent) will take the data from the response message, look up the attribute in its (virtual) database, and record the values it received. Roughly comparable work to process the data. dbh> I have worked with management applications that could regularly poll 10's of 1000's of devices. It was designed using a multi-tasking design, and some work went into ensuring it could meet scalability requirements. I have also worked with SNMP agents (what would here be the middlebox) that would lock up if it had more than 20 requests to process. Scalability has to do with implementation decisions. SNMPv3 was explicitly designed to support full-function management applications and minimal footprint small appliances. Implementations must be designed to match the environment in which they will operate. dbh> I do not believe that SNMPv3 has any scalability issues inherent in the protocol design. Given implementations that are deployed in their target environments, I believe that well-designed implementations will perform well, and poorly designed implementations will perform poorly. To answer the question any better than this will require that we define minimum requirements, apply them to all the candidate protocols, and test them so we have real data to compare. Personally, I have real job and my bosses want me to earn my pay, and doing this type of development so we can experiment is more than I wish to commit to. How will the traps work in the multi-server scenario? dbh> SNMPv3 trap management can support multiple manager applications, and you can configure the system to deliver certain types of traps to one manager, and another type to a different manager. Thanks. Cheers, suresh -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Harrington, David Sent: Tuesday, December 10, 2002 12:40 PM To: midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Hi Cedric, I agree that the numbers don't say much without knowing what you're measuring and what you're comparing to. Are there specific requirements about the number of transactions per minute that must be met to qualify? I didn't see any in the requirements documents. Eric raised the issue the other day, saying that the requireent was for a number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that SNMPv3 would have a problem. I fear that this is an unnecessary rathole. There are no identified minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show that SNMPv3 throughput has not been found to be a problem in other environments. dbh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Dec 11 03:44: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 DAA28924 for ; Wed, 11 Dec 2002 03:44:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB8lAR10775 for midcom-archive@odin.ietf.org; Wed, 11 Dec 2002 03:47:10 -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 gBB8hQv10684; Wed, 11 Dec 2002 03:43:26 -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 gBB8gmv10645 for ; Wed, 11 Dec 2002 03:42:48 -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 DAA28798 for ; Wed, 11 Dec 2002 03:39:41 -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 gBB8gRF14123; Wed, 11 Dec 2002 09:42:27 +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 A50AF7DCAD; Wed, 11 Dec 2002 09:40:03 +0100 (CET) Date: Wed, 11 Dec 2002 09:54:25 +0100 From: Juergen Quittek To: "Harrington, David" , midcom@ietf.org Subject: direction of SNMP traps (was: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?) Message-ID: <1668629.1039600465@[192.168.102.164]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA4892B1@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA4892B1@NHROCMBX1.ets.enterasys.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 David, Does SNMP allow to dynamically direct traps based on table indices or values of managed objects? Or more concretely, would the following be a valid MIB design? One kind of transactions used in the semantics doc is an asynchronous notification from middlebox to midcom agent. Particularly, the notification (for example on expiration of a policy rule) is sent to one or more agents that configured it and not to midcom agents unrelated to the policy rule. I assume that a policy rule is modeled by a row of a table, indexed by the owner (or creator) of the row (and some further index components). Is there a way to have a notification on policy rule timeout sent to (just) the owner of the row? Certainly, you can just specify this in the SMI description of the notification, but would existing standard compliant SNMP agent toolkits support this (with some extra code provided by the MIB implementor)? The address and other required information on the owner might be stored in a separate table. Juergen -- Harrington, David wrote on 10 December 2002 19:51 -0500: > How will the traps work in the multi-server scenario? > > dbh> SNMPv3 trap management can support multiple manager applications, and you can configure the system to deliver certain types of traps to one manager, and another type to a different manager. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Dec 11 07:51: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 HAA02901 for ; Wed, 11 Dec 2002 07:51:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBCrmu24561 for midcom-archive@odin.ietf.org; Wed, 11 Dec 2002 07:53:48 -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 gBBCrGv24548; Wed, 11 Dec 2002 07:53: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 gBB4wTv21467 for ; Tue, 10 Dec 2002 23:58:29 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01618 for ; Tue, 10 Dec 2002 23:55:25 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gBB4wILL020472 for ; Tue, 10 Dec 2002 21:58:18 -0700 (MST) Received: [from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id VAA20959 for ; Tue, 10 Dec 2002 21:58:17 -0700 (MST)] Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 10:28:15 +0530 Message-ID: <653138C25D8AD6118292000347080A3701DB7D64@zin05exm02.corp.mot.com> From: Aradhya Rohit V-A15094 To: Melinda Shore , Eliot Lear Cc: "Harrington, David" , midcom@ietf.org Subject: RE: [midcom] Protocol decision reminder Date: Wed, 11 Dec 2002 10:28:14 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain 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: , Melinda, I agree with you and "where the keys come from" is out of scope for SNMP, For key management entity KERBEROS with PKI will be a ideal candidate. Its already proven and deployed with SNMPV3 in packet cable world. -Rohit -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, December 11, 2002 1:13 AM To: Eliot Lear Cc: Harrington, David; midcom@ietf.org Subject: Re: [midcom] Protocol decision reminder > SNMP version 3's security model, while novel, does not provide for > distributed *integrated* key/certificate management. There is no > equivalent of Kerberos for SNMP users. Scalable authorization of > requests is required. Could you go into more detail about what the issue is here? Although there's an appendix describing how to convert passwords into keys, RFC 2264 doesn't describe where the keys come from and certainly doesn't preclude the use of an external key management system. The limitation is that it doesn't provide a mechanism for the engines to tell each other what keying system they're using. But as the document is currently written I believe that I could use Kerberos without changing anything. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ---------------------------------------------------------------------------------------- Rohit Aradhya, Motorola Bangalore, India Ph - + 91 (080) 5598615 X - 4005 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Dec 11 07:55: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 HAA02979 for ; Wed, 11 Dec 2002 07:55:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBCvV324758 for midcom-archive@odin.ietf.org; Wed, 11 Dec 2002 07:57:31 -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 gBBCs1v24588; Wed, 11 Dec 2002 07:54:01 -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 gBB5ESv22625 for ; Wed, 11 Dec 2002 00:14:28 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01920 for ; Wed, 11 Dec 2002 00:11:24 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gBB5EIbj000049 for ; Tue, 10 Dec 2002 22:14:18 -0700 (MST) Received: [from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA21995 for ; Tue, 10 Dec 2002 22:09:32 -0700 (MST)] Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Dec 2002 10:44:14 +0530 Message-ID: <653138C25D8AD6118292000347080A3701DB7DFA@zin05exm02.corp.mot.com> From: Aradhya Rohit V-A15094 To: Melinda Shore , Rohan Mahy Cc: "Harrington, David" , Eliot Lear , midcom@ietf.org Subject: RE: [midcom] key distribution Date: Wed, 11 Dec 2002 10:44:14 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain 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 6.3 of Packet cable security spec [pkt-sp-sec-I07-021127] gives an idea how Kerberos can be used for generating SNMPV3 Keys. -Rohit -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, December 11, 2002 3:59 AM To: Rohan Mahy Cc: Harrington, David; Eliot Lear; midcom@ietf.org Subject: Re: [midcom] key distribution I think people need to be clearer about whether or not they think this is a show-stopper and why. Taking off my chair hat for a moment, I don't think it is - there *is* a mechanism for carrying keying material and a detailed description of the security mechanisms used by the protocol. Where the keys come from is outside the scope of the existing documents. The use of Kerberos or Radius could be described in a midcom document if the protocol is otherwise suitable. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ---------------------------------------------------------------------------------------- Rohit Aradhya, Motorola Bangalore, India Ph - + 91 (080) 5598615 X - 4005 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 12 08:12: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 IAA21967 for ; Thu, 12 Dec 2002 08:12:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCDEbk17973 for midcom-archive@odin.ietf.org; Thu, 12 Dec 2002 08:14:37 -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 gBCD7ev17738; Thu, 12 Dec 2002 08:07:40 -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 gBCD5Dv17004 for ; Thu, 12 Dec 2002 08:05:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21634; Thu, 12 Dec 2002 08:02:16 -0500 (EST) Message-Id: <200212121302.IAA21634@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: Thu, 12 Dec 2002 08:02:15 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-04.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-04.txt Pages : 47 Date : 2002-12-11 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-04.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-04.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-04.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-12-11132828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-11132828.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 12 09:03:20 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 JAA23830 for ; Thu, 12 Dec 2002 09:03:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCE5lX20966 for midcom-archive@odin.ietf.org; Thu, 12 Dec 2002 09:05:47 -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 gBCDxCv20619; Thu, 12 Dec 2002 08:59: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 gBCDwHv20583 for ; Thu, 12 Dec 2002 08:58:17 -0500 Received: from mailscanout256k.tataelxsi.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23508 for ; Thu, 12 Dec 2002 08:55:16 -0500 (EST) Message-ID: <3DF89741.EE8408BB@tataelxsi.co.in> Date: Thu, 12 Dec 2002 19:33:45 +0530 From: "Venkatesh N" MIME-Version: 1.0 To: midcom@ietf.org CC: jdrosen@dynamicsoft.com, kuthan@fokus.fhg.de, amolitor@visi.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Query on MIDCOM Architecture and Framework 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, I have a query on MIDCOM Architecture and Framework document RFC 3303. In page 19 of this document in explaining "Timeline flow - Middlebox implementing NAPT Service" Initially the MIDCOM Agent queries the port bind for MA, 5060. >>As per my understanding this would return us the Private IP Adress and port of the SIP phone. Then in the next step MIDCOM Agent would query the NAT Session Descriptor for the flow Ea-to-Pa (External IP address to Internal Private IP Address) What does this NAT Session Descriptor is all about? What exactly is this for? Then again later on it says ++Create NAT Session | | | | descriptors for | | | | RTP1, RTCP1; Set | | | | parent session to | | | | SIP-ctrl session ++> Can any one explain this? Probably I'm not able to distinguish between a Session descriptor and port bindings that are created during NAPT operations. Could anyone please clarify my above queries? thanks in advance regards, Venkatesh N _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 12 14:15: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 OAA08015 for ; Thu, 12 Dec 2002 14:15:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCJI0009375 for midcom-archive@odin.ietf.org; Thu, 12 Dec 2002 14:18: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 gBCJEHv09247; Thu, 12 Dec 2002 14:14:17 -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 gBCJD9v09224 for ; Thu, 12 Dec 2002 14:13: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 OAA07797 for ; Thu, 12 Dec 2002 14:10:08 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBCJD3fm009260 for ; Thu, 12 Dec 2002 11:13:03 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABI24383; Thu, 12 Dec 2002 11:13:02 -0800 (PST) Message-Id: <200212121913.ABI24383@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 12 Dec 2002 14:13:02 -0500 Subject: [midcom] Where we stand/SNMPv3 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 the two concerns raised regarding using SNMPv3 as the midcom protocol are 1) lack of interface to a keying infrastructure, and 2) questions about transaction rate. The first is clearly addressable and the second, I think, remains an open question. We don't have a show-stopper. This process (working through the list in the order presented in the evaluation document) is about coming to a decision, but not coming to a consensus-based decision. It's absolutely clear that putting the three remaining protocols in front of the working group and saying "pick one" wasn't going to produce a consensus decision, either. In fact it was pretty much guaranteed to produce *no* decision. One interested observer described the process as the working group being in a death spiral, and I don't think the choice of the word "death" was accidental (more on that below). There seems to be an assumption among some working group participants that if we eliminate all of the existing protocols from contention we will be rechartered to undertake development of a protocol from scratch. That is absolutely not the case. I think it's pretty clear that if we found that none of SNMP, Diameter, and COPS were suitable the working group would be terminated rather than rechartered. We were told that eliminating them was a precondition for doing one from scratch, but we were never, ever told that if we were able to do so we would be given carte blanche to develop a new protocol. That leaves us with these questions: given that we did not arrive at SNMPv3 by consensus and given that the likely alternative is folding up our tent, is there support for going ahead and developing a midcom MIB and keying framework for SNMPv3? Is this something that would be useful and deployable? Are there people who would be interested in doing the work? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 12 14:57: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 OAA10162 for ; Thu, 12 Dec 2002 14:57:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCK0NN12269 for midcom-archive@odin.ietf.org; Thu, 12 Dec 2002 15:00:23 -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 gBCJu9v12029; Thu, 12 Dec 2002 14:56: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 gBCJtWv12000 for ; Thu, 12 Dec 2002 14:55:32 -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 OAA09956 for ; Thu, 12 Dec 2002 14:52:29 -0500 (EST) 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 gBCJtBx13425; Thu, 12 Dec 2002 14:55:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Dec 2002 14:55:12 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E027@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Where we stand/SNMPv3 Date: Thu, 12 Dec 2002 14:55:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A218.609B1A0C" 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_01C2A218.609B1A0C Content-Type: text/plain I actually figured I had to develop the MIB this week to make sure SNMP is a feasible approach. I was working on the assumption that the MIB to be developed represents the Agent's view rather than the view of the Middlebox. (i.e.) the Middlebox will have to maintain a MIB which is more extensive than what the Agent gets to see and manipulate. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, December 12, 2002 2:13 PM > To: midcom@ietf.org > Subject: [midcom] Where we stand/SNMPv3 > > > As things currently stand the two concerns raised regarding > using SNMPv3 as the midcom protocol are 1) lack of interface > to a keying infrastructure, and 2) questions about > transaction rate. The first is clearly addressable and the > second, I think, remains an open question. We don't have a > show-stopper. > > This process (working through the list in the order > presented in the evaluation document) is about coming to a > decision, but not coming to a consensus-based decision. It's > absolutely clear that putting the three remaining protocols > in front of the working group and saying "pick one" wasn't > going to produce a consensus decision, either. In fact it was > pretty much guaranteed to produce *no* decision. One > interested observer described the process as the working > group being in a death spiral, and I don't think the choice > of the word "death" was accidental (more on that below). > > There seems to be an assumption among some working group > participants that if we eliminate all of the existing > protocols from contention we will be rechartered to undertake > development of a protocol from scratch. That is absolutely > not the case. I think it's pretty clear that if we found > that none of SNMP, Diameter, and COPS were suitable the > working group would be terminated rather than rechartered. > We were told that eliminating them was a precondition for > doing one from scratch, but we were never, ever told that if > we were able to do so we would be given carte blanche to > develop a new protocol. > > That leaves us with these questions: given that we did not > arrive at SNMPv3 by consensus and given that the likely > alternative is folding up our tent, is there support for > going ahead and developing a midcom MIB and keying framework > for SNMPv3? Is this something that would be useful and > deployable? Are there people who would be interested in > doing the work? > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C2A218.609B1A0C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Where we stand/SNMPv3

I actually figured I had to develop the MIB this week = to make sure SNMP is a feasible approach.  I was working on the = assumption that the MIB to be developed represents the Agent's view = rather than the view of the Middlebox.  (i.e.) the Middlebox will = have to maintain a MIB which is more extensive than what the Agent gets = to see and manipulate.

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, December 12, 2002 2:13 = PM
> To: midcom@ietf.org
> Subject: [midcom] Where we stand/SNMPv3
>
>
> As things currently stand the two concerns = raised regarding
> using SNMPv3 as the midcom protocol are 1) lack = of interface
> to a keying infrastructure, and 2) questions = about
> transaction rate.  The first is clearly = addressable and the
> second, I think, remains an open = question.  We don't have a
> show-stopper.
>
> This process (working through the list in the = order
> presented in the evaluation document) is about = coming to a
> decision, but not coming to a consensus-based = decision. It's
> absolutely clear that putting the three = remaining protocols
> in front of the working group and saying = "pick one" wasn't
> going to produce a consensus decision, either. = In fact it was
> pretty much guaranteed to produce *no* = decision.  One
> interested observer described the process as = the working
> group being in a death spiral, and I don't = think the choice
> of the word "death" was accidental = (more on that below).
>
> There seems to be an assumption among some = working group
> participants that if we eliminate all of the = existing
> protocols from contention we will be = rechartered to undertake
> development of a protocol from scratch.  = That is absolutely
> not the case.  I think it's pretty clear = that if we found
> that none of SNMP, Diameter, and COPS were = suitable the
> working group would be terminated rather than = rechartered. 
> We were told that eliminating them was a = precondition for
> doing one from scratch, but we were never, ever = told that if
> we were able to do so we would be given carte = blanche to
> develop a new protocol.
>
> That leaves us with these questions: given that = we did not
> arrive at SNMPv3 by consensus and given that = the likely
> alternative is folding up our tent, is there = support for
> going ahead and developing a midcom MIB and = keying framework
> for SNMPv3?  Is this something that would = be useful and
> deployable?  Are there people who would be = interested in
> doing the work?
>
> Melinda
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C2A218.609B1A0C-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 12 16:23: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 QAA13399 for ; Thu, 12 Dec 2002 16:23:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCLQ8w17143 for midcom-archive@odin.ietf.org; Thu, 12 Dec 2002 16:26:08 -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 gBCLMCv17059; Thu, 12 Dec 2002 16:22: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 gBCLLqv17014 for ; Thu, 12 Dec 2002 16:21:52 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13270 for ; Thu, 12 Dec 2002 16:18:49 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id QAA07643 for ; Thu, 12 Dec 2002 16:33:55 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma007612; Thu, 12 Dec 02 16:32:58 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Thu, 12 Dec 2002 16:20:57 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 12 Dec 2002 16:20:57 -0500 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_01C2A224.5C0A5EA0" Subject: RE: [midcom] Where we stand/SNMPv3 Date: Thu, 12 Dec 2002 16:20:56 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA256F4D@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Where we stand/SNMPv3 Thread-Index: AcKiGTc01W+K9235T+O7/yQvlbzfxAACt/Wg From: "Harrington, David" To: "Tom-PT Taylor" , "Melinda Shore" , X-OriginalArrivalTime: 12 Dec 2002 21:20:57.0064 (UTC) FILETIME=[5C498680:01C2A224] 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_01C2A224.5C0A5EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I assumed that we would pick one, then take some time to design a solution with it. If it turns out that the chosen protocol doesn't work, then we eliminate it from contention and go back to the remaining candidates. =20 I doubt that we could design a well-designed solution with any candidate protocol, given only one day to do it. =20 dbh -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]=20 Sent: Thursday, December 12, 2002 2:55 PM To: 'Melinda Shore'; midcom@ietf.org Subject: RE: [midcom] Where we stand/SNMPv3 =09 =09 I actually figured I had to develop the MIB this week to make sure SNMP is a feasible approach. I was working on the assumption that the MIB to be developed represents the Agent's view rather than the view of the Middlebox. (i.e.) the Middlebox will have to maintain a MIB which is more extensive than what the Agent gets to see and manipulate. > -----Original Message-----=20 > From: Melinda Shore [mailto:mshore@cisco.com]=20 > Sent: Thursday, December 12, 2002 2:13 PM=20 > To: midcom@ietf.org=20 > Subject: [midcom] Where we stand/SNMPv3=20 >=20 >=20 > As things currently stand the two concerns raised regarding=20 > using SNMPv3 as the midcom protocol are 1) lack of interface=20 > to a keying infrastructure, and 2) questions about=20 > transaction rate. The first is clearly addressable and the=20 > second, I think, remains an open question. We don't have a=20 > show-stopper.=20 >=20 > This process (working through the list in the order=20 > presented in the evaluation document) is about coming to a=20 > decision, but not coming to a consensus-based decision. It's=20 > absolutely clear that putting the three remaining protocols=20 > in front of the working group and saying "pick one" wasn't=20 > going to produce a consensus decision, either. In fact it was=20 > pretty much guaranteed to produce *no* decision. One=20 > interested observer described the process as the working=20 > group being in a death spiral, and I don't think the choice=20 > of the word "death" was accidental (more on that below).=20 >=20 > There seems to be an assumption among some working group=20 > participants that if we eliminate all of the existing=20 > protocols from contention we will be rechartered to undertake=20 > development of a protocol from scratch. That is absolutely=20 > not the case. I think it's pretty clear that if we found=20 > that none of SNMP, Diameter, and COPS were suitable the=20 > working group would be terminated rather than rechartered. =20 > We were told that eliminating them was a precondition for=20 > doing one from scratch, but we were never, ever told that if=20 > we were able to do so we would be given carte blanche to=20 > develop a new protocol.=20 >=20 > That leaves us with these questions: given that we did not=20 > arrive at SNMPv3 by consensus and given that the likely=20 > alternative is folding up our tent, is there support for=20 > going ahead and developing a midcom MIB and keying framework=20 > for SNMPv3? Is this something that would be useful and=20 > deployable? Are there people who would be interested in=20 > doing the work?=20 >=20 > Melinda=20 > _______________________________________________=20 > midcom mailing list=20 > midcom@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/midcom=20 >=20 ------_=_NextPart_001_01C2A224.5C0A5EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 assumed that we would pick one, then take some time to design a solution = with=20 it. If it turns out that the chosen protocol doesn't work, then we = eliminate it=20 from contention and go back to the remaining = candidates.
 
I=20 doubt that we could design a well-designed solution with any candidate = protocol,=20 given only one day to do it.
 
dbh
-----Original Message-----
From: = Tom-PT Taylor=20 [mailto:taylor@nortelnetworks.com]
Sent: Thursday, December = 12,=20 2002 2:55 PM
To: 'Melinda Shore'; = midcom@ietf.org
Subject:=20 RE: [midcom] Where we stand/SNMPv3

I actually figured I had to develop the MIB this = week to make=20 sure SNMP is a feasible approach.  I was working on the = assumption that=20 the MIB to be developed represents the Agent's view rather than the = view of=20 the Middlebox.  (i.e.) the Middlebox will have to maintain a MIB = which is=20 more extensive than what the Agent gets to see and = manipulate.

> -----Original Message-----
>=20 From: Melinda Shore [mailto:mshore@cisco.com] =
> Sent: Thursday, December 12, 2002 2:13 PM =
> To: midcom@ietf.org
> = Subject: [midcom]=20 Where we stand/SNMPv3
>
>
> As things currently stand = the two=20 concerns raised regarding
> using SNMPv3 = as the=20 midcom protocol are 1) lack of interface
> to a=20 keying infrastructure, and 2) questions about
>=20 transaction rate.  The first is clearly addressable and the=20
> second, I think, remains an open = question. =20 We don't have a
> show-stopper. =
>
> This process (working = through the=20 list in the order
> presented in the = evaluation=20 document) is about coming to a
> = decision, but not=20 coming to a consensus-based decision. It's
>=20 absolutely clear that putting the three remaining protocols =
> in front of the working group and saying "pick one" = wasn't=20
> going to produce a consensus decision, = either. In=20 fact it was
> pretty much guaranteed to = produce=20 *no* decision.  One
> interested = observer=20 described the process as the working
> = group being=20 in a death spiral, and I don't think the choice
>=20 of the word "death" was accidental (more on that below). =
>
> There seems to be an = assumption among=20 some working group
> participants that if = we=20 eliminate all of the existing
> protocols = from=20 contention we will be rechartered to undertake
>=20 development of a protocol from scratch.  That is absolutely=20
> not the case.  I think it's pretty = clear=20 that if we found
> that none of SNMP, = Diameter, and=20 COPS were suitable the
> working group = would be=20 terminated rather than rechartered. 
> We were=20 told that eliminating them was a precondition for
>=20 doing one from scratch, but we were never, ever told that if =
> we were able to do so we would be given carte blanche to =
> develop a new protocol. =
>
> That leaves us with these = questions:=20 given that we did not
> arrive at SNMPv3 = by=20 consensus and given that the likely
> = alternative=20 is folding up our tent, is there support for
>=20 going ahead and developing a midcom MIB and keying framework =
> for SNMPv3?  Is this something that would be useful = and=20
> deployable?  Are there people who = would be=20 interested in
> doing the work? =
>
> Melinda
>=20 _______________________________________________
>=20 midcom mailing list
> = midcom@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/midcom =
>

=00 ------_=_NextPart_001_01C2A224.5C0A5EA0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 00:10:27 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 AAA03581 for ; Fri, 13 Dec 2002 00:10:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD5D3V12673 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 00:13:03 -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 gBD5CMv12650; Fri, 13 Dec 2002 00:12:22 -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 gBD5B7v12588 for ; Fri, 13 Dec 2002 00:11:07 -0500 Received: from mailscanout256k.tataelxsi.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03478 for ; Fri, 13 Dec 2002 00:07:55 -0500 (EST) Message-ID: <00e501c2a266$70287a20$6828010a@manicoz> From: "Rahul Gulati" To: Cc: "Jonathan Rosenberg" , , , , , , Date: Fri, 13 Dec 2002 10:43:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C2A294.89233280" Subject: [midcom] Question on Session Descriptors! 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_00E2_01C2A294.89233280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, All, I have a question on session descriptors. Refer to RFC 3303 Middlebox communication architecture and framework: Section 7.2 Page 19 SIP Phone SIP Proxy Middlebox SIP Phone (External) (MIDCOM agent) (NAPT (Private) IP Addr:Ea | Service) IP = addr:Pa | | IP addr:Ma = | | | | = | |----INVITE------->| | = | | | | = | |<---100Trying----| | = | | | | = | | |++ Query Port-BIND | | | | for (Ma, 5060) +++> | | | |<+ Port-BIND reply | = | | | for (Ma, 5060) ++++ | | | | | = | | |++ Query NAT Session | | | | Descriptor for | = | | | Ea-to-Pa SIP flow+> | | | |<+ Ea-to-Pa SIP flow | | | | Session Descriptor+ | | | | | = | In the example call flow, we query for session descriptors for Ea-to-Pa = SIP flow. 1) When is this session created?=20 Since INVITE hasn't been received at the Private SIP phone and we are = querying for the session descriptor which has already been created it = wud be beneficial if the above point could be explained? 2) We also maintain sessions for RTP-RTCP based on parent session as SIP = control.What is the relationship between these two sessions? Is there any section in RFC 3303 which explains the same? Best Regards' Rahul ------=_NextPart_000_00E2_01C2A294.89233280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, All,
 
I have a question on session=20 descriptors.
 
Refer to RFC 3303 Middlebox = communication=20 architecture and framework:
Section 7.2 Page 19
 
   SIP=20 Phone      SIP=20 Proxy           &n= bsp; =20 Middlebox     SIP = Phone
     =20 (External)     (MIDCOM=20 agent)        =20 (NAPT        =20 (Private)
      IP=20 Addr:Ea       =20 |            =       =20 Service)           = ;    =20 IP addr:Pa
     =20 |            =            | =             &= nbsp;    =20 IP=20 addr:Ma           =    =20 |
     =20 |            =            | =             &= nbsp;           &n= bsp;        =20 |            =  =20 |
     =20 |----INVITE------->|        &n= bsp;           &nb= sp;           &nbs= p; =20 |            =  =20 |
     =20 |            =           =20 |            =          =20             =20 |            =  =20 |
     =20 |<---100Trying----|        &nb= sp;           &nbs= p;=20             =20 |            =  =20 |
     =20 |            =           =20 |            =          =20             =20 |            =  =20 |
     =20 |            =           =20 |++ Query Port-BIND     =20 |            =  =20 |
     =20 |            =           =20 |   for (Ma, 5060) +++>  =20 |            =  =20 |
     =20 |            =           =20 |<+ Port-BIND reply       =20 |            =  =20 |
     =20 |            =           =20 |   for (Ma, 5060) ++++  =20 |            =  =20 |
     =20 |            =           =20 |            =             &= nbsp;          | &= nbsp;           =20 |
     =20 |            =           =20 |++ Query NAT Session =20 |            =  =20 |
     =20 |            =            | =  =20 Descriptor=20 for           &nbs= p; |          &nbs= p;  =20 |
     =20 |            =           =20 |   Ea-to-Pa SIP flow+>  =20 |            =  =20 |
     =20 |            =           =20 |<+ Ea-to-Pa SIP=20 flow     |      &n= bsp;      =20 |
     =20 |            =           =20 |   Session=20 Descriptor+   |       &= nbsp;     =20 |
     =20 |            =           =20 |            =             &= nbsp;          | &= nbsp;           =20 |
 
 
In the example call flow, we query for = session=20 descriptors for Ea-to-Pa SIP flow.
 
1)
When is this session created? =
Since INVITE hasn't been received at = the Private=20 SIP phone and we are querying for the session descriptor which has = already=20 been created it wud be beneficial if the above  point could be=20 explained?
 
2)
We also maintain sessions for RTP-RTCP = based on=20 parent session as SIP control.What is the relationship between these two = sessions?
 
Is there any section in RFC 3303 which = explains the=20 same?
 
Best Regards'
Rahul
 
 
------=_NextPart_000_00E2_01C2A294.89233280-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 03:36: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 DAA18041 for ; Fri, 13 Dec 2002 03:36:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD8dAc01654 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 03:39:10 -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 gBD8XNv00785; Fri, 13 Dec 2002 03:33:23 -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 gBD8WXv00737 for ; Fri, 13 Dec 2002 03:32:33 -0500 Received: from smtp013.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17951 for ; Fri, 13 Dec 2002 03:29:25 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Dec 2002 07:33:23 -0000 Reply-To: From: "Pyda Srisuresh" To: "Juergen Quittek" , "Harrington, David" , Subject: RE: direction of SNMP traps (was: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?) Date: Thu, 12 Dec 2002 23:37:11 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <1668629.1039600465@[192.168.102.164]> 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 My concern, the same. How effective is SNMP protocol for asynchronous notifications? Will the PUSH model work effectively? Refer section 8.2 of RFC 3303. regards, suresh -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Juergen Quittek Sent: Wednesday, December 11, 2002 12:54 AM To: Harrington, David; midcom@ietf.org Subject: direction of SNMP traps (was: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?) David, Does SNMP allow to dynamically direct traps based on table indices or values of managed objects? Or more concretely, would the following be a valid MIB design? One kind of transactions used in the semantics doc is an asynchronous notification from middlebox to midcom agent. Particularly, the notification (for example on expiration of a policy rule) is sent to one or more agents that configured it and not to midcom agents unrelated to the policy rule. I assume that a policy rule is modeled by a row of a table, indexed by the owner (or creator) of the row (and some further index components). Is there a way to have a notification on policy rule timeout sent to (just) the owner of the row? Certainly, you can just specify this in the SMI description of the notification, but would existing standard compliant SNMP agent toolkits support this (with some extra code provided by the MIB implementor)? The address and other required information on the owner might be stored in a separate table. Juergen -- Harrington, David wrote on 10 December 2002 19:51 -0500: > How will the traps work in the multi-server scenario? > > dbh> SNMPv3 trap management can support multiple manager applications, and you can configure the system to deliver certain types of traps to one manager, and another type to a different manager. _______________________________________________ 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 Dec 13 05:45: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 FAA19935 for ; Fri, 13 Dec 2002 05:45:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDAm8o08043 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 05:48:08 -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 gBDAlXv08032; Fri, 13 Dec 2002 05:47:33 -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 gBDAkov07989 for ; Fri, 13 Dec 2002 05:46:50 -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 FAA19927 for ; Fri, 13 Dec 2002 05:43:52 -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 gBDAjUF17246; Fri, 13 Dec 2002 11:46:25 +0100 (CET) (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 3C2A97E448; Fri, 13 Dec 2002 11:43:01 +0100 (CET) Message-ID: <3DF9B980.4010205@ccrle.nec.de> Date: Fri, 13 Dec 2002 11:42:08 +0100 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: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Where we stand/SNMPv3 References: <200212121913.ABI24383@mira-sjc5-c.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 > > That leaves us with these questions: given that we did not > arrive at SNMPv3 by consensus and given that the likely > alternative is folding up our tent, is there support for > going ahead and developing a midcom MIB and keying framework > for SNMPv3? Is this something that would be useful and > deployable? Are there people who would be interested in > doing the work? To points for SNMP: - the NAT MIB is already there and the NAT-MIB people think they can configure/control a NAT with this MIB. - our discussion has shown in my eyes that SNMP can do the job, but we do not know how good. But the "how good" is as always a matter of experience. So go ahead with SNMP, talk to the NAT-MIB people and get a MIDCOM protocol. Juergen and I both would like to support the definition of the MIDCOM MIB. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 05:56:20 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 FAA20057 for ; Fri, 13 Dec 2002 05:56:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDAwmo08327 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 05:58:48 -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 gBDAt5v08248; Fri, 13 Dec 2002 05:55:05 -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 gBDAsQv08220 for ; Fri, 13 Dec 2002 05:54:26 -0500 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 FAA20017 for ; Fri, 13 Dec 2002 05:51:26 -0500 (EST) 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 gBDArXi19514; Fri, 13 Dec 2002 11:53:34 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 11:53:32 +0100 Message-ID: From: "Cedric Aoun" To: "'Bob Penfield'" , "Harrington, David" , midcom@ietf.org, "'snmpv3@lists.tislabs.com'" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 13 Dec 2002 11:53:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A295.E12034AA" 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_01C2A295.E12034AA Content-Type: text/plain; charset="iso-8859-1" Bob thanks for giving a practical example, have a minor comment on the calculation we might need 5 transactions if we follow the reservation model prior to enabling the policy rule (I'm referring to the protocol semantics document). David, I agree that at this point looking at the number of messages per sec won't take us anywhere as we don't have SNMPv3, DIAMETER or COPS-PR code running the required extensions (in what ever form of extension) so comparing performance figures of existing implementations doesn't help (unless people have sometime to write some code for all the evaluated protocols and we do a bake off). Instead we could look how SNMPv3 can match MIDCOM pseudo messages documented in the protocol semantics (I already raised that previously). It would be interesting as well to understand the aggregation of commands (several policy rules installed or taken out without being in the same policy group) and see if in case there are some errors in the message how SNMP behaves (i.e. discard the whole request and send an error flag, or accept some of the commands and reply back with success for some commands and list the ones that have failed). Thanks Cedric -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: 10 December 2002 23:58 To: Harrington, David; midcom@ietf.org Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Assume a VOIP application using a middlebox handling a 1-Gigabit link. If you filled that link with G729-codec (8kbs/20ms samples) VOIP calls, you'd have 41,600 calls (using a bandwidth calculator I found on the web). If you assume a 3-minute call length, a continuously full 1-gigabit link would have a call rate of about 230 calls per second. At minimum, each call requires 2 transactions (open pinhole & close pinhole). That's 460 transactions per second. If it is a NAT box, and we might need to add a "reserve binding transaction", that's 690 transactions per second. If you had two 1-gigabit links, that's 1380 transactions per second. Hope that helps. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Harrington, David" To: Sent: Tuesday, December 10, 2002 3:40 PM Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Hi Cedric, I agree that the numbers don't say much without knowing what you're measuring and what you're comparing to. Are there specific requirements about the number of transactions per minute that must be met to qualify? I didn't see any in the requirements documents. Eric raised the issue the other day, saying that the requireent was for a number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that SNMPv3 would have a problem. I fear that this is an unnecessary rathole. There are no identified minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show that SNMPv3 throughput has not been found to be a problem in other environments. dbh -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Tuesday, December 10, 2002 2:40 PM To: Harrington, David; Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? In order to comment on these performance figures we need to understand if in order to install a policy rule we need more than a pair of messages (set and set response), I don't know if we got closure on the command aggregation or not without any proprietary hacks (sorry got lost in all the threads). The figures could be more representative if we could use the NAT MIB and see how the figures are affected. Is it possible to get the figures on the MIDCOM agent side (SNMP manager)? The next step is to see how to match this to real application sessions per sec that people expect this protocol to deliver on their boxes. We might get some agreement on the expected performance by saying that 6 or 8 pairs of MIDCOM messages (a pair is made of a request and reply) are required (between policy rule installation and policy rule deletion), in an average hold time of 1 min (let's say this is the worst case) this takes us to 16 MIDCOM messages (SNMP messages? ref to my note above) per mins for every application session (VoIP session, RTSP etc ...). After that, everyone can see if SNMPv3 meets their performance expectation (obviously without doing any implementation hacks, we're talking of a standard SNMPv3 stack). Thanks Cedric -----Original Message----- From: Harrington, David [ mailto:dbh@enterasys.com] Sent: 10 December 2002 20:04 To: Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Wes posted yesterday stating that it was messages per second. dbh > -----Original Message----- > From: Bob Penfield [ mailto:bpenfield@acmepacket.com] > Sent: Tuesday, December 10, 2002 1:30 PM > To: Harrington, David; midcom@ietf.org > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > Are those numbers transactions per second? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Harrington, David" > > -----Original Message----- > > From: Wes Hardaker [ mailto:hardaker@tislabs.com] > > > > Just for kicks, I ran 10000 requests of various kinds against the > > Net-SNMP stack (which is not a well optimized stack compared to > > the commercial vendors) and timed the results. This was on > a 233 PIII > > laptop which was not idle by any means, so take the numbers with a > > grain of salt. MD5 and DES were used for auth and priv. > > > > sysContact.0 in the Master agent: > > > > GET GETNEXT SET > > AuthPriv 1277 1176 493 > > AuthNoPriv 1462 1475 514 > > SNMPv1/2c 3769 3467 675 > > > > sysContact.0 in a subagent: > > > > GET GETNEXT SET > > AuthPriv 772 596 304 > > AuthNoPriv 860 661 355 > > SNMPv1/2c 1461 1018 420 > > > > > > -- > > Wes Hardaker > > Network Associates Laboratories > > _______________________________________________ > > 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 ------_=_NextPart_001_01C2A295.E12034AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

Bob thanks for giving a practical example, have a = minor comment on the calculation we might need 5 transactions if
we follow the reservation model prior to enabling = the policy rule (I'm referring to the protocol semantics = document).

David, I agree that at this point looking at the = number of messages per sec won't take us anywhere as we don't have = SNMPv3, DIAMETER or COPS-PR code running the required extensions (in = what ever form of extension) so comparing performance figures of = existing implementations doesn't help (unless people have sometime to = write some code for all the evaluated protocols and we do a bake = off).

Instead we could look how SNMPv3 can match MIDCOM = pseudo messages documented in the protocol semantics (I already raised = that previously).

It would be interesting as well to understand the = aggregation of commands (several policy rules installed or taken out = without being in the same policy group) and see if in case there are = some errors in the message how SNMP behaves (i.e. discard the whole = request and send an error flag, or accept some of the commands and = reply back with success for some commands and list the ones that have = failed).

Thanks
Cedric


-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: 10 December 2002 23:58
To: Harrington, David; midcom@ietf.org
Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: = Opinions?


Assume a VOIP application using a middlebox handling = a 1-Gigabit link. If
you filled that link with G729-codec (8kbs/20ms = samples) VOIP calls, you'd
have 41,600 calls (using a bandwidth calculator I = found on the web). If you
assume a 3-minute call length, a continuously full = 1-gigabit link would have
a call rate of about 230 calls per second. At = minimum, each call requires 2
transactions (open pinhole & close pinhole). = That's 460 transactions per
second. If it is a NAT box, and we might need to add = a "reserve binding
transaction", that's 690 transactions per = second. If you had two 1-gigabit
links, that's 1380 transactions per second.

Hope that helps.

cheers,
(-:bob

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

----- Original Message -----
From: "Harrington, David" = <dbh@enterasys.com>
To: <midcom@ietf.org>
Sent: Tuesday, December 10, 2002 3:40 PM
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: = Opinions?


Hi Cedric,

I agree that the numbers don't say much without = knowing what you're
measuring and what you're comparing to.

Are there specific requirements about the number of = transactions per minute
that must be met to qualify? I didn't see any in the = requirements documents.
Eric raised the issue the other day, saying that the = requireent was for a
number of transactions per minute. Even if it took = multiple request/reply
pairs to perform a transaction, at ~500 SET messages = per second I don't see
that SNMPv3 would have a problem.

I fear that this is an unnecessary rathole. There are = no identified minimum
requirements. There are no comparative numbers for = the other protocols
available. The numbers by themselves are = meaningless, except to show that
SNMPv3 throughput has not been found to be a problem = in other environments.

dbh

 -----Original Message-----
From: Cedric Aoun [mailto:cedric.aoun@nortel= networks.com]
Sent: Tuesday, December 10, 2002 2:40 PM
To: Harrington, David; Bob Penfield; = midcom@ietf.org
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: = Opinions?



In order to comment on these performance figures we = need to understand if in
order to install a policy rule we need
more than a pair of messages (set and set response), = I don't know if we got
closure on the command aggregation or not without = any proprietary hacks
(sorry got lost in all the threads).

The figures could be more representative if we could = use the NAT MIB and see
how the figures are affected.

Is it possible to get the figures on the MIDCOM agent = side (SNMP manager)?

The next step is to see how to match this to real = application sessions per
sec that people expect this protocol to deliver on = their boxes.

We might get some agreement on the expected = performance by saying that 6 or
8 pairs of MIDCOM messages (a pair is made of a = request and reply) are
required (between policy rule installation and = policy rule deletion), in an
average hold time of 1 min (let's say this is the = worst case) this takes us
to 16 MIDCOM messages (SNMP messages? ref to my note = above) per mins for
every application session (VoIP session, RTSP etc = ...).

After that, everyone can see if SNMPv3 meets their = performance expectation
(obviously without doing any implementation hacks, = we're talking of a
standard SNMPv3 stack).

Thanks
Cedric



-----Original Message-----
From: Harrington, David [ mailto:dbh@enterasys.com]
Sent: 10 December 2002 20:04
To: Bob Penfield; midcom@ietf.org
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: = Opinions?


Wes posted yesterday stating that it was messages per = second.

dbh

> -----Original Message-----
> From: Bob Penfield [ mailto:bpenfield@acmepacket.com= ]
> Sent: Tuesday, December 10, 2002 1:30 PM
> To: Harrington, David; midcom@ietf.org
> Subject: Re: [midcom] SNMPv3 as MIDCOM = protocol: Opinions?
>
>
> Are those numbers transactions per = second?
>
> cheers,
> (-:bob
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
>
> ----- Original Message -----
> From: "Harrington, David" = <dbh@enterasys.com>
> > -----Original Message-----
> > From: Wes Hardaker [ mailto:hardaker@tislabs.com]
> >
> > Just for kicks, I ran 10000 requests of = various kinds against the
> > Net-SNMP stack (which is not a well = optimized stack compared to
> > the commercial vendors) and timed the = results.  This was on
> a 233 PIII
> > laptop which was not idle by any means, so = take the numbers with a
> > grain of salt.  MD5 and DES were used = for auth and priv.
> >
> > sysContact.0 in the Master agent:
> >
> = >           &n= bsp;            = GET    GETNEXT    SET
> >   = AuthPriv          &nbs= p; 1277    1176       = 493
> >   = AuthNoPriv          = 1462    1475       = 514
> >   = SNMPv1/2c           = 3769    3467       = 675
> >
> > sysContact.0 in a subagent:
> >
> = >           &n= bsp;            = GET    GETNEXT    SET
> >   = AuthPriv          &nbs= p;  772     = 596       304
> >   = AuthNoPriv           = 860     661       = 355
> >   = SNMPv1/2c           = 1461    1018       = 420
> >
> >
> > --
> > Wes Hardaker
> > Network Associates Laboratories
> > = _______________________________________________
> > 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

------_=_NextPart_001_01C2A295.E12034AA-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 08:46: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 IAA23077 for ; Fri, 13 Dec 2002 08:46:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDDn2k17485 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 08:49:02 -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 gBDDmPv17450; Fri, 13 Dec 2002 08:48: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 gBDDlPv17412 for ; Fri, 13 Dec 2002 08:47:25 -0500 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 IAA23021 for ; Fri, 13 Dec 2002 08:44:17 -0500 (EST) 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 gBDDkoi14036; Fri, 13 Dec 2002 14:46:50 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 14:46:48 +0100 Message-ID: From: "Cedric Aoun" To: "'Melinda Shore'" , midcom@ietf.org, "'snmpv3@lists.tislabs.com'" Subject: RE: [midcom] Where we stand/SNMPv3 Date: Fri, 13 Dec 2002 14:46:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A2AE.15511AE2" 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_01C2A2AE.15511AE2 Content-Type: text/plain; charset="utf-8" "As things currently stand the two concerns raised regarding using SNMPv3 as the midcom protocol are 1) lack of interface to a keying infrastructure, and 2) questions about transaction rate. The first is clearly addressable and the second, I think, remains an open question. We don't have a show-stopper. " There is something else that people may want to understand is why the IETF is moving towards XML and leaving SNMP?Is this another protocol clone war? or there are real technical arguments for that? I'm trying to find an answer to this and appreciate any feedback from the list. Our problem is that the evaluated protocols meet the job, every protocol has its own way of doing the job. The main differences that we can list are relevant to performance (they have more or less the same amount of overhead) this what makes people really about especially that MIDCOM has real time applications. The first thing that comes to mind when looking at SNMP is its lack of in built transactional capability, it is up to the data objects carried by SNMP to achieve this transactional behavior (by looking at some reference number defined in the object format). How do people feel about that? Then we need to look at the atomicity issues that were addressed (by Juerguen and others) on the mailing list but didn't see any responses. Until we have cleared our minds on SNMP performance everybody will still have doubts and no real consensus will be reached, we should go and work on the MIB and then decide. We need to consider as well the applicability of the WG's delivery, will the low end Middlebox CPE vendors use it? SNMPv3 and the other evaluated protocols are more complex than all the protocols they are already running. I expect that they will go and use upnp (a lot of them already do that even with the known security flaws that were announced). Perhaps 2 protocols should be used in the internet depending on the market fit (please note that I'm not implying that we bring upnp to IETF and improve it). Cedric ------_=_NextPart_001_01C2A2AE.15511AE2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [midcom] Where we stand/SNMPv3

"As things currently stand the two concerns = raised regarding
using SNMPv3 as the midcom protocol are 1) lack of = interface
to a keying infrastructure, and 2) questions = about
transaction rate.  The first is clearly = addressable and the
second, I think, remains an open question.  We = don't have a
show-stopper. "

There is something else that people may want to = understand is why
the IETF is moving towards XML and leaving SNMP?Is = this another protocol clone war?
or there are real technical arguments for = that?
I'm trying to find an answer to this and appreciate = any feedback from the list.


Our problem is that the evaluated protocols meet the = job, every protocol has its own way
of doing the job. The main differences that we can = list are relevant to performance (they have more or less the same = amount of overhead) this what makes people really about especially that = MIDCOM has real time applications.

The first thing that comes to mind when looking at = SNMP is its lack of in built transactional capability, it is up to the = data objects carried by SNMP to achieve this transactional behavior (by = looking at some reference number defined in the object = format).

How do people feel about that?
Then we need to look at the atomicity issues that = were addressed (by Juerguen and others) on the mailing list but didn't = see any responses.

Until we have cleared our minds on SNMP performance = everybody will still have doubts and no real consensus will be reached, = we should go and work on the MIB and then decide.

We need to consider as well the applicability of the = WG's delivery, will the low end Middlebox CPE vendors use it? = SNMPv3

and the other evaluated protocols are more complex = than all the protocols they are already running.
I expect that they will go and use upnp (a lot of = them already do that even with the known security flaws that were = announced). Perhaps 2 protocols should be used in the internet = depending on the market fit (please note that I'm not implying that we = bring upnp to IETF and improve it).

  
Cedric


------_=_NextPart_001_01C2A2AE.15511AE2-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 09:10: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 JAA23749 for ; Fri, 13 Dec 2002 09:10:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDECTt19295 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 09:12:29 -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 gBDEC5v19283; Fri, 13 Dec 2002 09:12:05 -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 gBDEBHv19238 for ; Fri, 13 Dec 2002 09:11:17 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23729 for ; Fri, 13 Dec 2002 09:08:18 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA01808 for ; Fri, 13 Dec 2002 09:23:25 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma001782; Fri, 13 Dec 02 09:22:32 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 13 Dec 2002 09:10:36 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 13 Dec 2002 09:10:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: direction of SNMP traps (was: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?) Date: Fri, 13 Dec 2002 09:10:35 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892BC@NHROCMBX1.ets.enterasys.com> Thread-Topic: direction of SNMP traps (was: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?) Thread-Index: AcKg8VC7KaD7E9P0RJ6yTGtcaaH7KQBszxfQ From: "Harrington, David" To: "Juergen Quittek" , X-OriginalArrivalTime: 13 Dec 2002 14:10:35.0923 (UTC) FILETIME=[6819D630:01C2A2B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDEBHv19239 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 Hi, Yes. Notifications can be dynamically filtered based on table indices, using VACM. The SNMPv3 notification mibs can be used to direct notifications. By combining the two capabilities, SNMPv3 can be used to dynamically direct notifications based on the table indices of managed objects. The scenario you present should be no problem. There are a number of ways to design for this problem, and there may be more efficient ways to achieve this than my first suggestion. dbh > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Wednesday, December 11, 2002 3:54 AM > To: Harrington, David; midcom@ietf.org > Subject: direction of SNMP traps (was: RE: [midcom] SNMPv3 as MIDCOM > protocol: Opinions?) > > > David, > > Does SNMP allow to dynamically direct traps based on table > indices or values of managed objects? > > Or more concretely, would the following be a valid MIB design? > > One kind of transactions used in the semantics doc is an asynchronous > notification from middlebox to midcom agent. Particularly, the > notification (for example on expiration of a policy rule) is sent > to one or more agents that configured it and not to midcom agents > unrelated to the policy rule. > > I assume that a policy rule is modeled by a row of a table, > indexed by the owner (or creator) of the row (and some further > index components). Is there a way to have a notification on > policy rule timeout sent to (just) the owner of the row? > > Certainly, you can just specify this in the SMI description of the > notification, but would existing standard compliant SNMP agent > toolkits support this (with some extra code provided by the MIB > implementor)? > > The address and other required information on the owner might be > stored in a separate table. > > Juergen > > > -- Harrington, David wrote on 10 December 2002 19:51 -0500: > > > How will the traps work in the multi-server scenario? > > > > dbh> SNMPv3 trap management can support multiple manager > applications, and you can configure the system to deliver > certain types of traps to one manager, and another type to a > different manager. > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 09:10: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 JAA23762 for ; Fri, 13 Dec 2002 09:10:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDECUe19307 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 09:12:30 -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 gBDEC3v19267; Fri, 13 Dec 2002 09:12: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 gBDEBBv19233 for ; Fri, 13 Dec 2002 09:11:11 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23726 for ; Fri, 13 Dec 2002 09:08:12 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 09:11:08 -0500 Message-ID: <5001C86452603F41820378E167091F07EEDA07@email1.unispherenetworks.com> From: "Moisand, Jerome" To: midcom@ietf.org Date: Fri, 13 Dec 2002 09:09:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] SNMP proposal and transactional behavior 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: , Could somebody help me understand the following point? Say we have a VoIP scenario. With strong business constraints from a service provider operating the middlebox of not allowing a VoIP/RTP session to flow any longer than strictly necessary. Or strong security constraints from an enterprise IT organization operating the middlebox (with same end requirement). Say some sort of SIP proxy ends up triggering a middlebox agent software, which in turn pokes the appropriate hole in the middlebox via some form of "midcom SNMP MIB". This "hole" is truly a dynamic state, which should be removed whenever there is any doubt that the voice call is over. Now say that the combination of the SIP proxy and the middlebox agent software (functions may be actually colocated, but are probably pretty far from the middlebox itself) loses connectivity with the middlebox for a while. Then when the VoIP session is stopped via SIP (hence accounting/billing -for time-based models- are stopped), the middlebox can't know it via a regular SNMP set. What will ensure that the "dynamic" state which has been created will disappear? And disappear quickly enough? Note that a timer based on activity detection is not an answer, nothing says that traffic is legit. Tx Jerome _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 09:10: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 JAA23775 for ; Fri, 13 Dec 2002 09:10:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDECZp19320 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 09:12:35 -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 gBDE9Av19165; Fri, 13 Dec 2002 09:09:10 -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 gBDE8Vv19097 for ; Fri, 13 Dec 2002 09:08:31 -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 JAA23685 for ; Fri, 13 Dec 2002 09:05:32 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDE8SFp009202; Fri, 13 Dec 2002 06:08:28 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ53320; Fri, 13 Dec 2002 06:08:26 -0800 (PST) Message-Id: <200212131408.ABJ53320@mira-sjc5-c.cisco.com> To: "Cedric Aoun" cc: midcom@ietf.org, "'snmpv3@lists.tislabs.com'" From: Melinda Shore Subject: Re: [midcom] Where we stand/SNMPv3 In-Reply-To: Message from "Cedric Aoun" of "Fri, 13 Dec 2002 14:46:49 +0100." Date: Fri, 13 Dec 2002 09:08:26 -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 is something else that people may want to understand is why > the IETF is moving towards XML and leaving SNMP?Is this another protocol > clone war? There is no organized move within the IETF towards XML - some individual working groups are using XML-encoding for their protocols, but there's no conspiracy here. Possibly the most memorable quote from IETF 54 was Jeff Schilling's comment in the saag meeting that "XML is this decade's ASN.1." > Our problem is that the evaluated protocols meet the job, > every protocol has its own way of doing the job. The main > differences that we can list are relevant to performance > (they have more or less the same amount of overhead) this > what makes people really about especially that MIDCOM has > real time applications. We don't even know if there really are meaningful differences between the protocols when it comes to performance, so I'm not sure that there's progress to be made here. I haven't seen calls to eliminate protocols that use TCP or SCTP for transport on the basis of performance/ scalability. The discussion about protocol selection is over. The question now is whether or not to go ahead with an SNMP- based midcom protocol. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 09:17:59 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 JAA23965 for ; Fri, 13 Dec 2002 09:17:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDEKRq19657 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 09:20:27 -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 gBDEK3v19636; Fri, 13 Dec 2002 09:20: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 gBDEJhv19601 for ; Fri, 13 Dec 2002 09:19:43 -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 JAA23955 for ; Fri, 13 Dec 2002 09:16:44 -0500 (EST) 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 gBDEJbR16937; Fri, 13 Dec 2002 09:19:38 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 09:19:38 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E031@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Moisand, Jerome'" , midcom@ietf.org Subject: RE: [midcom] SNMP proposal and transactional behavior Date: Fri, 13 Dec 2002 09:19:36 -0500 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: , The Policy Rule lifetime may fulfill this role, though I would see it operating at a granularity of minutes to keep Midcom traffic down. > -----Original Message----- > From: Moisand, Jerome [mailto:jmoisand@juniper.net] > Sent: Friday, December 13, 2002 9:10 AM > To: midcom@ietf.org > Subject: [midcom] SNMP proposal and transactional behavior > > > > Could somebody help me understand the following point? > > Say we have a VoIP scenario. With strong business constraints > from a service provider operating the middlebox of not > allowing a VoIP/RTP session to flow any longer than strictly > necessary. Or strong security constraints from an enterprise > IT organization operating the middlebox (with same end requirement). > > Say some sort of SIP proxy ends up triggering a middlebox > agent software, which in turn pokes the appropriate hole in > the middlebox via some form of "midcom SNMP MIB". This "hole" > is truly a dynamic state, which should be removed whenever > there is any doubt that the voice call is over. > > Now say that the combination of the SIP proxy and the > middlebox agent software (functions may be actually > colocated, but are probably pretty far from the middlebox > itself) loses connectivity with the middlebox for a while. > Then when the VoIP session is stopped via SIP (hence > accounting/billing -for time-based models- are stopped), the > middlebox can't know it via a regular SNMP set. > > What will ensure that the "dynamic" state which has been > created will disappear? And disappear quickly enough? > > Note that a timer based on activity detection is not an > answer, nothing says that traffic is legit. > > Tx > Jerome > > _______________________________________________ > 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 Dec 13 09:29: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 JAA24279 for ; Fri, 13 Dec 2002 09:29:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDEVr320081 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 09:31:53 -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 gBDES7v19953; Fri, 13 Dec 2002 09:28: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 gBDER9v19926 for ; Fri, 13 Dec 2002 09:27:09 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24186 for ; Fri, 13 Dec 2002 09:24:09 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA03282 for ; Fri, 13 Dec 2002 09:39:15 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma003237; Fri, 13 Dec 02 09:38:55 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 13 Dec 2002 09:26:54 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 13 Dec 2002 09:26:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 13 Dec 2002 09:26:53 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892BD@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKilg9aLuh2e6ADSo6VuvHYfm3i9gAHBkjA From: "Harrington, David" To: "Cedric Aoun" , "Bob Penfield" , Cc: "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 13 Dec 2002 14:26:54.0064 (UTC) FILETIME=[AF1E4F00:01C2A2B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDER9v19927 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 Hi, First, as co-chair of SNMPv3, I would like to set some guidelines on which messages should be copied to the snmpv3 mailing list and which should not. I don't object to messages sent to the snmpv3 mailing list seeking input from SNMP-knowledgeable people about the capabilities of snmpv3. I encourage any interested SNMP-ers to join the midcom mailing list to participate. However, this WG is still involved in debates over just what the midcom requirements should be. That discussion is a topic for the midcom wg, not the snmpv3 wg. dbh -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Friday, December 13, 2002 5:54 AM To: 'Bob Penfield'; Harrington, David; midcom@ietf.org; 'snmpv3@lists.tislabs.com' Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Bob thanks for giving a practical example, have a minor comment on the calculation we might need 5 transactions if we follow the reservation model prior to enabling the policy rule (I'm referring to the protocol semantics document). David, I agree that at this point looking at the number of messages per sec won't take us anywhere as we don't have SNMPv3, DIAMETER or COPS-PR code running the required extensions (in what ever form of extension) so comparing performance figures of existing implementations doesn't help (unless people have sometime to write some code for all the evaluated protocols and we do a bake off). Instead we could look how SNMPv3 can match MIDCOM pseudo messages documented in the protocol semantics (I already raised that previously). It would be interesting as well to understand the aggregation of commands (several policy rules installed or taken out without being in the same policy group) and see if in case there are some errors in the message how SNMP behaves (i.e. discard the whole request and send an error flag, or accept some of the commands and reply back with success for some commands and list the ones that have failed). Thanks Cedric -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: 10 December 2002 23:58 To: Harrington, David; midcom@ietf.org Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Assume a VOIP application using a middlebox handling a 1-Gigabit link. If you filled that link with G729-codec (8kbs/20ms samples) VOIP calls, you'd have 41,600 calls (using a bandwidth calculator I found on the web). If you assume a 3-minute call length, a continuously full 1-gigabit link would have a call rate of about 230 calls per second. At minimum, each call requires 2 transactions (open pinhole & close pinhole). That's 460 transactions per second. If it is a NAT box, and we might need to add a "reserve binding transaction", that's 690 transactions per second. If you had two 1-gigabit links, that's 1380 transactions per second. Hope that helps. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Harrington, David" To: Sent: Tuesday, December 10, 2002 3:40 PM Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Hi Cedric, I agree that the numbers don't say much without knowing what you're measuring and what you're comparing to. Are there specific requirements about the number of transactions per minute that must be met to qualify? I didn't see any in the requirements documents. Eric raised the issue the other day, saying that the requireent was for a number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that SNMPv3 would have a problem. I fear that this is an unnecessary rathole. There are no identified minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show that SNMPv3 throughput has not been found to be a problem in other environments. dbh -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Tuesday, December 10, 2002 2:40 PM To: Harrington, David; Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? In order to comment on these performance figures we need to understand if in order to install a policy rule we need more than a pair of messages (set and set response), I don't know if we got closure on the command aggregation or not without any proprietary hacks (sorry got lost in all the threads). The figures could be more representative if we could use the NAT MIB and see how the figures are affected. Is it possible to get the figures on the MIDCOM agent side (SNMP manager)? The next step is to see how to match this to real application sessions per sec that people expect this protocol to deliver on their boxes. We might get some agreement on the expected performance by saying that 6 or 8 pairs of MIDCOM messages (a pair is made of a request and reply) are required (between policy rule installation and policy rule deletion), in an average hold time of 1 min (let's say this is the worst case) this takes us to 16 MIDCOM messages (SNMP messages? ref to my note above) per mins for every application session (VoIP session, RTSP etc ...). After that, everyone can see if SNMPv3 meets their performance expectation (obviously without doing any implementation hacks, we're talking of a standard SNMPv3 stack). Thanks Cedric -----Original Message----- From: Harrington, David [ mailto:dbh@enterasys.com] Sent: 10 December 2002 20:04 To: Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Wes posted yesterday stating that it was messages per second. dbh > -----Original Message----- > From: Bob Penfield [ mailto:bpenfield@acmepacket.com] > Sent: Tuesday, December 10, 2002 1:30 PM > To: Harrington, David; midcom@ietf.org > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > Are those numbers transactions per second? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Harrington, David" > > -----Original Message----- > > From: Wes Hardaker [ mailto:hardaker@tislabs.com] > > > > Just for kicks, I ran 10000 requests of various kinds against the > > Net-SNMP stack (which is not a well optimized stack compared to > > the commercial vendors) and timed the results. This was on > a 233 PIII > > laptop which was not idle by any means, so take the numbers with a > > grain of salt. MD5 and DES were used for auth and priv. > > > > sysContact.0 in the Master agent: > > > > GET GETNEXT SET > > AuthPriv 1277 1176 493 > > AuthNoPriv 1462 1475 514 > > SNMPv1/2c 3769 3467 675 > > > > sysContact.0 in a subagent: > > > > GET GETNEXT SET > > AuthPriv 772 596 304 > > AuthNoPriv 860 661 355 > > SNMPv1/2c 1461 1018 420 > > > > > > -- > > Wes Hardaker > > Network Associates Laboratories > > _______________________________________________ > > 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 Dec 13 10:03: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 KAA24942 for ; Fri, 13 Dec 2002 10:03:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDF6G721879 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 10:06:16 -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 gBDF5Nv21851; Fri, 13 Dec 2002 10:05:23 -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 gBDF4Rv21799 for ; Fri, 13 Dec 2002 10:04:27 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24885 for ; Fri, 13 Dec 2002 10:01:27 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA05786 for ; Fri, 13 Dec 2002 10:16:34 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma005771; Fri, 13 Dec 02 10:16:13 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 13 Dec 2002 10:04:22 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 13 Dec 2002 10:04:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 13 Dec 2002 10:04:21 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892BE@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKilg9aLuh2e6ADSo6VuvHYfm3i9gAHcVhw From: "Harrington, David" To: X-OriginalArrivalTime: 13 Dec 2002 15:04:21.0783 (UTC) FILETIME=[EADD0270:01C2A2B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDF4Rv21800 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 Hi Cedric, How well SNMP will be able to perform the specific transactions depends a great deal on how the mibs are designed. I, an experienced SNMP solutions designer, believe SNMP will be able to handle the semantic requirements. I and other experienced SNMP developers believe that in a well-designed mib solution, supporting transactions between two reasonably well-implemented snmp engines, you will not have a performance problem. I have already commented that the semantics requirements should be modified to align itself with the best current practices of the protocol selected, whichever one that may be. Doing a purely theoretical analysis of the efficiency of implementing according to semantic requirements that are not aligned with best current practices for the protocol seems like a gigantic waste of time. I believe there are so many variables involved, that we cannot answer this question using theory alone. I believe network latency will have a larger impact on performance than the SNMP operations involved. We don't know yet which snmp operations would be involved. We don't know how those operations map to underlying implementation details. and on and on and on... We have no real data to work with; we cannot prove nor disprove any claims that any of the protocols will or will not meet performance requirements. Forgive me for being blunt. I have a real job, and responding to a bunch of theoretical analyses requires a lot of my time, and I don't feel it is my responsibility to keep having to respond to new ill-conceived requirements made up on the fly. If the WG wants to consider the theoretical efficiencies of the different protocols, when used in a manner that is not aligned with best current practices for the protocols, I say "go ahead - have a good time". If you want meaningful analyses, you need to agree on your requirements, then do comparisons of the protocols, and compare well-designed solutions, and you should use REAL data not theoretical data. I'm not sure how long the industry will wait for you though. dbh -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Friday, December 13, 2002 5:54 AM To: 'Bob Penfield'; Harrington, David; midcom@ietf.org; 'snmpv3@lists.tislabs.com' Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Bob thanks for giving a practical example, have a minor comment on the calculation we might need 5 transactions if we follow the reservation model prior to enabling the policy rule (I'm referring to the protocol semantics document). David, I agree that at this point looking at the number of messages per sec won't take us anywhere as we don't have SNMPv3, DIAMETER or COPS-PR code running the required extensions (in what ever form of extension) so comparing performance figures of existing implementations doesn't help (unless people have sometime to write some code for all the evaluated protocols and we do a bake off). Instead we could look how SNMPv3 can match MIDCOM pseudo messages documented in the protocol semantics (I already raised that previously). It would be interesting as well to understand the aggregation of commands (several policy rules installed or taken out without being in the same policy group) and see if in case there are some errors in the message how SNMP behaves (i.e. discard the whole request and send an error flag, or accept some of the commands and reply back with success for some commands and list the ones that have failed). Thanks Cedric -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: 10 December 2002 23:58 To: Harrington, David; midcom@ietf.org Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Assume a VOIP application using a middlebox handling a 1-Gigabit link. If you filled that link with G729-codec (8kbs/20ms samples) VOIP calls, you'd have 41,600 calls (using a bandwidth calculator I found on the web). If you assume a 3-minute call length, a continuously full 1-gigabit link would have a call rate of about 230 calls per second. At minimum, each call requires 2 transactions (open pinhole & close pinhole). That's 460 transactions per second. If it is a NAT box, and we might need to add a "reserve binding transaction", that's 690 transactions per second. If you had two 1-gigabit links, that's 1380 transactions per second. Hope that helps. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Harrington, David" To: Sent: Tuesday, December 10, 2002 3:40 PM Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Hi Cedric, I agree that the numbers don't say much without knowing what you're measuring and what you're comparing to. Are there specific requirements about the number of transactions per minute that must be met to qualify? I didn't see any in the requirements documents. Eric raised the issue the other day, saying that the requireent was for a number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that SNMPv3 would have a problem. I fear that this is an unnecessary rathole. There are no identified minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show that SNMPv3 throughput has not been found to be a problem in other environments. dbh -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Tuesday, December 10, 2002 2:40 PM To: Harrington, David; Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? In order to comment on these performance figures we need to understand if in order to install a policy rule we need more than a pair of messages (set and set response), I don't know if we got closure on the command aggregation or not without any proprietary hacks (sorry got lost in all the threads). The figures could be more representative if we could use the NAT MIB and see how the figures are affected. Is it possible to get the figures on the MIDCOM agent side (SNMP manager)? The next step is to see how to match this to real application sessions per sec that people expect this protocol to deliver on their boxes. We might get some agreement on the expected performance by saying that 6 or 8 pairs of MIDCOM messages (a pair is made of a request and reply) are required (between policy rule installation and policy rule deletion), in an average hold time of 1 min (let's say this is the worst case) this takes us to 16 MIDCOM messages (SNMP messages? ref to my note above) per mins for every application session (VoIP session, RTSP etc ...). After that, everyone can see if SNMPv3 meets their performance expectation (obviously without doing any implementation hacks, we're talking of a standard SNMPv3 stack). Thanks Cedric -----Original Message----- From: Harrington, David [ mailto:dbh@enterasys.com] Sent: 10 December 2002 20:04 To: Bob Penfield; midcom@ietf.org Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Wes posted yesterday stating that it was messages per second. dbh > -----Original Message----- > From: Bob Penfield [ mailto:bpenfield@acmepacket.com] > Sent: Tuesday, December 10, 2002 1:30 PM > To: Harrington, David; midcom@ietf.org > Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? > > > Are those numbers transactions per second? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Harrington, David" > > -----Original Message----- > > From: Wes Hardaker [ mailto:hardaker@tislabs.com] > > > > Just for kicks, I ran 10000 requests of various kinds against the > > Net-SNMP stack (which is not a well optimized stack compared to > > the commercial vendors) and timed the results. This was on > a 233 PIII > > laptop which was not idle by any means, so take the numbers with a > > grain of salt. MD5 and DES were used for auth and priv. > > > > sysContact.0 in the Master agent: > > > > GET GETNEXT SET > > AuthPriv 1277 1176 493 > > AuthNoPriv 1462 1475 514 > > SNMPv1/2c 3769 3467 675 > > > > sysContact.0 in a subagent: > > > > GET GETNEXT SET > > AuthPriv 772 596 304 > > AuthNoPriv 860 661 355 > > SNMPv1/2c 1461 1018 420 > > > > > > -- > > Wes Hardaker > > Network Associates Laboratories > > _______________________________________________ > > 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 Dec 13 10:16:20 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 KAA25353 for ; Fri, 13 Dec 2002 10:16:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDFInT22954 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 10:18:49 -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 gBDFF6v22809; Fri, 13 Dec 2002 10: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 gBDFE5v22757 for ; Fri, 13 Dec 2002 10:14:05 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25174 for ; Fri, 13 Dec 2002 10:11:05 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA06440 for ; Fri, 13 Dec 2002 10:26:11 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma006415; Fri, 13 Dec 02 10:25:54 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 13 Dec 2002 10:14:03 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 13 Dec 2002 10:14:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Date: Fri, 13 Dec 2002 10:14:03 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892BF@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 as MIDCOM protocol: Opinions? Thread-Index: AcKilg9aLuh2e6ADSo6VuvHYfm3i9gAIw0oQ From: "Harrington, David" To: X-OriginalArrivalTime: 13 Dec 2002 15:14:03.0220 (UTC) FILETIME=[456D4140:01C2A2BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDFE5v22758 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 Hi, RFCs 1906-1907 and RFCs 2570-2576 describe SNMP behaviors. I recommend you read them. There are also numerous books available that are easier to read (although some have known inaccuracies). SNMP SET behavior is clearly defined in RFC1905. It is basically the same behavior SNMP has always followed for SETs since 1988. SNMP SETs are always atomic. The whole message succeeds or the whole message fails. Error codes are returned; a pointer shows the managed object that caused the problem. dbh -----Original Message----- From: Cedric Aoun [mailto:cedric.aoun@nortelnetworks.com] Sent: Friday, December 13, 2002 5:54 AM To: 'Bob Penfield'; Harrington, David; midcom@ietf.org; 'snmpv3@lists.tislabs.com' Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? It would be interesting as well to understand the aggregation of commands (several policy rules installed or taken out without being in the same policy group) and see if in case there are some errors in the message how SNMP behaves (i.e. discard the whole request and send an error flag, or accept some of the commands and reply back with success for some commands and list the ones that have failed). Thanks Cedric _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 13:08: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 NAA00371 for ; Fri, 13 Dec 2002 13:08:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDIBEX01670 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 13:11:14 -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 gBDIAJv01645; Fri, 13 Dec 2002 13:10:22 -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 gBDI9tv01600 for ; Fri, 13 Dec 2002 13:09:55 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00307 for ; Fri, 13 Dec 2002 13:06:53 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 13:09:50 -0500 Message-ID: <5001C86452603F41820378E167091F07EEDA0D@email1.unispherenetworks.com> From: "Moisand, Jerome" To: midcom@ietf.org Subject: RE: [midcom] Where we stand/SNMPv3 Date: Fri, 13 Dec 2002 13:08:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I'm glad you clarified, Melinda. I have to say I'm very uncomfortable with the "non-consensus" approach. In the five approaches suggested by Jonathan, I don't believe there was much support for this one... And I don't believe this is the best way to make the "midcom" protocol a reality implemented by multiple players. Maybe I'm still pretty new to the workgroup, but personally, I'm not convinced we were in a "death spiral". The list of protocols was getting slimmed down. And maybe I'm mistaken, but somehow I believe we could have quickly reached a "two protocol" list. What I cannot understand is why we did not consider the proposal to work on two protocols IF there were enough volunteers (hence industry interest) to do one or the other. As a personal assessment, I persist to think that SNMP is a better match for some scenarios/architectures, and COPS is a better match for some scenarios/architectures. I also strongly believe that the "spiral" we've entered tends to show that a single protocol approach is not the right thing to do, because the argument seems to have lasted long enough that each "camp" must have had valid points... The diffserv group developed a MIB and a PIB. The ipsp group is doing the same. And well, for these respective domains (both of them somewhat intersecting the midcom work, by the way), I think this was the right choice to allow architectural flexibility and provide the best answer to a large collection of use cases. As to the midcom group "efficiency" question, I do agree that working on something "real" (an SNMP MIB, a COPS PIB, whatever) is the way to move on. Then we stop with all these endless theoretical arguments and ask ourselves the real questions about the actual mapping, how to do it, does it work. Just my two cents... Jerome -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Thursday, December 12, 2002 2:13 PM To: midcom@ietf.org Subject: [midcom] Where we stand/SNMPv3 [...] This process (working through the list in the order presented in the evaluation document) is about coming to a decision, but not coming to a consensus-based decision. It's absolutely clear that putting the three remaining protocols in front of the working group and saying "pick one" wasn't going to produce a consensus decision, either. In fact it was pretty much guaranteed to produce *no* decision. One interested observer described the process as the working group being in a death spiral, and I don't think the choice of the word "death" was accidental (more on that below). There seems to be an assumption among some working group participants that if we eliminate all of the existing protocols from contention we will be rechartered to undertake development of a protocol from scratch. That is absolutely not the case. I think it's pretty clear that if we found that none of SNMP, Diameter, and COPS were suitable the working group would be terminated rather than rechartered. We were told that eliminating them was a precondition for doing one from scratch, but we were never, ever told that if we were able to do so we would be given carte blanche to develop a new protocol. That leaves us with these questions: given that we did not arrive at SNMPv3 by consensus and given that the likely alternative is folding up our tent, is there support for going ahead and developing a midcom MIB and keying framework for SNMPv3? Is this something that would be useful and deployable? Are there people who would be interested in doing the work? 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 Dec 13 13:16: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 NAA00576 for ; Fri, 13 Dec 2002 13:16:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDIIbY01880 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 13:18:37 -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 gBDIF3v01801; Fri, 13 Dec 2002 13:15: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 gBDIEPv01773 for ; Fri, 13 Dec 2002 13:14:25 -0500 Received: from mailhost1.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00471 for ; Fri, 13 Dec 2002 13:11:23 -0500 (EST) Received: by email1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 13:14:20 -0500 Message-ID: <5001C86452603F41820378E167091F07EEDA0F@email1.unispherenetworks.com> From: "Moisand, Jerome" To: "'Tom-PT Taylor'" , midcom@ietf.org Subject: RE: [midcom] SNMP proposal and transactional behavior Date: Fri, 13 Dec 2002 13:13:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Er... does this imply that each policy rule would have to be "refreshed" every few minutes? If I properly understood you, then I'm afraid this is a troublesome scaling issue? Plus this would imply states on the middlebox application, isn't it? -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, December 13, 2002 9:20 AM To: Moisand, Jerome; midcom@ietf.org Subject: RE: [midcom] SNMP proposal and transactional behavior The Policy Rule lifetime may fulfill this role, though I would see it operating at a granularity of minutes to keep Midcom traffic down. > -----Original Message----- > From: Moisand, Jerome [mailto:jmoisand@juniper.net] > Sent: Friday, December 13, 2002 9:10 AM > To: midcom@ietf.org > Subject: [midcom] SNMP proposal and transactional behavior > > > > Could somebody help me understand the following point? > > Say we have a VoIP scenario. With strong business constraints > from a service provider operating the middlebox of not > allowing a VoIP/RTP session to flow any longer than strictly > necessary. Or strong security constraints from an enterprise > IT organization operating the middlebox (with same end requirement). > > Say some sort of SIP proxy ends up triggering a middlebox > agent software, which in turn pokes the appropriate hole in > the middlebox via some form of "midcom SNMP MIB". This "hole" > is truly a dynamic state, which should be removed whenever > there is any doubt that the voice call is over. > > Now say that the combination of the SIP proxy and the > middlebox agent software (functions may be actually > colocated, but are probably pretty far from the middlebox > itself) loses connectivity with the middlebox for a while. > Then when the VoIP session is stopped via SIP (hence > accounting/billing -for time-based models- are stopped), the > middlebox can't know it via a regular SNMP set. > > What will ensure that the "dynamic" state which has been > created will disappear? And disappear quickly enough? > > Note that a timer based on activity detection is not an > answer, nothing says that traffic is legit. > > Tx > Jerome > > _______________________________________________ > 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 Dec 13 14:02:26 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 OAA01954 for ; Fri, 13 Dec 2002 14:02:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDJ4uD04160 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 14:04:56 -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 gBDJ1Cv04090; Fri, 13 Dec 2002 14:01: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 gBDJ0jv04061 for ; Fri, 13 Dec 2002 14:00:45 -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 NAA01797 for ; Fri, 13 Dec 2002 13:57:44 -0500 (EST) 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 gBDJ0UI04951; Fri, 13 Dec 2002 14:00:30 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 14:00:30 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E03C@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Moisand, Jerome'" , midcom@ietf.org Subject: RE: [midcom] SNMP proposal and transactional behavior Date: Fri, 13 Dec 2002 14:00:29 -0500 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: , The nature of policy rules for NATs and firewalls is that they are transient. They are assigned a lifetime when they are created (see the semantics draft for details), and expire at the end of that life unless renewed. Some rules (giving access to servers, perhaps) may need a long lifetime (are more or less permanent). Others relate to a session which typically will last minutes. Yes, there's lots of state in the middlebox application. > -----Original Message----- > From: Moisand, Jerome [mailto:jmoisand@juniper.net] > Sent: Friday, December 13, 2002 1:14 PM > To: Taylor, Tom-PT [CAR:B602:EXCH]; midcom@ietf.org > Subject: RE: [midcom] SNMP proposal and transactional behavior > > > > Er... does this imply that each policy rule would have to be > "refreshed" every few minutes? If I properly understood you, > then I'm afraid this is a troublesome scaling issue? > > Plus this would imply states on the middlebox application, isn't it? > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Friday, December 13, 2002 9:20 AM > To: Moisand, Jerome; midcom@ietf.org > Subject: RE: [midcom] SNMP proposal and transactional behavior > > > The Policy Rule lifetime may fulfill this role, though I > would see it operating at a granularity of minutes to keep > Midcom traffic down. > > > -----Original Message----- > > From: Moisand, Jerome [mailto:jmoisand@juniper.net] > > Sent: Friday, December 13, 2002 9:10 AM > > To: midcom@ietf.org > > Subject: [midcom] SNMP proposal and transactional behavior > > > > > > > > Could somebody help me understand the following point? > > > > Say we have a VoIP scenario. With strong business constraints > > from a service provider operating the middlebox of not > > allowing a VoIP/RTP session to flow any longer than strictly > > necessary. Or strong security constraints from an enterprise > > IT organization operating the middlebox (with same end requirement). > > > > Say some sort of SIP proxy ends up triggering a middlebox > > agent software, which in turn pokes the appropriate hole in > > the middlebox via some form of "midcom SNMP MIB". This "hole" > > is truly a dynamic state, which should be removed whenever > > there is any doubt that the voice call is over. > > > > Now say that the combination of the SIP proxy and the > > middlebox agent software (functions may be actually > > colocated, but are probably pretty far from the middlebox > > itself) loses connectivity with the middlebox for a while. > > Then when the VoIP session is stopped via SIP (hence > > accounting/billing -for time-based models- are stopped), the > > middlebox can't know it via a regular SNMP set. > > > > What will ensure that the "dynamic" state which has been > > created will disappear? And disappear quickly enough? > > > > Note that a timer based on activity detection is not an > > answer, nothing says that traffic is legit. > > > > Tx > > Jerome > > > > _______________________________________________ > > 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 Dec 13 15:05: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 PAA03989 for ; Fri, 13 Dec 2002 15:05:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDK7fB08791 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 15:07:41 -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 gBDK7Ev08619; Fri, 13 Dec 2002 15:07:14 -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 gBDK6Xv08128 for ; Fri, 13 Dec 2002 15:06:33 -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 PAA03977 for ; Fri, 13 Dec 2002 15:03:31 -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 gBDK6PR19274 for ; Fri, 13 Dec 2002 15:06:26 -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 WZPABFZ5; Fri, 13 Dec 2002 15:06:25 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.173]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W8HJ4PQD; Fri, 13 Dec 2002 15:06:25 -0500 Message-Id: <5.2.0.9.0.20021213140919.02f83440@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 15:04:19 -0500 To: midcom@ietf.org From: Kwok Ho Chan Cc: Kwok Ho Chan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [midcom] SNMPv3 and multiple MA requirement 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: , FYI! If SNMPv3 (and assuming SMIv2 is used also) is used as the MIDCOM protocol, There are additional complexity when considering the usage of multiple Middlebox Agents (MAs) with a Middlebox (MB). 1. When multiple MAs trying to control the same resource on the MB, SNMPv3 does not allow simple control of which MA performs SETs to which object instance in which order with deterministic results. For example resource on MB is controlled by MA-1, MA-2, MA-3 concurrently. Resource is parameterized by object-1, object-2, object-3. And they are inter-related. MA-1 created the object-1 instance needed for the resource. Object-2 and object-3 must be created correctly before the resource is setup/allocated correctly. Before MA-1 can create object-2, MA-2 modifies object-1 instance to an unacceptable value for MA-1 usage of the resource. MA-1 does not know object-1 instance have been modified by MA-2 and tries to created object-2 instance and succeeds (notice the successful operation is a problem, it should have failed). When multiple MAs are used, it is never sure that the previously set up object instance by an MA is not changed/deleted by another MA. This may possibly be handled by specifying the detail access control for each object attributes with dynamic changes of which operation (read/write/create) by whom at what time. But this adds much complexity to the SNMPv3 usage. Are there better ways? 2. When the same resource (same instance of one or more objects) on the same MB is being changed/created by multiple MAs at the same time, how is this handled? Will a spin-lock be needed for this? How would this add to complexity? How can the result be deterministic when each MA is changing the object instance to a different value? Does these complexity require some additional investigation of HOW WELL the protocol meets the requirements? And will people use it this way given its complexity? Maybe we need to focus on solving the MIDCOM problem using each of the candidate protocols (may be one at a time or in parallel) before making the firm decision of picking a specific protocol. I think someone have indicated before on this list that the devil is in the details. Thanks! -- Kwok Ho Chan -- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 13 17:13:20 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 RAA07109 for ; Fri, 13 Dec 2002 17:13:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDMFrW15942 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 17:15:53 -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 gBDMFIv15912; Fri, 13 Dec 2002 17:15:18 -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 gBDMECv15866 for ; Fri, 13 Dec 2002 17:14:12 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07050 for ; Fri, 13 Dec 2002 17:11:08 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA02475 for ; Fri, 13 Dec 2002 17:26:16 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma002470; Fri, 13 Dec 02 17:25:35 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Fri, 13 Dec 2002 17:13:39 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 13 Dec 2002 17:13:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMPv3 and multiple MA requirement Date: Fri, 13 Dec 2002 17:13:38 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892C3@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] SNMPv3 and multiple MA requirement Thread-Index: AcKi5CwbxeBMhKueRLiPfVKKL8hQEgAB+GWQ From: "Harrington, David" To: "Kwok Ho Chan" , X-OriginalArrivalTime: 13 Dec 2002 22:13:39.0291 (UTC) FILETIME=[E388D2B0:01C2A2F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDMECv15867 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 Hi Kwok, The simple solution to coordinating mutliple managers trying to set information at the same time is to use an advisory lock. RFC1907: snmpSetSerialNo OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating command generator applications to coordinate their use of the SNMP set operation. This object is used for coarse-grain coordination. To achieve fine-grain coordination, one or more similar objects might be defined within each MIB group, as appropriate." ::= { snmpSet 1 } This is very coarse-grained and only advisory, however. Finer-grained control would probably be better in most cases, and mib-specific snmp-agent-enforced locks are more reliable and often simpler. For example, defining the owners of rows, as is done with RMON, can limit who can change which rows within a mib table. SNMP has one MIB that all MAs use, and it is composed of multiple mib modules. VACM has a complete knowledge of all the SNMP data manageable at the device, and VACM can be utilized to control, based on the administrator's preferences, which MAs have access to read or modify which portions of the MIB - by mib module, by table, and by row as needed. A well-designed mib solution will take access control into consideration. There are times when one must coordinate multiple values to ensure consistency. Many mibs have been written over the years that have successfully addressed such consistency issues. A well-designed mib module will take data dependencies into consideration, and describe the expected behavior and locking that should be supported. There are many ways to approach the coordination of multiple management applications, and such methods have been used successfully in SNMP environments for a number of years. dbh > -----Original Message----- > From: Kwok Ho Chan [mailto:khchan@nortelnetworks.com] > Sent: Friday, December 13, 2002 3:04 PM > To: midcom@ietf.org > Cc: Kwok Ho Chan > Subject: [midcom] SNMPv3 and multiple MA requirement > > > FYI! > If SNMPv3 (and assuming SMIv2 is used also) is used as the > MIDCOM protocol, > There are additional complexity when considering the usage of > multiple Middlebox Agents (MAs) with a Middlebox (MB). > > 1. When multiple MAs trying to control the same resource on > the MB, SNMPv3 > does not allow simple control of which MA performs SETs > to which object > instance in which order with deterministic results. > For example resource on MB is controlled by MA-1, MA-2, MA-3 > concurrently. > Resource is parameterized by object-1, object-2, > object-3. And they are > inter-related. > MA-1 created the object-1 instance needed for the resource. > Object-2 and object-3 must be created correctly before > the resource is > setup/allocated correctly. > Before MA-1 can create object-2, MA-2 modifies object-1 > instance to an > unacceptable value for MA-1 usage of the resource. > MA-1 does not know object-1 instance have been modified by MA-2 > and tries to created object-2 instance and succeeds (notice the > successful operation is a problem, it should have failed). > > When multiple MAs are used, it is never sure that the > previously set > up object instance by an MA is not changed/deleted by > another MA. > > This may possibly be handled by specifying the detail > access control > for each object attributes with dynamic changes of > which operation > (read/write/create) by whom at what time. > But this adds much complexity to the SNMPv3 usage. > Are there better ways? > > 2. When the same resource (same instance of one or more > objects) on the > same MB is being changed/created by multiple MAs at the > same time, > how is this handled? > Will a spin-lock be needed for this? How would this > add to complexity? > How can the result be deterministic when each MA is > changing the object > instance to a different value? > > Does these complexity require some additional investigation > of HOW WELL the > protocol meets the requirements? And will people use it this > way given its > complexity? > Maybe we need to focus on solving the MIDCOM problem using each of the > candidate protocols (may be one at a time or in parallel) > before making the > firm decision of picking a specific protocol. > I think someone have indicated before on this list that the > devil is in the > details. > > Thanks! > -- Kwok Ho Chan -- > > > _______________________________________________ > 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 Dec 13 17:44: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 RAA07913 for ; Fri, 13 Dec 2002 17:44:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDMkpq17678 for midcom-archive@odin.ietf.org; Fri, 13 Dec 2002 17:46:51 -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 gBDMhAv17565; Fri, 13 Dec 2002 17:43:10 -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 gBDMgxv17550 for ; Fri, 13 Dec 2002 17:42:59 -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 RAA07803 for ; Fri, 13 Dec 2002 17:39:54 -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 gBDMghI02506; Fri, 13 Dec 2002 17:42:43 -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 WZPABHQC; Fri, 13 Dec 2002 17:42:42 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.173]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W8HJ4PXD; Fri, 13 Dec 2002 17:42:40 -0500 Message-Id: <5.2.0.9.0.20021213172457.026f61d0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Dec 2002 17:40:18 -0500 To: "Harrington, David" From: Kwok Ho Chan Subject: RE: [midcom] SNMPv3 and multiple MA requirement Cc: "Kwok-Ho Chan" , In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA4892C3@NHROCMBX1.ets.enter asys.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: , Dave: Thanks! So the answer is not in SNMPv3 but in SMIv2 and MIBs, or how they work together. Some example with existing MIBs and the operational experience using them in situations similar to MIDCOM will be very helpful. The operational complexity will be determined when such exercise is done. -- Kwok -- At 05:13 PM 12/13/02 -0500, Harrington, David wrote: >Hi Kwok, > >The simple solution to coordinating mutliple managers trying to set >information at the same time is to use an advisory lock. > >RFC1907: >snmpSetSerialNo OBJECT-TYPE > SYNTAX TestAndIncr > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "An advisory lock used to allow several cooperating > command generator applications to coordinate their > use of the SNMP set operation. > > This object is used for coarse-grain coordination. > To achieve fine-grain coordination, one or more similar > objects might be defined within each MIB group, as > appropriate." > ::= { snmpSet 1 } > >This is very coarse-grained and only advisory, however. Finer-grained >control would probably be better in most cases, and mib-specific >snmp-agent-enforced locks are more reliable and often simpler. For >example, defining the owners of rows, as is done with RMON, can limit who >can change which rows within a mib table. > >SNMP has one MIB that all MAs use, and it is composed of multiple mib >modules. VACM has a complete knowledge of all the SNMP data manageable at >the device, and VACM can be utilized to control, based on the >administrator's preferences, which MAs have access to read or modify which >portions of the MIB - by mib module, by table, and by row as needed. A >well-designed mib solution will take access control into consideration. > >There are times when one must coordinate multiple values to ensure >consistency. Many mibs have been written over the years that have >successfully addressed such consistency issues. A well-designed mib module >will take data dependencies into consideration, and describe the expected >behavior and locking that should be supported. > >There are many ways to approach the coordination of multiple management >applications, and such methods have been used successfully in SNMP >environments for a number of years. > >dbh > > > -----Original Message----- > > From: Kwok Ho Chan [mailto:khchan@nortelnetworks.com] > > Sent: Friday, December 13, 2002 3:04 PM > > To: midcom@ietf.org > > Cc: Kwok Ho Chan > > Subject: [midcom] SNMPv3 and multiple MA requirement > > > > > > FYI! > > If SNMPv3 (and assuming SMIv2 is used also) is used as the > > MIDCOM protocol, > > There are additional complexity when considering the usage of > > multiple Middlebox Agents (MAs) with a Middlebox (MB). > > > > 1. When multiple MAs trying to control the same resource on > > the MB, SNMPv3 > > does not allow simple control of which MA performs SETs > > to which object > > instance in which order with deterministic results. > > For example resource on MB is controlled by MA-1, MA-2, MA-3 > > concurrently. > > Resource is parameterized by object-1, object-2, > > object-3. And they are > > inter-related. > > MA-1 created the object-1 instance needed for the resource. > > Object-2 and object-3 must be created correctly before > > the resource is > > setup/allocated correctly. > > Before MA-1 can create object-2, MA-2 modifies object-1 > > instance to an > > unacceptable value for MA-1 usage of the resource. > > MA-1 does not know object-1 instance have been modified by MA-2 > > and tries to created object-2 instance and succeeds (notice the > > successful operation is a problem, it should have failed). > > > > When multiple MAs are used, it is never sure that the > > previously set > > up object instance by an MA is not changed/deleted by > > another MA. > > > > This may possibly be handled by specifying the detail > > access control > > for each object attributes with dynamic changes of > > which operation > > (read/write/create) by whom at what time. > > But this adds much complexity to the SNMPv3 usage. > > Are there better ways? > > > > 2. When the same resource (same instance of one or more > > objects) on the > > same MB is being changed/created by multiple MAs at the > > same time, > > how is this handled? > > Will a spin-lock be needed for this? How would this > > add to complexity? > > How can the result be deterministic when each MA is > > changing the object > > instance to a different value? > > > > Does these complexity require some additional investigation > > of HOW WELL the > > protocol meets the requirements? And will people use it this > > way given its > > complexity? > > Maybe we need to focus on solving the MIDCOM problem using each of the > > candidate protocols (may be one at a time or in parallel) > > before making the > > firm decision of picking a specific protocol. > > I think someone have indicated before on this list that the > > devil is in the > > details. > > > > Thanks! > > -- Kwok Ho Chan -- > > > > > > _______________________________________________ > > 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 Sat Dec 14 16:19: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 QAA10339 for ; Sat, 14 Dec 2002 16:19:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBELLXS21897 for midcom-archive@odin.ietf.org; Sat, 14 Dec 2002 16:21:33 -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 gBELKov21885; Sat, 14 Dec 2002 16:20:53 -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 gBELJov21838 for ; Sat, 14 Dec 2002 16:19:50 -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 QAA10323 for ; Sat, 14 Dec 2002 16:16:47 -0500 (EST) Received: from cisco.com (sjc-vpn3-318.cisco.com [10.21.65.62]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBELJFjS007791; Sat, 14 Dec 2002 13:19:15 -0800 (PST) Message-ID: <3DFBA06B.7020505@cisco.com> Date: Sat, 14 Dec 2002 13:19:39 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: midcom@ietf.org Subject: Re: [midcom] key distribution References: <6D745637A7E0F94DA070743C55CDA9BA4892B0@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA4892B0@NHROCMBX1.ets.enterasys.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 Dave, thanks for your answer regarding key management, but are you aware of a single implementation that actually does key management that includes both SNMP and other mechanisms? I perceive a running code deficit precisely because of the difficulties you mentioned. Eliot _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Dec 14 21:27:37 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 VAA15882 for ; Sat, 14 Dec 2002 21:27:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBF2UBg02683 for midcom-archive@odin.ietf.org; Sat, 14 Dec 2002 21:30:11 -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 gBF2TNv02654; Sat, 14 Dec 2002 21:29:23 -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 gBF2SLv02628 for ; Sat, 14 Dec 2002 21:28:21 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15872 for ; Sat, 14 Dec 2002 21:25:16 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id VAA10205 for ; Sat, 14 Dec 2002 21:40:26 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma010199; Sat, 14 Dec 02 21:40:25 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Sat, 14 Dec 2002 21:28:27 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 14 Dec 2002 21:28:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] key distribution Date: Sat, 14 Dec 2002 21:28:26 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA4892C7@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] key distribution Thread-Index: AcKjtpW+whtWjAMbRaauIrVfp5B1gwACHh2Q From: "Harrington, David" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 15 Dec 2002 02:28:27.0229 (UTC) FILETIME=[A644C8D0:01C2A3E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBF2SLv02629 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 Hi Eliot, DOCSIS supports the Diffie=Hellman kickstart and then lets SNMPv3 do its own key distribution, as I understand it. Reports I have received as WG co-chair indicate it is in use in the cable industry. Wes Hardaker has stated that NET-SNMP supports Kerberos, so we apparently have running code. Rohit Aradhya has stated that the Packet Cable security spec supports Kerberos, although he didn't say if he knew of running code. I have not done a survey looking for running code or deployments for this. I might have found more instances, or not. I also don't know if anybody has deployed a Kerberos-based SNMPv3 solution in a real-world environment. dbh > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Saturday, December 14, 2002 4:20 PM > To: Harrington, David > Cc: midcom@ietf.org > Subject: Re: [midcom] key distribution > > > Dave, > > thanks for your answer regarding key management, but are you > aware of a > single implementation that actually does key management that includes > both SNMP and other mechanisms? I perceive a running code deficit > precisely because of the difficulties you mentioned. > > Eliot > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Dec 15 11:58: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 LAA06374 for ; Sun, 15 Dec 2002 11:58:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBFH1HW18895 for midcom-archive@odin.ietf.org; Sun, 15 Dec 2002 12:01:17 -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 gBFH0fv18841; Sun, 15 Dec 2002 12:00:41 -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 gBFGxdv18787 for ; Sun, 15 Dec 2002 11:59:39 -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 LAA06342 for ; Sun, 15 Dec 2002 11:56:36 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBFGxYFp028879 for ; Sun, 15 Dec 2002 08:59:34 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK45629; Sun, 15 Dec 2002 08:59:33 -0800 (PST) Message-Id: <200212151659.ABK45629@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Sun, 15 Dec 2002 11:59:30 -0500 Subject: [midcom] Scott Bradner: response from the IESG on stun 04 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: , Feedback on the most recent STUN draft - we're still in the woods on several issues. Melnda ------- Forwarded Message Date: Sat, 14 Dec 2002 09:36:34 -0500 From: Scott Bradner To: mshore@cisco.com Subject: response from the IESG on stun 04 to be shared with the list - ---- From paf@cisco.com Sat Dec 14 08:27:22 2002 Date: Sat, 14 Dec 2002 14:28:26 +0100 Subject: Re: Evaluation: draft-ietf-midcom-stun - STUN - Simple Traversal of U DP Through Network Address Translators to Proposed Standard Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: IESG To: Scott Bradner From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 14 Dec 2002 13:28:28.0905 (UTC) FILETIME=[B04B3D90:01C2A 374] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id gB EDRMnb026965 I can not remove my discuss yet. See below. On torsdag, okt 31, 2002, at 15:47 Europe/Stockholm, Patrik Fältström wrote: > Yes No-Objection Discuss * Abstain > > Patrik Faltstrom [ ] [ ] [ X ] [ ] > > Discuss: > > (1) I don't understand how this combination of RECOMMENDED and MUST is > to work together. > > 8.1 Binding Requests > > [...snip...] > > It is RECOMMENDED that the server check the Binding Request for a > MESSAGE-INTEGRITY attribute. If not present, and the server requires > integrity checks on the request, it MUST generate a Binding Error > Response with an ERROR-CODE attribute with class 400 and number 1. This is ok in version 04. > (2) Why not send an error message? Is there not a risk that a client > tries again, and again, and again... > > 8.2 Shared Secret Requests > > [...snip...] > > If the server receives a Shared Secret Request, it MUST verify that > the request arrived on a TLS connection. If not, it discards the > request. > > [...snip...] > > 9.1 Discovery > > [...snip...] > > For STUN requests, failure occurs if there is a transport failure of > some sort (generally, due to fatal ICMP errors in UDP or connection > failures in TCP). Failure also occurs if the the request does not > solicit a response after 30 seconds. If a failure occurs, the client > SHOULD create a new request, which is identical to the previous, but > has a different transaction ID. That request is sent to the next > element in the list as specified by RFC 2782. I still don't understand why not an error code is sent back in 8.2. > (3) Why not follow the FTP/SMTP idea of "families" or return codes, > where the first digit tell whether one has a temporary or complete > error, success, "need more data" etc? This below is incredibly > complicated, especially given the number of words, and imply > interoperability problems. Yes, classes are defined in 11.2.9 > ERROR-CODE, but I would prefer if the classes indicated "what to do > next" and not "where the error occurred". Further, section 11.2.9 > which is to be the authoritative source on what to do when error > messages are passed (I guess) doesn't say anything about when a new > request is to be sent. > > 9.4 Processing Binding Responses > > The response can either be a Binding Response or Binding Error > Response. > > If the response is a Binding Error Response, the client checks the > class and number from the ERROR-CODE attribute of the response. For > 400 class responses with error number 2, the client SHOULD obtain a > new shared secret, and retry the Binding Request with a new > transaction. For 400 class responses with error numbers 1 and 4, if > the client had omitted the USERNAME or MESSAGE-INTEGRITY attribute > as > indicated by the error, it SHOULD try again with those attributes. > For 400 class responses with error number 3, the client SHOULD alert > the user, and MAY try the request again after obtaining a new > username and password. For 400 class responses with unknown numbers, > the client should alert the user that there was an error, and > display > the reason phrase of the ERROR-CODE response. For 500 class > responses > with unknown numbers, the client SHOULD retry the Binding Request. > For 600 class responses with unknown numbers, the client SHOULD NOT > retry the request, and should inform the user of the failure using > the reason phrase. This is ok. One follow the SIP codes. > (4) Figure 2 is useful. Why not start the document with it to describe > the algorithm, and go from there? This is now part of the "examples" > part of the document, and not the protocol specification, which is > very unfortunate. Ok, i.e. I understand why the image is not moved. > (5) The end of this paragraph is weird. > > 11.2 Message Attributes > > [...snip...] > > Future extensions MAY define new attributes. If a STUN client or > server receives a message with an unknown attribute with a type > lower > than or equal to 0x7fff, the message MUST be discarded. If the type > is greater than 0x7fff, the attribute MUST be ignored. The ordering > of attributes within a message is not important (except that the > MESSAGE-INTEGRITY attribute MUST be the last attribute), and a > client The new paragraph is more weird now. I don't know what this means to an implementation: > Extensions, documented in standards track IETF RFCs, MAY define new > attributes. Attributes with values greater than 0x7fff are optional, > and those less than or equal to 0x7fff are mandatory to understand. "mandatory to understand"? Especially for codes which will be registered later. > (6) Also is section 11.2, why so many discarded messages? This will > force clients and servers to retry over and over again. Further, > saying types above 0x7ffff is to be discarded is weird. Is the idea > that those are _reserved_? (Which for me is a completely different > thing, today it smells like values above 0x7ffff is forbidden) > > The following types are defined: > > 0x0001: MAPPED-ADDRESS > 0x0002: RESPONSE-ADDRESS > 0x0003: FLAGS > 0x0004: SOURCE-ADDRESS > 0x0005: CHANGED-ADDRESS > 0x0006: USERNAME > 0x0007: PASSWORD > 0x0008: MESSAGE-INTEGRITY > 0x0009: ERROR-CODE > > Future extensions MAY define new attributes. If a STUN client or > server receives a message with an unknown attribute with a type > lower > than or equal to 0x7fff, the message MUST be discarded. If the type > is greater than 0x7fff, the attribute MUST be ignored. Ok (see (5) above). > (7) How is this to work over TLS? Is the server to open a new TLS > connection? > > 11.2.3 CHANGED-ADDRESS > > The CHANGED-ADDRESS attribute indicates the IP address and port of a > STUN server where responses will be sent from if the "change IP" and > "change port" flags were set in the Binding Request. I presume the new text is clear and understandable. So, Ok. > (8) Similar problems in other places. (a) How are extensions > registered? (b) Should not some bits be reserved for "future expansion > when we run out of bits"? Should not extensions be registered with > IANA? Using the IETF process? Vendor specific extensions? > > 11.2.4 FLAGS > > The FLAGS attribute is a series of boolean flags. It is 32 bits > long: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | |A|B|C| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Only three flags, A,B,C, are currently defined. The other bits MAY > be > used by extensions to define additional flags. Unknown flags are > ignored. > > [...snip...] > > 13 IANA Considerations > > There are no IANA considerations associated with this specification. I still think we have a registration issue here. Both regarding flags and extensions. Especially together with "mandatory to understand". paf ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Dec 15 16:26: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 QAA10209 for ; Sun, 15 Dec 2002 16:26:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBFLTU030583 for midcom-archive@odin.ietf.org; Sun, 15 Dec 2002 16:29:30 -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 gBFLPlv30529; Sun, 15 Dec 2002 16:25:47 -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 gBFLOWv30498 for ; Sun, 15 Dec 2002 16:24:32 -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 QAA10167 for ; Sun, 15 Dec 2002 16:21:27 -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 gBFLOBF77312; Sun, 15 Dec 2002 22:24:11 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.33] (unknown [192.168.102.33]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1D5187E6DF; Sun, 15 Dec 2002 22:21:32 +0100 (CET) Date: Sun, 15 Dec 2002 22:21:29 +0100 From: Juergen Quittek To: Kwok Ho Chan , "Harrington, David" Cc: midcom@ietf.org Subject: RE: [midcom] SNMPv3 and multiple MA requirement Message-ID: <36074943.1039990888@[192.168.102.33]> In-Reply-To: <5.2.0.9.0.20021213172457.026f61d0@zbl6c002.corpeast.baynetworks.com> References: <5.2.0.9.0.20021213172457.026f61d0@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, A part of your point 1 was alreay answered by the discussion on atomicity that David and I had. You can set several objects with a single SNMP packet and have them all set or none of them. This includes establishing or deleting a pinhole or a NAT binding atomically. Juergen -- Kwok Ho Chan wrote on 13 December 2002 17:40 -0500: > Dave: > Thanks! > So the answer is not in SNMPv3 but in SMIv2 and MIBs, or how they work together. > > Some example with existing MIBs and the operational experience using them in > situations similar to MIDCOM will be very helpful. > > The operational complexity will be determined when such exercise is done. > -- Kwok -- > > > At 05:13 PM 12/13/02 -0500, Harrington, David wrote: >> Hi Kwok, >> >> The simple solution to coordinating mutliple managers trying to set >> information at the same time is to use an advisory lock. >> >> RFC1907: >> snmpSetSerialNo OBJECT-TYPE >> SYNTAX TestAndIncr >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "An advisory lock used to allow several cooperating >> command generator applications to coordinate their >> use of the SNMP set operation. >> >> This object is used for coarse-grain coordination. >> To achieve fine-grain coordination, one or more similar >> objects might be defined within each MIB group, as >> appropriate." >> ::= { snmpSet 1 } >> >> This is very coarse-grained and only advisory, however. Finer-grained >> control would probably be better in most cases, and mib-specific >> snmp-agent-enforced locks are more reliable and often simpler. For >> example, defining the owners of rows, as is done with RMON, can limit who >> can change which rows within a mib table. >> >> SNMP has one MIB that all MAs use, and it is composed of multiple mib >> modules. VACM has a complete knowledge of all the SNMP data manageable at >> the device, and VACM can be utilized to control, based on the >> administrator's preferences, which MAs have access to read or modify which >> portions of the MIB - by mib module, by table, and by row as needed. A >> well-designed mib solution will take access control into consideration. >> >> There are times when one must coordinate multiple values to ensure >> consistency. Many mibs have been written over the years that have >> successfully addressed such consistency issues. A well-designed mib module >> will take data dependencies into consideration, and describe the expected >> behavior and locking that should be supported. >> >> There are many ways to approach the coordination of multiple management >> applications, and such methods have been used successfully in SNMP >> environments for a number of years. >> >> dbh >> >> > -----Original Message----- >> > From: Kwok Ho Chan [mailto:khchan@nortelnetworks.com] >> > Sent: Friday, December 13, 2002 3:04 PM >> > To: midcom@ietf.org >> > Cc: Kwok Ho Chan >> > Subject: [midcom] SNMPv3 and multiple MA requirement >> > >> > >> > FYI! >> > If SNMPv3 (and assuming SMIv2 is used also) is used as the >> > MIDCOM protocol, >> > There are additional complexity when considering the usage of >> > multiple Middlebox Agents (MAs) with a Middlebox (MB). >> > >> > 1. When multiple MAs trying to control the same resource on >> > the MB, SNMPv3 >> > does not allow simple control of which MA performs SETs >> > to which object >> > instance in which order with deterministic results. >> > For example resource on MB is controlled by MA-1, MA-2, MA-3 >> > concurrently. >> > Resource is parameterized by object-1, object-2, >> > object-3. And they are >> > inter-related. >> > MA-1 created the object-1 instance needed for the resource. >> > Object-2 and object-3 must be created correctly before >> > the resource is >> > setup/allocated correctly. >> > Before MA-1 can create object-2, MA-2 modifies object-1 >> > instance to an >> > unacceptable value for MA-1 usage of the resource. >> > MA-1 does not know object-1 instance have been modified by MA-2 >> > and tries to created object-2 instance and succeeds (notice the >> > successful operation is a problem, it should have failed). >> > >> > When multiple MAs are used, it is never sure that the >> > previously set >> > up object instance by an MA is not changed/deleted by >> > another MA. >> > >> > This may possibly be handled by specifying the detail >> > access control >> > for each object attributes with dynamic changes of >> > which operation >> > (read/write/create) by whom at what time. >> > But this adds much complexity to the SNMPv3 usage. >> > Are there better ways? >> > >> > 2. When the same resource (same instance of one or more >> > objects) on the >> > same MB is being changed/created by multiple MAs at the >> > same time, >> > how is this handled? >> > Will a spin-lock be needed for this? How would this >> > add to complexity? >> > How can the result be deterministic when each MA is >> > changing the object >> > instance to a different value? >> > >> > Does these complexity require some additional investigation >> > of HOW WELL the >> > protocol meets the requirements? And will people use it this >> > way given its >> > complexity? >> > Maybe we need to focus on solving the MIDCOM problem using each of the >> > candidate protocols (may be one at a time or in parallel) >> > before making the >> > firm decision of picking a specific protocol. >> > I think someone have indicated before on this list that the >> > devil is in the >> > details. >> > >> > Thanks! >> > -- Kwok Ho Chan -- >> > >> > >> > _______________________________________________ >> > 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 Dec 16 10:15: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 KAA07710 for ; Mon, 16 Dec 2002 10:15:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGFHn727028 for midcom-archive@odin.ietf.org; Mon, 16 Dec 2002 10:17:49 -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 gBGFDvv26887; Mon, 16 Dec 2002 10:13:58 -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 gBGFCGv26850 for ; Mon, 16 Dec 2002 10:12:16 -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 KAA07520 for ; Mon, 16 Dec 2002 10:09:15 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBGFBmjS006757 for ; Mon, 16 Dec 2002 07:11:48 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABL20105; Mon, 16 Dec 2002 07:12:11 -0800 (PST) Message-Id: <200212161512.ABL20105@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 16 Dec 2002 10:12:11 -0500 Subject: [midcom] STUN update needed 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 saw from the mail I forwarded over the weekend, the STUN draft did not pass IESG review this time, either. The problem is that the question of extensions is handled inconsistently throughout the document. In order to conform to both the spirit and the letter of the charter, as well as discussions with the ADs, we need to remove references to/ discussions of extensibility from the draft. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 16 17:13: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 RAA19916 for ; Mon, 16 Dec 2002 17:13:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGMGE019050 for midcom-archive@odin.ietf.org; Mon, 16 Dec 2002 17:16:14 -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 gBGMCUv18939; Mon, 16 Dec 2002 17:12:30 -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 gBGMBZv18915 for ; Mon, 16 Dec 2002 17:11:35 -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 RAA19874 for ; Mon, 16 Dec 2002 17:08:30 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBGMBSKv021227 for ; Mon, 16 Dec 2002 14:11:28 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABL57462; Mon, 16 Dec 2002 14:11:27 -0800 (PST) Message-Id: <200212162211.ABL57462@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 16 Dec 2002 17:11:27 -0500 Subject: [midcom] Scott Bradner: a suggested clarification on stun 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: , Another note on STUN. Melinda ------- Forwarded Message Date: Mon, 16 Dec 2002 09:58:39 -0500 From: Scott Bradner To: mshore@cisco.com Subject: a suggested clarification on stun From harald@alvestrand.no Mon Dec 16 09:57:20 2002 Date: Mon, 16 Dec 2002 15:58:20 +0100 From: Harald Tveit Alvestrand To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Scott Bradner Cc: IESG Subject: Re: Evaluation: draft-ietf-midcom-stun - STUN - Simple Traversal of UDP Through Network Address Translators to Proposed Standard In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id gB GEvJnb002124 - --On lørdag, desember 14, 2002 14:28:26 +0100 Patrik Fältström wrote: >> (5) The end of this paragraph is weird. >> >> 11.2 Message Attributes >> >> [...snip...] >> >> Future extensions MAY define new attributes. If a STUN client or >> server receives a message with an unknown attribute with a type >> lower >> than or equal to 0x7fff, the message MUST be discarded. If the type >> is greater than 0x7fff, the attribute MUST be ignored. The ordering >> of attributes within a message is not important (except that the >> MESSAGE-INTEGRITY attribute MUST be the last attribute), and a >> client > > The new paragraph is more weird now. I don't know what this means to an > implementation: > >> Extensions, documented in standards track IETF RFCs, MAY define new >> attributes. Attributes with values greater than 0x7fff are optional, >> and those less than or equal to 0x7fff are mandatory to understand. > > "mandatory to understand"? Especially for codes which will be registered > later. the high bit is a criticality flag. 0 = critical, 1 = non-critical. do not deliver service fi you don't understand a critical extension. ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 17 07:42: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 HAA12762 for ; Tue, 17 Dec 2002 07:42:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHCjFH08237 for midcom-archive@odin.ietf.org; Tue, 17 Dec 2002 07:45:15 -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 gBHCiLv08213; Tue, 17 Dec 2002 07:44:21 -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 gBHCh9v08170 for ; Tue, 17 Dec 2002 07:43:09 -0500 Received: from mailscanout256k.tataelxsi.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12717 for ; Tue, 17 Dec 2002 07:40:05 -0500 (EST) Message-ID: <01cc01c2a5ca$4427efc0$6828010a@manicoz> From: "Rahul Gulati" To: Cc: "Jonathan Rosenberg" , , , , , , References: <00e501c2a266$70287a20$6828010a@manicoz> Subject: Re: [midcom] Question on Session Descriptors! Date: Tue, 17 Dec 2002 18:16:04 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C9_01C2A5F8.5C8863F0" 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_01C9_01C2A5F8.5C8863F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am reposting this query as I didnt get response to the previous one. Would appreciate any help on this. I have a question on session descriptors: RFC 3303 Middlebox communication architecture and framework: Section 7.2 Page 19 SIP Phone SIP Proxy Middlebox SIP Phone (External) (MIDCOM agent) (NAPT (Private) IP Addr:Ea | Service) IP = addr:Pa | | IP addr:Ma = | | | | = | |----INVITE------->| | = | | | | = | |<---100Trying----| | = | | | | = | | |++ Query Port-BIND | | | | for (Ma, 5060) +++> | | | |<+ Port-BIND reply | = | | | for (Ma, 5060) ++++ | | | | | = | | |++ Query NAT Session | | | | Descriptor for | = | | | Ea-to-Pa SIP flow+> | | | |<+ Ea-to-Pa SIP flow | | | | Session Descriptor+ | | | | | = | In the example call flow, we query for session descriptors for Ea-to-Pa = SIP flow. =20 1) When is this session descriptor created? Since INVITE *hasn't* been received at the Private SIP phone and we are = querying for the session descriptor which has *already been created* ! =20 2) We also maintain sessions for RTP-RTCP based on parent session as SIP = control.What is the relationship between these two sessions? Best Regards' Rahul =20 ------=_NextPart_000_01C9_01C2A5F8.5C8863F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am reposting this query as I didnt = get response=20 to the previous one.
Would appreciate any help on = this.
 
I have a question on session=20 descriptors:
 
RFC 3303 Middlebox communication = architecture and=20 framework:
Section 7.2 Page 19
 
   SIP=20 Phone      SIP=20 Proxy           &n= bsp; =20 Middlebox     SIP = Phone
     =20 (External)     (MIDCOM=20 agent)        =20 (NAPT        =20 (Private)
      IP=20 Addr:Ea       =20 |            =       =20 Service)           = ;    =20 IP addr:Pa
     =20 |            =            | =             &= nbsp;    =20 IP=20 addr:Ma           =    =20 |
     =20 |            =            | =             &= nbsp;           &n= bsp;        =20 |            =  =20 |
     =20 |----INVITE------->|        &n= bsp;           &nb= sp;           &nbs= p; =20 |            =  =20 |
     =20 |            =           =20 |            =          =20             =20 |            =  =20 |
     =20 |<---100Trying----|        &nb= sp;           &nbs= p;=20             =20 |            =  =20 |
     =20 |            =           =20 |            =          =20             =20 |            =  =20 |
     =20 |            =           =20 |++ Query Port-BIND     =20 |            =  =20 |
     =20 |            =           =20 |   for (Ma, 5060) +++>  =20 |            =  =20 |
     =20 |            =           =20 |<+ Port-BIND reply       =20 |            =  =20 |
     =20 |            =           =20 |   for (Ma, 5060) ++++  =20 |            =  =20 |
     =20 |            =           =20 |            =             &= nbsp;          | &= nbsp;           =20 |
     =20 |            =           =20 |++ Query NAT Session =20 |            =  =20 |
     =20 |            =            | =  =20 Descriptor=20 for           &nbs= p; |          &nbs= p;  =20 |
     =20 |            =           =20 |   Ea-to-Pa SIP flow+>  =20 |            =  =20 |
     =20 |            =           =20 |<+ Ea-to-Pa SIP=20 flow     |      &n= bsp;      =20 |
     =20 |            =           =20 |   Session=20 Descriptor+   |       &= nbsp;     =20 |
     =20 |            =           =20 |            =             &= nbsp;          | &= nbsp;           =20 |
 
 
In the example call flow, we query for = session=20 descriptors for Ea-to-Pa SIP flow.
 
1)
When is this session descriptor=20 created?
Since INVITE *hasn't* = been=20 received at the Private SIP phone and we are querying for the = session=20 descriptor which has *already been created* = !
 
2)
We also maintain sessions for RTP-RTCP = based on=20 parent session as SIP control.What is the relationship between these two = sessions?
 
 
Best Regards'
Rahul
 
------=_NextPart_000_01C9_01C2A5F8.5C8863F0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 17 12:08:37 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 MAA17808 for ; Tue, 17 Dec 2002 12:08:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHHB9Q23403 for midcom-archive@odin.ietf.org; Tue, 17 Dec 2002 12:11:09 -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 gBHH7Mv23091; Tue, 17 Dec 2002 12:07:22 -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 gBHH5iv22349 for ; Tue, 17 Dec 2002 12:05:44 -0500 Received: from smtp016.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17620 for ; Tue, 17 Dec 2002 12:02:40 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Dec 2002 17:05:39 -0000 Reply-To: From: "Pyda Srisuresh" To: "Rahul Gulati" , Cc: "Jonathan Rosenberg" , , , , , Subject: RE: [midcom] Question on Session Descriptors! Date: Tue, 17 Dec 2002 09:09:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C2A5AB.F613D240" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <01cc01c2a5ca$4427efc0$6828010a@manicoz> 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_0081_01C2A5AB.F613D240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Rahul, Sorry, I didnt respond. I have been tied up with some personal matters at home. Will get back to you soon, in 2 days(by 12/18). Thanks for your understanding. cheers, suresh -----Original Message----- From: Rahul Gulati [mailto:rgulati@tataelxsi.co.in] Sent: Tuesday, December 17, 2002 4:46 AM To: midcom@ietf.org Cc: Jonathan Rosenberg; kuthan@fokus.fhg.de; amolitor@visi.com; rayhan@ee.ryerson.ca; ar_rayhan@yahoo.ca; mshore@cisco.com; srisuresh@yahoo.com Subject: Re: [midcom] Question on Session Descriptors! Hi, I am reposting this query as I didnt get response to the previous one. Would appreciate any help on this. I have a question on session descriptors: RFC 3303 Middlebox communication architecture and framework: Section 7.2 Page 19 SIP Phone SIP Proxy Middlebox SIP Phone (External) (MIDCOM agent) (NAPT (Private) IP Addr:Ea | Service) IP addr:Pa | | IP addr:Ma | | | | | |----INVITE------->| | | | | | | |<---100Trying----| | | | | | | | |++ Query Port-BIND | | | | for (Ma, 5060) +++> | | | |<+ Port-BIND reply | | | | for (Ma, 5060) ++++ | | | | | | | |++ Query NAT Session | | | | Descriptor for | | | | Ea-to-Pa SIP flow+> | | | |<+ Ea-to-Pa SIP flow | | | | Session Descriptor+ | | | | | | In the example call flow, we query for session descriptors for Ea-to-Pa SIP flow. 1) When is this session descriptor created? Since INVITE *hasn't* been received at the Private SIP phone and we are querying for the session descriptor which has *already been created* ! 2) We also maintain sessions for RTP-RTCP based on parent session as SIP control.What is the relationship between these two sessions? Best Regards' Rahul ------=_NextPart_000_0081_01C2A5AB.F613D240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Rahul,
 
Sorry,=20 I didnt respond.
I have=20 been tied up with some personal matters at home.
Will get back to you soon, in 2 = days(by 12/18).=20
Thanks=20 for your understanding.
 
cheers,
suresh
-----Original Message-----
From: Rahul Gulati=20 [mailto:rgulati@tataelxsi.co.in]
Sent: Tuesday, December 17, = 2002=20 4:46 AM
To: midcom@ietf.org
Cc: Jonathan = Rosenberg;=20 kuthan@fokus.fhg.de; amolitor@visi.com; rayhan@ee.ryerson.ca;=20 ar_rayhan@yahoo.ca; mshore@cisco.com; = srisuresh@yahoo.com
Subject:=20 Re: [midcom] Question on Session Descriptors!

Hi,
 
I am reposting this query as I didnt = get response=20 to the previous one.
Would appreciate any help on = this.
 
I have a question on session=20 descriptors:
 
RFC 3303 Middlebox communication = architecture and=20 framework:
Section 7.2 Page 19
 
   SIP=20 Phone      SIP=20 = Proxy           &n= bsp; =20 Middlebox     SIP = Phone
     =20 (External)     (MIDCOM=20 agent)        =20 (NAPT        =20 (Private)
      IP=20 Addr:Ea       =20 = |            =       =20 = Service)           = ;    =20 IP addr:Pa
     =20 = |            =            | =             &= nbsp;    =20 IP=20 = addr:Ma           =    =20 |
     =20 = |            =            | =             &= nbsp;           &n= bsp;        =20 = |            =  =20 |
     =20 = |----INVITE------->|        &n= bsp;           &nb= sp;           &nbs= p; =20 = |            =  =20 |
     =20 = |            =           =20 = |            =          =20             =20 = |            =  =20 |
     =20 = |<---100Trying----|        &nb= sp;           &nbs= p;=20             =20 = |            =  =20 |
     =20 = |            =           =20 = |            =          =20             =20 = |            =  =20 |
     =20 = |            =           =20 |++ Query Port-BIND     =20 = |            =  =20 |
     =20 = |            =           =20 |   for (Ma, 5060) +++>  =20 = |            =  =20 |
     =20 = |            =           =20 |<+ Port-BIND reply       =20 = |            =  =20 |
     =20 = |            =           =20 |   for (Ma, 5060) ++++  =20 = |            =  =20 |
     =20 = |            =           =20 = |            =             &= nbsp;          | &= nbsp;           =20 |
     =20 = |            =           =20 |++ Query NAT Session =20 = |            =  =20 |
     =20 = |            =            | =  =20 Descriptor=20 = for           &nbs= p; |          &nbs= p;  =20 |
     =20 = |            =           =20 |   Ea-to-Pa SIP flow+>  =20 = |            =  =20 |
     =20 = |            =           =20 |<+ Ea-to-Pa SIP=20 = flow     |      &n= bsp;      =20 |
     =20 = |            =           =20 |   Session=20 = Descriptor+   |       &= nbsp;     =20 |
     =20 = |            =           =20 = |            =             &= nbsp;          | &= nbsp;           =20 |
 
 
In the example call flow, we query = for session=20 descriptors for Ea-to-Pa SIP flow.
 
1)
When is this session descriptor=20 created?
Since INVITE *hasn't* = been=20 received at the Private SIP phone and we are querying for the = session=20 descriptor which has *already been created* = !
 
2)
We also maintain sessions for = RTP-RTCP based on=20 parent session as SIP control.What is the relationship between these = two=20 sessions?
 
 
Best Regards'
Rahul
 
------=_NextPart_000_0081_01C2A5AB.F613D240-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Dec 18 17:28: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 RAA20620 for ; Wed, 18 Dec 2002 17:28:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIMUoR02682 for midcom-archive@odin.ietf.org; Wed, 18 Dec 2002 17:30: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 gBIMO1v02464; Wed, 18 Dec 2002 17:24: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 gBIMMgv02427 for ; Wed, 18 Dec 2002 17:22:42 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20524 for ; Wed, 18 Dec 2002 17:19:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBIMMaYH019911; Wed, 18 Dec 2002 17:22:36 -0500 (EST) Message-ID: <3E00F529.1030103@dynamicsoft.com> Date: Wed, 18 Dec 2002 17:22:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org, =?ISO-8859-1?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Scott Bradner Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 References: <200212151659.ABK45629@mira-sjc5-c.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 some responses inline. Melinda Shore wrote: >>8.2 Shared Secret Requests >> >>[...snip...] >> >> If the server receives a Shared Secret Request, it MUST verify that >> the request arrived on a TLS connection. If not, it discards the >> request. >> >>[...snip...] >> >>9.1 Discovery >> >>[...snip...] >> >> For STUN requests, failure occurs if there is a transport failure of >> some sort (generally, due to fatal ICMP errors in UDP or connection >> failures in TCP). Failure also occurs if the the request does not >> solicit a response after 30 seconds. If a failure occurs, the client >> SHOULD create a new request, which is identical to the previous, but >> has a different transaction ID. That request is sent to the next >> element in the list as specified by RFC 2782. > > > I still don't understand why not an error code is sent back in 8.2. There are two STUN requests, the Binding Request and Shared Secret Request. I added responses for the Binding Request in all cases, basd on your comments, so that there is no retransmitted requests or confusion on the part of the client. For Shared Secret Requests (the case of 8.2), those requests MUST always be sent by a client over TLS. Thus, the case of receiving them over something besides TLS should never happen in a correct implementation. THus, an error response which basically says "your software is wrong" probably won't help. However, it can't hurt, and since it may stop retransmissions, it is worth adding. The text in 8.2 now reads: > If the server receives a Shared Secret Request, it MUST verify that > the request arrived on a TLS connection. If not, it MUST generate a > Shared Secret Error Response, and it MUST include an ERROR-CODE > attribute with a 433 response code. If the Shared Secret Request was > received over TCP, the Shared Secret Error Response > is sent over the same connection the request was received on. If the > Shared Secret Request was receive over UDP, the Shared Secret Error > Response is sent to the source IP address and port that the request > came from. >>(5) The end of this paragraph is weird. >> >>11.2 Message Attributes >> >>[...snip...] >> >> Future extensions MAY define new attributes. If a STUN client or >> server receives a message with an unknown attribute with a type >>lower >> than or equal to 0x7fff, the message MUST be discarded. If the type >> is greater than 0x7fff, the attribute MUST be ignored. The ordering >> of attributes within a message is not important (except that the >> MESSAGE-INTEGRITY attribute MUST be the last attribute), and a >>client > > > The new paragraph is more weird now. I don't know what this means to an > implementation: > > >> Extensions, documented in standards track IETF RFCs, MAY define new >> attributes. Attributes with values greater than 0x7fff are optional, >> and those less than or equal to 0x7fff are mandatory to understand. > > > "mandatory to understand"? Especially for codes which will be > registered later. Detailed semantics for this are provided in section 8.1, which has this to say for binding requests: > The server MUST check for any attributes in the request with values > less than or equal to 0x7fff which it does not understand. If it > encounters any, the server MUST generate a Binding Error Response, > and it MUST include an ERROR-CODE attribute with a 420 response code. > That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing > the attributes with values less than or equal to 0x7fff which were > not understood. The Binding Error Response is sent to the IP address > and port the Binding Request came from, and sent from the IP address > and port the Binding Request was sent to. and 8.2 for shared secret requests: > The server MUST check for any attributes in the request with values > less than or equal to 0x7fff which it does not understand. If it > encounters any, the server MUST generate a Shared Secret Error > Response, and it MUST include an ERROR-CODE attribute with a 420 > response code. That response MUST contain an UNKNOWN-ATTRIBUTES > attribute listing the attributes with values less than or equal to > 0x7fff which were not understood. The Shared Secret Error Response is > sent over the TLS connection. and 9.2 for shared secret responses: > If a client receives a Shared Secret Response with an attribute whose > type is greater than 0x7fff, the attribute MUST be ignored. If the > client receives a Shared Secret Response with an attribute whose type > is less than or equal to 0x7fff, the response is ignored. and 9.4 for binding responses: > If a client receives a response with an attribute whose type is > greater than 0x7fff, the attribute MUST be ignored. If the client > receives a response with an attribute whose type is less than or > equal to 0x7fff, request retransmissions MUST cease, but the entire > response is otherwise ignored. However, I will further clarify the text in the paragraph you point out. It now reads: > Extensions, documented in standards track IETF RFCs, MAY define new > attributes. Attributes with values greater than 0x7fff are optional, > which means that the message can be processed by the client or server > even though the attribute is not understood. Attributes with values > less than or equal to 0x7fff are mandatory to understand, which means > that the client or server cannot process the message unless it > understands the attribute. >>13 IANA Considerations >> >> There are no IANA considerations associated with this specification. > > > I still think we have a registration issue here. Both regarding flags > and extensions. Especially together with "mandatory to understand". To be clear, I have removed flag extensibility altogether (in fact, the attribute is no longer named FLAGS). SO, its just attributes. Anyway, the idea is that since we don't anticipate extensions, an IANA registry need not be set up at this time. However, if we do get any, we can create the registries at that time. I would propose the following new text for IANA considerations: > STUN can be extended by defining new attributes in standards track > extensions. However, since it is anticipated that no extensions will > be needed or defined, no IANA registry is to be created at this > time. Should an extension to STUN be defined, that extension can > establish any necessary registries. Do these changes address your concerns? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Dec 18 20:04: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 UAA23403 for ; Wed, 18 Dec 2002 20:04:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJ17NA10770 for midcom-archive@odin.ietf.org; Wed, 18 Dec 2002 20:07:23 -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 gBJ10dv10025; Wed, 18 Dec 2002 20:00:39 -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 gBJ0xSv09975 for ; Wed, 18 Dec 2002 19:59:28 -0500 Received: from smtp011.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23244 for ; Wed, 18 Dec 2002 19:56:18 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Dec 2002 00:59:18 -0000 Reply-To: From: "Pyda Srisuresh" To: "Rahul Gulati" , Cc: "Jonathan Rosenberg" , , , , , Subject: RE: [midcom] Question on Session Descriptors! Date: Wed, 18 Dec 2002 17:02:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C7_01C2A6B7.48D4D950" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <00e501c2a266$70287a20$6828010a@manicoz> 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_00C7_01C2A6B7.48D4D950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Rahul Gulati Sent: Thursday, December 12, 2002 9:14 PM To: midcom@ietf.org Cc: Jonathan Rosenberg; kuthan@fokus.fhg.de; amolitor@visi.com; rayhan@ee.ryerson.ca; ar_rayhan@yahoo.ca; mshore@cisco.com; srisuresh@yahoo.com Subject: [midcom] Question on Session Descriptors! Hi, All, I have a question on session descriptors. Refer to RFC 3303 Middlebox communication architecture and framework: Section 7.2 Page 19 SIP Phone SIP Proxy Middlebox SIP Phone (External) (MIDCOM agent) (NAPT (Private) IP Addr:Ea | Service) IP addr:Pa | | IP addr:Ma | | | | | |----INVITE------->| | | | | | | |<---100Trying----| | | | | | | | |++ Query Port-BIND | | | | for (Ma, 5060) +++> | | | |<+ Port-BIND reply | | | | for (Ma, 5060) ++++ | | | | | | | |++ Query NAT Session | | | | Descriptor for | | | | Ea-to-Pa SIP flow+> | | | |<+ Ea-to-Pa SIP flow | | | | Session Descriptor+ | | | | | | In the example call flow, we query for session descriptors for Ea-to-Pa SIP flow. 1) When is this session created? Since INVITE hasn't been received at the Private SIP phone and we are querying for the session descriptor which has already been created it wud be beneficial if the above point could be explained? [SURESH] The query is for the Ea to Pa SIP session descriptor. 2) We also maintain sessions for RTP-RTCP based on parent session as SIP control.What is the relationship between these two sessions? Is there any section in RFC 3303 which explains the same? [SURESH] Section 7.0 provides all the explanation necessary for the follow-on subsections. Best Regards' Rahul cheers, suresh ------=_NextPart_000_00C7_01C2A6B7.48D4D950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Rahul = Gulati
Sent:=20 Thursday, December 12, 2002 9:14 PM
To:=20 midcom@ietf.org
Cc: Jonathan Rosenberg; kuthan@fokus.fhg.de; = amolitor@visi.com; rayhan@ee.ryerson.ca; ar_rayhan@yahoo.ca; = mshore@cisco.com;=20 srisuresh@yahoo.com
Subject: [midcom] Question on Session=20 Descriptors!

Hi, All,
 
I have a question on session=20 descriptors.
 
Refer to RFC 3303 Middlebox = communication=20 architecture and framework:
Section 7.2 Page 19
 
   SIP=20 Phone      SIP=20 = Proxy           &n= bsp; =20 Middlebox     SIP = Phone
     =20 (External)     (MIDCOM=20 agent)        =20 (NAPT        =20 (Private)
      IP=20 Addr:Ea       =20 = |            =       =20 = Service)           = ;    =20 IP addr:Pa
     =20 = |            =            | =             &= nbsp;    =20 IP=20 = addr:Ma           =    =20 |
     =20 = |            =            | =             &= nbsp;           &n= bsp;        =20 = |            =  =20 |
     =20 = |----INVITE------->|        &n= bsp;           &nb= sp;           &nbs= p; =20 = |            =  =20 |
     =20 = |            =           =20 = |            =          =20             =20 = |            =  =20 |
     =20 = |<---100Trying----|        &nb= sp;           &nbs= p;=20             =20 = |            =  =20 |
     =20 = |            =           =20 = |            =          =20             =20 = |            =  =20 |
     =20 = |            =           =20 |++ Query Port-BIND     =20 = |            =  =20 |
     =20 = |            =           =20 |   for (Ma, 5060) +++>  =20 = |            =  =20 |
     =20 = |            =           =20 |<+ Port-BIND reply       =20 = |            =  =20 |
     =20 = |            =           =20 |   for (Ma, 5060) ++++  =20 = |            =  =20 |
     =20 = |            =           =20 = |            =             &= nbsp;          | &= nbsp;           =20 |
     =20 = |            =           =20 |++ Query NAT Session =20 = |            =  =20 |
     =20 = |            =            | =  =20 Descriptor=20 = for           &nbs= p; |          &nbs= p;  =20 |
     =20 = |            =           =20 |   Ea-to-Pa SIP flow+>  =20 = |            =  =20 |
     =20 = |            =           =20 |<+ Ea-to-Pa SIP=20 = flow     |      &n= bsp;      =20 |
     =20 = |            =           =20 |   Session=20 = Descriptor+   |       &= nbsp;     =20 |
     =20 = |            =           =20 = |            =             &= nbsp;          | &= nbsp;           =20 |
 
 
In the example call flow, we query = for session=20 descriptors for Ea-to-Pa SIP flow.
 
1)
When is this session created? =
Since INVITE hasn't been received at = the Private=20 SIP phone and we are querying for the session descriptor which = has=20 already been created it wud be beneficial if the above  point = could be=20 explained?
 
[SURESH] The query=20 is for the Ea to Pa SIP session descriptor. 
 
2)
We also maintain sessions for = RTP-RTCP based on=20 parent session as SIP control.What is the relationship between these = two=20 sessions?
 
Is there any section in RFC = 3303 which=20 explains the same? 
 
[SURESH] Section 7.0 provides all the = explanation=20 necessary for the follow-on
subsections. 
 
Best Regards'
Rahul
 
cheers,
suresh
 
------=_NextPart_000_00C7_01C2A6B7.48D4D950-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 19 09:46: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 JAA17141 for ; Thu, 19 Dec 2002 09:46:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJEnYb30578 for midcom-archive@odin.ietf.org; Thu, 19 Dec 2002 09:49: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 gBJEjgv30383; Thu, 19 Dec 2002 09:45:42 -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 gBJEi7v30310 for ; Thu, 19 Dec 2002 09:44:07 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16978 for ; Thu, 19 Dec 2002 09:40:52 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBJEhsYH020096; Thu, 19 Dec 2002 09:43:54 -0500 (EST) Message-ID: <3E01DB23.8000300@dynamicsoft.com> Date: Thu, 19 Dec 2002 09:43:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Melinda Shore , midcom@ietf.org, Scott Bradner Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 References: <19E50DCE-1317-11D7-9FAC-0003934B2128@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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 Patrik Fältström wrote: >> To be clear, I have removed flag extensibility altogether (in fact, >> the attribute is no longer named FLAGS). SO, its just attributes. >> Anyway, the idea is that since we don't anticipate extensions, an IANA >> registry need not be set up at this time. > > > The problem I have is that you in the previous issue above talk about > "Extensions, documented in standards track IETF RFCc, MAY define new > attributes. Attributes...". > > The document is not consistent. > >> However, if we do get any, we can create the registries at that time. >> I would propose the following new text for IANA considerations: >> >>> STUN can be extended by defining new attributes in standards track >>> extensions. However, since it is anticipated that no extensions will >>> be needed or defined, no IANA registry is to be created at this >>> time. Should an extension to STUN be defined, that extension can >>> establish any necessary registries. >> > > See above. I have problems with you talking about extensions, and in the > IANA considerations section claim no registry is needed. It is clearly > needed for attributes, given the text above. OK, so that leaves two choices: 1. allow extensibility and define an IANA registry, 2. disallow extensibility, state that protocol changes need to be affected by revising the specification, and then there is no need for an IANA registry. The attribute usage (criticial attributes < 0x7fff) would remain to handle the possibility of a specification revision. The group has been somewhat divided on extensibility. I will, therefore, make a concrete proposal: let us do option 2, disallow attribute extensibility through separate RFCs. The primary motivation for this is: 1. keep things simple 2. there is risk of the protocol being abused 3. if there are real needs or problems we can always revise the spec Comments? I'd like to reach closure on this one very quickly.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 19 09:49: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 JAA17187 for ; Thu, 19 Dec 2002 09:49:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJEqWr30688 for midcom-archive@odin.ietf.org; Thu, 19 Dec 2002 09:52:32 -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 gBJEn3v30544; Thu, 19 Dec 2002 09:49: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 gBJEmkv30518 for ; Thu, 19 Dec 2002 09:48:46 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17095 for ; Thu, 19 Dec 2002 09:45:30 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gBJEmT2w014404; Thu, 19 Dec 2002 09:48:29 -0500 (EST) Date: Thu, 19 Dec 2002 09:48:29 -0500 (EST) From: Scott Bradner Message-Id: <200212191448.gBJEmT2w014404@newdev.harvard.edu> To: jdrosen@dynamicsoft.com, paf@cisco.com Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 Cc: midcom@ietf.org, mshore@cisco.com, sob@harvard.edu In-Reply-To: <3E01DB23.8000300@dynamicsoft.com> 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: , that works for me ---- From jdrosen@dynamicsoft.com Thu Dec 19 09:44:09 2002 Date: Thu, 19 Dec 2002 09:43:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Melinda Shore , midcom@ietf.org, Scott Bradner Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 References: <19E50DCE-1317-11D7-9FAC-0003934B2128@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Patrik Fältström wrote: >> To be clear, I have removed flag extensibility altogether (in fact, >> the attribute is no longer named FLAGS). SO, its just attributes. >> Anyway, the idea is that since we don't anticipate extensions, an IANA >> registry need not be set up at this time. > > > The problem I have is that you in the previous issue above talk about > "Extensions, documented in standards track IETF RFCc, MAY define new > attributes. Attributes...". > > The document is not consistent. > >> However, if we do get any, we can create the registries at that time. >> I would propose the following new text for IANA considerations: >> >>> STUN can be extended by defining new attributes in standards track >>> extensions. However, since it is anticipated that no extensions will >>> be needed or defined, no IANA registry is to be created at this >>> time. Should an extension to STUN be defined, that extension can >>> establish any necessary registries. >> > > See above. I have problems with you talking about extensions, and in the > IANA considerations section claim no registry is needed. It is clearly > needed for attributes, given the text above. OK, so that leaves two choices: 1. allow extensibility and define an IANA registry, 2. disallow extensibility, state that protocol changes need to be affected by revising the specification, and then there is no need for an IANA registry. The attribute usage (criticial attributes < 0x7fff) would remain to handle the possibility of a specification revision. The group has been somewhat divided on extensibility. I will, therefore, make a concrete proposal: let us do option 2, disallow attribute extensibility through separate RFCs. The primary motivation for this is: 1. keep things simple 2. there is risk of the protocol being abused 3. if there are real needs or problems we can always revise the spec Comments? I'd like to reach closure on this one very quickly.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 19 10:21: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 KAA17804 for ; Thu, 19 Dec 2002 10:21:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJFNkl32382 for midcom-archive@odin.ietf.org; Thu, 19 Dec 2002 10:23: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 gBJFKCv32231; Thu, 19 Dec 2002 10:20: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 gBJF4hv31106 for ; Thu, 19 Dec 2002 10:04:43 -0500 Received: from ams-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 KAA17432 for ; Thu, 19 Dec 2002 10:01:27 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJF1rYI020100; Thu, 19 Dec 2002 16:02:44 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 19 Dec 2002 16:03:58 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 19 Dec 2002 16:03:57 +0100 Date: Thu, 19 Dec 2002 16:03:55 +0100 Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: jdrosen@dynamicsoft.com, midcom@ietf.org, mshore@cisco.com To: Scott Bradner From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <200212191448.gBJEmT2w014404@newdev.harvard.edu> Message-Id: <17D62424-1363-11D7-9FAC-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 19 Dec 2002 15:03:57.0849 (UTC) FILETIME=[DB137890:01C2A76F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBJF4hv31107 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 Works for me as well. paf On torsdag, dec 19, 2002, at 15:48 Europe/Stockholm, Scott Bradner wrote: > that works for me > > ---- > From jdrosen@dynamicsoft.com Thu Dec 19 09:44:09 2002 > Date: Thu, 19 Dec 2002 09:43:47 -0500 > From: Jonathan Rosenberg > Organization: dynamicsoft > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) > Gecko/20020826 > X-Accept-Language: en-us, en > MIME-Version: 1.0 > To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= > CC: Melinda Shore , midcom@ietf.org, > Scott Bradner > Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 > References: <19E50DCE-1317-11D7-9FAC-0003934B2128@cisco.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 8bit > > > > Patrik Fältström wrote: > >>> To be clear, I have removed flag extensibility altogether (in fact, >>> the attribute is no longer named FLAGS). SO, its just attributes. >>> Anyway, the idea is that since we don't anticipate extensions, an >>> IANA >>> registry need not be set up at this time. >> >> >> The problem I have is that you in the previous issue above talk about >> "Extensions, documented in standards track IETF RFCc, MAY define new >> attributes. Attributes...". >> >> The document is not consistent. >> >>> However, if we do get any, we can create the registries at that time. >>> I would propose the following new text for IANA considerations: >>> >>>> STUN can be extended by defining new attributes in standards track >>>> extensions. However, since it is anticipated that no extensions will >>>> be needed or defined, no IANA registry is to be created at this >>>> time. Should an extension to STUN be defined, that extension can >>>> establish any necessary registries. >>> >> >> See above. I have problems with you talking about extensions, and in >> the >> IANA considerations section claim no registry is needed. It is clearly >> needed for attributes, given the text above. > > OK, so that leaves two choices: > > > 1. allow extensibility and define an IANA registry, > 2. disallow extensibility, state that protocol changes need to be > affected by revising the specification, and then there is no need for > an > IANA registry. The attribute usage (criticial attributes < 0x7fff) > would > remain to handle the possibility of a specification revision. > > > The group has been somewhat divided on extensibility. I will, > therefore, > make a concrete proposal: let us do option 2, disallow attribute > extensibility through separate RFCs. The primary motivation for this > is: > > 1. keep things simple > 2. there is risk of the protocol being abused > 3. if there are real needs or problems we can always revise the spec > > Comments? > > I'd like to reach closure on this one very quickly.... > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 19 11: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 LAA19467 for ; Thu, 19 Dec 2002 11:38:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJGfA204768 for midcom-archive@odin.ietf.org; Thu, 19 Dec 2002 11:41:10 -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 gBJGeUv04746; Thu, 19 Dec 2002 11:40:30 -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 gBJGdMv04674 for ; Thu, 19 Dec 2002 11:39:22 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19447 for ; Thu, 19 Dec 2002 11:36:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBJGd8YH020152; Thu, 19 Dec 2002 11:39:08 -0500 (EST) Message-ID: <3E01F629.50901@dynamicsoft.com> Date: Thu, 19 Dec 2002 11:39:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Melinda Shore , midcom@ietf.org, Scott Bradner Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 References: <19E50DCE-1317-11D7-9FAC-0003934B2128@cisco.com> <3E01DB23.8000300@dynamicsoft.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 Just a followup on exactly what I meant by proposal (2) below. The specific text I would change is: OLD: Extensions, documented in standards track IETF RFCs, MAY define new attributes. Attributes with values greater than 0x7fff are optional, which means that the message can be processed by the client or server even though the attribute is not understood. Attributes with values less than or equal to 0x7fff are mandatory to understand, which means that the client or server cannot process the message unless it understands the attribute. NEW: To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into optional and mandatory ones. Attributes with values greater than 0x7fff are optional, which means that the message can be processed by the client or server even though the attribute is not understood. Attributes with values less than or equal to 0x7fff are mandatory to understand, which means that the client or server cannot process the message unless it understands the attribute. and OLD: \section{IANA Considerations} STUN can be extended by defining new attributes in standards track extensions. However, since it is anticipated that no extensions will be needed or defined, no IANA registry is to be created at this time. Should an extension to STUN be defined, that extension can establish any necessary registries. NEW: \section{IANA Considerations} STUN cannot be extended. Changes to the protocol are made through a standards track revision of this specification. As a result, no IANA registries are needed. -Jonathan R. Jonathan Rosenberg wrote: > > > 1. allow extensibility and define an IANA registry, > 2. disallow extensibility, state that protocol changes need to be > affected by revising the specification, and then there is no need for an > IANA registry. The attribute usage (criticial attributes < 0x7fff) would > remain to handle the possibility of a specification revision. > > > The group has been somewhat divided on extensibility. I will, therefore, > make a concrete proposal: let us do option 2, disallow attribute > extensibility through separate RFCs. The primary motivation for this is: > > 1. keep things simple > 2. there is risk of the protocol being abused > 3. if there are real needs or problems we can always revise the spec > > Comments? > > I'd like to reach closure on this one very quickly.... > > -Jonathan R. > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 19 11:44: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 LAA19628 for ; Thu, 19 Dec 2002 11:44:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJGlP304957 for midcom-archive@odin.ietf.org; Thu, 19 Dec 2002 11:47:25 -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 gBJGl5v04943; Thu, 19 Dec 2002 11:47:05 -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 gBJGkwv04927 for ; Thu, 19 Dec 2002 11:46:58 -0500 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 LAA19578 for ; Thu, 19 Dec 2002 11:43:43 -0500 (EST) 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, 19 Dec 2002 08:46:42 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Dec 2002 08:46:41 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 19 Dec 2002 08:46:41 -0800 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, 19 Dec 2002 08:46:41 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 19 Dec 2002 08:46:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Scott Bradner: response from the IESG on stun 04 Date: Thu, 19 Dec 2002 08:46:40 -0800 Message-ID: Thread-Topic: [midcom] Scott Bradner: response from the IESG on stun 04 Thread-Index: AcKnfhZ8Pm8mpxWFQ4W9CjPRArlzQQAABVsA From: "Christian Huitema" To: "Jonathan Rosenberg" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Melinda Shore" , , "Scott Bradner" X-OriginalArrivalTime: 19 Dec 2002 16:46:42.0176 (UTC) FILETIME=[354D2000:01C2A77E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBJGkwv04928 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 Works for me. Simplicity should always win. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, December 19, 2002 8:39 AM > To: Jonathan Rosenberg > Cc: Patrik Fältström; Melinda Shore; midcom@ietf.org; Scott Bradner > Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 > > Just a followup on exactly what I meant by proposal (2) below. The > specific text I would change is: > > OLD: > > Extensions, documented in standards track IETF RFCs, MAY define new > attributes. Attributes with values greater than 0x7fff are optional, > which means that the message can be processed by the client or server > even though the attribute is not understood. Attributes with values > less than or equal to 0x7fff are mandatory to understand, which means > that the client or server cannot process the message unless it > understands the attribute. > > NEW: > > To allow future revisions of this specification to add new attributes > if needed, the attribute space is divided into optional and mandatory > ones. Attributes with values greater than 0x7fff are optional, which > means that the message can be processed by the client or server even > though the attribute is not understood. Attributes with values less > than or equal to 0x7fff are mandatory to understand, which means that > the client or server cannot process the message unless it understands > the attribute. > > > and > > OLD: > > \section{IANA Considerations} > > STUN can be extended by defining new attributes in standards track > extensions. However, since it is anticipated that no extensions will > be needed or defined, no IANA registry is to be created at this > time. Should an extension to STUN be defined, that extension can > establish any necessary registries. > > NEW: > > \section{IANA Considerations} > > STUN cannot be extended. Changes to the protocol are made through a > standards track revision of this specification. As a result, no IANA > registries are needed. > > > -Jonathan R. > > Jonathan Rosenberg wrote: > > > > > > > 1. allow extensibility and define an IANA registry, > > 2. disallow extensibility, state that protocol changes need to be > > affected by revising the specification, and then there is no need for an > > IANA registry. The attribute usage (criticial attributes < 0x7fff) would > > remain to handle the possibility of a specification revision. > > > > > > The group has been somewhat divided on extensibility. I will, therefore, > > make a concrete proposal: let us do option 2, disallow attribute > > extensibility through separate RFCs. The primary motivation for this is: > > > > 1. keep things simple > > 2. there is risk of the protocol being abused > > 3. if there are real needs or problems we can always revise the spec > > > > Comments? > > > > I'd like to reach closure on this one very quickly.... > > > > -Jonathan R. > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 Dec 19 13:24: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 NAA22325 for ; Thu, 19 Dec 2002 13:24:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJIQsq11156 for midcom-archive@odin.ietf.org; Thu, 19 Dec 2002 13:26:54 -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 gBJINKv10955; Thu, 19 Dec 2002 13:23:20 -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 gBJIDcv10583 for ; Thu, 19 Dec 2002 13:13:38 -0500 Received: from ams-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 NAA21913 for ; Thu, 19 Dec 2002 13:10:21 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJIAxtO005071; Thu, 19 Dec 2002 19:11:37 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 19 Dec 2002 19:12:59 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 19 Dec 2002 19:12:59 +0100 Date: Thu, 19 Dec 2002 19:12:57 +0100 Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Melinda Shore , midcom@ietf.org, Scott Bradner To: Jonathan Rosenberg From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3E01F629.50901@dynamicsoft.com> Message-Id: <804EFBBB-137D-11D7-9FAC-0003934B2128@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 19 Dec 2002 18:12:59.0507 (UTC) FILETIME=[433B2430:01C2A78A] 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 Perfect according to my taste. paf On torsdag, dec 19, 2002, at 17:39 Europe/Stockholm, Jonathan Rosenberg wrote: > Just a followup on exactly what I meant by proposal (2) below. The > specific text I would change is: > > OLD: > > Extensions, documented in standards track IETF RFCs, MAY define new > attributes. Attributes with values greater than 0x7fff are optional, > which means that the message can be processed by the client or server > even though the attribute is not understood. Attributes with values > less than or equal to 0x7fff are mandatory to understand, which means > that the client or server cannot process the message unless it > understands the attribute. > > NEW: > > To allow future revisions of this specification to add new attributes > if needed, the attribute space is divided into optional and mandatory > ones. Attributes with values greater than 0x7fff are optional, which > means that the message can be processed by the client or server even > though the attribute is not understood. Attributes with values less > than or equal to 0x7fff are mandatory to understand, which means that > the client or server cannot process the message unless it understands > the attribute. > > > and > > OLD: > > \section{IANA Considerations} > > STUN can be extended by defining new attributes in standards track > extensions. However, since it is anticipated that no extensions will > be needed or defined, no IANA registry is to be created at this > time. Should an extension to STUN be defined, that extension can > establish any necessary registries. > > NEW: > > \section{IANA Considerations} > > STUN cannot be extended. Changes to the protocol are made through a > standards track revision of this specification. As a result, no IANA > registries are needed. > > > -Jonathan R. > > Jonathan Rosenberg wrote: > >> 1. allow extensibility and define an IANA registry, >> 2. disallow extensibility, state that protocol changes need to be >> affected by revising the specification, and then there is no need for >> an IANA registry. The attribute usage (criticial attributes < 0x7fff) >> would remain to handle the possibility of a specification revision. >> The group has been somewhat divided on extensibility. I will, >> therefore, make a concrete proposal: let us do option 2, disallow >> attribute extensibility through separate RFCs. The primary motivation >> for this is: >> 1. keep things simple >> 2. there is risk of the protocol being abused >> 3. if there are real needs or problems we can always revise the spec >> Comments? >> I'd like to reach closure on this one very quickly.... >> -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 20 18:52:15 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 SAA15628 for ; Fri, 20 Dec 2002 18:52:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKNtFc18218 for midcom-archive@odin.ietf.org; Fri, 20 Dec 2002 18:55:15 -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 gBKNpWv18152; Fri, 20 Dec 2002 18:51:35 -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 gBKNoxv18121 for ; Fri, 20 Dec 2002 18:50:59 -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 SAA15591 for ; Fri, 20 Dec 2002 18:47:29 -0500 (EST) 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 gBKNoVfm004114 for ; Fri, 20 Dec 2002 15:50:31 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-141-97.cisco.com [128.107.141.97]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id FSE00173; Fri, 20 Dec 2002 15:50:55 -0800 (PST) From: "Cullen Jennings" To: Subject: RE: [midcom] Scott Bradner: response from the IESG on stun 04 Date: Fri, 20 Dec 2002 15:50:28 -0800 Message-ID: <001101c2a882$932a6840$618d6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E01F629.50901@dynamicsoft.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBKNp0v18122 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 Looks great. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Thursday, December 19, 2002 8:39 AM > To: Jonathan Rosenberg > Cc: Patrik Fältström; Melinda Shore; midcom@ietf.org; Scott Bradner > Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04 > > > Just a followup on exactly what I meant by proposal (2) below. The > specific text I would change is: > > OLD: > > Extensions, documented in standards track IETF RFCs, MAY > define new attributes. Attributes with values greater than > 0x7fff are optional, which means that the message can be > processed by the client or server even though the attribute > is not understood. Attributes with values less than or equal > to 0x7fff are mandatory to understand, which means that the > client or server cannot process the message unless it > understands the attribute. > > NEW: > > To allow future revisions of this specification to add new > attributes if needed, the attribute space is divided into > optional and mandatory ones. Attributes with values greater > than 0x7fff are optional, which means that the message can be > processed by the client or server even though the attribute > is not understood. Attributes with values less than or equal > to 0x7fff are mandatory to understand, which means that the > client or server cannot process the message unless it > understands the attribute. > > > and > > OLD: > > \section{IANA Considerations} > > STUN can be extended by defining new attributes in standards > track extensions. However, since it is anticipated that no > extensions will be needed or defined, no IANA registry is to > be created at this time. Should an extension to STUN be > defined, that extension can establish any necessary registries. > > NEW: > > \section{IANA Considerations} > > STUN cannot be extended. Changes to the protocol are made > through a standards track revision of this specification. As > a result, no IANA registries are needed. > > > -Jonathan R. > > Jonathan Rosenberg wrote: > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 23 08:09:21 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 IAA29043 for ; Mon, 23 Dec 2002 08:09:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNDCoL09168 for midcom-archive@odin.ietf.org; Mon, 23 Dec 2002 08:12: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 gBNDC5v09137; Mon, 23 Dec 2002 08:12:05 -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 gBNCxev08083 for ; Mon, 23 Dec 2002 07:59:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27687; Mon, 23 Dec 2002 07:55:40 -0500 (EST) Message-Id: <200212231255.HAA27687@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: Mon, 23 Dec 2002 07:55:40 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-05.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-05.txt Pages : 47 Date : 2002-12-20 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-05.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-05.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-05.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-12-20130047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130047.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 23 09:02: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 JAA02728 for ; Mon, 23 Dec 2002 09:02:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNE6GK12902 for midcom-archive@odin.ietf.org; Mon, 23 Dec 2002 09:06:16 -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 gBNDxAv12412; Mon, 23 Dec 2002 08:59:10 -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 gBNDwdv12274 for ; Mon, 23 Dec 2002 08:58:39 -0500 Received: from jupiter.jmi.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01942 for ; Mon, 23 Dec 2002 08:54:37 -0500 (EST) Received: (qmail 13801 invoked by uid 525); 23 Dec 2002 22:58:35 +0900 Received: (qmail 13745 invoked from network); 23 Dec 2002 22:58:29 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 23 Dec 2002 22:58:29 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id XAA29417 for ; Mon, 23 Dec 2002 23:01:37 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QSEi-0003ks-00 for ietf-announce-list@ran.ietf.org; Mon, 23 Dec 2002 08:03:12 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QSBv-0003fh-00 for all-ietf@ran.ietf.org; Mon, 23 Dec 2002 08:00:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27687; Mon, 23 Dec 2002 07:55:40 -0500 (EST) Message-Id: <200212231255.HAA27687@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 23 Dec 2002 07:55:40 -0500 Precedence: bulk Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-05.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 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-05.txt Pages : 47 Date : 2002-12-20 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-05.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-05.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-05.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-12-20130047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130047.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 26 17:25: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 RAA16613 for ; Thu, 26 Dec 2002 17:25:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBQMUcc17373 for midcom-archive@odin.ietf.org; Thu, 26 Dec 2002 17:30: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 gBQMTvJ17338; Thu, 26 Dec 2002 17:29:57 -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 gBQMSIJ17284 for ; Thu, 26 Dec 2002 17:28:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16572; Thu, 26 Dec 2002 17:22:43 -0500 (EST) Message-Id: <200212262222.RAA16572@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , midcom@ietf.org From: The IESG Date: Thu, 26 Dec 2002 17:22:43 -0500 Subject: [midcom] Protocol Action: STUN - Simple Traversal of UDP Through Network Address Translators to Proposed Standard 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: , The IESG has approved the Internet-Draft 'STUN - Simple Traversal of UDP Through Network Address Translators' as a Proposed Standard. This document is the product of the Middlebox Communication Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document describes Simple Traversal of UDP Through NATs (STUN). STUN is a lightweight protocol that allows applications to discover the presenceand 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 types of 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. This protocol is not a cure-all for the problems associated with NATs. It does not enable incoming TCP connections through NAT. It allows incoming UDP packets through NAT, but only through a subset of existing NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs, which are common in large enterprises. STUN's discovery procedures are based on assumptions on NAT treatment of UDP; such assumptions may prove invalid down the road as new NAT devices are deployed. STUN is a simple client-server protocol. A client sends a request to a server on the Internet, and the server returns a response. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client. Working Group Summary The midcom working group supported publication of this document. Security issues raised during IETF last call have been addressed in the current revision of the document. Protocol Quality This document was review for the IESG by Scott Bradner and Eric Rescorla. The area directors know of recent interoperability testing among several servers and clients in pre-commercial state, where the functions of STUN were successfully tested against each of the NAT varieties currently targeted. RFC Editor Note: Please add the following sentence to the IANA Considerations section: "Any future extensions will establish any needed regsteries." _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Dec 26 18:04: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 SAA17132 for ; Thu, 26 Dec 2002 18:04:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBQN9ih19402 for midcom-archive@odin.ietf.org; Thu, 26 Dec 2002 18:09:44 -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 gBQN6FJ18710; Thu, 26 Dec 2002 18:06: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 gBQN5BJ18685 for ; Thu, 26 Dec 2002 18:05:11 -0500 Received: from jupiter.jmi.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17000 for ; Thu, 26 Dec 2002 17:59:35 -0500 (EST) Received: (qmail 28334 invoked by uid 525); 27 Dec 2002 08:03:45 +0900 Received: (qmail 28320 invoked from network); 27 Dec 2002 08:03:41 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 27 Dec 2002 08:03:41 +0900 Received: from ran.ietf.org ([132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id IAA26821 for ; Fri, 27 Dec 2002 08:06:50 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18RgV2-0004Zx-00 for ietf-announce-list@ran.ietf.org; Thu, 26 Dec 2002 17:29:08 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18RgU8-0004ZT-00 for all-ietf@ran.ietf.org; Thu, 26 Dec 2002 17:28:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16572; Thu, 26 Dec 2002 17:22:43 -0500 (EST) Message-Id: <200212262222.RAA16572@ietf.org> To: hangsang@dreamwiz.com Cc: RFC Editor , Internet Architecture Board , midcom@ietf.org From: The IESG Date: Thu, 26 Dec 2002 17:22:43 -0500 Precedence: bulk Subject: [midcom] Protocol Action: STUN - Simple Traversal of UDP Through Network Address Translators to Proposed Standard Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'STUN - Simple Traversal of UDP Through Network Address Translators' as a Proposed Standard. This document is the product of the Middlebox Communication Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document describes Simple Traversal of UDP Through NATs (STUN). STUN is a lightweight protocol that allows applications to discover the presenceand 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 types of 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. This protocol is not a cure-all for the problems associated with NATs. It does not enable incoming TCP connections through NAT. It allows incoming UDP packets through NAT, but only through a subset of existing NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs, which are common in large enterprises. STUN's discovery procedures are based on assumptions on NAT treatment of UDP; such assumptions may prove invalid down the road as new NAT devices are deployed. STUN is a simple client-server protocol. A client sends a request to a server on the Internet, and the server returns a response. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client. Working Group Summary The midcom working group supported publication of this document. Security issues raised during IETF last call have been addressed in the current revision of the document. Protocol Quality This document was review for the IESG by Scott Bradner and Eric Rescorla. The area directors know of recent interoperability testing among several servers and clients in pre-commercial state, where the functions of STUN were successfully tested against each of the NAT varieties currently targeted. RFC Editor Note: Please add the following sentence to the IANA Considerations section: "Any future extensions will establish any needed regsteries." _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Dec 27 12:57: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 MAA12107 for ; Fri, 27 Dec 2002 12:57:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBRI34917403 for midcom-archive@odin.ietf.org; Fri, 27 Dec 2002 13:03:04 -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 gBRI2VJ17331; Fri, 27 Dec 2002 13:02:32 -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 gBRI0FJ17242 for ; Fri, 27 Dec 2002 13:00:15 -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 MAA12008 for ; Fri, 27 Dec 2002 12:54:17 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBRHvNFp022654 for ; Fri, 27 Dec 2002 09:57:23 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABR31134; Fri, 27 Dec 2002 09:57:22 -0800 (PST) Message-Id: <200212271757.ABR31134@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 27 Dec 2002 12:57:22 -0500 Subject: [midcom] Eval document approved 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: , The midcom protocol evaluation document was approved by the IESG today. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 30 07:55: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 HAA23931 for ; Mon, 30 Dec 2002 07:55:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUD1sK00696 for midcom-archive@odin.ietf.org; Mon, 30 Dec 2002 08:01:54 -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 gBUCw5J00567; Mon, 30 Dec 2002 07:58: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 gBUCuWJ00517 for ; Mon, 30 Dec 2002 07:56:32 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23910 for ; Mon, 30 Dec 2002 07:49:08 -0500 (EST) Received: from fordcl1163 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H7X00GWQNLSFN@mta1.huawei.com> for midcom@ietf.org; Mon, 30 Dec 2002 20:49:06 +0800 (CST) Date: Mon, 30 Dec 2002 18:24:47 +0530 From: ford To: midcom@ietf.org Message-id: <002f01c2b002$a2c88a70$5403120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High Content-Transfer-Encoding: 7BIT Subject: [midcom] Consultation 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: ?? According to the milestone for MIDCOM, at the end of this year, ?????DEC 02????Submission of an existing protocol for use as midcom protocol? ? ????Would anyone tell me how about this progress on the foregoing ?aspect? ????Thanks in advance!! ????Best regards! ????????????????????????????? Yours: Ford Cheng _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 30 08:09: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 IAA24105 for ; Mon, 30 Dec 2002 08:09:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUDGQO01684 for midcom-archive@odin.ietf.org; Mon, 30 Dec 2002 08:16:26 -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 gBUDG5J01656; Mon, 30 Dec 2002 08:16:05 -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 gBUDEeJ01591 for ; Mon, 30 Dec 2002 08:14:40 -0500 Received: from mailscanout256k.tataelxsi.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24063 for ; Mon, 30 Dec 2002 08:07:20 -0500 (EST) Message-ID: <007301c2b005$3c96dc40$6828010a@manicoz> From: "Rahul Gulati" To: , Date: Mon, 30 Dec 2002 18:43:25 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C2B033.55FB04D0" Subject: [midcom] Unidirectional RTP! 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_006E_01C2B033.55FB04D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am investigating into how RTP can be addressed through NATs and = firewalls. Some of the solutions mention using bi-directional RTP. These need extensions to SDP, or using STUN/TURN where STUN clients = residing in SIP-end equipment will need to send a request to the STUN = server to get UDP NAT-bindings for RTP. I had a few questions: 1) Is it possible to use uni-directional RTP in any of the above = approaches? 2) If yes How?, Are there any sample call flows/drafts which I can refer = for the same? Would appreciate any help on this... Best Regards' Rahul ------=_NextPart_000_006E_01C2B033.55FB04D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I am investigating into how = RTP can be=20 addressed through NATs and firewalls.
 
Some of the solutions mention using = bi-directional=20 RTP.
These need extensions to SDP, = or using=20 STUN/TURN where STUN clients residing = in SIP-end=20 equipment will need to send a request to the STUN server to get UDP = NAT-bindings for RTP.
 
I had a few questions:
 
1) Is it=20 possible to use uni-directional = RTP in any=20 of the above approaches?
2) If yes How?, Are there any = sample call=20 flows/drafts which I can refer for the same?
 
Would appreciate any help on = this...
 
Best Regards'
Rahul
 
------=_NextPart_000_006E_01C2B033.55FB04D0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 30 08:52: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 IAA24478 for ; Mon, 30 Dec 2002 08:52:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUDxlp03473 for midcom-archive@odin.ietf.org; Mon, 30 Dec 2002 08:59:47 -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 gBUDuFJ03375; Mon, 30 Dec 2002 08:56: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 gBUDtKJ03349 for ; Mon, 30 Dec 2002 08:55:20 -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 IAA24415 for ; Mon, 30 Dec 2002 08:48:00 -0500 (EST) 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 gBUDp4w13393; Mon, 30 Dec 2002 08:51:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Dec 2002 08:51:04 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E0C8@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'ford'" , midcom@ietf.org Subject: RE: [midcom] Consultation Date: Mon, 30 Dec 2002 08:51:02 -0500 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: , The current candidate protocol, subject to rejection if it is actually found to be unsuitable, is SNMPv3. > -----Original Message----- > From: ford [mailto:chengzhengqun@huawei.com] > Sent: Monday, December 30, 2002 7:55 AM > To: midcom@ietf.org > Subject: [midcom] Consultation > Importance: High > > > Dear All: > ?? According to the milestone for MIDCOM, at the end of this year, > > ?????DEC 02????Submission of an existing protocol for use as > midcom protocol? ? ????Would anyone tell me how about this > progress on the foregoing ?aspect? ????Thanks in advance!! > ????Best regards! ????????????????????????????? Yours: Ford Cheng > > > > > _______________________________________________ > 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 Dec 30 10:40:28 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 KAA25747 for ; Mon, 30 Dec 2002 10:40:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUFlKv08898 for midcom-archive@odin.ietf.org; Mon, 30 Dec 2002 10:47:20 -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 gBUFhfJ08774; Mon, 30 Dec 2002 10:43:42 -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 gBUFgJJ08722 for ; Mon, 30 Dec 2002 10:42:19 -0500 Received: from smtp014.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25655 for ; Mon, 30 Dec 2002 10:34:56 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Dec 2002 15:38:04 -0000 Reply-To: From: "Pyda Srisuresh" To: "Rahul Gulati" , , Subject: RE: [midcom] Unidirectional RTP! Date: Mon, 30 Dec 2002 07:41:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C2AFD6.E8A16A70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <007301c2b005$3c96dc40$6828010a@manicoz> 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_000C_01C2AFD6.E8A16A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Well, the goal of the WG has been to come up with a MIDCOM protocol that would make RTP possible through NAT and firewall. regards, suresh -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Rahul Gulati Sent: Monday, December 30, 2002 5:13 AM To: midcom@ietf.org; sip-implementors@cs.columbia.edu Subject: [midcom] Unidirectional RTP! Hi, I am investigating into how RTP can be addressed through NATs and firewalls. Some of the solutions mention using bi-directional RTP. These need extensions to SDP, or using STUN/TURN where STUN clients residing in SIP-end equipment will need to send a request to the STUN server to get UDP NAT-bindings for RTP. I had a few questions: 1) Is it possible to use uni-directional RTP in any of the above approaches? 2) If yes How?, Are there any sample call flows/drafts which I can refer for the same? Would appreciate any help on this... Best Regards' Rahul ------=_NextPart_000_000C_01C2AFD6.E8A16A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well,=20 the goal of the WG has been to come up with a MIDCOM=20 protocol
that=20 would make RTP possible through NAT and firewall.
 
regards,
suresh
-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Rahul = Gulati
Sent:=20 Monday, December 30, 2002 5:13 AM
To: midcom@ietf.org;=20 sip-implementors@cs.columbia.edu
Subject: [midcom] = Unidirectional=20 RTP!

 
Hi,
 
I am investigating into how = RTP can be=20 addressed through NATs and firewalls.
 
Some of the solutions mention using=20 bi-directional RTP.
These need extensions to = SDP, or using=20 STUN/TURN where STUN clients = residing in=20 SIP-end equipment will need to send a request to the STUN server to=20 get UDP NAT-bindings for RTP.
 
I had a few questions:
 
1) Is it=20 possible to = use uni-directional RTP in any=20 of the above approaches?
2) If yes How?, Are there any = sample call=20 flows/drafts which I can refer for the same?
 
Would appreciate any help on = this...
 
Best Regards'
Rahul
 
------=_NextPart_000_000C_01C2AFD6.E8A16A70-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 30 13:14:28 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 NAA28706 for ; Mon, 30 Dec 2002 13:14:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUILOt18140 for midcom-archive@odin.ietf.org; Mon, 30 Dec 2002 13:21:24 -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 gBUIHfJ17929; Mon, 30 Dec 2002 13:17:43 -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 gBUIGAJ17861 for ; Mon, 30 Dec 2002 13:16:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28615; Mon, 30 Dec 2002 13:08:43 -0500 (EST) Message-Id: <200212301808.NAA28615@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , midcom@ietf.org From: The IESG Date: Mon, 30 Dec 2002 13:08:43 -0500 Subject: [midcom] Document Action: Middlebox Communications (MIDCOM) Protocol Evaluation to Informational 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: , The IESG has approved the Internet-Draft 'Middlebox Communications (MIDCOM) Protocol Evaluation' as an Informational RFC. This document is the product of the Middlebox Communication Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Dec 30 20:04: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 UAA04995 for ; Mon, 30 Dec 2002 20:04:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBV1BPa08661 for midcom-archive@odin.ietf.org; Mon, 30 Dec 2002 20:11:25 -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 gBV17HJ08416; Mon, 30 Dec 2002 20:07:18 -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 gBV16oJ07924 for ; Mon, 30 Dec 2002 20:06:50 -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 TAA04950 for ; Mon, 30 Dec 2002 19:59:17 -0500 (EST) 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 gBV12Sfm015366; Mon, 30 Dec 2002 17:02:28 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-141-97.cisco.com [128.107.141.97]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id GTZ00434; Mon, 30 Dec 2002 17:02:53 -0800 (PST) From: "Cullen Jennings" To: "'Rahul Gulati'" , Subject: RE: [midcom] Unidirectional RTP! Date: Mon, 30 Dec 2002 17:02:23 -0800 Message-ID: <017301c2b068$46fc6a70$3dd16b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0174_01C2B025.38D92A70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <007301c2b005$3c96dc40$6828010a@manicoz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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_0174_01C2B025.38D92A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think that STUN will work the same with unidirectional RTP as it does with bidirectional RTP (that is to say it will work with man NATs but not all) -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Rahul Gulati Sent: Monday, December 30, 2002 5:13 AM To: midcom@ietf.org; sip-implementors@cs.columbia.edu Subject: [midcom] Unidirectional RTP! Hi, I am investigating into how RTP can be addressed through NATs and firewalls. Some of the solutions mention using bi-directional RTP. These need extensions to SDP, or using STUN/TURN where STUN clients residing in SIP-end equipment will need to send a request to the STUN server to get UDP NAT-bindings for RTP. I had a few questions: 1) Is it possible to use uni-directional RTP in any of the above approaches? 2) If yes How?, Are there any sample call flows/drafts which I can refer for the same? Would appreciate any help on this... Best Regards' Rahul ------=_NextPart_000_0174_01C2B025.38D92A70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 think that STUN will work the same with unidirectional RTP as it does = with=20 bidirectional RTP (that is to say it will work with man NATs but not=20 all)
 
-----Original Message-----
From:=20 midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of = Rahul=20 Gulati
Sent: Monday, December 30, 2002 5:13 AM
To: = midcom@ietf.org; sip-implementors@cs.columbia.edu
Subject: = [midcom]=20 Unidirectional RTP!

 
Hi,
 
I am investigating into how = RTP can be=20 addressed through NATs and firewalls.
 
Some of the solutions mention using=20 bi-directional RTP.
These need extensions to = SDP, or using=20 STUN/TURN where STUN clients = residing in=20 SIP-end equipment will need to send a request to the STUN server to=20 get UDP NAT-bindings for RTP.
 
I had a few questions:
 
1) Is it=20 possible to = use uni-directional RTP in any=20 of the above approaches?
2) If yes How?, Are there any = sample call=20 flows/drafts which I can refer for the same?
 
Would appreciate any help on = this...
 
Best Regards'
Rahul
 
------=_NextPart_000_0174_01C2B025.38D92A70-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 31 00:33:21 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 AAA08357 for ; Tue, 31 Dec 2002 00:33:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBV5eUs20953 for midcom-archive@odin.ietf.org; Tue, 31 Dec 2002 00:40:30 -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 gBV5alJ20222; Tue, 31 Dec 2002 00:36:47 -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 gBV5ZYJ20188 for ; Tue, 31 Dec 2002 00:35:34 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08256 for ; Tue, 31 Dec 2002 00:27:54 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBV5UvYH024017; Tue, 31 Dec 2002 00:30:59 -0500 (EST) Message-ID: <3E112B8D.5010903@dynamicsoft.com> Date: Tue, 31 Dec 2002 00:30:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rahul Gulati CC: midcom@ietf.org, sip-implementors@cs.columbia.edu References: <007301c2b005$3c96dc40$6828010a@manicoz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: [Sip-implementors] Unidirectional RTP! 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 inline. Rahul Gulati wrote: > > Hi, > > I am investigating into how RTP can be addressed through NATs and firewalls. > > Some of the solutions mention using bi-directional RTP. I think perhaps you mean what has been called "symmetric RTP", where one side sends media to the source IP/port where it received media from the other side. > These need extensions to SDP, or using STUN/TURN where STUN clients > residing in SIP-end equipment will need to send a request to the STUN > server to get UDP NAT-bindings for RTP. The usage of STUN is orthogonal to symmetric RTP. If you use symmetric RTP, and both sides are behind NAT, only one side needs to use STUN. With regular RTP its both. > > I had a few questions: > > 1) Is it possible to use uni-directional RTP in any of the above approaches? If you define "uni-directional RTP" as RTP where each side sends RTP to the IP/port advertised by the other side in SDP, then you can use that RTP along with stun of course. > 2) If yes How?, Are there any sample call flows/drafts which I can refer > for the same? The current repository of SIP/nat related flows is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt its a bit out of date, but should prove a good start. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Dec 31 07:36:56 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 HAA22472 for ; Tue, 31 Dec 2002 07:36:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVCiDR19423 for midcom-archive@odin.ietf.org; Tue, 31 Dec 2002 07:44:13 -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 gBVCeXJ19340; Tue, 31 Dec 2002 07:40:33 -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 gBVCdrJ19291 for ; Tue, 31 Dec 2002 07:39:53 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22416 for ; Tue, 31 Dec 2002 07:31:14 -0500 (EST) Received: from fordcl1163 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H7Z002F1HF5YT@mta1.huawei.com> for midcom@ietf.org; Tue, 31 Dec 2002 20:30:43 +0800 (CST) Date: Tue, 31 Dec 2002 18:06:22 +0530 From: ford Subject: RE: [midcom] Consultation In-reply-to: <4D79C746863DD51197690002A52CDA000400E0C8@zcard0kc.ca.nortel.com> To: "'Tom-PT Taylor'" , midcom@ietf.org Message-id: <000801c2b0c9$3aa03c50$5403120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High 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 Then when will the guideline for SNMPV3 as MIDCOM be put forwarded? Thanks a lot! Best regards! Yours: Ford Cheng -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Tom-PT Taylor Sent: Monday, December 30, 2002 7:21 PM To: 'ford'; midcom@ietf.org Subject: RE: [midcom] Consultation The current candidate protocol, subject to rejection if it is actually found to be unsuitable, is SNMPv3. > -----Original Message----- > From: ford [mailto:chengzhengqun@huawei.com] > Sent: Monday, December 30, 2002 7:55 AM > To: midcom@ietf.org > Subject: [midcom] Consultation > Importance: High > > > Dear All: > ?? According to the milestone for MIDCOM, at the end of this year, > > ?????DEC 02????Submission of an existing protocol for use as > midcom protocol? ? ????Would anyone tell me how about this > progress on the foregoing ?aspect? ????Thanks in advance!! > ????Best regards! ????????????????????????????? Yours: Ford Cheng > > > > > _______________________________________________ > 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