Re: Guidelines Document and Optional Groups

[Andy Bierman <abierman@cisco.com>]

At 11:31 AM 5/28/2003, David T. Perkins wrote:
>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 GROUP clause is part of the MODULE-COMPLIANCE.
Maybe you are thinking of OBJECT-GROUP.  The DESCRIPTION
clause for a GROUP clause is exactly where compliance
details for an associated OBJECT-GROUP belong.


>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.

I think optional groups are a political reality, even if they
are technically objectionable.  Ideally, there would only
be mandatory and conditionally mandatory groups.  I agree 
that purely optional groups should be discouraged, but they
are better than nothing (proprietary MIBs or CLI instead).


>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.)

I don't agree that RFCs should be split based on MIB object
conformance requirements.  The whole point of the conformance
section is to identify potentially varying requirements for
a single MIB module.

Andy



>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