2.4.5 Entity MIB (entmib)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


Keith McCloghrie <kzm@cisco.com>

Operations and Management Area Director(s):

Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Bert Wijnen <wijnen@vnet.ibm.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

OPS Area
ENTMIB WG Meeting Minutes
43rd IETF
Orlando, FL USA
December 7, 1998
WG Chair: Keith McCloghrie <kzm@cisco.com>
Minutes: Andy Bierman <abierman@cisco.com>


The Entity WG met to advance progress on the following work-in-progress:

[1] Entity MIB using SMIv2 (Version 2) <draft-ietf-entmib-v2-01.txt>


Advancement of draft-ietf-entmib-v2-01.txt:


1) Review comments from WG mailing list

The issues raised in an email (dated 14-nov-98) from Cliff Sojourner <cls@cisco.com> were discussed at length.

E1: asset information is only needed for FRU components. All the zero-length strings in the entPhysicalTable are just polling overhead.

Proposal 1: put the asset information in a separate table.

There was no WG consensus for special restrictions on which physical entity types may contain asset information. There was also no agreement on the exact definition of the term, "field-replaceable unit" (FRU). The definition of FRU can change over time for a given product, and not all components are field replaceable at the same level of expertise.

There was no WG consensus to move objects to a new 'SPARSE-AUGMENTS' table.

Resolution: Proposal 1 rejected.

E1-Addendum: Need some generic way to identity FRUs

Proposal 2: Add an flag to identify Field Replaceable Units

Add a TruthValue r/o column to the entPhysicalTable called 'entPhysicalIsFRU'. The new 'entPhysicalIsFRU' object is needed because not all removable components are considered field replaceable units by the vendor.

[Ed., A similar object was proposed by the WG Editor in a very early version of the Entity MIB, but it was removed before RFC 2037 was published. The entPhysicalIsRemovable object could be derived from the parent entity (i.e., if the parent's entPhysicalClass is 'container(5)', then the child entity is removable.)]

The WG could not agree on the definition of a FRU, but did agree it was useful to identify them in the entPhysicalTable. There were no arguments against adding this object.

Resolution: Proposal 2 accepted

E2: entPhysicalModelName semantics are unclear.

There is a need to differentiate between "orderable part number" and "manufacturing assembly number", and the object DESCRIPTION clause is unclear on which string to use.

Proposal 3: Specify that the entPhysicalModelName string is the customer-visible "orderable part number".

The WG did not agree on the need to for a new string object, but did agree this string should represent the orderable part number.

Resolution: Proposal 3 accepted.

Proposal 4: Add a new NV-stored SnmpAdminString to contain the manufacturing assembly number. This object is only instantiated if entPhysicalIsFRU is true.

There was no WG consensus that this object was needed. The NV-storage requirement is too high, and enough information is available to uniquely identify a component (e.g., entPhysicalModelName and entPhysicalHardwareRev strings).

Resolution: Proposal 4 rejected.

Proposal 5: entPhysicalMfgName clarification

Revise the entPhysicalMfgName DESCRIPTION to be clear that the other asset objects (sw/fw/hw revision, serial number, orderable part number, mfg ass'y number) only make sense in the context of that manufacturer. In other words, don't compare or collate these objects when they are from different manufacturers.

There were no objections from the WG.

Resolution: Proposal 5 accepted

E3: entPhysicalTable has no way to represent double-high modules

The entPhysicalContainedIn object allows one parent container entity to be identified, but some modules occupy more than one container.

Proposal 6: Model this information in the entPhysicalContainsTable.

Add text to the entPhysicalContainedIn object requiring the lowest numbered (value of entPhysicalIndex) entPhysicalEntry be used, in the event more than one parent entity exists. The entPhysicalContainsTable DESCRIPTION clause will also be clarified to encourage implementors to model all 'contained-in' relationships, for child entities which have more than one parent container entity.

There were no objections from the WG.

Resolution: Proposal 6 accepted

E4: implementation of user-writable objects is problematic

Proposal 7: entPhysicalAlias should be removed. This object correctly lies in the asset/spares/inventory management application.

There was no WG consensus to change or remove entPhysicalAlias. This object is needed to support the PTOPO Chassis Identifier attribute, and it is writable to allow an NMS to insure all chassis identifiers are unique within an administrative domain.

Resolution: Proposal 7 rejected

E5: specify the MIBs that are expected to populate logical entries

Proposal 8: list at least some standard MIBs that are expected to use the Entity MIB.

There was no WG consensus that this change was needed, or that the Entity MIB was the proper document to specify such behavior (e.g., the Bridge MIB WG should specify in the Bridge MIB, how the Entity MIB relates to multiple instances of the Bridge MIB).

Resolution: Proposal 8 rejected

E6: make entPhysicalIndex MAX-ACCESS accessible-for-notify

Proposal 9: change the INDEX object from not-accessible to accessible-for-notify, so it may be included as a varbind in notifications.

There was no WG consensus that this change was needed or even desirable. This change would set a precedent for all INDEX clauses, without good cause. The entPhysicalClass object is accessible, an instance of entPhysicalClass already identifies the entPhysicalIndex value, and it contains the same number of 'bits on the wire' as the proposed change.

Resolution: Proposal 9 rejected

E7: Need to define FRU

Proposal 10: Define "FRU" early in the draft and use the term, then MIB object descriptions won't have circumlocutions like "Physical entities which are permanently 'contained in' another physical entity (e.g., the repeater ports within a repeater module)".

The WG could not agree on the need to define a FRU, or the definition of a FRU, but did recognize that this is a different issue than simply identifying a FRU (see Proposal 2).

Resolution: Proposal 10 rejected

E8 and E9: Errata and Typos

The old (obsolete) text will be removed.

These bugs will be fixed in the next draft.

E10: SnmpAdminString size range semantics unclear

Are multi-byte UTF-8 characters counted as 1 'unit' in INDEX sub-ranges, or does each byte count as 1 'unit'.

This issue has already been resolved in the SNMPv3 WG. The sub-range limits refer to the number of octets used to encode all the UTF-8 characters, not the number of UTF-8 characters.

2) Any other WG comments on the I-D

The WG chair then opened the floor to discussion of any issues not already covered in the previous section.

F1: Trap Throttling

The entPhysicalChange trap must be throttled by the agent to insure that only one trap event is generated in a five second interval. There were several WG members who had issues with various portions of the text which defines this behavior.

The WG considered adding a MIB object to specify the mandatory throttling interval (including none) the agent must implement. This idea was eventually rejected in favor of a simpler approach.

Proposal 11: Relax the restrictive text in the entConfigChange NOTIFICATION-TYPE description from a "must throttle" to a "should throttle", and make the five second throttling period a suggested default, instead of a mandatory value.

The WG did not reach full resolution on this issue before the meeting concluded, but there seemed to be strong WG consensus that this was a good way to resolve the issue.

Resolution: Proposal 11 accepted

F2: EntConfigChange clarifying text

The entConfigChange DESCRIPTION clause text will be changed to indicate the throttling requirement applies to the lower level throttling entity, in a sub-agent environment, rather than the upper level SNMPv3 Notification Originator application, as defined in RFC 2271.

If sub-agents are used, the throttling period applies to the entire set of Entity MIB sub-agents.

The term 'trap' will be replaced with the term 'notification'.
The term 'send' will be replaced with the term 'emit'.

3) Is the MIB ready for WG Last Call?

The WG Chair outlined a schedule for completion of the current charter. There were no objections from the WG.

A 4 week WG Last Call will be issued when the next version of the Entity MIB draft is published. A new draft is expected before January 1999.


None received.