draft-ietf-bridge-rstpmib-04.txt   draft-ietf-bridge-rstpmib-05.txt 
Internet Draft V. Ngai Internet Draft V. Ngai
Expires August 2004 Enterasys Networks Expires March 2005 Enterasys Networks
draft-ietf-bridge-rstpmib-04.txt E. Bell draft-ietf-bridge-rstpmib-05.txt E. Bell
3Com Corp. 3Com Corp.
March 2004 September 2004
Definitions of Managed Objects for Bridges Definitions of Managed Objects for Bridges
with Rapid Spanning Tree Protocol with Rapid Spanning Tree Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, I certify that any applicable
of Section 10 of RFC2026. Internet-Drafts are working documents of patent or other IPR claims of which I am aware have been disclosed,
the Internet Engineering Task Force (IETF), its areas, and its or will be disclosed, and any of which I become aware will be
working groups. Note that other groups may also distribute working disclosed, in accordance with RFC 3668.
documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets. for use with network management protocols in TCP/IP based internets.
In particular, it defines a MIB module for managing the Rapid In particular, it defines a MIB module for managing the Rapid
Spanning Tree capability defined by the IEEE P802.1t [802.1t] and Spanning Tree capability defined by the IEEE P802.1t [802.1t] and
P802.1w [802.1w] amendments to IEEE Std 802.1D-1998 for bridging P802.1w [802.1w] amendments to IEEE Std 802.1D-1998 for bridging
between Local Area Network (LAN) segments. between Local Area Network (LAN) segments.
Provisions are made for support of transparent bridging. Provisions Provisions are made for support of transparent bridging. Provisions
are also made so that these objects apply to bridges connected by are also made so that these objects apply to bridges connected by
subnetworks other than LAN segments. This memo also includes a MIB subnetworks other than LAN segments. This memo also includes a MIB
module in a manner that is compliant to SMIv2 [RFC2578]. module in a manner that is compliant to SMIv2 [RFC2578].
This memo supplements RFC 1493 [BRIDGEMIB] and RFC 2674 [Q-BRIDGE- This memo supplements RFC 1493 [RFC1493] and RFC 2674 [RFC2674].
MIB].
Table of Contents Table of Contents
1 The SNMP Management Framework ................................ 3 1 The Internet-Standard Management Framework ................... 4
2 Overview ..................................................... 4 2 Overview ..................................................... 4
2.1 Scope ...................................................... 4 2.1 Scope ...................................................... 4
3 Structure of MIBs ............................................ 4 3 Structure of MIBs ............................................ 4
3.1 Structure of RSTP-MIB ...................................... 4 3.1 Structure of RSTP-MIB ...................................... 5
3.4 Relationship to Other MIBs ................................. 5 3.2 Relationship to Other MIBs ................................. 5
3.4.1 Relationship to Original Bridge MIB ...................... 5 3.2.1 Relation to Original Bridge MIB .......................... 5
3.4.1.1 The dot1dBase Group .................................... 5 3.2.1.1 The dot1dBase Group .................................... 6
3.4.1.2 The dot1dStp Group ..................................... 5 3.2.1.2 The dot1dStp Group ..................................... 6
3.4.1.3 The dot1dTp Group ...................................... 6 3.2.1.3 The dot1dTp Group ...................................... 7
3.4.1.4 The dot1dStatic Group .................................. 6 3.2.1.4 The dot1dStatic Group .................................. 7
4 Definition for RSTP-MIB ...................................... 7 4 Definitions for RSTP-MIB ..................................... 8
5 Acknowledgments .............................................. 13 5 Acknowledgments .............................................. 15
6 Security consideration ....................................... 13 6 Security Considerations ...................................... 15
7 References ................................................... 14 7 Normative References ......................................... 16
8 Authors' Addresses ........................................... 16 8 Informative References ....................................... 17
9 Intellectual Property ........................................ 17 9 Authors' Addresses ........................................... 18
10 Full Copyright .............................................. 18 Intellectual Property Statement ............................... 19
Disclaimer of Validity ........................................ 19
1. The SNMP Management Framework Copyright Statement ........................................... 19
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573 1. The Internet-Standard Management Framework
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework For a detailed overview of the documents that describe the current
can be found in RFC 2570 [RFC2570]. Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. MIB objects are generally
defined using the mechanisms defined in the SMI. accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
This memo specifies a MIB module that is compliant to the SMIv2. A Structure of Management Information (SMI). This memo specifies a MIB
MIB conforming to the SMIv1 can be produced through the appropriate module that is compliant to the SMIv2, which is described in STD 58,
translations. The resulting translated MIB must be semantically RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
equivalent, except where objects or events are omitted because no [RFC2580].
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
2. Overview 2. Overview
A common device present in many networks is the Bridge. This device A common device present in many networks is the Bridge. This device
is used to connect Local Area Network segments below the network is used to connect Local Area Network segments below the network
layer. These devices are often known as 'layer 2 switches'. layer. These devices are often known as 'layer 2 switches'.
There are two major modes defined for this bridging: Source-Route and There are two major modes defined for this bridging: Source-Route and
transparent. Source-Route bridging is described by IEEE 802.5 transparent. Source-Route bridging is described by IEEE 802.5
[802.5] and is not discussed further in this document. [802.5] and is not discussed further in this document.
The transparent method of bridging is defined by IEEE 802.1D-1998 The transparent method of bridging is defined by IEEE 802.1D-1998
[802.1D] Managed objects for that original specification of [802.1D] Managed objects for that original specification of
transparent bridging were defined in RFC 1493 [BRIDGEMIB]. transparent bridging were defined in RFC 1493 [RFC1493].
2.1. Scope 2.1. Scope
This MIB includes a comprehensive set of managed objects which This MIB includes a comprehensive set of managed objects which
attempts to match the set defined in IEEE P802.1t [802.1t] and attempts to match the set defined in IEEE P802.1t [802.1t] and
P802.1w [802.1w]. P802.1w [802.1w].
3. Structure of MIBs 3. Structure of MIBs
This document defines additional managed objects for Rapid Spanning This document defines additional managed objects for Rapid Spanning
Tree Protocol defined by IEEE P802.1t and IEEE P802.1w, on top of Tree Protocol defined by IEEE P802.1t and IEEE P802.1w, on top of
those existing in the original BRIDGE-MIB module defined in those existing in the original BRIDGE-MIB module defined in
[BRIDGEMIB]: that MIB module is to be maintained unchanged for [RFC1493]: that MIB module is to be maintained unchanged for
backwards compatibility. Section 3.4.1 of the present document backwards compatibility. Section 3.4.1 of the present document
contains some recommendations regarding usage of objects in the contains some recommendations regarding usage of objects in the
original bridge MIB by devices implementing the enhancements defined original bridge MIB by devices implementing the enhancements defined
here. here.
3.1. Structure of RSTP-MIB 3.1. Structure of RSTP-MIB
Objects in this MIB are defined as an addition to the dot1dStp group Objects in this MIB are defined as an addition to the dot1dStp group
in the original bridge MIB [BRIDGE-MIB]. The overall structure is in the original bridge MIB [RFC1493]. The overall structure is
shown below: shown below:
Bridge MIB Name IEEE 802.1 Reference Bridge MIB Name IEEE 802.1 Reference
dot1dStp dot1dStp
dot1dStpVersion (w) 17.16.1 ForceVersion dot1dStpVersion (w) 17.16.1 ForceVersion
dot1dStpTxHoldCount (w) 17.16.6 TxHoldCount dot1dStpTxHoldCount (w) 17.16.6 TxHoldCount
dot1dStpPathCostDefault dot1dStpPathCostDefault
dot1dStpExtPortTable dot1dStpExtPortTable
dot1dStpPortProtocolMigration (w) 17.18.10 mcheck dot1dStpPortProtocolMigration (w) 17.18.10 mcheck
dot1dStpPortAdminEdgePort (t) 18.3.3 adminEdgePort dot1dStpPortAdminEdgePort (t) 18.3.3 adminEdgePort
dot1dStpPortOperEdgePort (t) 18.3.4 operEdgePort dot1dStpPortOperEdgePort (t) 18.3.4 operEdgePort
dot1dStpPortAdminPointToPoint (w) 6.4.3 adminPointToPointMAC dot1dStpPortAdminPointToPoint (w) 6.4.3 adminPointToPointMAC
dot1dStpPortOperPointToPoint (w) 6.4.3 operPointToPointMAC dot1dStpPortOperPointToPoint (w) 6.4.3 operPointToPointMAC
dot1dStpPortAdminPathCost (D) 8.5.5.3 Path Cost dot1dStpPortAdminPathCost (D) 8.5.5.3 Path Cost
3.4. Relationship to Other MIBs 3.2. Relationship to Other MIBs
As described above, some IEEE 802.1D management objects have not been As described above, some IEEE 802.1D management objects have not been
included in this MIB because they overlap with objects in other MIBs included in this MIB because they overlap with objects in other MIBs
applicable to a bridge implementing this MIB. In particular, it is applicable to a bridge implementing this MIB. In particular, it is
assumed that a bridge implementing this MIB will implement the assumed that a bridge implementing this MIB will implement the
original bridge MIB [BRIDGEMIB]. original bridge MIB [RFC1493].
3.4.1. Relation to Original Bridge MIB 3.2.1. Relation to Original Bridge MIB
This section defines how objects in the original bridge MIB module This section defines how objects in the original bridge MIB module
[BRIDGEMIB] should be represented for devices which implement all the [RFC1493] should be represented for devices which implement all the
MIB modules described in this memo. Some of the old objects are less MIB modules described in this memo. Some of the old objects are less
useful in such devices but must still be implemented for reasons of useful in such devices but must still be implemented for reasons of
backwards compatibility. backwards compatibility.
3.4.1.1. The dot1dBase Group 3.2.1.1. The dot1dBase Group
This mandatory group contains the objects which are applicable to all This mandatory group contains the objects which are applicable to all
types of bridges. Interpretation of this group is unchanged. types of bridges. Interpretation of this group is unchanged.
3.4.1.2. The dot1dStp Group 3.2.1.2. The dot1dStp Group
This group contains the objects that denote the bridge's state with This group contains the objects that denote the bridge's state with
respect to the Spanning Tree Protocol. If a node does not implement respect to the Spanning Tree Protocol. If a node does not implement
the Spanning Tree Protocol, this group will not be implemented. the Spanning Tree Protocol, this group will not be implemented.
In a device supporting the Spanning Tree Algorithm and Protocol In a device supporting the Spanning Tree Algorithm and Protocol
defined in IEEE 802.1D-1998 Clause 8, interpretation of this group is defined in IEEE 802.1D-1998 Clause 8, interpretation of this group is
unchanged. unchanged.
In a device supporting the Rapid Spanning Tree Algorithm and Protocol In a device supporting the Rapid Spanning Tree Algorithm and Protocol
skipping to change at page 6, line 22 skipping to change at page 6, line 41
dot1dStpTimeSinceTopologyChange dot1dStpTimeSinceTopologyChange
The time since the tcWhile timer for any port on this Bridge was The time since the tcWhile timer for any port on this Bridge was
non-zero. non-zero.
dot1dStpTopChanges dot1dStpTopChanges
The number of times that there have been at least one non-zero The number of times that there have been at least one non-zero
tcWhile timer on this Bridge. tcWhile timer on this Bridge.
In a device supporting the 32-bit default Path Costs defined in IEEE 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 802.1t Table 8-5, the object dot1dStpPortPathCost32 [RFC1493] should
unchanged except for the following: be used rather than the older object dot1dStpPortPathCost. The newer
object supports the expanded range of 1-200,000,000.
dot1dStpPortPathCost
Definition remains unchanged, but the permissible values are
extended to 1-200,000,000.
3.4.1.3. The dot1dTp Group 3.2.1.3. The dot1dTp Group
This group contains objects that describe the entity's state with This group contains objects that describe the entity's state with
respect to transparent bridging. Interpretation for this group is respect to transparent bridging. Interpretation for this group is
unchanged. unchanged.
3.4.1.4. The dot1dStatic Group 3.2.1.4. The dot1dStatic Group
This group contains objects that describe the entity's state with This group contains objects that describe the entity's state with
respect to destination-address filtering. Interpretation for this respect to destination-address filtering. Interpretation for this
group is unchanged. group is unchanged.
4. Definitions for RSTP-MIB 4. Definitions for RSTP-MIB
RSTP-MIB DEFINITIONS ::= BEGIN RSTP-MIB DEFINITIONS ::= BEGIN
-- ------------------------------------------------------------- -- -------------------------------------------------------------
skipping to change at page 8, line 34 skipping to change at page 9, line 36
dot1dStpPathCostDefault OBJECT-TYPE dot1dStpPathCostDefault OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
stp8021d1998(1), stp8021d1998(1),
stp8021t2001(2) stp8021t2001(2)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The version of the Spanning Tree default Path Costs that "The version of the Spanning Tree default Path Costs that
are to be used by this Bridge. A value of 8021d1998(1) are to be used by this Bridge. A value of 8021d1998(1)
uses the 16-bit default Path Costs from IEEE Std. 802.1D-1998. means the bridge is using the 16-bit default Path Costs from
A value of stp8021t2001(2) uses the 32-bit default Path IEEE Std. 802.1D-1998. A value of stp8021t2001(2) means
Costs from IEEE Std. 802.1t." the bridge is using the 32-bit default Path Costs from IEEE
Std. 802.1t."
REFERENCE REFERENCE
"IEEE 802.1D & 802.1t Table 8-5" "IEEE 802.1D & 802.1t Table 8-5"
::= { dot1dStp 18 } ::= { dot1dStp 18 }
dot1dStpExtPortTable OBJECT-TYPE dot1dStpExtPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dStpExtPortEntry SYNTAX SEQUENCE OF Dot1dStpExtPortEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table that contains port-specific Rapid Spanning Tree "A table that contains port-specific Rapid Spanning Tree
skipping to change at page 9, line 49 skipping to change at page 11, line 8
::= { dot1dStpExtPortEntry 1 } ::= { dot1dStpExtPortEntry 1 }
dot1dStpPortAdminEdgePort OBJECT-TYPE dot1dStpPortAdminEdgePort OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The administrative value of the Edge Port parameter. A "The administrative value of the Edge Port parameter. A
value of TRUE(1) indicates that this port should be value of TRUE(1) indicates that this port should be
assumed as an edge-port and a value of FALSE(2) indicates assumed as an edge-port and a value of FALSE(2) indicates
that this port should be assumed as a non-edge-port." 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."
REFERENCE REFERENCE
"IEEE 802.1t clause 14.8.2, 18.3.3" "IEEE 802.1t clause 14.8.2, 18.3.3"
::= { dot1dStpExtPortEntry 2 } ::= { dot1dStpExtPortEntry 2 }
dot1dStpPortOperEdgePort OBJECT-TYPE dot1dStpPortOperEdgePort OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The operational value of the Edge Port parameter. The "The operational value of the Edge Port parameter. The
object is initialized to the value of object is initialized to the value of the corresponding
dot1dStpPortAdminEdgePort and is set FALSE on reception of instance of dot1dStpPortAdminEdgePort. When the
a BPDU." 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."
REFERENCE REFERENCE
"IEEE 802.1t clause 14.8.2, 18.3.4" "IEEE 802.1t clause 14.8.2, 18.3.4"
::= { dot1dStpExtPortEntry 3 } ::= { dot1dStpExtPortEntry 3 }
dot1dStpPortAdminPointToPoint OBJECT-TYPE dot1dStpPortAdminPointToPoint OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
forceTrue(0), forceTrue(0),
forceFalse(1), forceFalse(1),
auto(2) auto(2)
} }
skipping to change at page 14, line 5 skipping to change at page 16, line 5
SNMPv1 by itself is not a secure environment. Even if the network SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB. GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model [USM] and the View-based Access of the User-based Security Model [USM] and the View-based Access
Control Model [VACM] is recommended. Control Model [VACM] is recommended.
7. References 7. Normative References
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, An Architecture
for Describing SNMP Management Frameworks, RFC 2571, April
1999.
[RFC1155] Rose, M., and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based Internets, STD
16, RFC 1155, May 1990.
[RFC1212] Rose, M., and K. McCloghrie, Concise MIB Definitions, STD
16, RFC 1212, March 1991.
[RFC1215] M. Rose, A Convention for Defining Traps for use with the
SNMP, RFC 1215, March 1991.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, Structure of Management Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2), STD 58, RFC 2578, April Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999. 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, Textual Conventions for SMIv2, Rose, M., and S. Waldbusser, "Textual Conventions for
STD 58, RFC 2579, April 1999. SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, Conformance Statements for Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2, STD 58, RFC 2580, April 1999. SMIv2", STD 58, RFC 2580, April 1999.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple
Network Management Protocol, STD 15, RFC 1157, May 1990.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Introduction to Community-based SNMPv2, RFC 1901, January
1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2), RFC 1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, Message
Processing and Dispatching for the Simple Network
Management Protocol (SNMP), RFC 2572, April 1999.
[RFC2574] Blumenthal, U., and B. Wijnen, User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3), RFC 2574, April 1999.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2), RFC 1905, January 1996.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications,
RFC 2573, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP), RFC 2575, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
Introduction to Version 3 of the Internet-standard Network
Management Framework, RFC 2570, April 1999.
[RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A. and [RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A. and
McCloghrie, "Definitions of Managed Objects for Bridges McCloghrie, "Definitions of Managed Objects for Bridges
with Traffic Classes, Multicast Filtering and Virtual LAN with Traffic Classes, Multicast Filtering and Virtual LAN
Extensions", RFC 2674, August 1999. Extensions", RFC 2674, August 1999.
[802.1D] "Information technology - Telecommunications and [802.1D] "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Common specifications - Part metropolitan area networks - Common specifications - Part
3: Media Access Control (MAC) Bridges: Revision. This is 3: Media Access Control (MAC) Bridges: Revision. This is
a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k- a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-
1992. It incorporates P802.11c, P802.1p and P802.12e." 1992. It incorporates P802.11c, P802.1p and P802.12e."
ISO/IEC 15802-3: 1998. ISO/IEC 15802-3: 1998.
[BRIDGEMIB] Decker, E., Langille, P., Rijsinghani, A. and K. [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie,
McCloghrie, "Definitions of Managed Objects for Bridges", "Definitions of Managed Objects for Bridges", RFC 1493,
RFC 1493, July 1993. July 1993.
[802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D) IEEE [802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D) IEEE
Standard for Information technology - Telecommunications Standard for Information technology - Telecommunications
and information exchange between systems - Local and and information exchange between systems - Local and
metropolitan area networks - Common specifications - Part metropolitan area networks - Common specifications - Part
3: Media Access Control (MAC) Bridges: Technical and 3: Media Access Control (MAC) Bridges: Technical and
Editorial Corrections". Editorial Corrections".
[802.1w] IEEE 802.1w-2001, "(Amendment to IEEE Standard 802.1D) IEEE [802.1w] IEEE 802.1w-2001, "(Amendment to IEEE Standard 802.1D) IEEE
Standard for Information technology--Telecommunications and Standard for Information technology--Telecommunications and
information exchange between systems--Local and information exchange between systems--Local and
metropolitan area networks--Common Specifications--Part 3: metropolitan area networks--Common Specifications--Part 3:
Media Access Control (MAC) Bridges: Rapid Reconfiguation". Media Access Control (MAC) Bridges: Rapid Reconfiguation".
8. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
9. Authors' Addresses 9. Authors' Addresses
Les Bell Les Bell
3Com Europe Limited 3Com Europe Limited
eCom Centre, Boundary Way eCom Centre, Boundary Way
Hemel Hempstead Hemel Hempstead
Herts. HP2 7YU Herts. HP2 7YU
UK UK
Phone: +44 1442 438025 Phone: +44 1442 438025
skipping to change at page 17, line 5 skipping to change at page 19, line 5
Vivian Ngai Vivian Ngai
Enterasys Networks Enterasys Networks
2691 South Decker Lake Lane 2691 South Decker Lake Lane
Salt Lake City, UT 84119 Salt Lake City, UT 84119
USA USA
Phone: +1 801 556 5652 Phone: +1 801 556 5652
Email: vivian_ngai@acm.org Email: vivian_ngai@acm.org
9. Intellectual Property Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
10. Full Copyright
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished This document and the information contained herein are provided on an
to others, and derivative works that comment on or otherwise "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
explain it or assist in its implementation may be prepared, copied, OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
published and distributed, in whole or in part, without ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
restriction of any kind, provided that the above copyright notice INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
and this paragraph are included on all such copies and derivative INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
works. However, this document itself may not be modified in any WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not Copyright Statement
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on Copyright (C) The Internet Society (2004). This document is subject
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET to the rights, licenses and restrictions contained in BCP 78, and
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR except as set forth therein, the authors retain all their rights.
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/