Rstp-mib

Hi,

I'm doing a review of the RSTP-MIB document, and I think some editing
and reorganization is called for. I believe all the changes are
editorial in nature, with the one technical change being the OID
assignment change.

Please review my proposed changes and raise any issues, please. Since
this group has been fairly unresponsive, I will assume a lack of
response indicates consensus to adopt the changes.

-----------
( editor: The feb23 revision has the actual TOC at the end rather than
in the Table of Contents section. The nroff should be fixed. )
-----------
The title of the document should be changed to "RSTP MIB" since there
is only one module in the document. Since 802.1w is an identifier for
a transient effort, it probably shouldn't be part of the title.

-----------
Some references to the bridge-mib must be to the original RFC1493
(such as section 3.1), and others to the updated version. Most will
require reference to the updated version, which I recommend be
referenced as [RFC1493bis] and add a note to the RFC-editor to correct
this to the assigned RFC.

-----------
No references are allowed in the abstract. I suggest condensing the
abstract.
<Suggested text>
Abstract
   This memo defines an SMIv2 MIB module for managing the Rapid
   Spanning Tree capability defined by the IEEE P802.1t and
   P802.1w amendments to IEEE Std 802.1D-1998 for bridging
   between Local Area Network (LAN) segments. The objects are
   defined to apply to transparent bridging, and to bridges 
   connected by subnetworks other than LAN segments. 
</Suggested text>

I would remove the line that says this mib supplements RFC1493 and
RFC2674; that should be discussed under "Relationship to other MIBs".

-----------
I suggest that the current sections 1 and 2 be trimmed and merged.
Much of what is here appears to be copied from RFC1493 and is not
appropriate to this document. I would lead with the overview, and
follow with the boilerplate.
<Suggested text>
1. Overview

   This memo defines an SMIv2 MIB module for managing the Rapid
   Spanning Tree (RSTP) capability defined by the IEEE P802.1t 
   and P802.1w amendments to IEEE Std 802.1D-1998 for bridging
   between Local Area Network (LAN) segments. The objects can
   apply to transparent bridges, and to bridges connected by 
   subnetworks other than LAN segments. 

1.1. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7
of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store,
termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a
MIB
   module that is compliant to the SMIv2, which is described in STD
58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].
</suggested text> // to replace sections 1 and 2.

-----------
Section 3 has lots of info that apparently was cut and pasted from
RFC1493, and should be eliminated.

I suggest that current section 3.1 become section 2, to list the
objects in the RSTP MIB and their relationship to the IEEE
specifications. 
<Suggested text>
"2. Relationship to IEEE 802.1t and 802.1w amendments

   This document defines managed objects for the Rapid Spanning
   Tree Protocol defined by the IEEE P802.1t and IEEE P802.1w
   amendments to 802.1d-1998.

   RSTP-MIB Name                       IEEE 802.1 Reference

   dot1dStp
     dot1dStpVersion                   (w) 17.16.1  ForceVersion
     dot1dStpTxHoldCount               (w) 17.16.6  TxHoldCount
     dot1dStpPathCostDefault
     dot1dStpExtPortTable
       dot1dStpPortProtocolMigration   (w) 17.18.10 mcheck
       dot1dStpPortAdminEdgePort       (t) 18.3.3   adminEdgePort
       dot1dStpPortOperEdgePort        (t) 18.3.4   operEdgePort
       dot1dStpPortAdminPointToPoint   (w) 6.4.3
adminPointToPointMAC
       dot1dStpPortOperPointToPoint    (w) 6.4.3
operPointToPointMAC
       dot1dStpPortAdminPathCost       (D) 8.5.5.3  Path Cost
</ suggested text>

-----------
I suggest the current section 3 be replaced. I would eliminate all
text that discusses "mandatory" objects or unchanged interpretations;
For SMIv2 modules, that discussion largely belongs in the compliance
statements of the referenced modules. Apparently, there is no
relationship between this mib module and RFC2674.
<suggested text>
3.  Relationship to the BRIDGE-MIB

   The Original BRIDGE-MIB [RFC1493] has been updated in an 
   SMIv2-compliant version [RFC1493bis]. Conformance statements 
   have been added and some description and reference clauses 
   have been updated. The interpretations of some objects were 
   changed to accommodate IEEE 802.1t and 802.1w amendments.
    
   The object dot1dStpPortPathCost32 was added to
   support IEEE 802.1t, and the permissible values of
   dot1dStpPriority and dot1dStpPortPriority have been
   clarified for bridges supporting IEEE 802.1t or
   IEEE 802.1w. The interpretation of 
   dot1dStpTimeSinceTopologyChange has been clarified 
   for bridges supporting the RSTP.

   See the updated BRIDGE-MIB [RFC1493bis] for details.

   The objects in the RSTP-MIB supplement those 
   defined in the BRIDGE-MIB [RFC1493bis].

</ suggested text>

-----------
Definitions for RSTP-MIB
Following current MIB Doctor guidelines, the MODULE-IDENTITY should be
{ mib-2 xxxx }
Below that, it is recommended to put rstpNotifications(0),
rstpObjects(1), and rstpConformance(2)

.dot1dStpTxHoldCount - the DESCRIPTION doesn't discuss the
relationship between this and HelloTime.

-----------
The Security Considerations section needs details.
-----------
An IANA section is needed to discuss the assignment of the
MODULE-IDENTITY OID.


David Harrington
[email protected]