|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: FC Management MIB - proposed changes> 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. Agreed. Even so, almost everything in the MIB will be affected. > 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. With SNMPv2c/SNMPv3, a Trap became one of the two forms by which a notification is transmitted; the other form is an InformRequest. SMIv2 MIBs don't define traps - they define notifications (with the NOTIFICATION-TYPE macro). With SNMPv2c/SNMPv3, agents generate notifications, not traps. The destinations to which a notification is sent is determined by the tables in the two MIBs defined in RFC 2573: the SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB. The snmpNotifyType object in RFC 2573 determines in which form the notification is tranmsitted to a destination; it's possible for the same notification generated by an agent to be sent as a trap to one destination, and as an inform to another destination. Thus, the trap table is a relic of the SNMPv1-only days; it is: a) insufficient for SNMPv2c/SNMPv3, and b) a duplicate of a subset of RFC 2573. It should be deleted without replacement. > 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. We can postpone the decision on what happens to 2837. However, 2837 contains information on FC interfaces. The FC-MGMT MIB also contains information on FC interfaces. Most of the information will be the same, and should be defined once; I propose in the new FC-MGMT MIB. There are a few pieces of information which are specific to Fabric Elements. I'll include those in the FC-MGMT MIB for the time being, until the postponed decision is made. > 5. I think there's a misunderstanding here. There is only one > name service in any FC fabric, period. The term "Simple Name > Service" is historical and refers to the current approach > to Fibre Channel fabric name service by contrast to the > originally-proposed X.500 directory-based approach (see the > original FC-GS) - the meaning of "Simple" should now be > obvious, as it's by comparison to X.500 ;-). > > Both the Zoned and Unzoned name services are simple name services. > The same objects can be used to represent both, as only one is > active at any time, and the communication interfaces/protocols > are identical. Client access to the name service is the same > in both cases; zoned vs. unzoned only affects server behavior > in terms of what is returned to a query. In addition the name > service objects are described to represent only entities > "known to this unit". So, in a zoned fabric, I would expect > the table in a switch to be completely populated, but the table > in an HBA to contain only the entries in that HBA's zone > because the HBA doesn't "know" about any others. > > The name server objects need to be retained - these are quite > important for fabric management visibility. Whether the fabric > is zoned or not and how the nameserver behaves can be determined > from the zone objects (i.e., for a switch, the nameserver objects > contain everything and the zone objects have to be consulted to > figure out what a query from a particular client to the nameserver > will return). OK. > 7. I would definitely take out Class 1 support, and reference FC-MI > (which prohibits Class 1 service) as an authority for doing so. OK. > 8. For the initial version, I would only carry forward the zone > objects existing in the current MIB and not define any new > functionality - that can be done in revisions after -00. OK. > 9. I'd prefer that the -00 version contain no additional functional > changes beyond those required to support the necessary > structure and format changes. Once we have that -00 baseline, > functional changes can be made from there. OK. > 2, 4, and 6 look fine to me, as does the new draft name. Thnaks, Keith.
Home Last updated: Wed Nov 14 09:17:44 2001 7810 messages in chronological order |