tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6933

 Errata 
Proposed STD
Pages: 76
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: EMAN

Entity MIB (Version 4)

Part 1 of 3, p. 1 to 16
None       Next RFC Part

Obsoletes:    4133


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        A. Bierman
Request for Comments: 6933                               YumaWorks, Inc.
Obsoletes: 4133                                             D. Romascanu
Category: Standards Track                                          Avaya
ISSN: 2070-1721                                               J. Quittek
                                                         NEC Europe Ltd.
                                                         M. Chandramouli
                                                     Cisco Systems, Inc.
                                                                May 2013


                         Entity MIB (Version 4)

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects used for managing
   multiple logical and physical entities managed by a single Simple
   Network Management Protocol (SNMP) agent.  This document specifies
   version 4 of the Entity MIB.  This memo obsoletes version 3 of the
   Entity MIB module published as RFC 4133.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6933.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Page 2 
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. The SNMP Management Framework ...................................3
   2. Overview ........................................................3
      2.1. Terms ......................................................5
      2.2. Relationship to Community Strings ..........................6
      2.3. Relationship to SNMP Contexts ..............................6
      2.4. Relationship to Proxy Mechanisms ...........................6
      2.5. Relationship to a Chassis MIB ..............................7
      2.6. Relationship to the Interfaces MIB .........................7
      2.7. Relationship to the Other MIB Modules ......................7
      2.8. Relationship to Naming Scopes ..............................7
      2.9. Multiple Instances of the Entity MIB .......................8
      2.10. Re-Configuration of Entities ..............................9
      2.11. Textual Convention Change .................................9
      2.12. MIB Structure .............................................9
           2.12.1. entityPhysical Group ..............................10
           2.12.2. entityLogical Group ...............................12
           2.12.3. entityMapping Group ...............................12
           2.12.4. entityGeneral Group ...............................13
           2.12.5. entityNotifications Group .........................13
      2.13. Multiple Agents ..........................................13
      2.14. Changes Since RFC 2037 ...................................14
           2.14.1. Textual Conventions ...............................14
           2.14.2. New entPhysicalTable Objects ......................14
           2.14.3. New entLogicalTable Objects .......................14
           2.14.4. Bug Fixes .........................................14
      2.15. Changes Since RFC 2737 ...................................15
           2.15.1. Textual Conventions ...............................15
           2.15.2. New Objects .......................................15
           2.15.3. Bug Fixes .........................................15
      2.16. Changes Since RFC 4133 ...................................15
           2.16.1. MIB Module Addition ...............................15
           2.16.2. Modification to Some of the MIB Objects ...........15
           2.16.3. New TC for Universally Unique Identifier ..........16
   3. MIB Definitions ................................................16
      3.1. ENTITY-MIB ................................................16
      3.2. IANA-ENTITY-MIB ...........................................50
      3.3. UUID-TC-MIB ...............................................53
   4. Usage Examples .................................................55
      4.1. Router/Bridge .............................................55
      4.2. Repeaters .................................................62
      4.3. EMAN Example ..............................................69
   5. Security Considerations ........................................70

Top      ToC       Page 3 
   6. IANA Considerations ............................................72
   7. Acknowledgements ...............................................73
   8. References .....................................................73
      8.1. Normative References ......................................73
      8.2. Informative References ....................................74

1.  The SNMP Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

2.  Overview

   There is a need for a standardized way of representing a single
   agent, which supports multiple instances of one MIB module.  This is
   presently true for at least 3 standard MIB modules and is likely to
   become true for more and more MIB modules as time passes.  For
   example:

   - multiple instances of a bridge supported within a single device
     that has a single agent;

   - multiple repeaters supported by a single agent; and

   - multiple OSPF backbone areas, each operating as part of its own
     Autonomous System and each identified by the same area-id (e.g.,
     0.0.0.0), supported inside a single router with one agent.

   The single agent present in each of these cases implies a
   relationship binds these entities.  Effectively, there is some
   "overall" physical entity that houses the sum of the things managed
   by that one agent, i.e., there are multiple "logical" entities within
   a single physical entity.  Sometimes, the overall physical entity

