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]
---------------------------------------------------

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Thu, 11 Mar 1999 21:10:13 MST

Hi David,

> a device that is configured via a MIB, (yes, this implies SNMPv3).

I have not been assuming new devices.  I have been working on the 
assumption that policies will work on old and new things, whether the 
things are hardware (e.g., routers) or software (e.g., applications).

> complexity that the device can't handle).

For policy to be applicable across multiple devices (one of the 
assumptions I've been working under) such situations could occur.  I 
do believe that such problems in translation can be minimized.  For 
example, the translator will need to be specific to the task, so it 
has some built-in assumptions of how to handle policy for the device.  
If there is a problem with policy, the translator (which I call a 
proxy) should know enough about the device to properly report the 
problem.

It is possible with current devices to create configuration that the 
device cannot handle, or would cause poor performance.  Policy may 
make it easier to go beyond the simple capabilities of a device 
because it is easier to configure via policies.  In this case, the 
administrator can scale back the policy or upgrade or replace the 
device.  No real difference other than an extra layer between the user 
and device (and if policy is implemented properly, better usability).

We could limit policy to what existing devices can support.  I don't 
necessarily think that would be good, though. 

> way of configuring diff-serv devices.

My goal has been to define abstractions of actions, and allow the 
interpretation of the actions to be context specific.  If defined 
carefully, such actions can be used across multiple devices and yield 
consistent behavior across these devices. 

I am interested in keeping reality in mind when discussing what policy 
should look like, but I am also concerned that the general concepts on 
which we build policy standards not be too influenced by any one 
particular use of policy.

> --David

Thanks,

        Hugh Mahon                              |__|     
        Hewlett-Packard Company                 |  |     
        e-mail: [email-masked]                  |\  /|
        Phone: (970) 898-BITS (898-2487)           | \/ |