RE: mentioning companion MIB modules in compliance statements (WAS:section 3.2 of draft-ietf-ops-mib-review-guidelines-00.txt)

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

On Sat, 8 Feb 2003, C. M. Heard wrote:
> On Sat, 8 Feb 2003, Wijnen, Bert (Bert) wrote:
> > > On Sat, 8 Feb 2003, C. M. Heard wrote:
> > > On Fri, 7 Feb 2003, Harrie Hazewinkel wrote:
> > > > > 3.2.  Narrative Sections
> > > > >
> > > > >  If the MIB modules defined by the specification are always
> > > > >  implemented in conjunction with other MIB modules, then that
> > > > >  fact MUST be noted in the overview section, as MUST any special
> > > > >  interpretations of objects in other MIB modules.  For instance,
> > > > >  so-called media-specific MIB modules are always implemented in
> > > > >  conjunction with the IF-MIB [RFC2863] and are required to document
> > > > >  how certain objects in the IF-MIB are used.  In addition, media-
> > > > >  specific MIB modules that rely on the ifStackTable [RFC2863] and
> > > > >  the ifInvStackTable [RFC2864] to maintain information regarding
> > > > >  configuration and multiplexing of interface sublayers must contain
> > > > >  a description of the layering model.
> > > > 
> > > > Also the definition section should express this in its compliance
> > > > statements. (There is later a lot of info for this compliance
> > > > statements.)
> > > 
> > > Not necessarily.  In particular, not if it means I need to
> > > duplicate an entire compliance statement from one MIB module
> > > into another.
> > 
> > I agree, that if say MIB module A requires that the complete
> > compliance of some other MIB module B, then just staing soo in
> > the DESCRIPTION clause of the complaince statement in
> > MIB Module A is the best way to go.
> > 
> > [But] in cases where MIB module A only requires a piece of some
> > other MIB module B (ideally that would be at the level of a
> > OBJECT-GROUP already defined in MIB module B, but if not, then
> > Module A may want to define a new group of objects out of
> > MIB module B), then it seems best to me if Module A indeed
> > includes that formally in a module compliance statement.
> > I think RFC3289 is another good example for this, where it
> > required the ifCounterDiscontinuityGroup of IF-MIB (so not
> > the complete IF-MIB) and specified it as follows:
> > 
> >     MODULE IF-MIB -- The interfaces MIB, RFC2863
> >     MANDATORY-GROUPS {
> >        ifCounterDiscontinuityGroup
> >     }
> > 
> > I think such is REALLY GOOD practice. In fact I think
> > such is the proper way to do it.
> > 
> > Hope [this] explains my view of it.
> 
> Indeed, I agree with this principle, and especially with this
> particular example.
> 
> I'll draft some new text to cover these points and run it by
> everyone sometime next week.

OK, after thinking for a while about this I have decided that
the text in Section 3.2 is just fine as it stands;  any requirements
or recommendations on what compliance statements need to say about
companion modules properly belongs in Section 4.8, which is where
compliance statements are discussed.  Here is the text I came up
with;  it would go near then end of 4.8 (just before the endnote):

   In many cases a MIB module is always implemented in conjunction with
   one or more other MIB modules.  That fact is REQUIRED to be noted in
   the surrounding documentation (see Section 3.2 above), and it SHOULD
   also be noted in the relevant compliance statements as well.  In
   cases where a particular compliance statement in (say) MIB module A
   requires the complete implementation of some other MIB module B, then
   the RECOMMENDED approach is to include a statement to that effect in
   the DESCRIPTION clause of the compliance statement(s) in MIB module
   A.  It is also possible, however, that MIB module A might have
   requirements that are different from those that are expressed by any
   any compliance statement of module B -- for example, module A might
   not require any of the unconditionally mandatory object groups from
   module B but might require mandatory implementation of an object
   group from module B that is only conditionally mandatory with respect
   to the compliance statement(s) in module B.  In such cases the
   RECOMMENDED approach is for the compliance statement(s) in module A
   to formally specify requirements with respect to module B via
   appropriate MODULE, MANDATORY-GROUPS, GROUP, and OBJECT clauses.  An
   example is provided by the compliance statements in the DIFFSERV-MIB
   [RFC3289], which list the ifCounterDiscontinuityGroup from IF-MIB
   [RFC2863] as a mandatory group.  That group is not sufficient to
   satisfy any IF-MIB compliance statement, and it is conditionally
   mandatory in the IF-MIB's current compliance statement ifCompliance3.

Reactions?

//cmh