Top      ToC       Page 4 
   contains multiple (smaller) physical entities, and each logical
   entity is associated with a particular physical entity.  Sometimes,
   the overall physical entity is a "compound" of multiple physical
   entities (e.g., a stack of stackable hubs).

   What is needed is a way to determine exactly which logical entities
   are managed by the agent (with some version of SNMP) in order to
   communicate with the agent about a particular logical entity.  When
   different logical entities are associated with different physical
   entities within the overall physical entity, it is also useful to be
   able to use this information to distinguish between logical entities.

   In these situations, there is no need for varbinds for multiple
   logical entities to be referenced in the same SNMP message (although
   that might be useful in the future).  Rather, it is sufficient, and
   in some situations preferable, to have the context/community in the
   message identify the logical entity to which the varbinds apply.

   Version 2 of this MIB addresses new requirements that have emerged
   since the publication of the first Entity MIB [RFC2037].  There is a
   need for a standardized way of providing non-volatile,
   administratively assigned identifiers for physical components
   represented with the Entity MIB.  There is also a need to align the
   Entity MIB with the SNMPv3 administrative framework (STD 62,
   [RFC3411]).  Implementation experience has shown that additional
   physical component attributes are also desirable.

   Version 3 of this MIB addresses new requirements that have emerged
   since the publication of the second Entity MIB [RFC2737].  There is a
   need to identify physical entities that are central processing units
   (CPUs) and a need to provide a Textual Convention (TC) that
   identifies an entPhysicalIndex value or zero, where the value zero
   has application-specific semantics.  Two new objects have been added
   to the entPhysicalTable to identify the manufacturing date and
   provide additional URIs for a particular physical entity.

   Version 4 of this MIB addresses new requirements that have emerged
   since the publication of the third version of the Entity MIB
   [RFC4133].  There is a need to add new enumerated values for entity
   physical classes, a need to provide identification information for
   physical entities using a Universally Unique Identifier (UUID)
   format, and a need to have compliant implementations of the Entity
   MIB with a smaller subsets of MIB objects for devices with
   constrained resources.

   The PhysicalClass TEXTUAL-CONVENTION was deprecated, and a new
   IANAPhysicalClass TC (maintained by IANA) was created.  A new TC,
   UUIDorZero, was created to represent a UUID, and a new MIB object was

Top      ToC       Page 5 
   added to the entPhysicalTable to identify an entity.  A new
   compliance statement, entity4CRCompliance, has been added for
   possible implementation of a selected subset of MIB objects by
   entities with constrained resources.

2.1.  Terms

   The following terms are used throughout this document:

   - Naming Scope
     A "naming scope" represents the set of information that may be
     potentially accessed through a single SNMP operation.  All
     instances within the naming scope share the same unique identifier
     space.  For SNMPv1, a naming scope is identified by the value of
     the associated entLogicalCommunity instance.  For SNMPv3, the term
     "context" is used instead of "naming scope".  The complete
     definition of an SNMP context can be found in Section 3.3.1 of RFC
     3411 [RFC3411].

   - Multi-Scoped Object
     A MIB object for which identical instance values identify different
     managed information in different naming scopes is called a "multi-
     scoped" MIB object.

   - Single-Scoped Object
     A MIB object for which identical instance values identify the same
     managed information in different naming scopes is called a "single-
     scoped" MIB object.

   - Logical Entity
     A managed system contains one or more "logical entities", each
     represented by at most one instantiation of each of a particular
     set of MIB objects.  A set of management functions is associated
     with each logical entity.  Examples of logical entities include
     routers, bridges, print-servers, etc.

   - Physical Entity
     A "physical entity" or "physical component" represents an
     identifiable physical resource within a managed system.  Zero or
     more logical entities may utilize a physical resource at any given
     time.  Determining which physical components are represented by an
     agent in the EntPhysicalTable is an implementation-specific matter.
     Typically, physical resources (e.g., communications ports,
     backplanes, sensors, daughter-cards, power supplies, and the
     overall chassis), which can be managed via functions associated
     with one or more logical entities, are included in the MIB.

Top      ToC       Page 6 
   - Containment Tree
     Each physical component may be modeled as 'contained' within
     another physical component.  A "containment-tree" is the conceptual
     sequence of entPhysicalIndex values that uniquely specifies the
     exact physical location of a physical component within the managed
     system.  It is generated by 'following and recording' each
     entPhysicalContainedIn instance 'up the tree towards the root'
     until a value of zero, indicating no further containment, is found.

2.2.  Relationship to Community Strings

   For community-based SNMP, differentiating logical entities is one
   (but not the only) purpose of the community string [RFC1157].  This
   is accommodated by representing each community string as a logical
   entity.

   Note that different logical entities may share the same naming scope
   and, therefore, the same values of entLogicalCommunity.  This is
   possible, providing they have no need for the same instance of a MIB
   object to represent different managed information.

