Subject: [Entmib] Minutes from 52nd IETF

From: "Shawn A. Routhier" <[email-masked]>
Date: Thu, 13 Dec 2001 11:06:20 -0500

Here are the minutes from the meeting at the 52nd IETF
in Salt Lake City.  If anybody has any clarifications
or corrections of the minutes please send mail to me
by next wednesday morning (12/19).

regards,
sar

+++++++++++++++++++++++++++++++++++++++++++++++++++++

			Entity MIB
			December 12 2001
			Chair: Margaret Wasserman ([email-masked])
			Notes: Shawn A. Routhier ([email-masked])
			Mailing List: [email-masked]

The meeting was attended by approximately 20-30 people and started
with the standard agenda bashing.  The primary items on the agenda
were issues involved with advancing RFC2737 and accepting the Entity
Sensor MIB as a working group work item.

**********************************************************

        RFC2737

The working group is attempting to advance RFC2737 from "proposed" to
"draft" standard.  In order to do so the process requires that there
be two inter-operable implementations of the specification.  For a 
specification that defines a MIB, such as RFC2737, an inter-operable
implementation can be demonstrated by walking each of the MIB tables
with a SNMP manager tool.  Implementations and MIB walks have been found
for most groups of the MIB.  The exception is the entityLogical group.
In previous meetings several people had volunteered to supply MIB walks
for this group, however for various reasons they have been unable to do so.
In one case the company has not shipped the product and until they do so
they won't allow the MIB walk to be released.  They also won't comment on
when the product will be released.  In another case several products have
been examined but support has only been found for the default entry.  

Given this lack of implementation experience there are several possible
options:

    Wait for further implementations

    Drop the unimplemented portions from the document and then
    advance the document

    Split the document into two pieces with the unimplemented groups
    in one document and advance the two documents separately as reports
    are received.

The specification process has a guideline that standards should be
advanced between 6 months and 2 years after being "proposed".  This
is not a hard rule and is intended to insure that standards make
forward progress.  This would allow the WG to wait, however the WG
has already missed the milestones in the current charter.  If the WG
chose to wait the charter will need to be updated and the milestones
set appropriately.

If the WG chooses to split the document both pieces can go forward
on their own merits.  As the split documents would need to go through
some of the standards process that has the current document has already
done there would be some delay with this option.  It was also pointed
out that, while the standards process does allow parts of a document
to be dropped while advancing, the SMI doesn't.

The attendees have decided overwhelmingly to leave the draft as it is
now and wait to see if new implementations are created or found.  The
AD has agreed that waiting for an implementation is acceptable in this
case.

If you have an implementation of the Entity MIB, especially of the
entityLogical group, please supply a MIB walk to either the mailing
list or the chair.

**********************************************************

        Entity Sensor MIB

Andy Bierman ([email-masked]) presented a description of the
Entity Sensor MIB.  A copy of the document may be found at
ftp://ftpeng.cisco.com/ftp/entmib/draft-ietf-entmib-sensor-mib-pre-00.txt
until it is available from the internet-drafts repository.
Andy's slides should be available from the IETF eventually.

Andy and his co-authors are trying to provide a data model for sensors
so that managers may understand the sensors without previous knowledge
of the sensor.  This work is an attempt by the AD to get a generic
solution such that other groups, such as the Fiber Channel folks, will
not need to write their own specific MIB.  It originated as a response
to a request from the Fiber Channel folks to charter a similar MIB.
As such they will need to be consulted to ensure that this MIB is sufficient
for their needs.

The MIB is one smallish table that describes the various types of
sensors that are available and how they can be used.  The current
document leaves the table as read only in order to make it simple.
The core definitions of the document are the four TCs in it and the
authors believe with these TCs they have covered most of the needs of
most sensors.  However the document has not received extensive review,
and the authors encourage WG participants to read and review it.  One
issue that Andy brought up was if the list of data types for
"EntitySensorDataType" is complete.

There were several questions/issues from the floor with some discussion
on each.

The first was if the MIB supplied an indication that a given value indicates
a problem, such as an idiot light in a car.  This MIB does include a
truth value option allowing the agent to indicate a good or bad value.
The MIB does not have direct support for thresholding, where a manager
could indicate to the agent when to trigger an alarm.  There was some
agreement that threshold type processing should be handled in some other
MIB such as the Alarm MIB (see DISMAN WG) or RMON (for more basic thresholds).
One person from the Fiber Channel area stated that they had planned on
having the agent know more about its own state rather than offloading the
thresholding to some other entity via the Alarm or RMON MIB.  They will
need to examine this to see if it is sufficient for their requirements.

The second was an issue with the EntitySensorValue TC.  This TC has what
appears as an odd range restriction.  Instead of using one of the typical
powers of two ranges it uses a powers of ten range (-1,000,000,000 to
1,000,000,000).  This was thought to be due to the use of powers of ten
rather than powers of two in the scaling factor.  It was also pointed
out that is should be a union type of variable but that as the SMI doesn't
allow it, we have lots of words to try and describe it.

The third question asked if we should include other physical items such
as GPS co-ordinates.  This item was not discussed further.

The group then discussed what should be done with this MIB.  In general
it seemed that the MIB would be useful. Several of the attendees build
devices that have sensors of some sort and at least one of them thought
the MIB would be useful.  There was also some support for it from a user
perspective.  The group was asked several questions to try and gauge
support for working on and using this MIB.

The group felt that the MIB was heading in the proper direction.
As well there were several individuals that are interested in writing
and reviewing it.  Finally there were even some whose company's may
implement it.  There was good support for pursuing this work and accepting
the draft as a WG document.  As always this item will be taken to the WG
list to confirm the consensus of the meeting.  The authors acquired the
action item of re-spinning the draft (if necessary) and posting it as
a WG item.

**********************************************************

        Charter Update

As a result of the above two decisions (assuming the mailing list agrees)
the charter will need to be updated.  The dates for RFC2737 will be
postponed until the group thinks the sensor MIB will be ready at which
point the group will try to advance both.  Hopefully sufficient
implementations of RFC2737 will be available.  As the Sensor Entity MIB
is a fairly simple MIB the group believes that it should be able to deal
with it quickly (before the next IETF meeting.  However in order to be
conservative and due to the, sometimes, lack of response on the mailing
list the target will be to complete it and discuss it at the next meeting.

**********************************************************

        Other Issues

As the Fiber Channel group is interested in the outcome of the Entity
Sensor MIB one attendee asked about reposting messages between the
two lists.  This is acceptable but anybody with an interest in the
Entity Sensor MIB is strongly encouraged to join the Entity MIB mailing
list and discuss it there.

Previously several minor changes to the Entity MIB were deferred as they
might cause it to be unable to advance.  As the WG is now awaiting more
implementation experience, some small changes may be allowed into the MIB.
Two that have been discussed previously are: adding a CPU type to the
physical list and adding entPhyscialIndexOrZero.  The advocates of these
items have been asked to determine if they believe they are worthwhile
items and if so to send mail to the list.

Finally one of the attendees from the Fiber Channel group was going to
report back to them and determine if the proposed path was acceptable.

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