[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: snmpconf Conflict Resolution Issues
Your description of the state is accurate. I do not believe that on can
reasonably expect to understand all of "how we got here". We can improve
the situation if we want. Just as one can log all direct SNMP activity,
one could log all policy effects. One could then consult such a log to
find out that certain policies did take effect.
The alternative of trying to unwind the effect of a policy when it is
deleted requires guessing what the state "should" be. Such heuristics may
be interesting, but I don't think they belong in this work at this time.
At 02:12 PM 6/26/00 +0200, you wrote:
>So, the current state of a system ('attributes of instances') would be the
>result of the current pollicies, as well as of the previously deleted
>policies. If I assume the latest are not visible any longer, how would
>somebody look at the system and understand what is going on?
> > -----Original Message-----
> > From: Joel M. Halpern [SMTP:email@example.com]
> > Sent: Sun June 25 2000 0:24
> > To: snmpconf
> > Subject: Re: snmpconf Conflict Resolution Issues
> > It is my opinion that deleting a policy should not directly cause a change
> > in any attributes of any instances. It may be reasonable to expect
> > (depending upon our evaluation model) that the set of policies in effect
> > should be re-evaluated, which my cause some existing policy to change the
> > values of some objects. Trying to perform a direct "unwinding" of a
> > policy
> > when it is deleted would, I think, be a very bad idea.
> > Yours,
> > Joel M. Halpern
> > At 10:18 AM 6/22/00 -0400, Jon Saperia wrote:
> > >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.