[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use of OBJECT-IDENTITY
The use of the OBJECT-IDENTITY construct doesn't bother me.
However, there are several other design choices that do bother
1) "relaxed" usage of the term MIB (it's just sloppy).
Term "MIB tree" is just wrong.
2) use of counter64 instead of counter32, or is the current
approach changed to always use counter64 so you do not
have to be concerned of counter rollover?
3) use of "accessible-for-notify". There should be little, if
any, use of this max-access value. The problem is that
notifications cannot be guaranteed to be delivered,
and if the MIB model design is based-on management info
being available only via notifications, then there will
be times when needed info is not available.
4) indexing, number of instances, and relationships between
tables is not immediately obvious nor fully described.
In each table description, there MUST be a sentence or
two that provides the reader a clue to the number of
instances in the table. This could be as simple as
saying the number corresponded to the number of a
specific type of physical components. Or this could
correspond to the number of instances in another table.
Or it could be the number of "provisioned" entries of
some logical resource. In addition, the DESCRIPTION
clause for rows MUST indicate if row creation is allow
or not, if so, then details.
5) There are no objects with access of read-create or read-write.
This seems VERY strange.
PS Have you looked at http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt. It does some creative (not quite valid) things.
At 04:44 PM 3/17/2004 +0100, Wijnen, Bert (Bert) wrote:
>In draft-ietf-dhc-server-mib-10.txt I see the use of
>OBJECT-IDENTITY that I think was not intended.
/david t. perkins