Received: from bastion.arraycomm.com (ns.arraycomm.com [199.74.167.5]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9VJLg0e004624 for ; Fri, 31 Oct 2003 20:21:44 +0100 Received: from lester.arraycomm.com (lester.arraycomm.com [172.16.0.17]) by bastion.arraycomm.com (Postfix) with ESMTP id 7A3E35E135; Fri, 31 Oct 2003 11:21:41 -0800 (PST) Received: from ARRAYCOMM.COM (vclient-20.arraycomm.com [192.168.10.20]) by lester.arraycomm.com (8.12.9/8.12.9) with ESMTP id h9VJLYft027808 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 31 Oct 2003 11:21:35 -0800 (PST) Message-Id: <200310311921.h9VJLYft027808@lester.arraycomm.com> From: Branislav Meandzija To: "Wijnen, Bert (Bert)" , "Harrington, David" , j.schoenwaelder@iu-bremen.de, Aiko Pras Cc: nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] getlist protocol operation Date: Fri, 31 Oct 2003 11:13:31 -0800 X-Mailer: CorporateTime Outlook Connector 3.3 40513 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) X-Filter-Version: 1.9 (lester) X-IBRFilter-SpamReport: 2.95 (**) FORGED_MUA_OUTLOOK 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 h9VJLg0e004624 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,FORGED_MUA_OUTLOOK autolearn=no version=2.60 X-Spam-Level: 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: IMHO, what David is saying is right-on-the-money. Our problem may well be that we are too quick to construct another design or batch of c-code that will live much longer than we ever intended and will complicate the lives of many generations to come. My 12 cents. Could not resist neither :-) Branislav > -----Original Message----- > From: nmrg-admin@ibr.cs.tu-bs.de [mailto:nmrg-admin@ibr.cs.tu-bs.de]On > Behalf Of Wijnen, Bert (Bert) > Sent: Friday, October 31, 2003 10:14 AM > To: Harrington, David; j.schoenwaelder@iu-bremen.de; Aiko Pras > Cc: nmrg@ibr.cs.tu-bs.de > Subject: RE: [nmrg] getlist protocol operation > > > MMmm.. you seem to be a fast typist (or have lots of time to type). > If you had pounded on the keyboard for the same amount of time but > constructing c-code instead, then you would have implemented > the getlist function already. > > Oh well... my 6 cents > Could not resist. > > Thanks, > Bert > > > -----Original Message----- > > From: Harrington, David [mailto:dbh@enterasys.com] > > Sent: vrijdag 31 oktober 2003 18:14 > > To: j.schoenwaelder@iu-bremen.de; Aiko Pras > > Cc: nmrg@ibr.cs.tu-bs.de > > Subject: RE: [nmrg] getlist protocol operation > > > > > > Hi, > > > > IETF WGs have not done well at standardizing NMRG > contributions, such > > SNMP/TCP, SNMP compression, and SMING. > > > > Juergen has stated on a number of occasions that he feels the > > problem is > > old-timers unwilling to share power with a new generation. I > > don't agree > > with that, but then I'm considered one of the old-timers > apparently. > > > > I think the problem is different than one of power-sharing. As Andy > > pointed out, the vendors seem to resist many of these NMRG > > proposals. I > > agree with that. > > > > As the person in my company whose job is to analyze network > management > > technologies and trends and make recommendations to our > product teams > > about whether and when to support proposed technologies in > our product > > lines, let me provide some insight from a vendor point of view about > > network management, SNMP and NMRG proposals in general. > > > > Before a vendor will seriously consider implementing the getlist > > approach (or any approach), we are likely to do a (possibly rather > > informal) return on investment analysis. If it will cost the company > > additional scarce resources and dollars to offer the > feature, then we > > will want to know that we can sell that feature to recoup > the costs. > > > > The costs can be extensive. When we produce products, we > not only need > > to pay to have the code written, we also need have our training > > department prepare training sessions, and we have to pay our > > sales force > > to take training in how the feature will benefit customers > so they can > > sell it approriately (and when they're in class, they are not out > > selling), we will need to pay our field personnel to debug > problems on > > site, we need train our phone support personnel to handle > > questions, and > > if we're going to sell it we need to market it, so we need to > > train our > > marketing department how to present the benefits, and pay for > > advertising, and on and on. > > > > If it is a change in direction, such as SMING, then we also > > need to plan > > how to migrate from the old technology to the new > technology. We have > > lots of legacy devices in the field for which customers pay > > maintenance, > > and we will never add the new technology to these legacy > > devices. So we > > will need to continue supporting the old technology even if the new > > technology is better. Our applications will need to be upgraded to > > differentiate and support both the old and the new > technologies. That > > means all those training costs now include training new > people in both > > technologies. As some products are released with the new > > technology, we > > need to be careful not to cause our products that do not > have the new > > approach to stop selling. So our marketing message gets more > > complicated, our maintenance contracts become more > > complicated, and our > > support program becomes more complicated. Our sales people > may have a > > harder time selling multiple products in our product line, when one > > supports the new technology and the other supports the old > technology. > > The saleperson, or a technical pre-sales person, needs to be able to > > explain how to integrate the two technologies successfully > > (think about > > selling a mix of your products, some of which support SNMPv3 > > and others > > that only support SNMPv1 - what's your marketing message? How should > > customers use these products in combination?) > > > > One of the costs of adding any new technology or new feature is > > opportunity cost. If we spend money and resources to support > > feature X, > > which features do we not have the money and resources to > > support? If we > > need to make a decision about which features to add to our wireless > > access point product, should we deliver products with 802.11a/b and > > SNMPv1 or 802.11b only with SNMPv3? If we don't have > 8802.11a support, > > we can't sell our hardware. If we support SNMPv3, most > operators won't > > even turn it on. > > > > Addition of, and migration to, a new technology can be a costly and > > difficult thing for vendors (and for their customers), so > > vendors resist > > new technologies unless there is a real potential for > customer benefit > > and resulting increased sales. > > > > Now lets consider NMRG proposals. As a protocol designer, I > > think SMING > > was a nice protocol; I think SNMP/TCP makes sense; I think > compression > > makes sense; I think many of the proposals in the EOS WG made > > sense, and > > the new getlist proposal probably is nice as well. Good > work on all of > > them; as an engineer I salute your designs. > > > > But can a vendor recoup their costs? Are the operators > screaming for a > > solution to the problem it solves? Will operators (and the > > CIO and CFO) > > spend extra money to have that feature in a device they > buy? Will they > > refuse to buy a device that doesn't have it? If we put it into our > > devices, will the operators actually use it? What other > feature are we > > missing the opprtunity to support by allocating resources to these > > proposals? > > > > If there is no customer demand for such a feature, such that it will > > impact the customers' buying decisions, then why should a > vendor spend > > money putting it into their devices, when they could use > the resources > > providing features that WILL impact customer buying decisions? > > > > That's the problem you're faced with, much more than a problem with > > power-sharing in the IETF. > > > > If you want to see your proposal selected, I suggest you contact the > > authors of open source implementations and have them add > > support for the > > feature to their code, so that vendors who use their code get it for > > free. Document how people should migrate to using the new > > technology in > > a manner that doesn't cost vendors or their customers a lot > > of money or > > interruption of service. Document how people should use the new > > technology in a mixed environment of new and old > technology. In other > > words, do all the things a vendor would need to do, and then > > see if you > > think the proposal has a high-enough return on the investment. > > > > If a proposal has a high enough ROI, vendors will support > the proposal > > and that will help you get it standardized in the IETF. If IETF > > participants believe a proposal will help their company > compete, they > > will be motivated to work on it; if they think it is > > irrelevant to their > > company, they won't be motivated to work on it, and it will > > probably die > > from apathy. > > > > My $.04 > > dbh > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > > Sent: Friday, October 31, 2003 10:30 AM > > > To: Aiko Pras > > > Cc: nmrg@ibr.cs.tu-bs.de > > > Subject: Re: [nmrg] getlist protocol operation > > > > > > > > > On Thu, Oct 30, 2003 at 01:42:09PM +0100, Aiko Pras wrote: > > > > > > > I have quickly read the ID; I did not read precise wording. > > > In general I > > > > like the idea of bumpers; they seem an elegant solution to > > > determine the > > > > end of the requested data. Probably a better name for > > > GetList would be > > > > GetRange PDU. > > > > > > Yes, GetRange might indeed be a better choice. > > > > > > > I agree with you that the new PDU would primarily be useful > > > in situations > > > > where TCP and compression are used. Just as with the > > > traditional GetBulk, > > > > in the case of UDP it may still be difficult to determine > > > how many varbinds > > > > fit in the response. Implementation may therefore be > > > difficult / not > > > > efficient. > > > > > > Whatever transport you choose, there will be limits on the > > > message size > > > so the logic to fill the PDU will be the same in all > cases. The only > > > difference with TCP is that the minimum max size is much > > larger which > > > gives you real benefits. > > > > > > > I'm not sure what to do with this proposal. I don't expect > > > that new IETF > > > > WGs will be able to come to concensus on SNMP enhancements > > > like this one. > > > > Therefore standardization will be unlikely. However, I > > > still believe that > > > > it is important to document technical proposals made by the > > > NMRG. This is > > > > particularly true if there are reasonable chances that > > > these proposals get > > > > implemented. > > > > > > One of the failures in SNMP land is that people always think > > > we have to > > > start with standards-track. If you look at other > > > technologies, then they > > > seem to be much easier going with trying out proposals. > > Regarding this > > > document: I like to get this idea worked out, documented > > > (means published) > > > and implemented since I believe the idea has merits. > > > > > > /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. > > > -- > !! 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 hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9VISD0e016154 for ; Fri, 31 Oct 2003 19:28:14 +0100 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9VIRjF00566 for ; Fri, 31 Oct 2003 12:27:51 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3WZC1A>; Fri, 31 Oct 2003 19:27:44 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502D9498F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Harrington, David" Cc: nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] getlist protocol operation Date: Fri, 31 Oct 2003 19:26:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: 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: Small companies often just do it. Bigger companies have all that overhead and (required?) interaction that you taled about. The truth is probably somehwere in the middle. Peace. Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: vrijdag 31 oktober 2003 19:21 > To: Wijnen, Bert (Bert); j.schoenwaelder@iu-bremen.de; Aiko Pras > Cc: nmrg@ibr.cs.tu-bs.de > Subject: RE: [nmrg] getlist protocol operation > > > I agree I might have been able to code it with that amount of typing, > but not all the other things that a vendor needs to do to support > various proposals. That was the point of my message. > > Thank you for pointing out how easy it is to just do the coding part. > > dbh > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Friday, October 31, 2003 1:14 PM > > To: Harrington, David; j.schoenwaelder@iu-bremen.de; Aiko Pras > > Cc: nmrg@ibr.cs.tu-bs.de > > Subject: RE: [nmrg] getlist protocol operation > > > > > > MMmm.. you seem to be a fast typist (or have lots of time to type). > > If you had pounded on the keyboard for the same amount of time but > > constructing c-code instead, then you would have implemented > > the getlist function already. > > > > Oh well... my 6 cents > > Could not resist. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Harrington, David [mailto:dbh@enterasys.com] > > > Sent: vrijdag 31 oktober 2003 18:14 > > > To: j.schoenwaelder@iu-bremen.de; Aiko Pras > > > Cc: nmrg@ibr.cs.tu-bs.de > > > Subject: RE: [nmrg] getlist protocol operation > > > > > > > > > Hi, > > > > > > IETF WGs have not done well at standardizing NMRG > > contributions, such > > > SNMP/TCP, SNMP compression, and SMING. > > > > > > Juergen has stated on a number of occasions that he feels the > > > problem is > > > old-timers unwilling to share power with a new generation. I > > > don't agree > > > with that, but then I'm considered one of the old-timers > > apparently. > > > > > > I think the problem is different than one of > power-sharing. As Andy > > > pointed out, the vendors seem to resist many of these NMRG > > > proposals. I > > > agree with that. > > > > > > As the person in my company whose job is to analyze network > > management > > > technologies and trends and make recommendations to our > > product teams > > > about whether and when to support proposed technologies in > > our product > > > lines, let me provide some insight from a vendor point of > view about > > > network management, SNMP and NMRG proposals in general. > > > > > > Before a vendor will seriously consider implementing the getlist > > > approach (or any approach), we are likely to do a (possibly rather > > > informal) return on investment analysis. If it will cost > the company > > > additional scarce resources and dollars to offer the > > feature, then we > > > will want to know that we can sell that feature to recoup > > the costs. > > > > > > The costs can be extensive. When we produce products, we > > not only need > > > to pay to have the code written, we also need have our training > > > department prepare training sessions, and we have to pay our > > > sales force > > > to take training in how the feature will benefit customers > > so they can > > > sell it approriately (and when they're in class, they are not out > > > selling), we will need to pay our field personnel to debug > > problems on > > > site, we need train our phone support personnel to handle > > > questions, and > > > if we're going to sell it we need to market it, so we need to > > > train our > > > marketing department how to present the benefits, and pay for > > > advertising, and on and on. > > > > > > If it is a change in direction, such as SMING, then we also > > > need to plan > > > how to migrate from the old technology to the new > > technology. We have > > > lots of legacy devices in the field for which customers pay > > > maintenance, > > > and we will never add the new technology to these legacy > > > devices. So we > > > will need to continue supporting the old technology even > if the new > > > technology is better. Our applications will need to be upgraded to > > > differentiate and support both the old and the new > > technologies. That > > > means all those training costs now include training new > > people in both > > > technologies. As some products are released with the new > > > technology, we > > > need to be careful not to cause our products that do not > > have the new > > > approach to stop selling. So our marketing message gets more > > > complicated, our maintenance contracts become more > > > complicated, and our > > > support program becomes more complicated. Our sales people > > may have a > > > harder time selling multiple products in our product > line, when one > > > supports the new technology and the other supports the old > > technology. > > > The saleperson, or a technical pre-sales person, needs to > be able to > > > explain how to integrate the two technologies successfully > > > (think about > > > selling a mix of your products, some of which support SNMPv3 > > > and others > > > that only support SNMPv1 - what's your marketing message? > How should > > > customers use these products in combination?) > > > > > > One of the costs of adding any new technology or new feature is > > > opportunity cost. If we spend money and resources to support > > > feature X, > > > which features do we not have the money and resources to > > > support? If we > > > need to make a decision about which features to add to > our wireless > > > access point product, should we deliver products with > 802.11a/b and > > > SNMPv1 or 802.11b only with SNMPv3? If we don't have > > 8802.11a support, > > > we can't sell our hardware. If we support SNMPv3, most > > operators won't > > > even turn it on. > > > > > > Addition of, and migration to, a new technology can be a > costly and > > > difficult thing for vendors (and for their customers), so > > > vendors resist > > > new technologies unless there is a real potential for > > customer benefit > > > and resulting increased sales. > > > > > > Now lets consider NMRG proposals. As a protocol designer, I > > > think SMING > > > was a nice protocol; I think SNMP/TCP makes sense; I think > > compression > > > makes sense; I think many of the proposals in the EOS WG made > > > sense, and > > > the new getlist proposal probably is nice as well. Good > > work on all of > > > them; as an engineer I salute your designs. > > > > > > But can a vendor recoup their costs? Are the operators > > screaming for a > > > solution to the problem it solves? Will operators (and the > > > CIO and CFO) > > > spend extra money to have that feature in a device they > > buy? Will they > > > refuse to buy a device that doesn't have it? If we put it into our > > > devices, will the operators actually use it? What other > > feature are we > > > missing the opprtunity to support by allocating resources to these > > > proposals? > > > > > > If there is no customer demand for such a feature, such > that it will > > > impact the customers' buying decisions, then why should a > > vendor spend > > > money putting it into their devices, when they could use > > the resources > > > providing features that WILL impact customer buying decisions? > > > > > > That's the problem you're faced with, much more than a > problem with > > > power-sharing in the IETF. > > > > > > If you want to see your proposal selected, I suggest you > contact the > > > authors of open source implementations and have them add > > > support for the > > > feature to their code, so that vendors who use their code > get it for > > > free. Document how people should migrate to using the new > > > technology in > > > a manner that doesn't cost vendors or their customers a lot > > > of money or > > > interruption of service. Document how people should use the new > > > technology in a mixed environment of new and old > > technology. In other > > > words, do all the things a vendor would need to do, and then > > > see if you > > > think the proposal has a high-enough return on the investment. > > > > > > If a proposal has a high enough ROI, vendors will support > > the proposal > > > and that will help you get it standardized in the IETF. If IETF > > > participants believe a proposal will help their company > > compete, they > > > will be motivated to work on it; if they think it is > > > irrelevant to their > > > company, they won't be motivated to work on it, and it will > > > probably die > > > from apathy. > > > > > > My $.04 > > > dbh > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@iu-bremen.de] > > > > Sent: Friday, October 31, 2003 10:30 AM > > > > To: Aiko Pras > > > > Cc: nmrg@ibr.cs.tu-bs.de > > > > Subject: Re: [nmrg] getlist protocol operation > > > > > > > > > > > > On Thu, Oct 30, 2003 at 01:42:09PM +0100, Aiko Pras wrote: > > > > > > > > > I have quickly read the ID; I did not read precise wording. > > > > In general I > > > > > like the idea of bumpers; they seem an elegant solution to > > > > determine the > > > > > end of the requested data. Probably a better name for > > > > GetList would be > > > > > GetRange PDU. > > > > > > > > Yes, GetRange might indeed be a better choice. > > > > > > > > > I agree with you that the new PDU would primarily be useful > > > > in situations > > > > > where TCP and compression are used. Just as with the > > > > traditional GetBulk, > > > > > in the case of UDP it may still be difficult to determine > > > > how many varbinds > > > > > fit in the response. Implementation may therefore be > > > > difficult / not > > > > > efficient. > > > > > > > > Whatever transport you choose, there will be limits on the > > > > message size > > > > so the logic to fill the PDU will be the same in all > > cases. The only > > > > difference with TCP is that the minimum max size is much > > > larger which > > > > gives you real benefits. > > > > > > > > > I'm not sure what to do with this proposal. I don't expect > > > > that new IETF > > > > > WGs will be able to come to concensus on SNMP enhancements > > > > like this one. > > > > > Therefore standardization will be unlikely. However, I > > > > still believe that > > > > > it is important to document technical proposals made by the > > > > NMRG. This is > > > > > particularly true if there are reasonable chances that > > > > these proposals get > > > > > implemented. > > > > > > > > One of the failures in SNMP land is that people always think > > > > we have to > > > > start with standards-track. If you look at other > > > > technologies, then they > > > > seem to be much easier going with trying out proposals. > > > Regarding this > > > > document: I like to get this idea worked out, documented > > > > (means published) > > > > and implemented since I believe the idea has merits. > > > > > > > > /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 ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9VILQ0e013675 for ; Fri, 31 Oct 2003 19:21:27 +0100 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA29945 for ; Fri, 31 Oct 2003 13:22:03 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma029911; Fri, 31 Oct 03 13:21:37 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 31 Oct 2003 13:20:56 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 31 Oct 2003 13:20:56 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 31 Oct 2003 13:20:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] getlist protocol operation Date: Fri, 31 Oct 2003 13:20:56 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA011395FC@NHROCMBX1.ets.enterasys.com> Thread-Topic: [nmrg] getlist protocol operation Thread-Index: AcOf2wwELptoqqX+RJWJt1lYh3FdHgAAECVg From: "Harrington, David" To: "Wijnen, Bert (Bert)" , , "Aiko Pras" Cc: X-OriginalArrivalTime: 31 Oct 2003 18:20:56.0190 (UTC) FILETIME=[B9E431E0:01C39FDB] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:99.5902 M:72.2001 P:95.9108 R:95.9108 S:75.1327 ) X-pstn-settings: 4 (0.2500:0.5000) p:13 M:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-IBRFilter-SpamReport: 0 () 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 h9VILQ0e013675 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: 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 agree I might have been able to code it with that amount of typing, but not all the other things that a vendor needs to do to support various proposals. That was the point of my message. Thank you for pointing out how easy it is to just do the coding part. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, October 31, 2003 1:14 PM > To: Harrington, David; j.schoenwaelder@iu-bremen.de; Aiko Pras > Cc: nmrg@ibr.cs.tu-bs.de > Subject: RE: [nmrg] getlist protocol operation > > > MMmm.. you seem to be a fast typist (or have lots of time to type). > If you had pounded on the keyboard for the same amount of time but > constructing c-code instead, then you would have implemented > the getlist function already. > > Oh well... my 6 cents > Could not resist. > > Thanks, > Bert > > > -----Original Message----- > > From: Harrington, David [mailto:dbh@enterasys.com] > > Sent: vrijdag 31 oktober 2003 18:14 > > To: j.schoenwaelder@iu-bremen.de; Aiko Pras > > Cc: nmrg@ibr.cs.tu-bs.de > > Subject: RE: [nmrg] getlist protocol operation > > > > > > Hi, > > > > IETF WGs have not done well at standardizing NMRG > contributions, such > > SNMP/TCP, SNMP compression, and SMING. > > > > Juergen has stated on a number of occasions that he feels the > > problem is > > old-timers unwilling to share power with a new generation. I > > don't agree > > with that, but then I'm considered one of the old-timers > apparently. > > > > I think the problem is different than one of power-sharing. As Andy > > pointed out, the vendors seem to resist many of these NMRG > > proposals. I > > agree with that. > > > > As the person in my company whose job is to analyze network > management > > technologies and trends and make recommendations to our > product teams > > about whether and when to support proposed technologies in > our product > > lines, let me provide some insight from a vendor point of view about > > network management, SNMP and NMRG proposals in general. > > > > Before a vendor will seriously consider implementing the getlist > > approach (or any approach), we are likely to do a (possibly rather > > informal) return on investment analysis. If it will cost the company > > additional scarce resources and dollars to offer the > feature, then we > > will want to know that we can sell that feature to recoup > the costs. > > > > The costs can be extensive. When we produce products, we > not only need > > to pay to have the code written, we also need have our training > > department prepare training sessions, and we have to pay our > > sales force > > to take training in how the feature will benefit customers > so they can > > sell it approriately (and when they're in class, they are not out > > selling), we will need to pay our field personnel to debug > problems on > > site, we need train our phone support personnel to handle > > questions, and > > if we're going to sell it we need to market it, so we need to > > train our > > marketing department how to present the benefits, and pay for > > advertising, and on and on. > > > > If it is a change in direction, such as SMING, then we also > > need to plan > > how to migrate from the old technology to the new > technology. We have > > lots of legacy devices in the field for which customers pay > > maintenance, > > and we will never add the new technology to these legacy > > devices. So we > > will need to continue supporting the old technology even if the new > > technology is better. Our applications will need to be upgraded to > > differentiate and support both the old and the new > technologies. That > > means all those training costs now include training new > people in both > > technologies. As some products are released with the new > > technology, we > > need to be careful not to cause our products that do not > have the new > > approach to stop selling. So our marketing message gets more > > complicated, our maintenance contracts become more > > complicated, and our > > support program becomes more complicated. Our sales people > may have a > > harder time selling multiple products in our product line, when one > > supports the new technology and the other supports the old > technology. > > The saleperson, or a technical pre-sales person, needs to be able to > > explain how to integrate the two technologies successfully > > (think about > > selling a mix of your products, some of which support SNMPv3 > > and others > > that only support SNMPv1 - what's your marketing message? How should > > customers use these products in combination?) > > > > One of the costs of adding any new technology or new feature is > > opportunity cost. If we spend money and resources to support > > feature X, > > which features do we not have the money and resources to > > support? If we > > need to make a decision about which features to add to our wireless > > access point product, should we deliver products with 802.11a/b and > > SNMPv1 or 802.11b only with SNMPv3? If we don't have > 8802.11a support, > > we can't sell our hardware. If we support SNMPv3, most > operators won't > > even turn it on. > > > > Addition of, and migration to, a new technology can be a costly and > > difficult thing for vendors (and for their customers), so > > vendors resist > > new technologies unless there is a real potential for > customer benefit > > and resulting increased sales. > > > > Now lets consider NMRG proposals. As a protocol designer, I > > think SMING > > was a nice protocol; I think SNMP/TCP makes sense; I think > compression > > makes sense; I think many of the proposals in the EOS WG made > > sense, and > > the new getlist proposal probably is nice as well. Good > work on all of > > them; as an engineer I salute your designs. > > > > But can a vendor recoup their costs? Are the operators > screaming for a > > solution to the problem it solves? Will operators (and the > > CIO and CFO) > > spend extra money to have that feature in a device they > buy? Will they > > refuse to buy a device that doesn't have it? If we put it into our > > devices, will the operators actually use it? What other > feature are we > > missing the opprtunity to support by allocating resources to these > > proposals? > > > > If there is no customer demand for such a feature, such that it will > > impact the customers' buying decisions, then why should a > vendor spend > > money putting it into their devices, when they could use > the resources > > providing features that WILL impact customer buying decisions? > > > > That's the problem you're faced with, much more than a problem with > > power-sharing in the IETF. > > > > If you want to see your proposal selected, I suggest you contact the > > authors of open source implementations and have them add > > support for the > > feature to their code, so that vendors who use their code get it for > > free. Document how people should migrate to using the new > > technology in > > a manner that doesn't cost vendors or their customers a lot > > of money or > > interruption of service. Document how people should use the new > > technology in a mixed environment of new and old > technology. In other > > words, do all the things a vendor would need to do, and then > > see if you > > think the proposal has a high-enough return on the investment. > > > > If a proposal has a high enough ROI, vendors will support > the proposal > > and that will help you get it standardized in the IETF. If IETF > > participants believe a proposal will help their company > compete, they > > will be motivated to work on it; if they think it is > > irrelevant to their > > company, they won't be motivated to work on it, and it will > > probably die > > from apathy. > > > > My $.04 > > dbh > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > > Sent: Friday, October 31, 2003 10:30 AM > > > To: Aiko Pras > > > Cc: nmrg@ibr.cs.tu-bs.de > > > Subject: Re: [nmrg] getlist protocol operation > > > > > > > > > On Thu, Oct 30, 2003 at 01:42:09PM +0100, Aiko Pras wrote: > > > > > > > I have quickly read the ID; I did not read precise wording. > > > In general I > > > > like the idea of bumpers; they seem an elegant solution to > > > determine the > > > > end of the requested data. Probably a better name for > > > GetList would be > > > > GetRange PDU. > > > > > > Yes, GetRange might indeed be a better choice. > > > > > > > I agree with you that the new PDU would primarily be useful > > > in situations > > > > where TCP and compression are used. Just as with the > > > traditional GetBulk, > > > > in the case of UDP it may still be difficult to determine > > > how many varbinds > > > > fit in the response. Implementation may therefore be > > > difficult / not > > > > efficient. > > > > > > Whatever transport you choose, there will be limits on the > > > message size > > > so the logic to fill the PDU will be the same in all > cases. The only > > > difference with TCP is that the minimum max size is much > > larger which > > > gives you real benefits. > > > > > > > I'm not sure what to do with this proposal. I don't expect > > > that new IETF > > > > WGs will be able to come to concensus on SNMP enhancements > > > like this one. > > > > Therefore standardization will be unlikely. However, I > > > still believe that > > > > it is important to document technical proposals made by the > > > NMRG. This is > > > > particularly true if there are reasonable chances that > > > these proposals get > > > > implemented. > > > > > > One of the failures in SNMP land is that people always think > > > we have to > > > start with standards-track. If you look at other > > > technologies, then they > > > seem to be much easier going with trying out proposals. > > Regarding this > > > document: I like to get this idea worked out, documented > > > (means published) > > > and implemented since I believe the idea has merits. > > > > > > /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 ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9VIFk0f011288 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 31 Oct 2003 19:15:47 +0100 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9VIFgN17102 for ; Fri, 31 Oct 2003 12:15:43 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3WZB0C>; Fri, 31 Oct 2003 19:15:41 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502D9498C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Harrington, David" , j.schoenwaelder@iu-bremen.de, Aiko Pras Cc: nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] getlist protocol operation Date: Fri, 31 Oct 2003 19:13:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: 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: MMmm.. you seem to be a fast typist (or have lots of time to type). If you had pounded on the keyboard for the same amount of time but constructing c-code instead, then you would have implemented the getlist function already. Oh well... my 6 cents Could not resist. Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: vrijdag 31 oktober 2003 18:14 > To: j.schoenwaelder@iu-bremen.de; Aiko Pras > Cc: nmrg@ibr.cs.tu-bs.de > Subject: RE: [nmrg] getlist protocol operation > > > Hi, > > IETF WGs have not done well at standardizing NMRG contributions, such > SNMP/TCP, SNMP compression, and SMING. > > Juergen has stated on a number of occasions that he feels the > problem is > old-timers unwilling to share power with a new generation. I > don't agree > with that, but then I'm considered one of the old-timers apparently. > > I think the problem is different than one of power-sharing. As Andy > pointed out, the vendors seem to resist many of these NMRG > proposals. I > agree with that. > > As the person in my company whose job is to analyze network management > technologies and trends and make recommendations to our product teams > about whether and when to support proposed technologies in our product > lines, let me provide some insight from a vendor point of view about > network management, SNMP and NMRG proposals in general. > > Before a vendor will seriously consider implementing the getlist > approach (or any approach), we are likely to do a (possibly rather > informal) return on investment analysis. If it will cost the company > additional scarce resources and dollars to offer the feature, then we > will want to know that we can sell that feature to recoup the costs. > > The costs can be extensive. When we produce products, we not only need > to pay to have the code written, we also need have our training > department prepare training sessions, and we have to pay our > sales force > to take training in how the feature will benefit customers so they can > sell it approriately (and when they're in class, they are not out > selling), we will need to pay our field personnel to debug problems on > site, we need train our phone support personnel to handle > questions, and > if we're going to sell it we need to market it, so we need to > train our > marketing department how to present the benefits, and pay for > advertising, and on and on. > > If it is a change in direction, such as SMING, then we also > need to plan > how to migrate from the old technology to the new technology. We have > lots of legacy devices in the field for which customers pay > maintenance, > and we will never add the new technology to these legacy > devices. So we > will need to continue supporting the old technology even if the new > technology is better. Our applications will need to be upgraded to > differentiate and support both the old and the new technologies. That > means all those training costs now include training new people in both > technologies. As some products are released with the new > technology, we > need to be careful not to cause our products that do not have the new > approach to stop selling. So our marketing message gets more > complicated, our maintenance contracts become more > complicated, and our > support program becomes more complicated. Our sales people may have a > harder time selling multiple products in our product line, when one > supports the new technology and the other supports the old technology. > The saleperson, or a technical pre-sales person, needs to be able to > explain how to integrate the two technologies successfully > (think about > selling a mix of your products, some of which support SNMPv3 > and others > that only support SNMPv1 - what's your marketing message? How should > customers use these products in combination?) > > One of the costs of adding any new technology or new feature is > opportunity cost. If we spend money and resources to support > feature X, > which features do we not have the money and resources to > support? If we > need to make a decision about which features to add to our wireless > access point product, should we deliver products with 802.11a/b and > SNMPv1 or 802.11b only with SNMPv3? If we don't have 8802.11a support, > we can't sell our hardware. If we support SNMPv3, most operators won't > even turn it on. > > Addition of, and migration to, a new technology can be a costly and > difficult thing for vendors (and for their customers), so > vendors resist > new technologies unless there is a real potential for customer benefit > and resulting increased sales. > > Now lets consider NMRG proposals. As a protocol designer, I > think SMING > was a nice protocol; I think SNMP/TCP makes sense; I think compression > makes sense; I think many of the proposals in the EOS WG made > sense, and > the new getlist proposal probably is nice as well. Good work on all of > them; as an engineer I salute your designs. > > But can a vendor recoup their costs? Are the operators screaming for a > solution to the problem it solves? Will operators (and the > CIO and CFO) > spend extra money to have that feature in a device they buy? Will they > refuse to buy a device that doesn't have it? If we put it into our > devices, will the operators actually use it? What other feature are we > missing the opprtunity to support by allocating resources to these > proposals? > > If there is no customer demand for such a feature, such that it will > impact the customers' buying decisions, then why should a vendor spend > money putting it into their devices, when they could use the resources > providing features that WILL impact customer buying decisions? > > That's the problem you're faced with, much more than a problem with > power-sharing in the IETF. > > If you want to see your proposal selected, I suggest you contact the > authors of open source implementations and have them add > support for the > feature to their code, so that vendors who use their code get it for > free. Document how people should migrate to using the new > technology in > a manner that doesn't cost vendors or their customers a lot > of money or > interruption of service. Document how people should use the new > technology in a mixed environment of new and old technology. In other > words, do all the things a vendor would need to do, and then > see if you > think the proposal has a high-enough return on the investment. > > If a proposal has a high enough ROI, vendors will support the proposal > and that will help you get it standardized in the IETF. If IETF > participants believe a proposal will help their company compete, they > will be motivated to work on it; if they think it is > irrelevant to their > company, they won't be motivated to work on it, and it will > probably die > from apathy. > > My $.04 > dbh > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: Friday, October 31, 2003 10:30 AM > > To: Aiko Pras > > Cc: nmrg@ibr.cs.tu-bs.de > > Subject: Re: [nmrg] getlist protocol operation > > > > > > On Thu, Oct 30, 2003 at 01:42:09PM +0100, Aiko Pras wrote: > > > > > I have quickly read the ID; I did not read precise wording. > > In general I > > > like the idea of bumpers; they seem an elegant solution to > > determine the > > > end of the requested data. Probably a better name for > > GetList would be > > > GetRange PDU. > > > > Yes, GetRange might indeed be a better choice. > > > > > I agree with you that the new PDU would primarily be useful > > in situations > > > where TCP and compression are used. Just as with the > > traditional GetBulk, > > > in the case of UDP it may still be difficult to determine > > how many varbinds > > > fit in the response. Implementation may therefore be > > difficult / not > > > efficient. > > > > Whatever transport you choose, there will be limits on the > > message size > > so the logic to fill the PDU will be the same in all cases. The only > > difference with TCP is that the minimum max size is much > larger which > > gives you real benefits. > > > > > I'm not sure what to do with this proposal. I don't expect > > that new IETF > > > WGs will be able to come to concensus on SNMP enhancements > > like this one. > > > Therefore standardization will be unlikely. However, I > > still believe that > > > it is important to document technical proposals made by the > > NMRG. This is > > > particularly true if there are reasonable chances that > > these proposals get > > > implemented. > > > > One of the failures in SNMP land is that people always think > > we have to > > start with standards-track. If you look at other > > technologies, then they > > seem to be much easier going with trying out proposals. > Regarding this > > document: I like to get this idea worked out, documented > > (means published) > > and implemented since I believe the idea has merits. > > > > /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 ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9VHEe0e020495 for ; Fri, 31 Oct 2003 18:14:40 +0100 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA24785 for ; Fri, 31 Oct 2003 12:15:19 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma024778; Fri, 31 Oct 03 12:14:26 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 31 Oct 2003 12:13:44 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 31 Oct 2003 12:13:44 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 31 Oct 2003 12:13:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] getlist protocol operation Date: Fri, 31 Oct 2003 12:13:44 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA011395F3@NHROCMBX1.ets.enterasys.com> Thread-Topic: [nmrg] getlist protocol operation Thread-Index: AcOfxAQ03xsmTw7xTDuNX/6Y+FKzxQAByXew From: "Harrington, David" To: , "Aiko Pras" Cc: X-OriginalArrivalTime: 31 Oct 2003 17:13:44.0471 (UTC) FILETIME=[56CCB270:01C39FD2] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:99.7951 M:58.5379 P:95.9108 R:95.9108 S:65.3754 ) X-pstn-settings: 4 (0.2500:0.5000) p:13 M:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-IBRFilter-SpamReport: 0 () 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 h9VHEe0e020495 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: 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, IETF WGs have not done well at standardizing NMRG contributions, such SNMP/TCP, SNMP compression, and SMING. Juergen has stated on a number of occasions that he feels the problem is old-timers unwilling to share power with a new generation. I don't agree with that, but then I'm considered one of the old-timers apparently. I think the problem is different than one of power-sharing. As Andy pointed out, the vendors seem to resist many of these NMRG proposals. I agree with that. As the person in my company whose job is to analyze network management technologies and trends and make recommendations to our product teams about whether and when to support proposed technologies in our product lines, let me provide some insight from a vendor point of view about network management, SNMP and NMRG proposals in general. Before a vendor will seriously consider implementing the getlist approach (or any approach), we are likely to do a (possibly rather informal) return on investment analysis. If it will cost the company additional scarce resources and dollars to offer the feature, then we will want to know that we can sell that feature to recoup the costs. The costs can be extensive. When we produce products, we not only need to pay to have the code written, we also need have our training department prepare training sessions, and we have to pay our sales force to take training in how the feature will benefit customers so they can sell it approriately (and when they're in class, they are not out selling), we will need to pay our field personnel to debug problems on site, we need train our phone support personnel to handle questions, and if we're going to sell it we need to market it, so we need to train our marketing department how to present the benefits, and pay for advertising, and on and on. If it is a change in direction, such as SMING, then we also need to plan how to migrate from the old technology to the new technology. We have lots of legacy devices in the field for which customers pay maintenance, and we will never add the new technology to these legacy devices. So we will need to continue supporting the old technology even if the new technology is better. Our applications will need to be upgraded to differentiate and support both the old and the new technologies. That means all those training costs now include training new people in both technologies. As some products are released with the new technology, we need to be careful not to cause our products that do not have the new approach to stop selling. So our marketing message gets more complicated, our maintenance contracts become more complicated, and our support program becomes more complicated. Our sales people may have a harder time selling multiple products in our product line, when one supports the new technology and the other supports the old technology. The saleperson, or a technical pre-sales person, needs to be able to explain how to integrate the two technologies successfully (think about selling a mix of your products, some of which support SNMPv3 and others that only support SNMPv1 - what's your marketing message? How should customers use these products in combination?) One of the costs of adding any new technology or new feature is opportunity cost. If we spend money and resources to support feature X, which features do we not have the money and resources to support? If we need to make a decision about which features to add to our wireless access point product, should we deliver products with 802.11a/b and SNMPv1 or 802.11b only with SNMPv3? If we don't have 8802.11a support, we can't sell our hardware. If we support SNMPv3, most operators won't even turn it on. Addition of, and migration to, a new technology can be a costly and difficult thing for vendors (and for their customers), so vendors resist new technologies unless there is a real potential for customer benefit and resulting increased sales. Now lets consider NMRG proposals. As a protocol designer, I think SMING was a nice protocol; I think SNMP/TCP makes sense; I think compression makes sense; I think many of the proposals in the EOS WG made sense, and the new getlist proposal probably is nice as well. Good work on all of them; as an engineer I salute your designs. But can a vendor recoup their costs? Are the operators screaming for a solution to the problem it solves? Will operators (and the CIO and CFO) spend extra money to have that feature in a device they buy? Will they refuse to buy a device that doesn't have it? If we put it into our devices, will the operators actually use it? What other feature are we missing the opprtunity to support by allocating resources to these proposals? If there is no customer demand for such a feature, such that it will impact the customers' buying decisions, then why should a vendor spend money putting it into their devices, when they could use the resources providing features that WILL impact customer buying decisions? That's the problem you're faced with, much more than a problem with power-sharing in the IETF. If you want to see your proposal selected, I suggest you contact the authors of open source implementations and have them add support for the feature to their code, so that vendors who use their code get it for free. Document how people should migrate to using the new technology in a manner that doesn't cost vendors or their customers a lot of money or interruption of service. Document how people should use the new technology in a mixed environment of new and old technology. In other words, do all the things a vendor would need to do, and then see if you think the proposal has a high-enough return on the investment. If a proposal has a high enough ROI, vendors will support the proposal and that will help you get it standardized in the IETF. If IETF participants believe a proposal will help their company compete, they will be motivated to work on it; if they think it is irrelevant to their company, they won't be motivated to work on it, and it will probably die from apathy. My $.04 dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Friday, October 31, 2003 10:30 AM > To: Aiko Pras > Cc: nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] getlist protocol operation > > > On Thu, Oct 30, 2003 at 01:42:09PM +0100, Aiko Pras wrote: > > > I have quickly read the ID; I did not read precise wording. > In general I > > like the idea of bumpers; they seem an elegant solution to > determine the > > end of the requested data. Probably a better name for > GetList would be > > GetRange PDU. > > Yes, GetRange might indeed be a better choice. > > > I agree with you that the new PDU would primarily be useful > in situations > > where TCP and compression are used. Just as with the > traditional GetBulk, > > in the case of UDP it may still be difficult to determine > how many varbinds > > fit in the response. Implementation may therefore be > difficult / not > > efficient. > > Whatever transport you choose, there will be limits on the > message size > so the logic to fill the PDU will be the same in all cases. The only > difference with TCP is that the minimum max size is much larger which > gives you real benefits. > > > I'm not sure what to do with this proposal. I don't expect > that new IETF > > WGs will be able to come to concensus on SNMP enhancements > like this one. > > Therefore standardization will be unlikely. However, I > still believe that > > it is important to document technical proposals made by the > NMRG. This is > > particularly true if there are reasonable chances that > these proposals get > > implemented. > > One of the failures in SNMP land is that people always think > we have to > start with standards-track. If you look at other > technologies, then they > seem to be much easier going with trying out proposals. Regarding this > document: I like to get this idea worked out, documented > (means published) > and implemented since I believe the idea has merits. > > /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 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 h9VGCq0e028218; Fri, 31 Oct 2003 17:12:52 +0100 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 4F8D67B2FB; Fri, 31 Oct 2003 17:12:51 +0100 (CET) Received: from james (unknown [212.201.47.4]) by merkur.iu-bremen.de (Postfix) with ESMTP id 845E27B2E8; Fri, 31 Oct 2003 17:12:50 +0100 (CET) Received: by james (Postfix, from userid 1000) id 69E4082B3; Fri, 31 Oct 2003 17:12:49 +0100 (CET) Date: Fri, 31 Oct 2003 17:12:49 +0100 From: Juergen Schoenwaelder To: George Pavlou Cc: Frank Strauss , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Minutes from the Heidelberg Meeting Message-ID: <20031031161249.GL972@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: George Pavlou , Frank Strauss , 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.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: 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 Fri, Oct 31, 2003 at 04:08:58PM +0000, George Pavlou wrote: > Will the slides be circulated or, better, put somewhere to access? > I missed the first mini-conference-meeting and I see that interesting > material was presented. I have put the slides I have received so far on the meeting page and I plan to put the other stuff there as well when I receive it. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany 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 h9VG9M0f026245 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 31 Oct 2003 17:09:22 +0100 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 1AFbpb-0006Jj-00; Fri, 31 Oct 2003 16:08:59 +0000 Received: from ees2gp (helo=eim.surrey.ac.uk) by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 1AFbpa-0003Gj-00; Fri, 31 Oct 2003 16:08:58 +0000 To: Frank Strauss cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Minutes from the Heidelberg Meeting In-Reply-To: Message from Frank Strauss of "31 Oct 2003 16:57:45 +0100." Date: Fri, 31 Oct 2003 16:08:58 +0000 From: George Pavlou Message-Id: X-Scanner: exiscan *1AFbpb-0006Jj-00*Vmq8hMJrUxU* (SECM, UniS) X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 X-Spam-Level: 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: Frank et al, > Presenters, please also remember to > send your slides from the meeting to Juergen S., since they represent > the core information from the Meeting and the Minutes refer to them. Will the slides be circulated or, better, put somewhere to access? I missed the first mini-conference-meeting and I see that interesting material was presented. Rgs, -George 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.3/8.12.3/Debian-6.6) with ESMTP id h9VFvk0f021875 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 31 Oct 2003 16:57:46 +0100 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9VFvkVd019864; Fri, 31 Oct 2003 16:57:46 +0100 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id h9VFvk3r019861; Fri, 31 Oct 2003 16:57:46 +0100 From: Frank Strauss To: nmrg@ibr.cs.tu-bs.de Date: 31 Oct 2003 16:57:45 +0100 Message-ID: Lines: 243 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: Subject: [nmrg] Minutes from the Heidelberg 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: Hi! Here are the Minutes from our 14th Meeting at the NEC Network Labs in Heidelberg after integrating the notes from Juergen Q. Please send any final comments/corrections/additions you want to see in the Minutes to me within one week (until Friday, 2003-11-07), so that we can publish the final Minutes on 2003-11-10. Presenters, please also remember to send your slides from the meeting to Juergen S., since they represent the core information from the Meeting and the Minutes refer to them. -frank 14th NMRG Meeting, 2003-10-19 NEC Europe Ltd., Network Laboratories, Heidelberg, Germany Attendees: 1. MB Marcus Brunner (NEC Europe, Germany) 2. OC Omar Cherkaoui (University of Montreal, Canada) 3. TD Thomas Drevers (University of Twente, The Netherlands) 4. JH James Won-Ki Hong (Postech, Korea) 5. MM Maurizio Molina (NEC Europe, Germany) (until 13:30) 6. JP Jean-Philippe Martin-Flatin (CERN, Switzerland) 7. DP David Perkins (SNMPinfo, USA) 8. AP Aiko Pras (University of Twente, The Netherlands) 9. JQ Juergen Quittek (NEC Europe, Germany) 10. JS Juergen Schoenwaelder (International University Bremen, Germany) 11. RS Radu State (LORIA-INRIA, France) 12. FS Frank Strauss (TU Braunschweig, Germany) 13. RM Remco van de Meent (University of Twente, The Netherlands) 14. MV Matjaz Vrecko (MG Soft, Slovenia) 15. OW Oliver Wellnitz (TU Braunschweig, Germany) Agenda: 11:00 Welcome 11:10 NEC Introduction and Overview of Ongoing Projects (Marcus Brunner) 11:30 Measuring Network Traffic (Remco van de Meent) 12:30 Lunch 13:30 SyncML Device Management (Radu State) 14:30 Coffee Break 15:00 Performance of Web Services compared to traditional SNMP (Thomas Drevers) 16:00 Coffee Break 16:30 Session-based Security Model for SNMPv3 (Dave Perkins) 17:30 Wrap-up 17:45 Meeting Ends The meeting starts at 11:15. FS and JQ take notes, FS will compile them into one text. JQ invites the attendees to have dinner and whiskey tasting at his home. :-) 11:20 NEC Introduction and Overview of Ongoing Projects (MB) ------------------------------------------------------------ MB presents [see the applied PDF file] an overview of the topics and projects being worked on in his group at the NEC Network Laboratories in Heidelberg (3GPP, DHCPv6, IP-based Radio Access Networks, ...). He presents problems observed with SNMPv3: (1) No filtering of Get requests like in CMIP. (2) It's complicated to keep an mgmt system in sync with managed nodes if changes are done via CLI. (3) Checking the overall health of boxes requires a lot of requests Idea on (3): "One-Stop Health Check": aggregate various health information into a single object. JS notices that the DISMAN-EVENT/EXPRESSION-MIBs cover this. MB/JQ: The DISMAN MIBs are way to complicated, that's why they did not succeed. We want to set a strict focus on box health and keep it simple. 11:55 Measuring Network Traffic (RM) ------------------------------------ RM gives a presentation [see the applied PDF file] on what he's doing for his PhD on high-speed network traffic measurements. The measurements have been done at the University of Twente and two other research institutions at the routers that connect the institutions to their Internet providers. the measurements deliver characteristics of the traffic, such as flows being created per second, flow duration profiles, and application profiles. Observations: 90% of the local traffic is SMB, 10% of the incoming/outgoing traffic is unknown. The project shows that decent hardware is sufficient for even detailed measurements. Discussion: Page 12: We want to find the "clouds of most relevance", so that we come up with the result on page 13. JH: Can you address the specific characteristics of QoS premium class traffic? RM: No, we assume carriers to do reasonable overprovisioning instead of QoS management. AP presents some additional numbers from UT that show, that faculties retrieve much more traffic via file sharing from student houses than vice versa. :-) JS asks to what degree the traffic is anonymized. RM: IP addresses are changed, but mappings are retained. JS: However, you might be able to map back to the users based on other packet characteristics. This might be an issue, if you want to find other people doing such measurements. JP/JQ: It becomes an issue of national laws. MM: A challenging problem is to build models also for the traffic that we cannot yet identify. Protocols like HTTP are the easy cases, but in some situations the yet unidentified traffic is significant. AP: We assume it's right to follow both approaches in parallel: (a) doing careful measurements and analyzing them and (b) trying to come up with methematical models. JQ mentions that it would be reasonable to coordinate with the IRTF IMRG. References: Packet trace anonymization through tcpdpriv: http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html (13:25 Coffee Break) 13:35 SyncML Device Management (RS) ----------------------------------- Radu State reports on SyncML [see the applied PDF file] The general motivation for this discussion within the NMRG is not to do work twice. The SyncML initiative is a broadly supported effort towards universal data synchronization. Several manufacturers jointly proposed a standardized framework for device synchronization using a common data model based on XML, that was extended to be used also for device management. LORIA-INRIA has developed an open-source agent toolkit built around the SyncML model and evaluated the performance and cost of this approach in the context of limited devices supposed to host management agents. Discussion: Page 25: JS: It seems a bit strange that e.g. in case of HTTP as the transport, management requests are encapsulated in HTTP responses. DP: How is authentication done: RS: By shared secrets and MD5. JQ/RS: Clarification: The SyncML Forum is now part of the Open Mobile alliance (OMA). AP: What about interoperabilty between vendors. RS: Interoperability has been prooved for synchronization by several vendors. AP: Would you propose that the NETCONF WG should look at this or use this? RS: NETCONF's initial effort by Juniper was good and driven in combination with a data model, but now that the data model is completely taken aside and security is still missing, NETCONF is like an empty shell. JS: NETCONF will address both issues in the future. JQ: Could the NETCONF people learn from SyncML? RS: Yes, they can. DP/RS: Clarification on access control: ACLs are attached to instances. If an object has no ACL, it is inherited from its parent(s). You cannot have ACL properties for objects that do not yet exist, they have to be provided upon instantiation. (14:40 Lunch Break) 16:10 Performance of Web Services compared to traditional SNMP (TD) ------------------------------------------------------------------- AP gives a short overview of what some people at UT have done and are doing related to Web Services in the area of NM. Then TD gives a presentation [see the applied PDF file] on a comparison of SOAP and SNMP for monitoring. He developed an implementation that compares both for accessing different portions of the IF-MIB. The network usage was high for uncompressed SOAP, but comparable to SNMP for compressed SOAP. memory and CPU usage was higher for SNMP, but this may be caused by the used NET-SNMP implementation. The total operation time (over a fast link) was much higher for SNMP. The measurement of total time does include encoding and decoding at the SNMP manager. The (slightly surprising) conclusion is that there is no significant performance penalty when compressed XML is used instead of SNMP. Rather an increase in speed is possible. Discussion: JS/TD: Compressed data was well compressable, because most counters were zero because of unused virtual interfaces, so the results have to be interpreted carefully. The very bad CPU usage of NET-SNMP is caused by the fact that for every cell, the whole table is looked up, while in case of the Web Service, you have to fetch the whole table just once to deliver all its cells. For SNMP "walk" that can not be solved by caching, for SNMP GetBulk caching could improve performance, but it is not implemented in NET-SNMP. JP: Is XML validation of the exchanged XML infosets reasonable or even required? Conclusion: A recomendation is out of scope here, but it would be good to have a camparison of footprint and CPU usage with and without validation. DP/TD: Clarification: Operation time is from encoding the request until decoding the response(s). Tests were made on a 1GHz Intel GNU/Linux PC. AP's conclusion from these results: SNMP is good for retrieving single cells; that's what it has been primarily designed for. For larger amounts of data, Web Services win, especially when compression is used. JS: Compressed WS should not be compared to uncompressed SNMP. JS asks to make not only the result but also the code that was used to get the results available. DP/TD: gSOAP's XML message parser is optimized based on the expected messages; this makes it quite efficient. (17:25 Coffee Break) 17:35 Session-based Security Model for SNMPv3 (DP) -------------------------------------------------- DP presents [see the applied PDF file] work he has done together with Wes Hardaker (slides not reviewed by Wes) on a session-oriented security model for SNMP. Basically this model replaces the USM by a model that does not need authentication for every message. The model is still under development. JS has doubts how relevant this work is. It seems complicated in terms of key management similar to the former party based security model for SNMPv2. He would prefer to use something like TCP/TLS since it (a) is easier to implement and (b) people might have more trust that the TLS library has already been debugged. DP responds that the proposed work does work with any SNMP transport. References: draft-hardaker-snmp-session-sm-00.txt 18:35 Wrap-up ------------- JS asks to send in the presented slides. The meeting ends at 18:40. 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 h9VFTl0e010623 for ; Fri, 31 Oct 2003 16:29:47 +0100 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id BA3147B317; Fri, 31 Oct 2003 16:29:46 +0100 (CET) Received: from james (unknown [212.201.47.4]) by merkur.iu-bremen.de (Postfix) with ESMTP id 441DE7B313; Fri, 31 Oct 2003 16:29:44 +0100 (CET) Received: by james (Postfix, from userid 1000) id 1AF6082B3; Fri, 31 Oct 2003 16:29:44 +0100 (CET) Date: Fri, 31 Oct 2003 16:29:44 +0100 From: Juergen Schoenwaelder To: Aiko Pras Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] getlist protocol operation Message-ID: <20031031152944.GC972@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Aiko Pras , nmrg@ibr.cs.tu-bs.de References: <20031027161842.GA902@iu-bremen.de> <3FA10721.5090800@ctit.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA10721.5090800@ctit.utwente.nl> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 X-Spam-Level: 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 Thu, Oct 30, 2003 at 01:42:09PM +0100, Aiko Pras wrote: > I have quickly read the ID; I did not read precise wording. In general I > like the idea of bumpers; they seem an elegant solution to determine the > end of the requested data. Probably a better name for GetList would be > GetRange PDU. Yes, GetRange might indeed be a better choice. > I agree with you that the new PDU would primarily be useful in situations > where TCP and compression are used. Just as with the traditional GetBulk, > in the case of UDP it may still be difficult to determine how many varbinds > fit in the response. Implementation may therefore be difficult / not > efficient. Whatever transport you choose, there will be limits on the message size so the logic to fill the PDU will be the same in all cases. The only difference with TCP is that the minimum max size is much larger which gives you real benefits. > I'm not sure what to do with this proposal. I don't expect that new IETF > WGs will be able to come to concensus on SNMP enhancements like this one. > Therefore standardization will be unlikely. However, I still believe that > it is important to document technical proposals made by the NMRG. This is > particularly true if there are reasonable chances that these proposals get > implemented. One of the failures in SNMP land is that people always think we have to start with standards-track. If you look at other technologies, then they seem to be much easier going with trying out proposals. Regarding this document: I like to get this idea worked out, documented (means published) and implemented since I believe the idea has merits. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany 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 h9UCgC0e022382 for ; Thu, 30 Oct 2003 13:42:13 +0100 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 h9UCgASd020025; Thu, 30 Oct 2003 13:42:10 +0100 (MET) Received: from ctit.utwente.nl (utip250 [130.89.12.39]) by zeus.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id h9UCg8Fx011982; Thu, 30 Oct 2003 13:42:08 +0100 (MET) Message-ID: <3FA10721.5090800@ctit.utwente.nl> Date: Thu, 30 Oct 2003 13:42:09 +0100 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] getlist protocol operation References: <20031027161842.GA902@iu-bremen.de> In-Reply-To: <20031027161842.GA902@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: 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 Schoenwaelder wrote: > ... I came up with the following getlist proposal which > I attach to this message. > > I would like to hear your opinions whether (a) there is something > technically wrong or suboptimal that can be improved and (b) whether > you in general see value in such a conservative approach or completely > disagree with it. (Just try to keep the technical aspects separated > from the requirements for new PDUs.) I have quickly read the ID; I did not read precise wording. In general I like the idea of bumpers; they seem an elegant solution to determine the end of the requested data. Probably a better name for GetList would be GetRange PDU. I agree with you that the new PDU would primarily be useful in situations where TCP and compression are used. Just as with the traditional GetBulk, in the case of UDP it may still be difficult to determine how many varbinds fit in the response. Implementation may therefore be difficult / not efficient. I'm not sure what to do with this proposal. I don't expect that new IETF WGs will be able to come to concensus on SNMP enhancements like this one. Therefore standardization will be unlikely. However, I still believe that it is important to document technical proposals made by the NMRG. This is particularly true if there are reasonable chances that these proposals get implemented. Bye Aiko 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 h9SG0NpJ024366; Tue, 28 Oct 2003 17:00:24 +0100 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 86A397B1B3; Tue, 28 Oct 2003 17:00:20 +0100 (CET) Received: from james (unknown [212.201.47.4]) by merkur.iu-bremen.de (Postfix) with ESMTP id B4D2F7B081; Tue, 28 Oct 2003 17:00:18 +0100 (CET) Received: by james (Postfix, from userid 1000) id A1A8D7E6D; Tue, 28 Oct 2003 17:00:18 +0100 (CET) Date: Tue, 28 Oct 2003 17:00:18 +0100 From: Juergen Schoenwaelder To: Frank Strauss Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Preliminary Minutes from the Heidelberg Meeting Message-ID: <20031028160018.GA2497@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strauss , 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.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 Fri, Oct 24, 2003 at 07:18:55PM +0200, Frank Strauss wrote: > Here are my preliminary notes from the meeting. Optionally, if anyone > else has taken some notes, he would be willing to supply, that would > be welcome. I intend to compile the final notes real soon. Thanks for getting this out so quickly. A few comments: > code that was used to get the results available. DP/TD: gSOAP's XML > message parser is optimized based on the expected massages; this makes > it quite efficient. s/massages/messages > JS has doubts how relevant this work is. It seems complicated in terms > of key management similar to the former party based security model for > SNMPv2. TCP/TLS looks more managable and well known to people. Well, I think this is not a really accurate thing. I just said that I would prefer to use something like TCP/TLS since it (a) is easier for me to implement and (b) I have some trust that the TLS library has already been debugged. Dave rightfully responded that the proposed work does work with any SNMP transport, which I agree is a fine thing but has some costs. /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 h9RGIipJ020675 for ; Mon, 27 Oct 2003 17:18:44 +0100 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id BBF237AF06; Mon, 27 Oct 2003 17:18:43 +0100 (CET) Received: from james (unknown [212.201.47.4]) by merkur.iu-bremen.de (Postfix) with ESMTP id B0E945696F; Mon, 27 Oct 2003 17:18:42 +0100 (CET) Received: by james (Postfix, from userid 1000) id A8EC67E6D; Mon, 27 Oct 2003 17:18:42 +0100 (CET) Date: Mon, 27 Oct 2003 17:18:42 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20031027161842.GA902@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: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.3 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] getlist protocol operation 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: --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Having seen Aiko's performance measurements, I went back to the old getsubtree proposal (and the getcols proposal submitted to EOS as well as the object-oriented PDU proposal) and based on a recent article in the Simple Times, I came up with the following getlist proposal which I attach to this message. This proposal tries to be very conservative in that it does not expect any new capabilities in the protocol engine. It just tries to fix the getbulk behaviour where the manager has to guess good values for max-repetitions. I would like to hear your opinions whether (a) there is something technically wrong or suboptimal that can be improved and (b) whether you in general see value in such a conservative approach or completely disagree with it. (Just try to keep the technical aspects separated from the requirements for new PDUs.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="getlist.txt" NMRG J. Schoenwaelder Internet-Draft International University Bremen Expires: April 23, 2004 October 24, 2003 GetList Operation for the Simple Network Management Protocol (SNMP) draft-irtf-nmrg-snmp-getlist-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines the GetListRequest-PDU for the Simple Network Management Protocol (SNMP). The GetListRequest-PDU enabled a command generator to read a large amount of management information with a minimum number of protocol operations and without having to guess a suitable repetition count and without reading data beyond the information the command generator is interested in (overshoot effect). Schoenwaelder Expires April 23, 2004 [Page 1] Internet-Draft GetList Operation for SNMP October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Retrieving Columns from a Single Table . . . . . . . . . . . . 7 4.2 Retrieving Columns from Multiple Tables . . . . . . . . . . . 7 4.3 Retrieving Tables with Holes . . . . . . . . . . . . . . . . . 8 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Schoenwaelder Expires April 23, 2004 [Page 2] Internet-Draft GetList Operation for SNMP October 2003 1. Introduction The second version of the protocol operations for the Simple Network Management Protocol (SNMP) defined in RFC 3416 [RFC3416] introduce the GetBulkRequest-PDU for reading large amounts of management information. The GetBulkRequest-PDU can be seen as a generalization of the GetNextRequest-PDU since it basically asks the command generator to perform repeated get-next operations internally. The max-repetitions parameter in the GetBulkRequest-PDU defines the maximum number of repetitions. The command responder might perform fewer repetitions taking into account constraints for the response message or other processing constrains. The usage of the GetBulkRequest-PDU has shown some problems. First, command generators often do not know a suitable value for the max-repetitions parameter. If the parameter is chosen too small, more requests are needed which reduces the overall benefit. If the max-repetitions parameter is set too large, several variables might be retrieved that are not interesting for the command generator and subsequently discarded (overshoot effect). This can have severe effects if the retrieval of the unwanted data internally within the command generator is expensive [STBULK]. This memo introduces the GetListRequest-PDU which addresses these issues with the GetBulkRequest-PDU while otherwise following the same design principles: 1. The GetListRequest-PDU operates like all other SNMP PDUs on a lexicographically ordered list of instances and does not just assume and knowledge about conceptual tables. 2. The GetListRequest-PDU uses the same PDU format as all other SNMP PDUs. 3. The GetListRequest-PDU keep the non-repetitions parameter of the GetBulkRequest-PDU since it is often required to retrieve the value of sysUpTime in addition to other variables (especially for counter variables). 4. The GetListRequest-PDU requires no knowledge of the MIBs supported by an application and it can be used with existing instrumentations and extensible agent protocols such as AgentX . 5. The GetListRequest-PDU deals with holes or columns from conceptual tables with different sizes in way to which avoids the retrieval of uninteresting data. The basic improvement over the GetBulkRequest-PDU is to replace the Schoenwaelder Expires April 23, 2004 [Page 3] Internet-Draft GetList Operation for SNMP October 2003 max-repetitions parameter with a number of bumper object identifiers (OIDs) which define where the processing should stop, thus avoiding the need to estimate a suitable value for the max-repetitions parameter and any overshoots. The idea to use bumper OIDs (or short bumpers) was first introduced in [STBUMP]. The GetListRequest-PDU belongs to the Read class and the Confirmed class as defined in RFC 3411 [RFC3411]. 2. Definitions NMRG-SNMP-GETLIST-PDU DEFINITIONS ::= BEGIN IMPORTS VarBindList, max-bindings FROM SNMPv2-PDU; GetListRequest-PDU ::= [9] IMPLICIT -- xxx IANA, can we use [9] ?? GetListPDU GetListPDU ::= -- identical in structure to PDU SEQUENCE { request-id INTEGER (-2147483648..2147483647), non-repeaters INTEGER (0..max-bindings), bumpers -- number of bumper varbinds INTEGER (0..max-bindings), variable-bindings -- values are ignored VarBindList } END 3. Elements of Procedure A GetListRequest-PDU is generated and transmitted at the request of an application. The purpose of the GetListRequest-PDU is to request the transfer of a potentially large amount of data, including, but not limited to, the efficient and rapid retrieval of large tables. Upon receipt of a GetListRequest-PDU, the receiving SNMP entity processes each variable binding in the variable-binding list to produce a Response-PDU with its request-id field having the same Schoenwaelder Expires April 23, 2004 [Page 4] Internet-Draft GetList Operation for SNMP October 2003 value as in the request. The values of the non-repeaters (N) and bumpers (B) field together with the first elements in the variable bindings specify the processing requested. One variable binding in the Response-PDU is requested for the first N variable bindings in the request. The following B elements in the variable bindings are so called bumpers which split the list of lexicographically ordered variables into sublists. Multiple variable bindings are requested for each of the remaining (R) variable bindings in the request. If N is greater than zero, the first through the (N)-th variable bindings of the Response-PDU are each produced as follows: 1. The variable is located which is in the lexicographically ordered list of the names of all variables which are accessible by this request and whose name is the first lexicographic successor of the variable binding's name in the incoming GetListRequest-PDU. The corresponding variable binding's name and value fields in the Response-PDU are set to the name and value of the located variable 2. If the requested variable binding's name does not lexicographically precede the name of any variable accessible by this request, i.e., there is no lexicographic successor, then the corresponding variable binding produced in the Response-PDU has its value field set to "endOfMibView", and its name field set to the variable binding's name in the request. If B is greater than zero, the next B variable bindings are conceptually copied into the bumpers list (BL). If R is non-zero, the remaining variable bindings in the request are conceptually copied into the repeater list (RL). The (N + 1)-th and subsequent variable bindings of the Response-PDU are each produced in a similar manner: 1. Select the first element of the repeater list RL and the first element of the bumpers list BL. 2. The variable is located which is in the lexicographically ordered list of the names of all variables which are accessible by this request and whose name is the first lexicographic successor of the selected variable binding's name in the repeater list RL. 3. If the name of the located variable is lexicographically smaller than the name of the selected variable binding's name in the bumpers list BL, then the variable binding's name and value fields in the Response-PDU are set to the name and value of the located variable. The selected element in the repeater list RL is Schoenwaelder Expires April 23, 2004 [Page 5] Internet-Draft GetList Operation for SNMP October 2003 update with the name of the located variable. 4. Otherwise, the variable binding's name field in the Response-PDU is set to the name of the selected bumpers variable binding and the variable binding's value field is set to "endOfMibView". The selected elements are marked as "done" in the repeater list RL and the bumpers list BL. 5. The next element in the repeater list RL and the next element in the bumpers list BL which is not yet marked "done" is selected. If the end of the lists is reached, the first or a subsequent element not yet marked "done" is selected. Processing stops if no such element exists. Goto step number 2 if new elements were selected. While the GetListRequest-PDU retrieves all the requested lists of variables, the response may be generated with a lesser number of variable bindings (possibly zero) for either of two reasons. 1. If the size of the message encapsulating the Response-PDU containing the requested number of variable bindings would be greater than either a local constraint or the maximum message size of the originator, then the response is generated with a lesser number of variable bindings. This lesser number is the ordered set of variable bindings with some of the variable bindings at the end of the set removed, such that the size of the message encapsulating the Response-PDU is approximately equal to but no greater than either a local constraint or the maximum message size of the originator. Note that the number of variable bindings removed has no relationship to the values of N, B, or R. 2. In the event that the processing of a request with many repetitions requires a significantly greater amount of processing time than a normal request, then a command responder application may terminate the request with less than the full number of repetitions, providing at least one repetition is completed. If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetListRequest-PDU, with the value of its error-status field set to "genErr", and the value of its error-index field is set to the index of the variable binding in the original request which corresponds to the failed variable binding. Otherwise, the value of the Response-PDU's error-status field is set to "noError", and the value of its error-index field to zero. Schoenwaelder Expires April 23, 2004 [Page 6] Internet-Draft GetList Operation for SNMP October 2003 The generated Response-PDU (possibly with an empty variable-bindings field) is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetListRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. 4. Examples The following examples assume that an agent implements the ifTable and ifXTable of the IF-MIB [RFC2863] with five rows (identified by the ifIndex values 1 to 5) and the ipNetToMediaTable of the IP-MIB [RFC2011] with two rows (identified by 192.0.2.1, 192.0.2.25). 4.1 Retrieving Columns from a Single Table Retrieve the values for ifAdminStatus and ifOperStatus for all rows in the ifTable (assuming that only seven variable bindings fit into a Response-PDU). GetListRequest [ non-repeaters = 1, bumpers = 2 ] ( sysUpTime, ifOperStatus, ifLastChange, ifAdminStatus, ifOperStatus ) Response ( sysUpTime.0 = "12", ifAdminStatus.1 = "up", ifOperStatus.1 = "up", ifAdminStatus.2 = "up", ifOperStatus.2 = "up", ifAdminStatus.3 = "up", ifOperStatus.3 = "down" ) GetListRequest [ non-repeaters = 1, bumpers = 2 ] ( sysUpTime, ifOperStatus, ifLastChange, ifAdminStatus.3, ifOperStatus.3 ) Response ( sysUpTime.0 = "13", ifAdminStatus.4 = "up", ifOperStatus.4 = "down", ifAdminStatus.5 = "up", ifOperStatus.5 = "down", ifOperStatus = [endOfMibView], ifLastChange = [endOfMibView] ) 4.2 Retrieving Columns from Multiple Tables Retrieve the values of ifDescr, ifName, ipAdEntAddr, ipAdEntIfIndex, ipAdEntNetMask for all rows in the ifTable and the ipAdEntTable (assuming that only nine variable bindings fit into a Response-PDU). Schoenwaelder Expires April 23, 2004 [Page 7] Internet-Draft GetList Operation for SNMP October 2003 GetListRequest [ non-repeaters = 1, bumpers = 4 ] ( sysUpTime, ifType, ifInMulticastPkts, ipAdEntNetMask, ipAdEntBcastAddr, ifDescr, ifName, ipAdEntIfIndex, ipAdEntNetMask ) Response ( sysUpTime = "32", ifDescr.1 = "lo", ifName.1 = "lo", ipAdEntIfIndex.127.0.0.1 = "1", ipAdEntNetMask.127.0.0.1 = "255.0.0.0", ifDescr.2 = "eth0", ifName.2 = "eth0", ipAdEntIfIndex.192.0.2.1 = "2", ipAdEntNetMask.192.0.2.1 = "255.255.255.0" ) GetListRequest [non-repeaters = 1, bumpers = 4 ] ( sysUpTime, ifType, ifInMulticastPkts, ipAdEntNetMask, ipAdEntBcastAddr, ifDescr.2, ifName.2, ipAdEntIfIndex.192.0.2.1, ipAdEntNetMask.192.0.2.1 ) Response ( sysUpTime = "33", ifDescr.3 = "eth1", ifName.3 = "eth1", ipAdEntNetMask = [endOfMibView], ipAdEntNetMask = [endOfMibView], ifDescr.4 = "eth2", ifName.4 = "eth4", ifDescr.5 = "eth3", ifName.5 = "eth3" ) GetListRequest [non-repeaters = 1, bumpers = 2 ] ( sysUpTime, ifType, ifInMulticastPkts, ifDescr.5, ifName.5 ) Response ( sysUpTime = "34", ifType = [endOfMibView], ifInMulticastPkts = [endOfMibView] ) 4.3 Retrieving Tables with Holes Retrieve the values of ifDescr and ifAlias. Assume that the instance ifAlias.2 does not exist in the MIB view (assuming that twelve variable bindings fit into a Response-PDU). GetListRequest [ non-repeaters = 1, bumpers = 2 ] ( sysUpTime, ifType, ifCounterDiscontinuityTime, ifDescr, ifAlias ) Response ( sysUpTime = "42", ifDescr.1 = "lo", ifAlias.1 = "loopback interface", ifDescr.2 = "eth0", ifAlias.3 = "", Schoenwaelder Expires April 23, 2004 [Page 8] Internet-Draft GetList Operation for SNMP October 2003 ifDescr.3 = "eth1", ifAlias.4 = "", ifDescr.4 = "eth2", ifAlias.5 = "", ifDescr.5 = "eth3", ifCounterDiscontinuityTime = [endOfMibView], ifType = [endOfMibView] ) 5. Discussion Many proposals have been developed so far to improve the bulk retrieval performance characteristics of SNMP. The proposed solutions range from rather simple to rather drastic changes and additions to the existing protocol. The new PDU proposed in this memo certainly falls into the first category. By using this new PDU in combination with OID compression techniques and transports supporting larger message sizes (such as SNMP over TCP [RFC3430]), significant performance improvements can be achieved since (a) the manager does not have to guess a suitable value for the max-repetitions parameter of the GetBulkRequest-PDU and holes are handled in a way which avoids to return variables which are of no value for the command generator. Dave Perkins proposed a GetColsRequest-PDU which is more powerful than the GetListRequest-PDU described in this memo. The GetColsRequest-PDU operates on conceptual rows and supports a filter expression to select the desired rows. The response is returned in a compact encoding which suppresses redundant OID components. However, the GetColsRequest-PDU does not allow to retrieve data from multiple arbitrary tables with a single request and it requires that the SNMP engine has knowledge about table indexing to be able to extract values of auxiliary objects by unpacking instance identifiers. Wes Hardacker proposed a set of object-oriented PDUs which provide many new features. The processing of these PDUs requires MIB knowledge in the SNMP engine. The EOS working group of the IETF was not able to achieve consensus on these new object-oriented PDUs. 6. Acknowledgements The Network Management Research Group (NMRG) has discussed bulk data retrieval improvements for SNMP in several meetings. This document was inspired by many ideas that came up during these discussions. The submissions to the EOS IETF working group further helped to shape this document. The idea to introduce bumper objects to mark the end of lists was first described by M. Malowidzki [STBUMP]. Some paragraphs and phrases are taken from the second version of the protocol operations for the Simple Network Management Protocol (SNMP) Schoenwaelder Expires April 23, 2004 [Page 9] Internet-Draft GetList Operation for SNMP October 2003 [RFC3416] written by R. Presuhn, J. Case, K. McCloghrie, M. Rose, and S. Waldbusser. Normative References [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. Informative References [STBULK] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB Data", Simple Times 7(1), March 1999. [STBUMP] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), December 2002. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping", RFC 3430, December 2002. Author's Address Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Schoenwaelder Expires April 23, 2004 [Page 10] Internet-Draft GetList Operation for SNMP October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Schoenwaelder Expires April 23, 2004 [Page 11] Internet-Draft GetList Operation for SNMP October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schoenwaelder Expires April 23, 2004 [Page 12] --cWoXeonUoKmBZSoM-- 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 h9RBm7pJ007602 for ; Mon, 27 Oct 2003 12:48:07 +0100 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id E45797A816; Mon, 27 Oct 2003 12:48:06 +0100 (CET) Received: from james (unknown [212.201.47.56]) by merkur.iu-bremen.de (Postfix) with ESMTP id 0524D1AD4F; Mon, 27 Oct 2003 12:48:06 +0100 (CET) Received: by james (Postfix, from userid 1000) id C7B047E6D; Mon, 27 Oct 2003 12:48:05 +0100 (CET) Date: Mon, 27 Oct 2003 12:48:05 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] nmrg publications Message-ID: <20031027114805.GA2863@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de References: <20031022094449.GF1708@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031022094449.GF1708@iu-bremen.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 Wed, Oct 22, 2003 at 11:44:49AM +0200, Juergen Schoenwaelder wrote: > There are in addition papers written by NMRG participants that are not > really core NMRG publications, but which have been influenced by > NMRG discussions. Usually such papers acknowledge the NMRG somewhere. > I would like to compile a list of these papers as well but I need your > help. I have updated the NMRG web page with the list of documents which somehow acknowledge the NMRG. Please check and let me know if you think there is something missing or incorrect. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany 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.3/8.12.3/Debian-6.6) with ESMTP id h9PB5kpK004696 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 25 Oct 2003 13:05:46 +0200 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9PB5kVd009048; Sat, 25 Oct 2003 13:05:46 +0200 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id h9PB5kGS009045; Sat, 25 Oct 2003 13:05:46 +0200 From: Frank Strauss To: j.schoenwaelder@iu-bremen.de Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] nmrg publications References: <20031022094449.GF1708@iu-bremen.de> Date: 25 Oct 2003 13:05:46 +0200 In-Reply-To: <20031022094449.GF1708@iu-bremen.de> Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 "grep NMRG"'ed through the RFCs and I-Ds and found these: - RFC 3216 has been influenced significantly by the NMRG. - RFC 2975 refers to some extent to the NMRG. - Another expired working document is draft-ietf-sming-compl-00.txt. (It has been done for the SMING WG, but it covers NMRG work.) -frank Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9OLbZpK001633 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 24 Oct 2003 23:37:37 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9OLbVN18743 for ; Fri, 24 Oct 2003 16:37:32 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3WTSXJ>; Fri, 24 Oct 2003 23:37:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502C82C46@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Wes Hardaker , Branislav Meandzija Cc: "Nmrg (E-mail)" Subject: RE: [nmrg] Re: CAPWAP work Date: Fri, 24 Oct 2003 23:37:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 Thu, 23 Oct 2003 09:45:47 +0200, Juergen > Schoenwaelder said: > > Juergen> I am curious what you believe the complexity of NETCONF > Juergen> is. > > I think NETCONF has lots of complexity that aren't yet apparent, but > will be a result of decisions being made now. > Wes, pls point them out as much as possible as decision are being proposed and/or driven to consensus. If NetConf is gonna be too complex, we are NOT achieving our goal of wide implementation and deployment. Bert > -- > Wes Hardaker > Sparta > -- > !! 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 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.3/8.12.3/Debian-6.6) with ESMTP id h9OHItpK013204 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 24 Oct 2003 19:18:55 +0200 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9OHItVd019450; Fri, 24 Oct 2003 19:18:55 +0200 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id h9OHItPi019447; Fri, 24 Oct 2003 19:18:55 +0200 From: Frank Strauss To: nmrg@ibr.cs.tu-bs.de Date: 24 Oct 2003 19:18:55 +0200 Message-ID: Lines: 208 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -6.4 () USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.3 required=5.0 tests=USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Preliminary Minutes from the Heidelberg 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: Hi! Here are my preliminary notes from the meeting. Optionally, if anyone else has taken some notes, he would be willing to supply, that would be welcome. I intend to compile the final notes real soon. For those who did not attend the meeting: We had four well prepared presentations based on slides, which will hopefully be also available soon. The notes below do not cover the contents of this material, but just the discussions. -frank 14th NMRG Meeting, 2003-10-19 NEC Europe Ltd. Network Laboratories, Heidelberg, Germany Attendees: 1. MB Marcus Brunner (NEC Europe, Germany) 2. OC Omar Cherkaoui (University of Montreal, Canada) 3. TD Thomas Drevers (University of Twente, The Netherlands) 4. JH James Won-Ki Hong (Postech, Korea) 5. MM Maurizio Molina (NEC Europe, Germany) (until 13:30) 6. JP Jean-Philippe Martin-Flatin (CERN, Switzerland) 7. DP David Perkins (SNMPinfo, USA) 8. AP Aiko Pras (University of Twente, The Netherlands) 9. JQ Juergen Quittek (NEC Europe, Germany) 10. JS Juergen Schoenwaelder (International University Bremen, Germany) 11. RS Radu State (LORIA-INRIA, France) 12. FS Frank Strauss (TU Braunschweig, Germany) 13. RM Remco van de Meent (University of Twente, The Netherlands) 14. MV Matjaz Vrecko (MG Soft, Slovenia) 15. OW Oliver Wellnitz (TU Braunschweig, Germany) Agenda: 11:00 Welcome 11:10 NEC Introduction and Overview of Ongoing Projects (Marcus Brunner) 11:30 Measuring Network Traffic (Remco van de Meent) 12:30 Lunch 13:30 SyncML Device Management (Radu State) 14:30 Coffee Break 15:00 Performance of Web Services compared to traditional SNMP (Thomas Drevers) 16:00 Coffee Break 16:30 Session-based Security Model for SNMPv3 (Dave Perkins) 17:30 Wrap-up 17:45 Meeting Ends The meeting starts at 11:15. FS and JQ take notes, FS will compile them into one text. JQ invites the attendees to have dinner and whiskey tasting at his home. :-) 11:20 NEC Introduction and Overview of Ongoing Projects (MB) ------------------------------------------------------------ MB presents an overview of the topics and projects being worked on at the NEC Network Laboratories in Heidelberg (3GPP, DHCPv6, IP-based Radio Access Networks, ...). He presents problems observed with SNMPv3: (1) No filtering of Get requests like in CMIP. (2) It's complicated to keep an mgmt system in sync with managed nodes if changes are done via CLI. (3) Checking the overall health of boxes requires a lot of requests Idea on (3): "One-Stop Health Check": aggregate various health information into a single object. JS notices that the DISMAN-EVENT/EXPRESSION-MIBs cover this. MB/JQ: The DISMAN MIBs are way to complicated, that's why they did not succeed. We want to set a strict focus on box health and keep it simple. [Get slides from MB.] 11:55 Measuring Network Traffic (RM) ------------------------------------ RM gives a presentation on what he's doing for his PhD on network traffic measurements. [Get presentation from RM.] Page 12: We want to find the "clouds of most relevance", so that we come up with the result on page 13. JH: Can you address the specific characteristics of QoS premium class traffic? RM: No, we assume carriers to do reasonable overprovisioning instead of QoS management. AP presents some additional numbers from UT that show, that faculties retrieve much more traffic via file sharing from student houses than vice versa. :-) JS asks to what degree the traffic is anonymized. RM: IP addresses are changed, but mappings are retained. JS: However, you might be able to map back to the users based on other packet characteristics. This might be an issue, if you want to find other people doing such measurements. JP/JQ: It becomes an issue of national laws. MM: A challenging problem is to build models also for the traffic that we cannot yet identify. Protocols like HTTP are the easy cases, but in some situations the yet unidentified traffic is significant. AP: We assume it's right to follow both approaches in parallel: (a) doing careful measurements and analyzing them and (b) trying to come up with methematical models. JQ mentions that it would be reasonable to coordinate with the IRTF IMRG. References: Packet trace anonymization through tcpdpriv: http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html (13:25 Coffee Break) 13:35 SyncML Device Management (RS) ----------------------------------- The general motivation for this discussion within the NMRG is not to do work twice. [Get presentation from RS.] Page 25: JS: It seems a bit strange that e.g. in case of HTTP as the transport, management requests are encapsulated in HTTP responses. DP: How is authentication done: RS: By shared secrets and MD5. JQ/RS: Clarification: The SyncML Forum is now part of the Open Mobile alliance (OMA). AP: What about interoperabilty between vendors. RS: Interoperability has been prooved for synchronization by several vendors. AP: Would you propose that the NETCONF WG should look at this or use this? RS: NETCONF's initial effort by Juniper was good and driven in combination with a data model, but now that the data model is completely taken aside, NETCONF is like an empty shell. JQ: Could the NETCONF people learn from SyncML? RS: Yes, they can. DP/RS: Clarification on access control: ACLs are attached to instances. If an object has no ACL, it is inherited from its parent(s). You cannot have ACL properties for objects that do not yet exist, they have to be provided upon instantiation. (14:40 Lunch Break) 16:10 Performance of Web Services compared to traditional SNMP (TD) ------------------------------------------------------------------- AP gives a short overview of what some people at UT have done and are doing related to Web Services in the area of NM. Then TD gives his presentation [Get slides from TD, and maybe the one slide from AP.] No encryption has been used, neither for SNMP, nor for Web Services. JS/TD: Compressed data was well compressable, because most counters were zero because of unused virtual interfaces, so the results have to be interpreted carefully. The very bad CPU usage of NET-SNMP is caused by the fact that for every cell, the whole table is looked up, while in case of the Web Service, you have to fetch the whole table just once to deliver all its cells. For SNMP "walk" that can not be solved by caching, for SNMP GetBulk caching could improve performance, but it is not implemented in NET-SNMP. Question: Is XML validation of the exchanged XML infosets reasonable or even required? Conclusion: A recomendation is out of scope here, but it would be good to have a camparison of footprint and CPU usage with and without validation. DP/TD: Clarification: Operation time is from encoding the request until decoding the response(s). Tests were made on a 1GHz Intel GNU/Linux PC. AP's conclusion from these results: SNMP is good for retrieving single cells; that's what it has been primarily designed for. For larger amounts of data, Web Services win, especially when compression is used. JS: Compressed WS should not be compared to uncompressed SNMP. JS asks to make not only the result but also the code that was used to get the results available. DP/TD: gSOAP's XML message parser is optimized based on the expected massages; this makes it quite efficient. (17:25 Coffee Break) 17:35 Session-based Security Model for SNMPv3 (DP) -------------------------------------------------- DP presents work he has done together with Wes Hardaker (slides not reviewed by Wes). [Get presentation from DP.] JS has doubts how relevant this work is. It seems complicated in terms of key management similar to the former party based security model for SNMPv2. TCP/TLS looks more managable and well known to people. References: draft-hardaker-snmp-session-sm-00.txt 18:35 Wrap-up ------------- JS asks to send in the presented slides. The meeting ends at 18:40. Received: from mailhost.iu-bremen.de ([195.37.70.131]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9NGj5st017872 for ; Thu, 23 Oct 2003 18:45:05 +0200 Received: by mailhost.iu-bremen.de (Postfix, from userid 1000) id 0EADF7E6D; Thu, 23 Oct 2003 18:45:03 +0200 (CEST) Date: Thu, 23 Oct 2003 18:45:03 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Cc: Branislav Meandzija , "Nmrg (E-mail)" Subject: Re: [nmrg] Re: CAPWAP work Message-ID: <20031023164503.GA13565@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Wes Hardaker , Branislav Meandzija , "Nmrg (E-mail)" References: <200310220316.h9M3G8o6026403@lester.arraycomm.com> <20031023074547.GA1265@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 Thu, Oct 23, 2003 at 09:07:26AM -0700, Wes Hardaker wrote: > I think NETCONF has lots of complexity that aren't yet apparent, but > will be a result of decisions being made now. Not sure this helps me or others... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from wanderer.hardakers.net ([64.75.222.66]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9NG7Xst004274 for ; Thu, 23 Oct 2003 18:07:35 +0200 Received: by wanderer.hardakers.net (Postfix, from userid 274) id 56366574A8; Thu, 23 Oct 2003 09:07:26 -0700 (PDT) To: Branislav Meandzija Cc: "Nmrg (E-mail)" References: <200310220316.h9M3G8o6026403@lester.arraycomm.com> <20031023074547.GA1265@iu-bremen.de> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Thu, 23 Oct 2003 09:07:26 -0700 In-Reply-To: <20031023074547.GA1265@iu-bremen.de> (Juergen Schoenwaelder's message of "Thu, 23 Oct 2003 09:45:47 +0200") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Re: CAPWAP work 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 Thu, 23 Oct 2003 09:45:47 +0200, Juergen Schoenwaelder said: Juergen> I am curious what you believe the complexity of NETCONF Juergen> is. I think NETCONF has lots of complexity that aren't yet apparent, but will be a result of decisions being made now. -- Wes Hardaker Sparta Received: from atlanta.postech.ac.kr (atlanta.postech.ac.kr [141.223.82.74]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9NB49st019675 for ; Thu, 23 Oct 2003 13:04:11 +0200 Received: (from jwkhong@localhost) by atlanta.postech.ac.kr (v3smtp 8.11.6.9/8.11.6) id h9NB66922436 for nmrg@ibr.cs.tu-bs.de; Thu, 23 Oct 2003 20:06:06 +0900 (KST) Date: Thu, 23 Oct 2003 20:06:06 +0900 From: "Prof. J. Won-Ki Hong" To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] nmrg workshop in january 2003 Message-ID: <20031023200606.A22427@atlanta.postech.ac.kr> References: <20031023101800.GC1592@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20031023101800.GC1592@iu-bremen.de>; from j.schoenwaelder@iu-bremen.de on Thu, Oct 23, 2003 at 12:18:00PM +0200 X-IBRFilter-SpamReport: -39.1 () EMAIL_ATTRIBUTION,IN_REP_TO,OFFER,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_LONG_DENSE,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-44.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OFFER, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_DENSE,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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..... How about somewhere warmer? Like, Hawaii, Thailand, Bali, etc.... Just a thought.... James On Thu, Oct 23, 2003 at 12:18:00PM +0200, Juergen Schoenwaelder wrote: > I am wondering who would be interested and able to join an NMRG meeting > in January 2003 to be hold at the International University Bremen. The > proposal is to meet around Thursday, January 8th. The meeting could > be either very specific to discuss work on which NMRG people cooperate > (measurements?) or it could have workshop style like the last meeting. > As a special offer, all participants would be invited to join a talk > which will be given by Morris Sloman on Wednesday 7th at IUB. > > Please let me know what you think or whether you have any other ideas > for future meetings. > > /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. -- ---------------------------------------------------------------------------- James Won-Ki Hong, PhD, Associate Professor Dept. of Computer Science & Engineering, POSTECH, Pohang Korea 790-784 Tel: +82-54-279-2244 Fax: +82-54-279-5663 Mobile: +82-11-810-5641 Email: jwkhong@postech.ac.kr http://dpnm.postech.ac.kr/~jwkhong/ KNOM Chair: http://www.knom.or.kr NOMS 2004: http://www.noms2004.org IEEE ComSoc CNOM Vice Chair: http://www.comsoc.org/~cnomwww/ ---------------------------------------------------------------------------- Received: from mailhost.iu-bremen.de ([195.37.70.131]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9NAI2st003170 for ; Thu, 23 Oct 2003 12:18:02 +0200 Received: by mailhost.iu-bremen.de (Postfix, from userid 1000) id 46E7C7E6D; Thu, 23 Oct 2003 12:18:00 +0200 (CEST) Date: Thu, 23 Oct 2003 12:18:00 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20031023101800.GC1592@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.4i X-IBRFilter-SpamReport: -6.3 () OFFER,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-7.8 required=5.0 tests=BAYES_30,OFFER,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] nmrg workshop in january 2003 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 am wondering who would be interested and able to join an NMRG meeting in January 2003 to be hold at the International University Bremen. The proposal is to meet around Thursday, January 8th. The meeting could be either very specific to discuss work on which NMRG people cooperate (measurements?) or it could have workshop style like the last meeting. As a special offer, all participants would be invited to join a talk which will be given by Morris Sloman on Wednesday 7th at IUB. Please let me know what you think or whether you have any other ideas for future meetings. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from james ([195.37.70.131]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9N7jmjV006916 for ; Thu, 23 Oct 2003 09:45:48 +0200 Received: by james (Postfix, from userid 1000) id 1DE887E6D; Thu, 23 Oct 2003 09:45:47 +0200 (CEST) Date: Thu, 23 Oct 2003 09:45:47 +0200 From: Juergen Schoenwaelder To: Branislav Meandzija Cc: "Nmrg (E-mail)" Subject: Re: [nmrg] CAPWAP work Message-ID: <20031023074547.GA1265@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Branislav Meandzija , "Nmrg (E-mail)" References: <200310220316.h9M3G8o6026403@lester.arraycomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310220316.h9M3G8o6026403@lester.arraycomm.com> User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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, Oct 21, 2003 at 08:16:01PM -0700, Branislav Meandzija wrote: > There was a brief period between CMIP and CIM that SNMP was that single > solution but now we really need to come up with something else. Haven't > made up my mind yet about NETCONF but the complexity plus starting with > the protocol and ignoring the information model, seem to be a bad omen. I am curious what you believe the complexity of NETCONF is. But perhaps you should send these concerns better to the netconf mailing list since this is where people should express their support/concerns. /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 h9MFnHjV007994 for ; Wed, 22 Oct 2003 17:49:18 +0200 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h9MFnDn24291; Wed, 22 Oct 2003 08:49:14 -0700 Date: Wed, 22 Oct 2003 08:49:12 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Juergen Schoenwaelder cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meeting slides In-Reply-To: <20031022083057.GA1708@iu-bremen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IBRFilter-SpamReport: -25.6 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 want to have Wes review the slides before I send them to you, so it may take a few days. On Wed, 22 Oct 2003, Juergen Schoenwaelder wrote: > I like to collect the Heidelberg meeting slides - so please, if you have > not done so, send the PDF slides to me (or the PPT to JP-MF ;-). > > /js Regards, /david t. perkins Received: from james ([212.126.217.214]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9M9injV011269 for ; Wed, 22 Oct 2003 11:44:50 +0200 Received: by james (Postfix, from userid 1000) id CF52587C8; Wed, 22 Oct 2003 11:44:49 +0200 (CEST) Date: Wed, 22 Oct 2003 11:44:49 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20031022094449.GF1708@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.4i X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_20,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] nmrg publications 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 like to collect the list of NMRG publications. What I have is the set of documents that are considered core NMRG publications in the sense that they came really out of NMRG discussions. These are basically our RFCs plus the Simple Times paper about bulk data transfers. There are in addition papers written by NMRG participants that are not really core NMRG publications, but which have been influenced by NMRG discussions. Usually such papers acknowledge the NMRG somewhere. I would like to compile a list of these papers as well but I need your help. So if you have written such a paper which was influenced by NMRG discussions and acknowledges the NMRG, please let me know the details so that I can put things online. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from james ([212.126.217.214]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9M8UvjV017518 for ; Wed, 22 Oct 2003 10:30:57 +0200 Received: by james (Postfix, from userid 1000) id 18BF987C8; Wed, 22 Oct 2003 10:30:57 +0200 (CEST) Date: Wed, 22 Oct 2003 10:30:57 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20031022083057.GA1708@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.4i X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_00,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] meeting slides 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 like to collect the Heidelberg meeting slides - so please, if you have not done so, send the PDF slides to me (or the PPT to JP-MF ;-). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from bastion.arraycomm.com (ns.arraycomm.com [199.74.167.5]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9M3GFjV009217 for ; Wed, 22 Oct 2003 05:16:16 +0200 Received: from lester.arraycomm.com (lester.arraycomm.com [172.16.0.17]) by bastion.arraycomm.com (Postfix) with ESMTP id 765BF5E154; Tue, 21 Oct 2003 20:16:14 -0700 (PDT) Received: from ARRAYCOMM.COM (dhcp-143.arraycomm.com [172.16.2.143]) by lester.arraycomm.com (8.12.9/8.12.9) with ESMTP id h9M3G8o6026403 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Oct 2003 20:16:08 -0700 (PDT) Message-Id: <200310220316.h9M3G8o6026403@lester.arraycomm.com> From: Branislav Meandzija To: "Harrington, David" , "Nmrg (E-mail)" , Andrea Westerinen , "Wijnen, Bert (Bert)" , Marcus Brunner Subject: RE: [nmrg] CAPWAP work Date: Tue, 21 Oct 2003 20:16:01 -0700 X-Mailer: CorporateTime Outlook Connector 3.3 40513 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) X-Filter-Version: 1.9 (lester) X-IBRFilter-SpamReport: 0.6 () FORGED_MUA_OUTLOOK,QUOTED_EMAIL_TEXT 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 h9M3GFjV009217 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_20,FORGED_MUA_OUTLOOK,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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: Great suggestions. Perhaps another issue is that most of our solutions rely on complex technologies that have a large barrier-to-entry. That includes the relatively newer ones like CIM as well. That may have been justified when we created them but may be different now. Furthermore, considering the relative importance of management compared to core functions of a system it would seem absolutely necessary for the management community to have a single preferred solution. Otherwise, each device will have its own management architecture. There was a brief period between CMIP and CIM that SNMP was that single solution but now we really need to come up with something else. Haven't made up my mind yet about NETCONF but the complexity plus starting with the protocol and ignoring the information model, seem to be a bad omen. For a big part of the management pie, I like the availability of free LDAP tools, implementations and integration with data bases, but obviously that solves only part of the problem. The availability of CIM schema is great but in my opinion too complex and reliant on the X.700 way of thinking about management. Branislav > -----Original Message----- > From: nmrg-admin@ibr.cs.tu-bs.de [mailto:nmrg-admin@ibr.cs.tu-bs.de]On > Behalf Of Harrington, David > Sent: Tuesday, October 21, 2003 7:58 AM > To: Nmrg (E-mail) > Subject: RE: [nmrg] CAPWAP work > > > Hi, > > I think it is less a need for generalization, abstraction, and > simplification and more a need for tools/documents to > encourage reuse. I > suspect most people do not study the whole field of network management > looking for things that could be reused when thay have a specific > problem to be solved now. They tend instead to focus on their > own little > world and their immediate needs, and don't see those things that were > designed elsewhere that could be reused to solve their problem. > > Having worked with software reuse within my company, one key factor to > its success was making it easy for people to find what needed > functionality already existed that could be reused. It would be pretty > unreasonable to expect a software engineer to scan all the code in the > company's source code control system to see what could be reused when > they need to have their code running within 30 days. > > Yet, the standards organizations do seem to expect this. In the IETF > (the only organization I have adeqaute experience with to comment on), > there is no web site or search tool that can tell me if there is a > generic linked list mib design that I could reuse for my special > purposes. There is an RFC search capability that might help me find a > mib for the foo functionality, if the rfc-editor added a > search keyword > for "mib", especially if "managed objects" was used in the document's > title. > > Policy is a hot topic in NM, yet in the IETF there are multiple mib > approaches for scheduling, advertising the capabilities of an > agent, and > other concepts that should be able to be reused for multiple targeted > devices. > > "mib schedule" in the rfc search yields nothing; "mib > scheduling" brings > up one RFC; "policy schedule" and "policy scheduling" have no > hits. None > of these yield hits in the I-D search engine. > > "capabilities" brings up the BGP-4 capabilities RFC and numerous I-Ds, > but "mib capabilities" yields nothing. > > I think a web page that somehow categorizes mibs (and the > tables within > the mibs) based on the managed functionality and its potential for use > in solution spaces would be a useful thing. The effort > started by Sharon > to identify index relations between mibs is a step in the right > direction. I would imagine that a similar web site would also > be useful > for other standards bodies. > > IMHO as a vendor, the drive behind generalization, abstraction, and > simplification is more about "starting over" and redefining > standards to > follow some preconceived notion of the right way to do things, rather > than documenting what already exists that could be reused to good > effect. The costs associated with starting over are > significant and will > work against adoption. The reuse of existing solutions allows > vendors to > reduce costs by avoiding duplicate effort. For many segments of our > industry, the identification of reusable existing solutions would seem > to be a much better approach. > > dbh > > > -----Original Message----- > > From: Branislav Meandzija [mailto:bran@arraycomm.com] > > Sent: Tuesday, October 14, 2003 9:51 PM > > To: Wijnen, Bert (Bert); Marcus Brunner > > Cc: Nmrg (E-mail) > > Subject: RE: [nmrg] CAPWAP work > > > > > > > > Just going through my very big stack of unread reflector > > e-mail and would like to chip in my 2 cents worth. > > > > I do not understand why the community is considering every > > new device worthy of separate consideration. It seems to me > > that going down that path is constructing something similar > > to the "tower-of-babel" where each device has its own > > management solution. I think much of the work going on in the > > management community is in sore need of some juicy > > generalization, abstraction, and simplification. > > > > Branislav > > > > > -----Original Message----- > > > From: nmrg-admin@ibr.cs.tu-bs.de > > [mailto:nmrg-admin@ibr.cs.tu-bs.de]On > > > Behalf Of Wijnen, Bert (Bert) > > > Sent: Monday, September 29, 2003 4:09 AM > > > To: 'Marcus Brunner' > > > Cc: Nmrg (E-mail) > > > Subject: RE: [nmrg] CAPWAP work > > > > > > > > > Inline > > > > -----Original Message----- > > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > > Sent: maandag 29 september 2003 12:48 > > > > To: Wijnen, Bert (Bert) > > > > Cc: Nmrg (E-mail) > > > > Subject: Re: [nmrg] CAPWAP work > > > > > > > > > > > > Bert, > > > > > > > > As far as I remember, the nmrg has started pitching around > > > about various > > > > IETF politics and SNMP and so on. I don't remember having > > > seen substantial > > > > positions on CAPWAP. > > > > > > > Mmm... I sort of recall that there were specific worries > that CAPWAP > > > runs the risk to re-invent the wheel. > > > > > > > IMOH, CAPWAP has the right direction. Basically, > > > simplifying the control > > > > and management of WLAN access points (plug and play). > > > Unfortunately, the > > > > LWAPP proposal in discussion does everything on one newly > > > defined protocol > > > > without having well-known IETF protocols taken into account. > > > > > > > Aha... ok so that shows they have (potentially) not looked > > > (well enough) > > > at existing protocols. That we can deal with by making it > > explicit in > > > a WG charter-to-be that they MUST evaluate existing > protocols first. > > > > > > Thanks for the input. Any more comments from others? > > > Bert > > > > Marcus > > > > > > > -- > > > !! 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. > > > > -- > !! 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 ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9LEwnjV021237 for ; Tue, 21 Oct 2003 16:58:49 +0200 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA06896 for ; Tue, 21 Oct 2003 10:59:22 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma006870; Tue, 21 Oct 03 10:58:49 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 21 Oct 2003 10:58:12 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 21 Oct 2003 10:58:12 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Oct 2003 10:58:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] CAPWAP work Date: Tue, 21 Oct 2003 10:58:13 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA0113926C@NHROCMBX1.ets.enterasys.com> Thread-Topic: [nmrg] CAPWAP work Thread-Index: AcOVhSJHy5zBfDEaRcW2h9FeQEHfjgCWUfAw From: "Harrington, David" To: "Nmrg (E-mail)" X-OriginalArrivalTime: 21 Oct 2003 14:58:12.0817 (UTC) FILETIME=[BFD34410:01C397E3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:98.1557 M:74.8764 P:95.9108 R:95.9108 S:79.4062 ) X-pstn-settings: 4 (0.2500:0.5000) p:13 M:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT 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 h9LEwnjV021237 X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 think it is less a need for generalization, abstraction, and simplification and more a need for tools/documents to encourage reuse. I suspect most people do not study the whole field of network management looking for things that could be reused when thay have a specific problem to be solved now. They tend instead to focus on their own little world and their immediate needs, and don't see those things that were designed elsewhere that could be reused to solve their problem. Having worked with software reuse within my company, one key factor to its success was making it easy for people to find what needed functionality already existed that could be reused. It would be pretty unreasonable to expect a software engineer to scan all the code in the company's source code control system to see what could be reused when they need to have their code running within 30 days. Yet, the standards organizations do seem to expect this. In the IETF (the only organization I have adeqaute experience with to comment on), there is no web site or search tool that can tell me if there is a generic linked list mib design that I could reuse for my special purposes. There is an RFC search capability that might help me find a mib for the foo functionality, if the rfc-editor added a search keyword for "mib", especially if "managed objects" was used in the document's title. Policy is a hot topic in NM, yet in the IETF there are multiple mib approaches for scheduling, advertising the capabilities of an agent, and other concepts that should be able to be reused for multiple targeted devices. "mib schedule" in the rfc search yields nothing; "mib scheduling" brings up one RFC; "policy schedule" and "policy scheduling" have no hits. None of these yield hits in the I-D search engine. "capabilities" brings up the BGP-4 capabilities RFC and numerous I-Ds, but "mib capabilities" yields nothing. I think a web page that somehow categorizes mibs (and the tables within the mibs) based on the managed functionality and its potential for use in solution spaces would be a useful thing. The effort started by Sharon to identify index relations between mibs is a step in the right direction. I would imagine that a similar web site would also be useful for other standards bodies. IMHO as a vendor, the drive behind generalization, abstraction, and simplification is more about "starting over" and redefining standards to follow some preconceived notion of the right way to do things, rather than documenting what already exists that could be reused to good effect. The costs associated with starting over are significant and will work against adoption. The reuse of existing solutions allows vendors to reduce costs by avoiding duplicate effort. For many segments of our industry, the identification of reusable existing solutions would seem to be a much better approach. dbh > -----Original Message----- > From: Branislav Meandzija [mailto:bran@arraycomm.com] > Sent: Tuesday, October 14, 2003 9:51 PM > To: Wijnen, Bert (Bert); Marcus Brunner > Cc: Nmrg (E-mail) > Subject: RE: [nmrg] CAPWAP work > > > > Just going through my very big stack of unread reflector > e-mail and would like to chip in my 2 cents worth. > > I do not understand why the community is considering every > new device worthy of separate consideration. It seems to me > that going down that path is constructing something similar > to the "tower-of-babel" where each device has its own > management solution. I think much of the work going on in the > management community is in sore need of some juicy > generalization, abstraction, and simplification. > > Branislav > > > -----Original Message----- > > From: nmrg-admin@ibr.cs.tu-bs.de > [mailto:nmrg-admin@ibr.cs.tu-bs.de]On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, September 29, 2003 4:09 AM > > To: 'Marcus Brunner' > > Cc: Nmrg (E-mail) > > Subject: RE: [nmrg] CAPWAP work > > > > > > Inline > > > -----Original Message----- > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > Sent: maandag 29 september 2003 12:48 > > > To: Wijnen, Bert (Bert) > > > Cc: Nmrg (E-mail) > > > Subject: Re: [nmrg] CAPWAP work > > > > > > > > > Bert, > > > > > > As far as I remember, the nmrg has started pitching around > > about various > > > IETF politics and SNMP and so on. I don't remember having > > seen substantial > > > positions on CAPWAP. > > > > > Mmm... I sort of recall that there were specific worries that CAPWAP > > runs the risk to re-invent the wheel. > > > > > IMOH, CAPWAP has the right direction. Basically, > > simplifying the control > > > and management of WLAN access points (plug and play). > > Unfortunately, the > > > LWAPP proposal in discussion does everything on one newly > > defined protocol > > > without having well-known IETF protocols taken into account. > > > > > Aha... ok so that shows they have (potentially) not looked > > (well enough) > > at existing protocols. That we can deal with by making it > explicit in > > a WG charter-to-be that they MUST evaluate existing protocols first. > > > > Thanks for the input. Any more comments from others? > > Bert > > > Marcus > > > > > -- > > !! 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 cougar.icir.org (cougar.icir.org [192.150.187.76]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9KKCbBq030127 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 20 Oct 2003 22:12:39 +0200 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9p1/8.12.3) with ESMTP id h9KKBKGa047443; Mon, 20 Oct 2003 13:11:20 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200310202011.h9KKBKGa047443@cougar.icir.org> To: j.schoenwaelder@iu-bremen.de cc: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de, iab@iab.org, Ran Atkinson From: Sally Floyd Date: Mon, 20 Oct 2003 13:11:20 -0700 X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Re: [Research-funding] updates research funding draft 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: [Apologies for the duplicate, but I forgot to cc Ran the first time...] Juergen - >I have seen that an update of the research funding document has been >posted as draft-iab-research-funding-02.txt. I am surprised to some >extend that the text produced by the NMRG for section 3.5. (and which >has been discussed and posted on the research-funding mailing list) >was not considered or was rejected without any feedback. Perhaps >this is an oversight? We apologize for not getting back to you earlier with feedback out how NRMG's contribution on Network Management was and was not incorporated into draft-iab-research-funding-02.txt. We thank you for your contribution. It was taken into account in the revision of the document, even though it was not used directly. There were several reasons for not using the NMRG text directly: * We did not want the section on Network Management to be disproportionately large relative to the rest of the document; * We received input on the Network Management section from people other than the NMRG, including another proposal for a complete rewrite of that section (which we also did not use in its entirety). We retained editorial control for that section (as well as the rest of the document) in the IAB. The new version, draft-iab-research-funding-02.txt, is being submitted for IETF Call for Input before becoming an Informational RFC, so there is also room for additional feedback. Here is a summary of what the current draft, draft-iab-research-funding-02.txt, did and did not incorporate from the contribution by the NMRG: * The intro to Section 3.5 has text about operators' needs not being met. * The subection on "Managing Networks, Not Devices" includes much of the text from the NMRG contribution. * The subsection on "Enhanced Monitoring Capabilities" includes some of the additions from the NRMG text, but does not include the sentence about some implementations showing inaccuraties (as not appropriate for this document). * The subsection on Autonomous Network Management, originally from draft-iab-research-funding-01.txt, was deleted from draft-iab-research-funding-02.txt in the interests of shortening the Network Management section. * The subsection on "Configuration Management", originally from draft-iab-research-funding-01.txt, was also deleted in the interests of shortening the Network Management section. * The new material in the NRMG's subsection on "Customer Network Management" is the last paragraph, and this material was not included. Some of that paragraph is more detailed than is needed for this document, in terms of the specific needs of customer network management mechanisms. * The first paragraph of the NMRG section on Analysis of Current Management Protocol Usage has been incorporated into the last paragragh of Section 3.5.3 of draft-iab-research-funding-02.txt, though not in those exact words. The last sentence of the NRMG section, on "One way to research this issue", was also not included in draft-iab-research-funding-02.txt, as too detailed for this document. My apologies also for the delay in responding to your email from last week - I was slowed down considerably by a cold... - Sally Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9KH0aBp031732 for ; Mon, 20 Oct 2003 19:00:36 +0200 Received: from cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2003 10:01:49 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9KH0TQY020151; Mon, 20 Oct 2003 10:00:30 -0700 (PDT) Received: from CSCOAMERA18391 (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMR48189; Mon, 20 Oct 2003 09:59:47 -0700 (PDT) From: "Andrea Westerinen" To: "'Branislav Meandzija'" , "'Wijnen, Bert \(Bert\)'" , "'Marcus Brunner'" Cc: "'Nmrg \(E-mail\)'" Subject: RE: [nmrg] CAPWAP work Date: Mon, 20 Oct 2003 10:00:28 -0700 Message-ID: <008001c3972b$a9ef3540$bafd130a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <200310150150.h9F1opo6002806@lester.arraycomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-IBRFilter-SpamReport: -9.7 () IN_REP_TO,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-18.5 required=5.0 tests=BAYES_10,IN_REP_TO,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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: Your last sentence summarizes the purpose and work of the DMTF in creating CIM. Andrea -----Original Message----- From: nmrg-admin@ibr.cs.tu-bs.de [mailto:nmrg-admin@ibr.cs.tu-bs.de] On Behalf Of Branislav Meandzija Sent: Tuesday, October 14, 2003 6:51 PM To: Wijnen, Bert (Bert); Marcus Brunner Cc: Nmrg (E-mail) Subject: RE: [nmrg] CAPWAP work Just going through my very big stack of unread reflector e-mail and would like to chip in my 2 cents worth. I do not understand why the community is considering every new device worthy of separate consideration. It seems to me that going down that path is constructing something similar to the "tower-of-babel" where each device has its own management solution. I think much of the work going on in the management community is in sore need of some juicy generalization, abstraction, and simplification. Branislav > -----Original Message----- > From: nmrg-admin@ibr.cs.tu-bs.de [mailto:nmrg-admin@ibr.cs.tu-bs.de]On > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, September 29, 2003 4:09 AM > To: 'Marcus Brunner' > Cc: Nmrg (E-mail) > Subject: RE: [nmrg] CAPWAP work > > > Inline > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: maandag 29 september 2003 12:48 > > To: Wijnen, Bert (Bert) > > Cc: Nmrg (E-mail) > > Subject: Re: [nmrg] CAPWAP work > > > > > > Bert, > > > > As far as I remember, the nmrg has started pitching around > about various > > IETF politics and SNMP and so on. I don't remember having > seen substantial > > positions on CAPWAP. > > > Mmm... I sort of recall that there were specific worries that CAPWAP > runs the risk to re-invent the wheel. > > > IMOH, CAPWAP has the right direction. Basically, > simplifying the control > > and management of WLAN access points (plug and play). > Unfortunately, the > > LWAPP proposal in discussion does everything on one newly > defined protocol > > without having well-known IETF protocols taken into account. > > > Aha... ok so that shows they have (potentially) not looked > (well enough) > at existing protocols. That we can deal with by making it explicit in > a WG charter-to-be that they MUST evaluate existing protocols first. > > Thanks for the input. Any more comments from others? > Bert > > Marcus > > > -- > !! 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 tokyo.ccrle.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9HAOheB031065 for ; Fri, 17 Oct 2003 12:24:43 +0200 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9HAOd2q011884 for ; Fri, 17 Oct 2003 12:24:40 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9HAObmY011883 for ; Fri, 17 Oct 2003 12:24:37 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9HAOa2o011880; Fri, 17 Oct 2003 12:24:37 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 73FE54401F; Fri, 17 Oct 2003 11:50:57 +0200 (CEST) Date: Fri, 17 Oct 2003 12:24:35 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: "David T. Perkins" , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Pre-meeting details Message-ID: <11048506.1066393475@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.35 X-IBRFilter-SpamReport: -20.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,X_AUTH_WARNING X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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: David, we provide WLAN on Sunday, public address space, but behind a firewall (some VPN client make trouble), standard application should work. Marcus --On Freitag, 17. Oktober 2003 03:08 -0700 "David T. Perkins" wrote: > HI, > > I'm arriving into Frankfurt on Sat at 5:35pm, and then > taking the shuttle to the Marriot (where I'm staying). > A couple of questions: > 1) are there any dinner plans for saturday? > 2) what are the Internet connectivity options? > > Regards, > /david t. perkins > > -- > !! 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. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus 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 h9HA85eB025887 for ; Fri, 17 Oct 2003 12:08:06 +0200 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h9HA84j22624 for ; Fri, 17 Oct 2003 03:08:04 -0700 Date: Fri, 17 Oct 2003 03:08:02 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: nmrg@ibr.cs.tu-bs.de Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IBRFilter-SpamReport: -5.8 () USER_AGENT_PINE X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-5.7 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Pre-meeting details 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'm arriving into Frankfurt on Sat at 5:35pm, and then taking the shuttle to the Marriot (where I'm staying). A couple of questions: 1) are there any dinner plans for saturday? 2) what are the Internet connectivity options? Regards, /david t. perkins 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 h9GGUVeB009333 for ; Thu, 16 Oct 2003 18:30:31 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id CFC225718F; Thu, 16 Oct 2003 18:30:26 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 1A02F57181; Thu, 16 Oct 2003 18:30:26 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 1556187C8; Thu, 16 Oct 2003 18:30:25 +0200 (CEST) Date: Thu, 16 Oct 2003 18:30:25 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20031016163025.GA1256@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.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_10,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] NSF workshop on fundamental research in networking report 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: Some of you might find this interesting: http://www.cs.virginia.edu/~jorg/workshop1/NSF-NetWorkshop-2003.pdf /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 h9FLUbeB002366 for ; Wed, 15 Oct 2003 23:30:37 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id DE3A45711F; Wed, 15 Oct 2003 23:30:36 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 2D08C56C7E; Wed, 15 Oct 2003 23:30:36 +0200 (CEST) Received: by james (Postfix, from userid 1000) id AF943817F; Wed, 15 Oct 2003 23:30:35 +0200 (CEST) Date: Wed, 15 Oct 2003 23:30:35 +0200 From: Juergen Schoenwaelder To: iab@iab.org Cc: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Message-ID: <20031015213035.GA997@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: iab@iab.org, research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6 () MAILTO_WITH_SUBJ,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-5.7 required=5.0 tests=MAILTO_WITH_SUBJ,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] updates research funding draft 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: --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have seen that an update of the research funding document has been posted as draft-iab-research-funding-02.txt. I am surprised to some extend that the text produced by the NMRG for section 3.5. (and which has been discussed and posted on the research-funding mailing list) was not considered or was rejected without any feedback. Perhaps this is an oversight? I have attached the latest version of "our" submission (which you should also find in the research-funding mailing list archive) and I am looking forward to hear what you think about it. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=qwqw >From research-funding-admin@ietf.org Tue Jul 22 17:57:01 2003 Return-Path: X-Original-To: j.schoenwaelder@iu-bremen.de Delivered-To: j.schoenwaelder@iu-bremen.de Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 972231ADDE for ; Tue, 22 Jul 2003 17:57:01 +0200 (CEST) Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by merkur.iu-bremen.de (Postfix) with ESMTP id 4DC1A2E87 for ; Tue, 22 Jul 2003 17:57:00 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezVb-0004Ir-SN; Tue, 22 Jul 2003 11:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezUz-0004FK-Rf for research-funding@optimus.ietf.org; Tue, 22 Jul 2003 11:56:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17999 for ; Tue, 22 Jul 2003 11:56:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezUy-0005dh-00 for research-funding@ietf.org; Tue, 22 Jul 2003 11:56:20 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 19ezUn-0005dG-00 for research-funding@ietf.org; Tue, 22 Jul 2003 11:56:09 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id DEE281ADDF; Tue, 22 Jul 2003 17:55:13 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 40FEA2E87; Tue, 22 Jul 2003 17:55:13 +0200 (CEST) Received: by james (Postfix, from userid 1000) id AE9F58507; Tue, 22 Jul 2003 17:55:12 +0200 (CEST) From: Juergen Schoenwaelder To: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Message-ID: <20030722155512.GA1347@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de References: <20030708093936.GA1287@iu-bremen.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20030708093936.GA1287@iu-bremen.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Subject: [Research-funding] Re: [nmrg] network management research funding text Sender: research-funding-admin@ietf.org Errors-To: research-funding-admin@ietf.org X-BeenThere: research-funding@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: draft-iab-research-funding feedback List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 17:55:12 +0200 X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Status: No, hits=-8.2 required=5.0 tests=AWL,IN_REP_TO,KNOWN_MAILING_LIST,REFERENCES,USER_AGENT_MUTT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Status: RO Content-Length: 6243 Lines: 136 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is the revised text for section 3.5 of the IAB research funding draft which includes the changes made during the 13th NMRG meeting in Vienna. This is the last call to submit your input. If I do not receive any additional comments by August 10th, I consider this version to be in concens with the NMRG views. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-iab-research-funding-01.txt" 3.5. Network Management The Internet had early success in network device monitoring with the Simple Network Management Protocol (SNMP) and its associated Management Information Base (MIB). There has been comparatively less success in managing networks, in contrast to the monitoring of individual devices. Furthermore, there are a number of operator requirements not well supported by the current Internet management framework. An enhanced network management architecture that more fully supports real operational network management needs is desirable. Unfortunately, network management research has historically been very underfunded. Operators have complained that existing solutions are inadequate. Research needs to be done to better understand how to address the issues. 3.5.1. Managing Networks, Not Devices At present, there are few or no good tools for managing a whole network instead of isolated devices. Current network management protocols such as SNMP are fine for reading status of well-defined objects from individual devices. But managing networks instead of isolated devices requires the ability to view the network as a large distributed system. Research is needed on scalable distributed data aggregation mechanisms, scalable distributed event correlation algorithms, and distributed and dependable control mechanisms. Applied research into methods of managing sets of networked devices seems worthwhile. Ideally such a management approach would support distributed management, rather than being strictly centralized. The lack of appropriate network management tools has been cited as one of the major barriers to the deployment of IP multicast [Diot00, SP03]. This in particular impacts multimedia (voice and video) IP networks that rely on multicast services and research would be useful in this area. 3.5.2. Autonomous Network Management Current approaches to network management do not scale sufficiently, so network operators often have difficulties operating their network(s) as successfully and economically as desired. Hence, more work is needed to improve the automation achieved by network management systems and to localize management. This might involve application of control theory, artificial intelligence, expert systems technology, or other mechanisms. 3.5.3. Configuration Management Operators at the IAB Network Management Workshop [RFC-3535] held in 2002 reported that scalable distributed configuration management for sets of network devices is a significant challenge today. In particular, it is desirable to execute configuration transactions across a number of connected devices, which requires protocols that support distributed transactions. Furthermore, configuration data should be represented in a way which simplifies the processing and generation of configurations with standard tools. Even individual improvements in configuration management for sets of networked devices are very welcome. Such improvements need to include an integrated approach to security for the configuration data. 3.5.4. Enhanced Monitoring Capabilities SNMP does not scale very well to monitoring large numbers of objects in many devices in different parts of the network. Some implementations also show inaccuracies (especially when monitoring on shorter time scales) or they lack support for the objects that operators are interested in. An alternative approach worth exploring is how to provide scalable and distributed monitoring, not on individual devices, but instead on groups of devices and networks-as-a-whole. This requires adequate and scalable data aggregation techniques. 3.5.5. Customer Network Management An open issue related to network management is helping users and others to identify and resolve problems in the network. If a user can't access a web page, it would be useful if the user could find out, easily, without having to run low-level diagnostic tools (ping and traceroute), whether the problem was that the web server was down, that the network was partitioned due to a link failure, that there was heavy congestion along the path, that the DNS name couldn't be resolved, that the firewall prohibited the access, or something else. Applied research is needed to understand how to translate data that exists in a network or a network management system into terms understandable by customers. This also requires to be able to determine which customers are affected and how the business is affected if something breaks. Of course, customer network management mechanisms must not reveal any confidential details. 3.5.6 Analysis of Current Management Protocol Usage In the past, much work has been spent on the specification and implementation of the current Internet network management architecture. However, operators reported that they use only a subset of this architecture. A better understanding of what is used for which purpose (and what is not used) is highly desirable. One way to research this issue is by automated network management protocol traffic measurements and subsequent analysis in close cooperation with operators. --W/nzBZO5zC0uMSeA-- _______________________________________________ Research-funding mailing list Research-funding@ietf.org https://www1.ietf.org/mailman/listinfo/research-funding --2oS5YaxWCcQjTEyO-- Received: from bastion.arraycomm.com (ns.arraycomm.com [199.74.167.5]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9F1oxeB003624 for ; Wed, 15 Oct 2003 03:51:00 +0200 Received: from lester.arraycomm.com (lester.arraycomm.com [172.16.0.17]) by bastion.arraycomm.com (Postfix) with ESMTP id 7CBF25E211; Tue, 14 Oct 2003 18:50:58 -0700 (PDT) Received: from ARRAYCOMM.COM (dhcp-143.arraycomm.com [172.16.2.143]) by lester.arraycomm.com (8.12.9/8.12.9) with ESMTP id h9F1opo6002806 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Oct 2003 18:50:52 -0700 (PDT) Message-Id: <200310150150.h9F1opo6002806@lester.arraycomm.com> From: Branislav Meandzija To: "Wijnen, Bert (Bert)" , Marcus Brunner Cc: "Nmrg (E-mail)" Subject: RE: [nmrg] CAPWAP work Date: Tue, 14 Oct 2003 18:50:44 -0700 X-Mailer: CorporateTime Outlook Connector 3.3 40513 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) X-Filter-Version: 1.9 (lester) X-IBRFilter-SpamReport: 0.6 () FORGED_MUA_OUTLOOK,QUOTED_EMAIL_TEXT 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 h9F1oxeB003624 X-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_10,FORGED_MUA_OUTLOOK,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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: Just going through my very big stack of unread reflector e-mail and would like to chip in my 2 cents worth. I do not understand why the community is considering every new device worthy of separate consideration. It seems to me that going down that path is constructing something similar to the "tower-of-babel" where each device has its own management solution. I think much of the work going on in the management community is in sore need of some juicy generalization, abstraction, and simplification. Branislav > -----Original Message----- > From: nmrg-admin@ibr.cs.tu-bs.de [mailto:nmrg-admin@ibr.cs.tu-bs.de]On > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, September 29, 2003 4:09 AM > To: 'Marcus Brunner' > Cc: Nmrg (E-mail) > Subject: RE: [nmrg] CAPWAP work > > > Inline > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: maandag 29 september 2003 12:48 > > To: Wijnen, Bert (Bert) > > Cc: Nmrg (E-mail) > > Subject: Re: [nmrg] CAPWAP work > > > > > > Bert, > > > > As far as I remember, the nmrg has started pitching around > about various > > IETF politics and SNMP and so on. I don't remember having > seen substantial > > positions on CAPWAP. > > > Mmm... I sort of recall that there were specific worries that CAPWAP > runs the risk to re-invent the wheel. > > > IMOH, CAPWAP has the right direction. Basically, > simplifying the control > > and management of WLAN access points (plug and play). > Unfortunately, the > > LWAPP proposal in discussion does everything on one newly > defined protocol > > without having well-known IETF protocols taken into account. > > > Aha... ok so that shows they have (potentially) not looked > (well enough) > at existing protocols. That we can deal with by making it explicit in > a WG charter-to-be that they MUST evaluate existing protocols first. > > Thanks for the input. Any more comments from others? > Bert > > Marcus > > > -- > !! 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 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 h9E9oFQw015118 for ; Tue, 14 Oct 2003 11:50:15 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id E952057062; Tue, 14 Oct 2003 11:50:13 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id DEB1D57054; Tue, 14 Oct 2003 11:50:12 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 9381182B8; Tue, 14 Oct 2003 11:50:12 +0200 (CEST) Date: Tue, 14 Oct 2003 11:50:12 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Re: nmrg14th NMRG meeting in Heidelberg Message-ID: <20031014095012.GA1426@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Wes Hardaker , nmrg@ibr.cs.tu-bs.de References: <20030923155624.GA1870@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 Mon, Oct 13, 2003 at 04:15:39PM -0700, Wes Hardaker wrote: > Any chance I could get a copy of the SOAP presentation? I won't be > able to attend but would like to read the presentation (and maybe > offer some input if I can get a copy in advance)? I plan to collect all the presentations in order to make them available on the NMRG web site. Having seen a draft of the SOAP measurements, I know that the material is highly interesting. So stay tuned. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from wanderer.hardakers.net (adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9DNG0Qw015729 for ; Tue, 14 Oct 2003 01:16:01 +0200 Received: by wanderer.hardakers.net (Postfix, from userid 274) id B035E574A8; Mon, 13 Oct 2003 16:15:40 -0700 (PDT) To: nmrg@ibr.cs.tu-bs.de References: <20030923155624.GA1870@iu-bremen.de> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Mon, 13 Oct 2003 16:15:39 -0700 In-Reply-To: <20030923155624.GA1870@iu-bremen.de> (Juergen Schoenwaelder's message of "Tue, 23 Sep 2003 17:56:24 +0200") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Re: nmrg14th NMRG meeting in Heidelberg 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, 23 Sep 2003 17:56:24 +0200, Juergen Schoenwaelder said: Juergen> Juergen> http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2003/heidelberg/ Any chance I could get a copy of the SOAP presentation? I won't be able to attend but would like to read the presentation (and maybe offer some input if I can get a copy in advance)? -- Wes Hardaker Sparta Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h98LJYPT006619 for ; Wed, 8 Oct 2003 23:19:35 +0200 Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h98LJWb11734; Wed, 8 Oct 2003 14:19:32 -0700 (PDT) Received: (from rfc-ed@localhost) by jet.isi.edu (8.9.3/8.8.6) id OAA24045; Wed, 8 Oct 2003 14:19:31 -0700 (PDT) Date: Wed, 8 Oct 2003 14:19:31 -0700 From: RFC Editor To: nmrg@ibr.cs.tu-bs.de Cc: RFC Editor Message-ID: <20031008211931.GE23661@isi.edu> References: <20031008154008.GA8149@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008154008.GA8149@iu-bremen.de> User-Agent: Mutt/1.4i X-IBRFilter-SpamReport: -132.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-135.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT, USER_IN_WHITELIST autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Re: SMIng documents ready for experimental RFCs 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: Greetings, Thank you for your submissions. The RFC Editor has received your proposed RFCs, and will review the documents. Once the RFC Editor has reviewed these drafts, we will send them to the IESG for a 4 week timeout, allowing the IESG time to review and comment on these efforts. You can track the progress of your documents at: http://www.rfc-editor.org/queue.html Please note that your documents will be removed from our queue and treated as new submissions if we send them back to you for revisions. Thank you. RFC Editor On Wed, Oct 08, 2003 at 05:40:08PM +0200, Juergen Schoenwaelder wrote: > On behalf of the NMRG, I would like to ask you to publish > > draft-irtf-nmrg-sming-05.txt > draft-irtf-nmrg-sming-modules-03.txt > draft-irtf-nmrg-sming-snmp-03.txt > > as Experimental RFCs. These documents have been produced by the > Network Management Research Group (NMRG) of the IRTF. > > /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 h98FeDPT021245 for ; Wed, 8 Oct 2003 17:40:13 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 0949556D38; Wed, 8 Oct 2003 17:40:10 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 5611B1A75E; Wed, 8 Oct 2003 17:40:09 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 061FE82E9; Wed, 8 Oct 2003 17:40:08 +0200 (CEST) Date: Wed, 8 Oct 2003 17:40:08 +0200 From: Juergen Schoenwaelder To: rfc-editor@rfc-editor.org Cc: nmrg@ibr.cs.tu-bs.de Message-ID: <20031008154008.GA8149@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: rfc-editor@rfc-editor.org, 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.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] SMIng documents ready for experimental RFCs 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 behalf of the NMRG, I would like to ask you to publish draft-irtf-nmrg-sming-05.txt draft-irtf-nmrg-sming-modules-03.txt draft-irtf-nmrg-sming-snmp-03.txt as Experimental RFCs. These documents have been produced by the Network Management Research Group (NMRG) of the IRTF. /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 h98Fa9PT019719 for ; Wed, 8 Oct 2003 17:36:09 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id DB50156D5C; Wed, 8 Oct 2003 17:36:08 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 125D456D35; Wed, 8 Oct 2003 17:36:08 +0200 (CEST) Received: by james (Postfix, from userid 1000) id E3C0E82E9; Wed, 8 Oct 2003 17:36:07 +0200 (CEST) Date: Wed, 8 Oct 2003 17:36:07 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] sming last call Message-ID: <20031008153607.GA8163@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de References: <20030923101721.GA1206@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030923101721.GA1206@iu-bremen.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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, Sep 23, 2003 at 12:17:21PM +0200, Juergen Schoenwaelder wrote: > This is the start of a two week last call on the following SMIng > documents: > > draft-irtf-nmrg-sming-05.txt > draft-irtf-nmrg-sming-modules-03.txt > draft-irtf-nmrg-sming-snmp-03.txt > > If you have any issues, raise them now. Otherwise, these documents will > be submitted to the RFC editor for publication as experimental RFCs. This last call did end on October 7th (yesterday) and I received no comments. So I am going to send a message to the RFC editor asking him to put these documents into his publication queue. The SMIng project has been an interesting experience, not only on the technical side. I like to thank everyone who contributed to the final documents and especially Frank Strauss for having done most of the editing work. /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 h91B1v1v016136 for ; Wed, 1 Oct 2003 13:01:57 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id D1BFB56829; Wed, 1 Oct 2003 13:01:56 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 3505A56276; Wed, 1 Oct 2003 13:01:56 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 1FDCC81D0; Wed, 1 Oct 2003 13:01:56 +0200 (CEST) Date: Wed, 1 Oct 2003 13:01:56 +0200 From: Juergen Schoenwaelder To: brunner@ccrle.nec.de Cc: "Nmrg (E-mail)" Subject: Re: [nmrg] Re: CAPWAP work Message-ID: <20031001110156.GA764@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: brunner@ccrle.nec.de, "Nmrg (E-mail)" References: <6D745637A7E0F94DA070743C55CDA9BA01138CB2@NHROCMBX1.ets.enterasys.com> <3241.10.1.1.83.1064913633.squirrel@yamato.ccrle.nec.de> <20030930113009.GA1437@iu-bremen.de> <3578.10.1.1.83.1064999148.squirrel@yamato.ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3578.10.1.1.83.1064999148.squirrel@yamato.ccrle.nec.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -29.5 () EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-28.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 Wed, Oct 01, 2003 at 09:05:48AM -0000, brunner@ccrle.nec.de wrote: > The scenarios we are looking at, CLI is a no opt anyway (far too many APs). Sorry, I did not mean to suggest a CLI (well a standardized CLI would probably not be that bad ;-). The point I was trying to make is that if a certain group of people dislike a certain technology for whatever reason (might be totally non-technical), then they will not use it. I think the closest analogy are programming languages. People who like for example perl will continue to use something like perl regardless how often you tell them how great functional programming languages are. So I think it is important to sense what the key people really like to have and use and to let them move into that direction rather than trying to teach them that some other technology is what they really should use. Perhaps there is a correlation between WGs who did extensive and detailed requirements and technology comparison documents and WGs that fail at the end because the key driving people have gotten tired or the work has become almost irrelevant since proprietary solutions are already all over the place. [But this now sounds like we are on the problem-statement mailing list so I better shut up.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from tokyo.ccrle.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9195t1v010603 for ; Wed, 1 Oct 2003 11:05:55 +0200 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9195ofd044919 for ; Wed, 1 Oct 2003 11:05:50 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9195nAI044912 for ; Wed, 1 Oct 2003 11:05:49 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9195nfd044904; Wed, 01 Oct 2003 11:05:49 +0200 (CEST) Received: from yamato.ccrle.nec.de (jupiter.office [10.1.1.3]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with SMTP id 0EA59CE407; Wed, 1 Oct 2003 10:34:44 +0200 (CEST) Received: from 10.1.1.83 (SquirrelMail authenticated user brunner) by yamato.ccrle.nec.de with HTTP; Wed, 1 Oct 2003 09:05:48 -0000 (GMT) Message-ID: <3578.10.1.1.83.1064999148.squirrel@yamato.ccrle.nec.de> In-Reply-To: <20030930113009.GA1437@iu-bremen.de> References: <6D745637A7E0F94DA070743C55CDA9BA01138CB2@NHROCMBX1.ets.enterasys.com> <3241.10.1.1.83.1064913633.squirrel@yamato.ccrle.nec.de> <20030930113009.GA1437@iu-bremen.de> Date: Wed, 1 Oct 2003 09:05:48 -0000 (GMT) Subject: Re: [nmrg] Re: CAPWAP work From: brunner@ccrle.nec.de To: j.schoenwaelder@iu-bremen.de Cc: brunner@ccrle.nec.de, "Nmrg (E-mail)" User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.35 X-IBRFilter-SpamReport: -19.9 () IN_REP_TO,NO_REAL_NAME,PRIORITY_NO_NAME,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT,X_AUTH_WARNING X-Spam-Status: No, hits=-22.4 required=5.0 tests=BAYES_20,IN_REP_TO,NO_REAL_NAME,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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, Sep 30, 2003 at 09:20:33AM -0000, brunner@ccrle.nec.de wrote: >> >> And you need to implement several stacks on the "light weight" Access >> points. On the other hand, reusing DHCP would even help, since many >> enterprise networks have it already deployed. >> > > On the other hand, a pure access point is an IEEE 802 bridge and the APs > I had access to so far all supported the BRIDGE-MIB. Of course, most of > them also had proprietary (and sometimes rather ugly) MIB extensions > since we still have no standard MIBs for configuring basic things such > as IP interfaces or from where to download software images. > > And I have been told by some folks that they really like the newer Cisco > APs because they run something that looks and feels like an IOS CLI. The > same dilemma as usual. The scenarios we are looking at, CLI is a no opt anyway (far too many APs). Additionally, one of the targets of CAPWAP is to be able to built much cheaper APs for wide-area deployments. A potential problem is the number of protocol stacks you need to have. Marcus > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany > ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/