within the scope of this MIB to contain all the information which   might be necessary to manage a "chassis".  On the other hand, the   entities represented by an implementation of this MIB might well be   contained in a chassis.2.6.  Relationship to the Interfaces MIB   The Entity MIB contains a mapping table identifying physical   components that have 'external values' (e.g., ifIndex) associated   with them within a given naming scope.  This table can be used to   identify the physical location of each interface in the ifTable (RFC   2233 [RFC2233]).  Since ifIndex values in different contexts are not   related to one another, the interface to physical component   associations are relative to the same logical entity within the   agent.McCloghrie & Bierman        Standards Track                     [Page 6]RFC 2737                 Entity MIB (Version 2)            December 1999   The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias'   objects, which approximate the semantics of the 'ifName' and '   ifAlias' objects (respectively) from the Interfaces MIB [RFC2233],   for all types of physical components.2.7.  Relationship to the Other MIBs   The Entity MIB contains a mapping table identifying physical   components that have identifiers from other standard MIBs associated   with them.  For example, this table can be used along with the   physical mapping table to identify the physical location of each   repeater port in the rptrPortTable, or each interface in the ifTable.2.8.  Relationship to Naming Scopes   There is some question as to which MIB objects may be returned within   a given naming scope. MIB objects which are not multi-scoped within a   managed system are likely to ignore context information in   implementation. In such a case, it is likely such objects will be   returned in all naming scopes (e.g., not just the 'default' naming   scope or the SNMPv3 default context).   For example, a community string used to access the management   information for logical device 'bridge2' may allow access to all the   non-bridge related objects in the 'default' naming scope, as well as   a second instance of the Bridge MIB (RFC 1493 [RFC1493]).   It is an implementation-specific matter as to the isolation of   single-scoped MIB objects by the agent. An agent may wish to limit   the objects returned in a particular naming scope to just the multi-   scoped objects in that naming scope (e.g., system group and the   Bridge MIB).  In this case, all single-scoped management information   would belong to a common naming scope (e.g., 'default'), which itself   may contain some multi-scoped objects (e.g., system group).2.9.  Multiple Instances of the Entity MIB   It is possible that more than one agent exists in a managed system,   and in such cases, multiple instances of the Entity MIB (representing   the same managed objects) may be available to an NMS.   In order to reduce complexity for agent implementation, multiple   instances of the Entity MIB are not required to be equivalent or even   consistent. An NMS may be able to 'align' instances returned by   different agents by examining the columns of each table, but vendor-   specific identifiers and (especially) index values are likely to be   different. Each agent may be managing different subsets of the entire   chassis as well.McCloghrie & Bierman        Standards Track                     [Page 7]RFC 2737                 Entity MIB (Version 2)            December 1999   When all of a physically-modular device is represented by a single   agent, the entry for which entPhysicalContainedIn has the value zero   would likely have 'chassis' as the value of its entPhysicalClass;   alternatively, for an agent on a module where the agent represents   only the physical entities on that module (not those on other   modules), the entry for which entPhysicalContainedIn has the value   zero would likely have 'module' as the value of its entPhysicalClass.   An agent implementation of the entLogicalTable is not required to   contain information about logical entities managed primarily by other   agents. That is, the entLogicalTAddress and entLogicalTDomain objects   in the entLogicalTable are provided to support an historical   multiplexing mechanism, not to identify other SNMP agents.   Note that the Entity MIB is a single-scoped MIB, in the event an   agent represents the MIB in different naming scopes.2.10.  Re-Configuration of Entities   Most of the MIB objects defined in this MIB have at most a read-only   MAX-ACCESS clause.  This is a conscious decision by the working group   to limit this MIB's scope.  The second version of the Entity MIB   allows a network administrator to configure some common attributes of   physical components.2.11.  Textual Convention Change   Version 1 of the Entity MIB contains three MIB objects defined with   the (now obsolete) DisplayString textual convention.  In version 2 of   the Entity MIB, the syntax for these objects has been updated to use   the (now preferred) SnmpAdminString textual convention.   The working group realizes that this change is not strictly supported   by SMIv2.  In our judgment, the alternative of deprecating the old   objects and defining new objects would have a more adverse impact on   backward compatibility and interoperability, given the particular   semantics of these objects.2.12.  MIB Structure   The Entity MIB contains five groups of MIB objects:      - entityPhysical group        Describes the physical entities managed by a single agent.      - entityLogical group        Describes the logical entities managed by a single agent.McCloghrie & Bierman        Standards Track                     [Page 8]RFC 2737                 Entity MIB (Version 2)            December 1999      - entityMapping group        Describes the associations between the physical entities,        logical entities, interfaces, and non-interface ports managed by        a single agent.      - entityGeneral group        Describes general system attributes shared by potentially all        types of entities managed by a single agent.      - entityNotifications group        Contains status indication notifications.2.12.1.  entityPhysical Group   This group contains a single table to identify physical system   components, called the entPhysicalTable.   The entPhysicalTable contains one row per physical entity, and must   always contain at least one row for an "overall" physical entity,   which should have an entPhysicalClass value of 'stack(11)', '   chassis(3)' or 'module(9)'.   Each row is indexed by an arbitrary, small integer, and contains a   description and type of the physical entity.  It also optionally   contains the index number of another entPhysicalEntry indicating a   containment relationship between the two.   Version 2 of the Entity MIB provides additional MIB objects for each   physical entity. Some common read-only attributes have been added, as   well as three writable string objects.      - entPhysicalAlias        This string can be used by an NMS as a non-volatile identifier        for the physical component. Maintaining a non-volatile string        for every physical component represented in the entPhysicalTable        can be costly and unnecessary.  An agent may algorithmically        generate 'entPhysicalAlias' strings for particular entries        (e.g., based on the entPhysicalClass value).      - entPhysicalAssetID        This string is provided to store a user-specific asset        identifier for removable physical components.  In order to        reduce the non-volatile storage needed by a particular agent, a        network administrator should only assign asset identifiers to        physical entities which are field-replaceable (i.e., not        permanently contained within another physical entity).McCloghrie & Bierman        Standards Track                     [Page 9]RFC 2737                 Entity MIB (Version 2)            December 1999      - entPhysicalSerialNum        This string is provided to store a vendor-specific serial number        string for physical components.  This is a writable object in        case an agent cannot identify the serial numbers of all        installed physical entities, and a network administrator wishes        to configure the non-volatile serial number strings manually        (via an NMS application).2.12.2.  entityLogical Group   This group contains a single table to identify logical entities,   called the entLogicalTable.   The entLogicalTable contains one row per logical entity.  Each row is   indexed by an arbitrary, small integer and contains a name,   description, and type of the logical entity. It also contains   information to allow access to the MIB information for the logical   entity. This includes SNMP versions that use a community name (with   some form of implied context representation) and SNMP versions that   use the SNMP ARCH [RFC2571] method of context identification.   If a agent represents multiple logical entities with this MIB, then   this group must be implemented for all logical entities known to the   agent.   If an agent represents a single logical entity, or multiple logical   entities within a single naming scope, then implementation of this   group may be omitted by the agent.2.12.3.  entityMapping Group   This group contains three tables to identify associations between   different system components.   The entLPMappingTable contains mappings between entLogicalIndex   values (logical entities) and entPhysicalIndex values (the physical   components supporting that entity). A logical entity can map to more   than one physical component, and more than one logical entity can map   to (share) the same physical component.  If an agent represents a   single logical entity, or multiple logical entities within a single   naming scope, then implementation of this table may be omitted by the   agent.   The entAliasMappingTable contains mappings between entLogicalIndex,   entPhysicalIndex pairs and 'alias' object identifier values.  This   allows resources managed with other MIBs (e.g., repeater ports,   bridge ports, physical and logical interfaces) to be identified in   the physical entity hierarchy. Note that each alias identifier isMcCloghrie & Bierman        Standards Track                    [Page 10]RFC 2737                 Entity MIB (Version 2)            December 1999   only relevant in a particular naming scope.  If an agent represents a   single logical entity, or multiple logical entities within a single   naming scope, then implementation of this table may be omitted by the   agent.   The entPhysicalContainsTable contains simple mappings between   'entPhysicalContainedIn' values for each container/'containee'   relationship in the managed system. The indexing of this table allows   an NMS to quickly discover the 'entPhysicalIndex' values for all   children of a given physical entity.2.12.4.  entityGeneral Group   This group contains general information relating to the other object   groups.   At this time, the entGeneral group contains a single scalar object   (entLastChangeTime), which represents the value of sysUptime when any   part of the Entity MIB configuration last changed.2.12.5.  entityNotifications Group   This group contains notification definitions relating to the overall   status of the Entity MIB instantiation.2.13.  Multiple Agents   Even though a primary motivation for this MIB is to represent the   multiple logical entities supported by a single agent, it is also   possible to use it to represent multiple logical entities supported   by multiple agents (in the same "overall" physical entity).  Indeed,   it is implicit in the SNMP architecture, that the number of agents is   transparent to a network management station.   However, there is no agreement at this time as to the degree of   cooperation which should be expected for agent implementations.   Therefore, multiple agents within the same managed system are free to   implement the Entity MIB independently.  (Refer the section on   "Multiple Instances of the Entity MIB" for more details).2.14.  Changes Since RFC 20372.14.1.  Textual Conventions   The PhysicalClass TC text has been clarified, and a new enumeration   to support 'stackable' components has been added.  The   SnmpEngineIdOrNone TC has been added to support SNMPv3.McCloghrie & Bierman        Standards Track                    [Page 11]RFC 2737                 Entity MIB (Version 2)            December 19992.14.2.  New entPhysicalTable Objects   The entPhysicalHardwareRev, entPhysicalFirmwareRev, and   entPhysicalSoftwareRev objects have been added for revision   identification.   The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName,   and entPhysicalIsFru objects have been added for better vendor   identification for physical components.  The entPhysicalSerialNum   object can be set by a management station in the event the agent