Subject: RE: [nmrg] getlist protocol operation
From: Branislav Meandzija <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Harrington, David" <[email-masked]>, [email-masked], Aiko Pras <[email-masked]>
Cc: [email-masked]
Date: Fri, 31 Oct 2003 11:13:31 -0800
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Wijnen, Bert (Bert)
> Sent: Friday, October 31, 2003 10:14 AM
> To: Harrington, David; [email-masked]; Aiko Pras
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: vrijdag 31 oktober 2003 18:14
> > To: [email-masked]; Aiko Pras
> > Cc: [email-masked]
> > 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:[email-masked]] 
> > > Sent: Friday, October 31, 2003 10:30 AM
> > > To: Aiko Pras
> > > Cc: [email-masked]
> > > 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
> > > <http://www.eecs.iu-bremen.de/>	    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 
> > > <[email-masked]>
> > > !! 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 
> > <[email-masked]>
> > !! 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Harrington, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: [nmrg] getlist protocol operation
Date: Fri, 31 Oct 2003 19:26:29 +0100
Sender: [email-masked]

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:[email-masked]]
> Sent: vrijdag 31 oktober 2003 19:21
> To: Wijnen, Bert (Bert); [email-masked]; Aiko Pras
> Cc: [email-masked]
> 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:[email-masked]] 
> > Sent: Friday, October 31, 2003 1:14 PM
> > To: Harrington, David; [email-masked]; Aiko Pras
> > Cc: [email-masked]
> > 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:[email-masked]]
> > > Sent: vrijdag 31 oktober 2003 18:14
> > > To: [email-masked]; Aiko Pras
> > > Cc: [email-masked]
> > > 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:[email-masked]] 
> > > > Sent: Friday, October 31, 2003 10:30 AM
> > > > To: Aiko Pras
> > > > Cc: [email-masked]
> > > > 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
> > > > <http://www.eecs.iu-bremen.de/>	    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 
> > > > <[email-masked]>
> > > > !! 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 
> > > <[email-masked]>
> > > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> > > 
> > 
> 

content-class: urn:content-classes:message
Subject: RE: [nmrg] getlist protocol operation
Date: Fri, 31 Oct 2003 13:20:56 -0500
From: "Harrington, David" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>, "Aiko Pras" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
> Sent: Friday, October 31, 2003 1:14 PM
> To: Harrington, David; [email-masked]; Aiko Pras
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: vrijdag 31 oktober 2003 18:14
> > To: [email-masked]; Aiko Pras
> > Cc: [email-masked]
> > 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:[email-masked]] 
> > > Sent: Friday, October 31, 2003 10:30 AM
> > > To: Aiko Pras
> > > Cc: [email-masked]
> > > 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
> > > <http://www.eecs.iu-bremen.de/>	    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 
> > > <[email-masked]>
> > > !! 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 
> > <[email-masked]>
> > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> > 
> 

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Harrington, David" <[email-masked]>, [email-masked], Aiko Pras <[email-masked]>
Cc: [email-masked]
Subject: RE: [nmrg] getlist protocol operation
Date: Fri, 31 Oct 2003 19:13:55 +0100
Sender: [email-masked]

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:[email-masked]]
> Sent: vrijdag 31 oktober 2003 18:14
> To: [email-masked]; Aiko Pras
> Cc: [email-masked]
> 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:[email-masked]] 
> > Sent: Friday, October 31, 2003 10:30 AM
> > To: Aiko Pras
> > Cc: [email-masked]
> > 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
> > <http://www.eecs.iu-bremen.de/>	    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 
> > <[email-masked]>
> > !! 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

content-class: urn:content-classes:message
Subject: RE: [nmrg] getlist protocol operation
Date: Fri, 31 Oct 2003 12:13:44 -0500
From: "Harrington, David" <[email-masked]>
To: <[email-masked]>, "Aiko Pras" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
> Sent: Friday, October 31, 2003 10:30 AM
> To: Aiko Pras
> Cc: [email-masked]
> 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
> <http://www.eecs.iu-bremen.de/>	    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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Date: Fri, 31 Oct 2003 17:12:49 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: George Pavlou <[email-masked]>
Cc: Frank Strauss <[email-masked]>, [email-masked]
Subject: Re: [nmrg] Minutes from the Heidelberg Meeting
Reply-To: [email-masked]
Mail-Followup-To: George Pavlou <[email-masked]>, Frank Strauss <[email-masked]>, [email-masked]
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

To: Frank Strauss <[email-masked]>
cc: [email-masked]
Subject: Re: [nmrg] Minutes from the Heidelberg Meeting 
Date: Fri, 31 Oct 2003 16:08:58 +0000
From: George Pavlou <[email-masked]>
Sender: [email-masked]

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

