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

RE: snmpconf General Functional Questions



And, as Avri hinted, table (1) does need to be SNMP-writeable to satisfy the
operational requirement of not having to go visit the wiring-closet again to
restore things to normality [you have to make the assumption that suitable
authentication is in force: only authorised people/tools are allowed to
change things at both SNMP manager and local interface].

Andrew

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@mcquillan.com]
> Sent: Friday, June 09, 2000 12:43 PM
> To: snmpconf@snmp.com
> Subject: Re: snmpconf General Functional Questions
> 
> 
> This is an implementable, well defined behavior.  I could 
> live with it.
> 
> It would be nice if the implementation were simpler than I 
> imagine, so let 
> me describe what I think the implementation effect is:
> 1) There is a table of objects for which the "do not touch" 
> bit has been 
> set.  When policy actions are being considered, such objects 
> may not be 
> effected.  [This relates to the question of failures of 
> policies which 
> effect several related objects.  TBD.]  This table probably 
> should be SNMP 
> visible.
> 2) There must be a table (whether visible to SNMP or not) or 
> all elements 
> which have actually been touched by policy.  [Removal of 
> entries from this 
> table must be tied to the maintenance of policy and the 
> removal mechanisms 
> for policy.  It may need to know which policies touched the object to 
> handle policy removal).
> 3) When an object is manipulated directly using low level 
> mechanisms (CLI, 
> SNMP, ...) the table in (2) is checked.  If the object is in 
> said table, 
> then an entry is made in the table in (1).
> 
> This does seem to require updating the direct manipulation 
> subsystem when 
> policy is added, which is unfortunate, but probably inevitable.
> 
> Yours,
> Joel M. Halpern
> 
> At 02:52 PM 6/9/00 -0400, Jon Saperia wrote:
> >If an element under policy control has any attribute (read 
> MIB Object)
> >changed that is under policy control, then it has the 
> exemption bit set that
> >Matt and I wrote about (the don't touch bit) set. It remains 
> in this state
> >until manually changed back. Dale made a good point that is 
> at some point
> >the policy might need to change.
>