idnits 2.17.1 draft-ietf-bridge-rstpmib-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 630. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 38), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 224: '...e of this object MUST be retained acro...' RFC 2119 keyword, line 239: '...e of this object MUST be retained acro...' RFC 2119 keyword, line 317: '...e of this object MUST be retained acro...' RFC 2119 keyword, line 362: '...e of this object MUST be retained acro...' RFC 2119 keyword, line 406: '...e of this object MUST be retained acro...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2005) is 6822 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RSTP MIB August 2005 4 Internet Draft D.Levi 5 Expires February 2006 Nortel Networks 6 draft-ietf-bridge-rstpmib-09.txt D.Harrington 7 Effective Software 8 August 2005 10 Definitions of Managed Objects for Bridges 11 with Rapid Spanning Tree Protocol 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 This memo defines an SMIv2 MIB module for managing the Rapid Spanning 43 Tree capability defined by the IEEE P802.1t and P802.1w amendments to 44 IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) 45 segments. The objects in this MIB are defined to apply both to 46 transparent bridging and to bridges connected by subnetworks other 47 than LAN segments. 49 Table of Contents 51 1 The Internet-Standard Management Framework ................... 3 52 2 Overview ..................................................... 3 53 3 Relationship to IEEE 802.1t and 802.1w amendments ............ 3 54 4 Relation to the BRIDGE-MIB ................................... 4 55 5 Definitions for RSTP-MIB ..................................... 5 56 6 Acknowledgments .............................................. 12 57 7 IANA Considerations .......................................... 12 58 8 Security Considerations ...................................... 12 59 9 Normative References ......................................... 14 60 10 Informative References ...................................... 14 61 11 Authors' Addresses .......................................... 16 62 Intellectual Property Statement ............................... 17 63 Disclaimer of Validity ........................................ 17 64 Copyright Statement ........................................... 17 66 1. The Internet-Standard Management Framework 68 For a detailed overview of the documents that describe the current 69 Internet-Standard Management Framework, please refer to section 7 of 70 RFC 3410 [RFC3410]. 72 Managed objects are accessed via a virtual information store, termed 73 the Management Information Base or MIB. MIB objects are generally 74 accessed through the Simple Network Management Protocol (SNMP). 75 Objects in the MIB are defined using the mechanisms defined in the 76 Structure of Management Information (SMI). This memo specifies a MIB 77 module that is compliant to the SMIv2, which is described in STD 58, 78 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 79 [RFC2580]. 81 2. Overview 83 This memo defines an SMIv2 MIB module for managing the Rapid Spanning 84 Tree (RSTP) capability defined by the IEEE P802.1t [802.1t] and 85 P802.1w [802.1w] amendments to IEEE Std 802.1D-1998 [802.1D-1998] for 86 bridging between Local Area Network (LAN) segments. The objects in 87 this MIB are defined to apply both to transparent bridging and to 88 bridges connected by subnetworks other than LAN segments. 90 3. Relationship to IEEE 802.1t and 802.1w amendments 92 This document defines managed object for the Rapid Spanning Tree 93 Protocol defined by the IEEE P802.1t and IEEE P802.1w amendments to 94 802.1D-1998. 96 RSTP-MIB Name IEEE 802.1 Reference 98 dot1dStp 99 dot1dStpVersion (w) 17.16.1 ForceVersion 100 dot1dStpTxHoldCount (w) 17.16.6 TxHoldCount 101 dot1dStpExtPortTable 102 dot1dStpPortProtocolMigration (w) 17.18.10 mcheck 103 dot1dStpPortAdminEdgePort (t) 18.3.3 adminEdgePort 104 dot1dStpPortOperEdgePort (t) 18.3.4 operEdgePort 105 dot1dStpPortAdminPointToPoint (w) 6.4.3 adminPointToPointMAC 106 dot1dStpPortOperPointToPoint (w) 6.4.3 operPointToPointMAC 107 dot1dStpPortAdminPathCost (D) 8.5.5.3 Path Cost 109 There are concerns that there may be changes made in the 802.1D-2004 110 edition that would lead to non-backwards compatible SMI changes for 111 802.1t and 802.1w managed objects in the MIB modules. The Bridge MIB 112 WG decided to 'freeze' the technical content of the MIB modules at a 113 level that is compatible with the 802.1t and 802.1w versions, and 114 leave to the IEEE 802.1 WG any updates beyond this. 116 For informational purposes only, these are the references for the 117 above objects in 802.1D-2004 [802.1D-2004]. 119 RSTP-MIB Name IEEE 802.1D-2004 Reference 121 dot1dStp 122 dot1dStpVersion 17.13.4 ForceVersion 123 dot1dStpTxHoldCount 17.13.12 TxHoldCount 124 dot1dStpExtPortTable 125 dot1dStpPortProtocolMigration 17.19.13 mcheck 126 dot1dStpPortAdminEdgePort 17.13.1 adminEdgePort 127 dot1dStpPortOperEdgePort 17.19.17 operEdgePort 128 dot1dStpPortAdminPointToPoint 6.4.3 adminPointToPointMAC 129 dot1dStpPortOperPointToPoint 6.4.3 operPointToPointMAC 130 dot1dStpPortAdminPathCost 17.13.11 Path Cost 132 4. Relation to the BRIDGE-MIB 134 The objects in the RSTP-MIB supplement those defined in the Bridge 135 MIB [RFC1493bis]. 137 The Original BRIDGE-MIB [RFC1493] has been updated in an 138 SMIv2-compliant version [RFC1493bis]. Conformance statements have 139 been added and some description and reference clauses have been 140 updated. The interpretations of some objects were changed to 141 accommodate IEEE 802.1t and 802.1w amendments. 143 The object dot1dStpPortPathCost32 was added to support IEEE 802.1t, 144 and the permissible values of dot1dStpPriority and 145 dot1dStpPortPriority have been clarified for bridges supporting IEEE 146 802.1t or IEEE 802.1w. The interpretation of 147 dot1dStpTimeSinceTopologyChange has been clarified for bridges 148 supporting the RSTP. 150 See the updated BRIDGE-MIB [RFC1493bis] for details. 152 5. Definitions for RSTP-MIB 154 RSTP-MIB DEFINITIONS ::= BEGIN 156 -- ------------------------------------------------------------- 157 -- MIB for IEEE 802.1w Rapid Spanning Tree Protocol 158 -- ------------------------------------------------------------- 160 IMPORTS 161 MODULE-IDENTITY, OBJECT-TYPE, Integer32, mib-2 162 FROM SNMPv2-SMI 163 TruthValue 164 FROM SNMPv2-TC 165 MODULE-COMPLIANCE, OBJECT-GROUP 166 FROM SNMPv2-CONF 167 dot1dStp, dot1dStpPortEntry 168 FROM BRIDGE-MIB; 170 rstpMIB MODULE-IDENTITY 171 LAST-UPDATED "200507290000Z" 172 ORGANIZATION "IETF Bridge MIB Working Group" 173 CONTACT-INFO 174 "Email: Bridge-mib@ietf.org" 175 DESCRIPTION 176 "The Bridge MIB Extension module for managing devices 177 that support the Rapid Spanning Tree Protocol defined 178 by IEEE 802.1w. 180 Copyright (C) The Internet Society (2005). This version of 181 this MIB module is part of RFC XXXX; See the RFC itself for 182 full legal notices." 183 -- RFC Ed.: replace XXXX with RFC number and remove this note 185 REVISION "200507290000Z" 186 DESCRIPTION 187 "The initial version of this MIB module as published in 188 RFC XXXX." 189 -- RFC Ed.: replace XXXX with RFC number and remove this note 191 ::= { mib-2 xxxx } 192 -- RFC Ed.: replace xxxx with IANA-assigned number and 193 -- remove this note 195 -- ---------------------------------------------------------- -- 196 -- subtrees in the RSTP-MIB 197 -- ---------------------------------------------------------- -- 199 rstpNotifications OBJECT IDENTIFIER ::= { rstpMIB 0 } 200 rstpObjects OBJECT IDENTIFIER ::= { rstpMIB 1 } 201 rstpConformance OBJECT IDENTIFIER ::= { rstpMIB 2 } 203 -- ------------------------------------------------------------- 204 -- Addition to the dot1dStp group 205 -- ------------------------------------------------------------- 207 dot1dStpVersion OBJECT-TYPE 208 SYNTAX INTEGER { 209 stpCompatible(0), 210 rstp(2) 211 } 212 MAX-ACCESS read-write 213 STATUS current 214 DESCRIPTION 215 "The version of Spanning Tree Protocol the bridge is 216 currently running. The value 'stpCompatible(0)' 217 indicates the Spanning Tree Protocol specified in 218 IEEE 802.1D-1998 and 'rstp(2)' indicates the Rapid 219 Spanning Tree Protocol specified in IEEE 802.1w and 220 clause 17 of 802.1D-2004. The values are directly from 221 the IEEE standard. New values may be defined as future 222 versions of the protocol become available. 224 The value of this object MUST be retained across 225 reinitializations of the management system." 226 REFERENCE 227 "IEEE 802.1w clause 14.8.1, 17.12, 17.16.1" 228 DEFVAL { rstp } 229 ::= { dot1dStp 16 } 231 dot1dStpTxHoldCount OBJECT-TYPE 232 SYNTAX Integer32 (1..10) 233 MAX-ACCESS read-write 234 STATUS current 235 DESCRIPTION 236 "The value used by the Port Transmit state machine to limit 237 the maximum transmission rate. 239 The value of this object MUST be retained across 240 reinitializations of the management system." 242 REFERENCE 243 "IEEE 802.1w clause 17.16.6" 244 DEFVAL { 3 } 245 ::= { dot1dStp 17 } 247 -- 248 -- { dot1dStp 18 } was used to represent dot1dStpPathCostDefault 249 -- in an internet-draft version of this MIB. It has since been 250 -- obsoleted, and should not be used. 251 -- 253 dot1dStpExtPortTable OBJECT-TYPE 254 SYNTAX SEQUENCE OF Dot1dStpExtPortEntry 255 MAX-ACCESS not-accessible 256 STATUS current 257 DESCRIPTION 258 "A table that contains port-specific Rapid Spanning Tree 259 information." 260 ::= { dot1dStp 19 } 262 dot1dStpExtPortEntry OBJECT-TYPE 263 SYNTAX Dot1dStpExtPortEntry 264 MAX-ACCESS not-accessible 265 STATUS current 266 DESCRIPTION 267 "A list of Rapid Spanning Tree information maintained by 268 each port." 269 AUGMENTS { dot1dStpPortEntry } 270 ::= { dot1dStpExtPortTable 1 } 272 Dot1dStpExtPortEntry ::= 273 SEQUENCE { 274 dot1dStpPortProtocolMigration 275 TruthValue, 276 dot1dStpPortAdminEdgePort 277 TruthValue, 278 dot1dStpPortOperEdgePort 279 TruthValue, 280 dot1dStpPortAdminPointToPoint 281 INTEGER, 282 dot1dStpPortOperPointToPoint 283 TruthValue, 284 dot1dStpPortAdminPathCost 285 Integer32 286 } 288 dot1dStpPortProtocolMigration OBJECT-TYPE 289 SYNTAX TruthValue 290 MAX-ACCESS read-write 291 STATUS current 292 DESCRIPTION 293 "When operating in RSTP (version 2) mode, writing true(1) 294 to this object forces this port to transmit RSTP BPDUs. 295 Any other operation on this object has no effect and 296 it always returns false(2) when read." 297 REFERENCE 298 "IEEE 802.1w clause 14.8.2.4, 17.18.10, 17.26" 299 ::= { dot1dStpExtPortEntry 1 } 301 dot1dStpPortAdminEdgePort OBJECT-TYPE 302 SYNTAX TruthValue 303 MAX-ACCESS read-write 304 STATUS current 305 DESCRIPTION 306 "The administrative value of the Edge Port parameter. A 307 value of true(1) indicates that this port should be 308 assumed as an edge-port and a value of false(2) indicates 309 that this port should be assumed as a non-edge-port. 310 Setting this object will also cause the corresponding 311 instance of dot1dStpPortOperEdgePort to change to the 312 same value. Note that even when this object's value 313 is true, the value of the corresponding instance of 314 dot1dStpPortOperEdgePort can be false if a BPDU has 315 been received. 317 The value of this object MUST be retained across 318 reinitializations of the management system." 320 REFERENCE 321 "IEEE 802.1t clause 14.8.2, 18.3.3" 322 ::= { dot1dStpExtPortEntry 2 } 324 dot1dStpPortOperEdgePort OBJECT-TYPE 325 SYNTAX TruthValue 326 MAX-ACCESS read-only 327 STATUS current 328 DESCRIPTION 329 "The operational value of the Edge Port parameter. The 330 object is initialized to the value of the corresponding 331 instance of dot1dStpPortAdminEdgePort. When the 332 corresponding instance of dot1dStpPortAdminEdgePort is 333 set, this object will be changed as well. This object 334 will also be changed to false on reception of a BPDU." 336 REFERENCE 337 "IEEE 802.1t clause 14.8.2, 18.3.4" 338 ::= { dot1dStpExtPortEntry 3 } 340 dot1dStpPortAdminPointToPoint OBJECT-TYPE 341 SYNTAX INTEGER { 342 forceTrue(0), 343 forceFalse(1), 344 auto(2) 345 } 346 MAX-ACCESS read-write 347 STATUS current 348 DESCRIPTION 349 "The administrative point-to-point status of the LAN segment 350 attached to this port, using the enumeration values of the 351 IEEE 802.1w clause. A value of forceTrue(0) indicates 352 that this port should always be treated as if it is connected 353 to a point-to-point link. A value of forceFalse(1) indicates 354 that this port should be treated as having a shared media 355 connection. A value of auto(2) indicates that this port is 356 considered to have a point-to-point link if it is an Aggregator 357 and all of its members are aggregatable, or if the MAC entity 358 is configured for full duplex operation, either through 359 auto-negotiation or by management means. Manipulating this 360 object changes the underlying adminPortToPortMAC. 362 The value of this object MUST be retained across 363 reinitializations of the management system." 365 REFERENCE 366 "IEEE 802.1w clause 6.4.3, 6.5, 14.8.2" 367 ::= { dot1dStpExtPortEntry 4 } 369 dot1dStpPortOperPointToPoint OBJECT-TYPE 370 SYNTAX TruthValue 371 MAX-ACCESS read-only 372 STATUS current 373 DESCRIPTION 374 "The operational point-to-point status of the LAN segment 375 attached to this port. It indicates whether a port is 376 considered to have a point-to-point connection or not. 377 If adminPointToPointMAC is set to auto(2), then the value 378 of operPointToPointMAC is determined in accordance with the 379 specific procedures defined for the MAC entity concerned, 380 as defined in IEEE 802.1w clause 6.5. The value is 381 determined dynamically; i.e., it is re-evaluated whenever 382 the value of adminPointToPointMAC changes, and whenever 383 the specific procedures defined for the MAC entity evaluate 384 a change in its point-to-point status." 385 REFERENCE 386 "IEEE 802.1w clause 6.4.3, 6.5, 14.8.2" 387 ::= { dot1dStpExtPortEntry 5 } 389 dot1dStpPortAdminPathCost OBJECT-TYPE 390 SYNTAX Integer32 (0..200000000) 391 MAX-ACCESS read-write 392 STATUS current 393 DESCRIPTION 394 "The administratively assigned value for the contribution 395 of this port to the path cost of paths towards the spanning 396 tree root. 398 Writing a value of '0' assigns the automatically calculated 399 default Path Cost value to the port. If the default Path 400 Cost is being used, this object returns '0' when read. 402 This complements the object dot1dStpPortPathCost or 403 dot1dStpPortPathCost32, which returns the operational value 404 of the path cost. 406 The value of this object MUST be retained across 407 reinitializations of the management system." 408 REFERENCE 409 "IEEE 802.1D-1998: Section 8.5.5.3" 410 ::= { dot1dStpExtPortEntry 6 } 412 -- ------------------------------------------------------------- 413 -- rstpMIB - Conformance Information 414 -- ------------------------------------------------------------- 416 rstpGroups OBJECT IDENTIFIER ::= { rstpConformance 1 } 418 rstpCompliances OBJECT IDENTIFIER ::= { rstpConformance 2 } 420 -- ------------------------------------------------------------- 421 -- Units of conformance 422 -- ------------------------------------------------------------- 424 rstpBridgeGroup OBJECT-GROUP 425 OBJECTS { 426 dot1dStpVersion, 427 dot1dStpTxHoldCount 429 } 430 STATUS current 431 DESCRIPTION 432 "Rapid Spanning Tree information for the bridge." 433 ::= { rstpGroups 1 } 435 rstpPortGroup OBJECT-GROUP 436 OBJECTS { 437 dot1dStpPortProtocolMigration, 438 dot1dStpPortAdminEdgePort, 439 dot1dStpPortOperEdgePort, 440 dot1dStpPortAdminPointToPoint, 441 dot1dStpPortOperPointToPoint, 442 dot1dStpPortAdminPathCost 443 } 444 STATUS current 445 DESCRIPTION 446 "Rapid Spanning Tree information for individual ports." 447 ::= { rstpGroups 2 } 449 -- ------------------------------------------------------------- 450 -- Compliance statements 451 -- ------------------------------------------------------------- 453 rstpCompliance MODULE-COMPLIANCE 454 STATUS current 455 DESCRIPTION 456 "The compliance statement for device support of Rapid 457 Spanning Tree Protocol (RSTP) bridging services." 458 MODULE 459 MANDATORY-GROUPS { 460 rstpBridgeGroup, 461 rstpPortGroup 462 } 463 ::= { rstpCompliances 1 } 465 END 466 6. Acknowledgments 468 This document was produced on behalf of the Bridge MIB Working Group 469 in the Operations and Management area of the Internet Engineering 470 Task Force. 472 The authors wish to thank the members of the Bridge MIB Working 473 Group, especially Alex Ruzin, for their comments and suggestions 474 which improved this effort. 476 Vivian Ngai and Les Bell were the initial authors of this document, 477 and did the bulk of the development work for this document. 479 7. IANA Considerations 481 This document requires an OID assignment to be made by IANA: 483 Descriptor OBJECT IDENTIFIER value 484 ---------- ----------------------- 485 rstpMIB { mib-2 xxxx } 487 8. Security Considerations 489 There are a number of management objects defined in this MIB that 490 have a MAX-ACCESS clause of read-write and/or read-create. Such 491 objects may be considered sensitive or vulnerable in some network 492 environments. The support for SET operations in a non-secure 493 environment without proper protection can have a negative effect on 494 network operations. 496 Writable objects that could be misused to cause network delays and 497 spanning tree instabilities include dot1dStpVersion, 498 dot1dStpTxHoldCount, dot1dStpPortProtocolMigration, 499 dot1dStpPortAdminEdgePort, and dot1dStpPortAdminPathCost. 501 dot1dStpVersion could be read by an attacker to identify environments 502 containing applications or protocols which are potentially sensitive 503 to RSTP mode. 505 dot1dStpPortAdminPointToPoint could be used to mislead an access 506 control protocol, such as 802.1x, to believe that only one other 507 system is attached to a LAN segment and to enable network access 508 based on that assumption. This situation could permit potential man- 509 in-the-middle attacks. 511 SNMPv1 by itself is not a secure environment. Even if the network 512 itself is secure (for example by using IPSec), even then, there is no 513 control as to who on the secure network is allowed to access and 514 GET/SET (read/change/create/delete) the objects in this MIB. 516 It is RECOMMENDED that implementers consider the security features as 517 provided by the SNMPv3 framework (see [RFC3410], section 8), 518 including full support for the SNMPv3 cryptographic mechanisms (for 519 authentication and privacy), and user-based access control. 521 9. Normative References 523 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 524 Rose, M., and S. Waldbusser, "Structure of Management 525 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 526 1999. 528 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 529 Rose, M., and S. Waldbusser, "Textual Conventions for 530 SMIv2", STD 58, RFC 2579, April 1999. 532 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 533 Rose, M., and S. Waldbusser, "Conformance Statements for 534 SMIv2", STD 58, RFC 2580, April 1999. 536 [802.1D-1998] "Information technology - Telecommunications and 537 information exchange between systems - Local and 538 metropolitan area networks - Common specifications - Part 539 3: Media Access Control (MAC) Bridges: Revision. This is 540 a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 541 802.6k-1992. It incorporates P802.11c, P802.1p and 542 P802.12e." ISO/IEC 15802-3: 1998. 544 [RFC1493bis] Bell, E. and Norseth, K., "Definitions of Managed Objects 545 for Bridges", draft-ietf-bridge-bridgemib-smiv2-10.txt, 546 February 2005. NOTE TO RFC EDITOR: Replace the above ID 547 reference with the appropriate RFC. 549 [802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D) IEEE 550 Standard for Information technology - Telecommunications 551 and information exchange between systems - Local and 552 metropolitan area networks - Common specifications - Part 553 3: Media Access Control (MAC) Bridges: Technical and 554 Editorial Corrections". 556 [802.1w] IEEE 802.1w-2001, "(Amendment to IEEE Standard 802.1D) IEEE 557 Standard for Information technology--Telecommunications and 558 information exchange between systems--Local and 559 metropolitan area networks--Common Specifications--Part 3: 560 Media Access Control (MAC) Bridges: Rapid Reconfiguation". 562 10. Informative References 564 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 565 "Introduction and Applicability Statements for Internet 566 Standard Management Framework", RFC 3410, December 2002. 568 [802.1D-2004] IEEE Project 802 Local and Metropolitan Area 569 Networks, "IEEE Standard 802.1D-2004 MAC Bridges", 2004. 571 [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, 572 "Definitions of Managed Objects for Bridges", RFC 1493, 573 July 1993. 575 11. Authors' Addresses 577 David Levi 578 Nortel Networks 579 4655 Great America Parkway 580 Santa Clara, CA 95054 581 USA 583 Phone: +1 865 686 0432 584 Email: dlevi@nortel.com 586 David Harrington 587 Effective Software 588 50 Harding Rd. 589 Portsmouth, NH 03801 590 USA 592 Phone: +1 603 436 8634 593 Email: ietfdbh@comcast.net 595 Les Bell 596 Hemel Hempstead 597 Herts. HP2 7YU 598 UK 600 EMail: elbell@ntlworld.com 602 Vivian Ngai 603 Salt lake City, UT 604 USA 606 Email: vivian_ngai@acm.org 608 Intellectual Property Statement 610 The IETF takes no position regarding the validity or scope of any 611 Intellectual Property Rights or other rights that might be claimed to 612 pertain to the implementation or use of the technology described in 613 this document or the extent to which any license under such rights 614 might or might not be available; nor does it represent that it has 615 made any independent effort to identify any such rights. Information 616 on the procedures with respect to rights in RFC documents can be 617 found in BCP 78 and BCP 79. 619 Copies of IPR disclosures made to the IETF Secretariat and any 620 assurances of licenses to be made available, or the result of an 621 attempt made to obtain a general license or permission for the use of 622 such proprietary rights by implementers or users of this 623 specification can be obtained from the IETF on-line IPR repository at 624 http://www.ietf.org/ipr. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights that may cover technology that may be required to implement 629 this standard. Please address the information to the IETF at 630 ietf-ipr@ietf.org. 632 Disclaimer of Validity 634 This document and the information contained herein are provided 635 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 636 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 637 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 638 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 639 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 640 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 641 PARTICULAR PURPOSE. 643 Copyright Statement 645 Copyright (C) The Internet Society (2005). 647 This document is subject to the rights, licenses and restrictions 648 contained in BCP 78, and except as set forth therein, the authors 649 retain all their rights.