Subject: Re: snmpconf General Functional Questions - Policy Groups and Priority

From: Jeff Case <[email-masked]>
Date: Fri, 7 Jul 2000 18:19:05 -0400 (EDT)

i think we want to be fastidious in substututing the work precedence for
the word priority

regards,
jdc

---

From: Jon Saperia <[email-masked]>
Date: Sat, 08 Jul 2000 10:10:21 -0400

> i think we want to be fastidious in substututing the work precedence for

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
    DESCRIPTION
         "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
    DESCRIPTION
         "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

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 12 Jul 2000 23:35:47 -0700

Jon Saperia wrote:

>          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
policies.

>          These
>          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
they
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

Is that important?

>          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
description
where the entire policy evaluation algorithm should be described.

>          precedence value in not currently running, i.e.,  the schedule

This is pretty cool.

---

From: Matt White <[email-masked]>
Date: Thu, 13 Jul 2000 13:25:03 -0400 (EDT)

Jon:

This looks good to me.

Matt White
Ericsson IP Infrastructure

---

From: Jon Saperia <[email-masked]>
Date: Wed, 26 Jul 2000 09:57:39 -0400

> it wouldn't be cool to change only those that survive higher precedence

I did not reproduce the entire note here since the main points are above. In
short, we are in agreement that we want to have objects that control the
frequency of policy evaluation. I do not think what I propose requires that
all policies be evaluated in order. The precedence value will work even if
one policy is evaluated every minute while another that potentially
conflicts with it is evaluated only once a day. Once evaluated, the
information needed by the system to work is present.

We can talk more in Pitts.

/jon