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,
    
    The problem is that I am not sure we understand zoning management well
    enough right now, as compared to simply managing the transport.  For that
    reason I would hate to delay the FC MIBs for a long time to figure out how
    to correctly manage zoning.  There is nothing stopping you or John from
    proposing a seperate MIB and working on getting it standardized, but I am
    not certain it belongs in this effort (which is to standardize the Transport
    management)
    
    Bill
    +========+=========+=========+=========+=========+=========+=========+
    Bill Strahm     Software Development is a race between Programmers
    Member of the   trying to build bigger and better idiot proof software
    Technical Staff and the Universe trying to produce bigger and better
    bill@sanera.net idiots.
    (503) 601-0263  So far the Universe is winning --- Rich Cook
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    SPASIC,PREDRAG (HP-Roseville,ex1)
    Sent: Thursday, November 08, 2001 11:00 AM
    To: 'Keith McCloghrie'; ips@ece.cmu.edu
    Subject: RE: FC Management MIB - proposed changes
    
    
    Keith,
    
    
    Point 8:
    Although there are quite a few issues around zoning management,
    most of them revolving around perceived inadequate security of
    SNMP, without this information MIB 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.
    
    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 16:17:37 2001
7659 messages in chronological order