From: Frank Strauss <[email-masked]>
To: [email-masked]
Date: 31 Oct 2003 16:57:45 +0100
Lines: 243
Subject: [nmrg] Minutes from the Heidelberg Meeting
Sender: [email-masked]

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.

Date: Fri, 31 Oct 2003 16:29:44 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] getlist protocol operation
Reply-To: [email-masked]
Mail-Followup-To: Aiko Pras <[email-masked]>, [email-masked]
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Thu, 30 Oct 2003 13:42:09 +0100
From: Aiko Pras <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] getlist protocol operation
Sender: [email-masked]

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

Date: Tue, 28 Oct 2003 17:00:18 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Frank Strauss <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] Preliminary Minutes from the Heidelberg Meeting
Reply-To: [email-masked]
Mail-Followup-To: Frank Strauss <[email-masked]>, [email-masked]
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Mon, 27 Oct 2003 17:18:42 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] getlist protocol operation
Sender: [email-masked]

--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
<http://www.eecs.iu-bremen.de/>	    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: [email-masked]

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

Date: Mon, 27 Oct 2003 12:48:05 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] nmrg publications
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

From: Frank Strauss <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] nmrg publications
Date: 25 Oct 2003 13:05:46 +0200
Lines: 10
Sender: [email-masked]

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

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Wes Hardaker <[email-masked]>, Branislav Meandzija <[email-masked]>
Cc: "Nmrg (E-mail)" <[email-masked]>
Subject: RE: [nmrg] Re: CAPWAP work
Date: Fri, 24 Oct 2003 23:37:11 +0200
Sender: [email-masked]

> >>>>> On Thu, 23 Oct 2003 09:45:47 +0200, Juergen 
> Schoenwaelder <[email-masked]> 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

From: Frank Strauss <[email-masked]>
To: [email-masked]
Date: 24 Oct 2003 19:18:55 +0200
Lines: 208
Subject: [nmrg] Preliminary Minutes from the Heidelberg Meeting
Sender: [email-masked]

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.

Date: Thu, 23 Oct 2003 18:45:03 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Wes Hardaker <[email-masked]>
Cc: Branislav Meandzija <[email-masked]>, "Nmrg (E-mail)" <[email-masked]>
Subject: Re: [nmrg] Re: CAPWAP work
Reply-To: [email-masked]
Mail-Followup-To: Wes Hardaker <[email-masked]>, Branislav Meandzija <[email-masked]>, "Nmrg (E-mail)" <[email-masked]>
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

To: Branislav Meandzija <[email-masked]>
Cc: "Nmrg (E-mail)" <[email-masked]>
From: Wes Hardaker <[email-masked]>
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
Subject: [nmrg] Re: CAPWAP work
Sender: [email-masked]

>>>>> On Thu, 23 Oct 2003 09:45:47 +0200, Juergen Schoenwaelder <[email-masked]> 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

Date: Thu, 23 Oct 2003 20:06:06 +0900
From: "Prof. J. Won-Ki Hong" <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] nmrg workshop in january 2003
Sender: [email-masked]

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
> <http://www.eecs.iu-bremen.de/>	    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 <[email-masked]>
> !! 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: [email-masked]        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/
----------------------------------------------------------------------------

Date: Thu, 23 Oct 2003 12:18:00 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] nmrg workshop in january 2003
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Thu, 23 Oct 2003 09:45:47 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Branislav Meandzija <[email-masked]>
Cc: "Nmrg (E-mail)" <[email-masked]>
Subject: Re: [nmrg] CAPWAP work
Reply-To: [email-masked]
Mail-Followup-To: Branislav Meandzija <[email-masked]>, "Nmrg (E-mail)" <[email-masked]>
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 22 Oct 2003 08:49:12 -0700 (PDT)
From: "David T. Perkins" <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
cc: [email-masked]
Subject: Re: [nmrg] meeting slides
Sender: [email-masked]

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

Date: Wed, 22 Oct 2003 11:44:49 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] nmrg publications
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 22 Oct 2003 10:30:57 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] meeting slides
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

From: Branislav Meandzija <[email-masked]>
To: "Harrington, David" <[email-masked]>, "Nmrg (E-mail)" <[email-masked]>, Andrea Westerinen <[email-masked]>, "Wijnen,   Bert (Bert)" <[email-masked]>, Marcus Brunner <[email-masked]>
Subject: RE: [nmrg] CAPWAP work
Date: Tue, 21 Oct 2003 20:16:01 -0700
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]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:[email-masked]] 
> > 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: [email-masked] 
> > [mailto:[email-masked]]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:[email-masked]]
> > > > 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 
> > > <[email-masked]>
> > > !! 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 
> > <[email-masked]>
> > !! 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Content-Class: urn:content-classes:message
Subject: RE: [nmrg] CAPWAP work
Date: Tue, 21 Oct 2003 10:58:13 -0400
From: "Harrington, David" <[email-masked]>
To: "Nmrg (E-mail)" <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
> 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: [email-masked] 
> [mailto:[email-masked]]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:[email-masked]]
> > > 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 
> > <[email-masked]>
> > !! 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], Ran Atkinson <[email-masked]>
From: Sally Floyd <[email-masked]>
Date: Mon, 20 Oct 2003 13:11:20 -0700
Subject: [nmrg] Re: [Research-funding] updates research funding draft
Sender: [email-masked]

