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

[David Harrington <[e-mail]>]

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

Margaret Wasserman wrote:

> 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
> [e-mail]
> http://www.ietf.org/mailman/listinfo/entmib

--
---
David Harrington            Network Management Standards Architect
[e-mail]           Office of the CTO
[phone] - voice     Enterasys Networks
[phone] - fax       Rochester NH, USA



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