Subject: RE: [Entmib] London Minutes

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 11 Sep 2001 10:01:47 -0400

hi Margaret,

I don't see any mention of our second day 
discussion on a state/status extension to the
Entity MIB. I believe my notes captured both
discussion and action items from this discussion.

Sharon

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: Monday, September 10, 2001 9:43 PM
To: [email-masked]
Subject: [Entmib] London Minutes

Here are the minutes for our London meetings.  Thanks
to Mike MacFaden and Sharon Chisholm for taking notes.

Margaret

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.

_______________________________________________
Entmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/entmib

_______________________________________________
Entmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/entmib

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 11 Sep 2001 22:45:54 +0200

Inline
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: dinsdag 11 september 2001 20:19
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Entmib] London Minutes
> 
> 
> > Entity MIB WG [entmib]
> > August 7, 2001
> > IETF #51, London
> > 
> > ...
> > 
> > ...
> > 	2. ...
> > 	3. ...
> My apologies for not being present in London.  The above is the first
> I've heard of what happened.  I assume that Maragret presented the
> slides I provided.  Below is some text which covers the same ground as
> the slides, and hopefully clarifies why the topic was raised.
> 
> If the Entity MIB WG is not interested in doing this work, then
> perhaps the Area Director could provide his advice on where to do it.
> 
Keith, I am sure that you realize that if there is no WG interest, that
there is no way we can just assign such a topic to the WG.
So... possibly based on your info below, some people may come forward
to say yes yes... we are volunteering. Maybe the IPFC people come
out (or nmaybe you can convince them) to help with this work in the
entmib WG.

An alternative path is that you do an individual submission via
RFC-Editor and we can do a 4-week IETF Last Call for PS.
Maybe Margareth would not mind if you post a draft and try to get
some feedback via the WGs mailing list before you actually ask
for it to be considered PS.

Does this help?
> Thanks,
> Keith.
> ------------
> 
> RFC 2837 was the first Fibre Channel MIB, but it was designed 
> for Fibre
> Channel switches only (not for hosts/disk subsystems with 
> Fibre Channel
> interfaces).  More recently, the Fibre Alliance (a vendor 
> organization)
> developed a MIB intended for all Fibre Channel products.  This MIB has
> apparently been implemented by multiple vendors (more than 20 ??).
> It was brought to the IETF's IPFC Working Group, who are now trying to
> standardize it.  The latest version is 
> draft-ipfc-fcmgmt-int-mib-06.txt.
> The designers of this MIB decided they wanted a single MIB containing
> every object relevant to a Fibre Channel product.  Obviously, this was
> the wrong approach, which has been pointed out to the 
> author/editor and
> the WG chair, with the suggestion that the MIB needs to undergo
> significant changes, including the removal of all objects not specific
> to Fibre Channel.
> 
> The MIB is organized by what it calls "connectivity units";
> specifically, most tables in the MIB are indexed by a 
> connectivity-unit
> index value.  (The object containing the type of connectivity unit has
> defined values:  hub, switch, gateway, converter, module, host, hba,
> swDriver, storageDevice, storageSubsys, storageAccessDevice, 
> proxyAgent.)
> 
> The content not specific to Fibre Channel includes:
> 
> - product name & info, serial#, mgmt-URL, contact, location, upTime,
> - state: online/offline, ok/warning/failed,
> - read-write control object: reset/online/offline,
> - module-ID (to group conn-units in a hierarchy),
> - a Revision Table (lists the revisions of hardware/firmware/etc.
>   components supported by a connectivity unit),
> - a Sensor Table.
> 
> where INDEX for each of the above includes "connectivity unit".
> 
> Since this information is not specific to Fibre Channel, it seems
> logical for the IPFC Working Group to ask a different Working Group,
> one with a more generic focus, to look at developing a MIB to cover
> an appropriate subset of this info.  The fact the "connectivity units"
> are arranged in a hierarchy, and that some types of "connectivity
> units" are equivalent to physical components in the Entity MIB,
> suggests that some of the above is an extension of the Entity MIB.
> 
> Thus, the Entity MIB Working Group is being asked to consider these
> extensions as a potential work item.
> 
>