FC Management MIB - proposed changes

[Keith McCloghrie <kzm@cisco.com>]

Based on the issues that I listed in my previous message (yesterday), I
have a set of changes that I'd like to make to the FC-Mgmt MIB,
providing there are no objections from the WG.  These changes (the
first six correspond to the issues list) are:

1. MIB will be written using SMIv2.

2. All objects which apply in non-Fibre Channel environments will be
removed.  (Note that this applies to a large fraction of the objects
defined in this MIB.)

2a. For those objects which will be removed, if there are any which
are: a) not already covered in other MIBs, and b) considered essential
to the management of Fibre Channel-based products, then it will be
necessary to consider whether other MIB(s) need to be modified/created
as a home for them, and if so which WG(s) should undertake such work.

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.

4. This MIB will include a media-specific MIB to specify how Fibre
Channel interfaces use the ifTable (see section 4 in RFC 2863).  This
will result in many tables in this MIB being indexed by ifIndex.

5. Regarding the the MIB objects for the "Simple Name Service",
I see two possible solutions:

i. retain the MIB objects but focus them on GS-3's Unzoned Name Service.

ii. remove the MIB objects for the "Simple Name Service" from this MIB.
   If there is WG consensus that a MIB is needed for one of the GS-3 Name
   Services, and for which one, then the appropriate set of MIB objects
   can be defined in a new MIB.

Of these two, I propose to investigate solution i), and if it proves
feasible, then to adopt it;  if not, to fall back to solution ii).

6. The Counter32 or Counter64 syntax will be used for counters.

7. In addition to the above, it has been suggested that MIB objects to
support Class 1 are no longer needed.  If I don't hear any objections,
I will assume that I can make this change also.

8. Yesterday, John Nguyen (jnguyen@gadzoox.com) asked in an email about
"bringing ZONE into FC Management MIB".  His suggestion would seem to
be in addition to, rather than as a replacement for, anything which will
be in the new FC-Mgmt MIB.  Thus, at this point in time, I'd like to
suggest that the changes listed above represent a large enough amount
of work for us to chew on.  Therefore, I propose that our answer to
John's query is to ask him to  re-raise this issue at a point in the
future when the new FC-Mgmt MIB is becoming more stable.

9. Are there any other changes that anyone would like to see at this
time ?

Also note that with this MIB now being in a different WG, the I-D needs
to have a draft-ietf-ips-xxx name.  I propose to use
draft-ietf-ips-fcmgmt-mib-00.txt.

Keith.