idnits 2.17.1 draft-ietf-entmib-v3-07.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 2906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2895. ** 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 (19 January 2005) is 7036 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 464, but not defined == Missing Reference: 'RFC2574' is mentioned on line 2740, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Missing Reference: 'RFC2575' is mentioned on line 2741, but not defined ** Obsolete undefined reference: RFC 2575 (Obsoleted by RFC 3415) == Unused Reference: 'RFC2026' is defined on line 2769, 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 19 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 21 Internet-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 354 read-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 424 non-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. The special value '0000000000000000'H 444 may also be returned in this case. 446 - entPhysicalUris 447 This object provides additional identification information about 448 the physical entity. 450 The object contains one or more Uniform Resource Identifiers (URIs) 451 and therefore the syntax of this object must conform to RFC 2396 452 [RFC2396] section 2. Uniform Resource Names (URNs), RFC 3406 453 [RFC3406], are resource identifiers with the specific requirements 454 for enabling location independent identification of a resource, as 455 well as longevity of reference. URNs are part of the larger URI 456 family with the specific goal of providing persistent naming of 457 resources. URI schemes and URN name spaces are registered by IANA 458 (see http://www.iana.org/assignments/uri-schemes and 459 http://www.iana.org/assignments/urn-namespaces). 461 The entPhysicalUris object may be used to encode for example a URI 462 containing a Common Language Equipment Identifier (CLEI) URI for 463 the managed physical entity. The URN name space for CLEIs is 464 defined in [RFC CLEIURN], and the CLEI format is defined in 465 [T1.213][T1.213a]. For example, an entPhysicalUris instance may 466 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 "200501190000Z" 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 "200501190000Z" 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 - DISPLAY-HINT clause to PhysicalIndex TC 686 - PhysicalIndexOrZero TC 687 - entPhysicalMfgDate object 688 - entPhysicalUris object 689 Changes: 690 - entPhysicalContainedIn SYNTAX changed from 691 INTEGER to PhysicalIndexOrZero 693 This version published as RFC xxxx." 694 -- RFC Ed.: replace xxxx with actual RFC number & remove this notice 696 REVISION "199912070000Z" 697 DESCRIPTION 698 "Initial Version of Entity MIB (Version 2). 699 This revision obsoletes RFC 2037. 700 This version published as RFC 2737." 702 REVISION "199610310000Z" 703 DESCRIPTION 704 "Initial version (version 1), published as 705 RFC 2037." 706 ::= { mib-2 47 } 708 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 710 -- MIB contains four groups 711 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } 712 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } 713 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } 714 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } 716 -- Textual Conventions 717 PhysicalIndex ::= TEXTUAL-CONVENTION 718 DISPLAY-HINT "d" 719 STATUS current 720 DESCRIPTION 721 "An arbitrary value which uniquely identifies the physical 722 entity. The value should be a small positive integer; index 723 values for different physical entities are not necessarily 724 contiguous." 725 SYNTAX Integer32 (1..2147483647) 727 PhysicalIndexOrZero ::= TEXTUAL-CONVENTION 728 DISPLAY-HINT "d" 729 STATUS current 730 DESCRIPTION 731 "This textual convention is an extension of the 732 PhysicalIndex convention which defines a greater than zero 733 value used to identify a physical entity. This extension 734 permits the additional value of zero. The semantics of the 735 value zero are object-specific and must therefore be defined 736 as part of the description of any object which uses this 737 syntax. Examples of the usage of this extension are 738 situations where none or all physical entities need to be 739 referenced." 740 SYNTAX Integer32 (0..2147483647) 742 PhysicalClass ::= TEXTUAL-CONVENTION 743 STATUS current 744 DESCRIPTION 745 "An enumerated value which provides an indication of the 746 general hardware type of a particular physical entity. 747 There are no restrictions as to the number of 748 entPhysicalEntries of each entPhysicalClass, which must be 749 instantiated by an agent. 751 The enumeration 'other' is applicable if the physical entity 752 class is known, but does not match any of the supported 753 values. 755 The enumeration 'unknown' is applicable if the physical 756 entity class is unknown to the agent. 758 The enumeration 'chassis' is applicable if the physical 759 entity class is an overall container for networking 760 equipment. Any class of physical entity except a stack may 761 be contained within a chassis, and a chassis may only be 762 contained within a stack. 764 The enumeration 'backplane' is applicable if the physical 765 entity class is some sort of device for aggregating and 766 forwarding networking traffic, such as a shared backplane in 767 a modular ethernet switch. Note that an agent may model a 768 backplane as a single physical entity, which is actually 769 implemented as multiple discrete physical components (within 770 a chassis or stack). 772 The enumeration 'container' is applicable if the physical 773 entity class is capable of containing one or more removable 774 physical entities, possibly of different types. For example, 775 each (empty or full) slot in a chassis will be modeled as a 776 container. Note that all removable physical entities should 777 be modeled within a container entity, such as 778 field-replaceable modules, fans, or power supplies. Note 779 that all known containers should be modeled by the agent, 780 including empty containers. 782 The enumeration 'powerSupply' is applicable if the physical 783 entity class is a power-supplying component. 785 The enumeration 'fan' is applicable if the physical entity 786 class is a fan or other heat-reduction component. 788 The enumeration 'sensor' is applicable if the physical 789 entity class is some sort of sensor, such as a temperature 790 sensor within a router chassis. 792 The enumeration 'module' is applicable if the physical 793 entity class is some sort of self-contained sub-system. If 794 it is removable, then it should be modeled within a 795 container entity, otherwise it should be modeled directly 796 within another physical entity (e.g., a chassis or another 797 module). 799 The enumeration 'port' is applicable if the physical entity 800 class is some sort of networking port, capable of receiving 801 and/or transmitting networking traffic. 803 The enumeration 'stack' is applicable if the physical entity 804 class is some sort of super-container (possibly virtual), 805 intended to group together multiple chassis entities. A 806 stack may be realized by a 'virtual' cable, a real 807 interconnect cable, attached to multiple chassis, or may in 808 fact be comprised of multiple interconnect cables. A stack 809 should not be modeled within any other physical entities, 810 but a stack may be contained within another stack. Only 811 chassis entities should be contained within a stack. 813 The enumeration 'cpu' is applicable if the physical entity 814 class is some sort of central processing unit." 815 SYNTAX INTEGER { 816 other(1), 817 unknown(2), 818 chassis(3), 819 backplane(4), 820 container(5), -- e.g., chassis slot or daughter-card holder 821 powerSupply(6), 822 fan(7), 823 sensor(8), 824 module(9), -- e.g., plug-in card or daughter-card 825 port(10), 826 stack(11), -- e.g., stack of multiple chassis entities 827 cpu(12) 828 } 830 SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION 831 STATUS current 832 DESCRIPTION 833 "A specially formatted SnmpEngineID string for use with the 834 Entity MIB. 836 If an instance of an object of SYNTAX SnmpEngineIdOrNone has 837 a non-zero length, then the object encoding and semantics 838 are defined by the SnmpEngineID textual convention (see STD 839 62, RFC 3411 [RFC3411]). 841 If an instance of an object of SYNTAX SnmpEngineIdOrNone 842 contains a zero-length string, then no appropriate 843 SnmpEngineID is associated with the logical entity (i.e., 844 SNMPv3 not supported)." 845 SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID 847 -- The Physical Entity Table 848 entPhysicalTable OBJECT-TYPE 849 SYNTAX SEQUENCE OF EntPhysicalEntry 850 MAX-ACCESS not-accessible 851 STATUS current 852 DESCRIPTION 853 "This table contains one row per physical entity. There is 854 always at least one row for an 'overall' physical entity." 855 ::= { entityPhysical 1 } 857 entPhysicalEntry OBJECT-TYPE 858 SYNTAX EntPhysicalEntry 859 MAX-ACCESS not-accessible 860 STATUS current 861 DESCRIPTION 862 "Information about a particular physical entity. 864 Each entry provides objects (entPhysicalDescr, 865 entPhysicalVendorType, and entPhysicalClass) to help an NMS 866 identify and characterize the entry, and objects 867 (entPhysicalContainedIn and entPhysicalParentRelPos) to help 868 an NMS relate the particular entry to other entries in this 869 table." 870 INDEX { entPhysicalIndex } 871 ::= { entPhysicalTable 1 } 873 EntPhysicalEntry ::= SEQUENCE { 874 entPhysicalIndex PhysicalIndex, 875 entPhysicalDescr SnmpAdminString, 876 entPhysicalVendorType AutonomousType, 877 entPhysicalContainedIn PhysicalIndexOrZero, 878 entPhysicalClass PhysicalClass, 879 entPhysicalParentRelPos Integer32, 880 entPhysicalName SnmpAdminString, 881 entPhysicalHardwareRev SnmpAdminString, 882 entPhysicalFirmwareRev SnmpAdminString, 883 entPhysicalSoftwareRev SnmpAdminString, 884 entPhysicalSerialNum SnmpAdminString, 885 entPhysicalMfgName SnmpAdminString, 886 entPhysicalModelName SnmpAdminString, 887 entPhysicalAlias SnmpAdminString, 888 entPhysicalAssetID SnmpAdminString, 889 entPhysicalIsFRU TruthValue, 890 entPhysicalMfgDate DateAndTime, 891 entPhysicalUris OCTET STRING 893 } 895 entPhysicalIndex OBJECT-TYPE 896 SYNTAX PhysicalIndex 897 MAX-ACCESS not-accessible 898 STATUS current 899 DESCRIPTION 900 "The index for this entry." 901 ::= { entPhysicalEntry 1 } 903 entPhysicalDescr OBJECT-TYPE 904 SYNTAX SnmpAdminString 905 MAX-ACCESS read-only 906 STATUS current 907 DESCRIPTION 908 "A textual description of physical entity. This object 909 should contain a string which identifies the manufacturer's 910 name for the physical entity, and should be set to a 911 distinct value for each version or model of the physical 912 entity. " 913 ::= { entPhysicalEntry 2 } 915 entPhysicalVendorType OBJECT-TYPE 916 SYNTAX AutonomousType 917 MAX-ACCESS read-only 918 STATUS current 919 DESCRIPTION 920 "An indication of the vendor-specific hardware type of the 921 physical entity. Note that this is different from the 922 definition of MIB-II's sysObjectID. 924 An agent should set this object to a enterprise-specific 925 registration identifier value indicating the specific 926 equipment type in detail. The associated instance of 927 entPhysicalClass is used to indicate the general type of 928 hardware device. 930 If no vendor-specific registration identifier exists for 931 this physical entity, or the value is unknown by this agent, 932 then the value { 0 0 } is returned." 933 ::= { entPhysicalEntry 3 } 935 entPhysicalContainedIn OBJECT-TYPE 936 SYNTAX PhysicalIndexOrZero 937 MAX-ACCESS read-only 938 STATUS current 939 DESCRIPTION 940 "The value of entPhysicalIndex for the physical entity which 941 'contains' this physical entity. A value of zero indicates 942 this physical entity is not contained in any other physical 943 entity. Note that the set of 'containment' relationships 944 define a strict hierarchy; that is, recursion is not 945 allowed. 947 In the event a physical entity is contained by more than one 948 physical entity (e.g., double-wide modules), this object 949 should identify the containing entity with the lowest value 950 of entPhysicalIndex." 951 ::= { entPhysicalEntry 4 } 953 entPhysicalClass OBJECT-TYPE 954 SYNTAX PhysicalClass 955 MAX-ACCESS read-only 956 STATUS current 957 DESCRIPTION 958 "An indication of the general hardware type of the physical 959 entity. 961 An agent should set this object to the standard enumeration 962 value which most accurately indicates the general class of 963 the physical entity, or the primary class if there is more 964 than one. 966 If no appropriate standard registration identifier exists 967 for this physical entity, then the value 'other(1)' is 968 returned. If the value is unknown by this agent, then the 969 value 'unknown(2)' is returned." 970 ::= { entPhysicalEntry 5 } 972 entPhysicalParentRelPos OBJECT-TYPE 973 SYNTAX Integer32 (-1..2147483647) 974 MAX-ACCESS read-only 975 STATUS current 976 DESCRIPTION 977 "An indication of the relative position of this 'child' 978 component among all its 'sibling' components. Sibling 979 components are defined as entPhysicalEntries which share the 980 same instance values of each of the entPhysicalContainedIn 981 and entPhysicalClass objects. 983 An NMS can use this object to identify the relative ordering 984 for all sibling components of a particular parent 985 (identified by the entPhysicalContainedIn instance in each 986 sibling entry). 988 This value should match any external labeling of the 989 physical component if possible. For example, for a container 990 (e.g., card slot) labeled as 'slot #3', 991 entPhysicalParentRelPos should have the value '3'. Note 992 that the entPhysicalEntry for the module plugged in slot 3 993 should have an entPhysicalParentRelPos value of '1'. 995 If the physical position of this component does not match 996 any external numbering or clearly visible ordering, then 997 user documentation or other external reference material 998 should be used to determine the parent-relative position. If 999 this is not possible, then the the agent should assign a 1000 consistent (but possibly arbitrary) ordering to a given set 1001 of 'sibling' components, perhaps based on internal 1002 representation of the components. 1004 If the agent cannot determine the parent-relative position 1005 for some reason, or if the associated value of 1006 entPhysicalContainedIn is '0', then the value '-1' is 1007 returned. Otherwise a non-negative integer is returned, 1008 indicating the parent-relative position of this physical 1009 entity. 1011 Parent-relative ordering normally starts from '1' and 1012 continues to 'N', where 'N' represents the highest 1013 positioned child entity. However, if the physical entities 1014 (e.g., slots) are labeled from a starting position of zero, 1015 then the first sibling should be associated with a 1016 entPhysicalParentRelPos value of '0'. Note that this 1017 ordering may be sparse or dense, depending on agent 1018 implementation. 1020 The actual values returned are not globally meaningful, as 1021 each 'parent' component may use different numbering 1022 algorithms. The ordering is only meaningful among siblings 1023 of the same parent component. 1025 The agent should retain parent-relative position values 1026 across reboots, either through algorithmic assignment or use 1027 of non-volatile storage." 1028 ::= { entPhysicalEntry 6 } 1030 entPhysicalName OBJECT-TYPE 1031 SYNTAX SnmpAdminString 1032 MAX-ACCESS read-only 1033 STATUS current 1034 DESCRIPTION 1035 "The textual name of the physical entity. The value of this 1036 object should be the name of the component as assigned by 1037 the local device and should be suitable for use in commands 1038 entered at the device's `console'. This might be a text 1039 name, such as `console' or a simple component number (e.g., 1040 port or module number), such as `1', depending on the 1041 physical component naming syntax of the device. 1043 If there is no local name, or this object is otherwise not 1044 applicable, then this object contains a zero-length string. 1046 Note that the value of entPhysicalName for two physical 1047 entities will be the same in the event that the console 1048 interface does not distinguish between them, e.g., slot-1 1049 and the card in slot-1." 1050 ::= { entPhysicalEntry 7 } 1052 entPhysicalHardwareRev OBJECT-TYPE 1053 SYNTAX SnmpAdminString 1054 MAX-ACCESS read-only 1055 STATUS current 1056 DESCRIPTION 1057 "The vendor-specific hardware revision string for the 1058 physical entity. The preferred value is the hardware 1059 revision identifier actually printed on the component itself 1060 (if present). 1062 Note that if revision information is stored internally in a 1063 non-printable (e.g., binary) format, then the agent must 1064 convert such information to a printable format, in an 1065 implementation-specific manner. 1067 If no specific hardware revision string is associated with 1068 the physical component, or this information is unknown to 1069 the agent, then this object will contain a zero-length 1070 string." 1071 ::= { entPhysicalEntry 8 } 1073 entPhysicalFirmwareRev OBJECT-TYPE 1074 SYNTAX SnmpAdminString 1075 MAX-ACCESS read-only 1076 STATUS current 1077 DESCRIPTION 1078 "The vendor-specific firmware revision string for the 1079 physical entity. 1081 Note that if revision information is stored internally in a 1082 non-printable (e.g., binary) format, then the agent must 1083 convert such information to a printable format, in an 1084 implementation-specific manner. 1086 If no specific firmware programs are associated with the 1087 physical component, or this information is unknown to the 1088 agent, then this object will contain a zero-length string." 1089 ::= { entPhysicalEntry 9 } 1091 entPhysicalSoftwareRev OBJECT-TYPE 1092 SYNTAX SnmpAdminString 1093 MAX-ACCESS read-only 1094 STATUS current 1095 DESCRIPTION 1096 "The vendor-specific software revision string for the 1097 physical entity. 1099 Note that if revision information is stored internally in a 1100 non-printable (e.g., binary) format, then the agent must 1101 convert such information to a printable format, in an 1102 implementation-specific manner. 1104 If no specific software programs are associated with the 1105 physical component, or this information is unknown to the 1106 agent, then this object will contain a zero-length string." 1107 ::= { entPhysicalEntry 10 } 1109 entPhysicalSerialNum OBJECT-TYPE 1110 SYNTAX SnmpAdminString (SIZE (0..32)) 1111 MAX-ACCESS read-write 1112 STATUS current 1113 DESCRIPTION 1114 "The vendor-specific serial number string for the physical 1115 entity. The preferred value is the serial number string 1116 actually printed on the component itself (if present). 1118 On the first instantiation of an physical entity, the value 1119 of entPhysicalSerialNum associated with that entity is set 1120 to the correct vendor-assigned serial number, if this 1121 information is available to the agent. If a serial number 1122 is unknown or non-existent, the entPhysicalSerialNum will be 1123 set to a zero-length string instead. 1125 Note that implementations which can correctly identify the 1126 serial numbers of all installed physical entities do not 1127 need to provide write access to the entPhysicalSerialNum 1128 object. Agents which cannot provide non-volatile storage for 1129 the entPhysicalSerialNum strings are not required to 1130 implement write access for this object. 1132 Not every physical component will have a serial number, or 1133 even need one. Physical entities for which the associated 1134 value of the entPhysicalIsFRU object is equal to 'false(2)' 1135 (e.g., the repeater ports within a repeater module), do not 1136 need their own unique serial number. An agent does not have 1137 to provide write access for such entities, and may return a 1138 zero-length string. 1140 If write access is implemented for an instance of 1141 entPhysicalSerialNum, and a value is written into the 1142 instance, the agent must retain the supplied value in the 1143 entPhysicalSerialNum instance associated with the same 1144 physical entity for as long as that entity remains 1145 instantiated. This includes instantiations across all 1146 re-initializations/reboots of the network management system, 1147 including those which result in a change of the physical 1148 entity's entPhysicalIndex value." 1149 ::= { entPhysicalEntry 11 } 1151 entPhysicalMfgName OBJECT-TYPE 1152 SYNTAX SnmpAdminString 1153 MAX-ACCESS read-only 1154 STATUS current 1155 DESCRIPTION 1156 "The name of the manufacturer of this physical component. 1157 The preferred value is the manufacturer name string actually 1158 printed on the component itself (if present). 1160 Note that comparisons between instances of the 1161 entPhysicalModelName, entPhysicalFirmwareRev, 1162 entPhysicalSoftwareRev, and the entPhysicalSerialNum 1163 objects, are only meaningful amongst entPhysicalEntries with 1164 the same value of entPhysicalMfgName. 1166 If the manufacturer name string associated with the physical 1167 component is unknown to the agent, then this object will 1168 contain a zero-length string." 1169 ::= { entPhysicalEntry 12 } 1171 entPhysicalModelName OBJECT-TYPE 1172 SYNTAX SnmpAdminString 1173 MAX-ACCESS read-only 1174 STATUS current 1175 DESCRIPTION 1176 "The vendor-specific model name identifier string associated 1177 with this physical component. The preferred value is the 1178 customer-visible part number, which may be printed on the 1179 component itself. 1181 If the model name string associated with the physical 1182 component is unknown to the agent, then this object will 1183 contain a zero-length string." 1184 ::= { entPhysicalEntry 13 } 1186 entPhysicalAlias OBJECT-TYPE 1187 SYNTAX SnmpAdminString (SIZE (0..32)) 1188 MAX-ACCESS read-write 1189 STATUS current 1190 DESCRIPTION 1191 "This object is an 'alias' name for the physical entity as 1192 specified by a network manager, and provides a non-volatile 1193 'handle' for the physical entity. 1195 On the first instantiation of an physical entity, the value 1196 of entPhysicalAlias associated with that entity is set to 1197 the zero-length string. However, agent may set the value to 1198 a locally unique default value, instead of a zero-length 1199 string. 1201 If write access is implemented for an instance of 1202 entPhysicalAlias, and a value is written into the instance, 1203 the agent must retain the supplied value in the 1204 entPhysicalAlias instance associated with the same physical 1205 entity for as long as that entity remains instantiated. 1206 This includes instantiations across all 1207 re-initializations/reboots of the network management system, 1208 including those which result in a change of the physical 1209 entity's entPhysicalIndex value." 1210 ::= { entPhysicalEntry 14 } 1212 entPhysicalAssetID OBJECT-TYPE 1213 SYNTAX SnmpAdminString (SIZE (0..32)) 1214 MAX-ACCESS read-write 1215 STATUS current 1216 DESCRIPTION 1217 "This object is a user-assigned asset tracking identifier 1218 for the physical entity as specified by a network manager, 1219 and provides non-volatile storage of this information. 1221 On the first instantiation of an physical entity, the value 1222 of entPhysicalAssetID associated with that entity is set to 1223 the zero-length string. 1225 Not every physical component will have a asset tracking 1226 identifier, or even need one. Physical entities for which 1227 the associated value of the entPhysicalIsFRU object is equal 1228 to 'false(2)' (e.g., the repeater ports within a repeater 1229 module), do not need their own unique asset tracking 1230 identifier. An agent does not have to provide write access 1231 for such entities, and may instead return a zero-length 1232 string. 1234 If write access is implemented for an instance of 1235 entPhysicalAssetID, and a value is written into the 1236 instance, the agent must retain the supplied value in the 1237 entPhysicalAssetID instance associated with the same 1238 physical entity for as long as that entity remains 1239 instantiated. This includes instantiations across all 1240 re-initializations/reboots of the network management system, 1241 including those which result in a change of the physical 1242 entity's entPhysicalIndex value. 1244 If no asset tracking information is associated with the 1245 physical component, then this object will contain a 1246 zero-length string." 1247 ::= { entPhysicalEntry 15 } 1249 entPhysicalIsFRU OBJECT-TYPE 1250 SYNTAX TruthValue 1251 MAX-ACCESS read-only 1252 STATUS current 1253 DESCRIPTION 1254 "This object indicates whether or not this physical entity 1255 is considered a 'field replaceable unit' by the vendor. If 1256 this object contains the value 'true(1)' then this 1257 entPhysicalEntry identifies a field replaceable unit. For 1258 all entPhysicalEntries which represent components that are 1259 permanently contained within a field replaceable unit, the 1260 value 'false(2)' should be returned for this object." 1262 ::= { entPhysicalEntry 16 } 1264 entPhysicalMfgDate OBJECT-TYPE 1265 SYNTAX DateAndTime 1266 MAX-ACCESS read-only 1267 STATUS current 1268 DESCRIPTION 1269 "This object contains the date of manufacturing of the 1270 managed entity. If the manufacturing date is unknown or not 1271 supported the object is not instantiated. The special value 1272 '0000000000000000'H may also be returned in this case." 1273 ::= { entPhysicalEntry 17 } 1275 entPhysicalUris OBJECT-TYPE 1276 SYNTAX OCTET STRING 1277 MAX-ACCESS read-write 1278 STATUS current 1279 DESCRIPTION 1280 "This object contains additional identification information 1281 about the physical entity. The object contains URIs and 1282 therefore the syntax of this object must conform to RFC 1283 2396, section 2. 1285 Multiple URIs may be present and are separated by white 1286 space characters. Leading and trailing white space 1287 characters are ignored. 1289 If no additional identification information is known or 1290 supported about the physical entity the object is not 1291 instantiated. A zero length octet string may also be 1292 returned in this case." 1293 REFERENCE 1294 "RFC 2396, Uniform Resource Identifiers (URI): Generic 1295 Syntax, section 2, August 1998." 1297 ::= { entPhysicalEntry 18 } 1299 -- The Logical Entity Table 1300 entLogicalTable OBJECT-TYPE 1301 SYNTAX SEQUENCE OF EntLogicalEntry 1302 MAX-ACCESS not-accessible 1303 STATUS current 1304 DESCRIPTION 1305 "This table contains one row per logical entity. For agents 1306 which implement more than one naming scope, at least one 1307 entry must exist. Agents which instantiate all MIB objects 1308 within a single naming scope are not required to implement 1309 this table." 1310 ::= { entityLogical 1 } 1312 entLogicalEntry OBJECT-TYPE 1313 SYNTAX EntLogicalEntry 1314 MAX-ACCESS not-accessible 1315 STATUS current 1316 DESCRIPTION 1317 "Information about a particular logical entity. Entities 1318 may be managed by this agent or other SNMP agents (possibly) 1319 in the same chassis." 1320 INDEX { entLogicalIndex } 1321 ::= { entLogicalTable 1 } 1323 EntLogicalEntry ::= SEQUENCE { 1324 entLogicalIndex Integer32, 1325 entLogicalDescr SnmpAdminString, 1326 entLogicalType AutonomousType, 1327 entLogicalCommunity OCTET STRING, 1328 entLogicalTAddress TAddress, 1329 entLogicalTDomain TDomain, 1330 entLogicalContextEngineID SnmpEngineIdOrNone, 1331 entLogicalContextName SnmpAdminString 1332 } 1334 entLogicalIndex OBJECT-TYPE 1335 SYNTAX Integer32 (1..2147483647) 1336 MAX-ACCESS not-accessible 1337 STATUS current 1338 DESCRIPTION 1339 "The value of this object uniquely identifies the logical 1340 entity. The value should be a small positive integer; index 1341 values for different logical entities are are not 1342 necessarily contiguous." 1343 ::= { entLogicalEntry 1 } 1345 entLogicalDescr OBJECT-TYPE 1346 SYNTAX SnmpAdminString 1347 MAX-ACCESS read-only 1348 STATUS current 1349 DESCRIPTION 1350 "A textual description of the logical entity. This object 1351 should contain a string which identifies the manufacturer's 1352 name for the logical entity, and should be set to a distinct 1353 value for each version of the logical entity. " 1354 ::= { entLogicalEntry 2 } 1356 entLogicalType OBJECT-TYPE 1357 SYNTAX AutonomousType 1358 MAX-ACCESS read-only 1359 STATUS current 1360 DESCRIPTION 1361 "An indication of the type of logical entity. This will 1362 typically be the OBJECT IDENTIFIER name of the node in the 1363 SMI's naming hierarchy which represents the major MIB 1364 module, or the majority of the MIB modules, supported by the 1365 logical entity. For example: 1366 a logical entity of a regular host/router -> mib-2 1367 a logical entity of a 802.1d bridge -> dot1dBridge 1368 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 1369 If an appropriate node in the SMI's naming hierarchy cannot 1370 be identified, the value 'mib-2' should be used." 1371 ::= { entLogicalEntry 3 } 1373 entLogicalCommunity OBJECT-TYPE 1374 SYNTAX OCTET STRING (SIZE (0..255)) 1375 MAX-ACCESS read-only 1376 STATUS deprecated 1377 DESCRIPTION 1378 "An SNMPv1 or SNMPv2C community-string which can be used to 1379 access detailed management information for this logical 1380 entity. The agent should allow read access with this 1381 community string (to an appropriate subset of all managed 1382 objects) and may also return a community string based on the 1383 privileges of the request used to read this object. Note 1384 that an agent may return a community string with read-only 1385 privileges, even if this object is accessed with a 1386 read-write community string. However, the agent must take 1387 care not to return a community string which allows more 1388 privileges than the community string used to access this 1389 object. 1391 A compliant SNMP agent may wish to conserve naming scopes by 1392 representing multiple logical entities in a single 'default' 1393 naming scope. This is possible when the logical entities 1394 represented by the same value of entLogicalCommunity have no 1395 object instances in common. For example, 'bridge1' and 1396 'repeater1' may be part of the main naming scope, but at 1397 least one additional community string is needed to represent 1398 'bridge2' and 'repeater2'. 1400 Logical entities 'bridge1' and 'repeater1' would be 1401 represented by sysOREntries associated with the 'default' 1402 naming scope. 1404 For agents not accessible via SNMPv1 or SNMPv2C, the value 1405 of this object is the empty string. This object may also 1406 contain an empty string if a community string has not yet 1407 been assigned by the agent, or no community string with 1408 suitable access rights can be returned for a particular SNMP 1409 request. 1411 Note that this object is deprecated. Agents which implement 1412 SNMPv3 access should use the entLogicalContextEngineID and 1413 entLogicalContextName objects to identify the context 1414 associated with each logical entity. SNMPv3 agents may 1415 return a zero-length string for this object, or may continue 1416 to return a community string (e.g., tri-lingual agent 1417 support)." 1418 ::= { entLogicalEntry 4 } 1420 entLogicalTAddress OBJECT-TYPE 1421 SYNTAX TAddress 1422 MAX-ACCESS read-only 1423 STATUS current 1424 DESCRIPTION 1425 "The transport service address by which the logical entity 1426 receives network management traffic, formatted according to 1427 the corresponding value of entLogicalTDomain. 1429 For snmpUDPDomain, a TAddress is 6 octets long, the initial 1430 4 octets containing the IP-address in network-byte order and 1431 the last 2 containing the UDP port in network-byte order. 1432 Consult 'Transport Mappings for the Simple Network 1433 Management Protocol' (STD 62, RFC 3417 [RFC3417]) for 1434 further information on snmpUDPDomain." 1435 ::= { entLogicalEntry 5 } 1437 entLogicalTDomain OBJECT-TYPE 1438 SYNTAX TDomain 1439 MAX-ACCESS read-only 1440 STATUS current 1441 DESCRIPTION 1442 "Indicates the kind of transport service by which the 1443 logical entity receives network management traffic. 1444 Possible values for this object are presently found in the 1445 Transport Mappings for Simple Network Management Protocol' 1446 (STD 62, RFC 3417 [RFC3417])." 1447 ::= { entLogicalEntry 6 } 1449 entLogicalContextEngineID OBJECT-TYPE 1450 SYNTAX SnmpEngineIdOrNone 1451 MAX-ACCESS read-only 1452 STATUS current 1453 DESCRIPTION 1454 "The authoritative contextEngineID that can be used to send 1455 an SNMP message concerning information held by this logical 1456 entity, to the address specified by the associated 1457 'entLogicalTAddress/entLogicalTDomain' pair. 1459 This object, together with the associated 1460 entLogicalContextName object, defines the context associated 1461 with a particular logical entity, and allows access to SNMP 1462 engines identified by a contextEngineId and contextName 1463 pair. 1465 If no value has been configured by the agent, a zero-length 1466 string is returned, or the agent may choose not to 1467 instantiate this object at all." 1468 ::= { entLogicalEntry 7 } 1470 entLogicalContextName OBJECT-TYPE 1471 SYNTAX SnmpAdminString 1472 MAX-ACCESS read-only 1473 STATUS current 1474 DESCRIPTION 1475 "The contextName that can be used to send an SNMP message 1476 concerning information held by this logical entity, to the 1477 address specified by the associated 1478 'entLogicalTAddress/entLogicalTDomain' pair. 1480 This object, together with the associated 1481 entLogicalContextEngineID object, defines the context 1482 associated with a particular logical entity, and allows 1483 access to SNMP engines identified by a contextEngineId and 1484 contextName pair. 1486 If no value has been configured by the agent, a zero-length 1487 string is returned, or the agent may choose not to 1488 instantiate this object at all." 1489 ::= { entLogicalEntry 8 } 1491 entLPMappingTable OBJECT-TYPE 1492 SYNTAX SEQUENCE OF EntLPMappingEntry 1493 MAX-ACCESS not-accessible 1494 STATUS current 1495 DESCRIPTION 1496 "This table contains zero or more rows of logical entity to 1497 physical equipment associations. For each logical entity 1498 known by this agent, there are zero or more mappings to the 1499 physical resources which are used to realize that logical 1500 entity. 1502 An agent should limit the number and nature of entries in 1503 this table such that only meaningful and non-redundant 1504 information is returned. For example, in a system which 1505 contains a single power supply, mappings between logical 1506 entities and the power supply are not useful and should not 1507 be included. 1509 Also, only the most appropriate physical component which is 1510 closest to the root of a particular containment tree should 1511 be identified in an entLPMapping entry. 1513 For example, suppose a bridge is realized on a particular 1514 module, and all ports on that module are ports on this 1515 bridge. A mapping between the bridge and the module would be 1516 useful, but additional mappings between the bridge and each 1517 of the ports on that module would be redundant (since the 1518 entPhysicalContainedIn hierarchy can provide the same 1519 information). If, on the other hand, more than one bridge 1520 was utilizing ports on this module, then mappings between 1521 each bridge and the ports it used would be appropriate. 1523 Also, in the case of a single backplane repeater, a mapping 1524 for the backplane to the single repeater entity is not 1525 necessary." 1526 ::= { entityMapping 1 } 1528 entLPMappingEntry OBJECT-TYPE 1529 SYNTAX EntLPMappingEntry 1530 MAX-ACCESS not-accessible 1531 STATUS current 1532 DESCRIPTION 1533 "Information about a particular logical entity to physical 1534 equipment association. Note that the nature of the 1535 association is not specifically identified in this entry. 1536 It is expected that sufficient information exists in the 1537 MIBs used to manage a particular logical entity to infer how 1538 physical component information is utilized." 1539 INDEX { entLogicalIndex, entLPPhysicalIndex } 1540 ::= { entLPMappingTable 1 } 1542 EntLPMappingEntry ::= SEQUENCE { 1543 entLPPhysicalIndex PhysicalIndex 1544 } 1546 entLPPhysicalIndex OBJECT-TYPE 1547 SYNTAX PhysicalIndex 1548 MAX-ACCESS read-only 1549 STATUS current 1550 DESCRIPTION 1551 "The value of this object identifies the index value of a 1552 particular entPhysicalEntry associated with the indicated 1553 entLogicalEntity." 1554 ::= { entLPMappingEntry 1 } 1556 -- logical entity/component to alias table 1557 entAliasMappingTable OBJECT-TYPE 1558 SYNTAX SEQUENCE OF EntAliasMappingEntry 1559 MAX-ACCESS not-accessible 1560 STATUS current 1561 DESCRIPTION 1562 "This table contains zero or more rows, representing 1563 mappings of logical entity and physical component to 1564 external MIB identifiers. Each physical port in the system 1565 may be associated with a mapping to an external identifier, 1566 which itself is associated with a particular logical 1567 entity's naming scope. A 'wildcard' mechanism is provided 1568 to indicate that an identifier is associated with more than 1569 one logical entity." 1570 ::= { entityMapping 2 } 1572 entAliasMappingEntry OBJECT-TYPE 1573 SYNTAX EntAliasMappingEntry 1574 MAX-ACCESS not-accessible 1575 STATUS current 1576 DESCRIPTION 1577 "Information about a particular physical equipment, logical 1578 entity to external identifier binding. Each logical 1579 entity/physical component pair may be associated with one 1580 alias mapping. The logical entity index may also be used as 1581 a 'wildcard' (refer to the entAliasLogicalIndexOrZero object 1582 DESCRIPTION clause for details.) 1584 Note that only entPhysicalIndex values which represent 1585 physical ports (i.e. associated entPhysicalClass value is 1586 'port(10)') are permitted to exist in this table." 1587 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 1588 ::= { entAliasMappingTable 1 } 1590 EntAliasMappingEntry ::= SEQUENCE { 1591 entAliasLogicalIndexOrZero Integer32, 1592 entAliasMappingIdentifier RowPointer 1593 } 1595 entAliasLogicalIndexOrZero OBJECT-TYPE 1596 SYNTAX Integer32 (0..2147483647) 1597 MAX-ACCESS not-accessible 1598 STATUS current 1599 DESCRIPTION 1600 "The value of this object identifies the logical entity 1601 which defines the naming scope for the associated instance 1602 of the 'entAliasMappingIdentifier' object. 1604 If this object has a non-zero value, then it identifies the 1605 logical entity named by the same value of entLogicalIndex. 1607 If this object has a value of zero, then the mapping between 1608 the physical component and the alias identifier for this 1609 entAliasMapping entry is associated with all unspecified 1610 logical entities. That is, a value of zero (the default 1611 mapping) identifies any logical entity which does not have 1612 an explicit entry in this table for a particular 1613 entPhysicalIndex/entAliasMappingIdentifier pair. 1615 For example, to indicate that a particular interface (e.g., 1616 physical component 33) is identified by the same value of 1617 ifIndex for all logical entities, the following instance 1618 might exist: 1620 entAliasMappingIdentifier.33.0 = ifIndex.5 1622 In the event an entPhysicalEntry is associated differently 1623 for some logical entities, additional entAliasMapping 1624 entries may exist, e.g.: 1626 entAliasMappingIdentifier.33.0 = ifIndex.6 1627 entAliasMappingIdentifier.33.4 = ifIndex.1 1628 entAliasMappingIdentifier.33.5 = ifIndex.1 1629 entAliasMappingIdentifier.33.10 = ifIndex.12 1631 Note that entries with non-zero entAliasLogicalIndexOrZero 1632 index values have precedence over any zero-indexed entry. In 1633 this example, all logical entities except 4, 5, and 10, 1634 associate physical entity 33 with ifIndex.6." 1635 ::= { entAliasMappingEntry 1 } 1637 entAliasMappingIdentifier OBJECT-TYPE 1638 SYNTAX RowPointer 1639 MAX-ACCESS read-only 1640 STATUS current 1641 DESCRIPTION 1642 "The value of this object identifies a particular conceptual 1643 row associated with the indicated entPhysicalIndex and 1644 entLogicalIndex pair. 1646 Since only physical ports are modeled in this table, only 1647 entries which represent interfaces or ports are allowed. If 1648 an ifEntry exists on behalf of a particular physical port, 1649 then this object should identify the associated 'ifEntry'. 1650 For repeater ports, the appropriate row in the 1651 'rptrPortGroupTable' should be identified instead. 1653 For example, suppose a physical port was represented by 1654 entPhysicalEntry.3, entLogicalEntry.15 existed for a 1655 repeater, and entLogicalEntry.22 existed for a bridge. Then 1656 there might be two related instances of 1657 entAliasMappingIdentifier: 1658 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 1659 entAliasMappingIdentifier.3.22 == ifIndex.17 1660 It is possible that other mappings (besides interfaces and 1661 repeater ports) may be defined in the future, as required. 1663 Bridge ports are identified by examining the Bridge MIB and 1664 appropriate ifEntries associated with each 'dot1dBasePort', 1665 and are thus not represented in this table." 1666 ::= { entAliasMappingEntry 2 } 1668 -- physical mapping table 1669 entPhysicalContainsTable OBJECT-TYPE 1670 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 1671 MAX-ACCESS not-accessible 1672 STATUS current 1673 DESCRIPTION 1674 "A table which exposes the container/'containee' 1675 relationships between physical entities. This table provides 1676 all the information found by constructing the virtual 1677 containment tree for a given entPhysicalTable, but in a more 1678 direct format. 1680 In the event a physical entity is contained by more than one 1681 other physical entity (e.g., double-wide modules), this 1682 table should include these additional mappings, which cannot 1683 be represented in the entPhysicalTable virtual containment 1684 tree." 1685 ::= { entityMapping 3 } 1687 entPhysicalContainsEntry OBJECT-TYPE 1688 SYNTAX EntPhysicalContainsEntry 1689 MAX-ACCESS not-accessible 1690 STATUS current 1691 DESCRIPTION 1692 "A single container/'containee' relationship." 1693 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1694 ::= { entPhysicalContainsTable 1 } 1696 EntPhysicalContainsEntry ::= SEQUENCE { 1697 entPhysicalChildIndex PhysicalIndex 1698 } 1700 entPhysicalChildIndex OBJECT-TYPE 1701 SYNTAX PhysicalIndex 1702 MAX-ACCESS read-only 1703 STATUS current 1704 DESCRIPTION 1705 "The value of entPhysicalIndex for the contained physical 1706 entity." 1707 ::= { entPhysicalContainsEntry 1 } 1709 -- last change time stamp for the whole MIB 1710 entLastChangeTime OBJECT-TYPE 1711 SYNTAX TimeStamp 1712 MAX-ACCESS read-only 1713 STATUS current 1714 DESCRIPTION 1715 "The value of sysUpTime at the time a conceptual row is 1716 created, modified, or deleted in any of these tables: 1717 - entPhysicalTable 1718 - entLogicalTable 1719 - entLPMappingTable 1720 - entAliasMappingTable 1721 - entPhysicalContainsTable 1722 " 1723 ::= { entityGeneral 1 } 1725 -- Entity MIB Trap Definitions 1726 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1727 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1729 entConfigChange NOTIFICATION-TYPE 1730 STATUS current 1731 DESCRIPTION 1732 "An entConfigChange notification is generated when the value 1733 of entLastChangeTime changes. It can be utilized by an NMS 1734 to trigger logical/physical entity table maintenance polls. 1736 An agent should not generate more than one entConfigChange 1737 'notification-event' in a given time interval (five seconds 1738 is the suggested default). A 'notification-event' is the 1739 transmission of a single trap or inform PDU to a list of 1740 notification destinations. 1742 If additional configuration changes occur within the 1743 throttling period, then notification-events for these 1744 changes should be suppressed by the agent until the current 1745 throttling period expires. At the end of a throttling 1746 period, one notification-event should be generated if any 1747 configuration changes occurred since the start of the 1748 throttling period. In such a case, another throttling period 1749 is started right away. 1751 An NMS should periodically check the value of 1752 entLastChangeTime to detect any missed entConfigChange 1753 notification-events, e.g., due to throttling or transmission 1754 loss." 1755 ::= { entityMIBTrapPrefix 1 } 1757 -- conformance information 1758 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1760 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1761 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1763 -- compliance statements 1764 entityCompliance MODULE-COMPLIANCE 1765 STATUS deprecated 1766 DESCRIPTION 1767 "The compliance statement for SNMP entities which implement 1768 version 1 of the Entity MIB." 1769 MODULE -- this module 1770 MANDATORY-GROUPS { 1771 entityPhysicalGroup, 1772 entityLogicalGroup, 1773 entityMappingGroup, 1774 entityGeneralGroup, 1775 entityNotificationsGroup 1776 } 1777 ::= { entityCompliances 1 } 1779 entity2Compliance MODULE-COMPLIANCE 1780 STATUS deprecated 1781 DESCRIPTION 1782 "The compliance statement for SNMP entities which implement 1783 version 2 of the Entity MIB." 1784 MODULE -- this module 1785 MANDATORY-GROUPS { 1786 entityPhysicalGroup, 1787 entityPhysical2Group, 1788 entityGeneralGroup, 1789 entityNotificationsGroup 1790 } 1791 GROUP entityLogical2Group 1792 DESCRIPTION 1793 "Implementation of this group is not mandatory for agents 1794 which model all MIB object instances within a single naming 1795 scope." 1797 GROUP entityMappingGroup 1798 DESCRIPTION 1799 "Implementation of the entPhysicalContainsTable is mandatory 1800 for all agents. Implementation of the entLPMappingTable and 1801 entAliasMappingTables are not mandatory for agents which 1802 model all MIB object instances within a single naming scope. 1804 Note that the entAliasMappingTable may be useful for all 1805 agents, however implementation of the entityLogicalGroup or 1806 entityLogical2Group is required to support this table." 1808 OBJECT entPhysicalSerialNum 1809 MIN-ACCESS not-accessible 1810 DESCRIPTION 1811 "Read and write access is not required for agents which 1812 cannot identify serial number information for physical 1813 entities, and/or cannot provide non-volatile storage for 1814 NMS-assigned serial numbers. 1816 Write access is not required for agents which can identify 1817 serial number information for physical entities, but cannot 1818 provide non-volatile storage for NMS-assigned serial 1819 numbers. 1821 Write access is not required for physical entities for 1822 physical entities for which the associated value of the 1823 entPhysicalIsFRU object is equal to 'false(2)'." 1825 OBJECT entPhysicalAlias 1826 MIN-ACCESS read-only 1827 DESCRIPTION 1828 "Write access is required only if the associated 1829 entPhysicalClass value is equal to 'chassis(3)'." 1831 OBJECT entPhysicalAssetID 1832 MIN-ACCESS not-accessible 1833 DESCRIPTION 1834 "Read and write access is not required for agents which 1835 cannot provide non-volatile storage for NMS-assigned asset 1836 identifiers. 1838 Write access is not required for physical entities for which 1839 the associated value of entPhysicalIsFRU is equal to 1840 'false(2)'." 1842 OBJECT entPhysicalClass 1843 SYNTAX INTEGER { 1844 other(1), 1845 unknown(2), 1846 chassis(3), 1847 backplane(4), 1848 container(5), 1849 powerSupply(6), 1850 fan(7), 1851 sensor(8), 1852 module(9), 1853 port(10), 1854 stack(11) 1855 } 1856 DESCRIPTION 1857 "Implementation of the 'cpu(12)' enumeration is not 1858 required." 1860 ::= { entityCompliances 2 } 1862 entity3Compliance MODULE-COMPLIANCE 1863 STATUS current 1864 DESCRIPTION 1865 "The compliance statement for SNMP entities which implement 1866 version 3 of the Entity MIB." 1867 MODULE -- this module 1868 MANDATORY-GROUPS { 1869 entityPhysicalGroup, 1870 entityPhysical2Group, 1871 entityPhysical3Group, 1872 entityGeneralGroup, 1873 entityNotificationsGroup 1874 } 1875 GROUP entityLogical2Group 1876 DESCRIPTION 1877 "Implementation of this group is not mandatory for agents 1878 which model all MIB object instances within a single naming 1879 scope." 1881 GROUP entityMappingGroup 1882 DESCRIPTION 1883 "Implementation of the entPhysicalContainsTable is mandatory 1884 for all agents. Implementation of the entLPMappingTable and 1885 entAliasMappingTables are not mandatory for agents which 1886 model all MIB object instances within a single naming scope. 1888 Note that the entAliasMappingTable may be useful for all 1889 agents, however implementation of the entityLogicalGroup or 1890 entityLogical2Group is required to support this table." 1892 OBJECT entPhysicalSerialNum 1893 MIN-ACCESS not-accessible 1894 DESCRIPTION 1895 "Read and write access is not required for agents which 1896 cannot identify serial number information for physical 1897 entities, and/or cannot provide non-volatile storage for 1898 NMS-assigned serial numbers. 1900 Write access is not required for agents which can identify 1901 serial number information for physical entities, but cannot 1902 provide non-volatile storage for NMS-assigned serial 1903 numbers. 1905 Write access is not required for physical entities for 1906 physical entities for which the associated value of the 1907 entPhysicalIsFRU object is equal to 'false(2)'." 1909 OBJECT entPhysicalAlias 1910 MIN-ACCESS read-only 1911 DESCRIPTION 1912 "Write access is required only if the associated 1913 entPhysicalClass value is equal to 'chassis(3)'." 1915 OBJECT entPhysicalAssetID 1916 MIN-ACCESS not-accessible 1917 DESCRIPTION 1918 "Read and write access is not required for agents which 1919 cannot provide non-volatile storage for NMS-assigned asset 1920 identifiers. 1922 Write access is not required for physical entities for which 1923 the associated value of entPhysicalIsFRU is equal to 1924 'false(2)'." 1925 ::= { entityCompliances 3 } 1927 -- MIB groupings 1928 entityPhysicalGroup OBJECT-GROUP 1929 OBJECTS { 1930 entPhysicalDescr, 1931 entPhysicalVendorType, 1932 entPhysicalContainedIn, 1933 entPhysicalClass, 1934 entPhysicalParentRelPos, 1935 entPhysicalName 1936 } 1937 STATUS current 1938 DESCRIPTION 1939 "The collection of objects which are used to represent 1940 physical system components, for which a single agent 1941 provides management information." 1942 ::= { entityGroups 1 } 1944 entityLogicalGroup OBJECT-GROUP 1945 OBJECTS { 1946 entLogicalDescr, 1947 entLogicalType, 1948 entLogicalCommunity, 1949 entLogicalTAddress, 1950 entLogicalTDomain 1951 } 1952 STATUS deprecated 1953 DESCRIPTION 1954 "The collection of objects which are used to represent the 1955 list of logical entities for which a single agent provides 1956 management information." 1957 ::= { entityGroups 2 } 1959 entityMappingGroup OBJECT-GROUP 1960 OBJECTS { 1961 entLPPhysicalIndex, 1962 entAliasMappingIdentifier, 1963 entPhysicalChildIndex 1964 } 1965 STATUS current 1966 DESCRIPTION 1967 "The collection of objects which are used to represent the 1968 associations between multiple logical entities, physical 1969 components, interfaces, and port identifiers for which a 1970 single agent provides management information." 1971 ::= { entityGroups 3 } 1973 entityGeneralGroup OBJECT-GROUP 1974 OBJECTS { 1975 entLastChangeTime 1976 } 1977 STATUS current 1978 DESCRIPTION 1979 "The collection of objects which are used to represent 1980 general entity information for which a single agent provides 1981 management information." 1982 ::= { entityGroups 4 } 1984 entityNotificationsGroup NOTIFICATION-GROUP 1985 NOTIFICATIONS { entConfigChange } 1986 STATUS current 1987 DESCRIPTION 1988 "The collection of notifications used to indicate Entity MIB 1989 data consistency and general status information." 1990 ::= { entityGroups 5 } 1992 entityPhysical2Group OBJECT-GROUP 1993 OBJECTS { 1994 entPhysicalHardwareRev, 1995 entPhysicalFirmwareRev, 1996 entPhysicalSoftwareRev, 1997 entPhysicalSerialNum, 1998 entPhysicalMfgName, 1999 entPhysicalModelName, 2000 entPhysicalAlias, 2001 entPhysicalAssetID, 2002 entPhysicalIsFRU 2003 } 2004 STATUS current 2005 DESCRIPTION 2006 "The collection of objects which are used to represent 2007 physical system components, for which a single agent 2008 provides management information. This group augments the 2009 objects contained in the entityPhysicalGroup." 2010 ::= { entityGroups 6 } 2012 entityLogical2Group OBJECT-GROUP 2013 OBJECTS { 2014 entLogicalDescr, 2015 entLogicalType, 2016 entLogicalTAddress, 2017 entLogicalTDomain, 2018 entLogicalContextEngineID, 2019 entLogicalContextName 2021 } 2022 STATUS current 2023 DESCRIPTION 2024 "The collection of objects which are used to represent the 2025 list of logical entities for which a single SNMP entity 2026 provides management information." 2027 ::= { entityGroups 7 } 2029 entityPhysical3Group OBJECT-GROUP 2030 OBJECTS { 2031 entPhysicalMfgDate, 2032 entPhysicalUris 2033 } 2034 STATUS current 2035 DESCRIPTION 2036 "The collection of objects which are used to represent 2037 physical system components, for which a single agent 2038 provides management information. This group augments the 2039 objects contained in the entityPhysicalGroup." 2040 ::= { entityGroups 8 } 2042 END 2043 4. Usage Examples 2045 The following sections iterate the instance values for two example 2046 networking devices. These examples are kept simple to make them 2047 more understandable. Auxiliary components, such as fans, sensors, 2048 empty slots, and sub-modules are not shown, but might be modeled in 2049 real implementations. 2051 4.1. Router/Bridge 2053 A router containing two slots. Each slot contains a 3 port 2054 router/bridge module. Each port is represented in the ifTable. 2055 There are two logical instances of OSPF running and two logical 2056 bridges: 2058 Physical entities -- entPhysicalTable: 2059 1 Field-replaceable physical chassis: 2060 entPhysicalDescr.1 == 'Acme Chassis Model 100' 2061 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 2062 entPhysicalContainedIn.1 == 0 2063 entPhysicalClass.1 == chassis(3) 2064 entPhysicalParentRelPos.1 == 0 2065 entPhysicalName.1 == '100-A' 2066 entPhysicalHardwareRev.1 == 'A(1.00.02)' 2067 entPhysicalSoftwareRev.1 == '' 2068 entPhysicalFirmwareRev.1 == '' 2069 entPhysicalSerialNum.1 == 'C100076544' 2070 entPhysicalMfgName.1 == 'Acme' 2071 entPhysicalModelName.1 == '100' 2072 entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' 2073 entPhysicalAssetID.1 == '0007372293' 2074 entPhysicalIsFRU.1 == true(1) 2075 entPhysicalMfgDate.1 == '2002-5-26,13:30:30.0,-4:0' 2076 entPhysicalUris.1 == 'URN:CLEI:CNME120ARA' 2077 2 slots within the chassis: 2078 entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' 2079 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 2080 entPhysicalContainedIn.2 == 1 2081 entPhysicalClass.2 == container(5) 2082 entPhysicalParentRelPos.2 == 1 2083 entPhysicalName.2 == 'S1' 2084 entPhysicalHardwareRev.2 == 'B(1.00.01)' 2085 entPhysicalSoftwareRev.2 == '' 2086 entPhysicalFirmwareRev.2 == '' 2087 entPhysicalSerialNum.2 == '' 2088 entPhysicalMfgName.2 == 'Acme' 2089 entPhysicalModelName.2 == 'AA' 2090 entPhysicalAlias.2 == '' 2091 entPhysicalAssetID.2 == '' 2092 entPhysicalIsFRU.2 == false(2) 2093 entPhysicalMfgDate.2 == '2002-7-26,12:22:12.0,-4:0' 2094 entPhysicalUris.2 == 'URN:CLEI:CNME123ARA' 2096 entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' 2097 entPhysicalVendorType.3 = acmeProducts.slotTypes.1 2098 entPhysicalContainedIn.3 == 1 2099 entPhysicalClass.3 == container(5) 2100 entPhysicalParentRelPos.3 == 2 2101 entPhysicalName.3 == 'S2' 2102 entPhysicalHardwareRev.3 == '1.00.07' 2103 entPhysicalSoftwareRev.3 == '' 2104 entPhysicalFirmwareRev.3 == '' 2105 entPhysicalSerialNum.3 == '' 2106 entPhysicalMfgName.3 == 'Acme' 2107 entPhysicalModelName.3 == 'AA' 2108 entPhysicalAlias.3 == '' 2109 entPhysicalAssetID.3 == '' 2110 entPhysicalIsFRU.3 == false(2) 2111 entPhysicalMfgDate.3 == '2002-7-26,12:12:12.0,-4:0' 2112 entPhysicalUris.3 == 'URN:CLEI:CNME123ARA' 2114 2 Field-replaceable modules: 2115 Slot 1 contains a module with 3 ports: 2116 entPhysicalDescr.4 == 'Acme Router-100' 2117 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 2118 entPhysicalContainedIn.4 == 2 2119 entPhysicalClass.4 == module(9) 2120 entPhysicalParentRelPos.4 == 1 2121 entPhysicalName.4 == 'M1' 2122 entPhysicalHardwareRev.4 == '1.00.07' 2123 entPhysicalSoftwareRev.4 == '1.4.1' 2124 entPhysicalFirmwareRev.4 == 'A(1.1)' 2125 entPhysicalSerialNum.4 == 'C100087363' 2126 entPhysicalMfgName.4 == 'Acme' 2127 entPhysicalModelName.4 == 'R100-FE' 2128 entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' 2129 entPhysicalAssetID.4 == '0007372462' 2130 entPhysicalIsFRU.4 == true(1) 2131 entPhysicalMfgDate.4 == '2003-7-18,13:30:30.0,-4:0' 2132 entPhysicalUris.4 == 'URN:CLEI:CNRU123CAA' 2133 entPhysicalDescr.5 == 'Acme Ethernet-100 Port' 2134 entPhysicalVendorType.5 == acmeProducts.portTypes.2 2135 entPhysicalContainedIn.5 == 4 2136 entPhysicalClass.5 == port(10) 2137 entPhysicalParentRelPos.5 == 1 2138 entPhysicalName.5 == 'P1' 2139 entPhysicalHardwareRev.5 == 'G(1.02)' 2140 entPhysicalSoftwareRev.5 == '' 2141 entPhysicalFirmwareRev.5 == '1.1' 2142 entPhysicalSerialNum.5 == '' 2143 entPhysicalMfgName.5 == 'Acme' 2144 entPhysicalModelName.5 == 'FE-100' 2145 entPhysicalAlias.5 == '' 2146 entPhysicalAssetID.5 == '' 2147 entPhysicalIsFRU.5 == false(2) 2148 entPhysicalMfgDate.5 == '2003-7-18,14:20:22.0,-4:0' 2149 entPhysicalUris.5 == 'URN:CLEI:CNMES23ARA' 2151 entPhysicalDescr.6 == 'Acme Ethernet-100 Port' 2152 entPhysicalVendorType.6 == acmeProducts.portTypes.2 2153 entPhysicalContainedIn.6 == 4 2154 entPhysicalClass.6 == port(10) 2155 entPhysicalParentRelPos.6 == 2 2156 entPhysicalName.6 == 'P2' 2157 entPhysicalHardwareRev.6 == 'G(1.02)' 2158 entPhysicalSoftwareRev.6 == '' 2159 entPhysicalFirmwareRev.6 == '1.1' 2160 entPhysicalSerialNum.6 == '' 2161 entPhysicalMfgName.6 == 'Acme' 2162 entPhysicalModelName.6 == 'FE-100' 2163 entPhysicalAlias.6 == '' 2164 entPhysicalAssetID.6 == '' 2165 entPhysicalIsFRU.6 == false(2) 2166 entPhysicalMfgDate.6 == '2003-7-19,10:15:15.0,-4:0' 2167 entPhysicalUris.6 == 'URN:CLEI:CNMES23ARA' 2169 entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' 2170 entPhysicalVendorType.7 == acmeProducts.portTypes.3 2171 entPhysicalContainedIn.7 == 4 2172 entPhysicalClass.7 == port(10) 2173 entPhysicalParentRelPos.7 == 3 2174 entPhysicalName.7 == 'P3' 2175 entPhysicalHardwareRev.7 == 'B(1.03)' 2176 entPhysicalSoftwareRev.7 == '2.5.1' 2177 entPhysicalFirmwareRev.7 == '2.5F' 2178 entPhysicalSerialNum.7 == '' 2179 entPhysicalMfgName.7 == 'Acme' 2180 entPhysicalModelName.7 == 'FDDI-100' 2181 entPhysicalAlias.7 == '' 2182 entPhysicalAssetID.7 == '' 2183 entPhysicalIsFRU.7 == false(2) 2185 Slot 2 contains another 3-port module: 2186 entPhysicalDescr.8 == 'Acme Router-100 Comm Module' 2187 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 2188 entPhysicalContainedIn.8 == 3 2189 entPhysicalClass.8 == module(9) 2190 entPhysicalParentRelPos.8 == 1 2191 entPhysicalName.8 == 'M2' 2192 entPhysicalHardwareRev.8 == '2.01.00' 2193 entPhysicalSoftwareRev.8 == '3.0.7' 2194 entPhysicalFirmwareRev.8 == 'A(1.2)' 2195 entPhysicalSerialNum.8 == 'C100098732' 2196 entPhysicalMfgName.8 == 'Acme' 2197 entPhysicalModelName.8 == 'C100' 2198 entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' 2199 entPhysicalAssetID.8 == '0007373982' 2200 entPhysicalIsFRU.8 == true(1) 2201 entPhysicalMfgDate.8 == '2002-5-26,13:30:15.0,-4:0' 2202 entPhysicalUris.8 == 'URN:CLEI:CNRT321MAA' 2204 entPhysicalDescr.9 == 'Acme Fddi-100 Port' 2205 entPhysicalVendorType.9 == acmeProducts.portTypes.5 2206 entPhysicalContainedIn.9 == 8 2207 entPhysicalClass.9 == port(10) 2208 entPhysicalParentRelPos.9 == 1 2209 entPhysicalName.9 == 'FDDI Primary' 2210 entPhysicalHardwareRev.9 == 'CC(1.07)' 2211 entPhysicalSoftwareRev.9 == '2.0.34' 2212 entPhysicalFirmwareRev.9 == '1.1' 2213 entPhysicalSerialNum.9 == '' 2214 entPhysicalMfgName.9 == 'Acme' 2215 entPhysicalModelName.9 == 'FDDI-100' 2216 entPhysicalAlias.9 == '' 2217 entPhysicalAssetID.9 == '' 2218 entPhysicalIsFRU.9 == false(2) 2220 entPhysicalDescr.10 == 'Acme Ethernet-100 Port' 2221 entPhysicalVendorType.10 == acmeProducts.portTypes.2 2222 entPhysicalContainedIn.10 == 8 2223 entPhysicalClass.10 == port(10) 2224 entPhysicalParentRelPos.10 == 2 2225 entPhysicalName.10 == 'Ethernet A' 2226 entPhysicalHardwareRev.10 == 'G(1.04)' 2227 entPhysicalSoftwareRev.10 == '' 2228 entPhysicalFirmwareRev.10 == '1.3' 2229 entPhysicalSerialNum.10 == '' 2230 entPhysicalMfgName.10 == 'Acme' 2231 entPhysicalModelName.10 == 'FE-100' 2232 entPhysicalAlias.10 == '' 2233 entPhysicalAssetID.10 == '' 2234 entPhysicalIsFRU.10 == false(2) 2235 entPhysicalMfgDate.10 == '2002-7-26,13:30:15.0,-4:0' 2236 entPhysicalUris.10 == 'URN:CLEI:CNMES23ARA' 2238 entPhysicalDescr.11 == 'Acme Ethernet-100 Port' 2239 entPhysicalVendorType.11 == acmeProducts.portTypes.2 2240 entPhysicalContainedIn.11 == 8 2241 entPhysicalClass.11 == port(10) 2242 entPhysicalParentRelPos.11 == 3 2243 entPhysicalName.11 == 'Ethernet B' 2244 entPhysicalHardwareRev.11 == 'G(1.04)' 2245 entPhysicalSoftwareRev.11 == '' 2246 entPhysicalFirmwareRev.11 == '1.3' 2247 entPhysicalSerialNum.11 == '' 2248 entPhysicalMfgName.11 == 'Acme' 2249 entPhysicalModelName.11 == 'FE-100' 2250 entPhysicalAlias.11 == '' 2251 entPhysicalAssetID.11 == '' 2252 entPhysicalIsFRU.11 == false(2) 2253 entPhysicalMfgDate.11 == '2002-8-16,15:35:15.0,-4:0' 2254 entPhysicalUris.11 == 'URN:CLEI:CNMES23ARA' 2256 Logical entities -- entLogicalTable; no SNMPv3 support 2257 2 OSPF instances: 2258 entLogicalDescr.1 == 'Acme OSPF v1.1' 2259 entLogicalType.1 == ospf 2260 entLogicalCommunity.1 == 'public-ospf1' 2261 entLogicalTAddress.1 == 124.125.126.127:161 2262 entLogicalTDomain.1 == snmpUDPDomain 2263 entLogicalContextEngineID.1 == '' 2264 entLogicalContextName.1 == '' 2266 entLogicalDescr.2 == 'Acme OSPF v1.1' 2267 entLogicalType.2 == ospf 2268 entLogicalCommunity.2 == 'public-ospf2' 2269 entLogicalTAddress.2 == 124.125.126.127:161 2270 entLogicalTDomain.2 == snmpUDPDomain 2271 entLogicalContextEngineID.2 == '' 2272 entLogicalContextName.2 == '' 2274 2 logical bridges: 2275 entLogicalDescr.3 == 'Acme Bridge v2.1.1' 2276 entLogicalType.3 == dot1dBridge 2277 entLogicalCommunity.3 == 'public-bridge1' 2278 entLogicalTAddress.3 == 124.125.126.127:161 2279 entLogicalTDomain.3 == snmpUDPDomain 2280 entLogicalContextEngineID.3 == '' 2281 entLogicalContextName.3 == '' 2283 entLogicalDescr.4 == 'Acme Bridge v2.1.1' 2284 entLogicalType.4 == dot1dBridge 2285 entLogicalCommunity.4 == 'public-bridge2' 2286 entLogicalTAddress.4 == 124.125.126.127:161 2287 entLogicalTDomain.4 == snmpUDPDomain 2288 entLogicalContextEngineID.4 == '' 2289 entLogicalContextName.4 == '' 2291 Logical to Physical Mappings: 2292 1st OSPF instance: uses module 1-port 1 2293 entLPPhysicalIndex.1.5 == 5 2295 2nd OSPF instance: uses module 2-port 1 2296 entLPPhysicalIndex.2.9 == 9 2298 1st bridge group: uses module 1, all ports 2300 [ed. -- Note that these mappings are included in the table since 2301 another logical entity (1st OSPF) utilizes one of the 2302 ports. If this were not the case, then a single mapping 2303 to the module (e.g., entLPPhysicalIndex.3.4) would be 2304 present instead. ] 2305 entLPPhysicalIndex.3.5 == 5 2306 entLPPhysicalIndex.3.6 == 6 2307 entLPPhysicalIndex.3.7 == 7 2309 2nd bridge group: uses module 2, all ports 2310 entLPPhysicalIndex.4.9 == 9 2311 entLPPhysicalIndex.4.10 == 10 2312 entLPPhysicalIndex.4.11 == 11 2314 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2315 Example 1: ifIndex values are global to all logical entities 2316 entAliasMappingIdentifier.5.0 == ifIndex.1 2317 entAliasMappingIdentifier.6.0 == ifIndex.2 2318 entAliasMappingIdentifier.7.0 == ifIndex.3 2319 entAliasMappingIdentifier.9.0 == ifIndex.4 2320 entAliasMappingIdentifier.10.0 == ifIndex.5 2321 entAliasMappingIdentifier.11.0 == ifIndex.6 2323 Example 2: ifIndex values are not shared by all logical entities 2324 entAliasMappingIdentifier.5.0 == ifIndex.1 2325 entAliasMappingIdentifier.5.3 == ifIndex.101 2326 entAliasMappingIdentifier.6.0 == ifIndex.2 2327 entAliasMappingIdentifier.6.3 == ifIndex.102 2328 entAliasMappingIdentifier.7.0 == ifIndex.3 2329 entAliasMappingIdentifier.7.3 == ifIndex.103 2330 entAliasMappingIdentifier.9.0 == ifIndex.4 2331 entAliasMappingIdentifier.9.3 == ifIndex.204 2332 entAliasMappingIdentifier.10.0 == ifIndex.5 2333 entAliasMappingIdentifier.10.3 == ifIndex.205 2334 entAliasMappingIdentifier.11.0 == ifIndex.6 2335 entAliasMappingIdentifier.11.3 == ifIndex.206 2337 Physical Containment Tree -- entPhysicalContainsTable 2338 chassis has two containers: 2339 entPhysicalChildIndex.1.2 == 2 2340 entPhysicalChildIndex.1.3 == 3 2342 container 1 has a module: 2343 entPhysicalChildIndex.2.4 == 4 2345 container 2 has a module: 2346 entPhysicalChildIndex.3.8 == 8 2348 module 1 has 3 ports: 2349 entPhysicalChildIndex.4.5 == 5 2350 entPhysicalChildIndex.4.6 == 6 2351 entPhysicalChildIndex.4.7 == 7 2353 module 2 has 3 ports: 2354 entPhysicalChildIndex.8.9 == 9 2355 entPhysicalChildIndex.8.10 == 10 2356 entPhysicalChildIndex.1.11 == 11 2358 4.2. Repeaters 2360 A 3-slot Hub with 2 backplane ethernet segments. Slot three is 2361 empty, and the remaining slots contain ethernet repeater modules. 2363 Note that this example assumes an older Repeater MIB 2364 implementation, (RFC 1516 [RFC1516]) rather than the new Repeater 2365 MIB (RFC 2108 [RFC2108]). The new version contains an object 2366 called 'rptrPortRptrId', which should be used to identify repeater 2367 port groupings, rather than with community strings or contexts. 2369 Physical entities -- entPhysicalTable: 2370 1 Field-replaceable physical chassis: 2371 entPhysicalDescr.1 == 'Acme Chassis Model 110' 2372 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 2373 entPhysicalContainedIn.1 == 0 2374 entPhysicalClass.1 == chassis(3) 2375 entPhysicalParentRelPos.1 == 0 2376 entPhysicalName.1 == '110-B' 2377 entPhysicalHardwareRev.1 == 'A(1.02.00)' 2378 entPhysicalSoftwareRev.1 == '' 2379 entPhysicalFirmwareRev.1 == '' 2380 entPhysicalSerialNum.1 == 'C100079294' 2381 entPhysicalMfgName.1 == 'Acme' 2382 entPhysicalModelName.1 == '110' 2383 entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' 2384 entPhysicalAssetID.1 == '0007386327' 2385 entPhysicalIsFRU.1 == true(1) 2387 2 Chassis Ethernet Backplanes: 2388 entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' 2389 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 2390 entPhysicalContainedIn.2 == 1 2391 entPhysicalClass.2 == backplane(4) 2392 entPhysicalParentRelPos.2 == 1 2393 entPhysicalName.2 == 'B1' 2394 entPhysicalHardwareRev.2 == 'A(2.04.01)' 2395 entPhysicalSoftwareRev.2 == '' 2396 entPhysicalFirmwareRev.2 == '' 2397 entPhysicalSerialNum.2 == '' 2398 entPhysicalMfgName.2 == 'Acme' 2399 entPhysicalModelName.2 == 'BK-A' 2400 entPhysicalAlias.2 == '' 2401 entPhysicalAssetID.2 == '' 2402 entPhysicalIsFRU.2 == false(2) 2403 entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' 2404 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 2405 entPhysicalContainedIn.3 == 1 2406 entPhysicalClass.3 == backplane(4) 2407 entPhysicalParentRelPos.3 == 2 2408 entPhysicalName.3 == 'B2' 2409 entPhysicalHardwareRev.3 == 'A(2.04.01)' 2410 entPhysicalSoftwareRev.3 == '' 2411 entPhysicalFirmwareRev.3 == '' 2412 entPhysicalSerialNum.3 == '' 2413 entPhysicalMfgName.3 == 'Acme' 2414 entPhysicalModelName.3 == 'BK-A' 2415 entPhysicalAlias.3 == '' 2416 entPhysicalAssetID.3 == '' 2417 entPhysicalIsFRU.3 == false(2) 2419 3 slots within the chassis: 2420 entPhysicalDescr.4 == 'Acme Hub Slot Type RB' 2421 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 2422 entPhysicalContainedIn.4 == 1 2423 entPhysicalClass.4 == container(5) 2424 entPhysicalParentRelPos.4 == 1 2425 entPhysicalName.4 == 'Slot 1' 2426 entPhysicalHardwareRev.4 == 'B(1.00.03)' 2427 entPhysicalSoftwareRev.4 == '' 2428 entPhysicalFirmwareRev.4 == '' 2429 entPhysicalSerialNum.4 == '' 2430 entPhysicalMfgName.4 == 'Acme' 2431 entPhysicalModelName.4 == 'RB' 2432 entPhysicalAlias.4 == '' 2433 entPhysicalAssetID.4 == '' 2434 entPhysicalIsFRU.4 == false(2) 2436 entPhysicalDescr.5 == 'Acme Hub Slot Type RB' 2437 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 2438 entPhysicalContainedIn.5 == 1 2439 entPhysicalClass.5 == container(5) 2440 entPhysicalParentRelPos.5 == 2 2441 entPhysicalName.5 == 'Slot 2' 2442 entPhysicalHardwareRev.5 == 'B(1.00.03)' 2443 entPhysicalSoftwareRev.5 == '' 2444 entPhysicalFirmwareRev.5 == '' 2445 entPhysicalSerialNum.5 == '' 2446 entPhysicalMfgName.5 == 'Acme' 2447 entPhysicalModelName.5 == 'RB' 2448 entPhysicalAlias.5 == '' 2449 entPhysicalAssetID.5 == '' 2450 entPhysicalIsFRU.5 == false(2) 2452 entPhysicalDescr.6 == 'Acme Hub Slot Type RB' 2453 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 2454 entPhysicalContainedIn.6 == 1 2455 entPhysicalClass.6 == container(5) 2456 entPhysicalParentRelPos.6 == 3 2457 entPhysicalName.6 == 'Slot 3' 2458 entPhysicalHardwareRev.6 == 'B(1.00.03)' 2459 entPhysicalSoftwareRev.6 == '' 2460 entPhysicalFirmwareRev.6 == '' 2461 entPhysicalSerialNum.6 == '' 2462 entPhysicalMfgName.6 == 'Acme' 2463 entPhysicalModelName.6 == 'RB' 2464 entPhysicalAlias.6 == '' 2465 entPhysicalAssetID.6 == '' 2466 entPhysicalIsFRU.6 == false(2) 2468 Slot 1 contains a plug-in module with 4 10-BaseT ports: 2469 entPhysicalDescr.7 == 'Acme 10Base-T Module 114' 2470 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 2471 entPhysicalContainedIn.7 == 4 2472 entPhysicalClass.7 == module(9) 2473 entPhysicalParentRelPos.7 == 1 2474 entPhysicalName.7 == 'M1' 2475 entPhysicalHardwareRev.7 == 'A(1.02.01)' 2476 entPhysicalSoftwareRev.7 == '1.7.2' 2477 entPhysicalFirmwareRev.7 == 'A(1.5)' 2478 entPhysicalSerialNum.7 == 'C100096244' 2479 entPhysicalMfgName.7 == 'Acme' 2480 entPhysicalModelName.7 = '114' 2481 entPhysicalAlias.7 == 'bldg09:floor1:eng' 2482 entPhysicalAssetID.7 == '0007962951' 2483 entPhysicalIsFRU.7 == true(1) 2485 entPhysicalDescr.8 == 'Acme 10Base-T Port RB' 2486 entPhysicalVendorType.8 == acmeProducts.portTypes.10 2487 entPhysicalContainedIn.8 == 7 2488 entPhysicalClass.8 == port(10) 2489 entPhysicalParentRelPos.8 == 1 2490 entPhysicalName.8 == 'Ethernet-A' 2491 entPhysicalHardwareRev.8 == 'A(1.04F)' 2492 entPhysicalSoftwareRev.8 == '' 2493 entPhysicalFirmwareRev.8 == '1.4' 2494 entPhysicalSerialNum.8 == '' 2495 entPhysicalMfgName.8 == 'Acme' 2496 entPhysicalModelName.8 == 'RB' 2497 entPhysicalAlias.8 == '' 2498 entPhysicalAssetID.8 == '' 2499 entPhysicalIsFRU.8 == false(2) 2501 entPhysicalDescr.9 == 'Acme 10Base-T Port RB' 2502 entPhysicalVendorType.9 == acmeProducts.portTypes.10 2503 entPhysicalContainedIn.9 == 7 2504 entPhysicalClass.9 == port(10) 2505 entPhysicalParentRelPos.9 == 2 2506 entPhysicalName.9 == 'Ethernet-B' 2507 entPhysicalHardwareRev.9 == 'A(1.04F)' 2508 entPhysicalSoftwareRev.9 == '' 2509 entPhysicalFirmwareRev.9 == '1.4' 2510 entPhysicalSerialNum.9 == '' 2511 entPhysicalMfgName.9 == 'Acme' 2512 entPhysicalModelName.9 = 'RB' 2513 entPhysicalAlias.9 == '' 2514 entPhysicalAssetID.9 == '' 2515 entPhysicalIsFRU.9 == false(2) 2517 entPhysicalDescr.10 == 'Acme 10Base-T Port RB' 2518 entPhysicalVendorType.10 == acmeProducts.portTypes.10 2519 entPhysicalContainedIn.10 == 7 2520 entPhysicalClass.10 == port(10) 2521 entPhysicalParentRelPos.10 == 3 2522 entPhysicalName.10 == 'Ethernet-C' 2523 entPhysicalHardwareRev.10 == 'B(1.02.07)' 2524 entPhysicalSoftwareRev.10 == '' 2525 entPhysicalFirmwareRev.10 == '1.4' 2526 entPhysicalSerialNum.10 == '' 2527 entPhysicalMfgName.10 == 'Acme' 2528 entPhysicalModelName.10 == 'RB' 2529 entPhysicalAlias.10 == '' 2530 entPhysicalAssetID.10 == '' 2531 entPhysicalIsFRU.10 == false(2) 2533 entPhysicalDescr.11 == 'Acme 10Base-T Port RB' 2534 entPhysicalVendorType.11 == acmeProducts.portTypes.10 2535 entPhysicalContainedIn.11 == 7 2536 entPhysicalClass.11 == port(10) 2537 entPhysicalParentRelPos.11 == 4 2538 entPhysicalName.11 == 'Ethernet-D' 2539 entPhysicalHardwareRev.11 == 'B(1.02.07)' 2540 entPhysicalSoftwareRev.11 == '' 2541 entPhysicalFirmwareRev.11 == '1.4' 2542 entPhysicalSerialNum.11 == '' 2543 entPhysicalMfgName.11 == 'Acme' 2544 entPhysicalModelName.11 == 'RB' 2545 entPhysicalAlias.11 == '' 2546 entPhysicalAssetID.11 == '' 2547 entPhysicalIsFRU.11 == false(2) 2549 Slot 2 contains another ethernet module with 2 ports. 2550 entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' 2551 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 2552 entPhysicalContainedIn.12 = 5 2553 entPhysicalClass.12 == module(9) 2554 entPhysicalParentRelPos.12 == 1 2555 entPhysicalName.12 == 'M2' 2556 entPhysicalHardwareRev.12 == 'A(1.01.07)' 2557 entPhysicalSoftwareRev.12 == '1.8.4' 2558 entPhysicalFirmwareRev.12 == 'A(1.8)' 2559 entPhysicalSerialNum.12 == 'C100102384' 2560 entPhysicalMfgName.12 == 'Acme' 2561 entPhysicalModelName.12 == '4' 2562 entPhysicalAlias.12 == 'bldg09:floor1:devtest' 2563 entPhysicalAssetID.12 == '0007968462' 2564 entPhysicalIsFRU.12 == true(1) 2566 entPhysicalDescr.13 == 'Acme 802.3 AUI Port' 2567 entPhysicalVendorType.13 == acmeProducts.portTypes.11 2568 entPhysicalContainedIn.13 == 12 2569 entPhysicalClass.13 == port(10) 2570 entPhysicalParentRelPos.13 == 1 2571 entPhysicalName.13 == 'AUI' 2572 entPhysicalHardwareRev.13 == 'A(1.06F)' 2573 entPhysicalSoftwareRev.13 == '' 2574 entPhysicalFirmwareRev.13 == '1.5' 2575 entPhysicalSerialNum.13 == '' 2576 entPhysicalMfgName.13 == 'Acme' 2577 entPhysicalModelName.13 == '' 2578 entPhysicalAlias.13 == '' 2579 entPhysicalAssetID.13 == '' 2580 entPhysicalIsFRU.13 == false(2) 2582 entPhysicalDescr.14 == 'Acme 10Base-T Port RD' 2583 entPhysicalVendorType.14 == acmeProducts.portTypes.14 2584 entPhysicalContainedIn.14 == 12 2585 entPhysicalClass.14 == port(10) 2586 entPhysicalParentRelPos.14 == 2 2587 entPhysicalName.14 == 'E2' 2588 entPhysicalHardwareRev.14 == 'B(1.01.02)' 2589 entPhysicalSoftwareRev.14 == '' 2590 entPhysicalFirmwareRev.14 == '2.1' 2591 entPhysicalSerialNum.14 == '' 2592 entPhysicalMfgName.14 == 'Acme' 2593 entPhysicalModelName.14 == '' 2594 entPhysicalAlias.14 == '' 2595 entPhysicalAssetID.14 == '' 2596 entPhysicalIsFRU.14 == false(2) 2598 Logical entities -- entLogicalTable; with SNMPv3 support 2599 Repeater 1--comprised of any ports attached to backplane 1 2600 entLogicalDescr.1 == 'Acme repeater v3.1' 2601 entLogicalType.1 == snmpDot3RptrMgt 2602 entLogicalCommunity.1 'public-repeater1' 2603 entLogicalTAddress.1 == 124.125.126.127:161 2604 entLogicalTDomain.1 == snmpUDPDomain 2605 entLogicalContextEngineID.1 == '80000777017c7d7e7f'H 2606 entLogicalContextName.1 == 'repeater1' 2608 Repeater 2--comprised of any ports attached to backplane 2: 2609 entLogicalDescr.2 == 'Acme repeater v3.1' 2610 entLogicalType.2 == snmpDot3RptrMgt 2611 entLogicalCommunity.2 == 'public-repeater2' 2612 entLogicalTAddress.2 == 124.125.126.127:161 2613 entLogicalTDomain.2 == snmpUDPDomain 2614 entLogicalContextEngineID.2 == '80000777017c7d7e7f'H 2615 entLogicalContextName.2 == 'repeater2' 2617 Logical to Physical Mappings -- entLPMappingTable: 2619 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 2620 [ed. -- Note that a mapping to the module is not included, 2621 since in this example represents a port-switchable hub. 2622 Even though all ports on the module could belong to the 2623 same repeater as a matter of configuration, the LP port 2624 mappings should not be replaced dynamically with a single 2625 mapping for the module (e.g., entLPPhysicalIndex.1.7). 2626 If all ports on the module shared a single backplane connection, 2627 then a single mapping for the module would be more appropriate. ] 2628 entLPPhysicalIndex.1.2 == 2 2629 entLPPhysicalIndex.1.8 == 8 2630 entLPPhysicalIndex.1.9 == 9 2631 entLPPhysicalIndex.1.13 == 13 2633 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 2634 entLPPhysicalIndex.2.3 == 3 2635 entLPPhysicalIndex.2.10 == 10 2636 entLPPhysicalIndex.2.11 == 11 2637 entLPPhysicalIndex.2.14 == 14 2639 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2640 Repeater Port Identifier values are shared by both repeaters: 2641 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 2642 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 2643 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 2644 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 2645 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 2646 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 2648 Physical Containment Tree -- entPhysicalContainsTable 2649 chassis has two backplanes and three containers: 2650 entPhysicalChildIndex.1.2 == 2 2651 entPhysicalChildIndex.1.3 == 3 2652 entPhysicalChildIndex.1.4 == 4 2653 entPhysicalChildIndex.1.5 == 5 2654 entPhysicalChildIndex.1.6 == 6 2656 container 1 has a module: 2657 entPhysicalChildIndex.4.7 == 7 2659 container 2 has a module 2660 entPhysicalChildIndex.5.12 == 12 2661 [ed. - in this example, container 3 is empty.] 2663 module 1 has 4 ports: 2664 entPhysicalChildIndex.7.8 == 8 2665 entPhysicalChildIndex.7.9 == 9 2666 entPhysicalChildIndex.7.10 == 10 2667 entPhysicalChildIndex.7.11 == 11 2669 module 2 has 2 ports: 2670 entPhysicalChildIndex.12.13 == 13 2671 entPhysicalChildIndex.12.14 == 14 2673 5. Security Considerations 2675 There are a number of management objects defined in this MIB that 2676 have a MAX-ACCESS clause of read-write and/or read-create. Such 2677 objects may be considered sensitive or vulnerable in some network 2678 environments. The support for SET operations in a non-secure 2679 environment without proper protection can have a negative effect on 2680 network operations. 2682 There are a number of managed objects in this MIB that may contain 2683 sensitive information. These are: 2685 entPhysicalDescr 2686 entPhysicalVendorType 2687 entPhysicalHardwareRev 2688 entPhysicalFirmwareRev 2689 entPhysicalSoftwareRev 2690 entPhysicalSerialNum 2691 entPhysicalMfgName 2692 entPhysicalModelName 2694 These objects expose information about the physical entities within 2695 a managed system, which may be used to identify the vendor, model, 2696 and version information of each system component. 2698 entPhysicalAssetID 2700 This object can allow asset identifiers for various system 2701 components to be exposed, in the event this MIB object is actually 2702 configured by an NMS application. 2704 entLogicalDescr 2705 entLogicalType 2707 These objects expose the type of logical entities present in the 2708 managed system. 2710 entLogicalCommunity 2712 This object exposes community names associated with particular 2713 logical entities within the system. 2715 entLogicalTAddress 2716 entLogicalTDomain 2717 These objects expose network addresses that can be used to 2718 communicate with an SNMP agent on behalf of particular logical 2719 entities within the system. 2721 entLogicalContextEngineID 2722 entLogicalContextName 2724 These objects identify the authoritative SNMP engine that contains 2725 information on behalf of particular logical entities within the 2726 system. 2728 It is thus important to control even GET access to these objects 2729 and possibly to even encrypt the values of these object when 2730 sending them over the network via SNMP. Not all versions of SNMP 2731 provide features for such a secure environment. 2733 SNMPv1 by itself is not a secure environment. Even if the network 2734 itself is secure (for example by using IPSec), even then, there is 2735 no control as to who on the secure network is allowed to access and 2736 GET/SET (read/change/create/delete) the objects in this MIB. 2738 It is recommended that the implementers consider the security 2739 features as provided by the SNMPv3 framework. Specifically, the 2740 use of the User-based Security Model RFC 2574 [RFC2574] and the 2741 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 2743 It is then a customer/user responsibility to ensure that the SNMP 2744 entity giving access to an instance of this MIB, is properly 2745 configured to give access to the objects only to those principals 2746 (users) that have legitimate rights to indeed GET or SET 2747 (change/create/delete) them. 2749 6. IANA Considerations 2751 The MIB module in this document uses the following IANA-assigned 2752 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 2754 Descriptor OBJECT IDENTIFIER value 2755 ---------- ----------------------- 2756 entityMIB { mib-2 47 } 2758 Editor's Note (to be removed prior to publication): this draft 2759 makes no additional requests of the IANA. 2761 7. Acknowledgements 2763 This memo has been produced by the IETF's Entity MIB working group. 2765 8. References 2767 8.1. Normative References 2769 [RFC2026] 2770 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2771 2026, October, 1996. 2773 [RFC2396] 2774 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource 2775 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 2777 [RFC2578] 2778 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2779 and S. Waldbusser, "Structure of Management Information Version 2 2780 (SMIv2)", STD 58, RFC 2578, April 1999. 2782 [RFC2579] 2783 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2784 and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2785 2579, April 1999. 2787 [RFC2580] 2788 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2789 and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2790 2580, April 1999. 2792 [RFC3411] 2793 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2794 Describing Simple Network Management Protocol (SNMP) Management 2795 Frameworks", STD 62, RFC 3411, December 2002. 2797 [RFC3417] 2798 R. Presuhn, Ed., "Transport Mappings for the Simple Network 2799 Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 2801 8.2. Informative References 2803 [RFC1157] 2804 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2805 Management Protocol", STD 15, RFC 1157, May 1990. 2807 [RFC1493] 2808 Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, 2809 "Definitions of Managed Objects for Bridges", RFC 1493, July, 1993. 2811 [RFC1516] 2812 McMaster, D., and K. McCloghrie, "Definitions of Managed Objects 2813 for IEEE 802.3 Repeater Devices", RFC 1516, September, 1993. 2815 [RFC2037] 2816 McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037, 2817 October 1996. 2819 [RFC2108] 2820 de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, 2821 "Definitions of Managed Objects for IEEE 802.3 Repeater Devices 2822 using SMIv2", RFC 2108, February, 1997. 2824 [RFC2863] 2825 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 2826 2863, June, 2000. 2828 [RFC2737] 2829 McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, 2830 December 1999. 2832 [RFC3406] 2833 Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform 2834 Resource Names (URN) Namespace Definition Mechanisms", RFC 3406, 2835 October 2002. 2837 [RFC3410] 2838 Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and 2839 Applicability Statements for Internet- Standard Management 2840 Framework", RFC 3410, December 2002. 2842 [RFCCLEIURN] 2843 Tesink, K., and Robert H. Fox, "A Uniform Resource Name (URN) 2844 Namespace for the CLEI Code", Work in progress, November 7, 2004. 2846 [T1.213] 2847 ATIS T1.213-2001, "Coded Identification of Equipment Entities in 2848 the North American Telecommunications System for Information 2849 Exchange", 2001, www.ansi.org. 2851 [T1.213a] 2852 ATIS T1.213a, "Supplement to T1.213-2001, Coded Identification of 2853 Equipment Entities in the North American Telecommunications System 2854 for Information Exchange, to correct the representation of the 2855 Basic Code in Figure B.1", 2001, www.ansi.org. 2857 Authors' Addresses 2859 Andy Bierman 2860 Cisco Systems, Inc. 2861 170 West Tasman Drive 2862 San Jose, CA 95134 USA 2863 Phone: +1 408-527-3711 2864 Email: abierman@cisco.com 2866 Keith McCloghrie 2867 Cisco Systems, Inc. 2868 170 West Tasman Drive 2869 San Jose, CA 95134 USA 2870 Phone: +1 408-526-5260 2871 Email: kzm@cisco.com 2873 Intellectual Property Statement 2875 The IETF takes no position regarding the validity or scope of any 2876 Intellectual Property Rights or other rights that might be claimed 2877 to pertain to the implementation or use of the technology described 2878 in this document or the extent to which any license under such 2879 rights might or might not be available; nor does it represent that 2880 it has made any independent effort to identify any such rights. 2881 Information on the procedures with respect to rights in RFC 2882 documents can be found in BCP 78 and BCP 79. 2884 Copies of IPR disclosures made to the IETF Secretariat and any 2885 assurances of licenses to be made available, or the result of an 2886 attempt made to obtain a general license or permission for the use 2887 of such proprietary rights by implementers or users of this 2888 specification can be obtained from the IETF on-line IPR repository 2889 at http://www.ietf.org/ipr. 2891 The IETF invites any interested party to bring to its attention any 2892 copyrights, patents or patent applications, or other proprietary 2893 rights that may cover technology that may be required to implement 2894 this standard. Please address the information to the IETF at ietf- 2895 ipr@ietf.org. 2897 Disclaimer of Validity 2899 This document and the information contained herein are provided on 2900 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2901 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 2902 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2903 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2904 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2905 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2906 PARTICULAR PURPOSE. 2908 Copyright Statement 2910 Copyright (C) The Internet Society (2005). This document is 2911 subject to the rights, licenses and restrictions contained in BCP 2912 78, and except as set forth therein, the authors retain all their 2913 rights. 2915 Acknowledgment 2917 Funding for the RFC Editor function is currently provided by the 2918 Internet Society.