[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: mentioning companion MIB modules in compliance statements (WAS: section 3.2 of draft-ietf-ops-mib-review-guidelines-00.txt)
- To: "C. M. Heard" <heard@pobox.com>, 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)
- From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Date: Sun, 16 Feb 2003 11:57:57 +0100
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
>
>