Subject: Policy framework requirements

From: "Hugh F. Mahon" <[email-masked]>
Date: Thu, 24 Jun 1999 12:44:21 MDT

Hi Folks,

Within this working group there have been a lot of discussions of what 
kind of policy information is needed, and there's been a lot of work on 
schema for policy information.  There has also been a lot of discussion 
of how that information is to be used, and how it is shared.

Each of the participants has had in mind a model for how things work, 
but we rarely discuss this aspect of policy management.  If we are to 
indeed develop standards around which we can have interoperable policy 
management tools we need to have discussions of how these mechanisms 
will work together.

I am specifically not talking about how a UI looks or how policy is 
verified to be usable.  

I am talking about how policy gets from the administrator to where it 
is actually used, what the administrator (customer) expects from the 
policy management system, and the minimum pieces necessary to provide 
a functional system.  Without this understanding I do not see how we 
can define schema and how it is to be used that allows true 
interoperability (or value to customers).

To begin the discussion I've put together a simple description of what 
an administrator would do and expect.  The purpose is to drive toward 
common understanding and help in determining the solutions (or even 
allow us to choose which things to solve and what not to solve).

The Scenario
------------

An administrator must author policy.  This can be done either from 
scratch or using existing policies (either editing existing policies 
or copying them and using them for creating new policies).  Once new 
policies have been authored, the administrator must associate them 
with the managed entities the policies are to affect.  The 
administrator can either 'just know' to what policies can be 
associated, or a list can be presented.  There are other reasons that 
such a list would be valuable in the management system (see below).

Because policy can be complex, or have information the administrator 
may wish to track over time, it would be valuable to allow versioning 
of policy information, that is, earlier versions of policy information 
would be stored.  This versioning allows administrators to make 
changes without fear that valuable information will be irretrievably 
lost.  One example of this value is being able to quickly roll-back to 
a previous version of policy if the new policy is found to be 
incorrect. 

Once the policy has been created or edited by the administrator, it 
should be stored in a repository.  (Note that it is this repository 
that has been the focus of much of the group's discussions and is 
viewed as the central interoperability point.)  The managed entity 
should then receive the policy in a timely fashion and implement the 
policy.  Once the policy has been implemented on the managed entity 
the administrator should be notified of the status of the policy 
deployment: success, success with warnings, or failure (with the 
reason(s) for the failure).  This is an area where the list of managed 
entities would provide value: a place to associate status information 
about policy on those managed entities. 

Administrator Expectations
--------------------------

For example, if a network is experiencing poor performance, the 
administrator may choose to change policy.  Say a new tool for 
receiving news has been introduced, and it is using significant 
amounts of bandwidth.  We'll call it NewTool.  The administrator 
cannot stop all users from using NewTool, but can manage the QoS for 
the traffic it generates.  To improve the performance of other 
applications the administrator chooses to reduce the priority of 
NewTool.  Customers are clamoring for improved performance, so the 
administrator would like the changes to take effect immediately.  It 
is not desirable to wait an hour for all of the affected devices to 
query a central repository and learn that new policy exists.   Neither 
is it desirable to have each of the managed entities generating 
extraneous traffic to check for policy changes, adding a further 
burden to the already overworked network. 

In addition, the administrator wants to be notified as soon as the 
policy is in place on each of the affected managed entities.  Without 
such feedback, the administrator is not in control of the environment 
but at the mercy of the policy management system.

The Requirements
----------------

Based on the simple scenario described above, the requirements for a 
policy management system should include:

          - storage of policy information        
          - storage of information about managed entities 
          - an association between policies and what they are to manage
          - timely asynchronous notification of new/changed policy 
            information
          - ability to provide feedback to administrator of policy 
            status at managed entity
          - transactional qualities (the administrator can determine 
            that the changes were the result of a specific 
            administrator action)
          - definition of how policy information is to be used on 
            managed entities (e.g., how many actions are performed for 
            any event, etc.)
          - ensure that policies put in directory are what is read by 
            the PDP/interpreter

LDAP (and directories accessed by LDAP) can't do all of these things, 
at least not as it exists today (or in the near future).  Other 
mechanisms need to be in place to supplement LDAP's capabilities.

I agree with the Area Directors' concerns about adding more to the 
Working Group's tasks before the WG achieves its initial goals (i.e., 
a schema), but I can't help but feel that we will miss important 
things if we don't discuss how all of this is supposed to work.  We 
don't have to define all of it before we get some pieces firmed up, 
but we do need to discuss these other aspects more before we can call 
anything done or ready for use.

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

---

From: Andrew Smith <[email-masked]>
Date: Fri, 25 Jun 1999 18:14:53 -0700

I think that's a good start to defining the problem at a high level - I'd
recommend that we try to merge Hugh's description in to the policy framework
draft somewhere.

Andrew

> -----Original Message-----
> From: Hugh F. Mahon [mailto:[email-masked]]
> Sent: Thursday, June 24, 1999 11:44 AM
> To: [email-masked]
> Subject: Policy framework requirements
> 
> 
> Hi Folks,
>

---

From: Francis Reichmeyer -NJ <[email-masked]>
Date: Fri, 25 Jun 1999 22:56:43 -0400

-----Original Message-----
From: Andrew Smith [mailto:[email-masked]]
Sent: Friday, June 25, 1999 9:15 PM
To: [email-masked]
Subject: RE: Policy framework requirements

	[franr] And which policy framework draft would that be? :^)

Andrew

-Fran