RE: Process for SMIng Syntax Proposal Submissions:

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Glenn - in your message below it appears that you are confusing
MODULE-COMPLIANCEs with AGENT-CAPABILITIESs.

A MODULE-COMPLIANCE is a formal "requirements specification".
All RCFs on the standards track need a requirements portion,
either in the RFC or in another RFC.

A MODULE-COMPLIANCE can be used by purchases of managed devices
to formally say what they want. MODULE-COMPLIANCES can be
used by management application writers to say what objects
and notifications are "required" for implementation in the
agents for the management app to function.

On the other hand an AGENT-CAPABILITIES specification is
used to document implementation of an agent.

Your example appears to demonstrate invalid implementation,
which cannot be made OK by an AGENT-CAPABILITIES specification.

That is, the definitions in a MIB module specify architectual
limits. For example, consider a field in a protocol that must
be encoded in 8 bits, and has range from 0 to 255. If an
agent returned a value of 256 for it, then there is a bug
in the agent or the resource manager that supplied the
agent with the value. YOU cannot use AGENT-CAPABILTIES
to describe invalid behavior. 

In the pas (oh about 8 years ago) SMIv1 was not clear
as to what you put in definitions, whether range of
behavior for compliance or architectual behavior.
This was clarified in SMIv1, which is architecual
behavior. Now, if the MIB authors did not properly
write the MIB module because they missed this point
of understanding of SMIv2, then the MIB module needs
the be corrected!

On Tue, 30 Oct 2001, Glenn Waters wrote:

> > 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 
> 

Regards,
/david t. perkins