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

Re: snmpconf General Functional Questions - Policy Groups and Priority


This looks good to me.

Matt White
Ericsson IP Infrastructure

On Sat, 8 Jul 2000, Jon Saperia wrote:

> on 07/07/2000 6:19 PM, Jeff Case at case@snmp.com wrote:
> > i think we want to be fastidious in substututing the work precedence for
> > the word priority
> I believe Jeff is correct. The term I meant is precedence: the fact of
> preceding in time. Specifically precedence of evaluation of the policies.
> Given this, I would like to suggest addition of two objects to the policy
> table and the addition of one more enumerated value to the
> pmTrackingElementToPolicyStatus object and a notification:
> 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. These
>          values must be unique on the local policy system that realizes
>          this Module. The value for a particular policy should be
>          the same across an administrative domain, though that is not
>          mandatory.
>          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.
>          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."
>     ::= { 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