Re: Guidelines Document and Optional Groups

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

On Wed, 28 May 2003, Andy Bierman wrote:
> At 11:31 AM 5/28/2003, David T. Perkins wrote:
> >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.

This is true, but the point is well-taken that it is inappropriate
to put implementation requirements into the DESCRIPTION clause of an
OBJECT-GROUP or a NOTIFICATION-GROUP.  One example where this has
been done is in the SNMPv2-MIB's snmpNotificationGroup:

   snmpNotificationGroup OBJECT-GROUP
       OBJECTS { snmpTrapOID, snmpTrapEnterprise }
       STATUS  current
       DESCRIPTION
               "These objects are required for entities
               which support notification originator applications."
       ::= { snmpMIBGroups 12 }

As noted in my previous message, this group is not mentioned in the
SNMPv2-MIB's compliance statements.  That makes it optional with
respect to those compliance statements, despite what its DESCRIPTION
clause says.  I make it a point to ask authors of new MIB modules I
am reviewing NOT to put implementation requirements in OBJECT-GROUP
or NOTIFICATION-GROUP DESCRIPTION clauses.

In older MIB modules I'm sometimes inclined to be more lenient.
For instance, the following NOTIFICATION-GROUP definitions are
taken from the DS1-MIB (RFC 2495) and the DS3-MIB (RFC 2496):

     ds1NearEndOptionalTrapGroup NOTIFICATION-GROUP
         NOTIFICATIONS { dsx1LineStatusChange }
         STATUS    current
         DESCRIPTION
                 "A collection of notifications that may be
                 implemented on DS1 and DS2 interfaces."
         ::= { ds1Groups 8 }

     ds3NearEndOptionalTrapGroup NOTIFICATION-GROUP
         NOTIFICATIONS { dsx3LineStatusChange }
         STATUS    current
         DESCRIPTION
                 "A collection of notifications that may be
                 implemented on DS3/E3 interfaces."
         ::= { ds3Groups 6 }

Neither of these is mentioned in the compliance statements.  The
modules are under revision by the AToM MIB WG and I recently did a
MIB review of the revised modules.  These definitions were left
unchanged.  I considered requesting that they be changed and
mentioned in the compliance statements, but decided not to since the
intent is clear (the groups are optional) and it agrees with what
the compliance statements actually say.

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

I agree with this assessment.  I would like to add a couple of
additional points:

- SMIv2 does not forbid "totally optional" objects or groups. See
RFC 2580 section 5.4.2 for groups (which uses the term
"unconditionally optional") and 5.4.3.3 (and the MIN-ACCESS macro
definition) for objects.

- Sometimes MIB designers have good reasons for making a a group or
object "totally optional".  Consider, for instance, the
etherCollisionTableGroup in the EtherLike-MIB (RFC 2665), which is a
"collection of objects providing a histogram of packets successfully
transmitted after experiencing exactly N collisions."  This group is
recommended for network interfaces which operate half-duplex mode,
but implementation is optional because not all NICs have the
requisite underlying hardware support.  Similarly, the ETHER-WIS MIB
defines optional objects to access some useful testing features that
are optional in the IEEE 802.3ae standard.  In both cases is it
useful to have a standardized means to access the features on
systems that have the necessary hardware support, but it since
hardware support is not universally available it is not reasonable
to make support for the features mandatory.

On Thu, 29 May 2003, David T. Perkins wrote (in an off-line message):
> I think it is wrong to have totally optional objects and/or
> notifications in a standards track MIB module. 

In most cases I think that you are right, but I think there are
sometimes valid reasons for them.  I hope that the examples
given above are at least somewhat convincing.

> I understand that a module might have deprecated or obsolete
> items, and one probably doesn't want them in the current
> module compliance specification(s). But at some time, those
> objects and/or notifications had to be in a compliance.
> 
> So, would you explain what is going on.

That's generally true for modules that started out in life as SMIv2
modules.  But some of our more important MIB modules started out as
SMIv1 MIB modules, which did not have compliance statements, and
were later converted to SMIv2.  Many if not most retired a number of
objects at the time of the conversion process.  It would have been
useless make-work to write compliance statements covering the
obsolete requirements for the original version of the MIB module,
and the new compliance statements had no need for the retired
objects, so the groups containing them were simply left
unreferenced.  See snmpObsoleteGroup in the SNMPv2-MIB (RFC 3418)
and ifOldObjectsGroup in the IF-MIB (RFC 2863 ... although in
practice I think the ifOldObjectsGroup should have been mandatory
... Mike McFaden can tell you why).

//cmh