[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Updated PM MIB draft

Hi Dave,

David Harrington wrote:
> Hi Steve,
> Steve Waldbusser wrote:
> >
> > 34 Suggested that smarter implementations might want to rerun policies
> >    prior to maxLatency if a role changes (see pmPolicyFilterMaxLatency)
> I believe the object referenced should be pmPolicyConditionMaxLatency.

You're right.

> If I'm an operator, I need to know how this situation will be handled,
> and I don't want it to be implementation-specific, I want it consistent
> across my network, because it could impact the application of my
> security policies. Adding lots of vendor-specific if-then-else clauses
> to my policies will make then unwieldy, potentially unreliable, and
> difficult to debug and maintain.
> I am concerned that this text doesn't standardize the expected behavior.
> I think this language needs to be tightened up to guarantee a consistent
> approach by all implementations.

Well, the rules for maxLatency has always allowed this sort of leeway
(that's why it's called *max* latency). The new text just suggests a
particular situation in which the agent may wish to use this leeway.

Since we can't know the current value of the filter at every instant of
time, we necessarily rely on a cached value of the last outcome to
perform our logic. The maxLatency objects describe when the cached value
should be considered stale. The policy author can adjust this "cache
timeout" value to meet the needs of the policy. If the policy engine
updates the value more quickly than this, it's a bonus.

Do you think this is OK?