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

Re: snmpconf pm issue #23 - policy termination

Right.  Generally speaking I don't expect policy evaluation to be extremely 
computationally expensive such that it is infeasible to force a premature 
evaluation of a policy.  I also don't expect policies to be toggling in and 
out of effect at a high frequency, at least not policies that are in any 
way heavyweight.

The security argument is a good one, but I think a more general argument is 
that policy should put our network into a known state.  By leaving a gap 
between taking a policy out of service and putting the lower priority 
policy in service, we have a time period where the network policy is 
undefined.  I don't think providers, especially telecom providers, will be 
very happy with that arrangement.


--On Wednesday, June 06, 2001 8:34 PM -0700 Steve Waldbusser 
<waldbusser@nextbeacon.com> wrote:

> I totally agree with you guys that this is necessary. You can already
> see this behavior described somewhat, it's just not complete yet.
> The following text is in the defer() function:
> "When a policy defers it exits and the filter-matching policy with the
> next-highest precedence is immediately run."
> Similar text needs to be added to the policy table logic as well.
> This isn't expensive either. We're just changing the timing a bit. We're
> just re-evaluating the "previously trumped" policy filters immediately
> rather than waiting till the next policyFilterMaxLatency time.
> Steve
> Wes Hardaker wrote:
>> >>>>> On Tue, 05 Jun 2001 11:40:26 -0400, David Harrington
>> >>>>> <dbh@enterasys.com> said:
>> David> I am concerned that for policies which may affect the security
>> David> of the network, it may not be acceptable to wait until the next
>> David> regularly-scheduled policy evaluation; a more immediate
>> David> determination of the policy to apply may be necessary to ensure
>> David> the viability of the security environment.
>> David, thanks for writing up the exact point that I would have made.
>> It is a grave flaw to simply "wait" for the next update.
>> David> OTOH, I also recognize that forcing a complete evaluation cycle
>> David> to occur every time a policy becomes inactive may be
>> David> problematic. Is there any way with the existing language and
>> David> primitives to cause the evaluation to be done immediately when
>> David> selected policies become inactive?
>> Really you want to evaluate just the current element, which is what I
>> think you're applying.  Or, if a policy is deleted/made-in-active you
>> should evaluate any elements that it may have covered.  Unfortunately,
>> the point that this gets either ugly or expensive is a good point.
>> However, I think an immediate evaluation must be done regardless of
>> the costs (to do otherwise would prevent security policies from making
>> use of this work).
>> --
>> Wes Hardaker
>> NAI Labs
>> Network Associates