Entity MIB WG (entmib) Minutes Tuesday, November 19, 0100-0200 =============================== CHAIR: Margaret Wasserman AGENDA: Introduction and Agenda Bashing -- Margaret(5 min) State/Status Information for Entity MIB -- Sharon Chisholm (30 min) http://www.ietf.org/internet-drafts/draft-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.