Subject: [ifmib] RE: FWD: Restart ifmib WG?

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 8 Oct 2002 00:17:08 +0200

Mike, were you guys not working on some MIB (I forget which one
it is) that needs ifmib to go to full std? So I would try very very
hard to get current mib to advance. If more work/changes is/are needed
then I'd prefer to do it in such a way that current MIB can advance.
That is of course assuming that we do not find any fatal flaws.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: maandag 7 oktober 2002 18:56
> To: [email-masked]
> Subject: Re: FWD: Restart ifmib WG?
> 
> 
> [ Followups to [email-masked] please ]
> 
> At 01:36 PM 10/2/2002 -0400, Thomas Narten wrote:
> [ ... ]
> > The ifmib WG still exists on paper, but hasn't been active for some
> > time.
> > 
> > There are still (IMO) some important work items that would 
> be good to
> > get done. For example:
> > 
> >  - advance IF-MIB to full std
> >  - advance inverted stack table mib to DS
> > 
> > There might be some more possible items, but the above ones are
> > critical in the sense that there are other documents that can't
> > advance until the above takes place.
> [ ... ]
> > Are there other work items that should be considered?
> 
> On Thu, 3 Oct 2002, Andy Bierman replied:
> > bug fixes:
> > 
> >  - ifTableLastChange should be TimeStamp not TimeTicks
> >  - ifLastChange should be TimeStamp not TimeTicks
> >  - ifStackLastChange should be TimeStamp not TimeTicks
> 
> OK
> 
> > optional enhancements:
> > 
> >  - ifMtu needs a read-write version
> > 
> > the following objects may be available in a different MIB
> > for some media types:
> > 
> >  - ifSpeed needs a read-write version
> >  - ifHighSpeed needs a read-write version
> 
> If you add these new objects to the IF-MIB then it will have
> to recycle at proposed.  That would prevent any MIB modules
> that depend on the IF-MIB in a normative way -- and there
> are plenty of those -- from advancing past proposed standard.
> It might, therefore, be better to put these things into a
> supplemental IF MIB module.
> 
> 
> On Mon, 7 Oct 2002, Romascanu, Dan (Dan) wrote:
> > Hmmm. What happens now with those MIBs who already defined
> > their own objects, like the MAU MIB? It is very nice to fix
> > this problem now, in the 21st century, but we create a
> > compatibility problem, or at least a set of questions that
> > need to be asked. (will ifMauSpeed be deprecated, if not which
> > one takes precedence when their values are not consistent, etc.)
> 
> If the "extras" are defined in a supplemental IF MIB module,
> then one way to resolve these questions might be to require
> that applicability of the objects in the supplemental IF MIB be
> spelled out by each media-specific MIB module, in analogy with
> the requirements in Section 4 of RFC 2863.  The default, in the
> absence of any guidance in the media-specific MIB module, would
> be that the objects do not apply.  That would leave the meaning
> of existing media-specific MIBs that provide their own objects
> unchanged.
> 
> Mike
> 
> 
_______________________________________________
ifmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ifmib

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 8 Oct 2002 01:44:21 -0700 (PDT)

> That is of course assuming that we do not find any fatal flaws.

I don't think anyone is likely to quarrel with this point -- Andy
Bierman has already agreed that we should put any new IF-MIB extensions
into a separate supplemental MIB module.

But to answer your question:  one example of a MIB module that depends
on IF-MIB which we are trying to advance is the SONET-MIB (the AToMMIB
WG is trying to advance it to Draft Standard).  Like all media-specific
MIB modules, it normatively references the IF-MIB (by definition, since
it is a media-speciic extension thereof) and so could not be advanced
if IF-MIB recycles back to Proposed Standard.

Just for reference, I ran some grep tools on the MIB modules included
in the libsmi-0.4 distribution and it seems that the following ones
depend in the IF-MIB in a normative way, typically by importing
ifIndex, InterfaceIndex, or InterfaceIndexOrZero.  Note that this
excludes all SMIv1 MIB modules, MIB modules that import ifIndex from
RFC1213-MIB, and (to the extent I'm aware if it) MIB modules that won't
be advanced in any case because they are slated to be replaced by work
in progress.

ACCOUNTING-CONTROL-MIB
ADSL-LINE-MIB
ATM-ACCOUNTING-INFORMATION-MIB
ATM-MIB
CHARACTER-MIB
CIRCUIT-IF-MIB
DIAL-CONTROL-MIB
DIFFSERV-MIB
DISMAN-PING-MIB
DISMAN-TRACEROUTE-MIB
DLSW-MIB
DOCS-BPI-MIB
DOCS-CABLE-DEVICE-MIB
DOCS-IF-MIB
DOT12-IF-MIB
DS0-MIB
DS0BUNDLE-MIB
DS1-MIB
DS3-MIB
ENTITY-MIB
EtherLike-MIB
FLOW-METER-MIB
FR-ATM-PVC-SERVICE-IWF-MIB
FR-MFR-MIB
FRAME-RELAY-DTE-MIB
FRNETSERV-MIB
FRSLD-MIB
GSMP-MIB
HDSL2-SHDSL-LINE-MIB
HOST-RESOURCES-MIB
IGMP-STD-MIB
INTEGRATED-SERVICES-GUARANTEED-MIB
INTEGRATED-SERVICES-MIB
INTERFACETOPN-MIB
IPATM-IPMC-MIB
IPMROUTE-STD-MIB
IPOA-MIB
ISDN-MIB
MAU-MIB
NHRP-MIB
PARALLEL-MIB
PIM-MIB
RS-232-MIB
RSVP-MIB
RTP-MIB
SMON-MIB
SONET-MIB
SNMP-REPEATER-MIB
TUNNEL-MIB
VRRP-MIB

That's quite a long list!

Mike