Re: Compliance Statements

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

HI,

You guys are starting on something that is a little bit more
complex than you may realize.

The major uses of Enums are to identify states, used for triggers
of an action-status object, and to identify an item in an
extensible list. (When a list has distributed
"naming", then OID values are typically used.)

Unfortunately, the SMI doesn't make a distinction between these uses,
and allows additional enum values to be added. Of course, this is
not at good thing to do with states and action-status objects,
since it changes the semantics and possibly breaks cross version
compatibility. Of course, new enum values are expected to be
added for identify items in an extensible list, and mgmt applications
must be written to cope with this.

When enums are used for action-status objects, some values are
write-only, some are read-write, and others are read-only. The
SMI no provisions in TC or object definitions (other than text
in a DESCRIPTION clause) to describe the access for values.
And there is no provision in MCs or ACs to describe access
for values.

At 10:18 AM 2/14/2003 -0800, C. M. Heard wrote:
>On Fri, 14 Feb 2003, Wijnen, Bert (Bert) wrote:
>
>> > > - page 25 2nd bullet
>> > >   I actually wonder if it would not be better if people did
>> > >   list all the enumerations at the first revision of a MIB
>> > >   and the compliance statements. That way... it is clear 
>> > >   from the beginning what it is that one can expect.
>> > > 
>> > >   Of course some enumerations do not need that, because they
>> > >   are [not] intended to be extended, and that is OK.
>> > 
>> > I think RFC 2580 already says that.  Do we need to repeat it
>> > here?  The document is already pretty long, and it's not getting
>> > any shorter.
>> > 
>> I may not have been clear. What I meant to say is:
>> Suppose you have in the first version of a MIB MOdule
>> 
>>    someObject OBJECT-TYPE
>>        SYNTAX      INTEGER {
>>                       enum1(1),
>>                       enum2(2)
>>                       }
>>        MAX-ACCESS  read-create
>>        STATUS      current
>>        DESCRIPTION "Some descr"
>> 
>> Then I would think if any COMPLIANCE statement in that MIB Module
>> could have (from the start):
>>   
>>     OBJECT someObject
>>     SYNTAX INTEGER   {
>>                       enum1(1),
>>                       enum2(2)
>>                      }
>> 
>> So that it is automatically covered if anyone at any time later
>> adds something to the enumerations.
>
>Yes, this is what I understood from the beginning, and I think RFC
>2580 already has some advice to this effect.  I will have some other
>stuff that I need to do today so I will have to follow up on this
>later.
>
>Mike
Regards,
/david t. perkins