2.4.4 Entity MIB (entmib)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 25-Mar-98


Keith McCloghrie <kzm@cisco.com>

Operations and Management Area Director(s):

John Curran <jcurran@bbnplanet.com>
Michael O'Dell <mo@uu.net>

Operations and Management Area Advisor:

John Curran <jcurran@bbnplanet.com>

Mailing Lists:

General Discussion:entmib@cisco.com
To Subscribe: majordomo@cisco.com
In Body: subscribe entmib your_email_address
Archive: ftp://ftp.cisco.com/entmib/entmib

Description of Working Group:

This working group is chartered to standardize a set of managed objects representing logical and physical entities and the relationships between them. Logical entities can occur when a single agent supports multiple instances of one MIB, such as RFCs 1253, 1493, 1516 or 1525, where each instance represents a single (logical) device/entity. Physical entities are the actual physical components on which the logical entities operate; typically, the physical components exist in a hierarchy. The set of objects will be consistent with the SNMP framework and existing SNMP standards.

The scope of the defined managed objects should allow an NMS to interrogate a standard SNMP context and thereby discover what logical and physical entities exist, how to access the MIB information of each logical entity, and the relationships between the various entities. The MIB should support both a single agent or multiple agents in one physical entity. The Working Group should adopt a minimalist approach for the (initial) MIB so as to maximize the chance of success, e.g., read-only.

Goals and Milestones:



Hold BOF at Stockholm IETF.



Post Internet-Draft for Entity MIB.



Meet at Dallas IETF to review Internet-Draft and the issues raised during mailing list discussion.



Post updated Entity MIB Internet-Draft.



Meet at IETF to reach consensus on updated Internet-Draft.



Submit final version of Internet-Draft for consideration as a Proposed Standard.

Apr 98


Finalize scope of changes/augmentations to RFC 2037

Apr 98


Post updated/new Internet Drafts

Aug 98


Reach agreement on changes/extensions to RFC 2037

Oct 98


Evaluate status of RFC 2037 and report to the IESG if it should be recycled at Proposed or can be elevated to Draft Standard.

Oct 98


Submit Internet Draft containing Entity MIB Extensions to IESG for consideration as a Proposed Standard.


Request For Comments:







Entity MIB

Current Meeting Report

Minutes of the Entity MIB (entmib) Working Group

Reported by Andy Bierman


The Entity WG met to advance progress on all issues under consideration by the working group.

Review Material

[1] Entity MIB <RFC 2037>
[2] Entity MIB Extensions <draft-ietf-entmib-ext-00.txt>


WG status review
elevate 2037
2026 requirements reminder
implementation feedback
changes for PTOPO MIB support
changes for SNMPv3 support


I. RFC 2037 Interoperability Reports

The WG Chair conducted an implementation survey (previously sent to the mailing list) for all MIB objects in RFC 2037. This report is required for the RFC to elevate from Proposed to Draft Standard.

Approximately six to ten vendors have implemented all or part of the Entity MIB in one or more products. Three of the four vendors who gave implementation reports developed the entire MIB. The WG consensus is that all objects are useful and implementable.

Many vendors did both the agent and NMS implementations, but it appears that no generic or multi-vendor NMS applications are available which utilize the Entity MIB. Some vendors have not implemented the Entity MIB yet, due to large investments in proprietary solutions, which provide functionality similar to the Entity MIB.

There were several comments made regarding new features which should be added to the MIB. These are covered in section 2. Two problems encountered during agent development were discussed:

These discussions resulted in some MIB changes and additions, which are detailed in the next section.

II. RFC 2037 Extensions

2.1) Number of Documents

The WG decided to keep the Entity MIB objects in a single document, which will obsolete RFC 2037. The new Entity MIB will cycle at Proposed Standard, and therefore the WG will not attempt to elevate RFC 2037 to Draft Standard status at this time.

2.2) SNMPv3 Logical Entity Support

These extensions allow the Entity MIB to be used in an SNMPv3 environment. There are two mandatory objects added to the entPhysicalTable, entLogicalContextEngineID and entLogicalContextName. [2] They provide the context information needed to send SNMPv3 PDUs to the authoritative SNMPv3 Engine containing management information on behalf of the logical entity. These two objects are used in conjunction with the existing entLogicalTAddress and entLogicalTDomain objects.

2.2.1) entLogicalCommunity Deprecated

The entLogicalCommunity object will be deprecated in favor of the new objects which support SNMPv3 contexts.

2.2.2) Authoritative Context

The entLogicalContextEngineID object DESCRIPTION will be clarified to indicate that it represents the 'authoritative' engine ID associated with the logical entity.

2.2.3) Context Description Coupling

The entLogicalContextEngineID and entLogicalContextName object DESCRIPTION clauses will be clarified to indicate that the two objects together define the context associated with the logical entity.

2.3) Selection of entPhysical Extensions

Many vendors have added proprietary extensions to the entPhysical group. The WG considered the implementation experience of these vendors, and also considered the attributes provided in the DMTF Component Group, and the related CIM attributes.

The WG decided to add many new objects to the entPhysicalEntry, to better identify each physical component. Two new component types will also be added.

2.4) New entPhysicalClass Enumerations

Implementation experience has shown that it is difficult to represent 'stackable' products correctly with the entPhysical group.

A new enumeration called 'stack' will be added to represent the overall container of components belonging to the same stack.

A new enumeration called 'interconnect' will be added to represent any physical interconnect between two or more physical components. This is intended to represent the 'ribbon cable' connecting components together into a stack.

2.5) entPhysicalAlias

The entPhysicalAlias object defined in [2] will be added to the entPhysicalEntry.

2.6) Revision Strings

Three new revision strings (hardware, firmware, and software) will be added to the entPhysicalEntry. These strings are simple printable strings, which may include multiple revision entries per string. These objects all have a max-access of read-only.

A new TC will be defined to represent the format of these revision strings. The basic syntax will be SnmpAdminString, which will be refined to specify a field separator between each version string. The TC will also specify an algorithm for converting binary strings to printable hexadecimal characters (ASCII-HEX). The length range for the TC will be 0..255 octets.

2.6.1) Field Separators

The WG discussed the format of the field separator for the new revision string TC in great detail. Unfortunately, there is no clear WG consensus on this issue at this time. It is clear that the WG wants the entire string to be printable, so applications unaware of the field separators will be unaffected by them.

Proposals for the field separator include:

This issue will be discussed further on the mailing list. If no consensus emerges, the field separator will be left as an implementation-specific matter, but will be restricted to printable characters.

2.7) Serial Number

The serial number object is a printable UTF-8 string, containing the manufacturer serial number for the physical component. The max-access of this object is read-write, to allow for components which do not have 'burned in' serial numbers. The normal access is read-only, and the min-access is not-accessible. The conformance statement will make it clear which access level is required, based on the implementation limitations.

2.8) Manufacturer Name, Asset Tracking and Model Identifiers

A read-write asset identifier, with syntax of SnmpAdminString, will be added to the entPhysicalEntry. Read-only manufacturer and model identifier objects (with the same syntax) will also be added.

The read-write asset string is still controversial, since a large number of long asset identifiers can require a great deal of non-volatile storage to implement. The zero length string is the default value for these objects.

III. Interoperability Testing

The WG discussed the possibility of holding an interoperability test event for the Entity MIB. The WG decided not to hold such an event at this time. The issue will be revisited after the WG finishes the new Entity MIB document.


None Received

Attendees List

go to list