Current Meeting Report
Jabber Logs

2.4.5 Entity MIB (entmib)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/06/2002

Margaret Wasserman <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Bert Wijnen <>
Mailing Lists:
General Discussion:
To Subscribe:
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 1493, 1525, or 1850 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 WG will also standardize a set of managed objects representing sensor entities. Sensor entities are physical entities that report a value based on external conditions, such as temperature sensors, power monitors, etc. The Sensor Entity MIB will augment the basic Entity MIB to allow an NMS to obtain the value reported by a sensor. This MIB will not contain internal support for alarms or thresholds, but should work with standard alarm and threshold MIBs, such as RMON-2.

Goals and Milestones:
Done  Post Internet-Draft for Entity MIB.
Done  Post updated Entity MIB Internet-Draft.
Done  Submit final version of Internet-Draft for consideration as a Proposed Standard.
Done  Finalize scope of changes/augmentations to RFC 2037
Done  Post updated/new Internet Drafts
Done  Reach agreement on changes/extensions to RFC 2037
Done  Evaluate status of RFC 2037 and report to the IESG if it should be recycled at Proposed or can be elevated to Draft Standard.
Done  Submit Internet Draft containing Entity MIB Extensions to IESG for consideration as a Proposed Standard.
Done  Evaluate status of Entity MIB and collect implementation and interoperability reports
Done  Recommend to the IESG if Entity MIB can be elevated to Draft Standard.
Done  Post Internet-Draft for Sensor Entity MIB
JAN 02  Determine if the Entity MIB should be modified to resolve any open issues
FEB 02  Re-cycle the updated Entity MIB at proposed standard, if necessary
APR 02  Submit final version of Internet-Draft for Sensor Entity MIB for consideration as a Proposed Standard
JUL 02  Evaluate status of the Entity MIB and collect implementation and interoperability reports
SEP 02  Recommend to the IESG if the Entity MIB can be elevated to Draft Standard.
OCT 02  Evaluate status of the Sensor Entity MIB and collect implementation and interoperability reports
DEC 02  Recommend to the IESG if the Sensor Entity MIB can be elevated to Draft Standard
JAN 03  Re-charter or shut-down the WG
  • - draft-ietf-entmib-sensor-mib-01.txt
  • - draft-ietf-entmib-v3-00.txt
  • Request For Comments:
    RFC2037 PS Entity MIB
    RFC2737 PS Entity MIB (Version 2)

    Current Meeting Report

    Entity MIB WG (entmib) Minutes
    Tuesday, November 19, 0100-0200
    CHAIR: Margaret Wasserman <>
    Introduction and Agenda Bashing -- Margaret(5 min)
    State/Status Information for Entity MIB -- Sharon Chisholm (30 min)
    Wrap-up & Next Steps -- Margaret (10 min)
    Introduced state/status extension and discussed whether they would be 
    added to Entity MIB or published separately.  Andy: Would prefer to 
    publish separately, because he is concerned that the addition of new 
    variables will make it take longer to get two implementations.
    [Sharon Chisholm presented state/status extensions.  See slides.]
    Discussion of the meaning of "busy".  Works well in an situation with 
    discrete uses (i.e. slots), but is harder to map to things like fans.
    Discussed whether to include in Entity MIB document or publish as a 
    separate document.
    Andy: This is more of a sparse augments than an augments.  Sharon & Dave 
    Perkins pointed out that you could use the "lock" feature to 
    administratively lock an object, etc.  Andy:  Can live with a full 
    augments, but some things will get hard-wired to non-useful values.
    Andy: Would like to have min-access read-only on admin objects.  
    Sharon: Agrees.
    Mike M.:  Would like the two documents to be separate, because he 
    doesn't want ITU states to be wedded to the Entity MIB.
    Randy Presuhn:  Thinks this should be a sparse augments.  Nothing in the ITU 
    document indicates otherwise.  We need to be very careful not to confuse 
    admin state with security policy -- very different things.  
    Administratively locking a device does not necessarily provide access 
    Margaret:  Would like it to be separate to avoid delays to Entmib.  Andy:  
    Maybe a feature, not a bug to put modules in different MIB files.  Not all 
    may apply to the same box.
    Consensus:  Do we want to put the state/status into the same file as the 
    Entity MIB, or a separate MIB file?  Strong consensus for separate.
    Andy:  Question of whether to do this as a sparse augments or an 
    augments.  Also question of whether to do min-access of Read-Only.
    Consensus: Sparse augments via full augments?  Consensus for sparse 
    Min-access of Read-Only vs. Read-Write?  Split -- no consensus.
    Bert:  Could, instead, do two different compliance statements.  One of R/W 
    access and one for R/O access.  Randy Presuhn:  May not be consistent 
    across a product -- some parts may be R/O and others R/W.
    Kem:  Thinks that administrative variable should be R/W, even if some of 
    them aren't.  Randy P.:  That's what min-access R/O does.  Bert:  
    Prefers compliance statement, so that if an implementation claims full 
    compliance, all of the objects will be R/W.  Other compliance 
    statement indicates that some rows do not have R/W.  Sharon:  Issue is that 
    when the compliance statement only indicates R/O, manager may assume that 
    everything is R/O (and not try to write).
    Randy Presuhn:  We should have a max-access of R/W and two compliance 
    statements -- one that is R/W and one with a min-access of R/O.  Bert:  Can 
    we specify a max-access in the compliance statement?  Several: No.  
    Randy:  Even if we don't do a min-access, the management statement will 
    have to deal with the fact that it may not be able to write to some 
    Consensus:  Max-access of R/W and two compliance statements, one that is R/W 
    for all, and one that has a min-access of R/O.
    Sharon and Dave P. will do updates based on the feedback from this 
    meeting and re-publish.
    Regarding advancement of Entity MIB.  Andy will send mail to the mailing 
    list indicating what we would have to deprecate to remove the logical 
    table.  Margaret will check on the status of the Wind River 
    implementation and report back.


    Entity MIB State Extensions