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

First, apologies to everyone for losing my cool.  Now back to
technical stuff ...

On Tue, 25 Jan 2005, David B Harrington wrote:
> > -----Original Message-----
> > From: [email protected] 
> > 
> > (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.

In the interest of not creating more problems than are solved, I'm
going to make some explicit suggestions for the fixes.  These are
just suggestions;  the editor, the chair, and AD are free to do with
them as they see fit.

First, note that Section 3.1 refers to certain objects in the
SNMPv2-MIB and the IF-MIB.  I think that this is OK since these
objects also exist in MIB-II.  So no change is suggested there.

Second, for Sections 3.2, 3.2.1, and 3.2.2, the following
replacement text, referring both to RFC 1213 and its successors,
is suggested:

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.  In
   particular, it is assumed that a bridge implementing the BRIDGE-MIB
   module will also implement (at least) the 'system' subtree of MIB-II
   [RFC1213] or equivalent objects from the SNMPv2-MIB [RFC3418] and
   the 'interfaces' subtree of MIB-II or equivalent objects from the
   IF-MIB [RFC2863].  Systems that can claim compliance with the
   snmpBasicComplianceRev2 statement of the SNMPv2-MIB and with the
   ifCompliance3 statement of the IF-MIB will satisfy this assumption.

3.2.1  Relationship to the System Group

   The 'system' subtree of MIB-II [RFC21213], which is a subset of the
   systemGroup in the SNMPv2-MIB [RFC3418], is defined as being
   mandatory for all systems.  Thus, those objects apply to the entity
   as a whole irrespective of whether the entity's sole functionality is
   bridging, or whether bridging is only a subset of the entity's
   functionality.

3.2.2  Relationship to the Interfaces Group

   The 'interfaces' subtree of MIB-II [RFC1213], which is a subset of
   the IF-MIB [RFC2863], is defined as being mandatory for all systems
   and contains information on an entity's interfaces, where each
   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.

Third, add RFC 1213 to the normative references list.  This should
not be a problem since it is an Internet Standard.  We made a decision
many years ago NOT so send this MIB module (and the SMIv1 documents)
to Historic precisely because so many documents refer to it.

Finally, retain RFC 3418 and RFC 2863 as normative references.  The
latter is needed because of the IMPORT of InterfaceIndex, and both
are listed as alternatives to RFC 1213 in the prerequisites section.

> > (b) undo the following changes (or get an AD waiver from the MIB
> > review guidelines):
> > 
> > BRIDGE-MIB.mi2:194 [5] {named-number-changed} warning: named number
> > `transparent-only' changed to `transparentOnly' at type used in
> > `dot1dBaseType'
> > BRIDGE-MIB.mi2:194 [5] {named-number-changed} warning: named number
> > `sourceroute-only' changed to `sourcerouteOnly' at type used in in
> > `dot1dBaseType'
> >  
> I agree. The changes should be undone for backwards compatibility.
> 
> Unless I hear from others who object to this, I will forward these
> recommendations to the ADs.

Sounds good.

Thanks,

Mike