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

Hi,

Comments inline.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email protected]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, December 29, 2004 7:40 PM
> To: David B Harrington
> Cc: 'John Flick'; 'Congdon, Paul T'; [email protected]
> Subject: Re: [Bridge-mib] Review comments 
> ondraft-ietf-bridge-bridgemib-smiv2-07.txt
> 
> > ------------------------------------------
> > 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.

Thanks.

>  
> > ------------------------------------------
> > 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?

For the SMI experts amongst us, can we legally register the
MODULE-IDENTITY in the following way?

dot1dBridge MODULE-IDENTITY
	...
	::= { mib-2 17 }

RFC1493 registered dot1dbridge using "dot1dbridge OBJECT IDENTIFIER
::= { mib-2 17 }"
Juergen pointed out that the SMIv2-to-SMIv1 translation of a
MODULE-IDENTITY is simply an OID, so this might be legal.

If we can do this, it would move the mib up under mib-2, and eliminate
the forward reference (issue #757). 
It would also place the object and notification subtrees under the
dot1dBridge MODULE-IDENTITY, approximating the recommended practices
from draft-ietf-ops-mib-review-guidelines Suggested OID layout. 

We would want to remove the comment showing the assignment of
bridgeMIB to { dot1dBridge 8 }
And change dot1dConformance from { bridgeMIB 1 } to { dot1dBridge ##
}, where ## is an unused subtree, possibly { dot1dBridge 8 }

It is unfortunate that the MODULE-IDENTITY dot1dBridge would not
mirror the BRIDGE-MIB name, and pBridge and qBridge MODULE-IDENTITIES
are under dot1dBridge MODULE-IDENTITY, but we cannot change that now
without great pain.

Dbh

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