Subject: Administrator to Target process

From: [email-masked]
Date: Fri, 29 Oct 1999 01:18:50 +0300

Hi,

I have some questions on this sequence in draft-ietf-policy-req: 

   A.   Administrator  authors new policy (or edits existing pol-
        icy)

   B.   Administrator associates policy with Policy Targets.

Wouldn't the policies be associated with roles instead of targets.
With each target having many capabilities each defined by some
role.

   C.   Policy and association with Policy Targets is  stored  in
        repository.

If policies are associated with roles, then wouldn't the repository  
contain policy to role associations and role to target associations.

   D.   For  each  of  the  Policy  Targets, a Policy Consumer is
        notified that new policy is available for the Policy Tar-
        get.

I have some questions on this:  
1. If the target is one which is provisioned as opposed to
one which has an outsourcing PDP is there a need for this
real time notification?  Wouldn't a provisioning consumer be
more likely to pull the policies needed at the right time?
2. Won't this be difficult to do in a scalable way when the policy
is associated with a role associated with a great number of capabilities and
diverse targets? 
3. Is there a requirement that a target always be associated with the same
consumer?  If consumer - target associations are volatile, then how does the
repository know who to broadcast the policy out to?

   E.   The  Policy Consumer obtains the policy.  See below for a
        detailed description of the actions of  the  Policy  Con-
        sumer.

   F.   For each Policy Target which received policy information,
        the Policy Consumer provides status information  back  to
        the  Administrator  about  policy deployment; success, or
        failure and information about the failure.

Should this status be sent back to some intermediate entity (maybe a
repository) so as not to overburden an administrator? 

Regards
a.

-----------------------------------
avri doria
+1 617 678 9402

---

From: Hugh Mahon <[email-masked]>
Date: Fri, 29 Oct 1999 10:29:39 -0600 (MDT)

Hi Avri,

> With each target having many capabilities each defined by some

There are multiple ways to implement roles.  One way is to have roles 
configured on the device.  I have a concern about this implementation 
because it means that the administrator would have to use tools other 
than a Policy Management Application (PMA) to change the 'role' or a 
subset of interfaces with the same 'role' (the network is dynamic, so 
the need to change the policies on a subset of things that were once 
considered equivalent is a very real need).

> contain policy to role associations and role to target associations.

The repository would contain the associations, but when are those 
defined?  The above step (C) simply points out that this association 
must be established before the policy can be used by policy targets.

If roles were defined in terms of a grouping of policy targets the 
view to the administrator would be the same.  If the role were defined 
in terms of targets (or groupings of targets), the administrator 
could change (or add or delete) the members of the role completely 
within the PMA. 

> more likely to pull the policies needed at the right time?

How would a Policy Consumer know that new or changed policy is 
available without notification?  If it must rely on polling either 
there will be a lot more overhead (short polling interval) on the 
repository, network, and PC, or the PC may not notice new policy in a 
timely manner (a long polling interval). 

> is associated with a role associated with a great number of capabilities and

It depends.  There will be a lot of activity if a change involves a 
lot of targets (whether defined by role or as target groups or 
individual targets).  The design must be able to handle such things, 
and try to minimize activity at the core (i.e., PMA) while still 
allowing the configuration of N targets to occur in a timely manner.

> repository know who to broadcast the policy out to?

If the target - consumer relationship is volatile (either provisioned 
or outsourced) how is the consumer to know the current state of the 
target in order to perform the correct provisioning (or render a 
relevent decision)?  A rather stable relationship enables simpler 
design and administration.  (If you have examples that show that a 
volatile target-consumer relationship is simpler I'd be interested in 
learning about them.)

> repository) so as not to overburden an administrator? 

Yes, the wording above is intended to imply that the status goes to 
some intermediate storage, from which the information is then 
presented to the administrator.  I'll make a note to fix the wording 
in the next revision.

> a.

Thanks,

Hugh