Subject: RE: Policy issues: definition of Roles

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 26 Jan 2000 11:07:53 -0500

Jon,

To answer your question, Roles were first proposed in the context of PIBS.
In this context, a PIB row, or subset thereof, was associated with a group
of one or more services/components. In this context definition 2 is
perfectly reasonable because a PIB row is always unambiguous, even if it is
applied to a set of instances. In policy, this concept (and definition 2)
was inherited. However, attributes that will not be part of the same PIB row
will often coexist in the same policy. As I said in my first message, I
noticed this confusion during discussions with other folks at the last IETF.

regards,

-Walter

> -----Original Message-----
> From: Jon Sjoberg [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2000 8:46 PM
> To: [email-masked]
> Subject: RE: Policy issues: definition of Roles
> 
> 
> Not to seem too ignorant, but where did these definitions 
> come from?  There
> is a definition of roles in "Policy Framework Core 
> Information Model --
> Version 1 Specification", section 5.2, which I can't quite 
> match to either
> of the E-mailed definitions.
> 
> In this draft a role is defined as:
> "a policy administrator assigns each resource to one or more 
> roles, and then
> specifies the policies for each of these roles."
> 
> Then, further on, this draft states:
> "Roles are represented in the Core Policy Schema by values of 
> the Policy
> Keywords property."
> 
> Of which, section 6.1.2 further enumerates to be:
> "This document defines the following keywords:  "UNKNOWN", 
> "CONFIGURATION",
> "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and
> "EVENT"."
> 
> The best I can see is if we take definition number 1, and 
> generalize it out
> several orders, we sorta match the PFCIM definition.  Any 
> insight to help
> me?
> 
> Thanks,
> Jon
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Weiss, Walter
> Sent: Tuesday, January 25, 2000 11:08 AM
> To: [email-masked]
> Subject: Policy issues: definition of Roles
> 
> 
> At the last IETF, numerous conversations resulted in a number 
> of new issues
> that deserve discussion and consensus. I would like to start 
> addressing
> these issues from easiest to hardest with a desire to have 
> them all resolved
> prior to the next meeting. My intent is to serialize these 
> discussions to
> give each topic a fair hearing. However, if we run out of 
> time, I will start
> initiating parallel threads.
> 
> The first issue is one I eluded to in my presentation. There 
> are apparently
> two definitions for Role:
> 
> 1. A role is a list of targets for a policy to be applied to. In other
> words, if the policy conditions and actions describe some 
> interaction with
> or within an interface, the role lists the interfaces that 
> the policy is
> applicable to. If the policy describes some OSPF related 
> rules, then the
> role is the list of OSPF instances. This definition is more 
> applicable to
> how policies are distributed
> 
> 2. A role describes the binding between the set of attributes 
> used in a
> policy and the actual attributes that exist in a device or 
> service. For
> example, a policy that prevents new flows when total 
> bandwidth for that flow
> type exceeds 30% of all traffic, may need an explicit binding of the
> bandwidth counter attribute and the flow type definition to a 
> particular
> instance of a queue. This definition speaks more to how a policy is
> interpreted.
> 
> My take is that these two definitions are nearly the same. 
> However, if a
> role is assumed to be associated with the rule, I would be 
> inclined to favor
> definition 1. The reason is that I anticipate the possibility 
> of policy
> rules that either interact with multiple instances of the 
> same time (If Gold
> Traffic exceeds a threshold, lower bandwidth allocation for 
> Silver Service)
> or transcend service domains (When a new DHCP accounting user 
> is validated
> install a packet filter granting access to the accounting 
> network). In the
> first example a role listing the queues/services to which 
> this policy is
> applicable is reasonable. However, a role binding of the rule to a
> particular set of queues/services is ambiguous because the 
> gold service
> queue and the silver service queue would each interpret the 
> rule as "If MY
> traffic exceeds this threshold reduce MY bandwidth." What we 
> really want is
> "If MY  traffic exceeds this threshold reduce the OTHER 
> bandwidth." In the
> second example, according to definition 1 of role, the policy 
> server would
> determine that the role is applicable to the DHCP service and 
> the filters on
> edge interfaces of the accounting network. Under definition 
> 2, the attribute
> binding is confusing because the DHCP service has no packet forwarding
> service and the routers don't (usually) have a DHCP service. 
> Therefore a
> subset of the attributes are ambiguous. The only way to 
> disambiguate this
> type of rule is to qualify the attribute: 
> DHCPService.NewUserAddress and
> AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute
> qualification, the value of roles under definition 2 seems almost
> irrelevant.
> 
> Comments?
> 
> regards,
> 
> -Walter
> 
> 
>

---

From: "Jon Sjoberg" <[email-masked]>
Date: Wed, 26 Jan 2000 11:22:21 -0500

So the term "role" which you wished to get clarified is separate from the
term "role" defined in the PFCIM document, correct?

If these terms are different we should probably get the terms altered a bit
to remove yet a third point of confusion from your list.

If these terms are the same would you mind holding my hand a little to show
me how they are the same?

Thanks,
Jon

> From: Weiss, Walter [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2000 11:08 AM
> To: 'Jon Sjoberg'; [email-masked]