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

Re: snmpconf General Functional Questions


Thanks very much for the thoughtful comments. Some of the issues I think I
have some ideas about. Others are a bit more difficult. Perhaps others have

on 06/08/2000 10:22 AM, Joel M. Halpern at joel@mcquillan.com wrote:

> 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.

Perhaps I am being dense about this point because I do not understand why
this is true. We know exactly what instances are in a policy because we
evaluated the role table and it was based on the result of the evaluation
that we knew which instances the policy was applied to.  Additionally when
we made the atomic change either via cli or and non-policy enabled SNMP
system, the instance that was touched was part of the configuration command.
What have I missed.
> 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

It is for this reason that I suggested that if an object is brought out of
the policy by having a value changed that it be some marked (perhaps in the
role table, perhaps elsewhere). The object stays out of the policy until
either the big hammer is used and the entire policy is loaded again. This is
different than the policy being evaluated again - which will happen on a
routine basis in the managed device, how routing we still have not
established. You point made me see two things:

    1. The element does not need to inform software that realizes the Policy
Module when such a change is made. This is true because it is only really
relevant when the policy is re-evaluated. The disadvantage of this approach
is that some time might lag between the change and the time the notification
is sent to the central policy manager. This can be somewhat mitigated by the
configuration of informs from the managed object to the management system.
This will only work in the case of configuration change notifications built
into the basis system outside of any policy. Not  common today, but not hard
to add in the future. It can be further mitigated, depending on the policy
re-evaluation interval.

    2. The second point that your comment made me think about is that it is
probably wrong to have suggested that the element be moved back into policy
when the value that was changed was made the same again through any means
other than the policy mechanism. For example if a value of 2 is the policy
and a user makes it 3 and then later changes it back to a 2, I suggest that
the object is still outside the scope of the policy and should be so marked.
The way it becomes a member again is if the value that I have talked about
in the role table is deleted, or the entire policy is reloaded - the big
hammer approach that I am not real fond of.

> 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?

I like this idea of disabling parts of the policy. I suggest exactly the
same mechanism as I described above. The only difference here is that the
human sets an attribute value rather than the software that realizes the
Policy MIB Module.
> 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.

This is much harder. My knee jerk reaction that probably is wrong is that
the policy that is changed with regard to an element is the one in effect
when the change is made. For example if there are two policies a work hours
policy and a non-work hours policy and the value of a specific instance of
an object is changed during the work hours policy then that object is no
longer in the work hours policy. The non-work hours policy applies.
> My own conclusion is that
> A) we need to spell out clearly how and when policies take effect and
> maintain effect.

agreed. proposals are welcome.

> 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.

I was thinking something along the lines of what you said. An entry would be
made in the role, or perhaps other table, that indicates that a policy has
be exempted on this instance.  That would be sufficient. One problem I have
with the COPS-PR model is that it just does not deal with the inevitable
fact that people will make micro adjustments other than to reload the entire
policy. That could be a very expensive operation.

> 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.