Hi Bill and Tom,
Reading MIBs and talking about conformance has to be done in the
context of 'prior art'. Long before SMIv2 gave us 'MODULE-COMPLIANCE',
'AGENT-CAPABILITIES', and 'OBJECT-GROUP' macros (ever seen an
'AGENT-CAPABILITIES' statement published by a well-implemented
intermediate system - they have a lot of content), there has
always been a common understanding of what conforming to a
'Group' meant:
To whit, doing every object after the ASN.1 comment 'ABC Group (...'
and before then next comment 'DEF Group'. Clean MIBs don't
lump several tables into one group, usually. There are LOTs
of tables in the single HR MIB 'Device' group, but their implementation
is all conditional on 'hrDeviceType' (ie, if you don't show your
CPUs, and HR MIB offers no guidance here, then you don't do the
subordinate 'hrProcessorTable').
But, while the Printer MIB (RFC 1759) lowers the bar for the HR
MIB from the HR MIB itself (by leaving out the System group,
which was kind of silly, considering how useful its objects
are and how few of them there are, by comparison with RFC 1759),
when RFC 1759 says 'HR MIB Device and Storage groups' it implicitly
hands off to the HR MIB itself for compliance details - there is
NO way that the objects in the 'hrDeviceTable' or the 'hrStorageTable'
themselves are anything other than MANDATORY - any other interpretation
is going to finally run afoul of competent MIB folks like
Deidre - the PWG may not have the mission in life of doing MIBs,
but the IETF and IESG have compelling reasons to get serious
about what compliance means - the debacle of the SNMPv2
Working Group earlier this year (and late last year) didn't
go unnoticed by the open systems management community.
Cheers,
- Ira McDonald (outside network mgmt consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434