[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 :-(