[Bridge-mib] RE: draft-ietf-bridge-rstpmib-04.txt

["David Levi" <[e-mail]>]

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:[e-mail]] 
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:[e-mail]] 
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:[e-mail]]
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:[e-mail]] 
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:[e-mail]] 
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:[e-mail]] 
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:[e-mail]] 
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:[e-mail]]
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:[e-mail]] 
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