2.3.  Relationship to SNMP Contexts

   Version 2 of the Entity MIB contains support for associating SNMPv3
   contexts with logical entities.  Two new MIB objects, defining an
   SnmpEngineID and ContextName pair, are used together to identify an
   SNMP context associated with a logical entity.  This context can be
   used (in conjunction with the entLogicalTAddress and
   entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of a
   particular logical entity.

2.4.  Relationship to Proxy Mechanisms

   The Entity MIB is designed to allow functional component discovery.
   The administrative relationships between different logical entities
   are not visible in any Entity MIB tables.  A Network Management
   System (NMS) cannot determine whether MIB instances in different
   naming scopes are realized locally or remotely (e.g., via some proxy
   mechanism) by examining any particular Entity MIB objects.

   The management of administrative framework functions is not an
   explicit goal of the Entity MIB WG at this time.  This new area of
   functionality may be revisited after some operational experience with
   the Entity MIB is gained.

Top      ToC       Page 7 
   Note that for community-based versions of SNMP, a network
   administrator will likely be able to associate community strings with
   naming scopes that have proprietary mechanisms, as a matter of
   configuration.  There are no mechanisms for managing naming scopes
   defined in this MIB.

2.5.  Relationship to a Chassis MIB

   Some readers may recall that a previous IETF working group attempted
   to define a Chassis MIB.  No consensus was reached by that working
   group, possibly because its scope was too broad.  As such, it is not
   the purpose of the ENTITY-MIB module to be a "Chassis MIB
   replacement", nor is it within the scope of the ENTITY-MIB module to
   contain all the information that might be necessary to manage a
   "chassis".  On the other hand, the entities represented by an
   implementation of the ENTITY-MIB module 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
   [RFC2863].  Because 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.

   The Entity MIB also contains entPhysicalName and entPhysicalAlias
   objects, which approximate the semantics of the ifName and ifAlias
   objects (respectively) from the Interfaces MIB [RFC2863] for all
   types of physical components.

2.7.  Relationship to the Other MIB Modules

   The Entity MIB contains a mapping table identifying physical
   components that have identifiers from other standard MIB modules
   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 that are not multi-scoped within a
   managed system are likely to ignore context information in

Top      ToC       Page 8 
   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 [RFC4188].

   The isolation of single-scoped MIB objects by the agent is an
   implementation-specific matter.  An agent may wish to limit the
   objects returned in a particular naming scope to only 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 may exist in a managed
   system.  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.

   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 a 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.

Top      ToC       Page 9 
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 ENTMIB working group (which was in charge of the document at that
   point) realized that this change is not strictly supported by SMIv2.
   In their judgment, the alternative of deprecating the old objects and
   defining new objects would have had 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.

   - 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.

Top      ToC       Page 10 
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 that are field-replaceable (i.e., not permanently
     contained within another physical entity).

   - entPhysicalSerialNum
     This string is provided to store a vendor-specific serial number
     string for physical components.  This writable object is used when
     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).

