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
