Subject: snmpconf pm issue #23 - policy termination

From: Steve Waldbusser <[email-masked]>
Date: Mon, 04 Jun 2001 09:18:33 -0700

Issue: Jon writes: "There have been extensive discussions about
  what to happen when a policy terminates. My recollection -
  with help from David - is that if one wants a policy reset
  after termination, a lower precedence policy should be in
  the group that will take over. I have no issue with this as
  the resolution, only that we need to document that this is
  how this behavior is achieved."

How's this text?

"Note that if it is necessary to take certain actions after a policy is
no longer active on an element, these actions should be included in a
lower-precedence policy that is in the same policy group."

Steve

---

From: Jon Saperia <[email-masked]>
Date: Mon, 04 Jun 2001 12:48:03 -0400

> lower-precedence policy that is in the same policy group."
This is just fine, it does the job nicely.y

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: Steve Moulton <[email-masked]>
Date: Mon, 04 Jun 2001 13:13:44 -0400

I agree with the proposed text, but it raises a question.
When a policy is no longer active on an element, is another
policy evaluation done to ensure the proper policy
is in force?  This may have been discussed; but I don't recall the
resolution.

My immediate reaction is to say "no, it happens when it happens,
lets not micromanage this thing".  Some cases:

1  A policy goes out of schedule.  At this point, since a
   "policy evaluation cycle" is taking place, the lower precedence
   policy will be enforced.

2  A policy is removed from service (via pmPolicyAdminStatus or
   pmPolicyRowStatus).  Since these require positive action
   by a manager, that manager should be responsible for 
   the state of the elements governed by that policy.
   I'm not sure how this would be done, when it involves
   forcing a lower precedence policy evaluation to take place.
   Perhaps by temporarily changing the pmPolicyFilterMaxLatency
   for a short period of time on a policy the manager thinks
   should be in force.

3  The element has changed state in such a way as to no longer
   be managed by a given policy.   Should this just be caught
   on the next policy evaluation?

	- Steve

> lower-precedence policy that is in the same policy group."

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: David Harrington <[email-masked]>
Date: Tue, 05 Jun 2001 11:40:26 -0400

Hi,

I am concerned that for policies which may affect the security of the
network, it may not be acceptable to wait until the next
regularly-scheduled policy evaluation; a more immediate determination of
the policy to apply may be necessary to ensure the viability of the
security environment.

OTOH, I also recognize that forcing a complete evaluation cycle to occur
every time a policy becomes inactive may be problematic. Is there any
way with the existing language and primitives to cause the evaluation to
be done immediately when selected policies become inactive?

dbh

-- 
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: Wes Hardaker <[email-masked]>
Date: 06 Jun 2001 15:45:43 -0700

>>>>> On Tue, 05 Jun 2001 11:40:26 -0400, David Harrington <[email-masked]> 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

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 06 Jun 2001 20:34:36 -0700

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

---

From: David Partain <[email-masked]>
Date: Mon, 11 Jun 2001 11:31:05 +0200

Hi all,

Steve Waldbusser wrote, after discussion with others on

> rather than waiting till the next policyFilterMaxLatency time.

So, if such text is added in the "policy table logic", would
folks be happy?  I would be.

Cheers,

dlp

---

From: Jon Saperia <[email-masked]>
Date: Mon, 11 Jun 2001 08:34:31 -0400

> folks be happy?  I would be.
Good solution.
Thanks,
/jon
--

---

From: Steve Moulton <[email-masked]>
Date: Mon, 11 Jun 2001 10:16:52 -0400

> folks be happy?  I would be.

This resolves the implementation ambiguity that concerned me.

I'm happy.

	-s

---

---

From: Matt White <[email-masked]>
Date: Wed, 20 Jun 2001 07:00:55 -0400

Sounds good to me.

-Matt

---

From: Matt White <[email-masked]>
Date: Wed, 20 Jun 2001 07:05:36 -0400

There's always the ever-popular method of adding a flag to the policy.  All 
you really need is a "re-evaluate this policy group when this policy 
becomes inactive".

-Matt

---

From: Matt White <[email-masked]>
Date: Wed, 20 Jun 2001 07:12:01 -0400

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.

-Matt

---

From: Jon Saperia <[email-masked]>
Date: Fri, 22 Jun 2001 08:02:36 -0400

I am happy with the text. I appreciate the concerns about security but not all 
policies will have trumped a lower precedence policy. I am concerned that we 
could over-engineer this.

/jon

Thanks,
/jon
--