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

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

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.