Re: Review comments ondraft-ietf-bridge-bridgemib-smiv2-07.txt

On Wed, Dec 29, 2004 at 12:24:41PM -0500, David B Harrington wrote:
 
> > > 3. Section 3.1.3: Should we have an Informative reference to the
> > >    SR Bridge MIB RFC here (RFC 1513)?  It did not exist yet when
> > >    RFC 1493 was written, but it does now, so we could get rid
> > >    of the vague "a separate document" wording.
> > 
> > makes sense - done
> 
> This should be RFC 1525, not RFC 1513.

Fixed.
  
> ------------------------------------------
> RT Ticket#757:
> > 
> > > 5. The forward reference in the MODULE-IDENTITY {dot1dBridge 8}
> > >    is known to cause problems with some broken MIB compilers.
> > >    It is a problem with the MIB compilers, but customers typically
> > >    don't care - they complain to the equipment vendor that
> > >    provided them with the copy of the MIB module.  We had the
> > >    same problem with the MAU-MIB.  We would save ourselves,
> > >    vendors, and customers alot of grief by registering the
> > >    MODULE-IDENTITY directly below mib-2.
> > 
> > I have replaced { dot1dBridge 8 } with { mib-2 dot1dBridge(17) 8 }.
> > Does that address you concern? Note that we have more module 
> > identities
> > below dot1dBridge so using { dot1dBridge 8 } is at least consistent
> > with the other registrations. Let me know if you are happy with
> > { mib-2 dot1dBridge(17) 8 } or have other proposals.
> 
> I have concerns that this change will impact OTHER broken MIB
> compilers. I suspect many compilers that broke as the result of the
> forward reference in SMIv2 will have already been fixed for this
> problem. I believe some compilers may have a problem with the new
> proposed syntax, and don't want to make this a moving target. Let's
> keep the forward reference approach that is legal SMIv2 and common in
> other IETF standard MIB modules. If a MIB compiler still breaks as the
> result of the (legal) forward reference, then the broken compiler
> should be fixed.

I have reverted back to the original format. But see below.
 
> ------------------------------------------
> RT Ticket#759:
> >  
> > > 8. On page 12 where we list registrations defined in other
> modules,
> > >    should we also list rstpMIB?
> > 
> > I have added a comment. However, I am not sure what the status and
> > future of draft-ietf-bridge-rstpmib-05.txt is. Dave, can you tell
> > me what to do here?
> 
> I personally find it bad practice to predefine subtrees that are not
> actually used within a document, and I discourage the practice.
> I object to adding this registration here.

We can't change the pBridgeMIB and qBridgeMIB registration anymore.
We can of course move the bridgeMIB MODULE-IDENTITY registration to 
{ mib-2 xxx } (which also addresses issue #757) and we can remove the 
comments that refer to the srMIB, dot1dPortPair, rstpMIB. We probably
want to add a note saying the usage of the dot1dBridge subtree by 
other MIB modules is strongly discouraged. Any objections against
this approach?
 
/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany