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
