Hi, I have finally found time to review the mib-09 document.
1) There are multiple pages that exceed the maximum allowed lines per page. 2) The headers and footers do not appear to be standard. There should an abbreviated title for easch page after the first. 3) the terminology is not consistent with the other WG documents. 4) "roles a syslog entity maybe in" would be better as "roles of a syslog entity" (although then entity should be changed according to #3. 5) I concur with Bert that the citations in section 2 seem inappropriate. 6) I find the references to SA-Li, RA-Rj confusing since these are not used in the diagram. 7) "The MIB comprises of four groups" would be better as "The MIB contains four groups" 8) Section 3 has a number of lists. You should decide if the list should contain sentences, or makes up one complete sentence. If it is one sentence, then each listed clause should end with a comma, and be consistent in style. If each item is a sentence, then the introductory phrase needs to be a sentence. I recommend making each item a sentence, so we can eliminate the "which" conrstructs. 9) "asynchronously monitor" s/b "asynchronously report" 10) the name of SyslogMIB or syslogMIB should be consistent in the text. I recommend using SYSLOG-MIB, which is the correct name for the MIB module. 11) in SyslogSeverity, I recommend removing the second sentnece in the description "The syslog protocol uses the values 0 (emergency) to 7 (debug)." since this is already spelled out in the SYNTAX clause, and shows that 99 (other) is also used. Why do we need 99? Are other values valid? 12) SyslogService - can we make this just a service name. The port semantics are really ambiguous. How do distinguish a UDP port# from a TCP port#? 13) For consistency with most other MIB modules being developed, I suggest defining a top-level breakdown of syslogNotifications (0), syslogObjects (1), and syslogConformance (2). Then put syslogSystem and syslogDevice under syslogObjects. See RFC4181 appendix D. 14) transportAddressType is designed to be used with specific types of transportAddress. The syslogDefaultTransport object should probably be syslogDefaultTransportType. A transportAddressType seems inappropriate for use with syslogDefaultService, which does not necessarily resolve to one of the enumerated options. We should have a syslogDefaultTransport that is a transport address. If we want a Default service, that should probably be a separate object. 15) some objects are named xxxSeverity, but the description uses priority. We need to be consistent with the other documents about what this is called. 16) the syslogDefaultMaxMessageSize description really needs work - 480 is the minimum maximum size, not the recommended maximum size, so it should not be the default. The maximum message size also may depend on the transport protocol and the target system, so I'm not sure a default is a useful object. Who is the user of this default? The local system? If so, then it is an implementation detail and does not need to exposed in a mIB object. If it is for use by the remote system, then it shouldn't be a default value, but the actual value supported by the implementation. 17) syslEntOpsTable uses abbreviated elements in the name. I don't see why they need to be abbreviated, or what the name actually means. The description does not mention "ops". 18) object prefixes should be consistent for the whole module. The DefaultXXX uses syslog as the prefix, but here we use sysl. Why? See RFC4181 appendix C for naming guidelines. 19) syslEntCtlTable contains static info; does that imply that syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about the operational environment, and syslEntCtlTable about control info? The descritions should kae the purpose of the table unambiguous. 20) In the SNMPv2 effort, we found that using integer indices made using the tabels more difficut for human readers. It would be much easier for a human to interpret the statistics here is it is easy to tell what the systlog entity is. So I recommend using an SnmpAdminString as the index. For systems that cannot, for whatever reason, determine a human-readable identifier for the index, the SnmpAdminString can always be "1", "2", etc. 21) what is the persistence of the index? If syslog entities happen to start in a different order, will the index# refer to the same entity after a reboot? If the MIB says they must be persistent across reboots, how difficult will that be for the OS that starts the applications? What value will the system keep to match up to the integer indicies to make sure they remain the same? 22) syslEntOpsMsgsDropped counts messages that could not be relayed. What about messages that cannot be queued for transmission for an original sender? 23) syslEntOpsMsgsIgnored - where are the "allowed specifications" defined? We don't want a value that can be interpreted differently by different entities, because then the values canot be compared across systems, or have consistent baselines for comparison across products, etc. Objects shoud be defined to be interoperable and unambiguous. 24) syslEntOpsLastMsgDeliveredTime - the system does not know when the message was delivered, only when it was transmitted or received. 25) syslEntOpsLastError talks about "this process". Is this the syslog entity? This needs to be clear and unambiguous, and consistent with the terminology in the other WG documents. 26) syslEntOpsLastError talks about the last error this process "encountered". The definition of encountered needs to be made unclear and unambiguous. 27) what is the persistence of the syslEntOpsReference across reboots of the OS? Across reboots of the SNMP system? If it is not persistent, but the table is, what should the SNMP agent do - delete the references? Change the references to match the new SWRunIndex? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog