[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MODULE COMPLIANCE

HI,

Thanks for looking this up. However, the important paragraph is
the one that follows the one you quoted, which is....
   A group which is named in neither a MANDATORY-GROUPS clause nor a
   GROUP clause, is unconditionally optional for compliance to the MIB
   module.
An also of importance is section 5.4.4, which is....
   The DESCRIPTION clause must be present for each use of the GROUP or
   OBJECT clause.  For an OBJECT clause, it contains a textual
   description of the refined compliance requirement.  For a GROUP
   clause, it contains a textual description of the conditions under
   which the group is conditionally mandatory or unconditionally
   optional.

So, it looks like that you have found a place in RFC 2580, that is
a little unclear. And part of MODULE-COMPLIANCES that is a little
broken!

First, a MODULE-COMPLIANCE is a generic formal way for specifying
implementation requirements. (Which can also be used to specify
implementation requirements for claiming conformance to an RFC.)
Secondly, OBJECT-GROUPs and NOTIFICATION-GROUPs are just short-hand
ways of specifying a list of object and notification types. Putting
an object or a notification as a member of a group has no semantic
meaning.
Thirdly, an object or notification can be a member of more than one
group.
Fourth, when you write a requirements specification and do not make a
reference to an item, of course, implementing such as item is
unconditionally optional with regards to that requirements specification.

If you put all of these together, it shows the broken part of
MODULE-COMPLIANCE specifications...
The definitions do not say if it is valid or not valid to
specify groups that contain the same objects (or notifications).
Lets say I have group g1 with objects o1, o2, o3, and o4; and
group g2 with objects o3 and o4. Does the definition of MODULE-COMPLIANCES
allow me to define mc1 with mandatory group g1 and "unconditionally
optional" group g2, with the result being objects o3 and o4
are unconditionally optional? Note that there is no way for
a MIB compiler to determine this!

So yes, the term "unconditionally optional groups" is used, but it
is rather broken in its use in first paragraph of section 5.4.2,
and in section 5.4.4. Its use in the 3rd paragraph of section 5.4.2
is fine. (And I'm surprised that I let this slip through
the last update. Maybe I was worn out by the time we got to what
became RFC 2580. Sorry.)

I believe the only valid way to specify MODULE-COMPLIANCE c1 (above)
is to say that group g1 is mandatory, and then use the OBJECT
clause to specify that objects o3 and o4 are not required to
be implemented to claim conformance.

At 02:20 PM 1/7/2003 -0800, C. M. Heard wrote:
>On Tue, 7 Jan 2003, David T. Perkins wrote:
>> Note that "unconditionally optional group" is a not valid term.
>
>Well, look at RFC 2580, 5.4.2, "Mapping of the GROUP clause":
>
>   The GROUP clause, which need not be present, is repeatedly used to
>   name each object and notification group which is conditionally
>   mandatory for compliance to the MIB module.  The GROUP clause can
>   also be used to name unconditionally optional groups.  A group named
>   in a GROUP clause must be absent from the correspondent MANDATORY-
>   GROUPS clause.
>
>It's used there.
>
>//cmh
Regards,
/david t. perkins