Subject: [Entmib] Questions regarding draft-ietf-ipfc-fcmgmt-int-mib-06.txt

From: Margaret Wasserman <[email-masked]>
Date: Thu, 28 Jun 2001 09:28:01 -0400

Hi All,

As a WG, we need to respond to some questions that arose during a
review of the Fibre Channel MIB:

draft-ietf-ipfc-fcmgmt-int-mib-06.txt 

This MIB implements some objects that may overlap functions of
the Entity MIB.  It also contains some objects that might be better
represented in a generic form in a separate MIB (i.e. a Sensor MIB).  
So, there are basically two questions that we need to consider.

Keith McCloghrie wrote:
 > > To take one example, they have a Sensor Table in their MIB, which is 
 > > obviously not FC-specific. What would you say to extending the 
 > > Entity MIB WG charter to include the definition of data on Sensors ?

Bert asked that I bring this to the Entity MIB mailing list...

Do we think that this would be a good idea?  Are we willing
to take on this work?  Or do we think it would best be handled by
a separate working group?

According to Keith, Cisco has a sensor MIB that we might be able to use 
as a model:

 > > ftp://ftpeng.cisco.com/ftp/pub/mibs/v2/CISCO-ENTITY-SENSOR-MIB.my 

We don't have Cisco's permission to use this material, but perhaps we 
could obtain their permission?

Also, there is an open issue of whether some of the objects in the FC
MIB could be covered by the Entity MIB -- particularly those objects
that represent multiple Fibre Channel cards in a device.

Keith McCloghrie writes:
 > > > > But there's nothing unique to Fibre Channel in your statement, and 
 > > > > therefore you must NOT try to solve it in a Fibre Channel-specific MIB. 
 > > > > There are lots of SNMP-managed devices that have multiple blades or 
 > > > > are a series of boxes. See for example, the "usage examples" in 
 > > > > section 4 of the Entity MIB (RFC 2737). 
[...]
 > > > > > > c. these objects are either already in the ENTITY MIB (RFC 2737) or 
 > > > > > > belong in an extension to the ENTITY MIB: 
 > > > > > > fcConnUnitNumber 
 > > > > > > fcConnUnitNumPorts 
 > > > > > > fcConnUnitNumLinks 
 > > > > > > fcConnUnitNumRevs 
 > > > > > > fcConnUnitModuleId 
 > > > > > > fcConnUnitRevsTable 
 > > > > > > fcConnUnitRevsIndex 
 > > > > > > fcConnUnitRevsRevision 
 > > > > > > fcConnUnitRevsDescription 
 > > > > > > fcConnUnitPortSerialNo 
 > > > > > > fcConnUnitPortRevision 
 > > > > > > fcConnUnitPortVendor 

However, Steven Blumenau responded:
 > > > > > SMB> I did not believe they are covered. 

Any opinions on whether we cover the functionality described for the FC MIB?

Does RFC 2737 require any extensions to appropriately manage multiple FC cards
in a device?  If so, this is clearly something that we should discuss before 
moving to draft standard.

Steven, would you please provide details?  What is missing from the Entity
MIB that you need to manage FC cards in a chassis?

Thanks,
Margaret

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

---

From: David Harrington <[email-masked]>
Date: Thu, 28 Jun 2001 12:03:22 -0400

Hi,

If we substantially modify the Entity MIB, it will need to recycle at Proposed, I
believe.
I suggest that if the Entity MIB WG takes this on, it be done in a separate mib that
extends the Entity MIB.
If the FC folk are not convinced it belongs in the Entity MIB, then we should
definitely make it separate to avoid having the Entity MIB held up as that issue
gets resolved.

dbh

--
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 28 Jun 2001 10:09:07 -0700 (PDT)

Hi Dave,

Both your points lead to the conclusion of defining a new MIB as an
extension of the ENTITY-MIB module, which I believe would be fine.
 
Keith.