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

On Fri, Dec 17, 2004 at 06:43:33PM -0800, John Flick wrote:
 
> I had only a few comments on this draft:

Thanks very much for the comments. Please see my response to your
comments below. Note that there are some questions where I like to
have more input.

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

fixed
 
> 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).

fixed
 
> 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
 
> 4. Section 3.3 seems unnecessary - we shouldn't have to describe
>    what a textual convention is.

well, ok - removed

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

removed TC explanation and moved semantics into DESCRIPTION clauses

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

I have no clue - someone familiar with 802.1t must provide input or
the description stays as it is now.
 
> 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?
 
> 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.

I think it does not make sence to have a current compliance statement
which refers to a deprecated object. I do like the proposal to rename
the compliance statements and I do agree that the bridgeCompliance1493
should be current given the actual deployment of this module. So I
tend to make dot1dStpPortPathCost current and to add language similar
to the ifSpeed/ifHighSpeed objects 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.

Since I do not have 802.1t, can you please draft some text to put 
in place?

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

I have added UNITS "bytes" and I have closed this issue.

/js

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