idnits 2.17.1 draft-ietf-entmib-v3-06.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2883. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 37), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (07 January 2005) is 7048 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 CLEIURN' is mentioned on line 463, but not defined == Missing Reference: 'RFC2574' is mentioned on line 2736, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Missing Reference: 'RFC2575' is mentioned on line 2737, but not defined ** Obsolete undefined reference: RFC 2575 (Obsoleted by RFC 3415) == Unused Reference: 'RFC2026' is defined on line 2757, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) -- Obsolete informational reference (is this intentional?): RFC 1516 (Obsoleted by RFC 2108) -- Obsolete informational reference (is this intentional?): RFC 2037 (Obsoleted by RFC 2737) -- Obsolete informational reference (is this intentional?): RFC 2737 (Obsoleted by RFC 4133) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Entity MIB Working Group Andy Bierman 3 Internet Draft Keith McCloghrie 4 Cisco Systems, Inc. 5 07 January 2005 7 Entity MIB (Version 3) 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This memo defines a portion of the Management Information Base 42 (MIB) for use with network management protocols in the Internet 43 community. In particular, it describes managed objects used for 44 managing multiple logical and physical entities managed by a single 45 SNMP agent. This document specifies version 3 of the Entity MIB, 46 which obsoletes version 2 (RFC 2737). 48 Table of Contents 50 1 The SNMP Management Framework .............................. 3 51 2 Overview ................................................... 3 52 2.1 Terms .................................................... 4 53 2.2 Relationship to Community Strings ........................ 6 54 2.3 Relationship to SNMP Contexts ............................ 6 55 2.4 Relationship to Proxy Mechanisms ......................... 6 56 2.5 Relationship to a Chassis MIB ............................ 7 57 2.6 Relationship to the Interfaces MIB ....................... 7 58 2.7 Relationship to the Other MIBs ........................... 7 59 2.8 Relationship to Naming Scopes ............................ 8 60 2.9 Multiple Instances of the Entity MIB ..................... 8 61 2.10 Re-Configuration of Entities ............................ 9 62 2.11 Textual Convention Change ............................... 9 63 2.12 MIB Structure ........................................... 9 64 2.12.1 entityPhysical Group .................................. 10 65 2.12.2 entityLogical Group ................................... 12 66 2.12.3 entityMapping Group ................................... 12 67 2.12.4 entityGeneral Group ................................... 13 68 2.12.5 entityNotifications Group ............................. 13 69 2.13 Multiple Agents ......................................... 13 70 2.14 Changes Since RFC 2037 .................................. 14 71 2.14.1 Textual Conventions ................................... 14 72 2.14.2 New entPhysicalTable Objects .......................... 14 73 2.14.3 New entLogicalTable Objects ........................... 14 74 2.14.4 Bugfixes .............................................. 15 75 2.15 Changes Since RFC 2737 .................................. 15 76 2.15.1 Textual Conventions ................................... 15 77 2.15.2 New Objects ........................................... 15 78 2.15.3 Bugfixes .............................................. 15 79 3 Definitions ................................................ 16 80 4 Usage Examples ............................................. 48 81 4.1 Router/Bridge ............................................ 48 82 4.2 Repeaters ................................................ 55 83 5 Security Considerations .................................... 62 84 6 IANA Considerations ........................................ 64 85 7 Acknowledgements ........................................... 64 86 8 References ................................................. 64 87 8.1 Normative References ..................................... 64 88 8.2 Informative References ................................... 65 90 1. The SNMP Management Framework 92 For a detailed overview of the documents that describe the current 93 Internet-Standard Management Framework, please refer to section 7 94 of RFC 3410 [RFC3410]. 96 Managed objects are accessed via a virtual information store, 97 termed the Management Information Base or MIB. MIB objects are 98 generally accessed through the Simple Network Management Protocol 99 (SNMP). Objects in the MIB are defined using the mechanisms 100 defined in the Structure of Management Information (SMI). This 101 memo specifies a MIB module that is compliant to the SMIv2, which 102 is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 103 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 105 2. Overview 107 There is a need for a standardized way of representing a single 108 agent which supports multiple instances of one MIB. This is 109 presently true for at least 3 standard MIBs, and is likely to 110 become true for more and more MIBs as time passes. For example: 112 - multiple instances of a bridge supported within a single device 113 having a single agent; 115 - multiple repeaters supported by a single agent; 117 - multiple OSPF backbone areas, each one operating as part of its own 118 Autonomous System, and each identified by the same area-id (e.g., 119 0.0.0.0), supported inside a single router with one agent. 121 The fact that it is a single agent in each of these cases implies 122 there is some relationship which binds all of these entities 123 together. Effectively, there is some "overall" physical entity 124 which houses the sum of the things managed by that one agent, i.e., 125 there are multiple "logical" entities within a single physical 126 entity. Sometimes, the overall physical entity contains multiple 127 (smaller) physical entities and each logical entity is associated 128 with a particular physical entity. Sometimes, the overall physical 129 entity is a "compound" of multiple physical entities (e.g., a stack 130 of stackable hubs). 132 What is needed is a way to determine exactly what logical entities 133 are managed by the agent (with some version of SNMP), and thereby 134 to be able to communicate with the agent about a particular logical 135 entity. When different logical entities are associated with 136 different physical entities within the overall physical entity, it 137 is also useful to be able to use this information to distinguish 138 between logical entities. 140 In these situations, there is no need for varbinds for multiple 141 logical entities to be referenced in the same SNMP message 142 (although that might be useful in the future). Rather, it is 143 sufficient, and in some situations preferable, to have the 144 context/community in the message identify the logical entity to 145 which the varbinds apply. 147 Version 2 of this MIB addresses new requirements that have emerged 148 since the publication of the first Entity MIB (RFC 2037 [RFC2037]). 149 There is a need for a standardized way of providing non-volatile, 150 administratively assigned identifiers for physical components 151 represented with the Entity MIB. There is also a need to align the 152 Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 153 3411 [RFC3411]). Implementation experience has shown that 154 additional physical component attributes are also desirable. 156 Version 3 of this MIB addresses new requirements that have emerged 157 since the publication of the second Entity MIB (RFC 2737 158 [RFC2737]). There is a need for identifying physical entities 159 which are central processing units (CPUs) and a need to provide a 160 textual convention which identifies an entPhysicalIndex value or 161 zero, where the value zero has application-specific semantics. Two 162 new objects have been added to the entPhysicalTable to identify the 163 manufacturing date and provide additional URIs for a particular 164 physical entity. 166 2.1. Terms 168 Some new terms are used throughout this document: 170 - Naming Scope 171 A "naming scope" represents the set of information that may be 172 potentially accessed through a single SNMP operation. All instances 173 within the naming scope share the same unique identifier space. 174 For SNMPv1, a naming scope is identified by the value of the 175 associated 'entLogicalCommunity' instance. For SNMPv3, the term 176 'context' is used instead of 'naming scope'. The complete 177 definition of an SNMP context can be found in section 3.3.1 of RFC 178 3411 [RFC3411]. 180 - Multi-Scoped Object 181 A MIB object, for which identical instance values identify 182 different managed information in different naming scopes, is called 183 a "multi-scoped" MIB object. 185 - Single-Scoped Object 186 A MIB object, for which identical instance values identify the same 187 managed information in different naming scopes, is called a 188 "single-scoped" MIB object. 190 - Logical Entity 191 A managed system contains one or more logical entities, each 192 represented by at most one instantiation of each of a particular 193 set of MIB objects. A set of management functions is associated 194 with each logical entity. Examples of logical entities include 195 routers, bridges, print-servers, etc. 197 - Physical Entity 198 A "physical entity" or "physical component" represents an 199 identifiable physical resource within a managed system. Zero or 200 more logical entities may utilize a physical resource at any given 201 time. It is an implementation-specific manner as to which physical 202 components are represented by an agent in the EntPhysicalTable. 203 Typically, physical resources (e.g., communications ports, 204 backplanes, sensors, daughter-cards, power supplies, the overall 205 chassis) which can be managed via functions associated with one or 206 more logical entities are included in the MIB. 208 - Containment Tree 209 Each physical component may be modeled as 'contained' within 210 another physical component. A "containment-tree" is the conceptual 211 sequence of entPhysicalIndex values which uniquely specifies the 212 exact physical location of a physical component within the managed 213 system. It is generated by 'following and recording' each 214 'entPhysicalContainedIn' instance 'up the tree towards the root', 215 until a value of zero indicating no further containment is found. 217 2.2. Relationship to Community Strings 219 For community-based SNMP, distinguishing between different logical 220 entities is one (but not the only) purpose of the community string 221 (RFC 1157 [RFC1157]). This is accommodated by representing each 222 community string as a logical entity. 224 Note that different logical entities may share the same naming 225 scope (and therefore the same values of entLogicalCommunity). This 226 is possible, providing they have no need for the same instance of a 227 MIB object to represent different managed information. 229 2.3. Relationship to SNMP Contexts 231 Version 2 of the Entity MIB contains support for associating SNMPv3 232 contexts with logical entities. Two new MIB objects, defining an 233 SnmpEngineID and ContextName pair, are used together to identify an 234 SNMP context associated with a logical entity. This context can be 235 used (in conjunction with the entLogicalTAddress and 236 entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of 237 a particular logical entity. 239 2.4. Relationship to Proxy Mechanisms 241 The Entity MIB is designed to allow functional component discovery. 242 The administrative relationships between different logical entities 243 are not visible in any Entity MIB tables. An NMS cannot determine 244 whether MIB instances in different naming scopes are realized 245 locally or remotely (e.g., via some proxy mechanism) by examining 246 any particular Entity MIB objects. 248 The management of administrative framework functions is not an 249 explicit goal of the Entity MIB WG at this time. This new area of 250 functionality may be revisited after some operational experience 251 with the Entity MIB is gained. 253 Note that for community-based versions of SNMP, a network 254 administrator will likely be able to associate community strings 255 with naming scopes with proprietary mechanisms, as a matter of 256 configuration. There are no mechanisms for managing naming scopes 257 defined in this MIB. 259 2.5. Relationship to a Chassis MIB 261 Some readers may recall that a previous IETF working group 262 attempted to define a Chassis MIB. No consensus was reached by 263 that working group, possibly because its scope was too broad. As 264 such, it is not the purpose of this MIB to be a "Chassis MIB 265 replacement", nor is it within the scope of this MIB to contain all 266 the information which might be necessary to manage a "chassis". On 267 the other hand, the entities represented by an implementation of 268 this MIB might well be contained in a chassis. 270 2.6. Relationship to the Interfaces MIB 272 The Entity MIB contains a mapping table identifying physical 273 components that have 'external values' (e.g., ifIndex) associated 274 with them within a given naming scope. This table can be used to 275 identify the physical location of each interface in the ifTable 276 (RFC 2863 [RFC2863]). Since ifIndex values in different contexts 277 are not related to one another, the interface to physical component 278 associations are relative to the same logical entity within the 279 agent. 281 The Entity MIB also contains 'entPhysicalName' and 282 'entPhysicalAlias' objects, which approximate the semantics of the 283 'ifName' and 'ifAlias' objects (respectively) from the Interfaces 284 MIB [RFC2863], for all types of physical components. 286 2.7. Relationship to the Other MIBs 288 The Entity MIB contains a mapping table identifying physical 289 components that have identifiers from other standard MIBs 290 associated with them. For example, this table can be used along 291 with the physical mapping table to identify the physical location 292 of each repeater port in the rptrPortTable, or each interface in 293 the ifTable. 295 2.8. Relationship to Naming Scopes 297 There is some question as to which MIB objects may be returned 298 within a given naming scope. MIB objects which are not multi-scoped 299 within a managed system are likely to ignore context information in 300 implementation. In such a case, it is likely such objects will be 301 returned in all naming scopes (e.g., not just the 'default' naming 302 scope or the SNMPv3 default context). 304 For example, a community string used to access the management 305 information for logical device 'bridge2' may allow access to all 306 the non-bridge related objects in the 'default' naming scope, as 307 well as a second instance of the Bridge MIB (RFC 1493 [RFC1493]). 309 It is an implementation-specific matter as to the isolation of 310 single-scoped MIB objects by the agent. An agent may wish to limit 311 the objects returned in a particular naming scope to just the 312 multi-scoped objects in that naming scope (e.g., system group and 313 the Bridge MIB). In this case, all single-scoped management 314 information would belong to a common naming scope (e.g., 315 'default'), which itself may contain some multi-scoped objects 316 (e.g., system group). 318 2.9. Multiple Instances of the Entity MIB 320 It is possible that more than one agent exists in a managed system, 321 and in such cases, multiple instances of the Entity MIB 322 (representing the same managed objects) may be available to an NMS. 324 In order to reduce complexity for agent implementation, multiple 325 instances of the Entity MIB are not required to be equivalent or 326 even consistent. An NMS may be able to 'align' instances returned 327 by different agents by examining the columns of each table, but 328 vendor-specific identifiers and (especially) index values are 329 likely to be different. Each agent may be managing different 330 subsets of the entire chassis as well. 332 When all of a physically-modular device is represented by a single 333 agent, the entry for which entPhysicalContainedIn has the value 334 zero would likely have 'chassis' as the value of its 335 entPhysicalClass; alternatively, for an agent on a module where the 336 agent represents only the physical entities on that module (not 337 those on other modules), the entry for which entPhysicalContainedIn 338 has the value zero would likely have 'module' as the value of its 339 entPhysicalClass. 341 An agent implementation of the entLogicalTable is not required to 342 contain information about logical entities managed primarily by 343 other agents. That is, the entLogicalTAddress and entLogicalTDomain 344 objects in the entLogicalTable are provided to support an 345 historical multiplexing mechanism, not to identify other SNMP 346 agents. 348 Note that the Entity MIB is a single-scoped MIB, in the event an 349 agent represents the MIB in different naming scopes. 351 2.10. Re-Configuration of Entities 353 Most of the MIB objects defined in this MIB have at most a read- 354 only MAX-ACCESS clause. This is a conscious decision by the 355 working group to limit this MIB's scope. The second version of the 356 Entity MIB allows a network administrator to configure some common 357 attributes of physical components. 359 2.11. Textual Convention Change 361 Version 1 of the Entity MIB contains three MIB objects defined with 362 the (now obsolete) DisplayString textual convention. In version 2 363 of the Entity MIB, the syntax for these objects has been updated to 364 use the (now preferred) SnmpAdminString textual convention. 366 The working group realizes that this change is not strictly 367 supported by SMIv2. In our judgment, the alternative of 368 deprecating the old objects and defining new objects would have a 369 more adverse impact on backward compatibility and interoperability, 370 given the particular semantics of these objects. 372 2.12. MIB Structure 374 The Entity MIB contains five groups of MIB objects: 376 - entityPhysical group 377 Describes the physical entities managed by a single agent. 379 - entityLogical group 380 Describes the logical entities managed by a single agent. 382 - entityMapping group 383 Describes the associations between the physical entities, logical 384 entities, interfaces, and non-interface ports managed by a single 385 agent. 387 - entityGeneral group 388 Describes general system attributes shared by potentially all types 389 of entities managed by a single agent. 391 - entityNotifications group 392 Contains status indication notifications. 394 2.12.1. entityPhysical Group 396 This group contains a single table to identify physical system 397 components, called the entPhysicalTable. 399 The entPhysicalTable contains one row per physical entity, and must 400 always contain at least one row for an "overall" physical entity, 401 which should have an entPhysicalClass value of 'stack(11)', 402 'chassis(3)' or 'module(9)'. 404 Each row is indexed by an arbitrary, small integer, and contains a 405 description and type of the physical entity. It also optionally 406 contains the index number of another entPhysicalEntry indicating a 407 containment relationship between the two. 409 Version 2 of the Entity MIB provides additional MIB objects for 410 each physical entity. Some common read-only attributes have been 411 added, as well as three writable string objects. 413 - entPhysicalAlias 414 This string can be used by an NMS as a non-volatile identifier for 415 the physical component. Maintaining a non-volatile string for every 416 physical component represented in the entPhysicalTable can be 417 costly and unnecessary. An agent may algorithmically generate 418 'entPhysicalAlias' strings for particular entries (e.g., based on 419 the entPhysicalClass value). 421 - entPhysicalAssetID 422 This string is provided to store a user-specific asset identifier 423 for removable physical components. In order to reduce the non- 424 volatile storage needed by a particular agent, a network 425 administrator should only assign asset identifiers to physical 426 entities which are field-replaceable (i.e., not permanently 427 contained within another physical entity). 429 - entPhysicalSerialNum 430 This string is provided to store a vendor-specific serial number 431 string for physical components. This is a writable object in case 432 an agent cannot identify the serial numbers of all installed 433 physical entities, and a network administrator wishes to configure 434 the non-volatile serial number strings manually (via an NMS 435 application). 437 Version 3 of the Entity MIB provides two additional MIB objects for 438 each physical entity: 440 - entPhysicalMfgDate 441 This object contains the date of manufacturing of the managed 442 entity. If the manufacturing date is unknown or not supported the 443 object is not instantiated. 445 - entPhysicalUris 446 This object provides additional identification information about 447 the physical entity. 449 The object contains one or more Uniform Resource Identifiers (URIs) 450 and therefore the syntax of this object must conform to RFC 2396 451 [RFC2396] section 2. Uniform Resource Names (URNs), RFC 3406 452 [RFC3406], are resource identifiers with the specific requirements 453 for enabling location independent identification of a resource, as 454 well as longevity of reference. URNs are part of the larger URI 455 family with the specific goal of providing persistent naming of 456 resources. URI schemes and URN name spaces are registered by IANA 457 (see http://www.iana.org/assignments/uri-schemes and 458 http://www.iana.org/assignments/urn-namespaces). 460 The entPhysicalUris object may be used to encode for example a URI 461 containing a Common Language Equipment Identifier (CLEI) URI for 462 the managed physical entity. The URN name space for CLEIs is 463 defined in [RFC CLEIURN], and the CLEI format is defined in 464 [T1.213][T1.213a]. For example, an entPhysicalUris instance may 465 have the value of 467 URN:CLEI:D4CE18B7AA 469 [RFC2396] and [RFCCLEIURN] identify this as a URI in the CLEI URN 470 name space, and the specific CLEI code, D4CE18B7AA is based on the 471 example provided in [T1.213a]. 473 Multiple URIs may be present and are separated by white space 474 characters. Leading and trailing white space characters are 475 ignored. 477 If no additional identification information is known or supported 478 about the physical entity the object is not instantiated. 480 2.12.2. entityLogical Group 482 This group contains a single table to identify logical entities, 483 called the entLogicalTable. 485 The entLogicalTable contains one row per logical entity. Each row 486 is indexed by an arbitrary, small integer and contains a name, 487 description, and type of the logical entity. It also contains 488 information to allow access to the MIB information for the logical 489 entity. This includes SNMP versions that use a community name (with 490 some form of implied context representation) and SNMP versions that 491 use the SNMP ARCH [RFC3411] method of context identification. 493 If a agent represents multiple logical entities with this MIB, then 494 this group must be implemented for all logical entities known to 495 the agent. 497 If an agent represents a single logical entity, or multiple logical 498 entities within a single naming scope, then implementation of this 499 group may be omitted by the agent. 501 2.12.3. entityMapping Group 503 This group contains three tables to identify associations between 504 different system components. 506 The entLPMappingTable contains mappings between entLogicalIndex 507 values (logical entities) and entPhysicalIndex values (the physical 508 components supporting that entity). A logical entity can map to 509 more than one physical component, and more than one logical entity 510 can map to (share) the same physical component. If an agent 511 represents a single logical entity, or multiple logical entities 512 within a single naming scope, then implementation of this table may 513 be omitted by the agent. Note that this table is deprecated in 514 version 3 of the Entity MIB. 516 The entAliasMappingTable contains mappings between entLogicalIndex, 517 entPhysicalIndex pairs and 'alias' object identifier values. This 518 allows resources managed with other MIBs (e.g., repeater ports, 519 bridge ports, physical and logical interfaces) to be identified in 520 the physical entity hierarchy. Note that each alias identifier is 521 only relevant in a particular naming scope. If an agent represents 522 a single logical entity, or multiple logical entities within a 523 single naming scope, then implementation of this table may be 524 omitted by the agent. 526 The entPhysicalContainsTable contains simple mappings between 527 'entPhysicalContainedIn' values for each container/'containee' 528 relationship in the managed system. The indexing of this table 529 allows an NMS to quickly discover the 'entPhysicalIndex' values for 530 all children of a given physical entity. 532 2.12.4. entityGeneral Group 534 This group contains general information relating to the other 535 object groups. 537 At this time, the entGeneral group contains a single scalar object 538 (entLastChangeTime), which represents the value of sysUptime when 539 any part of the Entity MIB configuration last changed. 541 2.12.5. entityNotifications Group 543 This group contains notification definitions relating to the 544 overall status of the Entity MIB instantiation. 546 2.13. Multiple Agents 548 Even though a primary motivation for this MIB is to represent the 549 multiple logical entities supported by a single agent, it is also 550 possible to use it to represent multiple logical entities supported 551 by multiple agents (in the same "overall" physical entity). 552 Indeed, it is implicit in the SNMP architecture, that the number of 553 agents is transparent to a network management station. 555 However, there is no agreement at this time as to the degree of 556 cooperation which should be expected for agent implementations. 557 Therefore, multiple agents within the same managed system are free 558 to implement the Entity MIB independently. (Refer the section on 559 "Multiple Instances of the Entity MIB" for more details). 561 2.14. Changes Since RFC 2037 563 2.14.1. Textual Conventions 565 The PhysicalClass TC text has been clarified, and a new enumeration 566 to support 'stackable' components has been added. The 567 SnmpEngineIdOrNone TC has been added to support SNMPv3. 569 2.14.2. New entPhysicalTable Objects 571 The entPhysicalHardwareRev, entPhysicalFirmwareRev, and 572 entPhysicalSoftwareRev objects have been added for revision 573 identification. 575 The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, 576 and entPhysicalIsFru objects have been added for better vendor 577 identification for physical components. The entPhysicalSerialNum 578 object can be set by a management station in the event the agent 579 cannot identify this information. 581 The entPhysicalAlias and entPhysicalAssetID objects have been added 582 for better user component identification. These objects are 583 intended to be set by a management station and preserved by the 584 agent across restarts. 586 2.14.3. New entLogicalTable Objects 588 The entLogicalContextEngineID and entLogicalContextName objects 589 have been added to provide an SNMP context for SNMPv3 access on 590 behalf of a logical entity. 592 2.14.4. Bugfixes 594 A bug was fixed in the entLogicalCommunity object. The subrange was 595 incorrect (1..255) and is now (0..255). The description clause has 596 also been clarified. This object is now deprecated. 598 The entLastChangeTime object description has been changed to 599 generalize the events which cause an update to the last change 600 timestamp. 602 The syntax was changed from DisplayString to SnmpAdminString for 603 the entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. 605 2.15. Changes Since RFC 2737 607 2.15.1. Textual Conventions 609 The PhysicalIndexOrZero TC has been added to allow objects to 610 reference an entPhysicalIndex value or zero. The PhysicalClass TC 611 has been extended to support a new enumeration for central 612 processing units. 614 2.15.2. New Objects 616 The entPhysicalMfgDate object has been added to the 617 entPhysicalTable to provide the date of manufacturing of the 618 managed entity. 620 The entPhysicalUris object has been added to the entPhysicalTable 621 to provide additional identification information about the physical 622 entity, such as a Common Language Equipment Identifier (CLEI) URI. 624 2.15.3. Bugfixes 626 The syntax was changed from INTEGER to Integer32 for the 627 entPhysicalParentRelPos, entLogicalIndex, and 628 entAliasLogicalIndexOrZero objects, and from INTEGER to 629 PhysicalIndexOrZero for the entPhysicalContainedIn object. 631 3. Definitions 633 ENTITY-MIB DEFINITIONS ::= BEGIN 635 IMPORTS 636 MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, 637 Integer32 638 FROM SNMPv2-SMI 639 TDomain, TAddress, TEXTUAL-CONVENTION, 640 AutonomousType, RowPointer, TimeStamp, TruthValue, 641 DateAndTime 642 FROM SNMPv2-TC 643 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 644 FROM SNMPv2-CONF 645 SnmpAdminString 646 FROM SNMP-FRAMEWORK-MIB; 648 entityMIB MODULE-IDENTITY 649 LAST-UPDATED "200501070000Z" 650 ORGANIZATION "IETF ENTMIB Working Group" 651 CONTACT-INFO 652 " WG E-mail: entmib@ietf.org 653 Mailing list subscription info: 654 http://www.ietf.org/mailman/listinfo/entmib 656 Andy Bierman 657 Cisco Systems Inc. 658 170 West Tasman Drive 659 San Jose, CA 95134 660 +1 408-527-3711 661 abierman@cisco.com 663 Keith McCloghrie 664 Cisco Systems Inc. 665 170 West Tasman Drive 666 San Jose, CA 95134 667 +1 408-526-5260 668 kzm@cisco.com" 670 DESCRIPTION 671 "The MIB module for representing multiple logical 672 entities supported by a single SNMP agent. 674 Copyright (C) The Internet Society (2005). This 675 version of this MIB module is part of RFC xxxx; see 676 the RFC itself for full legal notices." 677 -- RFC Ed.: replace xxxx with actual RFC number & remove this notice 679 REVISION "200501070000Z" 680 DESCRIPTION 681 "Initial Version of Entity MIB (Version 3). 682 This revision obsoletes RFC 2737. 683 Additions: 684 - cpu(12) enumeration added to PhysicalClass TC 685 - PhysicalIndexOrZero TC 686 - entPhysicalMfgDate object 687 - entPhysicalUris object 688 Changes: 689 - entPhysicalContainedIn SYNTAX changed from 690 INTEGER to PhysicalIndexOrZero 692 This version published as RFC xxxx." 693 -- RFC Ed.: replace xxxx with actual RFC number & remove this notice 695 REVISION "199912070000Z" 696 DESCRIPTION 697 "Initial Version of Entity MIB (Version 2). 698 This revision obsoletes RFC 2037. 699 This version published as RFC 2737." 701 REVISION "199610310000Z" 702 DESCRIPTION 703 "Initial version (version 1), published as 704 RFC 2037." 705 ::= { mib-2 47 } 707 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 709 -- MIB contains four groups 710 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } 711 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } 712 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } 713 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } 715 -- Textual Conventions 716 PhysicalIndex ::= TEXTUAL-CONVENTION 717 STATUS current 718 DESCRIPTION 719 "An arbitrary value which uniquely identifies the physical 720 entity. The value should be a small positive integer; index 721 values for different physical entities are not necessarily 722 contiguous." 723 SYNTAX Integer32 (1..2147483647) 725 PhysicalIndexOrZero ::= TEXTUAL-CONVENTION 726 STATUS current 727 DESCRIPTION 728 "This textual convention is an extension of the 729 PhysicalIndex convention which defines a greater than zero 730 value used to identify a physical entity. This extension 731 permits the additional value of zero. The semantics of the 732 value zero are object-specific and must therefore be defined 733 as part of the description of any object which uses this 734 syntax. Examples of the usage of this extension are 735 situations where none or all physical entities need to be 736 referenced." 737 SYNTAX Integer32 (0..2147483647) 739 PhysicalClass ::= TEXTUAL-CONVENTION 740 STATUS current 741 DESCRIPTION 742 "An enumerated value which provides an indication of the 743 general hardware type of a particular physical entity. 744 There are no restrictions as to the number of 745 entPhysicalEntries of each entPhysicalClass, which must be 746 instantiated by an agent. 748 The enumeration 'other' is applicable if the physical entity 749 class is known, but does not match any of the supported 750 values. 752 The enumeration 'unknown' is applicable if the physical 753 entity class is unknown to the agent. 755 The enumeration 'chassis' is applicable if the physical 756 entity class is an overall container for networking 757 equipment. Any class of physical entity except a stack may 758 be contained within a chassis, and a chassis may only be 759 contained within a stack. 761 The enumeration 'backplane' is applicable if the physical 762 entity class is some sort of device for aggregating and 763 forwarding networking traffic, such as a shared backplane in 764 a modular ethernet switch. Note that an agent may model a 765 backplane as a single physical entity, which is actually 766 implemented as multiple discrete physical components (within 767 a chassis or stack). 769 The enumeration 'container' is applicable if the physical 770 entity class is capable of containing one or more removable 771 physical entities, possibly of different types. For example, 772 each (empty or full) slot in a chassis will be modeled as a 773 container. Note that all removable physical entities should 774 be modeled within a container entity, such as field- 775 replaceable modules, fans, or power supplies. Note that all 776 known containers should be modeled by the agent, including 777 empty containers. 779 The enumeration 'powerSupply' is applicable if the physical 780 entity class is a power-supplying component. 782 The enumeration 'fan' is applicable if the physical entity 783 class is a fan or other heat-reduction component. 785 The enumeration 'sensor' is applicable if the physical 786 entity class is some sort of sensor, such as a temperature 787 sensor within a router chassis. 789 The enumeration 'module' is applicable if the physical 790 entity class is some sort of self-contained sub-system. If 791 it is removable, then it should be modeled within a 792 container entity, otherwise it should be modeled directly 793 within another physical entity (e.g., a chassis or another 794 module). 796 The enumeration 'port' is applicable if the physical entity 797 class is some sort of networking port, capable of receiving 798 and/or transmitting networking traffic. 800 The enumeration 'stack' is applicable if the physical entity 801 class is some sort of super-container (possibly virtual), 802 intended to group together multiple chassis entities. A 803 stack may be realized by a 'virtual' cable, a real 804 interconnect cable, attached to multiple chassis, or may in 805 fact be comprised of multiple interconnect cables. A stack 806 should not be modeled within any other physical entities, 807 but a stack may be contained within another stack. Only 808 chassis entities should be contained within a stack. 810 The enumeration 'cpu' is applicable if the physical entity 811 class is some sort of central processing unit." 812 SYNTAX INTEGER { 813 other(1), 814 unknown(2), 815 chassis(3), 816 backplane(4), 817 container(5), -- e.g., chassis slot or daughter-card holder 818 powerSupply(6), 819 fan(7), 820 sensor(8), 821 module(9), -- e.g., plug-in card or daughter-card 822 port(10), 823 stack(11), -- e.g., stack of multiple chassis entities 824 cpu(12) 825 } 827 SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION 828 STATUS current 829 DESCRIPTION 830 "A specially formatted SnmpEngineID string for use with the 831 Entity MIB. 833 If an instance of an object of SYNTAX SnmpEngineIdOrNone has 834 a non-zero length, then the object encoding and semantics 835 are defined by the SnmpEngineID textual convention (see STD 836 62, RFC 3411 [RFC3411]). 838 If an instance of an object of SYNTAX SnmpEngineIdOrNone 839 contains a zero-length string, then no appropriate 840 SnmpEngineID is associated with the logical entity (i.e., 841 SNMPv3 not supported)." 842 SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID 844 -- The Physical Entity Table 845 entPhysicalTable OBJECT-TYPE 846 SYNTAX SEQUENCE OF EntPhysicalEntry 847 MAX-ACCESS not-accessible 848 STATUS current 849 DESCRIPTION 850 "This table contains one row per physical entity. There is 851 always at least one row for an 'overall' physical entity." 852 ::= { entityPhysical 1 } 854 entPhysicalEntry OBJECT-TYPE 855 SYNTAX EntPhysicalEntry 856 MAX-ACCESS not-accessible 857 STATUS current 858 DESCRIPTION 859 "Information about a particular physical entity. 861 Each entry provides objects (entPhysicalDescr, 862 entPhysicalVendorType, and entPhysicalClass) to help an NMS 863 identify and characterize the entry, and objects 864 (entPhysicalContainedIn and entPhysicalParentRelPos) to help 865 an NMS relate the particular entry to other entries in this 866 table." 867 INDEX { entPhysicalIndex } 868 ::= { entPhysicalTable 1 } 870 EntPhysicalEntry ::= SEQUENCE { 871 entPhysicalIndex PhysicalIndex, 872 entPhysicalDescr SnmpAdminString, 873 entPhysicalVendorType AutonomousType, 874 entPhysicalContainedIn PhysicalIndexOrZero, 875 entPhysicalClass PhysicalClass, 876 entPhysicalParentRelPos Integer32, 877 entPhysicalName SnmpAdminString, 878 entPhysicalHardwareRev SnmpAdminString, 879 entPhysicalFirmwareRev SnmpAdminString, 880 entPhysicalSoftwareRev SnmpAdminString, 881 entPhysicalSerialNum SnmpAdminString, 882 entPhysicalMfgName SnmpAdminString, 883 entPhysicalModelName SnmpAdminString, 884 entPhysicalAlias SnmpAdminString, 885 entPhysicalAssetID SnmpAdminString, 886 entPhysicalIsFRU TruthValue, 887 entPhysicalMfgDate DateAndTime, 888 entPhysicalUris OCTET STRING 890 } 892 entPhysicalIndex OBJECT-TYPE 893 SYNTAX PhysicalIndex 894 MAX-ACCESS not-accessible 895 STATUS current 896 DESCRIPTION 897 "The index for this entry." 898 ::= { entPhysicalEntry 1 } 900 entPhysicalDescr OBJECT-TYPE 901 SYNTAX SnmpAdminString 902 MAX-ACCESS read-only 903 STATUS current 904 DESCRIPTION 905 "A textual description of physical entity. This object 906 should contain a string which identifies the manufacturer's 907 name for the physical entity, and should be set to a 908 distinct value for each version or model of the physical 909 entity. " 910 ::= { entPhysicalEntry 2 } 912 entPhysicalVendorType OBJECT-TYPE 913 SYNTAX AutonomousType 914 MAX-ACCESS read-only 915 STATUS current 916 DESCRIPTION 917 "An indication of the vendor-specific hardware type of the 918 physical entity. Note that this is different from the 919 definition of MIB-II's sysObjectID. 921 An agent should set this object to a enterprise-specific 922 registration identifier value indicating the specific 923 equipment type in detail. The associated instance of 924 entPhysicalClass is used to indicate the general type of 925 hardware device. 927 If no vendor-specific registration identifier exists for 928 this physical entity, or the value is unknown by this agent, 929 then the value { 0 0 } is returned." 930 ::= { entPhysicalEntry 3 } 932 entPhysicalContainedIn OBJECT-TYPE 933 SYNTAX PhysicalIndexOrZero 934 MAX-ACCESS read-only 935 STATUS current 936 DESCRIPTION 937 "The value of entPhysicalIndex for the physical entity which 938 'contains' this physical entity. A value of zero indicates 939 this physical entity is not contained in any other physical 940 entity. Note that the set of 'containment' relationships 941 define a strict hierarchy; that is, recursion is not 942 allowed. 944 In the event a physical entity is contained by more than one 945 physical entity (e.g., double-wide modules), this object 946 should identify the containing entity with the lowest value 947 of entPhysicalIndex." 948 ::= { entPhysicalEntry 4 } 950 entPhysicalClass OBJECT-TYPE 951 SYNTAX PhysicalClass 952 MAX-ACCESS read-only 953 STATUS current 954 DESCRIPTION 955 "An indication of the general hardware type of the physical 956 entity. 958 An agent should set this object to the standard enumeration 959 value which most accurately indicates the general class of 960 the physical entity, or the primary class if there is more 961 than one. 963 If no appropriate standard registration identifier exists 964 for this physical entity, then the value 'other(1)' is 965 returned. If the value is unknown by this agent, then the 966 value 'unknown(2)' is returned." 967 ::= { entPhysicalEntry 5 } 969 entPhysicalParentRelPos OBJECT-TYPE 970 SYNTAX Integer32 (-1..2147483647) 971 MAX-ACCESS read-only 972 STATUS current 973 DESCRIPTION 974 "An indication of the relative position of this 'child' 975 component among all its 'sibling' components. Sibling 976 components are defined as entPhysicalEntries which share the 977 same instance values of each of the entPhysicalContainedIn 978 and entPhysicalClass objects. 980 An NMS can use this object to identify the relative ordering 981 for all sibling components of a particular parent 982 (identified by the entPhysicalContainedIn instance in each 983 sibling entry). 985 This value should match any external labeling of the 986 physical component if possible. For example, for a container 987 (e.g., card slot) labeled as 'slot #3', 988 entPhysicalParentRelPos should have the value '3'. Note 989 that the entPhysicalEntry for the module plugged in slot 3 990 should have an entPhysicalParentRelPos value of '1'. 992 If the physical position of this component does not match 993 any external numbering or clearly visible ordering, then 994 user documentation or other external reference material 995 should be used to determine the parent-relative position. If 996 this is not possible, then the the agent should assign a 997 consistent (but possibly arbitrary) ordering to a given set 998 of 'sibling' components, perhaps based on internal 999 representation of the components. 1001 If the agent cannot determine the parent-relative position 1002 for some reason, or if the associated value of 1003 entPhysicalContainedIn is '0', then the value '-1' is 1004 returned. Otherwise a non-negative integer is returned, 1005 indicating the parent-relative position of this physical 1006 entity. 1008 Parent-relative ordering normally starts from '1' and 1009 continues to 'N', where 'N' represents the highest 1010 positioned child entity. However, if the physical entities 1011 (e.g., slots) are labeled from a starting position of zero, 1012 then the first sibling should be associated with a 1013 entPhysicalParentRelPos value of '0'. Note that this 1014 ordering may be sparse or dense, depending on agent 1015 implementation. 1017 The actual values returned are not globally meaningful, as 1018 each 'parent' component may use different numbering 1019 algorithms. The ordering is only meaningful among siblings 1020 of the same parent component. 1022 The agent should retain parent-relative position values 1023 across reboots, either through algorithmic assignment or use 1024 of non-volatile storage." 1025 ::= { entPhysicalEntry 6 } 1027 entPhysicalName OBJECT-TYPE 1028 SYNTAX SnmpAdminString 1029 MAX-ACCESS read-only 1030 STATUS current 1031 DESCRIPTION 1032 "The textual name of the physical entity. The value of this 1033 object should be the name of the component as assigned by 1034 the local device and should be suitable for use in commands 1035 entered at the device's `console'. This might be a text 1036 name, such as `console' or a simple component number (e.g., 1037 port or module number), such as `1', depending on the 1038 physical component naming syntax of the device. 1040 If there is no local name, or this object is otherwise not 1041 applicable, then this object contains a zero-length string. 1043 Note that the value of entPhysicalName for two physical 1044 entities will be the same in the event that the console 1045 interface does not distinguish between them, e.g., slot-1 1046 and the card in slot-1." 1047 ::= { entPhysicalEntry 7 } 1049 entPhysicalHardwareRev OBJECT-TYPE 1050 SYNTAX SnmpAdminString 1051 MAX-ACCESS read-only 1052 STATUS current 1053 DESCRIPTION 1054 "The vendor-specific hardware revision string for the 1055 physical entity. The preferred value is the hardware 1056 revision identifier actually printed on the component itself 1057 (if present). 1059 Note that if revision information is stored internally in a 1060 non-printable (e.g., binary) format, then the agent must 1061 convert such information to a printable format, in an 1062 implementation-specific manner. 1064 If no specific hardware revision string is associated with 1065 the physical component, or this information is unknown to 1066 the agent, then this object will contain a zero-length 1067 string." 1068 ::= { entPhysicalEntry 8 } 1070 entPhysicalFirmwareRev OBJECT-TYPE 1071 SYNTAX SnmpAdminString 1072 MAX-ACCESS read-only 1073 STATUS current 1074 DESCRIPTION 1075 "The vendor-specific firmware revision string for the 1076 physical entity. 1078 Note that if revision information is stored internally in a 1079 non-printable (e.g., binary) format, then the agent must 1080 convert such information to a printable format, in an 1081 implementation-specific manner. 1083 If no specific firmware programs are associated with the 1084 physical component, or this information is unknown to the 1085 agent, then this object will contain a zero-length string." 1086 ::= { entPhysicalEntry 9 } 1088 entPhysicalSoftwareRev OBJECT-TYPE 1089 SYNTAX SnmpAdminString 1090 MAX-ACCESS read-only 1091 STATUS current 1092 DESCRIPTION 1093 "The vendor-specific software revision string for the 1094 physical entity. 1096 Note that if revision information is stored internally in a 1097 non-printable (e.g., binary) format, then the agent must 1098 convert such information to a printable format, in an 1099 implementation-specific manner. 1101 If no specific software programs are associated with the 1102 physical component, or this information is unknown to the 1103 agent, then this object will contain a zero-length string." 1104 ::= { entPhysicalEntry 10 } 1106 entPhysicalSerialNum OBJECT-TYPE 1107 SYNTAX SnmpAdminString (SIZE (0..32)) 1108 MAX-ACCESS read-write 1109 STATUS current 1110 DESCRIPTION 1111 "The vendor-specific serial number string for the physical 1112 entity. The preferred value is the serial number string 1113 actually printed on the component itself (if present). 1115 On the first instantiation of an physical entity, the value 1116 of entPhysicalSerialNum associated with that entity is set 1117 to the correct vendor-assigned serial number, if this 1118 information is available to the agent. If a serial number 1119 is unknown or non-existent, the entPhysicalSerialNum will be 1120 set to a zero-length string instead. 1122 Note that implementations which can correctly identify the 1123 serial numbers of all installed physical entities do not 1124 need to provide write access to the entPhysicalSerialNum 1125 object. Agents which cannot provide non-volatile storage for 1126 the entPhysicalSerialNum strings are not required to 1127 implement write access for this object. 1129 Not every physical component will have a serial number, or 1130 even need one. Physical entities for which the associated 1131 value of the entPhysicalIsFRU object is equal to 'false(2)' 1132 (e.g., the repeater ports within a repeater module), do not 1133 need their own unique serial number. An agent does not have 1134 to provide write access for such entities, and may return a 1135 zero-length string. 1137 If write access is implemented for an instance of 1138 entPhysicalSerialNum, and a value is written into the 1139 instance, the agent must retain the supplied value in the 1140 entPhysicalSerialNum instance associated with the same 1141 physical entity for as long as that entity remains 1142 instantiated. This includes instantiations across all re- 1143 initializations/reboots of the network management system, 1144 including those which result in a change of the physical 1145 entity's entPhysicalIndex value." 1146 ::= { entPhysicalEntry 11 } 1148 entPhysicalMfgName OBJECT-TYPE 1149 SYNTAX SnmpAdminString 1150 MAX-ACCESS read-only 1151 STATUS current 1152 DESCRIPTION 1153 "The name of the manufacturer of this physical component. 1154 The preferred value is the manufacturer name string actually 1155 printed on the component itself (if present). 1157 Note that comparisons between instances of the 1158 entPhysicalModelName, entPhysicalFirmwareRev, 1159 entPhysicalSoftwareRev, and the entPhysicalSerialNum 1160 objects, are only meaningful amongst entPhysicalEntries with 1161 the same value of entPhysicalMfgName. 1163 If the manufacturer name string associated with the physical 1164 component is unknown to the agent, then this object will 1165 contain a zero-length string." 1166 ::= { entPhysicalEntry 12 } 1168 entPhysicalModelName OBJECT-TYPE 1169 SYNTAX SnmpAdminString 1170 MAX-ACCESS read-only 1171 STATUS current 1172 DESCRIPTION 1173 "The vendor-specific model name identifier string associated 1174 with this physical component. The preferred value is the 1175 customer-visible part number, which may be printed on the 1176 component itself. 1178 If the model name string associated with the physical 1179 component is unknown to the agent, then this object will 1180 contain a zero-length string." 1181 ::= { entPhysicalEntry 13 } 1183 entPhysicalAlias OBJECT-TYPE 1184 SYNTAX SnmpAdminString (SIZE (0..32)) 1185 MAX-ACCESS read-write 1186 STATUS current 1187 DESCRIPTION 1188 "This object is an 'alias' name for the physical entity as 1189 specified by a network manager, and provides a non-volatile 1190 'handle' for the physical entity. 1192 On the first instantiation of an physical entity, the value 1193 of entPhysicalAlias associated with that entity is set to 1194 the zero-length string. However, agent may set the value to 1195 a locally unique default value, instead of a zero-length 1196 string. 1198 If write access is implemented for an instance of 1199 entPhysicalAlias, and a value is written into the instance, 1200 the agent must retain the supplied value in the 1201 entPhysicalAlias instance associated with the same physical 1202 entity for as long as that entity remains instantiated. 1203 This includes instantiations across all re- 1204 initializations/reboots of the network management system, 1205 including those which result in a change of the physical 1206 entity's entPhysicalIndex value." 1207 ::= { entPhysicalEntry 14 } 1209 entPhysicalAssetID OBJECT-TYPE 1210 SYNTAX SnmpAdminString (SIZE (0..32)) 1211 MAX-ACCESS read-write 1212 STATUS current 1213 DESCRIPTION 1214 "This object is a user-assigned asset tracking identifier 1215 for the physical entity as specified by a network manager, 1216 and provides non-volatile storage of this information. 1218 On the first instantiation of an physical entity, the value 1219 of entPhysicalAssetID associated with that entity is set to 1220 the zero-length string. 1222 Not every physical component will have a asset tracking 1223 identifier, or even need one. Physical entities for which 1224 the associated value of the entPhysicalIsFRU object is equal 1225 to 'false(2)' (e.g., the repeater ports within a repeater 1226 module), do not need their own unique asset tracking 1227 identifier. An agent does not have to provide write access 1228 for such entities, and may instead return a zero-length 1229 string. 1231 If write access is implemented for an instance of 1232 entPhysicalAssetID, and a value is written into the 1233 instance, the agent must retain the supplied value in the 1234 entPhysicalAssetID instance associated with the same 1235 physical entity for as long as that entity remains 1236 instantiated. This includes instantiations across all re- 1237 initializations/reboots of the network management system, 1238 including those which result in a change of the physical 1239 entity's entPhysicalIndex value. 1241 If no asset tracking information is associated with the 1242 physical component, then this object will contain a zero- 1243 length string." 1244 ::= { entPhysicalEntry 15 } 1246 entPhysicalIsFRU OBJECT-TYPE 1247 SYNTAX TruthValue 1248 MAX-ACCESS read-only 1249 STATUS current 1250 DESCRIPTION 1251 "This object indicates whether or not this physical entity 1252 is considered a 'field replaceable unit' by the vendor. If 1253 this object contains the value 'true(1)' then this 1254 entPhysicalEntry identifies a field replaceable unit. For 1255 all entPhysicalEntries which represent components that are 1256 permanently contained within a field replaceable unit, the 1257 value 'false(2)' should be returned for this object." 1258 ::= { entPhysicalEntry 16 } 1260 entPhysicalMfgDate OBJECT-TYPE 1261 SYNTAX DateAndTime 1262 MAX-ACCESS read-only 1263 STATUS current 1264 DESCRIPTION 1265 "The manufacturing date for the physical entity. The value 1266 '0000000000000000'H is returned if the manufacturing date of 1267 the entity in unknown." 1268 ::= { entPhysicalEntry 17 } 1270 entPhysicalUris OBJECT-TYPE 1271 SYNTAX OCTET STRING 1272 MAX-ACCESS read-write 1273 STATUS current 1274 DESCRIPTION 1275 "This object contains additional identification information 1276 about the physical entity. The object contains URIs and 1277 therefore the syntax of this object must conform to RFC 1278 2396, section 2. 1280 Multiple URIs may be present and are separated by white 1281 space characters. Leading and trailing white space 1282 characters are ignored. 1284 If no additional identification information is known or 1285 supported about the physical entity the object is not 1286 instantiated. A zero length octet string may also be 1287 returned in this case." 1288 REFERENCE 1289 "RFC 2396, Uniform Resource Identifiers (URI): Generic 1290 Syntax, section 2, August 1998." 1292 ::= { entPhysicalEntry 18 } 1294 -- The Logical Entity Table 1295 entLogicalTable OBJECT-TYPE 1296 SYNTAX SEQUENCE OF EntLogicalEntry 1297 MAX-ACCESS not-accessible 1298 STATUS current 1299 DESCRIPTION 1300 "This table contains one row per logical entity. For agents 1301 which implement more than one naming scope, at least one 1302 entry must exist. Agents which instantiate all MIB objects 1303 within a single naming scope are not required to implement 1304 this table." 1305 ::= { entityLogical 1 } 1307 entLogicalEntry OBJECT-TYPE 1308 SYNTAX EntLogicalEntry 1309 MAX-ACCESS not-accessible 1310 STATUS current 1311 DESCRIPTION 1312 "Information about a particular logical entity. Entities 1313 may be managed by this agent or other SNMP agents (possibly) 1314 in the same chassis." 1315 INDEX { entLogicalIndex } 1316 ::= { entLogicalTable 1 } 1318 EntLogicalEntry ::= SEQUENCE { 1319 entLogicalIndex Integer32, 1320 entLogicalDescr SnmpAdminString, 1321 entLogicalType AutonomousType, 1322 entLogicalCommunity OCTET STRING, 1323 entLogicalTAddress TAddress, 1324 entLogicalTDomain TDomain, 1325 entLogicalContextEngineID SnmpEngineIdOrNone, 1326 entLogicalContextName SnmpAdminString 1327 } 1329 entLogicalIndex OBJECT-TYPE 1330 SYNTAX Integer32 (1..2147483647) 1331 MAX-ACCESS not-accessible 1332 STATUS current 1333 DESCRIPTION 1334 "The value of this object uniquely identifies the logical 1335 entity. The value should be a small positive integer; index 1336 values for different logical entities are are not 1337 necessarily contiguous." 1338 ::= { entLogicalEntry 1 } 1340 entLogicalDescr OBJECT-TYPE 1341 SYNTAX SnmpAdminString 1342 MAX-ACCESS read-only 1343 STATUS current 1344 DESCRIPTION 1345 "A textual description of the logical entity. This object 1346 should contain a string which identifies the manufacturer's 1347 name for the logical entity, and should be set to a distinct 1348 value for each version of the logical entity. " 1350 ::= { entLogicalEntry 2 } 1352 entLogicalType OBJECT-TYPE 1353 SYNTAX AutonomousType 1354 MAX-ACCESS read-only 1355 STATUS current 1356 DESCRIPTION 1357 "An indication of the type of logical entity. This will 1358 typically be the OBJECT IDENTIFIER name of the node in the 1359 SMI's naming hierarchy which represents the major MIB 1360 module, or the majority of the MIB modules, supported by the 1361 logical entity. For example: 1362 a logical entity of a regular host/router -> mib-2 1363 a logical entity of a 802.1d bridge -> dot1dBridge 1364 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 1365 If an appropriate node in the SMI's naming hierarchy cannot 1366 be identified, the value 'mib-2' should be used." 1367 ::= { entLogicalEntry 3 } 1369 entLogicalCommunity OBJECT-TYPE 1370 SYNTAX OCTET STRING (SIZE (0..255)) 1371 MAX-ACCESS read-only 1372 STATUS deprecated 1373 DESCRIPTION 1374 "An SNMPv1 or SNMPv2C community-string which can be used to 1375 access detailed management information for this logical 1376 entity. The agent should allow read access with this 1377 community string (to an appropriate subset of all managed 1378 objects) and may also return a community string based on the 1379 privileges of the request used to read this object. Note 1380 that an agent may return a community string with read-only 1381 privileges, even if this object is accessed with a read- 1382 write community string. However, the agent must take care 1383 not to return a community string which allows more 1384 privileges than the community string used to access this 1385 object. 1387 A compliant SNMP agent may wish to conserve naming scopes by 1388 representing multiple logical entities in a single 'default' 1389 naming scope. This is possible when the logical entities 1390 represented by the same value of entLogicalCommunity have no 1391 object instances in common. For example, 'bridge1' and 1392 'repeater1' may be part of the main naming scope, but at 1393 least one additional community string is needed to represent 1394 'bridge2' and 'repeater2'. 1396 Logical entities 'bridge1' and 'repeater1' would be 1397 represented by sysOREntries associated with the 'default' 1398 naming scope. 1400 For agents not accessible via SNMPv1 or SNMPv2C, the value 1401 of this object is the empty string. This object may also 1402 contain an empty string if a community string has not yet 1403 been assigned by the agent, or no community string with 1404 suitable access rights can be returned for a particular SNMP 1405 request. 1407 Note that this object is deprecated. Agents which implement 1408 SNMPv3 access should use the entLogicalContextEngineID and 1409 entLogicalContextName objects to identify the context 1410 associated with each logical entity. SNMPv3 agents may 1411 return a zero-length string for this object, or may continue 1412 to return a community string (e.g., tri-lingual agent 1413 support)." 1414 ::= { entLogicalEntry 4 } 1416 entLogicalTAddress OBJECT-TYPE 1417 SYNTAX TAddress 1418 MAX-ACCESS read-only 1419 STATUS current 1420 DESCRIPTION 1421 "The transport service address by which the logical entity 1422 receives network management traffic, formatted according to 1423 the corresponding value of entLogicalTDomain. 1425 For snmpUDPDomain, a TAddress is 6 octets long, the initial 1426 4 octets containing the IP-address in network-byte order and 1427 the last 2 containing the UDP port in network-byte order. 1428 Consult 'Transport Mappings for the Simple Network 1429 Management Protocol' (STD 62, RFC 3417 [RFC3417]) for 1430 further information on snmpUDPDomain." 1431 ::= { entLogicalEntry 5 } 1433 entLogicalTDomain OBJECT-TYPE 1434 SYNTAX TDomain 1435 MAX-ACCESS read-only 1436 STATUS current 1437 DESCRIPTION 1438 "Indicates the kind of transport service by which the 1439 logical entity receives network management traffic. 1440 Possible values for this object are presently found in the 1441 Transport Mappings for Simple Network Management Protocol' 1442 (STD 62, RFC 3417 [RFC3417])." 1443 ::= { entLogicalEntry 6 } 1445 entLogicalContextEngineID OBJECT-TYPE 1446 SYNTAX SnmpEngineIdOrNone 1447 MAX-ACCESS read-only 1448 STATUS current 1449 DESCRIPTION 1450 "The authoritative contextEngineID that can be used to send 1451 an SNMP message concerning information held by this logical 1452 entity, to the address specified by the associated 1453 'entLogicalTAddress/entLogicalTDomain' pair. 1455 This object, together with the associated 1456 entLogicalContextName object, defines the context associated 1457 with a particular logical entity, and allows access to SNMP 1458 engines identified by a contextEngineId and contextName 1459 pair. 1461 If no value has been configured by the agent, a zero-length 1462 string is returned, or the agent may choose not to 1463 instantiate this object at all." 1464 ::= { entLogicalEntry 7 } 1466 entLogicalContextName OBJECT-TYPE 1467 SYNTAX SnmpAdminString 1468 MAX-ACCESS read-only 1469 STATUS current 1470 DESCRIPTION 1471 "The contextName that can be used to send an SNMP message 1472 concerning information held by this logical entity, to the 1473 address specified by the associated 1474 'entLogicalTAddress/entLogicalTDomain' pair. 1476 This object, together with the associated 1477 entLogicalContextEngineID object, defines the context 1478 associated with a particular logical entity, and allows 1479 access to SNMP engines identified by a contextEngineId and 1480 contextName pair. 1482 If no value has been configured by the agent, a zero-length 1483 string is returned, or the agent may choose not to 1484 instantiate this object at all." 1485 ::= { entLogicalEntry 8 } 1487 entLPMappingTable OBJECT-TYPE 1488 SYNTAX SEQUENCE OF EntLPMappingEntry 1489 MAX-ACCESS not-accessible 1490 STATUS current 1491 DESCRIPTION 1492 "This table contains zero or more rows of logical entity to 1493 physical equipment associations. For each logical entity 1494 known by this agent, there are zero or more mappings to the 1495 physical resources which are used to realize that logical 1496 entity. 1498 An agent should limit the number and nature of entries in 1499 this table such that only meaningful and non-redundant 1500 information is returned. For example, in a system which 1501 contains a single power supply, mappings between logical 1502 entities and the power supply are not useful and should not 1503 be included. 1505 Also, only the most appropriate physical component which is 1506 closest to the root of a particular containment tree should 1507 be identified in an entLPMapping entry. 1509 For example, suppose a bridge is realized on a particular 1510 module, and all ports on that module are ports on this 1511 bridge. A mapping between the bridge and the module would be 1512 useful, but additional mappings between the bridge and each 1513 of the ports on that module would be redundant (since the 1514 entPhysicalContainedIn hierarchy can provide the same 1515 information). If, on the other hand, more than one bridge 1516 was utilizing ports on this module, then mappings between 1517 each bridge and the ports it used would be appropriate. 1519 Also, in the case of a single backplane repeater, a mapping 1520 for the backplane to the single repeater entity is not 1521 necessary." 1522 ::= { entityMapping 1 } 1524 entLPMappingEntry OBJECT-TYPE 1525 SYNTAX EntLPMappingEntry 1526 MAX-ACCESS not-accessible 1527 STATUS current 1528 DESCRIPTION 1529 "Information about a particular logical entity to physical 1530 equipment association. Note that the nature of the 1531 association is not specifically identified in this entry. 1533 It is expected that sufficient information exists in the 1534 MIBs used to manage a particular logical entity to infer how 1535 physical component information is utilized." 1536 INDEX { entLogicalIndex, entLPPhysicalIndex } 1537 ::= { entLPMappingTable 1 } 1539 EntLPMappingEntry ::= SEQUENCE { 1540 entLPPhysicalIndex PhysicalIndex 1541 } 1543 entLPPhysicalIndex OBJECT-TYPE 1544 SYNTAX PhysicalIndex 1545 MAX-ACCESS read-only 1546 STATUS current 1547 DESCRIPTION 1548 "The value of this object identifies the index value of a 1549 particular entPhysicalEntry associated with the indicated 1550 entLogicalEntity." 1551 ::= { entLPMappingEntry 1 } 1553 -- logical entity/component to alias table 1554 entAliasMappingTable OBJECT-TYPE 1555 SYNTAX SEQUENCE OF EntAliasMappingEntry 1556 MAX-ACCESS not-accessible 1557 STATUS current 1558 DESCRIPTION 1559 "This table contains zero or more rows, representing 1560 mappings of logical entity and physical component to 1561 external MIB identifiers. Each physical port in the system 1562 may be associated with a mapping to an external identifier, 1563 which itself is associated with a particular logical 1564 entity's naming scope. A 'wildcard' mechanism is provided 1565 to indicate that an identifier is associated with more than 1566 one logical entity." 1567 ::= { entityMapping 2 } 1569 entAliasMappingEntry OBJECT-TYPE 1570 SYNTAX EntAliasMappingEntry 1571 MAX-ACCESS not-accessible 1572 STATUS current 1573 DESCRIPTION 1574 "Information about a particular physical equipment, logical 1575 entity to external identifier binding. Each logical 1576 entity/physical component pair may be associated with one 1577 alias mapping. The logical entity index may also be used as 1578 a 'wildcard' (refer to the entAliasLogicalIndexOrZero object 1579 DESCRIPTION clause for details.) 1581 Note that only entPhysicalIndex values which represent 1582 physical ports (i.e. associated entPhysicalClass value is 1583 'port(10)') are permitted to exist in this table." 1584 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 1585 ::= { entAliasMappingTable 1 } 1587 EntAliasMappingEntry ::= SEQUENCE { 1588 entAliasLogicalIndexOrZero Integer32, 1589 entAliasMappingIdentifier RowPointer 1590 } 1592 entAliasLogicalIndexOrZero OBJECT-TYPE 1593 SYNTAX Integer32 (0..2147483647) 1594 MAX-ACCESS not-accessible 1595 STATUS current 1596 DESCRIPTION 1597 "The value of this object identifies the logical entity 1598 which defines the naming scope for the associated instance 1599 of the 'entAliasMappingIdentifier' object. 1601 If this object has a non-zero value, then it identifies the 1602 logical entity named by the same value of entLogicalIndex. 1604 If this object has a value of zero, then the mapping between 1605 the physical component and the alias identifier for this 1606 entAliasMapping entry is associated with all unspecified 1607 logical entities. That is, a value of zero (the default 1608 mapping) identifies any logical entity which does not have 1609 an explicit entry in this table for a particular 1610 entPhysicalIndex/entAliasMappingIdentifier pair. 1612 For example, to indicate that a particular interface (e.g., 1613 physical component 33) is identified by the same value of 1614 ifIndex for all logical entities, the following instance 1615 might exist: 1617 entAliasMappingIdentifier.33.0 = ifIndex.5 1619 In the event an entPhysicalEntry is associated differently 1620 for some logical entities, additional entAliasMapping 1621 entries may exist, e.g.: 1623 entAliasMappingIdentifier.33.0 = ifIndex.6 1624 entAliasMappingIdentifier.33.4 = ifIndex.1 1625 entAliasMappingIdentifier.33.5 = ifIndex.1 1626 entAliasMappingIdentifier.33.10 = ifIndex.12 1628 Note that entries with non-zero entAliasLogicalIndexOrZero 1629 index values have precedence over any zero-indexed entry. In 1630 this example, all logical entities except 4, 5, and 10, 1631 associate physical entity 33 with ifIndex.6." 1632 ::= { entAliasMappingEntry 1 } 1634 entAliasMappingIdentifier OBJECT-TYPE 1635 SYNTAX RowPointer 1636 MAX-ACCESS read-only 1637 STATUS current 1638 DESCRIPTION 1639 "The value of this object identifies a particular conceptual 1640 row associated with the indicated entPhysicalIndex and 1641 entLogicalIndex pair. 1643 Since only physical ports are modeled in this table, only 1644 entries which represent interfaces or ports are allowed. If 1645 an ifEntry exists on behalf of a particular physical port, 1646 then this object should identify the associated 'ifEntry'. 1647 For repeater ports, the appropriate row in the 1648 'rptrPortGroupTable' should be identified instead. 1650 For example, suppose a physical port was represented by 1651 entPhysicalEntry.3, entLogicalEntry.15 existed for a 1652 repeater, and entLogicalEntry.22 existed for a bridge. Then 1653 there might be two related instances of 1654 entAliasMappingIdentifier: 1655 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 1656 entAliasMappingIdentifier.3.22 == ifIndex.17 1657 It is possible that other mappings (besides interfaces and 1658 repeater ports) may be defined in the future, as required. 1660 Bridge ports are identified by examining the Bridge MIB and 1661 appropriate ifEntries associated with each 'dot1dBasePort', 1662 and are thus not represented in this table." 1663 ::= { entAliasMappingEntry 2 } 1665 -- physical mapping table 1666 entPhysicalContainsTable OBJECT-TYPE 1667 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 1668 MAX-ACCESS not-accessible 1669 STATUS current 1670 DESCRIPTION 1671 "A table which exposes the container/'containee' 1672 relationships between physical entities. This table provides 1673 all the information found by constructing the virtual 1674 containment tree for a given entPhysicalTable, but in a more 1675 direct format. 1677 In the event a physical entity is contained by more than one 1678 other physical entity (e.g., double-wide modules), this 1679 table should include these additional mappings, which cannot 1680 be represented in the entPhysicalTable virtual containment 1681 tree." 1682 ::= { entityMapping 3 } 1684 entPhysicalContainsEntry OBJECT-TYPE 1685 SYNTAX EntPhysicalContainsEntry 1686 MAX-ACCESS not-accessible 1687 STATUS current 1688 DESCRIPTION 1689 "A single container/'containee' relationship." 1690 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1691 ::= { entPhysicalContainsTable 1 } 1693 EntPhysicalContainsEntry ::= SEQUENCE { 1694 entPhysicalChildIndex PhysicalIndex 1695 } 1697 entPhysicalChildIndex OBJECT-TYPE 1698 SYNTAX PhysicalIndex 1699 MAX-ACCESS read-only 1700 STATUS current 1701 DESCRIPTION 1702 "The value of entPhysicalIndex for the contained physical 1703 entity." 1704 ::= { entPhysicalContainsEntry 1 } 1706 -- last change time stamp for the whole MIB 1707 entLastChangeTime OBJECT-TYPE 1708 SYNTAX TimeStamp 1709 MAX-ACCESS read-only 1710 STATUS current 1711 DESCRIPTION 1712 "The value of sysUpTime at the time a conceptual row is 1713 created, modified, or deleted in any of these tables: 1714 - entPhysicalTable 1715 - entLogicalTable 1716 - entLPMappingTable 1717 - entAliasMappingTable 1718 - entPhysicalContainsTable 1719 " 1720 ::= { entityGeneral 1 } 1722 -- Entity MIB Trap Definitions 1723 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1724 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1726 entConfigChange NOTIFICATION-TYPE 1727 STATUS current 1728 DESCRIPTION 1729 "An entConfigChange notification is generated when the value 1730 of entLastChangeTime changes. It can be utilized by an NMS 1731 to trigger logical/physical entity table maintenance polls. 1733 An agent should not generate more than one entConfigChange 1734 'notification-event' in a given time interval (five seconds 1735 is the suggested default). A 'notification-event' is the 1736 transmission of a single trap or inform PDU to a list of 1737 notification destinations. 1739 If additional configuration changes occur within the 1740 throttling period, then notification-events for these 1741 changes should be suppressed by the agent until the current 1742 throttling period expires. At the end of a throttling 1743 period, one notification-event should be generated if any 1744 configuration changes occurred since the start of the 1745 throttling period. In such a case, another throttling period 1746 is started right away. 1748 An NMS should periodically check the value of 1749 entLastChangeTime to detect any missed entConfigChange 1750 notification-events, e.g., due to throttling or transmission 1751 loss." 1752 ::= { entityMIBTrapPrefix 1 } 1754 -- conformance information 1755 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1757 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1758 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1760 -- compliance statements 1761 entityCompliance MODULE-COMPLIANCE 1762 STATUS deprecated 1763 DESCRIPTION 1764 "The compliance statement for SNMP entities which implement 1765 version 1 of the Entity MIB." 1766 MODULE -- this module 1767 MANDATORY-GROUPS { 1768 entityPhysicalGroup, 1769 entityLogicalGroup, 1770 entityMappingGroup, 1771 entityGeneralGroup, 1772 entityNotificationsGroup 1773 } 1774 ::= { entityCompliances 1 } 1776 entity2Compliance MODULE-COMPLIANCE 1777 STATUS deprecated 1778 DESCRIPTION 1779 "The compliance statement for SNMP entities which implement 1780 version 2 of the Entity MIB." 1781 MODULE -- this module 1782 MANDATORY-GROUPS { 1783 entityPhysicalGroup, 1784 entityPhysical2Group, 1785 entityGeneralGroup, 1786 entityNotificationsGroup 1787 } 1788 GROUP entityLogical2Group 1789 DESCRIPTION 1790 "Implementation of this group is not mandatory for agents 1791 which model all MIB object instances within a single naming 1792 scope." 1794 GROUP entityMappingGroup 1795 DESCRIPTION 1796 "Implementation of the entPhysicalContainsTable is mandatory 1797 for all agents. Implementation of the entLPMappingTable and 1798 entAliasMappingTables are not mandatory for agents which 1799 model all MIB object instances within a single naming scope. 1801 Note that the entAliasMappingTable may be useful for all 1802 agents, however implementation of the entityLogicalGroup or 1803 entityLogical2Group is required to support this table." 1805 OBJECT entPhysicalSerialNum 1806 MIN-ACCESS not-accessible 1807 DESCRIPTION 1808 "Read and write access is not required for agents which 1809 cannot identify serial number information for physical 1810 entities, and/or cannot provide non-volatile storage for 1811 NMS-assigned serial numbers. 1813 Write access is not required for agents which can identify 1814 serial number information for physical entities, but cannot 1815 provide non-volatile storage for NMS-assigned serial 1816 numbers. 1818 Write access is not required for physical entities for 1819 physical entities for which the associated value of the 1820 entPhysicalIsFRU object is equal to 'false(2)'." 1822 OBJECT entPhysicalAlias 1823 MIN-ACCESS read-only 1824 DESCRIPTION 1825 "Write access is required only if the associated 1826 entPhysicalClass value is equal to 'chassis(3)'." 1828 OBJECT entPhysicalAssetID 1829 MIN-ACCESS not-accessible 1830 DESCRIPTION 1831 "Read and write access is not required for agents which 1832 cannot provide non-volatile storage for NMS-assigned asset 1833 identifiers. 1835 Write access is not required for physical entities for which 1836 the associated value of entPhysicalIsFRU is equal to 1837 'false(2)'." 1839 OBJECT entPhysicalClass 1840 SYNTAX INTEGER { 1841 other(1), 1842 unknown(2), 1843 chassis(3), 1844 backplane(4), 1845 container(5), 1846 powerSupply(6), 1847 fan(7), 1848 sensor(8), 1849 module(9), 1850 port(10), 1851 stack(11) 1852 } 1853 DESCRIPTION 1854 "Implementation of the 'cpu(12)' enumeration is not 1855 required." 1857 ::= { entityCompliances 2 } 1859 entity3Compliance MODULE-COMPLIANCE 1860 STATUS current 1861 DESCRIPTION 1862 "The compliance statement for SNMP entities which implement 1863 version 3 of the Entity MIB." 1864 MODULE -- this module 1865 MANDATORY-GROUPS { 1866 entityPhysicalGroup, 1867 entityPhysical2Group, 1868 entityPhysical3Group, 1869 entityGeneralGroup, 1870 entityNotificationsGroup 1871 } 1872 GROUP entityLogical2Group 1873 DESCRIPTION 1874 "Implementation of this group is not mandatory for agents 1875 which model all MIB object instances within a single naming 1876 scope." 1878 GROUP entityMappingGroup 1879 DESCRIPTION 1880 "Implementation of the entPhysicalContainsTable is mandatory 1881 for all agents. Implementation of the entLPMappingTable and 1882 entAliasMappingTables are not mandatory for agents which 1883 model all MIB object instances within a single naming scope. 1885 Note that the entAliasMappingTable may be useful for all 1886 agents, however implementation of the entityLogicalGroup or 1887 entityLogical2Group is required to support this table." 1889 OBJECT entPhysicalSerialNum 1890 MIN-ACCESS not-accessible 1891 DESCRIPTION 1892 "Read and write access is not required for agents which 1893 cannot identify serial number information for physical 1894 entities, and/or cannot provide non-volatile storage for 1895 NMS-assigned serial numbers. 1897 Write access is not required for agents which can identify 1898 serial number information for physical entities, but cannot 1899 provide non-volatile storage for NMS-assigned serial 1900 numbers. 1902 Write access is not required for physical entities for 1903 physical entities for which the associated value of the 1904 entPhysicalIsFRU object is equal to 'false(2)'." 1906 OBJECT entPhysicalAlias 1907 MIN-ACCESS read-only 1908 DESCRIPTION 1909 "Write access is required only if the associated 1910 entPhysicalClass value is equal to 'chassis(3)'." 1912 OBJECT entPhysicalAssetID 1913 MIN-ACCESS not-accessible 1914 DESCRIPTION 1915 "Read and write access is not required for agents which 1916 cannot provide non-volatile storage for NMS-assigned asset 1917 identifiers. 1919 Write access is not required for physical entities for which 1920 the associated value of entPhysicalIsFRU is equal to 1921 'false(2)'." 1922 ::= { entityCompliances 3 } 1924 -- MIB groupings 1925 entityPhysicalGroup OBJECT-GROUP 1926 OBJECTS { 1927 entPhysicalDescr, 1928 entPhysicalVendorType, 1929 entPhysicalContainedIn, 1930 entPhysicalClass, 1931 entPhysicalParentRelPos, 1932 entPhysicalName 1933 } 1934 STATUS current 1935 DESCRIPTION 1936 "The collection of objects which are used to represent 1937 physical system components, for which a single agent 1938 provides management information." 1939 ::= { entityGroups 1 } 1941 entityLogicalGroup OBJECT-GROUP 1942 OBJECTS { 1943 entLogicalDescr, 1944 entLogicalType, 1945 entLogicalCommunity, 1946 entLogicalTAddress, 1947 entLogicalTDomain 1948 } 1949 STATUS deprecated 1950 DESCRIPTION 1951 "The collection of objects which are used to represent the 1952 list of logical entities for which a single agent provides 1953 management information." 1954 ::= { entityGroups 2 } 1956 entityMappingGroup OBJECT-GROUP 1957 OBJECTS { 1958 entLPPhysicalIndex, 1959 entAliasMappingIdentifier, 1960 entPhysicalChildIndex 1961 } 1962 STATUS current 1963 DESCRIPTION 1964 "The collection of objects which are used to represent the 1965 associations between multiple logical entities, physical 1966 components, interfaces, and port identifiers for which a 1967 single agent provides management information." 1968 ::= { entityGroups 3 } 1970 entityGeneralGroup OBJECT-GROUP 1971 OBJECTS { 1972 entLastChangeTime 1973 } 1974 STATUS current 1975 DESCRIPTION 1976 "The collection of objects which are used to represent 1977 general entity information for which a single agent provides 1978 management information." 1979 ::= { entityGroups 4 } 1981 entityNotificationsGroup NOTIFICATION-GROUP 1982 NOTIFICATIONS { entConfigChange } 1983 STATUS current 1984 DESCRIPTION 1985 "The collection of notifications used to indicate Entity MIB 1986 data consistency and general status information." 1987 ::= { entityGroups 5 } 1989 entityPhysical2Group OBJECT-GROUP 1990 OBJECTS { 1991 entPhysicalHardwareRev, 1992 entPhysicalFirmwareRev, 1993 entPhysicalSoftwareRev, 1994 entPhysicalSerialNum, 1995 entPhysicalMfgName, 1996 entPhysicalModelName, 1997 entPhysicalAlias, 1998 entPhysicalAssetID, 1999 entPhysicalIsFRU 2000 } 2001 STATUS current 2002 DESCRIPTION 2003 "The collection of objects which are used to represent 2004 physical system components, for which a single agent 2005 provides management information. This group augments the 2006 objects contained in the entityPhysicalGroup." 2007 ::= { entityGroups 6 } 2009 entityLogical2Group OBJECT-GROUP 2010 OBJECTS { 2011 entLogicalDescr, 2012 entLogicalType, 2013 entLogicalTAddress, 2014 entLogicalTDomain, 2015 entLogicalContextEngineID, 2016 entLogicalContextName 2017 } 2018 STATUS current 2019 DESCRIPTION 2020 "The collection of objects which are used to represent the 2021 list of logical entities for which a single SNMP entity 2022 provides management information." 2023 ::= { entityGroups 7 } 2025 entityPhysical3Group OBJECT-GROUP 2026 OBJECTS { 2027 entPhysicalMfgDate, 2028 entPhysicalUris 2029 } 2030 STATUS current 2031 DESCRIPTION 2032 "The collection of objects which are used to represent 2033 physical system components, for which a single agent 2034 provides management information. This group augments the 2035 objects contained in the entityPhysicalGroup." 2036 ::= { entityGroups 8 } 2038 END 2039 4. Usage Examples 2041 The following sections iterate the instance values for two example 2042 networking devices. These examples are kept simple to make them 2043 more understandable. Auxiliary components, such as fans, sensors, 2044 empty slots, and sub-modules are not shown, but might be modeled in 2045 real implementations. 2047 4.1. Router/Bridge 2049 A router containing two slots. Each slot contains a 3 port 2050 router/bridge module. Each port is represented in the ifTable. 2051 There are two logical instances of OSPF running and two logical 2052 bridges: 2054 Physical entities -- entPhysicalTable: 2055 1 Field-replaceable physical chassis: 2056 entPhysicalDescr.1 == 'Acme Chassis Model 100' 2057 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 2058 entPhysicalContainedIn.1 == 0 2059 entPhysicalClass.1 == chassis(3) 2060 entPhysicalParentRelPos.1 == 0 2061 entPhysicalName.1 == '100-A' 2062 entPhysicalHardwareRev.1 == 'A(1.00.02)' 2063 entPhysicalSoftwareRev.1 == '' 2064 entPhysicalFirmwareRev.1 == '' 2065 entPhysicalSerialNum.1 == 'C100076544' 2066 entPhysicalMfgName.1 == 'Acme' 2067 entPhysicalModelName.1 == '100' 2068 entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' 2069 entPhysicalAssetID.1 == '0007372293' 2070 entPhysicalIsFRU.1 == true(1) 2071 entPhysicalMfgDate.1 == '2002-5-26,13:30:30.0,-4:0' 2072 entPhysicalUris.1 == 'URN:CLEI:CNME120ARA' 2073 2 slots within the chassis: 2074 entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' 2075 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 2076 entPhysicalContainedIn.2 == 1 2077 entPhysicalClass.2 == container(5) 2078 entPhysicalParentRelPos.2 == 1 2079 entPhysicalName.2 == 'S1' 2080 entPhysicalHardwareRev.2 == 'B(1.00.01)' 2081 entPhysicalSoftwareRev.2 == '' 2082 entPhysicalFirmwareRev.2 == '' 2083 entPhysicalSerialNum.2 == '' 2084 entPhysicalMfgName.2 == 'Acme' 2085 entPhysicalModelName.2 == 'AA' 2086 entPhysicalAlias.2 == '' 2087 entPhysicalAssetID.2 == '' 2088 entPhysicalIsFRU.2 == false(2) 2089 entPhysicalMfgDate.2 == '2002-7-26,12:22:12.0,-4:0' 2090 entPhysicalUris.2 == 'URN:CLEI:CNME123ARA' 2092 entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' 2093 entPhysicalVendorType.3 = acmeProducts.slotTypes.1 2094 entPhysicalContainedIn.3 == 1 2095 entPhysicalClass.3 == container(5) 2096 entPhysicalParentRelPos.3 == 2 2097 entPhysicalName.3 == 'S2' 2098 entPhysicalHardwareRev.3 == '1.00.07' 2099 entPhysicalSoftwareRev.3 == '' 2100 entPhysicalFirmwareRev.3 == '' 2101 entPhysicalSerialNum.3 == '' 2102 entPhysicalMfgName.3 == 'Acme' 2103 entPhysicalModelName.3 == 'AA' 2104 entPhysicalAlias.3 == '' 2105 entPhysicalAssetID.3 == '' 2106 entPhysicalIsFRU.3 == false(2) 2107 entPhysicalMfgDate.3 == '2002-7-26,12:12:12.0,-4:0' 2108 entPhysicalUris.3 == 'URN:CLEI:CNME123ARA' 2110 2 Field-replaceable modules: 2111 Slot 1 contains a module with 3 ports: 2112 entPhysicalDescr.4 == 'Acme Router-100' 2113 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 2114 entPhysicalContainedIn.4 == 2 2115 entPhysicalClass.4 == module(9) 2116 entPhysicalParentRelPos.4 == 1 2117 entPhysicalName.4 == 'M1' 2118 entPhysicalHardwareRev.4 == '1.00.07' 2119 entPhysicalSoftwareRev.4 == '1.4.1' 2120 entPhysicalFirmwareRev.4 == 'A(1.1)' 2121 entPhysicalSerialNum.4 == 'C100087363' 2122 entPhysicalMfgName.4 == 'Acme' 2123 entPhysicalModelName.4 == 'R100-FE' 2124 entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' 2125 entPhysicalAssetID.4 == '0007372462' 2126 entPhysicalIsFRU.4 == true(1) 2127 entPhysicalMfgDate.4 == '2003-7-18,13:30:30.0,-4:0' 2128 entPhysicalUris.4 == 'URN:CLEI:CNRU123CAA' 2129 entPhysicalDescr.5 == 'Acme Ethernet-100 Port' 2130 entPhysicalVendorType.5 == acmeProducts.portTypes.2 2131 entPhysicalContainedIn.5 == 4 2132 entPhysicalClass.5 == port(10) 2133 entPhysicalParentRelPos.5 == 1 2134 entPhysicalName.5 == 'P1' 2135 entPhysicalHardwareRev.5 == 'G(1.02)' 2136 entPhysicalSoftwareRev.5 == '' 2137 entPhysicalFirmwareRev.5 == '1.1' 2138 entPhysicalSerialNum.5 == '' 2139 entPhysicalMfgName.5 == 'Acme' 2140 entPhysicalModelName.5 == 'FE-100' 2141 entPhysicalAlias.5 == '' 2142 entPhysicalAssetID.5 == '' 2143 entPhysicalIsFRU.5 == false(2) 2144 entPhysicalMfgDate.5 == '2003-7-18,14:20:22.0,-4:0' 2145 entPhysicalUris.5 == 'URN:CLEI:CNMES23ARA' 2147 entPhysicalDescr.6 == 'Acme Ethernet-100 Port' 2148 entPhysicalVendorType.6 == acmeProducts.portTypes.2 2149 entPhysicalContainedIn.6 == 4 2150 entPhysicalClass.6 == port(10) 2151 entPhysicalParentRelPos.6 == 2 2152 entPhysicalName.6 == 'P2' 2153 entPhysicalHardwareRev.6 == 'G(1.02)' 2154 entPhysicalSoftwareRev.6 == '' 2155 entPhysicalFirmwareRev.6 == '1.1' 2156 entPhysicalSerialNum.6 == '' 2157 entPhysicalMfgName.6 == 'Acme' 2158 entPhysicalModelName.6 == 'FE-100' 2159 entPhysicalAlias.6 == '' 2160 entPhysicalAssetID.6 == '' 2161 entPhysicalIsFRU.6 == false(2) 2162 entPhysicalMfgDate.6 == '2003-7-19,10:15:15.0,-4:0' 2163 entPhysicalUris.6 == 'URN:CLEI:CNMES23ARA' 2165 entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' 2166 entPhysicalVendorType.7 == acmeProducts.portTypes.3 2167 entPhysicalContainedIn.7 == 4 2168 entPhysicalClass.7 == port(10) 2169 entPhysicalParentRelPos.7 == 3 2170 entPhysicalName.7 == 'P3' 2171 entPhysicalHardwareRev.7 == 'B(1.03)' 2172 entPhysicalSoftwareRev.7 == '2.5.1' 2173 entPhysicalFirmwareRev.7 == '2.5F' 2174 entPhysicalSerialNum.7 == '' 2175 entPhysicalMfgName.7 == 'Acme' 2176 entPhysicalModelName.7 == 'FDDI-100' 2177 entPhysicalAlias.7 == '' 2178 entPhysicalAssetID.7 == '' 2179 entPhysicalIsFRU.7 == false(2) 2181 Slot 2 contains another 3-port module: 2182 entPhysicalDescr.8 == 'Acme Router-100 Comm Module' 2183 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 2184 entPhysicalContainedIn.8 == 3 2185 entPhysicalClass.8 == module(9) 2186 entPhysicalParentRelPos.8 == 1 2187 entPhysicalName.8 == 'M2' 2188 entPhysicalHardwareRev.8 == '2.01.00' 2189 entPhysicalSoftwareRev.8 == '3.0.7' 2190 entPhysicalFirmwareRev.8 == 'A(1.2)' 2191 entPhysicalSerialNum.8 == 'C100098732' 2192 entPhysicalMfgName.8 == 'Acme' 2193 entPhysicalModelName.8 == 'C100' 2194 entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' 2195 entPhysicalAssetID.8 == '0007373982' 2196 entPhysicalIsFRU.8 == true(1) 2197 entPhysicalMfgDate.8 == '2002-5-26,13:30:15.0,-4:0' 2198 entPhysicalUris.8 == 'URN:CLEI:CNRT321MAA' 2200 entPhysicalDescr.9 == 'Acme Fddi-100 Port' 2201 entPhysicalVendorType.9 == acmeProducts.portTypes.5 2202 entPhysicalContainedIn.9 == 8 2203 entPhysicalClass.9 == port(10) 2204 entPhysicalParentRelPos.9 == 1 2205 entPhysicalName.9 == 'FDDI Primary' 2206 entPhysicalHardwareRev.9 == 'CC(1.07)' 2207 entPhysicalSoftwareRev.9 == '2.0.34' 2208 entPhysicalFirmwareRev.9 == '1.1' 2209 entPhysicalSerialNum.9 == '' 2210 entPhysicalMfgName.9 == 'Acme' 2211 entPhysicalModelName.9 == 'FDDI-100' 2212 entPhysicalAlias.9 == '' 2213 entPhysicalAssetID.9 == '' 2214 entPhysicalIsFRU.9 == false(2) 2216 entPhysicalDescr.10 == 'Acme Ethernet-100 Port' 2217 entPhysicalVendorType.10 == acmeProducts.portTypes.2 2218 entPhysicalContainedIn.10 == 8 2219 entPhysicalClass.10 == port(10) 2220 entPhysicalParentRelPos.10 == 2 2221 entPhysicalName.10 == 'Ethernet A' 2222 entPhysicalHardwareRev.10 == 'G(1.04)' 2223 entPhysicalSoftwareRev.10 == '' 2224 entPhysicalFirmwareRev.10 == '1.3' 2225 entPhysicalSerialNum.10 == '' 2226 entPhysicalMfgName.10 == 'Acme' 2227 entPhysicalModelName.10 == 'FE-100' 2228 entPhysicalAlias.10 == '' 2229 entPhysicalAssetID.10 == '' 2230 entPhysicalIsFRU.10 == false(2) 2231 entPhysicalMfgDate.10 == '2002-7-26,13:30:15.0,-4:0' 2232 entPhysicalUris.10 == 'URN:CLEI:CNMES23ARA' 2234 entPhysicalDescr.11 == 'Acme Ethernet-100 Port' 2235 entPhysicalVendorType.11 == acmeProducts.portTypes.2 2236 entPhysicalContainedIn.11 == 8 2237 entPhysicalClass.11 == port(10) 2238 entPhysicalParentRelPos.11 == 3 2239 entPhysicalName.11 == 'Ethernet B' 2240 entPhysicalHardwareRev.11 == 'G(1.04)' 2241 entPhysicalSoftwareRev.11 == '' 2242 entPhysicalFirmwareRev.11 == '1.3' 2243 entPhysicalSerialNum.11 == '' 2244 entPhysicalMfgName.11 == 'Acme' 2245 entPhysicalModelName.11 == 'FE-100' 2246 entPhysicalAlias.11 == '' 2247 entPhysicalAssetID.11 == '' 2248 entPhysicalIsFRU.11 == false(2) 2249 entPhysicalMfgDate.11 == '2002-8-16,15:35:15.0,-4:0' 2250 entPhysicalUris.11 == 'URN:CLEI:CNMES23ARA' 2252 Logical entities -- entLogicalTable; no SNMPv3 support 2253 2 OSPF instances: 2254 entLogicalDescr.1 == 'Acme OSPF v1.1' 2255 entLogicalType.1 == ospf 2256 entLogicalCommunity.1 == 'public-ospf1' 2257 entLogicalTAddress.1 == 124.125.126.127:161 2258 entLogicalTDomain.1 == snmpUDPDomain 2259 entLogicalContextEngineID.1 == '' 2260 entLogicalContextName.1 == '' 2262 entLogicalDescr.2 == 'Acme OSPF v1.1' 2263 entLogicalType.2 == ospf 2264 entLogicalCommunity.2 == 'public-ospf2' 2265 entLogicalTAddress.2 == 124.125.126.127:161 2266 entLogicalTDomain.2 == snmpUDPDomain 2267 entLogicalContextEngineID.2 == '' 2268 entLogicalContextName.2 == '' 2270 2 logical bridges: 2271 entLogicalDescr.3 == 'Acme Bridge v2.1.1' 2272 entLogicalType.3 == dot1dBridge 2273 entLogicalCommunity.3 == 'public-bridge1' 2274 entLogicalTAddress.3 == 124.125.126.127:161 2275 entLogicalTDomain.3 == snmpUDPDomain 2276 entLogicalContextEngineID.3 == '' 2277 entLogicalContextName.3 == '' 2279 entLogicalDescr.4 == 'Acme Bridge v2.1.1' 2280 entLogicalType.4 == dot1dBridge 2281 entLogicalCommunity.4 == 'public-bridge2' 2282 entLogicalTAddress.4 == 124.125.126.127:161 2283 entLogicalTDomain.4 == snmpUDPDomain 2284 entLogicalContextEngineID.4 == '' 2285 entLogicalContextName.4 == '' 2287 Logical to Physical Mappings: 2288 1st OSPF instance: uses module 1-port 1 2289 entLPPhysicalIndex.1.5 == 5 2291 2nd OSPF instance: uses module 2-port 1 2292 entLPPhysicalIndex.2.9 == 9 2294 1st bridge group: uses module 1, all ports 2296 [ed. -- Note that these mappings are included in the table since 2297 another logical entity (1st OSPF) utilizes one of the 2298 ports. If this were not the case, then a single mapping 2299 to the module (e.g., entLPPhysicalIndex.3.4) would be 2300 present instead. ] 2301 entLPPhysicalIndex.3.5 == 5 2302 entLPPhysicalIndex.3.6 == 6 2303 entLPPhysicalIndex.3.7 == 7 2305 2nd bridge group: uses module 2, all ports 2306 entLPPhysicalIndex.4.9 == 9 2307 entLPPhysicalIndex.4.10 == 10 2308 entLPPhysicalIndex.4.11 == 11 2310 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2311 Example 1: ifIndex values are global to all logical entities 2312 entAliasMappingIdentifier.5.0 == ifIndex.1 2313 entAliasMappingIdentifier.6.0 == ifIndex.2 2314 entAliasMappingIdentifier.7.0 == ifIndex.3 2315 entAliasMappingIdentifier.9.0 == ifIndex.4 2316 entAliasMappingIdentifier.10.0 == ifIndex.5 2317 entAliasMappingIdentifier.11.0 == ifIndex.6 2319 Example 2: ifIndex values are not shared by all logical entities 2320 entAliasMappingIdentifier.5.0 == ifIndex.1 2321 entAliasMappingIdentifier.5.3 == ifIndex.101 2322 entAliasMappingIdentifier.6.0 == ifIndex.2 2323 entAliasMappingIdentifier.6.3 == ifIndex.102 2324 entAliasMappingIdentifier.7.0 == ifIndex.3 2325 entAliasMappingIdentifier.7.3 == ifIndex.103 2326 entAliasMappingIdentifier.9.0 == ifIndex.4 2327 entAliasMappingIdentifier.9.3 == ifIndex.204 2328 entAliasMappingIdentifier.10.0 == ifIndex.5 2329 entAliasMappingIdentifier.10.3 == ifIndex.205 2330 entAliasMappingIdentifier.11.0 == ifIndex.6 2331 entAliasMappingIdentifier.11.3 == ifIndex.206 2333 Physical Containment Tree -- entPhysicalContainsTable 2334 chassis has two containers: 2335 entPhysicalChildIndex.1.2 == 2 2336 entPhysicalChildIndex.1.3 == 3 2338 container 1 has a module: 2339 entPhysicalChildIndex.2.4 == 4 2341 container 2 has a module: 2342 entPhysicalChildIndex.3.8 == 8 2344 module 1 has 3 ports: 2345 entPhysicalChildIndex.4.5 == 5 2346 entPhysicalChildIndex.4.6 == 6 2347 entPhysicalChildIndex.4.7 == 7 2349 module 2 has 3 ports: 2350 entPhysicalChildIndex.8.9 == 9 2351 entPhysicalChildIndex.8.10 == 10 2352 entPhysicalChildIndex.1.11 == 11 2354 4.2. Repeaters 2356 A 3-slot Hub with 2 backplane ethernet segments. Slot three is 2357 empty, and the remaining slots contain ethernet repeater modules. 2359 Note that this example assumes an older Repeater MIB 2360 implementation, (RFC 1516 [RFC1516]) rather than the new Repeater 2361 MIB (RFC 2108 [RFC2108]). The new version contains an object 2362 called 'rptrPortRptrId', which should be used to identify repeater 2363 port groupings, rather than with community strings or contexts. 2365 Physical entities -- entPhysicalTable: 2366 1 Field-replaceable physical chassis: 2367 entPhysicalDescr.1 == 'Acme Chassis Model 110' 2368 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 2369 entPhysicalContainedIn.1 == 0 2370 entPhysicalClass.1 == chassis(3) 2371 entPhysicalParentRelPos.1 == 0 2372 entPhysicalName.1 == '110-B' 2373 entPhysicalHardwareRev.1 == 'A(1.02.00)' 2374 entPhysicalSoftwareRev.1 == '' 2375 entPhysicalFirmwareRev.1 == '' 2376 entPhysicalSerialNum.1 == 'C100079294' 2377 entPhysicalMfgName.1 == 'Acme' 2378 entPhysicalModelName.1 == '110' 2379 entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' 2380 entPhysicalAssetID.1 == '0007386327' 2381 entPhysicalIsFRU.1 == true(1) 2383 2 Chassis Ethernet Backplanes: 2384 entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' 2385 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 2386 entPhysicalContainedIn.2 == 1 2387 entPhysicalClass.2 == backplane(4) 2388 entPhysicalParentRelPos.2 == 1 2389 entPhysicalName.2 == 'B1' 2390 entPhysicalHardwareRev.2 == 'A(2.04.01)' 2391 entPhysicalSoftwareRev.2 == '' 2392 entPhysicalFirmwareRev.2 == '' 2393 entPhysicalSerialNum.2 == '' 2394 entPhysicalMfgName.2 == 'Acme' 2395 entPhysicalModelName.2 == 'BK-A' 2396 entPhysicalAlias.2 == '' 2397 entPhysicalAssetID.2 == '' 2398 entPhysicalIsFRU.2 == false(2) 2399 entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' 2400 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 2401 entPhysicalContainedIn.3 == 1 2402 entPhysicalClass.3 == backplane(4) 2403 entPhysicalParentRelPos.3 == 2 2404 entPhysicalName.3 == 'B2' 2405 entPhysicalHardwareRev.3 == 'A(2.04.01)' 2406 entPhysicalSoftwareRev.3 == '' 2407 entPhysicalFirmwareRev.3 == '' 2408 entPhysicalSerialNum.3 == '' 2409 entPhysicalMfgName.3 == 'Acme' 2410 entPhysicalModelName.3 == 'BK-A' 2411 entPhysicalAlias.3 == '' 2412 entPhysicalAssetID.3 == '' 2413 entPhysicalIsFRU.3 == false(2) 2415 3 slots within the chassis: 2416 entPhysicalDescr.4 == 'Acme Hub Slot Type RB' 2417 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 2418 entPhysicalContainedIn.4 == 1 2419 entPhysicalClass.4 == container(5) 2420 entPhysicalParentRelPos.4 == 1 2421 entPhysicalName.4 == 'Slot 1' 2422 entPhysicalHardwareRev.4 == 'B(1.00.03)' 2423 entPhysicalSoftwareRev.4 == '' 2424 entPhysicalFirmwareRev.4 == '' 2425 entPhysicalSerialNum.4 == '' 2426 entPhysicalMfgName.4 == 'Acme' 2427 entPhysicalModelName.4 == 'RB' 2428 entPhysicalAlias.4 == '' 2429 entPhysicalAssetID.4 == '' 2430 entPhysicalIsFRU.4 == false(2) 2432 entPhysicalDescr.5 == 'Acme Hub Slot Type RB' 2433 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 2434 entPhysicalContainedIn.5 == 1 2435 entPhysicalClass.5 == container(5) 2436 entPhysicalParentRelPos.5 == 2 2437 entPhysicalName.5 == 'Slot 2' 2438 entPhysicalHardwareRev.5 == 'B(1.00.03)' 2439 entPhysicalSoftwareRev.5 == '' 2440 entPhysicalFirmwareRev.5 == '' 2441 entPhysicalSerialNum.5 == '' 2442 entPhysicalMfgName.5 == 'Acme' 2443 entPhysicalModelName.5 == 'RB' 2444 entPhysicalAlias.5 == '' 2445 entPhysicalAssetID.5 == '' 2446 entPhysicalIsFRU.5 == false(2) 2448 entPhysicalDescr.6 == 'Acme Hub Slot Type RB' 2449 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 2450 entPhysicalContainedIn.6 == 1 2451 entPhysicalClass.6 == container(5) 2452 entPhysicalParentRelPos.6 == 3 2453 entPhysicalName.6 == 'Slot 3' 2454 entPhysicalHardwareRev.6 == 'B(1.00.03)' 2455 entPhysicalSoftwareRev.6 == '' 2456 entPhysicalFirmwareRev.6 == '' 2457 entPhysicalSerialNum.6 == '' 2458 entPhysicalMfgName.6 == 'Acme' 2459 entPhysicalModelName.6 == 'RB' 2460 entPhysicalAlias.6 == '' 2461 entPhysicalAssetID.6 == '' 2462 entPhysicalIsFRU.6 == false(2) 2464 Slot 1 contains a plug-in module with 4 10-BaseT ports: 2465 entPhysicalDescr.7 == 'Acme 10Base-T Module 114' 2466 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 2467 entPhysicalContainedIn.7 == 4 2468 entPhysicalClass.7 == module(9) 2469 entPhysicalParentRelPos.7 == 1 2470 entPhysicalName.7 == 'M1' 2471 entPhysicalHardwareRev.7 == 'A(1.02.01)' 2472 entPhysicalSoftwareRev.7 == '1.7.2' 2473 entPhysicalFirmwareRev.7 == 'A(1.5)' 2474 entPhysicalSerialNum.7 == 'C100096244' 2475 entPhysicalMfgName.7 == 'Acme' 2476 entPhysicalModelName.7 = '114' 2477 entPhysicalAlias.7 == 'bldg09:floor1:eng' 2478 entPhysicalAssetID.7 == '0007962951' 2479 entPhysicalIsFRU.7 == true(1) 2481 entPhysicalDescr.8 == 'Acme 10Base-T Port RB' 2482 entPhysicalVendorType.8 == acmeProducts.portTypes.10 2483 entPhysicalContainedIn.8 == 7 2484 entPhysicalClass.8 == port(10) 2485 entPhysicalParentRelPos.8 == 1 2486 entPhysicalName.8 == 'Ethernet-A' 2487 entPhysicalHardwareRev.8 == 'A(1.04F)' 2488 entPhysicalSoftwareRev.8 == '' 2489 entPhysicalFirmwareRev.8 == '1.4' 2490 entPhysicalSerialNum.8 == '' 2491 entPhysicalMfgName.8 == 'Acme' 2492 entPhysicalModelName.8 == 'RB' 2493 entPhysicalAlias.8 == '' 2494 entPhysicalAssetID.8 == '' 2495 entPhysicalIsFRU.8 == false(2) 2497 entPhysicalDescr.9 == 'Acme 10Base-T Port RB' 2498 entPhysicalVendorType.9 == acmeProducts.portTypes.10 2499 entPhysicalContainedIn.9 == 7 2500 entPhysicalClass.9 == port(10) 2501 entPhysicalParentRelPos.9 == 2 2502 entPhysicalName.9 == 'Ethernet-B' 2503 entPhysicalHardwareRev.9 == 'A(1.04F)' 2504 entPhysicalSoftwareRev.9 == '' 2505 entPhysicalFirmwareRev.9 == '1.4' 2506 entPhysicalSerialNum.9 == '' 2507 entPhysicalMfgName.9 == 'Acme' 2508 entPhysicalModelName.9 = 'RB' 2509 entPhysicalAlias.9 == '' 2510 entPhysicalAssetID.9 == '' 2511 entPhysicalIsFRU.9 == false(2) 2513 entPhysicalDescr.10 == 'Acme 10Base-T Port RB' 2514 entPhysicalVendorType.10 == acmeProducts.portTypes.10 2515 entPhysicalContainedIn.10 == 7 2516 entPhysicalClass.10 == port(10) 2517 entPhysicalParentRelPos.10 == 3 2518 entPhysicalName.10 == 'Ethernet-C' 2519 entPhysicalHardwareRev.10 == 'B(1.02.07)' 2520 entPhysicalSoftwareRev.10 == '' 2521 entPhysicalFirmwareRev.10 == '1.4' 2522 entPhysicalSerialNum.10 == '' 2523 entPhysicalMfgName.10 == 'Acme' 2524 entPhysicalModelName.10 == 'RB' 2525 entPhysicalAlias.10 == '' 2526 entPhysicalAssetID.10 == '' 2527 entPhysicalIsFRU.10 == false(2) 2529 entPhysicalDescr.11 == 'Acme 10Base-T Port RB' 2530 entPhysicalVendorType.11 == acmeProducts.portTypes.10 2531 entPhysicalContainedIn.11 == 7 2532 entPhysicalClass.11 == port(10) 2533 entPhysicalParentRelPos.11 == 4 2534 entPhysicalName.11 == 'Ethernet-D' 2535 entPhysicalHardwareRev.11 == 'B(1.02.07)' 2536 entPhysicalSoftwareRev.11 == '' 2537 entPhysicalFirmwareRev.11 == '1.4' 2538 entPhysicalSerialNum.11 == '' 2539 entPhysicalMfgName.11 == 'Acme' 2540 entPhysicalModelName.11 == 'RB' 2541 entPhysicalAlias.11 == '' 2542 entPhysicalAssetID.11 == '' 2543 entPhysicalIsFRU.11 == false(2) 2545 Slot 2 contains another ethernet module with 2 ports. 2546 entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' 2547 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 2548 entPhysicalContainedIn.12 = 5 2549 entPhysicalClass.12 == module(9) 2550 entPhysicalParentRelPos.12 == 1 2551 entPhysicalName.12 == 'M2' 2552 entPhysicalHardwareRev.12 == 'A(1.01.07)' 2553 entPhysicalSoftwareRev.12 == '1.8.4' 2554 entPhysicalFirmwareRev.12 == 'A(1.8)' 2555 entPhysicalSerialNum.12 == 'C100102384' 2556 entPhysicalMfgName.12 == 'Acme' 2557 entPhysicalModelName.12 == '4' 2558 entPhysicalAlias.12 == 'bldg09:floor1:devtest' 2559 entPhysicalAssetID.12 == '0007968462' 2560 entPhysicalIsFRU.12 == true(1) 2562 entPhysicalDescr.13 == 'Acme 802.3 AUI Port' 2563 entPhysicalVendorType.13 == acmeProducts.portTypes.11 2564 entPhysicalContainedIn.13 == 12 2565 entPhysicalClass.13 == port(10) 2566 entPhysicalParentRelPos.13 == 1 2567 entPhysicalName.13 == 'AUI' 2568 entPhysicalHardwareRev.13 == 'A(1.06F)' 2569 entPhysicalSoftwareRev.13 == '' 2570 entPhysicalFirmwareRev.13 == '1.5' 2571 entPhysicalSerialNum.13 == '' 2572 entPhysicalMfgName.13 == 'Acme' 2573 entPhysicalModelName.13 == '' 2574 entPhysicalAlias.13 == '' 2575 entPhysicalAssetID.13 == '' 2576 entPhysicalIsFRU.13 == false(2) 2578 entPhysicalDescr.14 == 'Acme 10Base-T Port RD' 2579 entPhysicalVendorType.14 == acmeProducts.portTypes.14 2580 entPhysicalContainedIn.14 == 12 2581 entPhysicalClass.14 == port(10) 2582 entPhysicalParentRelPos.14 == 2 2583 entPhysicalName.14 == 'E2' 2584 entPhysicalHardwareRev.14 == 'B(1.01.02)' 2585 entPhysicalSoftwareRev.14 == '' 2586 entPhysicalFirmwareRev.14 == '2.1' 2587 entPhysicalSerialNum.14 == '' 2588 entPhysicalMfgName.14 == 'Acme' 2589 entPhysicalModelName.14 == '' 2590 entPhysicalAlias.14 == '' 2591 entPhysicalAssetID.14 == '' 2592 entPhysicalIsFRU.14 == false(2) 2594 Logical entities -- entLogicalTable; with SNMPv3 support 2595 Repeater 1--comprised of any ports attached to backplane 1 2596 entLogicalDescr.1 == 'Acme repeater v3.1' 2597 entLogicalType.1 == snmpDot3RptrMgt 2598 entLogicalCommunity.1 'public-repeater1' 2599 entLogicalTAddress.1 == 124.125.126.127:161 2600 entLogicalTDomain.1 == snmpUDPDomain 2601 entLogicalContextEngineID.1 == '80000777017c7d7e7f'H 2602 entLogicalContextName.1 == 'repeater1' 2604 Repeater 2--comprised of any ports attached to backplane 2: 2605 entLogicalDescr.2 == 'Acme repeater v3.1' 2606 entLogicalType.2 == snmpDot3RptrMgt 2607 entLogicalCommunity.2 == 'public-repeater2' 2608 entLogicalTAddress.2 == 124.125.126.127:161 2609 entLogicalTDomain.2 == snmpUDPDomain 2610 entLogicalContextEngineID.2 == '80000777017c7d7e7f'H 2611 entLogicalContextName.2 == 'repeater2' 2613 Logical to Physical Mappings -- entLPMappingTable: 2615 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 2616 [ed. -- Note that a mapping to the module is not included, 2617 since in this example represents a port-switchable hub. 2618 Even though all ports on the module could belong to the 2619 same repeater as a matter of configuration, the LP port 2620 mappings should not be replaced dynamically with a single 2621 mapping for the module (e.g., entLPPhysicalIndex.1.7). 2622 If all ports on the module shared a single backplane connection, 2623 then a single mapping for the module would be more appropriate. ] 2624 entLPPhysicalIndex.1.2 == 2 2625 entLPPhysicalIndex.1.8 == 8 2626 entLPPhysicalIndex.1.9 == 9 2627 entLPPhysicalIndex.1.13 == 13 2629 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 2630 entLPPhysicalIndex.2.3 == 3 2631 entLPPhysicalIndex.2.10 == 10 2632 entLPPhysicalIndex.2.11 == 11 2633 entLPPhysicalIndex.2.14 == 14 2635 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2636 Repeater Port Identifier values are shared by both repeaters: 2637 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 2638 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 2639 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 2640 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 2641 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 2642 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 2644 Physical Containment Tree -- entPhysicalContainsTable 2645 chassis has two backplanes and three containers: 2646 entPhysicalChildIndex.1.2 == 2 2647 entPhysicalChildIndex.1.3 == 3 2648 entPhysicalChildIndex.1.4 == 4 2649 entPhysicalChildIndex.1.5 == 5 2650 entPhysicalChildIndex.1.6 == 6 2652 container 1 has a module: 2653 entPhysicalChildIndex.4.7 == 7 2655 container 2 has a module 2656 entPhysicalChildIndex.5.12 == 12 2657 [ed. - in this example, container 3 is empty.] 2659 module 1 has 4 ports: 2660 entPhysicalChildIndex.7.8 == 8 2661 entPhysicalChildIndex.7.9 == 9 2662 entPhysicalChildIndex.7.10 == 10 2663 entPhysicalChildIndex.7.11 == 11 2665 module 2 has 2 ports: 2666 entPhysicalChildIndex.12.13 == 13 2667 entPhysicalChildIndex.12.14 == 14 2669 5. Security Considerations 2671 There are a number of management objects defined in this MIB that 2672 have a MAX-ACCESS clause of read-write and/or read-create. Such 2673 objects may be considered sensitive or vulnerable in some network 2674 environments. The support for SET operations in a non-secure 2675 environment without proper protection can have a negative effect on 2676 network operations. 2678 There are a number of managed objects in this MIB that may contain 2679 sensitive information. These are: 2681 entPhysicalDescr 2682 entPhysicalVendorType 2683 entPhysicalHardwareRev 2684 entPhysicalFirmwareRev 2685 entPhysicalSoftwareRev 2686 entPhysicalSerialNum 2687 entPhysicalMfgName 2688 entPhysicalModelName 2690 These objects expose information about the physical entities within 2691 a managed system, which may be used to identify the vendor, model, 2692 and version information of each system component. 2694 entPhysicalAssetID 2696 This object can allow asset identifiers for various system 2697 components to be exposed, in the event this MIB object is actually 2698 configured by an NMS application. 2700 entLogicalDescr 2701 entLogicalType 2703 These objects expose the type of logical entities present in the 2704 managed system. 2706 entLogicalCommunity 2708 This object exposes community names associated with particular 2709 logical entities within the system. 2711 entLogicalTAddress 2712 entLogicalTDomain 2713 These objects expose network addresses that can be used to 2714 communicate with an SNMP agent on behalf of particular logical 2715 entities within the system. 2717 entLogicalContextEngineID 2718 entLogicalContextName 2720 These objects identify the authoritative SNMP engine that contains 2721 information on behalf of particular logical entities within the 2722 system. 2724 It is thus important to control even GET access to these objects 2725 and possibly to even encrypt the values of these object when 2726 sending them over the network via SNMP. Not all versions of SNMP 2727 provide features for such a secure environment. 2729 SNMPv1 by itself is not a secure environment. Even if the network 2730 itself is secure (for example by using IPSec), even then, there is 2731 no control as to who on the secure network is allowed to access and 2732 GET/SET (read/change/create/delete) the objects in this MIB. 2734 It is recommended that the implementers consider the security 2735 features as provided by the SNMPv3 framework. Specifically, the 2736 use of the User-based Security Model RFC 2574 [RFC2574] and the 2737 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 2739 It is then a customer/user responsibility to ensure that the SNMP 2740 entity giving access to an instance of this MIB, is properly 2741 configured to give access to the objects only to those principals 2742 (users) that have legitimate rights to indeed GET or SET 2743 (change/create/delete) them. 2745 6. IANA Considerations 2747 This document has no actions for IANA. 2749 7. Acknowledgements 2751 This memo has been produced by the IETF's Entity MIB working group. 2753 8. References 2755 8.1. Normative References 2757 [RFC2026] 2758 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2759 2026, October, 1996. 2761 [RFC2396] 2762 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource 2763 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 2765 [RFC2578] 2766 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2767 and S. Waldbusser, "Structure of Management Information Version 2 2768 (SMIv2)", STD 58, RFC 2578, April 1999. 2770 [RFC2579] 2771 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2772 and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2773 2579, April 1999. 2775 [RFC2580] 2776 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2777 and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2778 2580, April 1999. 2780 [RFC3411] 2781 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2782 Describing Simple Network Management Protocol (SNMP) Management 2783 Frameworks", STD 62, RFC 3411, December 2002. 2785 [RFC3417] 2786 R. Presuhn, Ed., "Transport Mappings for the Simple Network 2787 Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 2789 8.2. Informative References 2791 [RFC1157] 2792 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2793 Management Protocol", STD 15, RFC 1157, May 1990. 2795 [RFC1493] 2796 Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, 2797 "Definitions of Managed Objects for Bridges", RFC 1493, July, 1993. 2799 [RFC1516] 2800 McMaster, D., and K. McCloghrie, "Definitions of Managed Objects 2801 for IEEE 802.3 Repeater Devices", RFC 1516, September, 1993. 2803 [RFC2037] 2804 McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037, 2805 October 1996. 2807 [RFC2108] 2808 de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, 2809 "Definitions of Managed Objects for IEEE 802.3 Repeater Devices 2810 using SMIv2", RFC 2108, February, 1997. 2812 [RFC2863] 2813 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 2814 2863, June, 2000. 2816 [RFC2737] 2817 McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, 2818 December 1999. 2820 [RFC3406] 2821 Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform 2822 Resource Names (URN) Namespace Definition Mechanisms", RFC 3406, 2823 October 2002. 2825 [RFC3410] 2826 Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and 2827 Applicability Statements for Internet- Standard Management 2828 Framework", RFC 3410, December 2002. 2830 [RFCCLEIURN] 2831 Tesink, K., and Robert H. Fox, "A Uniform Resource Name (URN) 2832 Namespace for the CLEI Code", Work in progress, November 7, 2004. 2834 [T1.213] 2835 ATIS T1.213-2001, "Coded Identification of Equipment Entities in 2836 the North American Telecommunications System for Information 2837 Exchange", 2001, www.ansi.org. 2839 [T1.213a] 2840 ATIS T1.213a, "Supplement to T1.213-2001, Coded Identification of 2841 Equipment Entities in the North American Telecommunications System 2842 for Information Exchange, to correct the representation of the 2843 Basic Code in Figure B.1", 2001, www.ansi.org. 2845 Authors' Addresses 2847 Andy Bierman 2848 Cisco Systems, Inc. 2849 170 West Tasman Drive 2850 San Jose, CA 95134 USA 2851 Phone: +1 408-527-3711 2852 Email: abierman@cisco.com 2854 Keith McCloghrie 2855 Cisco Systems, Inc. 2856 170 West Tasman Drive 2857 San Jose, CA 95134 USA 2858 Phone: +1 408-526-5260 2859 Email: kzm@cisco.com 2861 Intellectual Property Statement 2863 The IETF takes no position regarding the validity or scope of any 2864 Intellectual Property Rights or other rights that might be claimed 2865 to pertain to the implementation or use of the technology described 2866 in this document or the extent to which any license under such 2867 rights might or might not be available; nor does it represent that 2868 it has made any independent effort to identify any such rights. 2869 Information on the procedures with respect to rights in RFC 2870 documents can be found in BCP 78 and BCP 79. 2872 Copies of IPR disclosures made to the IETF Secretariat and any 2873 assurances of licenses to be made available, or the result of an 2874 attempt made to obtain a general license or permission for the use 2875 of such proprietary rights by implementers or users of this 2876 specification can be obtained from the IETF on-line IPR repository 2877 at http://www.ietf.org/ipr. 2879 The IETF invites any interested party to bring to its attention any 2880 copyrights, patents or patent applications, or other proprietary 2881 rights that may cover technology that may be required to implement 2882 this standard. Please address the information to the IETF at ietf- 2883 ipr@ietf.org. 2885 Disclaimer of Validity 2887 This document and the information contained herein are provided on 2888 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2889 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 2890 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2891 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2892 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2893 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2894 PARTICULAR PURPOSE. 2896 Copyright Statement 2898 Copyright (C) The Internet Society (2005). This document is 2899 subject to the rights, licenses and restrictions contained in BCP 2900 78, and except as set forth therein, the authors retain all their 2901 rights. 2903 Acknowledgment 2905 Funding for the RFC Editor function is currently provided by the 2906 Internet Society.