[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

From: "Andrea Westerinen" <[email-masked]>
To: "'Branislav Meandzija'" <[email-masked]>, "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'Marcus Brunner'" <[email-masked]>
Cc: "'Nmrg \(E-mail\)'" <[email-masked]>
Subject: RE: [nmrg] CAPWAP work
Date: Mon, 20 Oct 2003 10:00:28 -0700
Importance: Normal
Sender: [email-masked]

Your last sentence summarizes the purpose and work of the DMTF in
creating CIM.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]]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:[email-masked]]
> > 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 
> <[email-masked]>
> !! 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 <[email-masked]>
!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Date: Fri, 17 Oct 2003 12:24:35 +0200
From: Marcus Brunner <[email-masked]>
Reply-To: Marcus Brunner <[email-masked]>
To: "David T. Perkins" <[email-masked]>, [email-masked]
Subject: Re: [nmrg] Pre-meeting details
Sender: [email-masked]

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" 
<[email-masked]> 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
> <[email-masked]> !! or look at
> https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
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

Date: Fri, 17 Oct 2003 03:08:02 -0700 (PDT)
From: "David T. Perkins" <[email-masked]>
To: [email-masked]
Subject: [nmrg] Pre-meeting details
Sender: [email-masked]

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

Date: Thu, 16 Oct 2003 18:30:25 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] NSF workshop on fundamental research in networking report
Sender: [email-masked]

Some of you might find this interesting:

http://www.cs.virginia.edu/~jorg/workshop1/NSF-NetWorkshop-2003.pdf

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 15 Oct 2003 23:30:35 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Subject: [nmrg] updates research funding draft
Sender: [email-masked]

--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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=qwqw

>From [email-masked] Tue Jul 22 17:57:01 2003
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked], [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked]
Subject: [Research-funding] Re: [nmrg] network management research funding text
Sender: [email-masked]
Date: Tue, 22 Jul 2003 17:55:12 +0200
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
<http://www.eecs.iu-bremen.de/>	    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
[email-masked]
https://www1.ietf.org/mailman/listinfo/research-funding

--2oS5YaxWCcQjTEyO--

From: Branislav Meandzija <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, Marcus Brunner <[email-masked]>
Cc: "Nmrg (E-mail)" <[email-masked]>
Subject: RE:  [nmrg] CAPWAP work
Date: Tue, 14 Oct 2003 18:50:44 -0700
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]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:[email-masked]]
> > 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Date: Tue, 14 Oct 2003 11:50:12 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Wes Hardaker <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] Re: nmrg14th NMRG meeting in Heidelberg
Reply-To: [email-masked]
Mail-Followup-To: Wes Hardaker <[email-masked]>, [email-masked]
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

To: [email-masked]
From: Wes Hardaker <[email-masked]>
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
Subject: [nmrg] Re: nmrg14th NMRG meeting in Heidelberg
Sender: [email-masked]

>>>>> On Tue, 23 Sep 2003 17:56:24 +0200, Juergen Schoenwaelder <[email-masked]> 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

Date: Wed, 8 Oct 2003 14:19:31 -0700
From: RFC Editor <[email-masked]>
To: [email-masked]
Cc: RFC Editor <[email-masked]>
Subject: [nmrg] Re: SMIng documents ready for experimental RFCs
Sender: [email-masked]

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
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 8 Oct 2003 17:40:08 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked]
Subject: [nmrg] SMIng documents ready for experimental RFCs
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 8 Oct 2003 17:36:07 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] sming last call
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 1 Oct 2003 13:01:56 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: "Nmrg (E-mail)" <[email-masked]>
Subject: Re: [nmrg] Re: CAPWAP work
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], "Nmrg (E-mail)" <[email-masked]>
Sender: [email-masked]

On Wed, Oct 01, 2003 at 09:05:48AM -0000, [email-masked] 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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 1 Oct 2003 09:05:48 -0000 (GMT)
Subject: Re: [nmrg] Re: CAPWAP work
From: [email-masked]
To: [email-masked]
Cc: [email-masked], "Nmrg (E-mail)" <[email-masked]>
Importance: Normal
Sender: [email-masked]

> On Tue, Sep 30, 2003 at 09:20:33AM -0000, [email-masked] 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
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
> Germany
>

-----------------------------------------
This email was sent using SquirrelMail.
   "Webmail for nuts!"
http://squirrelmail.org/