[SNMP4J] SNMPv3 timing information

[Peter Verthez]

To follow up on my own question...

Verthez, Peter (Peter) wrote:
> Hello Frank,
>
> I have a small question regarding SNMPv3 timing (engine boots, engine time).
>
> We are managing an agent that does not behave entirely properly 
> regarding this timing: in some cases it resets the engine time back to 
> 0, but without incrementing the engine boots.   What we see is that we 
> as manager are then sending requests according to our knowledge of the 
> engine boots/engine time, and these are - rightfully - rejected by the 
> agent, because our engine time is higher than the agent's engine time.   
> And the agent sends an SNMPv3 report with the usmStatsNotInTimeWindows 
> variable.   This is never resolved, unless we force a cleanup in SNMP4J 
> of the timing information for that agent.
>
> Of course, the root cause (not incrementing the engine boots in the 
> agent) is a bug in the agent, but there is a discussion going on in our 
> team now what the proper behaviour of the manager should be.  The 
> discussion is whether in such cases, since we are the non-authoritative 
> engine in this exchange, the manager (and thus SNMP4J in this case) 
> should automatically do a rediscovery of the engine boots/engine time.   
> I couldn't immediately find an explanation in the RFCs to counter that 
> argument, but it is clear that SNMP4J does not do that.
>   

Well, I suppose what is applicable here is section 3.2 point 7b of RFC 
3414, but the question is: does this then also apply to the receiving of 
the report from the authoritative engine that says that the sent message 
is outside the time window?   It could be argued that in this case the 
manager should attempt to resynchronize with the agent.

Best regards,
Peter.

> Could you explain your view on this?
>
> Best regards,
> Peter.
>
>   


-- 
Peter Verthez