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
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net



_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog