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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Looks good to me.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zondag 16 februari 2003 2:11
> To: mibs@ops.ietf.org
> Subject: RE: mentioning companion MIB modules in compliance statements
> (WAS: section 3.2 of draft-ietf-ops-mib-review-guidelines-00.txt)
> 
> 
> 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
> 
>