Re: comments on 21-july draft

["David L. Arneson ([e-mail])" <[e-mail]>]

> 
> 1) chasUpTime--I will make one more pitch for this object, then give up:
> Basing chasSlotLastChange (or any other HW timestamp) on sysUpTime implies
> that the hardware portion of an entity/device is always reset when the
> management portion is reset.  In our repeaters, it is possible to
> reset the management without resetting the hardware. (This allows
> xyzValueForRestart type changes to be affected.) It is considered a bad 
> thing to reset hardware and disrupt network service if it can be avoided.
> 
> I'm also concerned about the assumption/rule that only one agent per chassis
> implement the Chassis MIB, and therefore chasSlotLastChange is relative to 
> the primary agent.  It may be possible for an NMS to access a secondary 
> agent in the chassis, but not the primary.
> 
> We were hoping to use the chassis MIB to allow any agent in the box to
> find out about all other agents in the box.  I admit this is difficult 
> to manage--one of those things that should be left implementation-dependent.  
> This problem overlaps the auto-discovery problem...an NMS may not know about
> a particular agent, but still have a route to it.
>
What is being said is that each instance of the chassis MIB should appear to
have a single manager.  Notice I said each instance.  I feel that it should
be possible for implementations to have multiple logical chassis within a
single physical chassis.  Each logical chassis would have complete knowledge
of it's self.  This can be handled by treating a sub chassis as another entity
with a type of agent.

I feel that it would be OK for each logical chassis to have a different
view of the time.  However within an instance of the chassis MIB time should
be a constant.  Therefore chasUpTime would not be required.
 
> 2) chasEntityAdminStatus = reset(4)
> This is a great idea.  We have a "chassisSlotReset" capability in our MIBs,
> but resetting per entity is a much better idea.  There should be language 
> in the DESCRIPTION clause that specifies that an agent may disallow setting
> this object (return BADVAL, NOSUCH, or GENERR?).  The chasEntityArgument
> object could be used to implement different kind of resets (e.g. factoryDefault).
> 
> 3) chasEntityFunction
> Obviously, multiple-function devices can be described with different
> values of chasEntityIndex/chasConfigEntity (and the same value of 
> chasConfigSlot). This way, chasEntityFunction can be an OBJECT IDENTIFIER,
> avoiding the "bounded enumeration" problem that exists with INTEGER
> objects.  The trade-off is that the chasEntityTable will be harder to implement
> and harder for an NMS to manage.  It will not take long for this bit-string
> list of 9 functions to be out-dated.
>
This is the primary reason I lean towards single function entities.  I
think the multiple function entities could be viewed as seperate logical
entities.  They would exists as a single entity but be called out as seperate
entities within the chasEntityTable.  I don't see any problem having multiple
entities on a given module.
 
> 4) chasConfigStatus
> Are the enumerations of valid(1) and invalid(2) enough?  I think the
> RMON model (add an OwnerString and use EntryStatus) would be more 
> robust.  The current model seems to require an entity to be created/modified
> in a single PDU.  However, it's already hard enough to test an arbitrary
> combination of chasConfigTable varBinds for simultaneous consistency, 
> and having a bunch of rows in 'underCreation' state would just make
> things harder. (I'm waffling :-)
>
>From Keith's explanation of this table these status values are quite sufficient.
I don't think we have any problems creating entries within this table.
 
> 5) chasConfigIfIndex
> I'm confused about the usefulness of this object. Is this supposed to
> help an NMS figure out how to reach/manage a particular entity? (Already
> handled by chasEntityParty or chasEntityIpAddress/chasEntityCommunity)
>
This would exists more as a connection point to MIBs defined by the module. 
> 
> --andy;
> [e-mail]
> 
>