comments on latest draft...

[Andrew Bierman <[e-mail]>]

> 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;
[e-mail]