Re: Guidelines Document and Optional Groups

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

hi,

You can't put compliance requirements in the DESCRIPTION clause
for a GROUP. Why? Because compliances are specified in
MODULE-COMPLIANCE specifications. In one compliance specification,
a group can not be needed (under any circumstances). In another
case, the group will be needed in specific circumstances, and
finally, in another compliance, a group is needed in all
circumstances.

The confusion is that MODULE-COMPLIANCEs are used BOTH in MIB
modules in RFCs to specify what must be implemented to claim
conformance to the RFC, AND in compliance statements from other
RFCs and/or users of management products. For an example of
the later, a compliance specification can be written for agents
that a management app interacts with. The compliance specifies
the objects and notifications that MUST BE implemented for the
management app to function. For example, for an RMON mgmt app
to function, objects and notifications from the RMON MIB modules
must be implemented. However, there is no need for objects from
the OSPF MIB module to be implemented for the RMON app to function.


The text in the
MIB review document is meant to deal with the issue of defining
objects and notifications in RFCs, but not requiring them to
be implemented. This is BAD, BAD, BAD. Such items are "totally
optional" and, thus, don't belong in standards track RFCs.

With standards track documents, it is sometimes easier (and better)
to have one module compliance. Other times it is better to have
subsetting module compliances for a basic, intermediate, and
advanced implementations. And still other times it is best to
have separate compliances for disjoint implementation requirements.
(In the later case, it might be better to split the RFCs, but
such choices depend on factors such as size.)

At 09:59 AM 5/28/2003 -0700, Andy Bierman wrote:
>At 07:20 AM 5/28/2003, Sharon Chisholm wrote:
>>hi
>>
>>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, with the rational that people might accidentally
>>leave groups off the list otherwise. Has this really been a problem
>>historically?
>>
>>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 disagree.  This is not very much work:
>  
>     GROUP  fooGroup
>     DESCRIPTION
>         "Implementation of this group is optional."
>
>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.
>
>
>>Sharon Chisholm
>>Portfolio Integration
>>Nortel Networks
>>Ottawa, Canada
>
>Andy
Regards,
/david t. perkins