Hi, SNMP is good at monitoring systems, but not as good at configuring systems. The reason is fairly straightforward - Configuration requires a much more in-depth knowledge of the thing being managed than does monitoring.
I can tell if my car is working properly by asking some stock questions - does the motor start? Does it run without excessive and unexpected noise? Do the tires inflate? Can you shift in various gears, etc. But if I had to actually build or repair a car, I would need to know much more about it. SNMP is designed to allow the development of standard mib modules, and to let those be supplemented by vendor-specific mib modules. We should work to find a common set of attributes that can be monitored. If we also want to be able to do common configuration tasks, then we should also try to identify a common set of configuration parameters. But we should expect that there will be vendor-specific mib modules to supplement the standard mib module. The goal is to agree on as much as we can, keeping the ease of management by our customers/users in mind, and put that agreement into the standard mib module, and keep any vendor-specific mib modules small. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, January 30, 2004 12:57 PM > To: Glenn Mansfield Keeni; [EMAIL PROTECTED] > Subject: RE: SyslogMIB Issue-#4 // Issue-#2 > > Let me make a comment here that applies to issue #2 (BSD Centric) > > > -----Original Message----- > > From: Glenn Mansfield Keeni [mailto:[EMAIL PROTECTED] > > Sent: Sunday, January 25, 2004 3:05 PM > > To: Harrington, David > > Cc: [EMAIL PROTECTED] > > Subject: Re: SyslogMIB Issue-#4 > > > > Hi Dave, > > Thanks for the comments. I agree with you. Traps are useful. > > They provide a uniform mechanism/console for the network manager > > to manage the network, related devices and processes. > > There are two levels at which we may want SNMP traps in the > > Syslog Messaging context. > > a. To provide another option of how a message will be > > processed. Presently we have > > - log (syslogCtlLogActionTable) > > - display on users console (syslogCtlUserActionTable) > > - relay/forward (syslogCtlFwdActionTable) > > - pipe (syslogCtlPipeActionTable) > > In our products, we have many more options. I know for sure that Kiwi > syslogd also has many more options. I think many other vendors do have > other options, too. Upcoming versions of our *nix based syslogd will > definitely have more options. -sign may eventually require new actions > (verify signature? log diagnostic warning?) [this is speculated, just > for the records;)]. > > What I am trying to convey is that this is a very limited set and > different syslogd's may have totally different implementations. We can > stick with the minimal set of generic things. I am not deep enough in > SNMP to know if we (vendor) can define a mib to take care of > the others > (I am sure we can ;)). But the question is how this would > relate to the > "standard actions". > > As a side note, the filterig/rule processing system is also totally > different in different implementations, this complicates things pretty > much. So it is probably best to stick with the minimal possibilities > from stock syslogd. > > Rainer > > > >
