First, I am not on your mailing list, so pls copy me on the
follow up email if you want me to see it.
Since I was in the syslog WG session today I quickly scanned
the document. I would STRONGLY URGE you to look at
draft-ietf-ops-mib-review-guidelines-01.txt
and make sure that you follow those guidelines, certainly before
you submit this to the MIB doctors for review. A lot of my comments
below could/SHOULD have been addressed by just following those
guidelines.
Here is a initial set of things I noticed:
- do not do
- Do not include REVISION clauses for I-D revisions.
You can keep that text in an appendix or so (to be deleted
when it becomes an RFC).
A MIB that becomes RFC for the first time has just ONE
REVISION clause
- I see you use Integer32 for index objects. It is acceptable,
but the recommendation is to use Unsigned32 and I do not see
why that would not work for you
- You have a RowStatus object that says:
- you have syslogAllowedHostsMaskLen as a Integer32.
Why is that not a InetAddressPrefixLength (from RFC3291) ?
- syslogAllowedHostsTable does not have a StorageType object,
nor does the table DESCRIPTION clause say anything on
persistency behaviour
- you have syslogParamsRowStatus and state in DESCRIPTION clause
a. change the row status to ''invalid'', causing its deletion
b. create a new conceptual row with the desired values.
Well, 'invalid' is NOT one of the values that a RowStatus can
be set to.
- The StorageType object that you DO use, does not describe
what columns MUST be writable for 'permanent' rows. See the
StorageType TC in rfc 2579.
- I see
syslogParamsFacilityTranslation OBJECT-TYPE
SYNTAX INTEGER {
off (1),
on (2)
}
MAX-ACCESS read-write
Why is that not a TruthValue?
There are more of those objects that I think can be represented
with a TruthValue Syntax
- syslogParamsSecuritySpecs
Why do the enums start at zero while we recommend to start at 1
There is probably much more. Please review the MIB guidelines and
try to do a good job at following them
Thanks,
Bert
