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

Inline

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On
> Behalf Of C. M. Heard
> Sent: Wednesday, January 26, 2005 00:42
> To: Bridge-Mib (E-mail)
> Subject: RE: [Bridge-mib] Re: Draft-iet-bridge-bridgemib-smiv2-09.txt
> 
> 
> First, apologies to everyone for losing my cool.  Now back to
> technical stuff ...
> 
Mike ... thanks for your Review. 
You didn't know the context and so I think what you did was fine.
If everyone in the IETF always stayed as cool as you are, then 
we'd have much more technical fun!

more below

> 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.
> 
Although currently it would not be an issue to let this doc make
a normative ref to RFC1213, I prefer that we get rid of it.
I think that with the above text, it is defendable that the
normative refs are to 3418 and 2863 and that we keep 1213 as
an informative reference, don't you think so?

> 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.
> 
I can in fact live with either if the WG is OK. If we want to keep the
new labels, then we should add some text that we explicitly considered
the (incompatible) change and that we checked all IETF MIB documents
and that we did not see an uissue there and that we believe the
impact on vendor specific MIB modules (if any) will be very minimal.

Bert
> Sounds good.
> 
> Thanks,
> 
> Mike
>