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

Re: snmpconf General Functional Questions



I would agree that the ability to override policy on a "local" basis is 
important.  There are several ways to look at this, some of which I think 
are problematic.

1) Unless we change the SNMP semantics (something we all agree we should 
not do), there is a basic multi-manager capability of SNMP.  As such, 
something set at a policy level can be changed at the instance level.  I 
think it would both be significant effort and undesirable to change this.

1a) The immediate question then becomes what indications one expects of 
this change.  Trying to keep enough track of what objects are effected by 
policies such that when a person changes an instance object a higher level 
policy marking is automatically created reflecting the override seems 
problematic.

1b) There is the whole question of how / when policies are neforced.  if we 
consider that policy actions are taken when policy conditions are checked 
and verified, we still have the question of when the conditions are 
rechecked.  If they are rechecked periodically, and if the conditions 
include the state of the variable to be changed, then it is quite easy to 
see that a human being trying to change an isntance object might find it 
continually changing back.  He would then need to somehow track down the 
policy that is controlling that, and somehow have a way to disable the policy.
1b') The disabling of the policy is probably only supposed to happen for 
some specific instance, not all instances in the box.  But one would not 
want to have to change the roles attached to an instance just to disable a 
policy, would you?  Similarly, what happens if the manager sends a new set 
of policies?  How will those effect this override?

1c) There can easily be more than one policy which affects an instance 
variable (for example, different policies for different times of day).  I 
can not see an obvious heuristic for deciding what the operator wants done 
with the nighttime policy when he changes a variable and turns off the 
daytime policy.

My own conclusion is that
A) we need to spell out clearly how and when policies take effect and 
maintain effect.
B) That most of the rest needs to be left to the structuring of the policy 
conditions.  For example, one could add a role that is "exempted", and in 
all ones policies include "and not exempted".  That may not be the best 
solution, and we certainly can not mandate it.  But trying to solve all of 
the interactions in "override are simply impractical.  The only alternative 
I can see is a COPS-like mechanism where there is no override at all.

Yours,
Joel M. Halpern

At 08:49 AM 6/8/00 -0400, Jon Saperia wrote:
> > General Functional Questions:
> >
> > 1. Should operators be able to override policy? Where is it useful to
> > restrict this in the architecture - fall out issues?
>
>Yes. It is an essential operational component for operators to be able to
>change one or more elements that are under policy control. For the purposes
>of this discussion, an element could be anything from an entire system,
>software that runs on it, or an individual queue on an interface. I do not
>believe we should restrict the ability to override policy in the
>architecture. I believe that this approach raises several issues. I have
>added my suggestions for their resolution - I am sure there may be others.
>
>    A. Notification of the change to operators - I believe that a
>notification  should be sent from the managed element to the configured
>managers for the system. The notification should contain the following
>information: user, time of change, and the objects that were changed. The
>instance values will be known to the system and would be conveyed to the
>manager as in any other notification. The preferred notification for all of
>our would should be an inform.
>
>    B. Where is the override shown on managed system. The managed system
>should reflect this in the status objects contained in the the Policy Table,
>and when an implementation and/or mechanism specific Module is in use, the
>change(s) should be reflected in the relevant status objects contained in
>that modules table. We may want to consider a marking for the Role table so
>show when an element that is under policy control contains one or more
>objects that have other than 'default' values.
>
>    C. How long is the override in effect? I recommend until one of two
>events. First, some source outside the policy system changes the value(s)
>back to the defaults. In which case there will no longer be the difference
>detected in point B above. The most common source will be the CLI. Second, a
>policy is reloaded to a system which should override the overrides.
>
>    D. What if the override causes a fault or failure in one or more
>operating policies? - I see this as no different than failures under other
>circumstances. The same rules (that we have not yet worked out) should
>apply.