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

Mike, 

If you provide us with a list of necessary changes, we can discuss
them and make them part of the AD review process.

We are definitely looking to eliminate nice-to-have changes and
proposed mib review requirements that are not currently included in
the mib-review-guidelines-03. 

[soapbox]
Working against constantly moving targets is one major reason why
these documents have already taken three years. If it wasn't defined
as a requirement when we started WGLC, I don't want to hear about it
now.
[end soapbox]

David Harrington
[email protected]
co-chair, IETF Bridge WG

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of C. M. Heard
> Sent: Tuesday, January 25, 2005 12:50 PM
> To: Bridge-Mib (E-mail)
> Subject: Re: [Bridge-mib] 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
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>