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