Re: FC Management MIB - issues

[Keith McCloghrie <kzm@cisco.com>]

Bill,

You raise a good point.  One of the reasons to move the FCMGMT MIB to
this WG was to ensure coordination with this WG's MIBs.  You're right
that the FCIP MIB is dependent on the FCMGMT MIB, since every table in
the FCIP MIB is INDEXed by fcConnUnitId, which it IMPORTS from the
FCMGMT MIB.

As and when a new structure is adopted for the FCMGMT MIB, the FCIP MIB
will be affected, and will need to be updated accordingly.  However, I
too don't think there's time to achieve the required coordination
before the Internet-Draft deadline.

Keith.

> An interesting issue Keith...
> Currently there are a couple of tables in the FCIP MIB that AUGMENT tables
> in this MIB, and the FCIP MIB also imports a few of the indexes from the
> FCMGMT MIB.
> 
> Will you be able to co-ordinate changes with the FCIP MIB editors (I am
> assuming they will not be able to adjust their MIB by next week) however can
> updated versions of these MIBs come out in the future ?
> 
> Bill
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Keith McCloghrie
> Sent: Wednesday, November 07, 2001 1:03 PM
> To: ips@ece.cmu.edu
> Cc: Keith McCloghrie
> Subject: FC Management MIB - issues
> 
> 
> Hi,
> 
> As indicated by Elizabeth's message (below), I've agreed to be the
> interim editor for the FC Management MIB.  So, first, I'd like to
> list a set of issues that have been raised concerning the most
> recent draft: draft-ietf-ipfc-fcmgmt-int-mib-07.txt.  They are:
> 
>   1. The use of SMIv2 is mandatory.
> 
>   2. This MIB seems to have been defined with the notion that it will be
>   the only MIB that a Fibre Channel product will require.  The notion of
>   an agent implementing just a single MIB was abandoned by the IETF in
>   1992 as being non-scaleable.  Rather, this is another MIB in the
>   continuing series of MIBs defined by the IETF, and thus, it needs to be
>   consistent with its predecessors.  In other words, there are existing
>   MIBs which all SNMP agents must support, even if the support of Fibre
>   Channel interfaces is the only functionality that they have.  Thus, as
>   the Fibre Channel Integration MIB, it is essential that this MIB
>   contain only objects for information which is specific to Fibre
>   Channel.  All objects which apply in non-Fibre Channel environments
>   need to be removed.  (This applies even it were to require the
>   definition of other new MIBs to contain information which is not
>   already defined in other existing MIBs, but needed by Fibre Channel
>   products.)  Note that this issue applies to a large fraction of the
>   objects defined in this MIB.
> 
>   3. The text needs to include an explanation of the relationship between
>   this MIB and RFC 2837.  Is it a replacement or is it complementary ?
>   If complementary, which agents implement which MIB; do some agents
>   implement both ?
> 
>   4. Every SNMP agent implements the ifTable.  The ifTable counters are
>   undoubtedly the MIB objects most well-used by administrators in SNMP
>   management.  SNMP agents need to implement a row in the ifTable for
>   each of their network interfaces, including their Fibre Channel
>   interfaces.  The IF-MIB requires a media-specific MIB to specify how
>   that type of interface uses the ifTable (see section 4 in RFC 2863).
>   RFC 2837 doesn't do that, and nor (currently) does this MIB.  That
>   needs to be fixed.  This will likely result in many tables in this
>   MIB being indexed by ifIndex.
> 
>   5. There are a number of objects related to the "Simple Name Service",
>   and the definitions refer to Fibre Channel's GS-3 spec.  However, GS-3
>   defines two Name Services: a Zoned Name Service and a Unzoned Name
>   Service, but GS-3 does NOT use the term "Simple" for either of them !!
>   This ambiguity needs to be resolved.
> 
>   6. It is essential that the Counter32 or Counter64 (not OCTET STRINGs)
>   syntax be used for counters.
> 
> Thanks,
> Keith.
> --------------
> Forwarded message:
> > From: "Elizabeth Rodriguez" <egrodriguez@lucent.com>
> > To: <ipfc@standards.gadzoox.com>,
> >         "IPS Mailing List (E-mail)" <ips@ece.cmu.edu>
> > Subject: FC Management MIB -- Transfer from IPFC To IPS WG
> > Cc: <muralir@lightsand.com>, <sob@harvard.edu>, <Black_David@emc.com>,
> >         <narten@us.ibm.com>, <kzm@cisco.com>, <bwijnen@lucent.com>,
> >         <Erik.Nordmark@eng.sun.com>,
> >         "Elizabeth Rodriguez"
> <Elizabeth.Rodriguez@nc8220exch1.ral.lucent.com>,
> >         <mankin@isi.edu>
> >
> > All,
> >
> > The IPFC working group has only one item left on its charter.
> > It is that of the FC Management MIB.  It has been identified
> > that this MIB does not follow the IETF guidelines for MIBs
> > in its current format, in its lack of focus, and in its overlap
> > with existing MIBs.  Rework of this MIB will take some time.
> > The content of this MIB will fit in well with the IPS WG,
> > especially because the subject matter experts participate in
> > this WG.
> >
> > For these reasons, the working group chairs, with the INT and TSV area
> > directors, have determined that this effort should be moved from the
> > IPFC working group to the IPS working group.  Upon transferring of this
> > work, the IPFC working group will have completed the items in its
> > charter and the IPFC WG will be closed.
> >
> > The IPS working group has a technical advisor for MIB work -- Keith
> > McCloghrie.  Since it has been determined that the current MIB has
> > issues with format, Keith McCloghrie has agreed to become the interim
> > editor of this MIB.  As part of the re-architecture, the MIB will be
> > evaluated with respect to fit with other IPS WG MIBs, and may take the
> > form of a single new MIB or multiple MIBs, as appropriate.  The IPS
> > working group will also be seeking Fibre Channel expertise to help
> > formulate the new MIB, including an editor with FC and MIB experience.
> >
> > The IPFC working group would also like to thank Steven Blumenau for all
> > his work on the original MIB.
> >
> > Elizabeth Rodriguez & David Black, IPS Working Group Chairs
> > Murali Rajagopal, IPFC Working Group Chair
> >
> 
>