Hi Albert, Thank you for your comments. I will have to review the MIB with them in mind.
To summarize your comments, the MIB needs to be extended to include control of syslog on UNIX platforms. I agree. Anyone have any thoughts of what extensions might be required for the PC platform? It was written from the perspective of a non UNIX embedded platform. The concept of an application came about because most of the processes in an embedded device do not map well to the non-local facilities. Like kernel(0), etc. This requires that multiple applications be mapped onto one or more of the local facilities. The control over individual applications allows varying the severity of the messages generated by each application. This was viewed to be useful from a diagnostic point of view, where one might want to have very detailed messages from an application like spanning tree, but might not want to be overwhelmed with messages from all the other applications that might be running. The numbering of the severity from 1-8 has to do with a limitation of SNMPv1, I will check and see if this limitation is lifted with v2. Otherwise it will just be a mapping of 0-7 onto 1-8. Some of the statistics had to do with messages that might be dropped due to internal queue limitations. In a diagnostic mode there might be more messages generated than can be queued internally and it would be nice to provide some indication of that. I will try to rethink the MIB from the UNIX/Windows perspectives. Anyone else have any thoughts or comments? Should this MIB try to cover all possible syslog device cases? With friendly greetings, Bruno "albert.mietus" wrote: > Hai all, > > I'm not a great expert on MIB, but I give it a try. Here are my remarks on > the the first syslog-mib draft (Nov 2001). > > * H3 > I think I misinterprepate the 2 figures. Or they are't "the same" as the > syslog-syslog one. > > The figures (expessially no 1), suggest that there is a distiction between > "the application" and "the syslog device". This isn;t true according to > RFC3164: the syslog-device is the "first" component is a row. > > Is "SDS" (in the middle) 'Syslog Device Software' a device of is it a relay > (like sysliogd on Unix). The name suggest the fist, the figure the second > option. > > Please clearify this. Best by pictures simulair to the ones in rfc3164. > > * H5, p5 SyslogFacility > I mis the non-local facilities. Like "kernel (0)", "mail(2)", etc. See the > rfc for a list. > > * H5 p5, SylogSeverity > There is a mismummering in the integers. > Emergency should be (int) 0 (not 1). Debug 7 (not 8) > Simulair for the inbetweens > > * P6, snmpSyslogDeviceMessages: DESCRIPTION > Remove "succesfully". syslog devices don't know this! > > * P6, snmpSyslogDeviceMessagesDropped > I think this one isn't needed. See above > > * P6 snmpSyslogDiviceMessagesFilered (ADDED > Add this counter to count the number of messages that where filtered out > due to the thesshold of the syslogdevice > Optional: add it as an array (table). One counter per facilty. > > * P9, snmpSyslogCollectorFacility > Update the description "local0-local7", as changed in SysLogFAcily (see > above) > > Hope this will help > > --ALbert > sent mail to [EMAIL PROTECTED], to address me personal. > sent mail to [EMAIL PROTECTED], to address me for businesses
