[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
> > 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
>breaks down to the no-op I described (i.e.: any time you notice a
>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
>command), then the algorithm makes some sense.
>It seems we have three models to choose from:
>1. Allow no overrides
>In this option, if the policy is causing an operational problem in the
>policy must be re-written at headquarters and re-distributed, which will
>2. Any change causes an implicit override
>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
>they are overriding it or without understanding the implications of
>policies they are overriding.
>3. Explicit override capability
>Allows quick resolution of a problem and then subsequent re-engineering
>policy to anticipate the new situation. Policy will still be enforced in
> - Untrained technician misconfigures something
> - Service provider or vendor tech-support script (or human) makes
>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
>(with SNMP or CLI) variables not under policy control. And operators can
>variables that are under policy control but only after disabling the
>policy (with SNMP or CLI).