Hi David,
Here's the replacement text I promised.
On page 6, change this:
In a device supporting the 32-bit default Path Costs defined in IEEE
802.1t Table 8-5, the interpretation of objects in this group is
unchanged except for the following:
dot1dStpPortPathCost
Definition remains unchanged, but the permissible values are
extended to 1-200,000,000.
to this:
In a device supporting the 32-bit default Path Costs defined in IEEE
802.1t Table 8-5, the object dot1dStpPortPathCost32 [XXX] should be used
rather than the older object dot1dStpPortPathCost. The newer object
supports the expanded range of 1-200,000,000.
Note that there would need to be a reference to the latest BRIDGE-MIB
document (where I put [XXX]). But that document is not yet published as
an RFC. I guess this change depends on advancement of that document.
I had suggested changing the SYNTAX of dot1dStpPortProtocolMigration from
TruthValue to just an enumerated INTEGER. I looked more closely at the 802.1w
document, and this parameter is described there as a boolean value. The
description there is kind of odd, as it basically says you can set the value
to TRUE, but that when you do, it will be immediately set back to FALSE.
Anyway, I guess this is why TruthValue was used in the MIB. I could go either
way on this, but if other people think it makes sense to change the SYNTAX,
here's what I'd suggest:
dot1dStpPortProtocolMigration OBJECT-TYPE
SYNTAX INTEGER {
transmitRstpBpdus(1)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When operating in RSTP (version 2) mode, setting this
object forces this port to transmit RSTP BPDUs. Any
other operation on this object has no effect and it
always returns transmitRstpBpdus(2) when read."
REFERENCE
"IEEE 802.1w clause 14.8.2.4, 17.18.10, 17.26"
::= { dot1dStpExtPortEntry 1 }
For the DESCRIPTION of dot1dStpPortAdminEdgePort, I'd suggest:
DESCRIPTION
"The administrative value of the Edge Port parameter. A
value of TRUE(1) indicates that this port should be
assumed as an edge-port and a value of FALSE(2) indicates
that this port should be assumed as a non-edge-port.
Setting this object will also cause the corresponding
instance of dot1dStpPortOperEdgePort to change to the
same value. Note that even when this object's value
is true, the value of the corresponding instance of
dot1dStpPortOperEdgePort can be false if a BPDU has
been received."
and for dot1dStpPortOperEdgePort:
DESCRIPTION
"The operational value of the Edge Port parameter. The
object is initialized to the value of the corresponding
instance of dot1dStpPortAdminEdgePort. When the
corresponding instance of dot1dStpPortAdminEdgePort is
set, this object will be changed as well. This object
will also be changed to FALSE on reception of a BPDU."
-Dave
-----Original Message-----
From: Levi, David [SC100:323:EXCH]
Sent: Tuesday, April 20, 2004 9:23 AM
To: 'Harrington, David'; Wijnen, Bert (Bert)
Cc: Dan Romascanu (E-mail); Les Bell
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
Hi David,
I just forwarded my comments to the mailing list.
I could do some editing if necessary (there are only minor edits required). I'll write up some replacement text
to address my comments sometime today or tomorrow.
-Dave
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: Tuesday, April 20, 2004 8:32 AM
To: Wijnen, Bert (Bert); Levi, David [SC100:323:EXCH]
Cc: Dan Romascanu (E-mail); Les Bell
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
Oooh. I didn't look at the addresses and assumed it had been posted.
Yes, It should certainly be posted to the bridge mailing list to help stimulate discussion, and let the authors know what you've found.
Dave, can you post it directly? Thanks much for doing the review.
The editors of that document may not be able to make the changes; I'd rather keep you as a reviewer, but if it comes to it, could you help by editing the document? You could also make it much easier for the editors if you can propose the replacement/additional text to resolve your concerns.
Thanks,
dbh
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Tuesday, April 20, 2004 2:51 AM
To: David Levi; Harrington, David; Wijnen, Bert (Bert)
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
Would it not be good to post this to bridegmib wg mailing list?
I think it would
Thanks,
Bert
-----Original Message-----
From: David Levi [mailto:dlevi@nortelnetworks.com]
Sent: maandag 19 april 2004 18:42
To: 'Harrington, David'; Wijnen, Bert (Bert)
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
Hi David,
Here are some comments on the draft.
- The references to SNMPv3 RFCs throughout the document are all out-of-date, they need to be updated to 341*.
- On page 6, right at the end of section 3.4.1.2, the text about dot1dStpPortPathCost needs to be changed, it
should refer to the new object dot1dStpPortPathCost32, rather than describing a change to the older object.
- On page 7, the stpCompatible(0) enumeration in dot1dStpVersion ought to be stpCompatible(1) (RFC 2578,
section 7.1.1 recommends that integer enumerations start at 1).
- On page 8, I'd like to see better working in the DESCRIPTION of dot1dStpPathCostDefault. Something like this:
"The version of the Spanning Tree default Path Costs that
are to be used by this Bridge. A value of 8021d1998(1)
means the bridge is using the 16-bit default Path Costs from
IEEE Std. 802.1D-1998. A value of stp8021t2001(2) means
the bridge is using the 32-bit default Path Costs from IEEE
Std. 802.1t."
- On page 9, I think dot1dStpPortProtocolMigration should not be of type TruthValue, the semantics of the
object do not match the semantics of TruthValue. A better choice would be to use a plain enumerated
INTEGER type. Also, only one enumerated value is really required.
- On page 9 and 10, I think there should be more text in the DESCRIPTIONs of dot1dStpPortAdminEdgePort
and dot1dStpPortOperEdgePort to describe the behaviour of these objects, and their relationship. For example,
what happens to the value of dot1dStpPortOperEdgePort when the value of dot1dStpPortAdminEdgePort is set
to false(2)? The DESCRIPTIONs don't spell this out, and they should.
- On page 11-12, the rstpDefaultPathCostGroup OBJECT-GROUP does not appear in the rstpCompliance
MODULE-COMPLIANCE statement. While I don't think it is required to appear in a MODULE-COMPLIANCE
statement, I wasn't sure where this was just an over-sight, or whether it was intentionally left out.
That's it, hope this is helpful.
-Dave
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: Friday, April 09, 2004 8:31 AM
To: Levi, David [SC100:323:EXCH]; Wijnen, Bert (Bert)
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
I would appreciate the help.
Thanks,
dbh
From: David Levi [mailto:dlevi@nortelnetworks.com]
Sent: Thursday, April 08, 2004 6:50 PM
To: Harrington, David; Wijnen, Bert (Bert)
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
David,
If it can wait until late next week, then yes.
-Dave
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: Thursday, April 08, 2004 3:16 PM
To: Wijnen, Bert (Bert); Levi, David [SC100:323:EXCH]
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
Hi,
We are about to go to last call with the rstp mib, IF my initial review shows it is ready for such. I could certainly use help since I have to review all the bridgemib documents before going to last call.
Dave, are you interested in doing a MIB Doctor review or a lighterweight MIB Doctor review (Is that a MIB Nurse review) of the rstpmib for me?
dbh
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, April 08, 2004 10:34 AM
To: David Levi; 'Wijnen, Bert (Bert)'
Cc: Harrington, David
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
Dave, are you not getting it?
I am trying to pull you into some active IETF work again ;-)
It is fun man!
Would a promise for a good beer convince you?
Thanks,
Bert
-----Original Message-----
From: David Levi [mailto:dlevi@nortelnetworks.com]
Sent: donderdag 8 april 2004 16:20
To: 'Wijnen, Bert (Bert)'
Cc: David Harrington (E-mail)
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
Bert,
Actually, I think it is safe to claim that we are implementing the std track version, because the only
real difference is that we have it rooted in our enterprise branch instead of under dot1dBridge.
-Dave
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, April 08, 2004 7:41 AM
To: Levi, David [SC100:323:EXCH]
Cc: David Harrington (E-mail)
Subject: RE: draft-ietf-bridge-rstpmib-04.txt
At the moment, we are implementing a clone of the RSTP-MIB under our enterprises branch,
but we'd prefer to implement a standarized version.
So PLEASE help Dave Harrington finalize, so you can implement an IETF stds track one!?
Bert
-Dave