Subject: Policy definition

From: "Hugh F. Mahon" <[email-masked]>
Date: Fri, 12 Mar 1999 14:04:24 MST

Hello All,

        Based on discussions during meetings in Orlando, Research 
Triangle Park, and on the mailing list there is still lack of 
consensus on what policy is.  I think we've been making progress, but 
while talking about other topics.

        We have multiple documents which describe schemas and 
architectures, but without consensus on WHAT policy information 
actually is we continue to debate broad issues.  While these documents 
go into some detail of how to use policy, they leave plenty of room 
for interpretation of what policy information actually is. 

        Each person involved in the discussions has brought with them 
a set of concepts of what constitutes policy.  Even with these 
individual concepts, policy remains a somewhat abstract notion, and 
necessarily so.  Before we can make progress in the working group we 
must have some discussions to provide a common understanding of what 
policy is in the context of this working group.

	I have noticed that I can read a document about policy and in 
viewing it with my definitions agree with the document, but when 
presented with the original authors' concepts find myself in 
disagreement.  It is for this reason that I want to have a discussion 
about the more basic aspects of policy definition. 

        Below is an attempt to provide a tighter definition for 
policy, complete with examples.  The description below is relatively 
short, and for a reason: we need to reach agreement on a few concepts 
before going further.  If more information is needed before we can 
reach agreement then I will be happy to write more (other participants 
are welcome!).

        If there is agreement that such information is valuable, and 
we can agree on the definition(s), it can be put in the proper form 
and submitted as an Internet Draft.  

        I do believe that there is value in providing a definition 
separate from the schema and architecture documents.  Such a 
definition could be rolled into draft-strassner-policy-terms-00.txt or 
be a separate document.

        Therefore, I not only encourage, but request questions, 
feedback, and suggestions.

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

Why Policy? 

The information used to manage the networked computing environment is 
defined at multiple levels.  At the highest level there are Service 
Level Agreements (SLAs) which describe services provided to customers, 
both in qualitative and quantitative measures.  At the lowest level of 
information is the device configuration information which is specific 
to each device, which describes how and what the device is to do on 
the network.

For completeness it should be noted that even the terms SLA and device 
configuration are hard to precisely describe, since the kinds of 
information within SLAs and even device configuration varies from one 
usage to another.

Between SLAs and device configuration there are Service Level 
Objectives (SLOs), which provide a set of measures to determine 
whether or not a given SLA is being met.  There are usually many SLOs 
for any given SLA.

One of the objectives noted at the first meeting of the Policy 
Framework Working Group was to use policies to manage the network, not 
just individual devices on the network.  In order to achieve this goal 
the information contained in policies must be at a higher level than 
device configuration information.  To be more specific about the 
requirement, policy information must be able to be used across 
multiple devices and describe an aggregate behavior.

Policy Definition

Policy is a specification of behaviors or actions to be taken in the 
managed environment.  Policies may be reactive (require an external 
event to trigger them) or may be proactive (e.g., policies are invoked 
as a consequence of time information within the policy itself). 

Further, policies may be used to cause configuration, or may be 
operated on dynamically.  How the policy is used is dependent on the 
context of where it is used.  

For example, a security policy which specifies that user Joe is 
allowed access may cause a record for Joe to be created in a system's 
login file (configuration usage), while the same policy may be 
referenced when the user attempts to pass through a firewall (dynamic 
usage). 

What is a Policy?

The Policy Framework WG is chartered to develop a general framework 
for policy, but in order to allow a discussion of the requirements for 
the framework it is necessary to discuss examples of what policy is 
used for.  The following is not intended to describe the results of 
the working group, but rather to provide a setting in which to pursue 
the tasks of the working group.

Policy is a set containing one or more actions with one or more 
conditions determining access to that action.  This set is called a 
Policy Rule. 

Actions are an abstraction to allow description of control, functions, 
operations, and provisioning.  Control would include things such as 
'access'.  Functions would include things such as 'events'.  
Operations would include automated actions.  Provisioning would 
include configuration of an operation on a device or software entity.  

The contents of the action section are specific to how the policy is 
being used, and the conditions would be relevant to the contents of 
the action section.

For example, for policies used in measurement, the rule could be 
something like:

        (usergroup == mktg) && (diskusage > 8000000bytes)

to monitor disk usage by members of a user group, and the action could 
be an invocation of a script, like so:

        invoke mktg_user_disk_exceeded_notify

which would be a script written by the IT administrator to perform a 
set of functions in the case of this particular threshold being crossed.

For access control, a policy may simply be used to specify 'access' or 
'deny' given the result of evaluating the rule.  The following example 
would be used in an environment where the default action (the action 
taken after all the rules in the policies have evaluated false) would 
be to allow access:

        action:     access deny 
        condition:  (usergroup == shift1) && (!timerange 0800 to 1700)

The same policy for an environment that by default denied access would 
be:

        action:     access allow 
        condition:  (usergroup == shift1) && (timerange 0800 to 1700)

The above access policies could be used on firewalls, file servers, 
DHCP servers, etc. 

For network Quality of Service (QoS), a policy could look like the 
following:

        action:     priority=4 
        condition:  (usergroup == eng) && (TCPport == 80)

Such a policy could be used in a Bandwidth Broker to provide 
information in response to a real-time request, or could be used to 
provision a router or trafficshaper.  

Acknowledgements

        This is a complex topic.  John and Ed's original paper,  
"Terminology for describing network policy and services", 
draft-strassner-policy-terms-00.txt, August 1998, provides a basis for 
discussion, but further definition seems to be required.

	Raju Rajan and Sanjay Kamat provide additional definition in 
their document, draft-rajan-kamat-policy-arch-proposal-00.txt .  I 
think there is still room for interpretation in their document which 
will not allow us to agree.  Please note that I am not disagreeing 
with their text.  

        Silvano Gai and David Black have been raising valuable points 
in the mailing list about conditions and their use within policies.