NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Margaret Wasserman <mrw@windriver.com>
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Bert Wijnen <bwijnen@lucent.com>
General Discussion:entmib@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/entmib
Archive: www.ietf.org/mail-archive/working-groups/entmib/current/maillist.htm
This working group is chartered 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 1493, 1525, or 1850 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 the defined managed objects 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.
Done |
|
Hold BOF at Stockholm IETF. |
Done |
|
Post Internet-Draft for Entity MIB. |
Done |
|
Meet at Dallas IETF to review Internet-Draft and the issues raised during mailing list discussion. |
Done |
|
Post updated Entity MIB Internet-Draft. |
Done |
|
Meet at IETF to reach consensus on updated Internet-Draft. |
Done |
|
Submit final version of Internet-Draft for consideration as a Proposed Standard. |
Done |
|
Finalize scope of changes/augmentations to RFC 2037 |
Done |
|
Post updated/new Internet Drafts |
Done |
|
Reach agreement on changes/extensions to RFC 2037 |
Done |
|
Evaluate status of RFC 2037 and report to the IESG if it should be recycled at Proposed or can be elevated to Draft Standard. |
Done |
|
Submit Internet Draft containing Entity MIB Extensions to IESG for consideration as a Proposed Standard. |
Apr 01 |
|
Evaluate status of RFC 2737 and collect implementation and interoperability reports |
Sep 01 |
|
Recommend to the IESG if RFC 2737 can be elevated to Draft Standard. |
Oct 01 |
|
Shut down working group |
RFC |
Status |
Title |
RFC2737 |
PS |
Entity MIB (Version 2) |
Entity MIB WG [entmib]
August 7, 2001
IETF #51, London
First Session
=============
1. Agenda Bashing
2. WG's Current Goal - to advance RFC2737 to Draft Standard
Sharon Chisholm - Implementation Report (see slides)
- Product description for a Nortel bridge 24 port stackable 10/100 ethernet switch
- Implementation checklist
Uses EMANATE toolkit
supports SNMPV3
- No management interoperability testing
- Examples of mib walks
- No support for entityLogicalMap
- No write access to entPhysicalSerialNum,alias, asset
- Did the notification
- Containment model includes stack(11)
Mike MacFaden - Implementation Report (see slides)
- Implemented entityPhysicalGroup, entityPhysicalGroup2
- No support for the Logical Group
- Used encoding scheme for entPhysicalIndex, performance at the cost of causing issues.
- Agent-Capabilities MIB module available for this implementation
- Entity MIB notification is too generic
Andy Bierman - Implementation Report (see slides)
- Multiple agent platforms implement all/most of 2737 some don't do Logical stuff (GSR 10000 ESR (All objects), IOS 12.1, uBR IOS 12.1(3), Cat6k w/Sup2 12.1.)
- Several MIB extensions have been deployed
- NMS interoperability with own apps (UGM managing 5x00)
- CisoView will use entity mib vs chassis mib
- CISCO-ENTITY-* mibs, include stuff like CLEI codes
- EntLogical group used for bridge/ospf.
- Biggest use is physical inventory!
- entPhysicalIndex used in other vendor MIB modules to provide references.
Dave Perkins - Implementaiton Report
- Physical Table, alias table
- Didn't use logical or mapping table at all
- PhysicalTC didn't exist, but wanted an "orZero" value
- Encoded information about cards into entPhysicalIndex
- Added extension mib module for LED states
- Added sensor MIB module
- Extention for status or state model (X.721)
Discussion of advancing RFC 2737 to Draft Standard. Technical issues raised on the list (or elsewhere):
Andy Bierman -
entLogicalTable Issues
1. SYNTAX for Tadder/Tdomain address types not using InetAddress? should be SnmpTagValue
granularity is per-logical entity
2. entLogicalTable provides contextEngineID and contextName to create scoped PDUs.
snmpCommunityTable also has these objects, granularity is per community string. Redundancy.
(1) Juergen S states Taddress/Tdomain is not same as InetAddr. If Taddress doesn't support IPv6, that is an issue for the whole ops area, no specific to this MIB module - resolved.
(2) Community information is already deprecated -- resolved.
Briefly discussed issues raised in review of the Fibre Channel MIB. Noone from the FC MIB WG was in attendance, and we didn't have a strong understanding of the outstanding issues, if any.
No additional issues were raised.
What type of implementation reports/documentation do we need?
After some discussion, it was determined that we need implementation reports and MIB walks that show all of the objects reported as the correct types.
Currently, we only have one report that implements the Logical group (Andy from Cisco). Two other people (Dan Romanescu and ??) said that they have implementations that include the Logical group and will fill out a report.
All implementors are requested to send MIB walks.
General agreement in the room to advance RFC 2737 to Draft Standard (with no modifications) once implementation reports are completed. Any extensions would be done in separate document(s).
A WG last call will be issued on the mailing list once implementation reports are completed.
Second Session
==============
Discussed several proposals for Entity MIB extensions or further work for the entmib Working Group. Three topics were specifically discussed:
1. Sensor Entity MIB
2. entPhysicalIndexOrZero TC
3. Non-snmp logical entries
(1) Keith McCloghrie had proposed that the Entity MIB WG consider standardizing a Sensor MIB similar to Cisco's Sensor Entity MIB. Andy Bierman discussed the existing Cisco Sensor Entity MIB.
There was insufficient interest in the room to warrant work on a Sensor Entity MIB. Several people thought that a Sensor Entity MIB would be desireable, but only 2 or 3 people were interesting in doing this work within the Entity MIB WG.
(2) Dave Perkins proposed an entPhysicalIndexOrZero TC to be used in cases where it is desireable to have a value to indicate a "null pointer" -- no corresponding entPhysicalIndex.
There was a general agreement in the room that this would be useful, but the benefit did not justify recycling RFC 2737. Also, it is not significant enough to warrant a separate document. Several people indicated that they are using this in practice without a TC.
(3) Dan Romanescu had proposed, after the previous meeting, that we consider support for Non-SNMP logical entries in the Entity MIB. Dan could not attend the second session, so the chair presented his proposal. The current Entity MIB assumes that all logical entries will be SNMP agents, but it might be desireable to add a type and other addressing information to allow redirection to Non-SNMP entities.
There was insufficient interest in the room to pursue work in this area.
People who are interested in pursuing any of these proposals or other new work in the Entity MIB WG should take their ideas to the list. If sufficient interest is demonstrated on the list, we will consider taking on new work. Otherwise, we will concentrate on moving RFC 2737 to Draft Standard and plan to go into hiatus after advancing the document.
Entity MIB Implementation Report
Entity MIB Riverstone Implementation on RS Platform