Re: Slightly higher level policy

["Lee Rafalow" <rafalow@xxxxxxxxxxxxxxx>]

The method used in the policy framework working group is to create an
information model (using UML) to describe the semantics and then derive
implementation from that as needed.  This is what we're doing with the
device-level model and I'd encourage the WG to do the same for any
higher-level models.

The Policy Core Information Model has the capability to have a policy rule
that's not enabled (perhaps named but not yet defined).  The same (or very
similar) action, proposal and transform subclasses can be used to define the
types of service and we can use higher-level conditions and policy roles to
define applicability of the types of service to traffic and endpoints.

Lee

----- Original Message -----
From: "Hilarie Orman" <HORMAN@xxxxxxxxxx>
To: <ipsec-policy@xxxxxxxx>
Sent: Wednesday, November 29, 2000 1:32 PM
Subject: Slightly higher level policy


> I would like to suggest a language-based approach to the problem
> of specifying policy for collections of elements.  This is fairly generic,
> and I'm curious to know if it duplicates other proposed methods.
>
> The idea is that when filling in the attributes of a structure, you
> can specify that some items are named but not yet bound.
> For example, a collection of elements defined with identical
> attributes but differing in their specific IP address would
> use one data structure, but fill in the address as
> "$this_ip_address", which would make it a free variable
> of the element definition.
>
> Each specific element would be defined with a reference
> to the data structure and a specific IP address:
>
> security_gateway(this_ip_address = 192.60.51.3)
>
> There are well-known formal constructs for the binding rules
> and evaluation of such languages.  They seem like a simple
> extension of policy definitions.  Could they be applied usefully
> to the IPSec Policy arena?
>
> Hilarie
>
>