Fwd: Entity MIB Minutes

Hi All,

Here are the draft minutes from our meeting.  Please let me
know if there are any question or comments.

Margaret


Entity MIB WG (entmib) Minutes
Tuesday, November 19, 0100-0200
===============================
CHAIR: Margaret Wasserman <[email protected]>

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.