RE: FC Management MIB - proposed changes

[Kha Sin Teow <KhaSin@Brocade.COM>]

Hi,

I just got back from the T10 meeting and saw
a flurry of discussion on this topic.

I think Dave's comments are mostly in line with mine.
Some more in-line comments below ...

| -----Original Message-----
| From: Black_David@emc.com [mailto:Black_David@emc.com]
| Sent: Thursday, November 08, 2001 12:51 PM
| To: kzm@cisco.com; ips@ece.cmu.edu
| Subject: RE: FC Management MIB - proposed changes
| 
| 
| Folks,
| 
| For simplicity, I would propose keeping the initial revision focused
| on structural and format changes only - i.e., make no functional
| changes that aren't required to bring the MIB into line with the
| overall architecture of MIBs, use of SMIv2, and the like.

Absolutely.
It's not a good idea to start opening up at this stage
for more functionalities.

|  Comments on
| this, keyed to Keith's issue numbers:
| 
| 1.  The trap table doesn't match up with RFC 2573 - I presume
| 	correcting this is part of the conversion to SMIv2.
| 
| 3.  Let's keep the replacement of RFC 2837 as (a) a proposal
| 	and (b) Keith's recommendation to the WG as MIB Advisor,
| 	but not formally adopt that approach until we have a version
| 	of the MIB draft that would replace RFC 2837 available for
| 	review by the WG.

agree.
let me add Keith's point 3 here (preceded with ">") with my
comments.

> - 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.

I'm not sure if I follow the argument above as a good reason
to replace RFC2837. It started out as an effort to define MIB for
FC switches (not FC hub, HBA or other FC interconnect elements as
in to be re-worked FC-Mgmt MIB).

I'm open to suggestion that if RFC2837 needs revision to
line up with other MIBs due to overlaps (such as Entity MIB).
If that means that RFC2837 will be obsoleted some time in future
by the new FC-Mgmt MIB, I'm ok with it.
However, we need to be careful that we don't try to fold everything into
the new MIB in one go.
If we need to fix the sink, please don't think about doing a new roof.-)

> - it should have extended the ifTable, rather than overlapping with it,

Unfortunately, at the time, the adivsor didn't raise the issue with
the working group; 
I agree it's an area to improve.

> - it should not have defined the fcFeModuleTable, which overlaps with
>   the Entity MIB.

At the time, the Entity MIB was work in progress.
I didn't quite see how it fits in then.
Given the state of Entity MIB, I agree that this is another area to improve.

> - and it should have specified (at least) its octet counters as Counter64.

as Predrag pointed out, FC standards doesn't specify 64bit counters.
As far as I'm aware, most current FC implementations only support 32-bit
counters.
Therefore we should be cautious about specifying 64bit counter
(which would require an agent to maintain a set of software counters).

... 

| 2, 4, and 6 look fine to me, as does the new draft name.
| 
| Comments?
| 
| Thanks,
| --David
| 
| ---------------------------------------------------
| David L. Black, Senior Technologist
| EMC Corporation, 42 South St., Hopkinton, MA  01748
| +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
| black_david@emc.com       Mobile: +1 (978) 394-7754
| ---------------------------------------------------
| 
| > -----Original Message-----
| > From: Keith McCloghrie [mailto:kzm@cisco.com]
| > Sent: Thursday, November 08, 2001 1:43 PM
| > To: ips@ece.cmu.edu
| > Cc: kzm@cisco.com
| > Subject: FC Management MIB - proposed changes
| > 
...

Kha Sin/