Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VJc4nS024133 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 31 Mar 2004 21:38:05 +0200 Received: from ccsrlt06.ee.surrey.ac.uk ([131.227.89.156] ident=root) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1B8lXB-0001M3-00 for nmrg@ibr.cs.tu-bs.de; Wed, 31 Mar 2004 20:37:57 +0100 Received: from ee.surrey.ac.uk (ees2gp@localhost) by ccsrlt06.ee.surrey.ac.uk (8.11.6/8.9.3) with ESMTP id i2VJbv416258 for ; Wed, 31 Mar 2004 20:37:57 +0100 Message-Id: <200403311937.i2VJbv416258@ccsrlt06.ee.surrey.ac.uk> X-Authentication-Warning: ccsrlt06.ee.surrey.ac.uk: ees2gp owned process doing -bs To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] 16th meeting page created/updated In-Reply-To: Message from Juergen Schoenwaelder of "Wed, 31 Mar 2004 14:35:40 +0200." <20040331123540.GH7193@iu-bremen.de> Date: Wed, 31 Mar 2004 20:37:56 +0100 From: George Pavlou X-Spam-Status: No, hits=-101.4 required=5.5 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST, X_AUTH_WARNING version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1B8lXB-0001M3-00*8X4//qneTK6* (SECM, UniS) X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen, John, et al, >> And for the record, I disagreed with more than just the information and >> data modeling directions. > > I have created/updated the web page for our meeting in Seoul. > http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/seoul/ I think an additional agenda item on NetConf, its direction and views by participants would be interesting. Rgs, -George Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VCaE47026306 for ; Wed, 31 Mar 2004 14:36:14 +0200 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by merkur.iu-bremen.de (Postfix) with ESMTP id 3884289622; Wed, 31 Mar 2004 14:36:14 +0200 (CEST) Received: from merkur.iu-bremen.de ([212.201.44.27]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 21513-07; Wed, 31 Mar 2004 14:36:13 +0200 (CEST) Received: from james.eecs.iu-bremen.de (unknown [212.201.46.228]) by merkur.iu-bremen.de (Postfix) with ESMTP id BA22789626; Wed, 31 Mar 2004 14:36:12 +0200 (CEST) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4EE2E888C; Wed, 31 Mar 2004 14:29:44 +0200 (CEST) Date: Wed, 31 Mar 2004 14:29:44 +0200 From: Juergen Schoenwaelder To: John Strassner Cc: George Pavlou , Aiko Pras , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meeting in Seoul next to NOMS Message-ID: <20040331122944.GG7193@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: John Strassner , George Pavlou , Aiko Pras , nmrg@ibr.cs.tu-bs.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Tue, Mar 30, 2004 at 06:35:29PM -0700, John Strassner wrote: > I will be there as well. I think we should try and address some > fundamental concerns in NetConf, but then again, I'm not sure that this > will be productive. Getting an understanding what the various concerns are would probably be a step forward in our understanding of this new protocol. We should not even try to improve netconf in an NMRG meeting since netconf really is an IETF activity. But understanding netconf and the issues around it, also in the perspective of other work done in this space, is I think a good think and worth to spend time on. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VCa847026276 for ; Wed, 31 Mar 2004 14:36:08 +0200 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by merkur.iu-bremen.de (Postfix) with ESMTP id 162B189626 for ; Wed, 31 Mar 2004 14:36:08 +0200 (CEST) Received: from merkur.iu-bremen.de ([212.201.44.27]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 21504-07 for ; Wed, 31 Mar 2004 14:36:07 +0200 (CEST) Received: from james.eecs.iu-bremen.de (unknown [212.201.46.228]) by merkur.iu-bremen.de (Postfix) with ESMTP id 6BC6889622 for ; Wed, 31 Mar 2004 14:36:06 +0200 (CEST) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 5DCF2888D; Wed, 31 Mar 2004 14:35:40 +0200 (CEST) Date: Wed, 31 Mar 2004 14:35:40 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20040331123540.GH7193@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] 16th meeting page created/updated Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I have created/updated the web page for our meeting in Seoul. http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/seoul/ There is a tentative agenda now which still might change as things mature. Note that people from James' group want to present some evaluations they have done on scalability and performace aspects of xml-based management approaches, which I think fits nicely into discussions we had at previous meetings. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from COSIUM03.intelliden.net (cosium03.intelliden.net [12.41.186.100]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VC6j47012528 for ; Wed, 31 Mar 2004 14:06:45 +0200 Content-class: urn:content-classes:message Subject: RE: [nmrg] meeting in Seoul next to NOMS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Mar 2004 05:06:42 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] meeting in Seoul next to NOMS thread-index: AcQWQLEx/0xIgbktRpSvZWtTGOa/WgAHqu/gAB8HkgAADzBFAA== From: "John Strassner" To: "Harrington, David" , "George Pavlou" , "Aiko Pras" Cc: , X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id i2VC6j47012528 Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hmmm, I always thought that NMRG was about management, and that throwing a fresh perspective on things might actually help an active working group. And for the record, I disagreed with more than just the information and data modeling directions. regards, John Strassner TeleManagement Forum Advisory Director John Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: Tuesday, March 30, 2004 9:58 PM > To: John Strassner; George Pavlou; Aiko Pras > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > Subject: RE: [nmrg] meeting in Seoul next to NOMS > > > Hi, > > I disagree that the NMRG should try to address fundamental > concerns in NetConf. I am aware that you disagree with some > of the positions of the Netconf leaders regarding the > information/data modeling questions. > > NMRG is part of the IRTF - the Internet **Research** Task > Force - and should be focused on research. It should NOT be > focused on trying to influence directions of active working > groups in the IETF. Discussions of the directions of IETF WGs > such as NetConf should be held in the working groups of the > IETF, not in the IRTF. > > dbh > > > -----Original Message----- > > From: nmrg-admin@ibr.cs.tu-bs.de > > [mailto:nmrg-admin@ibr.cs.tu-bs.de] On Behalf Of John Strassner > > Sent: Tuesday, March 30, 2004 8:35 PM > > To: George Pavlou; Aiko Pras > > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > > Subject: RE: [nmrg] meeting in Seoul next to NOMS > > > > I will be there as well. I think we should try and address some > > fundamental concerns in NetConf, but then again, I'm not sure that > > this will be productive. > > > > regards, > > John Strassner > > TeleManagement Forum Advisory Director > > > > > > John Strassner > > Chief Strategy Officer > > Intelliden Inc. > > 90 South Cascade Avenue > > Colorado Springs, CO 80906 USA > > phone: +1.719.785.0648 > > fax: +1.719.785.0644 > > email: john.strassner@intelliden.com > > > > > > > > > -----Original Message----- > > > From: nmrg-admin@ibr.cs.tu-bs.de > > [mailto:nmrg-admin@ibr.cs.tu-bs.de] > > > Sent: Tuesday, March 30, 2004 3:19 AM > > > To: Aiko Pras > > > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > > > Subject: Re: [nmrg] meeting in Seoul next to NOMS > > > > > > > > > > > > > As you know, I will be in Seoul and will be able to > > attend. I would > > > > love > > > > to have (yet again) some discussion on how to use web > > services for > > > > management, but I'm afraid I'll have little time to prepair > > > something. > > > > > > I will be there as well (I arrive on Saturday), so I could be > > > involved in another discussion on the topic (but have no > > new material > > > since what I presented in Bremen). > > > > > > Regards, > > > -George > > > > > > -- > > > !! This message is brought to you via the `nmrg' mailing > > > list. !! Please do not reply to this message to unsubscribe. > > > To unsubscribe or adjust !! your settings, send a mail > > > message to !! or look at > > https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > > > -- > > !! This message is brought to you via the `nmrg' mailing list. > > !! Please do not reply to this message to unsubscribe. To > > unsubscribe or adjust > > !! your settings, send a mail message to > > > > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > > > > Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VAau47031141 for ; Wed, 31 Mar 2004 12:36:57 +0200 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id i2VAamCi013360; Wed, 31 Mar 2004 12:36:49 +0200 (MET DST) Received: from ctit.utwente.nl (utip250 [130.89.12.39]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id i2VAabl6003404; Wed, 31 Mar 2004 12:36:37 +0200 (MEST) Message-ID: <406A9F36.7080300@ctit.utwente.nl> Date: Wed, 31 Mar 2004 12:36:38 +0200 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Harrington, David" CC: John Strassner , George Pavlou , Aiko Pras , j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meeting in Seoul next to NOMS References: <6D745637A7E0F94DA070743C55CDA9BA017E1060@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA017E1060@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.67, clamav-milter version 0.66n X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi David I agree with you that the NMRG should not try to "influence directions of active working groups in the IETF". I'm sure, however, that we will not do that. Aiko Harrington, David wrote: > Hi, > > I disagree that the NMRG should try to address fundamental concerns in > NetConf. I am aware that you disagree with some of the positions of the > Netconf leaders regarding the information/data modeling questions. > > NMRG is part of the IRTF - the Internet **Research** Task Force - and > should be focused on research. It should NOT be focused on trying to > influence directions of active working groups in the IETF. Discussions > of the directions of IETF WGs such as NetConf should be held in the > working groups of the IETF, not in the IRTF. > > dbh > > >>-----Original Message----- >>From: nmrg-admin@ibr.cs.tu-bs.de >>[mailto:nmrg-admin@ibr.cs.tu-bs.de] On Behalf Of John Strassner >>Sent: Tuesday, March 30, 2004 8:35 PM >>To: George Pavlou; Aiko Pras >>Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de >>Subject: RE: [nmrg] meeting in Seoul next to NOMS >> >>I will be there as well. I think we should try and address some >>fundamental concerns in NetConf, but then again, I'm not sure >>that this >>will be productive. >> >>regards, >>John Strassner >>TeleManagement Forum Advisory Director >> >> >>John Strassner >>Chief Strategy Officer >>Intelliden Inc. >>90 South Cascade Avenue >>Colorado Springs, CO 80906 USA >>phone: +1.719.785.0648 >> fax: +1.719.785.0644 >>email: john.strassner@intelliden.com >> >> >> >> >>>-----Original Message----- >>>From: nmrg-admin@ibr.cs.tu-bs.de >> >>[mailto:nmrg-admin@ibr.cs.tu-bs.de] >> >>>Sent: Tuesday, March 30, 2004 3:19 AM >>>To: Aiko Pras >>>Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de >>>Subject: Re: [nmrg] meeting in Seoul next to NOMS >>> >>> >>> >>> >>>>As you know, I will be in Seoul and will be able to >> >>attend. I would >> >>>>love >>>>to have (yet again) some discussion on how to use web >> >>services for >> >>>>management, but I'm afraid I'll have little time to prepair >>> >>>something. >>> >>>I will be there as well (I arrive on Saturday), so I could be >>>involved in another discussion on the topic (but have no >> >>new material >> >>>since what I presented in Bremen). >>> >>>Regards, >>>-George >>> >>>-- >>>!! This message is brought to you via the `nmrg' mailing >>>list. !! Please do not reply to this message to unsubscribe. >>>To unsubscribe or adjust !! your settings, send a mail >>>message to !! or look at >> >>https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. >> >>-- >>!! This message is brought to you via the `nmrg' mailing list. >>!! Please do not reply to this message to unsubscribe. To >>unsubscribe or adjust >>!! your settings, send a mail message to >> >>!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. >> >> Received: from gtfw2.enterasys.com (gtfw2.enterasys.com [12.25.1.128]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2V4wGjZ022704 for ; Wed, 31 Mar 2004 06:58:17 +0200 Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i2V4wDiR003403 for ; Tue, 30 Mar 2004 23:58:13 -0500 (EST) Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 30 Mar 2004 23:58:11 -0500 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Tue, 30 Mar 2004 23:58:11 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 23:58:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] meeting in Seoul next to NOMS Date: Tue, 30 Mar 2004 23:58:09 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA017E1060@NHROCMBX1.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] meeting in Seoul next to NOMS Thread-Index: AcQWQLEx/0xIgbktRpSvZWtTGOa/WgAHqu/gAB8HkgA= From: "Harrington, David" To: "John Strassner" , "George Pavlou" , "Aiko Pras" Cc: , X-OriginalArrivalTime: 31 Mar 2004 04:58:11.0436 (UTC) FILETIME=[C43FFAC0:01C416DC] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:93.8525 M:96.4339 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id i2V4wGjZ022704 Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi, I disagree that the NMRG should try to address fundamental concerns in NetConf. I am aware that you disagree with some of the positions of the Netconf leaders regarding the information/data modeling questions. NMRG is part of the IRTF - the Internet **Research** Task Force - and should be focused on research. It should NOT be focused on trying to influence directions of active working groups in the IETF. Discussions of the directions of IETF WGs such as NetConf should be held in the working groups of the IETF, not in the IRTF. dbh > -----Original Message----- > From: nmrg-admin@ibr.cs.tu-bs.de > [mailto:nmrg-admin@ibr.cs.tu-bs.de] On Behalf Of John Strassner > Sent: Tuesday, March 30, 2004 8:35 PM > To: George Pavlou; Aiko Pras > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > Subject: RE: [nmrg] meeting in Seoul next to NOMS > > I will be there as well. I think we should try and address some > fundamental concerns in NetConf, but then again, I'm not sure > that this > will be productive. > > regards, > John Strassner > TeleManagement Forum Advisory Director > > > John Strassner > Chief Strategy Officer > Intelliden Inc. > 90 South Cascade Avenue > Colorado Springs, CO 80906 USA > phone: +1.719.785.0648 > fax: +1.719.785.0644 > email: john.strassner@intelliden.com > > > > > -----Original Message----- > > From: nmrg-admin@ibr.cs.tu-bs.de > [mailto:nmrg-admin@ibr.cs.tu-bs.de] > > Sent: Tuesday, March 30, 2004 3:19 AM > > To: Aiko Pras > > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > > Subject: Re: [nmrg] meeting in Seoul next to NOMS > > > > > > > > > As you know, I will be in Seoul and will be able to > attend. I would > > > love > > > to have (yet again) some discussion on how to use web > services for > > > management, but I'm afraid I'll have little time to prepair > > something. > > > > I will be there as well (I arrive on Saturday), so I could be > > involved in another discussion on the topic (but have no > new material > > since what I presented in Bremen). > > > > Regards, > > -George > > > > -- > > !! This message is brought to you via the `nmrg' mailing > > list. !! Please do not reply to this message to unsubscribe. > > To unsubscribe or adjust !! your settings, send a mail > > message to !! or look at > https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust > !! your settings, send a mail message to > > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > Received: from COSIUM03.intelliden.net (cosium03.intelliden.net [12.41.186.100]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2V44vjZ032639 for ; Wed, 31 Mar 2004 06:05:00 +0200 Subject: RE: [nmrg] meeting in Seoul next to NOMS Date: Tue, 30 Mar 2004 18:35:29 -0700 Message-ID: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-TNEF-Correlator: Thread-Topic: [nmrg] meeting in Seoul next to NOMS thread-index: AcQWQLEx/0xIgbktRpSvZWtTGOa/WgAHqu/g Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 From: "John Strassner" To: "George Pavlou" , "Aiko Pras" Cc: , X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id i2V44vjZ032639 Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I will be there as well. I think we should try and address some fundamental concerns in NetConf, but then again, I'm not sure that this will be productive. regards, John Strassner TeleManagement Forum Advisory Director John Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: nmrg-admin@ibr.cs.tu-bs.de [mailto:nmrg-admin@ibr.cs.tu-bs.de] > Sent: Tuesday, March 30, 2004 3:19 AM > To: Aiko Pras > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] meeting in Seoul next to NOMS > > > > > As you know, I will be in Seoul and will be able to attend. I would > > love > > to have (yet again) some discussion on how to use web services for > > management, but I'm afraid I'll have little time to prepair > something. > > I will be there as well (I arrive on Saturday), so I could be > involved in another discussion on the topic (but have no new material > since what I presented in Bremen). > > Regards, > -George > > -- > !! This message is brought to you via the `nmrg' mailing > list. !! Please do not reply to this message to unsubscribe. > To unsubscribe or adjust !! your settings, send a mail > message to !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2V1HljZ026966 for ; Wed, 31 Mar 2004 03:17:48 +0200 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2V1Hdn4024826; Tue, 30 Mar 2004 17:17:44 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-39.cisco.com [10.86.240.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHF89640; Tue, 30 Mar 2004 20:17:38 -0500 (EST) Message-Id: <4.3.2.7.2.20040330102811.02579810@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Mar 2004 10:28:50 -0500 To: j.schoenwaelder@iu-bremen.de From: Ralph Droms Subject: Re: [nmrg] meeting in Seoul next to NOMS Cc: nmrg@ibr.cs.tu-bs.de In-Reply-To: <20040327111225.GA938@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-IBRFilter-SpamReport: -4.25 () BAYES_00,DATE_IN_PAST_06_12 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I don't plan to attend NOMS and would not be able to attend an NMRG meeting associated with NOMS... - Ralph At 12:12 PM 3/27/2004 +0100, Juergen Schoenwaelder wrote: >I got an offer from James Hong to host a meeting next to NOMS 2004, >for example Sunday afternoon before NOMS. I think this is a nice >idea but before putting this forward, I would like to know who is >interested and able to attend. Also, if you have specific topics >you want to discuss, I would also like to know about it. > >Please respond quickly since NOMS is coming close quickly. > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > >-- >!! This message is brought to you via the `nmrg' mailing list. >!! Please do not reply to this message to unsubscribe. To unsubscribe or >adjust >!! your settings, send a mail message to >!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. Received: from james.eecs.iu-bremen.de (G4089.g.pppool.de [80.185.64.137]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2ULRDjZ028044 for ; Tue, 30 Mar 2004 23:27:13 +0200 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 414E85EB52; Tue, 30 Mar 2004 23:27:13 +0200 (CEST) Date: Tue, 30 Mar 2004 23:27:13 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20040330212713.GB1675@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de References: <20040327111225.GA938@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040327111225.GA938@iu-bremen.de> User-Agent: Mutt/1.5.5.1+cvs20040105i X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] Re: meeting in Seoul next to NOMS Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Sat, Mar 27, 2004 at 12:12:25PM +0100, Juergen Schoenwaelder wrote: > I got an offer from James Hong to host a meeting next to NOMS 2004, > for example Sunday afternoon before NOMS. I think this is a nice > idea but before putting this forward, I would like to know who is > interested and able to attend. Also, if you have specific topics > you want to discuss, I would also like to know about it. I received responses from five people who plan to attend and we have some topics I find interesting (I especially like to hear more about the netconf prototype). So I think we should use the opportunity to meet on Sunday afternoon before NOMS. Perhaps some other people will join who happen to hang around in Seoul and who are not on this list. I will shortly create a web page for this meeting, which is BTW now the 16th meeting (and Seoul adds a nice place to the list of places we have been so far). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from smtp02-w.exodus.net (smtp.exodus.net [66.35.230.237]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2ULLuja025707 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 30 Mar 2004 23:21:57 +0200 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i2UITVEv012876 for ; Tue, 30 Mar 2004 12:29:32 -0600 Received: from [206.117.31.228] (unverified [206.117.31.228]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Tue, 30 Mar 2004 13:21:53 -0800 Mime-Version: 1.0 X-Sender: margaret@thingmagic.com@ms101.mail1.com Message-Id: In-Reply-To: <3971.82.224.85.23.1080680826.squirrel@www.loria.fr> References: <20040327111225.GA938@iu-bremen.de> <3971.82.224.85.23.1080680826.squirrel@www.loria.fr> Date: Tue, 30 Mar 2004 16:21:32 -0500 To: , j.schoenwaelder@iu-bremen.de From: Margaret Wasserman Subject: Re: [nmrg] meeting in Seoul next to NOMS Cc: nmrg@ibr.cs.tu-bs.de, Radu.State@loria.fr Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Unfortunately I do not have sufficient travel budget to come to Seoul for this meeting. However, I would be very interested in hearing about this implementation of netconf. Is it available on-line? Thanks, Margaret At 11:07 PM -0200 3/30/04, wrote: >Dear all, > >Both Radu and I will be in Seoul and able to attend a NMRG meeting. We >arrive on saturday morning or something like that in Seoul. >We can present our native C++ NetConf agent toolkit implementation on Linux >called YENCA (it does not means anything, but looks nice). The environment >is complete and has some nice features, even if we have few configuration >modules available at the moment,i.e. application modules built using the >agent. Naturally, the code is Open Source. > >Olivier > >> I got an offer from James Hong to host a meeting next to NOMS 2004, for >> example Sunday afternoon before NOMS. I think this is a nice >> idea but before putting this forward, I would like to know who is >> interested and able to attend. Also, if you have specific topics >> you want to discuss, I would also like to know about it. >> >> Please respond quickly since NOMS is coming close quickly. >> >> /js >> >> -- >> Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, 28725 Bremen, >> Germany >> >> -- >> !! This message is brought to you via the `nmrg' mailing list. >> !! Please do not reply to this message to unsubscribe. To unsubscribe >> or adjust !! your settings, send a mail message to >> !! or look at >> https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > >-- >!! This message is brought to you via the `nmrg' mailing list. >!! Please do not reply to this message to unsubscribe. To >unsubscribe or adjust >!! your settings, send a mail message to >!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. Received: from james.eecs.iu-bremen.de (G4089.g.pppool.de [80.185.64.137]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2ULC8jZ021278 for ; Tue, 30 Mar 2004 23:12:08 +0200 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id CE6305EB52; Tue, 30 Mar 2004 23:12:08 +0200 (CEST) Date: Tue, 30 Mar 2004 23:12:08 +0200 From: Juergen Schoenwaelder To: Olivier.Festor@loria.fr Cc: nmrg@ibr.cs.tu-bs.de, Radu.State@loria.fr Subject: Re: [nmrg] meeting in Seoul next to NOMS Message-ID: <20040330211208.GA1562@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Olivier.Festor@loria.fr, nmrg@ibr.cs.tu-bs.de, Radu.State@loria.fr References: <20040327111225.GA938@iu-bremen.de> <3971.82.224.85.23.1080680826.squirrel@www.loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3971.82.224.85.23.1080680826.squirrel@www.loria.fr> User-Agent: Mutt/1.5.5.1+cvs20040105i X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Tue, Mar 30, 2004 at 11:07:06PM -0200, Olivier.Festor@loria.fr wrote: > Both Radu and I will be in Seoul and able to attend a NMRG meeting. We > arrive on saturday morning or something like that in Seoul. > We can present our native C++ NetConf agent toolkit implementation on Linux > called YENCA (it does not means anything, but looks nice). The environment > is complete and has some nice features, even if we have few configuration > modules available at the moment,i.e. application modules built using the > agent. Naturally, the code is Open Source. I am certainly interested in this since I have so many question about how netconf is supposed to work and you already have an implementation (and thus all the answers to my questions ;-). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from macker.loria.fr (macker.loria.fr [152.81.1.70]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2UL79jZ019149 for ; Tue, 30 Mar 2004 23:07:10 +0200 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0FE7715C9B; Tue, 30 Mar 2004 23:07:07 +0200 (CEST) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from loria.fr (auxerois.loria.fr [152.81.144.16]) by macker.loria.fr (Postfix) with SMTP id 48D1715C8C; Tue, 30 Mar 2004 23:07:04 +0200 (CEST) Received: from 82.224.85.23 (SquirrelMail authenticated user festor) by www.loria.fr with HTTP; Tue, 30 Mar 2004 23:07:06 -0200 (MET DST) Message-ID: <3971.82.224.85.23.1080680826.squirrel@www.loria.fr> Date: Tue, 30 Mar 2004 23:07:06 -0200 (MET DST) Subject: Re: [nmrg] meeting in Seoul next to NOMS From: To: j.schoenwaelder@iu-bremen.de In-Reply-To: <20040327111225.GA938@iu-bremen.de> References: <20040327111225.GA938@iu-bremen.de> Cc: nmrg@ibr.cs.tu-bs.de, Radu.State@loria.fr X-Mailer: SquirrelMail (version 1.0.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-IBRFilter-SpamReport: -2.809 () BAYES_00,DATE_IN_FUTURE_03_06,NO_REAL_NAME X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Dear all, Both Radu and I will be in Seoul and able to attend a NMRG meeting. We arrive on saturday morning or something like that in Seoul. We can present our native C++ NetConf agent toolkit implementation on Linux called YENCA (it does not means anything, but looks nice). The environment is complete and has some nice features, even if we have few configuration modules available at the moment,i.e. application modules built using the agent. Naturally, the code is Open Source. Olivier > I got an offer from James Hong to host a meeting next to NOMS 2004, for > example Sunday afternoon before NOMS. I think this is a nice > idea but before putting this forward, I would like to know who is > interested and able to attend. Also, if you have specific topics > you want to discuss, I would also like to know about it. > > Please respond quickly since NOMS is coming close quickly. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To unsubscribe > or adjust !! your settings, send a mail message to > !! or look at > https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2UAJ8ja019193 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 30 Mar 2004 12:19:08 +0200 Received: from hermes.ee.surrey.ac.uk ([131.227.88.10] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1B8GKc-0003dm-00; Tue, 30 Mar 2004 11:18:54 +0100 Received: from ees2gp (helo=eim.surrey.ac.uk) by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 1B8GKb-0003SO-00; Tue, 30 Mar 2004 11:18:53 +0100 To: Aiko Pras cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meeting in Seoul next to NOMS In-Reply-To: Message from Aiko Pras of "Tue, 30 Mar 2004 12:05:25 +0200." <40694665.9030201@cs.utwente.nl> Date: Tue, 30 Mar 2004 11:18:53 +0100 From: George Pavlou Message-Id: X-Spam-Status: No, hits=-101.0 required=5.5 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1B8GKc-0003dm-00*/CUYyMVeKtc* (SECM, UniS) X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: > As you know, I will be in Seoul and will be able to attend. I would love > to have (yet again) some discussion on how to use web services for > management, but I'm afraid I'll have little time to prepair something. I will be there as well (I arrive on Saturday), so I could be involved in another discussion on the topic (but have no new material since what I presented in Bremen). Regards, -George Received: from netlx050.vf.utwente.nl (netlx050.vf.utwente.nl [192.87.17.19]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2UA5OjZ013442 for ; Tue, 30 Mar 2004 12:05:24 +0200 Received: from cs.utwente.nl (adsl219222.adsl.utwente.nl [130.89.225.67]) by netlx050.vf.utwente.nl (8.11.7/HKD) with ESMTP id i2UA5IV03871; Tue, 30 Mar 2004 12:05:20 +0200 Message-ID: <40694665.9030201@cs.utwente.nl> Date: Tue, 30 Mar 2004 12:05:25 +0200 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meeting in Seoul next to NOMS References: <20040327111225.GA938@iu-bremen.de> In-Reply-To: <20040327111225.GA938@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-MailScanner-From: pras@cs.utwente.nl X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: As you know, I will be in Seoul and will be able to attend. I would love to have (yet again) some discussion on how to use web services for management, but I'm afraid I'll have little time to prepair something. Bye Aiko Juergen Schoenwaelder wrote: > I got an offer from James Hong to host a meeting next to NOMS 2004, > for example Sunday afternoon before NOMS. I think this is a nice > idea but before putting this forward, I would like to know who is > interested and able to attend. Also, if you have specific topics > you want to discuss, I would also like to know about it. > > Please respond quickly since NOMS is coming close quickly. > > /js > Received: from gtfw2.enterasys.com (gtfw2.enterasys.com [12.25.1.128]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2TFp8jZ020283 for ; Mon, 29 Mar 2004 17:51:09 +0200 Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i2TFp4iR013814 for ; Mon, 29 Mar 2004 10:51:07 -0500 (EST) Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 29 Mar 2004 10:51:04 -0500 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Mon, 29 Mar 2004 10:51:04 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 10:51:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] meeting in Seoul next to NOMS Date: Mon, 29 Mar 2004 10:51:03 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA017E0F9D@NHROCMBX1.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] meeting in Seoul next to NOMS Thread-Index: AcQT7KsCAJk6lPvNRYiefWzopHaYrwBJfKAg From: "Harrington, David" To: , X-OriginalArrivalTime: 29 Mar 2004 15:51:04.0126 (UTC) FILETIME=[A42A9DE0:01C415A5] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:79.5348 M:98.8113 P:95.9108 R:95.9108 S: 8.8929 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id i2TFp8jZ020283 Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi Juergen, I am unlikely to attend NOMS, and couldn't justify the flight for a two day meeting, so I unlikely to attend if it is held in Seoul. dbh > -----Original Message----- > From: nmrg-admin@ibr.cs.tu-bs.de > [mailto:nmrg-admin@ibr.cs.tu-bs.de] On Behalf Of Juergen Schoenwaelder > Sent: Saturday, March 27, 2004 6:12 AM > To: nmrg@ibr.cs.tu-bs.de > Subject: [nmrg] meeting in Seoul next to NOMS > > I got an offer from James Hong to host a meeting next to NOMS 2004, > for example Sunday afternoon before NOMS. I think this is a nice > idea but before putting this forward, I would like to know who is > interested and able to attend. Also, if you have specific topics > you want to discuss, I would also like to know about it. > > Please respond quickly since NOMS is coming close quickly. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust > !! your settings, send a mail message to > > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > Received: from james.eecs.iu-bremen.de (G5150.g.pppool.de [80.185.81.80]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2RBCQjZ008210 for ; Sat, 27 Mar 2004 12:12:27 +0100 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 468B4887B; Sat, 27 Mar 2004 12:12:26 +0100 (CET) Date: Sat, 27 Mar 2004 12:12:25 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20040327111225.GA938@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] meeting in Seoul next to NOMS Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I got an offer from James Hong to host a meeting next to NOMS 2004, for example Sunday afternoon before NOMS. I think this is a nice idea but before putting this forward, I would like to know who is interested and able to attend. Also, if you have specific topics you want to discuss, I would also like to know about it. Please respond quickly since NOMS is coming close quickly. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2QJJvjZ015434; Fri, 26 Mar 2004 20:19:58 +0100 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i2QJJub08878; Fri, 26 Mar 2004 11:19:56 -0800 Message-Id: <5.2.0.9.2.20040326111341.02326e60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 26 Mar 2004 11:19:51 -0800 To: Torsten Klie , nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Subject: Re: [nmrg] Draft minutes of the 15th NMRG-Meeting In-Reply-To: <40641031.7070806@ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IBRFilter-SpamReport: -1.524 () BAYES_01 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: HI, Torsten - thank you for taking notes. I found the discussion on the last two topics quite interesting. One item that came up was comparing network management to distributed computing. There were comments that they were the same. However, I have always believed that they were fundamental different. Is there a paper that compares the two, or could someone send out a comparison. I'm sorry that I wasn't able to attend. I always learn much and enjoy the interaction. Regards, /david t. perkins Received: from ibr.cs.tu-bs.de (pc176.learninglab.uni-hannover.de [130.75.87.176]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2QBCmja002352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 26 Mar 2004 12:12:49 +0100 Message-ID: <40641031.7070806@ibr.cs.tu-bs.de> Date: Fri, 26 Mar 2004 12:12:49 +0100 From: Torsten Klie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en, es-es, es, ca, fr MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Content-Type: multipart/mixed; boundary="------------040706020308040106040209" X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: [nmrg] Draft minutes of the 15th NMRG-Meeting Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------040706020308040106040209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! Attached you will find the draft minutes of the 15th NMRG meeting (January 2004, Bremen). I focused on the discussions, because the presentation slides are already available, so I more or less copied the abstracts of the talks. Please let me know, if there is anything I shall change. Best regards, Torsten --------------040706020308040106040209 Content-Type: text/plain; name="minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minutes.txt" 15th NMRG-Meeting (January 8th, 2004, IU Bremen) ================================================ Participants: ------------- # Marcus Brunner (NEC Europe, Germany) # Luca Deri (ntop.org, Italy) # Olivier Festor (LORIA-INRIA, France) # Torsten Klie (TU Braunschweig, Germany) # Aad van Moorsel (?) # George Pavlou (University of Surrey, England) # Aiko Pras (University of Twente, The Netherlands) # Juergen Quittek (NEC Europe, Germany) # Juergen Schoenwaelder (International University Bremen, Germany) # Radu State (LORIA-INRIA, France) # Frank Strauss (TU Braunschweig, Germany) Minutes: Torsten 1. Path-coupled signaling for traffic measurement (Marcus) ---------------------------------------------------------- Passive and active measurement technologies are available for measuring hop-by-hop properties of traffic along its path through the Internet. Passive technologies can measure these properties accurately, but configuring them for the measurement of a particular traffic flow at all hops requires significant overhead for measurement configuration. This problem does not apply to active measurements, such as traceroute, because probing packets automatically follow the same path as the traffic flow to be measured. However, active techniques measure properties/conditions of the injected traffic, which may differ from those of the traffic of interest. Marcus showed an approach [1] that tries to combine the two ways of measurement. It uses signaling for configuring passive hop-by-hop measurements along the path of a traffic flow of interest. Implementations use a pre-standard IETF NSIS protocol. Discussion: AP: What do you consider a high speed link? MB: A link with more than 1GBit. AP: Why is using signaling for measurement configuration better than using traceroute for example? MB: Traceroute gives you the location of the current flow which may change. With signaling, you measure only what you really are interested in. AP: Are these route changes a real issue or are they just theoretically a problem? MB: They are a real problem but not much looked at. JQ: It is simpler because you do not have to implement the transport or the basic security level. Another reason is that it must be simpler because it is meant to be an end user technology and not for someone who is monitoring the network anyway. So it is important not to require any knowledge of the topology. LD: What are your probes? MB: There are 3 implementations, one on Linux (kernel space), one on Linux (user space) and another one on an IXP node. LD: Is it possible to apply this to a real network? It looks more like a configuration for routers. So why yet another protocol instead of a configuration in a MIB? JQ: We are only interested to have it on routers. Dedicated probes is not our focus. The basic idea of the NSIS protocol is to have signaling support on routers. JQ: There are problems with load balancing (data and signaling may have different paths). The same with MPLS. There are scalability problems as well (like in RSVP). MB: In order to save memory the number of managed flows can be restricted. AP: How do you do time-stamping? MB: There is GPS in the routers. AP: What about routers "without daylight"? MB: The problem has not been solved. Maybe using NTP can help. This is definitively an issue. AP: What about the accuracy without GPS? JS: It depends on the accuracy of the kernel mechanisms (more information on the NTP web-site [2]). JS: You have an implementation of the NSIS signaling protocol? MB: It is just a pre-standard prototype implementation. JS: Does the protocol specify how you detect route changes? Or is it an implementation issue? JQ: It works on a refresh base. You have to refresh your routing configuration regularly and when the routing changes the refresh is also rerouted. MB: There is no agreement so far. It depends on the situation (for example mobile vs. more stable environment). JS: Are there other fundamental differences between NSIS and RSVP? MB: The most fundamental change was the split into the generic part and application-oriented part. RSVP is targeted to QoS which has been given up. Multicast is not included. JS: How about security? MB: Security is another hot topic in NSIS and SIP. It is tight to the business model and the trust relationships. OF: If it is not possible to do measurements on all hops in the path, is it possible to go back (like in RSVP) and make a proposal to do measurements every two hops, for example? MB: You could implement that. It is part of the signaling/measurement application. The base NSIS protocol allows you to do that. OF: Can collection be done with signaling as well? MB: Yes. MB: In the future we want to look at what kinds of measurements can be done this way and what are the benefits. AP: The most attractive idea is that you can give these kinds of services to you end users without the need of giving them access to the internals of your network. JS: I think the end user model has scalability problems. I think, it could be used as a service for neighbor ISP because you do not have to give them insight on your network topology. MB: It can be the end user. If it is the service, the user pays for it, so the price will solve the scalability problem. AP: A disadvantage of the approach is that the measurement has to be done within the router. Is there not a problem with the computing power? Signaling may increase the load. This may be an obstacle for deployment. JQ: The routers have an "overload brake" (so that the router stops signaling and measurement when a certain load threshold has been reached). There may be a problem with availability, but the service is not meant to be available for all time. 2. Improving Passive Packet Capture: Beyond Device Polling (Luca) ----------------------------------------------------------------- Passive packet capture is necessary for many activities including network debugging and monitoring. With the advent of fast gigabit networks, packet capture is becoming a problem even on PCs due to the poor performance of popular OSs. The introduction of device polling has improved the capture process quite a bit but not really solved the problem. The problem with polling is that the time-stamps may not be accurate if polling is too slow. If polling is fast, very little CPU is left for user space applications. Luca showed an approach [3] to passive packet capture that combined with device polling further improves it and allows, on fast machines, packets to be captured at (almost) wire speed. He proposed a packet ring data structure in the network driver where incoming packets are copied to. The packet will not be queued into kernel data structures. It is important to know where package loss occurs (driver, kernel, or user-space). Discussion: AP: I have obtained different measurement results with a 1GBit card. Why are the differences in package loss between a 1GBit card and a 100MBit card so high? LD: The logic of the faster cards is much more efficient so interrupts are raised less often. 10GBit cards are even more efficient. JQ: The point is that the large number of package loss only occurs with a large sequence of small packages, so it does not happen that often. Thus, libpcap works in many cases but does not always capture all packages. AP: That was our observation that when you have a DNS attack than you lose data. However, we do not care about counting packages if we get an DNS attack. LD: There is another issue that you should consider. When you lose packages you should also know where you lose packages (kernel level, driver level or user space level). If tcpdump, for example, tells you that you do not have package loss it does not mean that you do not lose packages. JS: What are the differences between the implementations of the different OSes? LD: Linux uses soft interrupts which lead to low performance. Windows uses optimized network drivers and deferred interrupts to achieve better performance. MB: Are there differences in the implementation between Linux 2.4 and 2.6? LD: Not much. JS: How much work is it to adapt the device drivers? LD: Very little. You just have to modify the driver to call my function instead of netif_rx and to disable the transmission. MB: Why do you not implement the function at the beginning of the chain in the kernel before the package is filled into the whole structures? Then it would be generally available to each network card. LD: Such a generic approach should be doable. However, it is much easier to just override the system call in the driver. 3. Solving the middle-box problem (Juergen Q.) --------------------------------------------- Firewalls and NATs are middle-boxes and integral components of the Internet infrastructure but they are also obstacles for many communication services including IP telephony, video conferencing, etc. Several alternative approaches for overcoming this problem are currently under investigation. Juergen showed [4] three of them: (1) controlling middle-boxes by more or less central entities like 'call agents', as investigated by the IETF MIDCOM WG [5], (2) path-coupled signaling between terminals and middle-boxes, as investigated by the NSIS WG [6], and (3) smart middle-boxes configuring themselves based on observed signaling messages. A comparison of advantages and disadvantages of the approaches shows that in different scenarios, different approaches are preferable. The first approach is a telco-style solution. It is widely understood because it is close to gateway controllers. The MIDCOM WG was charted to select an existing protocol. They selected SNMPv3 as the appropriate protocol for configuring firewalls and NATs. The reason was that SNMPv3 is a full standard. However, some people claim that SNMP was not designed for that purposes. The second approach is path coupled signaling, as described above in Markus' presentation. The terminals are enabled to open pin holes. The topic is addressed by the NSIS WG. If there were a transport protocol for signaling, it would progress more quickly. This approach is the only one that will work if the SIP signaling path is different from the data path. The third approach is the smart middle-box approach. A smart middle-box is a device that is smart enough to handle everything. There is small-office/home-office firewall available from CISCO. However, Juergen did not test it, because there are no specifications available. A main problem here is that the firewall must be able to support new signaling protocols. Another issue is that the signaling must be path coupled with the session that shall be established. There should be some policy control. Juergen implemented a modular firewall on NET-BSD with loadable kernel modules which extend ipfilter by new rules. The current conclusion is that all three approaches are useful and needed in different environments. A telecommunication operator will like to have the call-agent approach. At home, users definitely want to have smart middle-boxes. In some other scenarios, path coupled signaling is the best solution. However, probably not all three approaches will survive. Discussion: AP: What happens when you forget to close the pin holes? JQ: For approach 1 and 2, there are timeouts. I would call it "middle-box control" rather than "middle-box management" because you do not configure permanent state. AP: Is the smart middle-box approach not the best solution in theory? JQ: All approaches have advantages and disadvantages. The problem is that networks are usually too complicated. For example, the signaling and the voice data stream do not necessarily take the same way. I also consider it the best solution, except for this disadvantage. Another problem is that it needs quite a lot of computing power on the firewall or NAT because it has to be aware of all the protocols involved. AP: Is the functionality not included in iptables? So implementing it should be quite simple. JQ: Yes, but you also need to implement the protocol parser. AP: [related to approach 1] What happens if the gateway is owned by the end user (for example at home networks)? The end user will have to trust his operator. Furthermore, you need authentication etc. JS: I completely disagree, the firewall does not want to trust the IP phone. AP: I was thinking about the firewall at my home. There will be more home user firewalls than firewalls of companies.At home, I trust my IP phone. JQ: It is possible to have an own SIP server which controls the personal firewall. The call-agent will only control firewalls which are somewhere else (SIP proxy chaining). AP: Then I will need a SIP proxy at home, but I do not want another box there. JQ: It is possible to run the SIP proxy as a process on your PC (such as your personal firewall) or in a box that already provides firewall functionality. AP: If you put the functionality into the same box, where is the difference between a smart middle-box? JQ: In that case, the two approaches are almost merged. However, if you look at companies where you have 50 users but only a single SIP server in one firewall it is fine. AP: People who have ADSL at home will start using IP telephony, so this issue will become important. JQ: Firewalls must be extended with SIP proxy servers (or opened). JS: What happens to your personal firewall if you get an incoming call that wants to go through your firewall? JQ: You will listen on the SIP port and then you will have to open your firewall. OF: Today, in France, if you use the current offers on VoIP over ADSL, you have the phone access directly on the box that you have received from your provider. You cannot put a firewall between your VoIP signaling. AP: ADSL is often offered by other companies than your telephone company, who are competitors, so they try to give you locked solutions so that you cannot switch the operator. OF: There are applications which configure your firewall using UPnP. JQ: UPnP is also one of the protocols here. MB: Our approach was not targeted to the home user with one firewall and one phone, but UPnP is. JQ: UPnP is not well suited if you have a larger office. LD: What about security? JQ: If a remote phone says "open your firewall for me" the incoming call will have to be acknowledged. This can be done via signaling. In order to be more secure the protocol could be extended to restrict the opened UDP traffic to the source address of the calling phone. LD: With IPv6, you will not have NAT but you will have firewalls so your approach will be still useful. JQ: NAT will still be used with IPv6. GP & LD: NAT will disappear. JQ: NAT will still be used because huge companies such as IBM, Sun, HP use NAT although they have enough IP addresses. However, it will not be used that intensively as today. AP: If you have a lot of machines at home - Morris said yesterday that there might be 100000 machines at home - your network is more easy to manage using NAT. LD: You can connect to all machines using the same address. AP: Why does the MIDCOM WG not use NETCONF instead of SNMPv3? JQ: It is a fast and dynamic configuration issue which you do on a call per call base. I am not sure if NETCONF is the right tool here. AP: No, it is not. JS: Another reason is that SNMPv3 is a full standard. Formally, it is better to use something that already exists than something that might exist sometimes. JQ: SNMP was not designed to do these kind of things. AP: SNMP was designed to do that but it is not happening. JQ: If it is not happening, there is probably something wrong with the design. JS: It is completely contradictory that you do a protocol evaluation which concludes that SNMP is the right choice and afterwards without really knowing the details you find out that SNMP was not really designed for the purpose. JQ: It can serve the purpose but that does not mean that it has to be specifically designed to serve the purpose. The other protocols were also not designed to serve the purpose (COPS, for example). JS: What was the technical argument behind the statement "SNMP was not designed for that purpose"? JQ: Transactions are possible with SNMP but not really convenient. It is possible to do everything in a single set operation, but only if it fits. AP: How much data do you usually need? Maybe it will fit. JS: It might fit but it is a problem of the problem. With the security enabled, the space in a set operation will be quite limited. AP: What about scalability? If the security features of SNMPv3 are used, key management will become very complicated. JQ: Key management is a problem anyway, also with the other protocols that were considered. AP: What about the future of the WG? JQ: The WG probably will be closed soon after a MIB will be released. AP: Is the constraint of not defining a new protocol a good argument for smart middle-boxes? If you are not allowed to define a protocol. do not define and use a protocol. JQ: We defined a simple protocol as an Internet draft. However, the area director said we first have to define a MIB and then we are allowed to publish the new protocol as an informational RFC. OF: [related to approach 3] The intelligence of the firewall must be configured somehow. Is this possible? AP: The firmware of a firewall can be updated in the same way as usual operating systems. AP: What protocols can be used? JQ: ftp, h.323, SIP, rtcp AP: Which ones have been done? JQ: None, but ftp should be quite simple to do. AP: ftp has. MB: No, iptables does not support ftp. JQ: Well, ftp is simple to implement and we used ipfilters and not iptables. AP: Was UPnP not specifically designed to solve the mentioned problems? JQ: UPnP is the best choice for the single computer home environment. Therefore, it is also discussed in the MIDCOM WG. But there are scenarios where UPnP is not sufficient. 4. Using Distributed Object Technologies for Network Management (George) The use of distributed object technologies for network management has been intensively researched in the mid- to late-1990's. The X/Open-NMF JIDM produced guidelines for translating SNMP, SMI, and OSI-SM GDMO models to CORBA IDL and using CORBA as the access mechanism. This approach though was never adopted per se, but variations of it have been used mostly in telecommunication environments. It has recently become evident that a semantic rather than syntactic approach for converting SNMP SMI and GDMO models to distributed object interface specifications is the way forward. George's presentation [7] reviews the state-of-the-art in using distributed object technologies for network management and will propose a framework that circumvents their usual problems, making potentially possible to adopt distributed objects for Internet management. For all other cases than table retrieval, plain Get request is sufficient. However, this is not true for SNMPv1 because of the lack of proper error handling. A disadvantage of DOT is that the default is to have one get method per object attribute. In case of large object populations, this leads to sub-optimal information retrieval. George therefore proposes a different mapping. For all attributes (i.e. properties) use one method per object. Dynamic counters and probably time attributes should be grouped. Discussion: JS: Some of my code does not use Get at all. GP: Why do you use GetNext to retrieve single instance objects? JS: The reason is that when you ask for a list of objects and one object is not present then your whole get operation fails. AP: This is only true for SNMPv1. JS: Well, I am talking to real agents. Anyway, it is possible to generate stubs out of MIBs. GP: Yes, that is what WS people do. BTW, is there any SNMP API with stubs? JS: Yes, I have written one (xxx Juergen, smidump -f net-snmp?). The protocol is very simple and it requires some engineering on top of it to make it usable. The interesting thing is, that it in all the years with SNMP people have not done this. GP: I completely agree. AP: We as researchers keep making the same mistakes. When we talk about simple, we talk about simple design. But if you want to have something simple it should be simple to use. The main advantage of WS is that it is easy to use because you get it for free everywhere. GP: If you take WS with a plain SOAP API it is very difficult to use. AP: Why should there not be a Get operation in the WSDL file that retrieves all the data in a large XML file on which XPath and XQuery can be used to select more specific data? GP: The proposal is not only applicable to WS. It is transparent to all DOTs. AP: There is another advantage. This is easy to parse with existing software. With MS Excel, for example, you can write it down in four lines. If you have an XML document you will have the XML handling yourself. For users, this is far more difficult. AvM: HP decided to go use a grid service approach because they think there will not be consensus on the grouping of objects. That is why they prefer to deal with large XML documents. In general, the XML based approach seems to be more useful in a large scale operator environment where experts do the management. GP: Network management is not that different to other distributed systems topics. AP: Management is not different than anything else so we should use the same technologies. However, we may have our specialized WSDL files. AvM: The Question is what should be standardized. AP: The question is what will be used. I think that the users will decide for what they find easy to use. George's approach is simpler to use than shipping large XML documents. However, if you manage sophisticated machines within an operator environment where you have skilled people with the XML approach you are more powerful. But if we have 100000 computers per human being we cannot manage them by programming with XML documents. It does not scale anymore. AvM: Why do you consider WS to have strong typing? GP: On the SOAP level, it is loose typing. But if you use stubs, you will get strong typing. AP: Is it better to ship entire tables or is it better to retrieve single entries? GP: If you ship entire tables it is possible to have faster agents. With the retrieval of single entries it is possible to save bandwidth. However, bandwidth is not an issue these days. If you need to get single objects you can implement it. However, then you will need a naming etc. and it will get complicated. AP: Would it not be useful to have a possibility to retrieve an entire table and specifying arguments that select rows which have certain properties? GP: I was trying to keep it simple. It shall be dine at the manager's side. GP: Why did MIB designers invented linked replies? Why did they not include all the data in a single big reply? AP: Because the reply could consume MBs of data. JS: Because the model allows asking multiple agents in one request. That makes it impossible to put everything into one reply. OF: If you have an application level routing on distinguished names, the request can be forwarded to different agents depending on the prefix. JS: [shows his TCP-MIB API, which has been generated by a compiler] I agree with the statement that for real management applications the API is the key. In my API, there is a stub function to which you pass a mask and which then retrieves the desired data from the MIB. I allow the application to chose the data. For read/write stuff, such as the tcp table, for example, you get another stub function that retrieves the whole table. You can mask some columns if you want to. Another stub function is "get one entry". With this API you can write management applications without knowing anything about SNMP. The compiler was written in 2000. However, people are still programming with Get and GetNext API calls. AP: I think vendors will include WS into their devices like they have put web servers for manual configuration. Probably, these WS will not be standardized. 5. Performance Evaluation of Web Services as Management Technology (George) Web Services has been recently emerging as an XML-based technology for distributed access to Internet services. A careful examination reveals that Web Services is a technology with many similarities to distributed objects, so it could also be used for network management. This could be possibly done through the framework presented in the previous talk, which avoids potential scalability problems. In this presentation, George first identifies the similarities of WS and distributed object technologies. He then examines the usability and suitability of WS for network management and presents a performance evaluation of selected scenarios in comparison to SNMP and CORBA. Aiko did almost similar measurements but got different result. GP: We used WASP and not gSOAP, because GSOAP is highly optimized software and there is no highly optimized software for CORBA. To ensure a fair comparison, we used a "lighter" API. AP: This is an important point. With WS you can get highly optimized software for free. AvM: WS are not OO technology, at least not at the moment (WSDL 1.1) because inheritance and statefulness is missing. Maybe those will be added in WSDL 1.2 or 2.0. It would be better to compare CORBA with Grid Services (OGSI and OGSA) because WS is service oriented technology whereas GS is OO technology. AP: It is an interesting observation that sometimes it takes longer to retrieve values from kernel space than to do the entire protocol handling. So protocol handling often is only a minor issue. If you use NET-SNMP, for example, which does not do any caching, it will retrieve value after value out of the interface table even when you look at the whole table. Therefore, if you make a Get on 100 values from the interface table you will make 100 single kernel polls. GP: We started our implementations in Java. Later, we recoded them in C++ due to the overhead of Java. AP: We did some implementations in Java because we wanted to run the applications on mobile phones. The problem with Java is that it is very difficult to get low level informations about the amount of memory that you use. AP: I have different measurement results that lead me to different conclusions. One reason is that George used hard-wired data with the TCP implementation (e.g. counters). So, in my figures, SNMP is much worse than anything else. JS: This is due to a bad behavior of the SNMP implementation which may lead to a large number of get requests there are different results with non hard-wired data. AvM: SNMP is bad in your cases. JS: No, the implementation is bad. The quality of the SNMP implementations after 12 years of SNMP is totally disappointing, so we should stop. AP: WS without compression leads to very large amount of data that has to be shipped, much more than SNMP or CORBA use. Compressed WS are very good with respect to network usage. AP: When using compression with WS, the efficiency increases if more data is retrieved. My conclusion is that it is impossible to conclude which technology is better in general because it depends on the use case and the used software packages. If you just want to retrieve sysUpTime from a router, do it via SNMP. If you want to retrieve the entire interface table for 500 customers that are connected to your ADSL multiplexer, forget about SNMP, because compressed WS are far more efficient. My measurements also show that the time for the protocol is neglectable compared to the time of the data retrieval. JS: It is not valid to make comparisons with bad implementations. AP: We want to compare what is practically available and does we do not care about theoretical comparisons. References --------------------------- [1] http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/bremen/brunner.pdf [2] http://www.ntp.org [3] http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/bremen/deri.pdf [4] http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/bremen/quittek.pdf [5] http://www.ietf.org/html.charters/midcom-charter.html [6] http://www.ietf.org/html.charters/nsis-charter.html [7] http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2004/bremen/pavlou1.pdf --------------040706020308040106040209--