[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf General Functional Questions
on 06/09/2000 1:27 PM, Matt White at firstname.lastname@example.org wrote:
> 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.
Yes, I think we are saying the same thing.
> 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.
I think that the marking must be policy specific due to time. In one of my
previous examples, I mentioned the work and non-work hours case. I think the
exemption should contain the policyID and description. I know that the ids
may get reused, that is why the description is helpful.
> * Do we want to mark local modifications prior to policies being applied?
> It seems to me that we want to do this as well.
I am not sure what this means until an element has been identified as being
associated with one or more policies. I think many items could be in the
role table and never be in a policy. I think this only becomes interesting
after an element has been put under policy control. That said as another
part of this working group's activity, we are developing a BCP for
configuration in which we suggest that any time a configuration is changed
that the information about the change be send to the central manager. Seems
like good management practice to me.
> 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?
I think the 'don't touch' is an attribute of an element (instance) if it has
been placed under policy control and has then been modified by something
other than the policy system. The don't touch can only be helpful I think if
it is that specific and the don't touch is associated with a policy. What do