Entity MIB WG (entmib) Minutes IETF 54 Yokohama, Japan Tuesday, July 16, 2002 @ 0215-0315 ================================== CHAIR: Margaret Wasserman AGENDA: Introduction and Agenda Bashing (5 min) Entity MIB Updates and Open Issues -- Andy Bierman (10 min) Sensor Entity MIB Status and Open Issues -- Andy Bierman (5 min) State/Status Information for Entity MIB -- Sharon Chisholm (15 min) 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 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.