[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf General Functional Questions
on 07/04/2000 4:43 AM, Steve Waldbusser at firstname.lastname@example.org wrote:
> Comments inline:
>>> 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
>> 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.
It seems like we want the same thing. Consistent control by the policy
system while allowing for human override. I agree that allowing the facility
for override might have the entropy effect. Nevertheless, we must do it
since that is how operators will want things done. All I am suggesting is
that when a change to a policy controlled element is made, that the policy
system can know about it. In fact this could be used by management systems
to produce exception reports. Lets put the extra value I described in the
object you suggested.
> 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?
I did not suggest having the policy action execute for the reason you state.
We do not want it overriding the human override. It is the evaluation (one
of the means I suggested) of the filter that will have to be done
repetitively independent of whether we do this feature or not. Otherwise how
will we know if a new policy element has come into existence that should
have a policy action taken. I did suggest that even the element evaluation
might not be necessary for this function since the system will already know
what elements are associated with a policy. That will be in the agent
>> 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
I agree with you here again. I am saying that only those that can su to root
can make the change. My point was that permissions based on who you are can
>>> 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; 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)
for each following application
if value is equal default then continue, else
if value does not equal default and
is modified(3) - do not change (no-op)
reset value and send notification.
How is this?