With some trepidation I will offer some limited explanation of the history of the MIB, hopefully I will not try to constrain or influence the future direction as I have abdicated my editorial duties.
The MIB, as it was in draft -01-, was an attempt to provide SNMP management support for syslog devices. Since file and GUI based management of syslog relays and collectors is already well established, possibly more complex, and not something that needed to be performed on 10's, 100's, 1000's, etc. of entities at a time no effort was expended in that area. The text in section 3 was an attempt to describe what were considered the two major classes of implementations. The first class is what is offered in vxWorks, the OS handles the distribution of the syslog messages to the various configured servers, all servers are fed from the same queue, and are sent the same messages. The second class of implementations would allow the messages to be filtered on a per application and per priority basis, per server. Some of the text discusses this in the context of managing network equipment, I could see the need to rewrite that in more general terms, or the rest of it in more easily understandable terms. The DefaultUdpPort, DefaultFacility, and DefaultSeverity objects were an attempt to provide unambiguous or straight forward support for both classes of implementations described in section 3. Initially the MIB was written for the second class of implementations and then extended to support the vxWorks implementation. There might be simpler ways to achieve this. The indexes for the table could be unconstrained, if they are there might be value in having objects that describe the maximum number of entries that are supported in the tables, if it is considered best, or reasonable, current practice. LastMessageTime and MessagesIgnored where for diagnostic purposes, one could poll 1000's of devices and see when the most recent message was sent, might be reassuring if ones collector had not seen any messages for some time period and one wanted verification that none had been sent. MessagesIgnored would let one know that applications had been generating messages but that they had been filtered. Hopefully what I have written does not impede anyone from finding a cleaner, simpler, more all encompassing management interface for syslog. With friendly Greetings, Bruno -----Original Message----- From: Harrington, David Sent: Wednesday, January 01, 2003 6:25 PM To: [EMAIL PROTECTED] Subject: FW: syslog mib review Hi, I have some comments based on a fairly quick review of the mib in -01-. I will do a more thorough review when Glenn publishes a new revision. The bulk of section 2 should be replaced with the new mib boilerplate, which can be copied from RFC3418. The paragraphs on RowStatus and RFC2119 should probably be made separate subsections under section 2. Section 3 looks like it could use a complete rewrite. I'll consider providing text if Glenn hasn't already rewritten this. Much of this seems to reflect implementation-specific considerations. I recommend chaging the name from DRAFT-IETF-SYSLOG-DEVICE-MIB to simply SYSLOG-DEVICE-MIB. If this mib is oriented toward the client, it might be better named as the SYSLOG-CLIENT-MIB and have another for server configuration. The object-types typically start with snmpSyslog or etsysSyslog. Both the "snmp" and "etsys" prefixes can be removed, and object descriptors can start with "syslog". Bruno Pape should be removed from the CONTACT-INFO, although I think he should be acknowledged in an Acknowledgement or Authors section (the chairs can decide how they want to handle that issue). IANA should provide a number to replace the 999999 in the MODULE-IDENTITY. The chairs can handle that. I'm not sure that this should be directly under snmpModules. The Textual Conventions use syslog enumerations. REFERENCE clauses should be included to document where the values are officially defined. The message counters don't indicate whether they are persistent or not, and do not define "successfully delivered", which could lead to varying interpretations and subsequent problems with interoperability. LastMessageTime - I'm not sure this will be useful in practice. What is the anticipated rate of queueing versus the anticipated rate of polling? I'm not sure the DeviceControl BITS object is justified if there is only one value. CollectorMaxEntries has a range (1..8). This looks to be an implementation-specific decision. The same for NextAvailableIndex. I don't like the last paragraph of the description for NextAvailableIndex, or understand why it is needed. Row creation should follow the normal constraints of SNMP SETs for row creation. CollectorEntry: There may be better ways to specify the non-volatile requirements, such as the StorageType Textual Convention. I would change "across entity resets" to "across re-initializations of the network management portion of the system". CollectorIndex should not be constrained to the (1..8) range. If syslog is ever used over transports that are not IP-based, then using transport address conventions as discussed in RFC3419 might be appropriate. CollectorUDPPort might be better as simply CollectorPort to allow TCP ports to be specified. I'm not sure I understand why the MessagesIgnored counter is important to maintain. I would eliminate the DefaultUdpPort, DefaultFacility, and DefaultSeverity options as adding unnecessary complexity, unless the WG feels this is justified. The security boilerplate is under review by the O&M Area. It should be updated when the new boilerplate becomes available. References should be updated. SNMPv3 has been published in new RFCs, and th eboilerplate for mibs has been simplified, so many of the references can be eliminated from this document, and some need to be modified. dbh --- David Harrington [EMAIL PROTECTED] co-chair, IETF SNMPv3 WG
