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

Re: Guidelines Document and Optional Groups



On Thu, 29 May 2003, C. M. Heard wrote:
> On Wed, 28 May 2003, Sharon Chisholm wrote:
[ ... ]
> > 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.

Following up on my own post:  while researching a different question
I noticed the following warning in the SNMPv2-MIB (RFC 3418):

 This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)
 has been processed to get the following results:
 smilint -m -s -l 6 -i integer-misuse SNMPv2-MIB

 /usr/local/share/mibs/ietf/SNMPv2-MIB:638: [5] {group-unref}
 warning: current group `snmpNotificationGroup' is not referenced
 in this module

In other words, snmpNotificationGroup is unconditionally optional
with respect to all compliance statements, including the current
one, snmpBasicComplianceRev2.  However, this appears to be
erroneous:  snmpNotificationGroup contains the accessible-for-notify
objects snmpTrapOID and snmpTrapEnterprise and is required for all
notification generators -- or so its DESCRIPTION says -- and
snmpBasicComplianceRev2 makes snmpBasicNotificationsGroup mandatory
and snmpWarmStartNotificationGroup conditionally mandatory.  On this
basis it seems to me that snmpBasicComplianceRev2 should have made
snmpNotificationGroup mandatory, too.(*)  So, yes, accidental
omission of groups from compliance statements had been a problem
historically.

So, I think that MIB reviewers SHOULD be suspicious of unreferenced
OBJECT-GROUPs and NOTIFICATION-GROUPs and SHOULD meticulously check
to make sure that such omission, when it occurs, is not accidental.
And I think it is justified to RECOMMEND to MIB module authors to
explicitly mention all _appropriate_ groups in a compliance
statement, even groups that are optional.

Mike

(*) Actually, the situation is not quite this simple.  Only
snmpTrapOID is needed by all notification generators;
snmpTrapEnterprise is only needed for proxies.  Probably each object
should have been in a separate group, with snmpTrapOIDGroup
mandatory in the SNMPv2-MIB's compliance statement and
snmpTrapEnterpriseGroup mandatory in (a replacement for) the
snmpProxyTrapForwardCompliance in the coex doc's SNMP-COMMUNITY-MIB.
But I fear that I am opening an unwelcome can of worms :-(