Last Modifield: 06/06/2002
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.
| 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 |
| RFC | Status | Title |
|---|---|---|
| RFC2037 | PS | Entity MIB |
| RFC2737 | PS | Entity MIB (Version 2) |
Entity MIB WG (entmib) Minutes Tuesday, November 19, 0100-0200 =============================== CHAIR: Margaret Wasserman <mrw@windriver.com> AGENDA: Introduction and Agenda Bashing -- Margaret(5 min) State/Status Information for Entity MIB -- Sharon Chisholm (30 min) http://www.ietf.org/internet-drafts/draf t-chisholm-entmib-state-00.txt Wrap-up & Next Steps -- Margaret (10 min) INTRO & AGENDA BASHING ====================== 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. STATE/STATUS INFORMATION ======================== [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 control. 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 augments. 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 variables. 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. WRAP-UP/NEXT STEPS ================== 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. |