[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: snmpconf Conflict Resolution Issues
Jon, quick question. What's an intentional conflict between policies?
> -----Original Message-----
> From: Jon Saperia [mailto:firstname.lastname@example.org]
> Sent: Thursday, June 22, 2000 10:19 AM
> To: snmpconf
> Subject: 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.
> 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]