Re: comments on latest draft...

[Andrew Bierman <[e-mail]>]

> >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...
> >
> I tend to agree with you.  Yes some people may be able to switch their
> repeaters from one network to another.  However trying to do that in
> the chassis MIB tends to make this MIB somewhat unusable.

At first I thought, this is useful for devices that have no other suitable MIB.
It provides a uniform way for an NMS to control the device. But since the control
is based (partly) on registration OIDs, the NMS app would have to be hard-coded to
handle each device based on the OID it returned (i.e. chasModuleType, chasPhyResType).
The "well-known" OIDs will have "well-known" MIBs to manage the devices they
represent, leaving the vendor-specific OIDs, which require hard-coding.

But despite all this, I think the model has a lot of potential...we need to
be able to codify the resource-to-entity mapping mechanisms in order for
generic NMS apps to really manage unfamiliar devices with this MIB.  

> > [...]
> >      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.
> >
> I guess I like the ability to disable an entity at this level.  By doing
> this I can control when that device is a bridge, when it is a router etc.
> This is something that can be done from the entity specific MIBs but the
> central control is nice.
> 
> Now if the admin status objects cause a major stumbling block I'm willing
> to let them die off.

I like the idea as well. But from an implementation standpoint, this is 
problematic. Coupling and cohesion stuff...management domain integration
would be difficult...if there was a "primary MIB" that managed the entity,
how would the agent prevent these status vars, or chasPhyResAssignment, from
stepping on each other?

> 
> >      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).
> >
> So you support the many to many mapping that has been proposed.  I do tend
> to belive that this tends to be a bit more usable.

As mentioned by someone else, real devices share real resources. The MIB should
reflect that.

> > [...]
> -------------------
> Consider breaking the configuration group into a physical config group
> and a logical config group.
> 
> The physical config group would be optional and provide a table similar
> to this:
> 	chasPhyConfigTable
> 		INDEX { Physical location type index,
> 		        physical location,
> 			entity ID }
> This would provide a basic brute force approach to perform the mapping of
> entities onto physical modules.  It provides no information on how that
> is accomplished it just resolves the mapping for you.
> 
> 
> The logical config group would also be optional and would be basically
> what is currently proposed:
> 	chasResourceTable - Lists all resources within the chassis
> 	chasLogConfigTable - The many to many mapping between modules,
> 		resources and entities that has currently been proposed.
> 
> Well its a thought perhaps I can edit the existing draft with some of
> these ideas so people can see some of the proposals in more detail.
> 
> /David Arneson
> 

I like the idea of some optional tables that would allow the detailed
control that has been proposed. There are those who do not like
optional groups, because (in reality) they never get used.
I think I need to go over the draft a few more times to really understand
how to use the entire MIB. I'm sure others need to do the same.
To that end, any examples of MIB usage would be helpful.

--andy;
[e-mail]