Minutes - IETF #40  Washington, D.C.
------------------------------------

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.