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

Hi,

Correction:
I see I made a mistake in my proposed changes to -09- for section
3.2.2 
My proposal should have read
> 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 (

ifPhysAddress, ifDescr, ifType, and ifLastChange 

), 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.

David Harrington
[email protected]


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of David B Harrington
> Sent: Thursday, January 27, 2005 8:34 PM
> To: [email protected]; 'Wijnen, Bert (Bert)'
> Cc: 'C. M. Heard'; 'Bridge-Mib (E-mail)'
> Subject: RE: [Bridge-mib] Re:
Draft-iet-bridge-bridgemib-smiv2-09.txt
> 
> 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
> > 
> 
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>