idnits 2.17.1 draft-ietf-ipoib-ibmib-tc-mib-08.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 594. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 2006) is 6523 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) == Missing Reference: 'RFC 2578' is mentioned on line 98, but not defined == Missing Reference: 'RFC 2579' is mentioned on line 101, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'IBTAARCH' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP over InfiniBand 3 Internet Draft Hal Rosenstock 4 draft-ietf-ipoib-ibmib-tc-mib-08.txt HNR Consulting 5 Expires: December 2006 June 2006 7 Definitions of Textual Conventions 8 and OBJECT-IDENTITIES for 9 IP Over InfiniBand (IPOVERIB) Management 11 13 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This memo defines a Management Information Base (MIB) module that 37 contains Textual Conventions and OBJECT-IDENTITIES for use in 38 definitions of management information for IP Over InfiniBand 39 (IPOVERIB) networks. The intent is that these TEXTUAL 40 CONVENTIONs (TCs) will be imported and used in IPOVERIB related 41 MIB modules. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Table of Contents 49 1. Introduction...................................................3 50 2. The Internet-Standard Management Framework.....................3 51 3. IPOVERIB Textual Conventions MIB Definitions...................4 52 4. Security Considerations.......................................12 53 5. IANA Considerations...........................................12 54 6. Revision History..............................................12 55 6.1 Changes from .......12 56 7. References....................................................12 57 7.1 Normative References......................................13 58 7.2 Informative References....................................13 59 8. Acknowledgements..............................................13 60 9. Author's Address..............................................13 61 10. Intellectual Property Notice.................................14 62 11. Full Copyright Statement.....................................14 64 1. Introduction 66 This memo defines a portion of the Management Information Base for 67 use with network management protocols in the Internet community. 68 In particular, it defines Textual Conventions used in IETF IPOVERIB 69 and IPOVERIB-related MIBs. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 For an introduction to the concepts of InfiniBand, see [IBTAARCH]. 77 2. The Internet-Standard Management Framework 79 For a detailed overview of the documents that describe the current 80 Internet-Standard Management Framework, please refer to section 7 of 81 RFC 3410 [RFC3410]. 83 Managed objects are accessed via a virtual information store, termed 84 the Management Information Base or MIB. MIB objects are generally 85 accessed through the Simple Network Management Protocol (SNMP). 86 Objects in the MIB are defined using the mechanisms defined in the 87 Structure of Management Information (SMI). This memo specifies a MIB 88 module that is compliant to the SMIv2, which is described in STD 58, 89 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 90 [RFC2580]. 92 3. IPOVERIB Textual Conventions MIB Definitions 94 IB-TC-MIB DEFINITIONS ::= BEGIN 96 IMPORTS 97 experimental, MODULE-IDENTITY, Unsigned32 98 FROM SNMPv2-SMI -- [RFC 2578] 100 TEXTUAL-CONVENTION 101 FROM SNMPv2-TC; -- [RFC 2579] 103 ibTcMIB MODULE-IDENTITY 104 LAST-UPDATED "200606270000Z" -- 27 June 2006 00:00:00 GMT 105 ORGANIZATION 106 "IETF IP over IB (IPOIB) Working Group" 107 CONTACT-INFO 108 "Hal Rosenstock 109 Postal: HNR Consulting 110 200 Old Harvard Road 111 Boxboro MA 01719-1834 112 United States 113 Email: hnrose@earthlink.net 115 Email comments to the IPOIB WG Mailing List at 116 ipoverib@ietf.org." 117 DESCRIPTION 118 "Copyright (C) The Internet Society (2006). The initial 119 version of this MIB module was published in RFC XXXX; for 120 full legal notices see the RFC itself. Supplementary 121 information may be available on 122 http://www.ietf.org/copyrights/ianamib.html. 124 This MIB contains managed object definitions and textual 125 conventions for managing InfiniBand devices that support 126 the IP Over InfiniBand (IPOIB) protocols and procedures." 128 REVISION 129 "200606270000Z" -- 27 June 2006 00:00:00 GMT 130 DESCRIPTION 131 "Initial version published as part of RFC XXXX." 132 ::= { infinibandMIB 1 } 134 -- The IANA has currently defined the InfiniBand MIB on the 135 -- experimental branch. 137 infinibandMIB OBJECT IDENTIFIER ::= { experimental 117 } 138 -- This object identifier needs to be reassigned by IANA. 139 -- Since infiniband has been assigned an ifType of 199 a 140 -- recommendation is made that this OID be 199 as well, e.g. 142 -- ::= { transmission 199 } 143 -- 144 -- The updated Object Identifier definition would be: 145 -- 146 -- infinibandMIB OBJECT IDENTIFIER ::= { transmission 199 } 147 -- 149 -- Textual Conventions. 151 IbPort ::= TEXTUAL-CONVENTION 152 DISPLAY-HINT "d" 153 STATUS current 154 DESCRIPTION 155 "Identifies an InfiniBand (IB) Port. The InfiniBand 156 Architecture (IBA) defines a maximum of 254 physical ports 157 numbered Port 1 to Port 254. A port is the location on a 158 Channel Adapter, IB Router, or IB Switch to which a link is 159 connected. If a device has N ports, the physical ports are 160 always numbered from 1 to N. The relationship between an 161 InfiniBand port and an ifIndex is one-to-one. As such, the 162 value of an ifIndex object instance can be directly used to 163 identify corresponding instances of the objects defined 164 herein as IB ports. Note: this definition does include 165 enhanced switch port 0 but not base switch port 0. In the 166 case of a switch with enhanced switch port 0, the ifIndex is 167 offset by 1 from the ibPort. In all other cases, the ifIndex 168 is identical to the ibPort." 169 REFERENCE 170 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 171 Section 18.2.4.1 (C18-10.a1) for switches and (C18-14.a1) 172 for switch port 0, Section 17.2.1.3 (C17-7.a1) for Channel 173 Adapters, and Section 19.2.4.2 for routers." 174 SYNTAX Unsigned32 (0..254) 176 IbPhysPort ::= TEXTUAL-CONVENTION 177 DISPLAY-HINT "d" 178 STATUS current 179 DESCRIPTION 180 "Identifies a physical InfiniBand (IB) Port. The InfiniBand 181 Architecture (IBA) defines a maximum of 254 physical ports 182 numbered Port 1 to Port 254. A port is the location on a 183 Channel Adapter, IB Router, or IB Switch to which a link is 184 connected. If a device has N ports, the ports are always 185 numbered from 1 to N. Note: this definition does NOT include 186 switch Port 0, which is not a physical port." 187 REFERENCE 188 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 189 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 190 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 191 routers." 192 SYNTAX Unsigned32 (1..254) 194 IbPhysPortAndInvalid ::= TEXTUAL-CONVENTION 195 DISPLAY-HINT "d" 196 STATUS current 197 DESCRIPTION 198 "Identifies a physical IB port plus an invalid port number. 199 The invalid port number has a value of 255. Note: this 200 definition does NOT include switch logical Port 0, which is 201 not a physical port." 202 REFERENCE 203 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 204 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 205 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 206 routers." 207 SYNTAX Unsigned32 (1..255) 209 IbDataPort ::= TEXTUAL-CONVENTION 210 DISPLAY-HINT "d" 211 STATUS deprecated 212 DESCRIPTION 213 "Identifies a physical InfiniBand (IB) Port. The InfiniBand 214 Architecture (IBA) defines a maximum of 254 physical ports 215 numbered Port 1 to Port 254. A port is the location on a 216 Channel Adapter, IB Router, or IB Switch to which a link is 217 connected. If a device has N ports, the ports are always 218 numbered from 1 to N. The relationship between an InfiniBand 219 port and an ifIndex is one-to-one. As such, the value of an 220 ifIndex object instance can be directly used to identify 221 corresponding instances of the objects defined herein as IB 222 data ports. Note: this definition does NOT include logical 223 Port 0, which is reserved for IB management packets." 224 REFERENCE 225 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 226 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 227 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 228 routers." 229 SYNTAX Unsigned32 (1..254) 231 IbDataPortAndInvalid ::= TEXTUAL-CONVENTION 232 STATUS deprecated 233 DESCRIPTION 234 "Identifies a physical IB port plus an invalid port number. 235 The invalid port number has a value of 255. Note: this 236 definition does NOT include logical Port 0, which is reserved 237 for IB management packets." 238 REFERENCE 239 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 240 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 241 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 242 routers." 243 SYNTAX Unsigned32 (1..255) 245 IbVirtualLane ::= TEXTUAL-CONVENTION 246 DISPLAY-HINT "d" 247 STATUS current 248 DESCRIPTION 249 "Identifies a Virtual Lane (VL) instance on a given interface 250 (i.e., IB port). VLs provide a mechanism for creating 251 multiple virtual links within a physical link. IBA defines 252 VL 0 through VL 14 for data and VL 15 exclusively for Subnet 253 Management. The actual data VLs that a port uses are 254 configured by the Subnet Manager. The default data VL is 255 always VL 0." 256 REFERENCE 257 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 258 Section 3.5.7." 259 SYNTAX Unsigned32 (0..15) 261 IbDataVirtualLane ::= TEXTUAL-CONVENTION 262 DISPLAY-HINT "d" 263 STATUS current 264 DESCRIPTION 265 "Identifies a Data Virtual Lane instance on a given interface 266 (i.e., IB port). This TC definition excludes the management 267 Virtual Lane (VL 15). The actual data VLs that a port uses 268 are configured by the Subnet Manager. The default data VL is 269 always the first VL (VL 0)." 270 REFERENCE 271 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 272 Section 3.5.7." 273 SYNTAX Unsigned32 (0..14) 275 IbDlid ::= TEXTUAL-CONVENTION 276 DISPLAY-HINT "d" 277 STATUS current 278 DESCRIPTION 279 "Identifies the Destination Local Identifier (DLID). The IBA 280 defines LID 0 as reserved and valid Local Identifier (LID) 281 values from 1 to 65535. LID 65535 is defined as a permissive 282 DLID. 284 This value is stored in IBA defined bit order, that is, the 285 high-order bit of the Local Identifier byte 0 is positioned 286 as the high-order bit of the first byte of the integer 287 representation." 289 REFERENCE 290 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 291 Section 4.1.3." 292 SYNTAX Unsigned32 (0..65535) 294 IbUnicastLid ::= TEXTUAL-CONVENTION 295 DISPLAY-HINT "d" 296 STATUS current 297 DESCRIPTION 298 "Identifies a Unicast LID. Value is stored in IBA defined bit 299 order, that is, the high-order bit of the Local Identifier 300 byte 0 is positioned as the high-order bit of the first byte 301 of the integer representation." 302 REFERENCE 303 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 304 Section 4.1.3." 305 SYNTAX Unsigned32 (0..49151) 307 IbMulticastLid ::= TEXTUAL-CONVENTION 308 DISPLAY-HINT "d" 309 STATUS current 310 DESCRIPTION 311 "Identifies a Multicast LID. Value is stored in IBA defined 312 bit order, that is, the high-order bit of the Local 313 Identifier byte 0 is positioned as the high-order bit of the 314 first byte of the integer representation." 315 REFERENCE 316 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 317 Section 4.1.3." 318 SYNTAX Unsigned32 (49152..65535) 320 IbGuid ::= TEXTUAL-CONVENTION 321 DISPLAY-HINT "1x:" 322 STATUS current 323 DESCRIPTION 324 "Globally Unique Identifier (GUID) is a number that uniquely 325 identifies an IB device or component. It is a compliant 326 IEEE-defined 64-bit extended unique identifier (EUI-64) 327 for Host Channel Adapters (HCA), Terminal Channel Adpaters 328 (TCA), routers, and switches. This 64-bit value is created 329 by concatenating a 24-bit company ID value and a 40-bit 330 extension. The IEEE Registration Authority assigns the 331 company ID. The extension ID is assigned by the particular 332 company. Each HCA, TCA, switch, and router as well as each 333 endport shall be assigned an EUI-64 GUID by the 334 manufacturer." 335 REFERENCE 336 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 337 Section 4.1." 339 SYNTAX OCTET STRING (SIZE(8)) 341 IbSmaPortList ::= TEXTUAL-CONVENTION 342 STATUS current 343 DESCRIPTION 344 "Each bit mapping within this value specifies a port presence 345 within the managed IB device. This definition includes bit0 346 as IB Port 0, the switch management port. Valid physical 347 port mappings are from bit1 to bit254. Bit255 is invalid 348 and MUST always be zero." 349 REFERENCE 350 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 351 Section 18.2.4.1 (C18-10.a1) for switches and (C18-14.a1) 352 for switch port 0, Section 17.2.1.3 (C17-7.a1) for Channel 353 Adapters, and Section 19.2.4.2 for routers." 354 SYNTAX OCTET STRING (SIZE(32)) 356 IbSmPortList ::= TEXTUAL-CONVENTION 357 STATUS deprecated 358 DESCRIPTION 359 "Each bit mapping within this value specifies a port presence 360 within the managed IB device. This definition includes bit0 361 as IB Port 0, the logical port used exclusively for 362 management packets. Valid data port mappings are from bit1 to 363 bit254. Bit255 is invalid and MUST always be zero." 364 REFERENCE 365 "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH] 366 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 367 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 368 routers." 369 SYNTAX OCTET STRING (SIZE(32)) 371 IbIpoibClientIdentifier ::= TEXTUAL-CONVENTION 372 STATUS current 373 DESCRIPTION 374 "The IPOIB Client Identifier uniquely identifies an IPOIB link 375 layer address associated with the InfiniBand port. It 376 comprises three fields. 377 1. Global Identifier (GID) 378 2. Queue Pair Number field (QPN) 379 3. reserved 381 0 1 2 3 382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |1:GID(0-7) |2:GID(8-15) |3:GID(16-23) |4:GID(24-31) | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |5:GID(32-39) |6:GID(40-47) |7:GID(48-55) |8:GID(56-63) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |9:GID(64-71) |10:GID(72-79) |11:GID(80-87) |12:GID(88-95) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |13:GID(96-103) |14:GID(104-111)|15:GID(112-119)|16:GID(120-127)| 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |17:QPN(0-7) |18:QPN(8-15) |19:QPN(16-23) |20:(reserved) | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 The Global Identifier field is a 16 octet field (octets 1 396 through 16) that is formed by the combination of the IB 397 subnet prefix and the port's GUID. It is unique in the 398 InfiniBand fabric. NOTE: An IPOIB interface may have more 399 than 1 GID associated with it. 401 The Queue Pair Number field is a 3 octet field (octets 17, 402 18, & 19) that identifies the destination queue pair. Note: 403 The reserved field and the QPN field are collectively 404 referred to as the interface-id. If an IPOIB interface has 405 only 1 GID associated with it, the interface-id MAY contain 406 all zeroes. 408 The reserved field is octet 20. It is reserved for future 409 use. These bits SHOULD be set to zero." 410 SYNTAX OCTET STRING (SIZE(20)) 412 IbSmSubnetPrefix ::= TEXTUAL-CONVENTION 413 DISPLAY-HINT "2x:" 414 STATUS current 415 DESCRIPTION 416 "The 64-bit value used to identify an InfiniBand subnet." 417 SYNTAX OCTET STRING (SIZE(8)) 419 IbSmState ::= TEXTUAL-CONVENTION 420 STATUS current 421 DESCRIPTION 422 "Subnet Manager's state: 423 notActive(0) SM is not active 424 discovering(1) SM is discovering subnet 425 standby(2) SM is in standby role 426 master(3) SM is in master role." 427 SYNTAX INTEGER { 428 notActive(0), 429 discovering(1), 430 standby(2), 431 master(3) 432 } 434 IbNodeType ::= TEXTUAL-CONVENTION 435 STATUS current 436 DESCRIPTION 437 "Type of InfiniBand node." 438 SYNTAX INTEGER { 439 unknown(0), 440 channelAdapter(1), 441 switch(2), 442 router(3) 443 } 445 IbMtu ::= TEXTUAL-CONVENTION 446 STATUS current 447 DESCRIPTION 448 "The MTU size of this InfiniBand link." 449 SYNTAX INTEGER { 450 mtu256(1), 451 mtu512(2), 452 mtu1024(3), 453 mtu2048(4), 454 mtu4096(5) 455 } 457 IbPartitionKey ::= TEXTUAL-CONVENTION 458 DISPLAY-HINT "x" 459 STATUS current 460 DESCRIPTION 461 "The 16-bit Partition Key." 462 SYNTAX Unsigned32 (0..65535) 464 IbPartition ::= TEXTUAL-CONVENTION 465 DISPLAY-HINT "x" 466 STATUS current 467 DESCRIPTION 468 "The 15-bit Partition Key Base (without the membership bit)." 469 SYNTAX Unsigned32 (0..32767) 471 IbTransportTime ::= TEXTUAL-CONVENTION 472 STATUS current 473 DESCRIPTION 474 "The time value used to calculate the InfiniBand network 475 delay or response. The duration of time is calculated 476 by the following formula: 477 delay/response = (4.096 microseconds * 2 ^ IbTransportTime)." 478 SYNTAX Unsigned32 (0..31) 480 END 482 4. Security Considerations 484 This memo defines textual conventions and object identities for use 485 in IPOVERIB MIB modules. Security issues for these MIB modules are 486 addressed in the memos defining those modules. Because this memo 487 does not define management objects, the memo has no impact on the 488 security of the Internet. 490 5. IANA Considerations 492 IANA is requested to make a MIB OID assignment under the transmission 493 branch, that is, assign the infinibandMIB under { transmission 199 }. 494 This sub-id is requested because 199 is the ifType for 495 infiniband(199) and is available under transmission. 497 In the future, IPOIB related standards track MIB modules should be 498 rooted under the infinibandMIB subtree. The IANA is requested to 499 manage that namespace. New assignments can only be made via a 500 Standards Action as specified in [RFC2434]. 502 This document also requests IANA to assign { infinibandMIB 1 } to the 503 IB-TC-MIB specified in this document. 505 6. Revision History 507 This section should be removed when this document is published as an 508 RFC. 510 6.1 Changes from 512 Added IbPort, IbPhysPort, and IbPhysPortAndInvalid and deprecated 513 IbDataPort and IbDataPortAndInvalid 515 Added IbSmaPortList and deprecated IbSmPortList 517 Added IbPartition 519 Updated to InfiniBand Architecture Revision 1.2 from 1.1 521 Resolved nits with 523 Added revision history 525 7. References 526 7.1 Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 532 IANA Considerations Section in RFCs", BCP: 26, RFC 2434, 533 October 1998. 535 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 536 Rose, M. and S. Waldbusser, "Structure of Management 537 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 538 1999. 540 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 541 Rose, M. and S. Waldbusser, "Textual Conventions for 542 SMIv2", STD 58, RFC 2579, April 1999. 544 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 545 Rose, M. and S. Waldbusser, "Conformance Statements for 546 SMIv2", STD 58, RFC 2580, April 1999. 548 [IBTAARCH] InfiniBand Architecture Specification Volume 1, 549 Release 1.2, October, 2004, Final Release. 551 7.2 Informative References 553 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 554 "Introduction and Applicability Statements for 555 Internet-Standard Management Framework", RFC 3410, 556 December 2002. 558 8. Acknowledgements 560 This MIB module was updated based on the original work done by Sean 561 Harnedy. Bill Anderson, and Bill Strahm. 563 9. Author's Address 565 Hal Rosenstock 566 HNR Consulting 567 200 Old Harvard Road 568 Boxboro, MA 01719-1834 569 USA 570 Email: hnrose@earthlink.net 572 10. Intellectual Property Notice 574 The IETF takes no position regarding the validity or scope of any 575 Intellectual Property Rights or other rights that might be claimed 576 to pertain to the implementation or use of the technology 577 described in this document or the extent to which any license 578 under such rights might or might not be available; nor does it 579 represent that it has made any independent effort to identify any 580 such rights. Information on the procedures with respect to rights 581 in RFC documents can be found in BCP 78 and BCP 79. 583 Copies of IPR disclosures made to the IETF Secretariat and any 584 assurances of licenses to be made available, or the result of an 585 attempt made to obtain a general license or permission for the use 586 of such proprietary rights by implementers or users of this 587 specification can be obtained from the IETF on-line IPR repository 588 at http://www.ietf.org/ipr. 590 The IETF invites any interested party to bring to its attention 591 any copyrights, patents or patent applications, or other 592 proprietary rights that may cover technology that may be required 593 to implement this standard. Please address the information to the 594 IETF at ietf-ipr@ietf.org. 596 11. Full Copyright Statement 598 Copyright (C) The Internet Society (2006). 599 This document is subject to the rights, licenses and restrictions 600 contained in BCP 78, and except as set forth therein, the authors 601 retain all their rights. 603 This document and the information contained herein are provided 604 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 605 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 606 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 607 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 608 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 609 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 610 PARTICULAR PURPOSE. 612 This document and translations of it may be copied and 613 furnished to others, and derivative works that comment on 614 or otherwise explain it or assist in its implementation may 615 be prepared, copied, published and distributed, in whole or 616 in part, without restriction of any kind, provided that the 617 above copyright notice and this paragraph are included on 618 all such copies and derivative works. However, this document 619 itself may not be modified in any way, such as by removing the 620 copyright notice or references to the Internet Society or other 621 Internet organizations, except as needed for the purpose of 622 developing Internet standards in which case the procedures for 623 copyrights defined in the Internet Standards process must be 624 followed, or as required to translate it into languages other 625 than English. 627 The limited permissions granted above are perpetual and 628 will not be revoked by the Internet Society or its 629 successors or assigns. 631 Acknowledgement 633 Funding for the RFC Editor function is currently provided by the 634 Internet Society.