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

Re: snmpconf General Functional Questions

Jon Saperia wrote:

> > This breaks down to: if (variable == 7) then variable = 7; else skip cuz
> > somebody changed it;
> >
> > In other words, a no-op.
> >
> No, if the value is not 7 do not reset. The idea is to reflect that the
> variable has been changed (not necessary to report the changed value since
> that can be obtained directly via a get from the management system). I think
> the logic would be:
>     If first evaluation of policy (for each element in a policy)
>         set value
>     for each following application
>         if value is equal default then continue, else
>            if value does not equal default and
>            pmTrackingElementToPolicyStatus
>             is modified(3) - do not change (no-op)
>         else,
>            reset value and send notification.

It all depends on how you set the value to modified(3). If it is done
when the policy engine notices that the value has changed, then the
entire algorithm
breaks down to the no-op I described (i.e.: any time you notice a
variable has
changed, set the do-not-touch bit. Stated another way: only enforce
configuration of variables that have correct configuration.)

However, if the modified(3) bit is set explicitely through an SNMP set
(or CLI
command), then the algorithm makes some sense.

It seems we have three models to choose from:

1. Allow no overrides
(Most conservative)
In this option, if the policy is causing an operational problem in the
field, the
policy must be re-written at headquarters and re-distributed, which will
problem resolution.

2. Any change causes an implicit override
(Most liberal)
I claim that this becomes a no-op. However, even if it worked as
desired, it seems
too liberal to let anybody override policy even when they might not
realize that
they are overriding it or without understanding the implications of
overriding the
policies they are overriding.

3. Explicit override capability
(Middle Ground)
Allows quick resolution of a problem and then subsequent re-engineering
of the
policy to anticipate the new situation. Policy will still be enforced in
following situations:
    - Untrained technician misconfigures something
    - Service provider or vendor tech-support script (or human) makes
changes that
don't follow customer's policy
    - Highly skilled network engineer makes a mistake
    - etc.

I suggest that the mddle ground is the right way to go. Operators can
still tweak
(with SNMP or CLI) variables not under policy control. And operators can
still tweak
variables that are under policy control but only after disabling the
policy (with SNMP or CLI).