Subject: RE: snmpconf General Functional Questions

From: Andrew Smith <[email-masked]>
Date: Fri, 9 Jun 2000 11:43:47 -0700

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
deployable.

Andrew

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Friday, June 09, 2000 11:21 AM
> To: [email-masked]
> 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
>

---

From: Jon Saperia <[email-masked]>
Date: Fri, 09 Jun 2000 15:38:01 -0400

> application of the protocol but it does make it implementable and

I can see how putting these items out of scope of that work does simplify
things. I hope we can take a middle ground in terms of assumptions and yet
get a good improvement. For example, by allowing for the 'override' but not
attempting to roll back and keeping the element 'exempted' once a value has
been overridden. One tool that we do have that may make it more reasonable
is that we do have access and visibility into the instance specific data.

/jon