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

 Hi,

I have opened issues for some of the items John raised that may
require discussion.
My comments inline reflect the RT Ticket Numbers for opened issues.
I did not open tickets for the editorial tweaks.

David Harrington
[email protected]
co-chair, IETF Bridge WG
 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Juergen 
> Schoenwaelder

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

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

Makes sense to me.
------------------------------------------
RT Ticket#758:
> 
> > 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.

We are not changing this document to be up-to-date with the most
recent IEEE documents. Such an update can be done by the IEEE 802.1
WG.
Changing the BridgeID semantics might alter the semantics of a number
of objects and require that we deprecate and redefine such objects.
We should not change BridgeId if it changes the semantics of any
objects in the MIB module.

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

------------------------------------------
RT Ticket#760 (and 669):
>  
> > 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.
>  
------------------------------------------
RT Ticket#761:

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

Keep in mind we are not trying to update this document to the current
IEEE documents, but simply to update the original 1493 MIB module.
We have added this object (a decision I sorely regret now) but any
changes we make now should not impact the semantics of the original
objects or require any other updates to the document, if possible.

John can you propose some text for the description clause?

------------------------------------------
RT Ticket#763:
> 
> > 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.

As co-chair, I will consider this issue closed if there are no
objections.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>