Subject: RE: [Bridge-mib] Re: Draft-iet-bridge-bridgemib-smiv2-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 26 Jan 2005 01:16:45 +0100

> Juergen Schoenwaelder wrote:
> Sent: Wednesday, January 26, 2005 00:12
> To: David B Harrington
> Cc: 'C. M. Heard'; 'Bridge-Mib (E-mail)'
> Subject: Re: [Bridge-mib] Re: Draft-iet-bridge-bridgemib-smiv2-09.txt
> 
> 
> On Tue, Jan 25, 2005 at 04:41:35PM -0500, David B Harrington wrote:
> 
> > > (a) the text in Sections 3.2 was adapted from the original 1493 but
> > > now points to RFCs 3418 and 2863.  As a result it is now inaccurate.
> > > Details were spelled out in previous e-mail responses to Juergen.
> > > If you wish to leave the prerequisites exactly as they were in 1493
> > > then you should probably revert to referring to RFC 1213.  If you
> > > want to leave the references to 3418 and 2863 then please do
> > > something to fix the inaccuracies, particularly in 3.2.2.
> > > 
> > After reviewing the discussion more closely, I agree. 
> > This text should refer to RFC1213 for backwards compatibility.
> > 
> > There is no MODULE-COMPLIANCE in RFC3418 that appropriately reflects
> > RFC1213 compliance.
> > The same appears to be true for RFC2863.
> 
> I personally hate to see this SMIv2 proposed standard version of the
> BRIDGE-MIB depend on RFC1213. So if the current text is not good
> enough, I would rather prefer to work through the details to come
> up with text that says what we believe RFC 1493 did say, but referring 
> to the current MIB modules we have. In the worst case, we list all 
> the IF-MIB/SNMPv2-MIB objects that we believe were meant when RFC 
> 1493 was written. We may add a note that the IF-MIB/SNMPv2-MIB
> have evolved and that compliance to the current IF-MIB/SNMPv2-MIB may 
> require the implementation of additional objects but doing so is not 
> mandated by the BRIDGE-MIB itself.
> 

I agree with Juergen and would prefer that we try to do so.
At some point it would be good to get rid of normative 
dependecies on RFC1213. I think we have an opportunity to 
help work towards that goal here, and we can do so relatively
easy in this case as Juergen proposes.

Bert
> /js

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jan 2005 22:04:28 +0100

> easy in this case as Juergen proposes.

So here is an attempt to put things into concrete words. Please let
me know how to improve this and whether this text matches your
understanding of the situation.

3.2  Relationship to Other MIB Modules

   As described above, some IEEE 802.1D management objects have not
   been included in this MIB module because they overlap with objects
   in other MIB modules applicable to a bridge implementing this MIB
   module.

3.2.1  Relationship to the SNMPv2-MIB

   The SNMPv2-MIB [RFC3418] defines objects that are generally
   applicable to managed devices. These objects apply to the device as
   a whole irrespective of whether the device's sole functionality is
   bridging, or whether bridging is only a subset of the device's
   functionality. Implementation of the BRIDGE-MIB module requires
   that at least the objects sysDescr, sysObjectID, sysUpTime,
   sysContact, sysName, sysLocation, and sysServices of the SNMPv2-MIB
   [RFC3418] are implemented.

   Note that compliance to the current SNMPv2-MIB module requires
   additional objects and notifications to be implemented as specified
   in RFC 3418 [RFC3418].

3.2.2  Relationship to the IF-MIB

   The IF-MIB [RFC2863] defines managed objects used for managing
   network interface. A network interface is thought of as being
   attached to a `subnetwork'. (Note that this term is not to be
   confused with `subnet' which refers to an addressing partitioning
   scheme used in the Internet suite of protocols.)  The term
   'segment' is used in this memo to refer to such a subnetwork,
   whether it be an Ethernet segment, a 'ring', a WAN link, or even an
   X.25 virtual circuit.

   Implementation of the BRIDGE-MIB module requires that the following
   objects of the IF-MIB module are implemented: ifNumber, ifIndex,
   ifDescr, ifType, ifMtu, ifSpeed, ifPhysAddress, ifAdminStatus,
   ifOperStatus, ifLastChange, ifInOctets, ifInUcastPkts,
   ifInNUcastPkts, ifInDiscards, ifInErrors, ifInUnknownProtos,
   ifOutOctets, ifOutUcastPkts, ifOutNUcastPkts, ifOutDiscards,
   ifOutErrors, ifOutQLen, ifSpecific.

   Note that compliance to the current IF-MIB module requires
   additional objects and notifications to be implemented as 
   specified in RFC 2863 [RFC2863].

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany