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