comments on latest draft...
Andrew Bierman <email@example.com> Fri, 18 June 1993 23:03 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14960;
18 Jun 93 19:03 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa14956; 18 Jun 93 19:03 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA28428; Fri, 18 Jun 93 18:40:22 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Fri, 18 Jun 1993 18:40:20 EDT
Received: from pobox.synoptics.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA28408; Fri, 18 Jun 93 18:40:15 -0400
Received: from donatello (donatello.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA09731; Fri, 18 Jun 93 15:40:22 PDT
Received: by donatello (4.1/2.0N) id AA11623; Fri, 18 Jun 93 15:40:22 PDT
Date: Fri, 18 Jun 93 15:40:22 PDT
From: Andrew Bierman <firstname.lastname@example.org>
Subject: comments on latest draft...
> Four individuals have participated in these discussions, with three > believing that allowing for items 1 and 2 is very important. (There > seems to be general agreement on item 3.) > > What do others think? Make that one more. I think it is important to have a simple mechanism for finding out what physical resources are being used by a given entity, and what entities are using a given physical resource. That is, if I was to buy off on this model... -------------------------------------------------------------- I have been trying to evaluate the chassis MIB with the following criteria: 1) Could I implement this MIB on the assortment of platforms and devices I have to support? 2) Could I use this MIB to effectively manage all of these devices? short answer: 1) yes -- with a great deal of effort. But it won't be pretty mapping existing management structures to the "resource/entity" model 2) no -- there are too many abstractions and not enough real information to manage an arbitrary entity or physical resource. long answer: I think the MIB will end up being used to find out what's in a chassis, and enough information about each "thing" to point to the "real" MIB used to manage that "thing". (This is a feature, not a bug.) I don't think the MIB needs to provide control of every "thing" in the chassis. The MIB provides detailed inventory information that in itself is useful to generic NMS applications. I envision an app using the MIB to find out what entities are present on what modules... A user might click on a bridge icon shown on some sort of front panel display, generated from the chassis MIB inventory data, and the app might use the bridge MIB (not the chassis MIB) to find out about the configuration of the bridge and all of its ports, in order to display a new management screen for the bridge. It's hard for me to comment on individual objects when I don't agree with the goals established for this MIB. I think it's enough to provide the inventory and "common chassis" support (e.g. fans, PS, sensors) in a standard MIB. (So I'll reserve my comments on chasModuleAdminStatus and chasEntityAdminStatus until I see if anyone agrees with me ;-) I suppose this doesn't matter because an Agent can disallow setting of the adminStatus objects, but I think it will take a great deal of effort to reach closure on these objects. Thanks mostly to the work of the four previously mentioned participants, there is a workable model (albeit complicated) for representing the logical and physical parts of a chassis (assuming that many:many entity-resource mapping is added in some form). Since an NMS app could ascertain all of the logical chassis information simply by fishing for SNMP agents, and then fishing for MIBs on each agent, one unique capability of the chassis MIB is providing the logical to physical mapping of each entity. And I think this MIB can do that. Plus you get power-supply info thrown in for free. However... model bash: In general, I believe it will require great effort to map existing (and even new) products into this model. Knowing what all the logical and physical resources are for each entity and card will be hard enough, but actually managing things via this model will be even harder. And I'm not sure it's worth it...if I want to manage bridge ports I will use the bridge MIB, and use the repeater MIB for repeater ports. In fact, for just about any "thing" that can be a resource or entity, that "thing" will be more accurately managed via a MIB designed for just that purpose, than with the chassis MIB. And that MIB will probably be easier to implement than the chassis MIB. I think I already know the answer to this question, but is there a way to make the resource tables optional, and still be able to associate logical entities with their physical location within the chassis? --andy; email@example.com