[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Process for SMIng Syntax Proposal Submissions:



Title: RE: Process for SMIng Syntax Proposal Submissions:

> Number 1 problem area for cisco mib-police (MIB review board):
> - creating or updating a MODULE-COMPLIANCE or OBJECT-GROUP macro
> Authors almost always get this wrong. I don't want to remove it though.
> We could not agree on which objects to include in a MIB without
> the flexibility of the MODULE-COMPLIANCE macro.  (It should really
> be called the MODULE-NON-COMPLIANCE macro, since it's used
> to describe all the ways not to conform to the MIB definitions as specified
> in the OBJECT-TYPE macros. :-)

I understand that there is some value in module compliance. I agree with what you describe above.

There are many ways that module compliance statements are not useful and I think that they outweigh the good.

For example, imagine querying some simple object on some box in the network. The object comes back with a value of 0 when you are expecting some positive number. Now, is that value 0 because it is really the correct value or is it 0 because some module compliance statement somewhere suggested that the vendor implemented this object differently. Now, assuming there is a module compliance statement out there somewhere, find the MIB module from that vendor and for that product that has the module compliance statement. Next to impossible. Hence where is the value for the customer.

To do module compliance properly I believe that it needs to be available from the box over SNMP. That way network management tools could choose to make use of the information. I am not sure we should do what I just suggested, but it does provide more value than the module compliance statement in the MIB.

Cheers, /gww