RE: Compliance Statements

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> >It turns out that RFC 2580 does have this advice for agent-caps
> >statements (it is in the last paragraph of Section 6.5.2.1), but
> >it has no similar advice for compliance statements.  So, I guess
> >it would indeed be a good idea to add something to this effect
> >to Section 4.8 of the guidelines.  Here is what I come up with:
> >
> >   Even in a compliance statements where all values are 
> required to be
> >   supported, it is RECOMMENDED that an OBJECT clause listing all
> >   enumerations be provided for each writeable object of enumerated
> >   INTEGER or BITS type if the set of named numbers or named 
> bits might
> >   be expanded in a future revision of the MIB module.  Doing so will
> >   ensure that the meaning of the compliance statement 
> remains unchanged 
> >   even after such a revision.  This is not necessary, of course, for
> >   objects that are not required to be writeable nor for 
> objects whose 
> >   value set will remain unchanged when the MIB module is revised.
> >
> >Comments?
> 
> This will make M-Cs extremely verbose and a lot of work to create.
> It would be better to create these verbose OBJECT clauses only
> when the enum list is extended, when you know for sure the
> OBJECT clause is needed.  This can go in a new deprecated M-C,
> at the same time you create a new current M-C.
> 
I do understand that concern. 
But if you have for example imported TCs that can be changed, then
they might happen without the authors of the TC doc knowing all
the places where it is used.

I agree that if one uses ENUMs/BITS that are defined in ones
own module, that it is not needed. Maybe it is more important
for imported ENUMs/BITS. 

Bert
> 
> >//cmh
> 
> Andy
> 
>