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

Re: snmpconf General Functional Questions

on 06/30/2000 6:45 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote:

> I agree that the "touch-bit" needs to be instance specific, but placing it in
> the role table is pretty heavyweight because it will turn off *all* policies
> that control a particular element. Say I need to override a variable for
> firefighting purposes but I don't want to also turn off the policy that
> applies
> QOS to that interface (because that might cause another firefight). The
> "touch-bit" should turn off a particular policy from a particular instance.

Steve I had not intended that the policy be turned off globally. It was just
and indication that a particular element controlled by a policy had been
tweaked. That said, the proposal for the pmTrackingElementToPolicyElement
may be better than using the role table. The change I would make is that we
add an enumeration which is:

This indicates that the values for a specific element in a specific policy
have been changed by a means other than the policy system.
> In the current draft, such a facility exists:
> PmTrackingElementToPolicyEntry ::= SEQUENCE {
> pmTrackingElementToPolicyElement          RowPointer,
> pmTrackingElementToPolicyStatus           INTEGER
> }
> INDEX       { pmTrackingElementToPolicyElement, pmPolicyIndex }
> pmTrackingElementToPolicyStatus OBJECT-TYPE
> off(0),
> on(1),
> forceOff(2)
> }
> The forceOff state is the touch-bit. When set, it forcibly disables this
> policy from executing on this element.

This is fine but different. This value would be considered to be under the
control of the policy management system in my view. The modified value
indicates that a CLI or other non-policy based method touched the values for
this element that are associated with this policy.

> 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. 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. I might
configure my systems under policy control so that only certain 'highly
privileged' users can modify the instance level configuration parameters
that are under policy control. They off course need this for fire-fighting
etc. This model is really no different that when a config file is sent to a
router today and is then later modified with a couple of CLI commands by a
network engineer because of one problem or another.

> 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. There are several
ways of doing this, one might be during the re-evaluation of the policy
filter associated with each policy. This is not as bad as it might at first
seem since all that is required is to know if a value for an instance is
different than the default contained in the policy action object directly or
in a mechanism or implementation specific module. Another implementation
approach could be to separate this check from the instance evaluation since
the instances are already known. This could be a computationally less costly
approach. For future modules, I suggest more extensive use of notifications.
That way when a notification is generated a more timely update can be done
with less overhead.

> 3) Doesn't specify which policy to override in those cases where a single
> variable is under control of multiple policies.
In this case, one would assume multiple entries in your table, one for each
policy that an element is a member of. In that case the status would be
modified for each policy that the element is a member of.