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

Re: snmpconf General Functional Questions

The problem with I have with your proposal is two fold:
A) Your objection to alternative 2 (roughly what is on the table, stated 
somewhat oddly) is in your concern about whether someone should be able to 
override policy.  If they have the access to write directly to the 
variable, then they should be able to do so.  They should not have to 
understand the policy tables and find the correct place to markt "I mean 
this"  If they are making the change, they mean it.

2) If you require people to explicitly mark that they want to override 
policy, they will forget.  They will be surprised and confused when the 
system does things that they do not expect.

Fundementally, you are arguing that putting an object under policy control 
should remove it from SNMP control unless it is explicitly removed from 
policy control first.  I am arguing that the act of directly setting the 
attribute seems to me to be quite clear enough.

You raise the red herring of "then why reevaluate policy".  The answer is 
that there are many ways that reality can change, not just by changing an 
SNMP variable.  Some of these are equivalent to such sets (CLI is I agree 
still manual change).  But cards fail.  VCs come up.  peerings start and 
stop.  Cards get inserted and removed. These things may have effects on the 
policy decision.  Probably teh easiest case to understand is when a 
customer is added to a port.  Yes, this results in direct SNMP sets.  But 
these occur before the policy has manipulated the port.  So they don't 
prevent policy from taking effect.  Then the policy system decides what the 
effect of these (role, etc) attribute settings should be.  Another related 
example is where the role table is changed.  That does not change any 
object directly effected by policy, and therefore does not remove anything 
from policy.  The policy reevaluation will take these changes into account.


At 11:20 AM 7/5/00 -0700, Steve Waldbusser wrote:

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