RE: section 3.2 of draft-ietf-ops-mib-review-guidelines-00.txt

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

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zaterdag 8 februari 2003 0:52
> To: mibs@ops.ietf.org
> Subject: Re: section 3.2 of 
> draft-ietf-ops-mib-review-guidelines-00.txt
> 
> 
> On Fri, 7 Feb 2003, Harrie Hazewinkel wrote:
> > I read the document and have a few comments.
> > '> ' indicates text from the draft itself (sorry it I cut/paste to 
> > much).
> 
> Thanks for your comments.  I will answer all of them in detail but
> there is one thing which needs a quick reply.
>  
Thanks from me too Harrie.
Other folk... pls review and comment too.
Even a "I like it" or "I hate it" is good feedback, although
in the latter case I would prefer to hear why as well.

> >  >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.  Consider the media-specific MIB modules that
> are all sparse-augments of the IF-MIB.  What you have asked
> for above would have every one of them duplicating a major
> part of the IF-MIB compliance statement.  That creates a big
> maintenance burden, which I think greatly offsets any benefits.
> In the media-specific MIB modules with which I am familiar the
> practice is simply to state in the narrative section that the
> IF-MIB is a required prerequisite.  They don't duplicate the
> compliance statements in the IF-MIB.  If I were reviewing a
> media-specific MIB module that did that, I would sat in my
> review comments that I though it was a bad idea.
> 
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.

> As a side note, I will agree that it would be nice if SMIv2
> provided some way for one compliance statement to formally
> say that some other compliance statement is a prerequisite.
> As it stands, the best you can do (short of copying compliance
> info) is to put such a statement in the DESCRIPTION clause
> associated with the MODULE-COMPLIANCE.  That, I think, would
> be good advice.
> 
Indeed.

> I wanted to get a quick answer on this topic because there are
> other folks asking for the same thing, and I feel quite strongly
> that there are many cases where it should not be done.
> 
Well, 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 thsi explains my view of it.

Bert
> Regards,
> 
> Mike Heard
> 
>