Review comments on draft-ietf-bridge-bridgemib-smiv2-07.txt

Hi,

I had only a few comments on this draft:

1. In Section 3, bullet 4, says: "Limit the total of objects.", which
    should be "Limit the total number of objects."

2. Section 3.1: the term "group" has a more specific meaning in SMIv2
    than it did in SMIv1.  It seems like most MIB doctor reviews have
    been discouraging the use of the term "group" for meanings other
    than "OBJECT-GROUP".  Perhaps "subtree" would be better here
    (and a few other places in the document).

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.

4. Section 3.3 seems unnecessary - we shouldn't have to describe
    what a textual convention is.

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.

6. The big comment blocks around the T-Cs seem unnecessary.  Again,
    it should not be necessary to describe what a textual convention
    is here.  Text specific to the textual convention should be in
    the DESCRIPTION clause, not in a comment.

7. Is the BridgeId description still correct, or did 802.1t change
    this?

8. On page 12 where we list registrations defined in other modules,
    should we also list rstpMIB?

9. I would suggest changing bridgeCompliance and bridgeCompliance2
    to bridgeCompliance1493 and bridgeCompliance (or some better
    name for the new compliance) and making both current, to avoid
    deprecating support for 1493-compliant bridges.  Not sure if
    we should be deprecating dot1dStpPortPathCost...I can see
    valid arguments either way.  Reporting 65535, and stating
    that PortCost32 should be examined for the real path cost when
    PathCost reports 65535, would be compatible with what we did
    for ifSpeed/ifHighSpeed in the IF-MIB.

10. Open issues 1: I think this has been discussed on the mailing
     list - PortCost32 is necessitated by higher speed links, not
     RSTP.  Can we steal some text from 802.1t Table 8.5 and the
     following Note 2 to explain this issue.  Place it in the
     Overview text, or better yet, in the Description clauses of
     PortCost and PortCost32.

11. Open issues 3: We return bytes here.  The comment above the
     object about how it would have been nice if we could have used
     ifMtu seems to imply it should be bytes.  I agree we should
     say so exlicitly.

Hope this helps,
John