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

Re: snmpconf General Functional Questions - Policy Groups andPriority

Jon Saperia wrote:

> pmPolicyPrecedence OBJECT-TYPE
>     SYNTAX      Integer32 (0..65535)
>     MAX-ACCESS  read-create
>     STATUS      current
>          "The order in which policies on the local system are
>          evaluated. A policy with a higher precedence value will
>          be evaluated after a policy with a lower precedence. For
>          example, a policy with a precedence value of 999 will be
>          evaluated after a policy with a precedence value of 998.

I don't think "time order" semantics will work very well. First of all,
it seems to assume that there are no side effects of a variable going
through a sequence of lower-precedence values before settling on the
highest-precedence value. Second, we talked at the last meeting about
having objects that control the frequency of policy evaluation on a
per-policy basis, so it doesn't seem right to assume that all policies
are evaluated at the same time, in order. Third, I'm concerned about
what happens when an element changes state and suddenly matches
a policyFilter - are we forced to rerun all higher precedence
policyActions? Finally, consider that a policyAction may affect multiple
variables - I think we want all of the variables to be set or none -
it wouldn't be cool to change only those that survive higher precedence

>          These
>          values must be unique on the local policy system that realizes
>          this Module.

What if they're not? Should the agent reboot? I'd prefer to specify the 
agent behavior even if they aren't unique. Let me suggest that we allow 
them to be the same but it is an implementation-dependent matter how
are processed if they are the same. If the manager needs "unique"
semantics, it's its responsibility to set them right.

BTW, this would also present multi-manager problems.

> The value for a particular policy should be
>          the same across an administrative domain, though that is not
>          mandatory.

Is that important?

>          When the local policy system performs the evaluation
>          in the pmPolicyFilter for the policy identified by this row
>          it will also read the pmTrackingElementToPolicyStatus object
>          for each object returned as a result of the policy evaluation.
>          If that object is set to modified(3), then the pmPolicyAction
>          shall not be taken on that element.

This object seems like an odd context to describe the modified or
forceOff semantics. It should probably be in the pmPolicyTable
where the entire policy evaluation algorithm should be described.

>          The value of precedence(4), of pmTrackingElementToPolicyStatus
>          is an indication that when an evaluation was performed by
>          another policy, the pmTrackingElementToPolicyStatus was
>          found to have a value of on(1) and that policy had a higher
>          precedence value than the policy that initially set the value
>          of the pmTrackingElementToPolicyStatus to on(1). In this event,
>          the pmTrackingElementToPolicyPrecedence object shall have the
>          value of the pmPolicyIndex for the policy with the higher
>          precedence value entered. If the policy identified by this
>          row of the pmPolicyTable has a higher precedence value than
>          the value found in pmTrackingElementToPolicyPrecedence then
>          the pmPolicyAction should be performed on the element and the
>          pmTrackingElementToPolicyPrecedence object updated with the
>          value of the pmPolicyIndex for this policy. The only exception
>          to these rules is when the policy that has the higher
>          precedence value in not currently running, i.e.,  the schedule
>          is off."

This is pretty cool.

>     ::= { pmPolicyEntry XX }
> pmPolicyGroup OBJECT-TYPE
>     SYNTAX      SnmpAdminString
>     MAX-ACCESS  read-create
>     STATUS      current
>          "An administratively assigned string that is used to group
>          policies. Any combination is legal, the pmPolicyGroup object
>          does not constrain precedence. That is precedence is evaluated
>          independent of grouping though adminstrators might group
>          related policies together for clarity."
>     ::= { pmPolicyEntry XX }
> I think the addition of the new state for pmTrackingElementToPolicyStatus
> and the new pmTrackingElementToPolicyPrecedence are pretty well defined
> above.
> We should add a notification each time such an override takes place. The
> notification should include the element, prior value, policy with the higher
> precedence and new value. This is an exception condition and should be
> reported as such. I think the exception to this exception is in schedule
> transitions.
> /jon