Re: FC Management MIB - proposed changes

[Keith McCloghrie <kzm@cisco.com>]

Marjorie,
 
> A little background on the intent of these two MIBs - the FC Mgmt MIB was
> originally intended to represent "everything that had Fibre Channel Ports".
> In that sense, it is analogous to the Interfaces Group MIB.

Your analogy doesn't (to me) seem very accurate.  (Only RFC 2863, not
the FC Mgmt MIB, has many other MIBs which extend its functionality
with more specific information.)

> RFC 2837 was
> intended to represent FC Fabric Switch information - more like a "router
> MIB" - intended to represent the information specific to the functions of a
> Fibre Channel fabric switch.

Well, the IETF has not specified a "router MIB".  It's better to
specify MIBs in smaller functional increments (e.g., OSPF MIB, BGP MIB,
etc.), rather than as "type of box" MIBs.  This allows functions which
are common to multiple types of boxes to be specified in one MIB and
implemented by all the types, e.g., the ATM interface MIB applies to
ATM hosts and ATM switches.  Moral: the definition of "type of box"
MIBs can be a contributory factor to the kinds of problems that we
have now.

> That doesn't seem to me to be information that
> should be in an "interfaces MIB".  It doesn't seem logical to replace RFC
> 2837 with a new FC Mgmt MIB, the intent of both MIBs is/should be much
> different.

All MIB information which is relevant to an FC interface should have
been specified as an extension of the ifTable.  This applies to both
the FC Mgmt MIB and to RFC 2837.  That information should be specified
only once. 

I was focussing on the significant overlap between them.  Above you
seem to be saying there are significant differences between them.
Perhaps, both the overlap *and* the differences are significant.
Let me work on it and see what emerges.

> The name server stuff never belonged in the FC Mgmt MIB, it (and
> other Fabric Services information) belongs in the RFC 2837 MIB.

You're right that the connUnitSnsTable describes itself as: "This table
contains an entry for each object registered with this port [sic] in
the switch."  However, see comments above on "type of box" MIBs;
it would be better for it to be in a Name Server MIB.

Keith.

 
> Thoughts?
> Marjorie
> 
> 
> > 3. With 20x20 hindsight, the following observations can be made with
> > respect to RFC 2837:
> > 
> > - the reason that we now have the issue of how it relates to the
> >   FC-Mgmt MIB is because it was written as a Fabric Element MIB;
> >   this issue would not have arisen if it had been written as a
> >   Fibre Channel interface MIB.
> > - it should have extended the ifTable, rather than 
> > overlapping with it,
> > - it should not have defined the fcFeModuleTable, which overlaps with
> >   the Entity MIB.
> > - and it should have specified (at least) its octet counters 
> > as Counter64.
> > 
> > Given these problems, I propose that the new FC-Mgmt MIB be specified
> > as a replacement for RFC 2837.
> > 
> 
>  
>