OPS Area
ENTMIB WG Meeting Minutes
43rd IETF
Orlando, FL USA
December 7, 1998
WG Chair: Keith McCloghrie <[email protected]>
Minutes: Andy Bierman <[email protected]>

Summary
-------

The Entity WG met to advance progress on the following work-in-progress:

[1] Entity MIB using SMIv2 (Version 2)  <draft-ietf-entmib-v2-01.txt>

Agenda
------

 Advancement of draft-ietf-entmib-v2-01.txt:
 - review comments from WG mailing list
 - any other comments from the WG?
 - is the MIB ready for WG Last Call?

Minutes
-------

1)  Review comments from WG mailing list
----------------------------------------

The issues raised in an email (dated 14-nov-98) from Cliff Sojourner
<[email protected]> were discussed at length.

E1: asset information is only needed for FRU components.
All the zero-length strings in the entPhysicalTable are
just polling overhead.

Proposal 1: put the asset information in a separate table.

There was no WG consensus for special restrictions on which
physical entity types may contain asset information. There was
also no agreement on the exact definition of the term,
"field-replaceable unit" (FRU). The definition of FRU can
change over time for a given product, and not all components
are field replaceable at the same level of expertise.

There was no WG consensus to move objects to a new 'SPARSE-AUGMENTS'
table.

Resolution: Proposal 1 rejected.

E1-Addendum: Need some generic way to identity FRUs

Proposal 2: Add an flag to identify Field Replaceable Units

Add a TruthValue r/o column to the entPhysicalTable called
'entPhysicalIsFRU'.  The new 'entPhysicalIsFRU' object is needed
because not all removable components are considered field
replaceable units by the vendor.

[Ed., A similar object was proposed by the WG Editor in a very
early version of the Entity MIB, but it was removed before
RFC 2037 was published. The entPhysicalIsRemovable object
could be derived from the parent entity (i.e., if the parent's
entPhysicalClass is 'container(5)', then the child entity is
removable.)]

The WG could not agree on the definition of a FRU, but did
agree it was useful to identify them in the entPhysicalTable.
There were no arguments against adding this object.

Resolution: Proposal 2 accepted

E2: entPhysicalModelName semantics are unclear.

There is a need to differentiate between "orderable part number"
and "manufacturing assembly number", and the object DESCRIPTION
clause is unclear on which string to use.

Proposal 3: Specify that the entPhysicalModelName string is the
customer-visible "orderable part number".

The WG did not agree on the need to for a new string object,
but did agree this string should represent the orderable part
number.

Resolution:  Proposal 3 accepted.

Proposal 4: Add a new NV-stored SnmpAdminString to contain the
manufacturing assembly number. This object is only instantiated
if entPhysicalIsFRU is true.

There was no WG consensus that this object was needed.
The NV-storage requirement is too high, and enough information
is available to uniquely identify a component (e.g.,
entPhysicalModelName and entPhysicalHardwareRev strings).

Resolution: Proposal 4 rejected.

Proposal 5: entPhysicalMfgName clarification

