Subject: [Entmib] Fwd: Draft Minutes

From: Margaret Wasserman <[email-masked]>
Date: Tue, 16 Jul 2002 09:30:09 -0400

Hi All,

Here are the draft minutes from the Entity MIB meeting this afternoon.
Please let me know if you have any comments.

We seemed to have consensus on the following points in the meeting:

	- The changes to the Entity MIB document properly reflect
		the feedback from last meeting
	- We want to do work on state/status additions to the Entity
		MIB
	- The changes should be contained in a separate table that
		is a sparse augments of the current Entity MIB table(s)
	- The changes should be included in the same document with the
		Entity MIB -- the Entity MIB will not be re-published
		as a PS until these changes are completed.

Folks on the list, please let us know if you disagree with these
decisions.

Thanks,
Margaret

Entity MIB Minutes -- DRAFT
IETF54 Yokohama, Japan
Tuesday, July 15, 2002

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.

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib