Dave, Thanks for the comments. Most of them have been incorporated in the -02 draft or are not-applicable as the draft has changed. Some remain as TBDs. Hope to get those in the next version.
My reactions are inline. Harrington, David wrote: > 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. This is done. > The paragraphs on RowStatus and RFC2119 > should probably be made separate subsections under section 2 This probably does not apply. > > Section 3 looks like it could use a complete rewrite. >I'll consider providing text if Glenn hasn't already rewritten this. Yes it has been completely rewritten. Please feel free to add or suggest modifications. 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. I have left the draft name the same but as far as the contents are concerned it is a syslog-MIB. > > 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". This is already done. > > 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). This is not yet done. I was under the impression that Bruno will be on the team. Let me know if I am wrong. > > 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. TBD. > > The Textual Conventions use syslog enumerations. REFERENCE clauses should be > included to document where the values are officially defined. This is yet to be done. > > 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. TBD > > 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. Not Applicable. > > 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. Not Applicable. > > 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. Not applicable. > > I'm not sure I understand why the MessagesIgnored counter is important to maintain. This could be of interest to a Manager to know how many useless messages are being directed to it. > > I would eliminate the DefaultUdpPort, DefaultFacility, and DefaultSeverity options >as adding > unnecessary complexity, unless the WG feels this is justified. Not really. Let me have other opinions. > > The security boilerplate is under review by the O&M Area. It should be updated when >the new > boilerplate becomes available. Absolutely. I have not worked on this section at all. > > References should be updated. SNMPv3 has been published in new RFCs, and the >boilerplate for > mibs has been simplified, so many of the references can be eliminated from this >document, and > some need to be modified. Some cleaning has been done. I will take another look at this. > > dbh > --- > David Harrington > [EMAIL PROTECTED] > co-chair, IETF SNMPv3 WG Thanks a lot. Glenn
