Subject: RE: policyValidityPeriodCondition

From: "Black, David" <[email-masked]>
Date: Mon, 8 Mar 1999 09:28:04 -0500

Hugh,

> Does this really make a difference with respect to a general definition 
> of policy?  I think it affects what is contained within the policy (the 
> specific kinds of conditions and actions), but WHERE the policy is to 
> be executed does not affect the form of the rule itself.

Actually, I believe Silvano agrees with you on this
point -- I'm the one who's been arguing the other side :-).
Let me try to briefly restate my viewpoint.

IMHO, much of the discussion has been assuming new
policy-aware hardware.  In contrast, I'm interested in how
to apply policy to existing devices that can't speak, spell,
or parse LDAP (among other protocols).  Such devices are
nonetheless configurable, and hence ought to be managed
by overall network policy.  For concreteneess, consider
a device that is configured via a MIB, (yes, this implies SNMPv3).

It seems to me that there are two ways to do this.  As I
understand him, Silvano is advocating an approach where
the PDP selects the rules that apply to a device/PEP at
this time, and then the device carries them out.  That
requires that the entire set of rules (conditions and actions)
be translated/compiled down to the MIB.  I'm concerned about
the opacity of this translation/compilation process (e.g., add
another rule, and suddenly the device balks for reasons that
aren't obvious, perhaps the rule addition implies a classification
complexity that the device can't handle).

The alternative approach that I'd like us to consider starts
from the MIB and works upward to define rule actions that correspond
reasonably directly to the MIB.  This is not a "free lunch",
as it's still possible to write rule action sets that won't
work, but when the device balks, it now balks in terms of
rule actions that correspond to its configuration MIB, and
the mess should be easier to unscramble.  A specific example
is that diff-serv expects to define a MIB, and I think it
behooves us to respect that MIB rather than define  a new
way of configuring diff-serv devices.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------