Current Meeting Report
Slides


2.4.5 Entity MIB (entmib)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/06/2002

Chair(s):
Margaret Wasserman <mrw@windriver.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: entmib@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/entmib
Archive: www.ietf.org/mail-archive/working-groups/entmib/current/maillist.htm
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
Internet-Drafts:
  • - draft-ietf-entmib-sensor-mib-00.txt
  • - draft-ietf-entmib-v3-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC2037 PS Entity MIB
    RFC2737 PS Entity MIB (Version 2)

    Current Meeting Report

    Entity MIB WG (entmib) Minutes
    IETF 54 Yokohama, Japan
    Tuesday, July 16, 2002 @ 0215-0315
    ==================================

    CHAIR: Margaret Wasserman <mrw@windriver.com>

    AGENDA:

    Introduction and Agenda Bashing (5 min)

    Entity MIB Updates and Open Issues -- Andy Bierman (10 min)
    <http://www.ietf.org/internet-drafts/draft-ietf-entmib-v3-00.txt>

    Sensor Entity MIB Status and Open Issues -- Andy Bierman (5 min)
    <http://www.ietf.org/internet-drafts/draft-ietf-entmib-sensor-mib-00.txt>

    State/Status Information for Entity MIB -- Sharon Chisholm (15 min)
    <See email to entmib@ietf.org dated 4-Jul-02>

    Next Steps -- Margaret (10 min)


    DISCUSSION MINUTES:

    Status of current work
    Entity Sensor MIB has been submitted to the IESG for PS Entity MIB updates completed as agreed at last meeting.

    Consensus that the Entity MIB changes accurately reflect feedback from last meeting.

    Entity State discussion

    <Sharon Chisholm presented State/Status proposal>

    Discussion of whether we should add redundancy support to the requirements for State/Status. For instance, the ability to indicate the index of the entity for which this is redundant. May be more complex to handle N+N and N+M redundancy. Or would support for 1+1 redundancy be a 90% solution.

    Options:

    - Add objects to the Entity MIB tables
    - Add a state table to the Entity MIB
    - Create a new MIB with state info

    What model to use?

    David Perkins: Glad we are doing this. Has worked on this before -- a compromise IETF-like version.

    Andy: Could be done with 4 or 5 objects.

    Randy Presuhn: By definition, this is sparse. Some entities won't have some state objects

    Need to be careful, when we define state objects and descriptions that we actually get everything that we need. Current ITU document cover a 3-dimensional state model that considers usage information. If we want to compress to two dimensions, need to be careful.

    Margaret: Prefers to do separate MIB.

    Sharon: May turn into a big project that way.

    Andy: Whole new MIB module requires taking a charter update to the IESG. Perhaps not worth it, when it will only require a few objects.

    David Perkins: Don't need the Entity MIB for v3 because you use a context in v3 and a community string in v1/v2.

    Consensus to do work on State/Status additions to the Entity MIB

    Andy: What MIB we do it in depends on whether we will need to cycle the Entity MIB at proposed.

    Randy Presuhn: Look at what we are trying to accomplish -- common way of managing state/status info across different types of widgets. Should we do this in a MIB, or in the enhanced data modeling features of SMIng?

    Pros and Cons to each choice: Adding the information model is aesthetically more appealing, having a MIB is more operational appealing.

    Sharon: Benefit of doing it in the Entity MIB is that you can look in one place for the op/admin status of everything. Don't need to know about all sorts of other tables.

    Andy: One table gives a good place to look for alarming and thresholding in DisMan MIB

    Consensus to do as separate Sparse Augments table.

    Consensus to add state/status variables to the current document.

    Sharon will write up a proposal for what we can add to the current Entity MIB.

    Andy: If we rathole on the stand-by thing, we should leave it out.

    Slides

    IPv6 MIB Status and Issues
    Entity MIB State Extensions