SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: FC Management MIB - proposed changes



    Predrag,
    
    > 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