Revise the entPhysicalMfgName DESCRIPTION to be clear that the other
asset objects (sw/fw/hw revision, serial number, orderable part number,
mfg ass'y number) only make sense in the context of that manufacturer.
In other words, don't compare or collate these objects when they are
from different manufacturers.

There were no objections from the WG.

Resolution: Proposal 5 accepted

E3: entPhysicalTable has no way to represent double-high modules

The entPhysicalContainedIn object allows one parent container entity
to be identified, but some modules occupy more than one container.

Proposal 6: Model this information in the entPhysicalContainsTable.

Add text to the entPhysicalContainedIn object requiring
the lowest numbered (value of entPhysicalIndex) entPhysicalEntry
be used, in the event more than one parent entity exists.
The entPhysicalContainsTable DESCRIPTION clause will also be
clarified to encourage implementors to model all 'contained-in'
relationships, for child entities which have more than one parent
container entity.

There were no objections from the WG.

Resolution: Proposal 6 accepted

E4: implementation of user-writable objects is problematic

Proposal 7: entPhysicalAlias should be removed.  This object
correctly lies in the asset/spares/inventory management application.

There was no WG consensus to change or remove entPhysicalAlias.
This object is needed to support the PTOPO Chassis Identifier
attribute, and it is writable to allow an NMS to insure
all chassis identifiers are unique within an administrative
domain.

Resolution: Proposal 7 rejected

E5: specify the MIBs that are expected to populate logical entries

Proposal 8: list at least some standard MIBs that are expected to
use the Entity MIB.

There was no WG consensus that this change was needed, or that
the Entity MIB was the proper document to specify such behavior
(e.g., the Bridge MIB WG should specify in the Bridge MIB, how
the Entity MIB relates to multiple instances of the Bridge MIB).

Resolution: Proposal 8 rejected

E6:  make entPhysicalIndex MAX-ACCESS accessible-for-notify

Proposal 9: change the INDEX object from not-accessible to
accessible-for-notify, so it may be included as a varbind
in notifications.

There was no WG consensus that this change was needed or
even desirable. This change would set a precedent for all
INDEX clauses, without good cause. The entPhysicalClass object
is accessible, an instance of entPhysicalClass already
identifies the entPhysicalIndex value, and it contains the
same number of 'bits on the wire' as the proposed change.

Resolution: Proposal 9 rejected

E7: Need to define FRU

Proposal 10: Define "FRU" early in the draft and use the term,
then MIB object descriptions won't have circumlocutions like
"Physical entities which are permanently 'contained in' another
physical entity (e.g., the repeater ports within a repeater
module)".

The WG could not agree on the need to define a FRU, or the
definition of a FRU, but did recognize that this is a different
issue than simply identifying a FRU (see Proposal 2).

Resolution: Proposal 10 rejected

E8 and E9: Errata and Typos

- 4.10 says "Most of the MIB objects defined in this MIB have at most
  a read-only MAX-ACCESS clause, i.e., none are write-able."  Yet there
  are two read-write objects in this draft.

The old (obsolete) text will be removed.

- typos in section 6.1, remaining from RFC 2037:

These bugs will be fixed in the next draft.

E10:  SnmpAdminString size range semantics unclear

Are multi-byte UTF-8 characters counted as 1 'unit' in
INDEX sub-ranges, or does each byte count as 1 'unit'.

This issue has already been resolved in the SNMPv3 WG.
The sub-range limits refer to the number of octets used
to encode all the UTF-8 characters, not the number of
UTF-8 characters.

2) Any other WG comments on the I-D
-----------------------------------

The WG chair then opened the floor to discussion of any issues not
already covered in the previous section.

F1: Trap Throttling

The entPhysicalChange trap must be throttled by the agent to
insure that only one trap event is generated in a five second
interval. There were several WG members who had issues with
various portions of the text which defines this behavior.

The WG considered adding a MIB object to specify the
mandatory throttling interval (including none) the
agent must implement. This idea was eventually rejected
in favor of a simpler approach.

Proposal 11: Relax the restrictive text in the entConfigChange
NOTIFICATION-TYPE description from a "must throttle" to a
"should throttle", and make the five second throttling
period a suggested default, instead of a mandatory value.

The WG did not reach full resolution on this issue before the
meeting concluded, but there seemed to be strong WG consensus
that this was a good way to resolve the issue.

Resolution: Proposal 11 accepted

F2: EntConfigChange clarifying text

The entConfigChange DESCRIPTION clause text will be changed
to indicate the throttling requirement applies to the lower
level throttling entity, in a sub-agent environment, rather
than the upper level SNMPv3 Notification Originator application,
as defined in RFC 2271.

If sub-agents are used, the throttling period applies to
the entire set of Entity MIB sub-agents.

The term 'trap' will be replaced with the term 'notification'.
The term 'send' will be replaced with the term 'emit'.

3) Is the MIB ready for WG Last Call?
-------------------------------------

The WG Chair outlined a schedule for completion of the
current charter. There were no objections from the WG.

A 4 week WG Last Call will be issued when the next version of
the Entity MIB draft is published. A new draft is expected
before January 1999.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.