WG: ENTMIB
Area: OPS
Meeting: 11dec97 0900-1130
WG Chair: Keith McCloghrie
Minutes: Andy Bierman
Summary
-------
The Entity MIB WG reconvened at this meeting. The new charter will be
essentially unchanged from the original charter. The WG intends to advance
the status of RFC 2037 and add additional features, such as SNMPv3 context
support and non-volatile name strings for physical components.
Agenda
------
- Introduction
- Proposed New Charter
- Discussion of Work Items
- draft-bierman-entmib-compid-01.txt
- updates for SNMPv3
- any other proposals
- RFC 2037 implementation feedback
- Proposed Steps Forward
Detailed Account of Agenda Items
--------------------------------
1) WG History
A 'History of the WG' was presented by the WG Chair, which included
accounts of the Chassis MIB WG effort, and the publication history of
the Entity MIB (RFC 2037).
2) Status of RFC 2037
The WG must decide what 'status-action' should be pursued for the
Entity MIB, which is currently at Proposed Draft Standard status.
The choices are:
a) Advance (all or part) to Draft Standard status
b) Cycle (all or part) at Proposed Draft Standard status
c) Remove the standard (all or part) by assigning Historic status
The WG agreed that choice (a) will be pursued for all existing MIB objects.
New objects will be added independently, and follow a different standards
track.
3) New Charter
The existing charter was presented by the WG Chair. It was proposed that
only editorial changes be made to the charter. The WG agreed to this
decision, except that new features are not restricted to read-only access.
3.1) Time-Table for New Charter
A list of milestones was proposed by the WG Chair and accepted by the WG:
- Reactivate at Washington, D.C. (done! :-)
- WG Mailing List discussion on new features and any other issues
- Finalize the scope of the changes at the Spring IETF (#41)
- Post initial I-Ds after Spring IETF
- WG Agreement on specific changes at Summer IETF (#42)
- Post updated I-Ds after Summer IETF
- WG Last Call on I-Ds immediately after I-Ds are posted
- WG Approval Sept. 98 (done)
4) Physical Topology MIB Support
The WG Editor presented a summary of the internet draft:
draft-bierman-entmib-compid-01.txt.
This I-D proposes an augmentation to the entPhysicalTable, which
contains a read-write string (entPhysicalAlias), used much the same way as
the ifAlias object in the Interfaces MIB (RFC 2233).
The WG agreed to add this object to the updated Entity MIB, after some
editorial changes are discussed on the mailing list. There is some
ambiguity regarding the semantics of a particular entPhysicalAlias value
after a physical component is moved from one location to another one
within the same chassis. (I.e., does the moved card name have to
stay the same, change to a new value, or either one?)
The WG will discuss changes to this I-D on the mailing list.
The PTOPO MIB would like the Entity MIB WG to produce an update to RFC 2037,
which contains the entPhysicalAlias object, since the PTOPO MIB documents
cannot progress until the non-volatile 'chassis ID' name string is added
to the Entity MIB. (The PTOPOMIB WG may consider adding the 'Chassis ID'
support to the PTOPO MIB, to remove this dependency.)
The Entity MIB WG discussed the possibility of producing the quick update
requested by the PTOPOMIB WG. This idea was tabled for now, and the WG will
follow the proposed timeline (in section 3.1).
5) SNMPv3 changes
The WG discussed the scope of changes needed for SNMPv3 support.
a) naming scope -- An SNMPv3 contextName must be added to each
entLogicalEntry.
b) discovery issues -- the agent can set auth/nopriv view to allow this or
not. The out-of-box configuration should be noauth/nopriv to allow
discovery of new devices.
c) character set -- new objects will use the UTF-8 character set, instead of
the NVT character set. The description string objects in the Entity MIB
will be deprecated, and replaced with new objects of syntax
'SnmpAdminString'.
6) EntPhysicalParentRelPos Bug
An issue was raised on the mailing list regarding the entPhysicalParentRelPos
object. The WG Editor clarified the correct behavior for this object for
containers and modules. The containers modeled by the agent should have a
parent-relative position as identified by the writing on the equipment itself
(e.g. container for slot #3 has a entPhysicalParentRelPos value of 3).
The module(s) plugged into a particular container have a parent-relative
position with respect to that container (e.g., the card in container #3 has an
entPhysicalParentRelPos value of 1). The Entity MIB contains incorrect
examples which show this value to be the same as that of the container entry
(e.g. '3' instead of '1'). These examples will be corrected in the updated
Entity MIB.
7) RFC Advancement Criteria
The WG Chair must seek implementation feedback on RFC 2037, according to the
guidelines in RFC 2026. At least two independent and interoperable
implementations from different code bases demonstrating "sufficient
successful operational experience" must be identified, fostering a
strong belief that the technology is mature and will be useful.
8) Entity MIB Implementation Experience
The WG chair must document the implementation experience. The WG members
present at this meeting were asked the following questions, directed
at any implementation efforts.
- who implemented?
- how much implemented?
- trouble with any objects?
- found some objects were missing?
- found some objects not to be useful?
Four vendors present had implemented some or all of the Entity MIB.
A full implementation report will be presented later, after WG
members on the mailing list have been queried for implementation
experience.
In general, all four vendors were able to implement the MIB without
difficulty. The entPhysical group was the most widely implemented
group. The entLogical group is not really needed if all MIB
objects are within a single naming scope, and this was reflected
in implementation experience. One vendor utilized multiple entLogicalTable
entries to support multiple instances of the Bridge MIB.
The various mapping tables were utilized differently, depending
on the system. A repeater implementation may utilize the
entAliasMappingTable for "repeater port to ifIndex" mappings, and
an implementation for a very large system (i.e. large number of
entPhysicalTable entries) may rely on the entPhysicalContainsTable
to reduce data retrieval time.
There were some suggestions for new objects:
- entPhysicalEntry
SW revision string
HW revision string
an assignable name (e.g. entPhysicalAlias)
- entLogicalTable
mapping to AgentX platforms
9) Interoperability Testing
The WG discussed ideas for an interoperability bake-off in the near
future. The most attractive plan requires several vendors to make
agent implementations available for query over the Internet. The
mailing list will be used to coordinate this effort. It is possible
that a real test event will be planned some time in the future.
