Re: Guidelines Document and Optional Groups

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

On Wed, 28 May 2003, Sharon Chisholm wrote:
> In section 4.8 in the MIB Review guidelines, it is RECOMMENDED
> that optional groups have a compliance statement where the
> description clause indicates that the group is optional,

More precisely, it is RECOMMENDED that optional groups _which are
relevant to a particular compliance statement_ have a GROUP
clause saying that the group is optional.

> with the rational that people might accidentally leave groups off
> the list otherwise. Has this really been a problem historically?

Well, I've seen unreferenced OBJECT-GROUPs and NOTIFICATION-GROUPs
in more than one MIB review during the past year where it was not
entirely clear what the authors had in mind.  In one case there were
optional groups that applied to only one of the compliance
statements and which made sense to implement only under certain
circumstances.  In another case the groups were not optional at all
(one was mandatory, the other conditionally mandatory).  So, yes,
the problem does arise.

In older MIB modules with retired objects (especially those that
have been converted from SMIv1) it's common to have deprecated or
even obsolete OBJECT-GROUPs and/or NOTIFICATION-GROUPs which are not
referenced by a compliance statement.  These, of course, ordinarily
needn't (and indeed, in most cases shouldn't) be mentioned in a
GROUP clause, as they not relevant any more.

> My concern with RECOMMENDING this design approach is that the
> problem it is claiming to solve doesn't seem to justify the
> extra work for
> 	- the MIB editors
> 	- MIB police
> 	- the reader needing to read a lot more text to determine
>             which are the mandatory or conditionally mandatory
>             groups. (Personally I like to skim documents on the
>             first pass and the RECOMMENDED approach is going to
>             give me bad information.)
> 
> Can we reduce this to a COULD in the next update of the
> guidelines?

I will concede that this may cause a little more work for a MIB
module editor, but it's not much:

On Wed, 28 May 2003, Andy Bierman wrote:
% I disagree.  This is not very much work:
%   
%      GROUP  fooGroup
%      DESCRIPTION
%          "Implementation of this group is optional."

I don't agree that it causes more work for a MIB reviewer.  
Whenever a MIB compiler gives a warning about an unreferenced group,
I always look at it to see if it's what the author/editor intended.  
In some cases it's obvious (e.g., groups of deprecated or obsolete
objects, as mentioned above);  more often I have to ask the
author/editor what was intended.  It's always less work for me if I
don't have to ask.

There are several ways that being explicit can be helpful to an
ordinary user of a MIB module.  Andy mentions one:
% It is useful to help track the total set of objects associated
% with a MODULE-COMPLIANCE. It also helps track when a group
% of objects was added to the MIB, since REVISION clauses tend
% to leave out these details.

Here is another:  in the OPT-IF-MIB the optIfOTSnAPRControlGroup
is mentioned in the following GROUP in the optIfOtnConfigCompl
compliance statement, but it is not mentioned in the module's
other compleance statement (optIfPreOtnPMCompl):

    GROUP  optIfOTSnAPRControlGroup
    DESCRIPTION
      "This group is optional, but is recommended for interfaces
       of ifType opticalTransport(196) that provide Automatic
       Power Reduction control functions."

Note that this GROUP clause tells the user:
- to which compliance statement the GROUP is relevant;
- under what conditions is it appropriate to implement it.

The astute user could probably figure that out without the GROUP
clause, but it seems to me that it is more helpful to be explicit.

Mike