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

snmpconf Conflict Resolution Issues

Here is the second in the group of issues that came out of our interim

As before, I will put in my suggestions/thoughts where I have an opinion.

Conflict Resolution Issues:

1. How do we deal with intentional and unintended conflicts.

It is hard to tell between intentional and unintended conflicts between
policies. My suggestion is that this function be left to the policy
application function and not the managed element software.

2. Is conflict detection or resolution a goal?

Both are hard. Unless someone has a specific proposal, I suggest that we
omit this capability or recommend that it be left to the ingenuity of the
equipment or manager software developers.

3. What happens when a policy is deleted? What if anything do you revert to?

In the case of DIFFSERV, I do not see much of a problem since the traffic
that would have been treated will in systems I know about,  pass through the
system subject to the same 'rules' as the rest of the traffic. The problem
is for other types of policy. For example;  a policy that causes the
configuration of primary and secondary DNS servers. If the policy is
removed, the systems could be left without knowing where to send DNS
requests. I do not think we want to have the managed elements keep a scratch
pad either (though some may choose to do this for a number of reasons - and
we should not prohibit this).

My suggestion is that we recommend in the BCP that policy managers that
delete a policy, replace it with a default if appropriate or the parameters
that existed prior to the installation of this policy. This will be a
difficult problem to solve.

4. How many errors are acceptable in a policy? How are they reported?

Just as with the override of policy, failures should be reported on a per
instance basis. That is, if 5 instances fail a status object in the role
table that indicates a policy that includes this instance based on the
evaluation of the policy filter is not in force. This time the reason is a
failure as opposed to an override. There is probably no need for a second
object since the status can not both be failed and overridden.

A notification should be sent in such failure situations only when the
policy is first evaluated, not each time the policy is locally evaluated.

Beyond a managed elements requirements for consistency, we could create
another object that could deal with this, but it is probably best left to
the management application. The management application would also be the
place to determine if a particular value for a MIB Object under policy
control is outside of a policy range which would be helpful. Particular
instances may be tweaked that are under policy control due to a number of

5. What happens when a configured element breaks that is executing a policy?

The object that reflects the element status in the role table should be
updated and a notification sent. The policy ID should be part of all such
notifications for override, failures on initial evaluation/set up and
subsequent failures.

[end of list]