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

RE: snmpconf General Functional Questions

We dived into this can of worms with COPS-PR. We very quickly swam to the
edge of the can and got out again and declared (a) time-of-day in the device
and (b) multiple managers, to be out of scope. Yes, this limits the areas of
application of the protocol but it does make it implementable and


> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@mcquillan.com]
> Sent: Friday, June 09, 2000 11:21 AM
> To: snmpconf@snmp.com
> Subject: 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