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.