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

Re: snmpconf General Functional Questions



It may be as straight-forward as you and Jon suggest.
But, somehow, I can see ending up in interesting states.

For example, using the daytime / nighttime case, someone overrides the 
current (daytime) policy on some instance.  It becomes night, and the 
nighttime policy takes effect.  It was not overriden.  Then, it is no 
longer nighttime.  But, the daytime policy is still overriden.  So the 
instances remains set as the nighttime policy specified?  That is unlikely 
to be the desired effect.  But I tend to strongly shy away from policies 
which can unwind themselves to "previous" states where those are unspecified.

The obvious alternative is that if an object is touched manually, then it 
is blocked from policy. Or maybe only from policies which were already in 
the box when the attribute was changed?
Still looks complicated to me.

Yours,
Joel

At 01:27 PM 6/9/00 -0400, Matt White wrote:
>On Fri, 9 Jun 2000, Jon Saperia wrote:
>
> > 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.
>
>In fact, we can probably store policy affected object identifiers in a
>table and then mark them when they are locally modified.  To return that
>object to its policy based state, we simply remove the marking.
>
>The questions then become:
>*  What happens to marked objects if the policy affecting them is removed?
>    Are they removed from the table or do they remain in case the policy
>    affecting them is reinstated?  I lean towards the later due to
>    time-based policies, if nothing else.
>*  Do we want to mark local modifications prior to policies being applied?
>    It seems to me that we want to do this as well.
>
>So maybe what we really want is a "Don't touch" table of locally
>configured OIDs and the ability to delete OIDs from that table when the
>local configuration is no longer relevant?
>
>
>-Matt
>----
>Matt White
>Ericsson IP Infrastructure