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

On Tue, 25 Jan 2005, Juergen Schoenwaelder wrote:
> > > > 10.) Technical content -- the extent of my technical review was
> > > > to go over the output from smidiff.  I noticed a couple of things:
> > ...
> > > > (b) also, the following changes violate our 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'
> > > > 
> > > > See draft-ietf-ops-mib-review-guidelines-03.txt, section 4.9, first
> > > > bullet on p. 29.  [ ... ]
...
> > But as I said, I will not pick a fight about this.
> 
> I certainly do not want to discuss the merrit of these rules here. I
> can life either way. But it would be good if the conclusion how we
> deal with this case could be recorded so that we do things consistently
> the next time this pops up.

In that case I would ask that the original labels be reinstated, in
compliance with the MIB review guidelines, because I think that the
MIB review guidelines are correct as written.

> > > > (c) As a result of 9(d) above, I noticed that the compliance
> > > > statements do not spell out the prerequisites [ ... ]
...
> So from this, I conclude that we probably want to add the following 
> to the compliance statements:
> 
> 	Note that compliance with this MIB module requires
> 	compliance with the ifCompliance3 MODULE-COMPLIANCE 
> 	statement of the IF-MIB (RFC2863) and compliance with
> 	the snmpBasicComplianceRev2 MODULE-COMPLIANCE of the
> 	SNMPv2-MIB (RFC3418).
> 
> Section 3.2.1 would be changed to the following:
> 
> 	Implementations of the BRIDGE-MIB must comply with the
> 	snmpBasicComplianceRev2 MODULE-COMPLIANCE statement in 
> 	the SNMPv2-MIB [RFC2863].
> 
> Section 3.2.2 first paragraph would be changed to the following:
> 
> 	Implementations of the BRIDGE-MIB must comply with the
> 	ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB
> 	[RFC2863]. In the IF-MIB terminology, an 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.

Making compliance with snmpBasicComplianceRev2 raises the bar quite
a bit higher than necessary.  That compliance statement imposes a
requirement for SNMP instrumentation.  Maybe that's a good thing to
have, but it's not necessary to support the BRIDGE-MIB.  If suffices
to support the systemGroup.  But, if it is agreed to go that route,
I will have no quarrel.

> We may want to add after the first sentence (although this should
> be clear from reading the IF-MIB):
>
>       This includes mandatory support of the ifFixedLengthGroup,
>       the ifPacketGroup, and the ifCounterDiscontinuityGroup of
>       the IF-MIB [RFC2863], which are conditionally mandatory
>       in the ifCompliance3 statement.

Leave that out.  Redundant text runs the risk of being
contradictory, and this is such a case.  ifFixedLengthGroup and
ifPacketGroup are mutually exclusive in ifCompliance3.  Let RFC 2863
speak for itself.

The one other fix that I would suggest along with the above would be
the following new text for Sec. 3.2:

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 the SNMPv2-MIB [RFC3418] and the IF-MIB
   [RFC2863].

On Tue, 25 Jan 2005, David B Harrington wrote:
> Let me jump in as chair.
> 
> It is important to realize that we have already been through WGLC and
> submitted the document for advancement, and cannot make any changes to
> the document without "unsubmitting" it. We cannot publish a new
> revision for minor changes.
> 
> I asked for an independent MIB Doctor review to ensure that there is
> nothing **broken** in this document; given that it has been reviewed
> by three of four MIB Doctors already, I didn't think it very likely we
> missed anything, but an extra pair of eyes doesn't hurt, and reassures
> the IESG it has been independently reviewed.

In that case I will withdraw all of my merely "nice-to-have" comments,
and I can resubmit the remaining stuff as IETF Last Call comments.  That
would include the editorial stuff plus the two issues discussed above.

Mike