RE: granularity of object re-use (was: section 3.2 ofdraft-ietf-ops-mib-review-guidelines-00.txt)

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

>>>>> On Sunday, February 09, 2003 C. M. Heard wrote:
C> It is not legal for module A to define a group of objects
C> from module B.  Conformance groups MUST be defined in the
C> same module as the objects or notifications that they
C> contain.  See Sections 3.1 and 4.1 of RFC 2580.  So I
C> think there are really only three possibilities:
C> 
C> - a compliance statement in module B may cite a group
C> from module A in a MANDATORY-GROUPS clause;
C> 
C> - a compliance statement in module B may cite a group
C> from module A in a GROUP clause;
C> 
C> - a compliance statement in module B may state in its
C> DESCRIPTION clause that module A is a prerequisite
C> (and may optionally mention a specific compliance
C> statement from module A that is required).

>>>>> On Sun, 9 Feb 2003, Romascanu, Dan (Dan) replied:
Dan> This is actually bothering me a little. It looks like we have
Dan> some kind of granularity problem in re-using objects from an
Dan> existing MIB module. Does this mean that if I need to re-use
Dan> some objects from module A in module B, I have no other choice
Dan> but to take the full group, as defined in the compliance
Dan> statements of module A? What if I need just a few, or maybe
Dan> just one object from module A, and there is no group in the
Dan> compliance statements restricted to such a granularity?

Even if no set of groups in module A has exactly the objects that
you need to re-use in module B, you can still express your
requirements in a compliance statement in module B.  The way to
do so is to mention some set of groups in module A than includes
all the objects that you need, and then mention all the objects
that you don't need in OBJECT clauses that have a MIN-ACCESS of
not-accessible.  Of course, if there are a lot if excluded objects
then module B's compliance statement won't be very easy to read.

Dan> (see the recent proposal by Andy Bierman about a new object to
Dan> clarify TimeFilter TC behavior, and the subsequent thread about
Dan> this object being part of probeConfig group).

My understanding is that the proposals were either to make a new
group with timeFilterMode as its sole member, or else to define a
new group probeConfigurationGroupRev1 that contains timeFilterMode
plus the current members of probeConfigurationGroup.   If there's a
significant chance that external MIB modules will want to re-use
timeFilterMode without having the other stuff, then putting it into
a group all by itself might be the best way to go (cf. IF-MIB's
ifCounterDiscontinuityTime, which lives by itself in
ifCounterDiscontinuityGroup).

//cmh