[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf General Functional Questions
> > Also, I don't believe in having these bits set as side-effects of setting an
> > SNMP variable. Reasons include:
> > 1) An SNMP set for a variable that is under policy control doesn't communicate
> > the following necessary sentiment: "While I know that this variable is under
> > policy control, I intend to override that anyway". In other words, the SNMP
> > engine can't tell whether the request intended to override policy or was an
> > innocent mistake. It would be hard to say that we're enforcing policy when any
> > request has carte-blanche to get an exemption.
> The intent of the user, innocent or not does not matter here. What matters
> is that a value that was provisioned via the Policy module was changed by
> something other than the policy module.
But what happened to the policy system's enforcement responsibility? Getting the
network set up in a consistent way is only half the problem. From that point entropy
takes over and makes the configuration less and less consistent as more and more
devices get tweaked. Unfortunately, in my experience, humans are responsible for the
large majority of this "entropy": untrained technicians, sloppy engineers, people
from outside organizations, etc are all responsible for making configuration changes
that defy the network manager's wishes. It must be the responsibility of the policy
system to enforce the network manager's high-level wishes, while still allowing a
fireighting technician to override when absolutely necessary.
Another question this raises is why would we have the policyAction execute
repetitively if it will never end up changing any variables back into conformance
with the policy? The only time it is allowed to enforce the policy is when the
network element is already in conformance with the policy?
> Certainly a well run system would
> not give carte-blanche to any user to make modifications. This is one of the
> reasons why user based security can be helpful in policy management.
Security is orthogonal to this discussion. If I am a highly-priveleged Unix admin I
don't spend my day reading my email and writing documents while logged in as root. I
spend most of my time with my privileges disabled so that I won't make a mistake and
wreck the system. I enable my priveleges only when I need to use them so that I
don't break my own "policy". In other words, even privileged users need a policy
system to make sure that they don't make mistakes.
> > 2) Would require changing instrumentation for all MIBs.
> I do not believe this is so since it is the policy system that will detect
> this change, not the instance specific instrumentation.
This breaks down to:
if (variable == 7) then
variable = 7;
skip cuz somebody changed it;
In other words, a no-op.