Re: Re: comments on 21-july draft

[[e-mail]]

>> 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. 
> 
>I still don't understand.  The timestamps do not impose any requirement to 
>reset the hardware when the mgmt portion is reset (if there is any text
>which implies that we need to change it.)  On the other hand, after the 
>mgmt portion is reset, how does that mgmt portion know when the slot last 
>changed ?  How can it give anything else but a zero, meaning "at or before 
>the last mgmt reset", which is exactly the semantics of chasSlotLastChange:
>

oops...  I should have read the definition of chasSlotLastChange more closely.
There is no conflict for this variable. Our vendor MIB contains
hardware reset-timestamps and uptimes.  When sysUpTime is reset to zero,
these objects have to be reset to zero as well--so we make them 
relative to chassisUpTime instead.  chasUpTime is still useful if 
multiple agents within a chassis have a view (full or partial) of
the chassis MIB.  However, we may not get a consensus on how to implement it.
An alternative is to create an object that indicates who is the 
'primary' chassis MIB agent.  chasSlotLastChange would be relative to the
sysUpTime of that agent.


>> 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?).  
>
>How about including the following in the DESCRIPTION:
>
>      Agent support for the writing of any of the values of this 
>      object is implementation-specific.  For example, this object 
>      might be read only for entities that disabling would compromise 
>      the integrity of the chassis.
>
>Note that I don't think it's appropriate to include specific SNMP 
>error-codes in the DESCRIPTIONs.

Sounds good to me...I wasn't suggesting that error codes be specified in 
the DESCRIPTION clause, just wondering aloud what the proper error code 
would be. (My guess is BADVAL if some status values are supported, NOSUCH
if the object is implemented read-only.)

--andy;
[e-mail]