2.4.4 Entity MIB (entmib)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Nov-97


Keith McCloghrie <kzm@cisco.com>

Operations and Management Area Director(s):

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

Operations and Management Area Advisor:

John Curran <jcurran@bbn.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:

The goal of this working group is 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 this MIB 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.

Dec 95


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

Jan 96


Post updated Entity MIB Internet-Draft.

Mar 96


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

Apr 96


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


Request For Comments:







Entity MIB

Current Meeting Report

Minutes of the Entity MIB (entmib) WG

WG Chair: Keith McCloghrie
Reported by: Andy Bierman


The Entity MIB WG reconvened at this meeting. The new charter will be essentially unchanged from the original charter. The WG intends to advance the status of RFC 2037 and add additional features, such as SNMPv3 context support and non-volatile name strings for physical components.


1) Introduction
2) Proposed New Charter
3) Discussion of Work Items

4) Proposed Steps Forward

Detailed Account of Agenda Items

1) WG History

A 'History of the WG' was presented by the WG Chair, which included accounts of the Chassis MIB WG effort, and the publication history of the Entity MIB (RFC 2037).

2) Status of RFC 2037

The WG must decide what 'status-action' should be pursued for the Entity MIB, which is currently at Proposed Draft Standard status. The choices are:

a) Advance (all or part) to Draft Standard status
b) Cycle (all or part) at Proposed Draft Standard status
c) Remove the standard (all or part) by assigning Historic status

The WG agreed that choice (a) will be pursued for all existing MIB objects. New objects will be added independently, and follow a different standards track.

3) New Charter

The existing charter was presented by the WG Chair. It was proposed that
only editorial changes be made to the charter. The WG agreed to this
decision, except that new features are not restricted to read-only access.

3.1) Time-Table for New Charter

A list of milestones was proposed by the WG Chair and accepted by the WG:

4) Physical Topology MIB Support

The WG Editor presented a summary of the internet draft: draft-bierman-entmib-compid-01.txt.

This I-D proposes an augmentation to the entPhysicalTable, which contains a read-write string (entPhysicalAlias), used much the same way as the ifAlias object in the Interfaces MIB (RFC 2233).

The WG agreed to add this object to the updated Entity MIB, after some editorial changes are discussed on the mailing list. There is some ambiguity regarding the semantics of a particular entPhysicalAlias value after a physical component is moved from one location to another one within the same chassis (i.e., does the moved card name have to stay the same, change to a new value, or either one?) The WG will discuss changes to this I-D on the mailing list.

The PTOPO MIB would like the Entity MIB WG to produce an update to RFC 2037, which contains the entPhysicalAlias object, since the PTOPO MIB documents cannot progress until the non-volatile 'chassis ID' name string is added to the Entity MIB. (The PTOPOMIB WG may consider adding the 'Chassis ID' support to the PTOPO MIB, to remove this dependency.)

The Entity MIB WG discussed the possibility of producing the quick update requested by the PTOPOMIB WG. This idea was tabled for now, and the WG will follow the proposed timeline (in section 3.1).

5) SNMPv3 Changes

The WG discussed the scope of changes needed for SNMPv3 support.

6) EntPhysicalParentRelPos Bug

An issue was raised on the mailing list regarding the entPhysicalParentRelPos object. The WG Editor clarified the correct behavior for this object for containers and modules. The containers modeled by the agent should have a parent-relative position as identified by the writing on the equipment itself (e.g., container for slot #3 has a entPhysicalParentRelPos value of 3). The module(s) plugged into a particular container have a parent-relative position with respect to that container (e.g., the card in container #3 has an entPhysicalParentRelPos value of 1). The Entity MIB contains incorrect examples which show this value to be the same as that of the container entry (e.g., '3' instead of '1'). These examples will be corrected in the updated Entity MIB.

7) RFC Advancement Criteria

The WG Chair must seek implementation feedback on RFC 2037, according to the guidelines in RFC 2026. At least two independent and interoperable implementations from different code bases demonstrating "sufficient successful operational experience" must be identified, fostering a strong belief that the technology is mature and will be useful.

8) Entity MIB Implementation Experience

The WG chair must document the implementation experience. The WG members present at this meeting were asked the following questions, directed at any implementation efforts.

Four vendors present had implemented some or all of the Entity MIB. A full implementation report will be presented later, after WG members on the mailing list have been queried for implementation experience.

In general, all four vendors were able to implement the MIB without difficulty. The entPhysical group was the most widely implemented group. The entLogical group is not really needed if all MIB objects are within a single naming scope, and this was reflected in implementation experience. One vendor utilized multiple entLogicalTable entries to support multiple instances of the Bridge MIB.

The various mapping tables were utilized differently, depending on the system. A repeater implementation may utilize the entAliasMappingTable for "repeater port to ifIndex" mappings, and an implementation for a very large system (i.e., large number of entPhysicalTable entries) may rely on the entPhysicalContainsTable to reduce data retrieval time.

There were some suggestions for new objects:

9) Interoperability Testing

The WG discussed ideas for an interoperability bake-off in the near future. The most attractive plan requires several vendors to make agent implementations available for query over the Internet. The mailing list will be used to coordinate this effort. It is possible that a real test event will be planned some time in the future.


None Received

Attendees List

go to list

Previous PageNext Page