Re: Compliance Statements

["C. M. Heard" <heard@pobox.com>]

On Sat, 15 Feb 2003, Andy Bierman wrote:
> At 12:36 PM 2/15/2003 -0800, C. M. Heard wrote:
> >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.

That's a good point.  Notice that guidelines section 4.9 already
say something about this:

   - RFC 2580 should (but does not) recommend that OBJECT clauses
     specifying support for the original set of values be added to a
     compliance statement when enumerated INTEGER objects or BITS
     objects referenced by the compliance statement have enumerations
     added, assuming that no such clauses are already present.  This is
     necessary in order to avoid a silent change to the meaning of the
     compliance statement.  MIB module authors and reviewers SHOULD
     watch for this to ensure that such OBJECT clauses are added when
     needed.  Note that this may not always be possible to do, since
     affected compliance statements may reside in modules other than the
     one that contains the revised definition(s).

> This can go in a new deprecated M-C,
> at the same time you create a new current M-C.

You don't even need to deprecate the existing M-C,
assuming it still says what you want to say.
Recall that this was done for the RMON-MIB revision
that had the extra enums to support HC stuff.

//cmh