RE: Re: Draft-iet-bridge-bridgemib-smiv2-09.txt

"David B Harrington" <[email protected]> Thu, 27 Jan 2005 20:34:14 -0500
Newsgroups gmane.ietf.bridge
Message-ID <[email protected]>
Hi,

If, for accuracy reasons, we're going to list required objects from
other mib modules, then we need to be accurate.

As detailed in 3.1, the bridge mib document has referential dependence
on sysDescr and sysUpTime to identify management objects which
substitute for 802.1D management objects that are NOT included in this
mib module. No IMPORTS or DESCRIPTION clauses indicate any semantic
dependencies on any 'system' objects. The BRIDGE-MIB has no dependence
on sysObjectID, sysName, sysContact, sysLocation or sysServices - and
the BRIDGE-MIB doesn't have a dependency on sysDescr or sysUpTime,
only a documentation dependency.

The bridge mib document has referential dependence on ifPhysAddress,
ifDescr, ifType, and ifLastChange to identify management objects which
substitute for 802.1D management objects that are NOT included in this
mib module. It has an explicit dependence only on InterfaceIndex, as
indicated in the IMPORTS clause. It mentions ifIndex in a DESCRIPTION
clause (which explains what InterfaceIndex means), and it mentions
ifMtu in a comment. It mentions interface number, but not ifNumber
directly; it probably should mention ifNumber specifically. The
BRIDGE-MIB module has no dependencies on ifNumber, ifDescr, ifType,
ifSpeed, ifPhysAddress, ifAdminStatus, ifOperStatus, ifLastChange,
ifInOctets, ifInUcastPkts, ifInNUcastPkts, ifInDiscards, ifInErrors,
ifInUnknownProtos, ifOutOctets, ifOutUcastPkts, ifOutNUcastPkts,
ifOutDiscards, ifOutErrors, ifOutQLen, or ifSpecific.

--- Suggested changes to -09-:
The second sentence in 3.2 should be eliminated (as Juergen's proposed
text has done).

section 3.2.1 text should be eliminated and should be replaced by text
that identifies the system objects which substitute for 802.1D
management objects that are NOT included in this mib module (sysDescr
and sysUpTime), thus duplicating section 3.1. 

section 3.2.2 should be trimmed to remove "is defined as being
mandatory for all systems and", and should add text to identify IF-MIB
management objects which substitute for 802.1D management objects that
are NOT included in the mib module (InterfaceIndex and ifIndex), thus
duplicating section 3.1. The comment about ifMtu might better be moved
here as well, rather than having it embedded in the module as a
comment.
 
--- comments on Juergen's proposed text:
Section 3.2.1: I believe Juergen's proposed text that says
'Implementation of the BRIDGE-MIB module requires
that at least ... are implemented' is inaccurate; this mib module can
be implemented without those objects if desired, but you will miss
some of the objects recommended by 802.1-D, and the functionality they
provide (but then even if you implement this mib module plus those
objects, you'll still be missing some objects listed in 802.1-D and
the functionality they provide, as described in 3.1).

Section 3.2.2: I believe Juergen's proposed ext that says
'Implementation of the BRIDGE-MIB module requires that the following
objects of the IF-MIB module are implemented' is inaccurate in its
list, as I describe above.


David Harrington
[email protected]
  

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email protected]] 
> Sent: Thursday, January 27, 2005 4:04 PM
> To: Wijnen, Bert (Bert)
> Cc: David B Harrington; 'C. M. Heard'; 'Bridge-Mib (E-mail)'
> Subject: Re: [Bridge-mib] Re:
Draft-iet-bridge-bridgemib-smiv2-09.txt
> 
> On Wed, Jan 26, 2005 at 01:16:45AM +0100, Wijnen, Bert (Bert) wrote:
> 
> > 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.
> 
> 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
>