[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:saperia@mediaone.net]
> 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
> meeting.
> 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
> conditions. 
> 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]