Top      ToC       Page 11 
   Version 3 of the Entity MIB provides two additional MIB objects for
   each physical entity:

   - entPhysicalMfgDate
     This object contains the date of manufacturing of the managed
     entity.  If the manufacturing date is unknown or not supported the
     object is not instantiated.  The special value '0000000000000000'H
     may also be returned in this case.

   - entPhysicalUris
     This object provides additional identification information about
     the physical entity.

     This object contains one or more Uniform Resource Identifiers
     (URIs); therefore, the syntax of this object must conform to
     [RFC3986], Section 3.  Uniform Resource Names (URNs) [RFC3406] are
     resource identifiers with the specific requirements for enabling
     location-independent identification of a resource, as well as
     longevity of reference.  URNs are part of the larger URI family
     with the specific goal of providing persistent naming of resources.
     URI schemes and URN namespaces are registered by IANA (see
     http://www.iana.org/assignments/uri-schemes and
     http://www.iana.org/assignments/urn-namespaces).

     For example, the entPhysicalUris object may be used to encode a URI
     containing a Common Language Equipment Identifier (CLEI) URN for
     the managed physical entity.  The URN namespace for CLEIs is
     defined in [RFC4152], and the CLEI format is defined in [T1.213]
     and [T1.213a].  For example, an entPhysicalUris instance may have
     the value of:

        URN:CLEI:D4CE18B7AA

     [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN
     namespace.  The specific CLEI code, D4CE18B7AA, is based on the
     example provided in [T1.213a].

     Multiple URIs may be present and are separated by white space
     characters.  Leading and trailing white space characters are
     ignored.

     If no additional identification information is known about the
     physical entity or supported, the object is not instantiated.

     Version 4 of the Entity MIB module provides an additional MIB
     object for each physical entity.

Top      ToC       Page 12 
   - entPhysicalUUID
     This object provides an unique identification about the physical
     entity.  This object contains a globally unique identifier for the
     physical entity with the format defined in RFC 4122 [RFC4122].

     To support the existing implementations of ENTITY-MIB version 3
     [RFC4133], entPhysicalUris object should be used to store the UUID
     value of the physical entity as well in URN format.  This
     duplication of information enables backward compatibility.  Note
     that entPhysicalUris allows write access while entPhysicalUUID is
     read-only.

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 [RFC3411] method of context identification.

   If an 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.

   - entLPMappingTable
     This table 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.

Top      ToC       Page 13 
   - entAliasMappingTable
     This table contains mappings between entLogicalIndex,
     entPhysicalIndex pairs, and 'alias' object identifier values.  This
     allows resources managed with other MIB modules (e.g., repeater
     ports, bridge ports, physical and logical interfaces) to be
     identified in the physical entity hierarchy.  Note that each alias
     identifier is 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.

   - entPhysicalContainsTable
     This table 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, another
   motivation is 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 that should be expected for agent implementations.
   Therefore, multiple agents within the same managed system are free to
   implement the Entity MIB independently.  (For more information, refer
   to Section 2.9, "Multiple Instances of the Entity MIB".)

Top      ToC       Page 14 
2.14.  Changes Since RFC 2037

2.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.

2.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.  In the event the agent
   cannot identify this information, the entPhysicalSerialNum object can
   be set by a management station.

   The entPhysicalAlias and entPhysicalAssetID objects have been added
   for better user component identification.  These objects are intended
   to be set by a management station and preserved by the agent across
   restarts.

2.14.3.  New entLogicalTable Objects

   The entLogicalContextEngineID and entLogicalContextName objects have
   been added to provide an SNMP context for SNMPv3 access on behalf of
   a logical entity.

2.14.4.  Bug Fixes

   A bug was fixed in the entLogicalCommunity object.  The subrange was
   incorrect (1..255) and is now correct (0..255).  The description
   clause has also been clarified.  This object is now deprecated.

   The entLastChangeTime object description has been changed to
   generalize the events that cause an update to the last change
   timestamp.

   The syntax was changed from DisplayString to SnmpAdminString for the
   entPhysicalDescr, entPhysicalName, and entLogicalDescr objects.

Top      ToC       Page 15 
2.15.  Changes Since RFC 2737

2.15.1.  Textual Conventions

   The PhysicalIndexOrZero TC has been added to allow objects to
   reference an entPhysicalIndex value or zero.  The PhysicalClass TC
   has been extended to support a new enumeration for central processing
   units.

2.15.2.  New Objects

   The entPhysicalMfgDate object has been added to the entPhysicalTable
   to provide the date of manufacturing of the managed entity.

   The entPhysicalUris object has been added to the entPhysicalTable to
   provide additional identification information about the physical
   entity, such as a Common Language Equipment Identifier (CLEI) URN.

2.15.3.  Bug Fixes

   The syntax was changed from INTEGER to Integer32 for the
   entPhysicalParentRelPos, entLogicalIndex, and
   entAliasLogicalIndexOrZero objects, and from INTEGER to
   PhysicalIndexOrZero for the entPhysicalContainedIn object.

2.16.  Changes Since RFC 4133

2.16.1.  MIB Module Addition

   Over time, there may be the need to add new enumerated values to the
   PhysicalClass TEXTUAL-CONVENTION.  To allow for such additions
   without requiring re-issuing of this MIB module, a new MIB module
   called IANA-ENTITY-MIB that provides the IANA-maintained TEXTUAL-
   CONVENTION IANAPhysicalClass has been created.  The PhysicalClass TC
   has been deprecated.

2.16.2.  Modification to Some of the MIB Objects

   A new MIB object has been added to the entPhysicalTable,
   entPhysicalUUID.  In comparison to entPhysicalUris, the new object is
   read-only and restricted to a fixed size to allow only for RFC 4122
   [RFC4122] compliant values.  The PhysicalClass TEXTUAL-CONVENTION was
   deprecated, and a new IANAPhysicalClass TC (maintained by IANA) has
   been created.

Top      ToC       Page 16 
   Two new MODULE-COMPLIANCE modules have been created:
   entity4Compliance for full compliance with version 4 of the Entity
   MIB, and entity4CRCompliance for devices with constrained resources
   like batteries that might require a limited number of objects to be
   supported (entPhysicalClass, entPhysicalName, and entPhysicalUUID).

2.16.3.  New TC for Universally Unique Identifier

   A new TEXTUAL-CONVENTION, UUIDorZero, was created to represent a
   Universally Unique Identifier (UUID) with a syntax that conforms to
   [RFC4122], Section 4.1.  Defining it as a TC will allow for future
   reuse in other MIB modules that will import the TC.  This Textual
   Convention is included in the UUID-TC-MIB module.



(page 16 continued on part 2)

Next RFC Part