NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Nov-97
Chair(s):
Keith McCloghrie <kzm@cisco.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O'Dell <mo@uu.net>
Operations and Management Area Advisor:
John Curran <jcurran@bbn.com>
Mailing Lists:
General Discussion:entmib@cisco.com
To Subscribe: majordomo@cisco.com
In Body: subscribe entmib your_email_address
Archive: ftp://ftp.cisco.com/entmib/entmib
Description of Working Group:
The goal of this working group is to standardize a set of managed objects representing logical and physical entities and the relationships between them. Logical entities can occur when a single agent supports multiple instances of one MIB, such as RFCs 1253, 1493, 1516 or 1525, where each instance represents a single (logical) device/entity. Physical entities are the actual physical components on which the logical entities operate; typically, the physical components exist in a hierarchy. The set of objects will be consistent with the SNMP framework and existing SNMP standards.
The scope of this MIB should allow an NMS to interrogate a standard SNMP context and thereby discover what logical and physical entities exist, how to access the MIB information of each logical entity, and the relationships between the various entities. The MIB should support both a single agent or multiple agents in one physical entity. The Working Group should adopt a minimalist approach for the (initial) MIB so as to maximize the chance of success, e.g., read-only.
Goals and Milestones:
Done |
|
Hold BOF at Stockholm IETF. |
Done |
|
Post Internet-Draft for Entity MIB. |
Dec 95 |
|
Meet at Dallas IETF to review Internet-Draft and the issues raised during mailing list discussion. |
Jan 96 |
|
Post updated Entity MIB Internet-Draft. |
Mar 96 |
|
Meet at IETF to reach consensus on updated Internet-Draft. |
Apr 96 |
|
Submit final version of Internet-Draft for consideration as a Proposed Standard. |
Internet-Drafts:
· Entity MIB Extensions for Persistent Component Identification
Request For Comments:
RFC |
Status |
Title |
RFC2037 |
PS |
Entity MIB |
Minutes of the Entity MIB (entmib) WG
WG Chair: Keith McCloghrie
Reported by: 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
1) Introduction
2) Proposed New Charter
3) Discussion of Work Items
- draft-bierman-entmib-compid-01.txt
- updates for SNMPv3
- any other proposals
- RFC 2037 implementation feedback
4) 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.
None Received