|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: FC Management MIB - proposed changesPredrag, > Point 8: > Although there are quite a few issues around zoning management, > most of them revolving around perceived inadequate security of > SNMP, I assume you mean the inadequate security of SNMPv1 and SNMPv2c, i.e., nobody perceives that SNMPv3 is insecure, right ?? > without this information MIB will not be complete. Are you saying that this MIB will not be complete, or that Fibre Channel management will not be complete ? > Zoning management is extensively defined in FC-GS3, is specific > to FC, and I do not see any reasons to delay this for some point > in the future. I see several options: 1. have the first version of the new FC-Mgmt MIB include Zoning, 2. start work on another MIB to address Zoning in parallel with working on the first version of the new FC-Mgmt MIB. 3. complete the first version (Internet-Draft) of the new FC-Mgmt MIB, and defer the addition of Zoning until a second or subsequent Internet-Draft of this MIB, but before its WG Last Call. 4. defer the start of work on another MIB to address Zoning until after completing the first version (Internet-Draft) of the new FC-Mgmt MIB. 5. finish the new FC-Mgmt MIB, including having it published as an RFC, and only then work on extending it to address Zoning. I'm not proposing #5 (as you may have feared). Rather, I'm proposing that we not do #1 - specifically, that producing the first version of the new FC-Mgmt MIB is a large enough task, that we should do it first before tackling Zoning. I also think #2 would require coodination between something new and something which is changing, and therefore would be more work/more difficult than is warranted/necessary. So, I'm proposing either #3 or #4; at this point, I don't have a feel for which would be better. What do you think ? Keith. > Regards > > Predrag Spasic, > Hewlett Packard > Details: https://ecardfile.com/id/predrag_spasic > > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Thursday, November 08, 2001 10:43 AM > > To: ips@ece.cmu.edu > > Cc: kzm@cisco.com > > Subject: FC Management MIB - proposed changes > > > > > > > > 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. > > >
Home Last updated: Thu Nov 08 15:17:36 2001 7655 messages in chronological order |