Subject: Re: Policy issues: definition of Roles

From: "Bert Wijnen" <[email-masked]>
Date: Tue, 1 Feb 00 11:23:05 CET

Let me suggest a procedure so we do not get all these cross postings.
As you can see, I post to one list at a time, so that the REPLY
button that some people use do not automatically cross post too.

As you can see from the subject line, this topic (I think)
should be discussed on the POLICY wg mailing list and not be cross
posted to a set of other lists.

The issue there has to do with the defenition of that term in
the core info model document that is currently in WG last call
in the Policy WG.

If you want to join the discussion, then you should subscribe and
post to the policy wg mailing list: [email-masked], normal
majordomo subscription mechanism I believe.

After the POLICY wg list has agreed on how they want to define the
term, then they might want to post their viewpoint to polterm
mailing list so that any other viewpoints that were not yet
considered can be discussed as well. After that, it may be a term
that the Polterm DT (Design Team) may include in their terminology
document.

Bert

---

From: [email-masked]
Date: Thu, 3 Feb 2000 08:58:30 -0500

It's occurred to me as I've watched the *lengthy* series of notes
on this topic, that PolicyKeywords may be just a bit too lean to
capture all that we want to capture about roles and role
combinations.  Recall that PolicyKeywords is already doing two
(really, three) jobs in the PCIM:

  - returning architected values representing the policy
    categories listed in section 2 of the document;
  - returning the special architected value "POLICY" for the
    benefit of those implementations that don't return class
    information correctly - this is the third job I alluded to;
  - returning installation-specific keywords that an administrator
    might define to help get the right policies to the right PDPs.

For all of these uses, there are implicit OR semantics:  policies
are flagged with individual keywords, and a policy qualifies as
flagged so long as the flagging keyword appears somewhere in its
PolicyKeywords list.

Given these semantics, we're going to need something other than
PolicyKeywords to represent roles / role combinations *if* we
want role combinations to work the same way on the "hop" between
the Policy Repository and the PDP as they do on the "hop" between
the PDP and the PEP.  Here's a possible solution:

1. Define a new multivalued property PolicyRoles, either in the
   abstract class Policy, or in its subclass PolicyRule.

2. The semantics for this property would state that each value
   identifies a role combination, i.e., a set of one or more
   role names that are ANDed together to form a single selector.
   This could be accomplished with a string syntax of the form

     <RoleName>[&&<RoleName>]*

   where the individual role names must appear in alphabetical
   order (according to whatever collating sequence the IETF would
   like us to use) to make the string matches work correctly.

3. The multiple values for PolicyRoles would be logically ORed,
   to allow a policy to be associated with multiple independent
   roles / role combinations.

4. Individual role names would be installation-specific, i.e.,
   assigned by an administrator.  It's tempting to try to define
   a "starter set" of role names in the PCIM, but I think we'll
   always have to leave the door open for installation-specific
   ones as well.  Given that this is the case, it's simpler just
   to say that they're all installation-specific.

What do people think?  Since we're attaching so much significance
to them, I like the idea of moving roles out of the generic
PolicyKeywords bucket.  Does this sound like something we should
add to the PCIM?

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: "John C. Strassner" <[email-masked]>
Date: Sun, 06 Feb 2000 17:36:51 -0800

<walter wrote:>
In the original posting, my main concern was that the policy rules, and more
precisely the attributes within policy rules, eventually have to be bound to
some physical attribute somewhere in order to effect changes in network
devices or services. Specifying keywords is not enough. We should also
document how an attribute actually maps to given instances of that attribute
in an interface, queue or whatever.
</walter>

I would humbly submit that this issue, though important, is orthogonal to 
roles. See my earlier posting. This is a binding issue, and affects not 
just roles (which are, after all, attributes) but other types of attributes 
as well.

regards,
John

At 01:36 PM 1/31/00 -0500, Weiss, Walter wrote:
>Jon,
>
>Since my posting, the intent of Roles (in the form of keywords and keyword
>combinations) has become clearer to me. With role combinations, I can create
>policies that cross domains. That said, I wanted to draw attention to the
>text because it was too vague for me to understand what the intent was.
>
>It seems that the definition of Roles that PCIM authors had in mind is a bit
>more high level then what I was thinking of. I don't have any problem with
>grouping policies together based on some keyword. These are fairly abstract
>concepts that I could easily see  as useful for policy conflicts. However, I
>have not seen the rubber hit the road yet.
>
>In the original posting, my main concern was that the policy rules, and more
>precisely the attributes within policy rules, eventually have to be bound to
>some physical attribute somewhere in order to effect changes in network
>devices or services. Specifying keywords is not enough. We should also
>document how an attribute actually maps to given instances of that attribute
>in an interface, queue or whatever. We could use the role keyword as a way
>of indicating which set of interfaces or queues we would like the policy to
>apply to, but then we need a mechanism to bind the keyword to that set. If
>that is the approach taken, then we still have attribute qualifiers to deal
>with, but at least I know how I can use Role Keys beyond conflict detection.
>
>As a side note, we are spending a considerable amount of time focused on
>device interfaces. I would like to remind folks that the purpose of this
>working group is to come up with a framework that can not only be applied to
>QoS components in forwarding engines, but also other problem domains.
>Security policies, Address management policies, and Routing policies have
>little if anything to do with interfaces. While I am comfortable with
>focusing on QoS (as per our charter), I would like to make sure that we
>don't make assumptions about how and where policy will be used.
>
>regards,
>
>-Walter
>
> > -----Original Message-----
> > From: Jon Sjoberg [mailto:[email-masked]]
> > Sent: Sunday, January 30, 2000 9:08 AM
> > To: Weiss, Walter
> > Cc: [email-masked]
> > Subject: RE: Policy issues: definition of Roles
> >
> >
> > Walter,
> >
> > > <PCIM>
> > > The Policy Framework is then responsible for configuring
> > > each of the resources associated with a role in such a way that it
> > > behaves according to the policies specified for that role.
> > > </PCIM>
> > >
> > > First, there is a reference to resources without any context.
> > > Second, I find
> > > policies that can only operate within the confines of a
> > > particular resource
> > > unnecessarily restrictive.
> > >
> > I don't understand where the second point is derived from.  I
> > guess I read
> > the text to say that policies are confined within a specific
> > role.  It seems
> > that policies, in the general sense, can operate across
> > resource and role
> > boundaries.  Each policy rule that enacts a policy must be restricted,
> > however, to a role.  It would be easier, from a PDP/PEP
> > implementation stand
> > point, to restrict each policy rule down to a resource (and
> > make the policy
> > management tool do all the REAL work).
> >
> > >
> > > <PCIM>
> > > Roles are represented in the Core Policy Schema by values of the
> > > PolicyKeywords property.
> > > </PCIM>
> > >
> > > I found this text to be even more confusing because it
> > supported a third
> > > concept not defined in either of the two concepts I described: an
> > > arbitrary
> > > grouping based on a keyword possibly bound to a technology
> > like QoS or
> > > security, or an organization like engineering, or something else???
> > >
> > Actually the possible current values are enumerated in 6.1.2,
> > and the values
> > fall into the "something else" category.  If I read
> > correctly, the standard
> > possible values are:
> > UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE",
> > "MOTIVATIONAL",
> > "INSTALLATION", and "EVENT".  I am not sure I fully understand many of
> > these, though the document does explain them.  Anyway, it is
> > clearly another
> > definition of role not akin to your two or, best I can tell,
> > Shai's newest
> > proposal.
> >
> >
> >

---

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 10 Feb 2000 16:02:53 -0500

I noticed that roles have been described in PFCIM through the PolicyKeywords
attribute in the Policy class. As PolicyGroup, PolicyRule, PolicyCondition
and PolicyAction both derive from Policy, all of these classes can specify
PolicyKeywords. This suggests that rather than having a role per
policy/rule, you can have keywords at any and all levels of a policy. Is
this desirable or are we going to place certain usage restrictions or
precedence hierarchies on the keywords/roles?

regards,

-Walter

---

From: [email-masked]
Date: Fri, 11 Feb 2000 07:58:41 -0500

Walter,

In an earlier posting I proposed separating Policy Roles out from
the more general set of Policy Keywords.  At that time I left it
open where the PolicyRoles property should be placed:  in the
abstract class Policy (which is where PolicyKeywords is now), or
in the class PolicyRule.  I'm now convinced that PolicyRoles should
be placed in PolicyRule, rather than in Policy, because the function
of PolicyRoles is to (help) select the set of PolicyRules that apply
to a given resource.  Contrast this function with that of the
PolicyKeywords property, which is to identify any object in the
policy repository that might be of interest to a PDP that's
searching the repository.

I'm planning to write up a new section for the PCIM describing the
PolicyRoles property, which I will post to the list as soon as I've
completed it.  Then people can decide whether it makes sense.  John
is going to be taking a shot at a section positioning this type of
role versus, say, the roles that are used in COPS.  I don't know
whether he's planning to proposed a set of adjectives to distinguish
the different types of roles, although this has certainly been
discussed on the list.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

"Weiss, Walter" <[email-masked]>@raleigh.ibm.com on 02/10/2000
04:02:53 PM

Please respond to "Weiss, Walter" <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: Policy issues: definition of Roles

I noticed that roles have been described in PFCIM through the
PolicyKeywords

regards,

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 11 Feb 2000 12:05:09 -0500

Bob,

I think this is an excellent idea. However, I believe another problem
arrises. Let's consider two policy rules. In one policy rule, let's suppose
we are trying to limit engineering traffic to some arbitrary level/rate.
This policy rule would presumably have two roles: Engineering Interface and
Edge Interface. I believe the presumption is that the policy rule can only
be applied if both roles are satisfied.

Now, let's suppose the second policy is designed to facilitate a network
login by preventing access to the network until the appropriate IP address
has been given by the DHCP server. Thus when the IP address is assigned, the
policy adds or removes the filter (as the case may be) to allow access to
certain parts of the network based on the identity of the new user. Now,
here I am trying to make a feable attempt at describing a policy that
crosses two technology domains. Presumably, because we are crossing two
domains, the roles need to represent both domains so that the policy (or
portions of the policy) can be distributed (or processed on behalf of) the
DHCP server and the router managing the filter. Hence, the role for the
policy rule would presumably be DHCP and EndUserInterface.

Now, in the first policy example, we only processed the policy rule on
behalf of devices that satisfied both role criteria (a logical AND of the
roles). In the second policy rule, we want to process the policy for either
role (a logical OR of the roles). If we go with a AND semantic or we go with
an OR semantic seems to cause problems.

regards,

-Walter

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 11, 2000 7:59 AM
> To: Weiss, Walter
> Cc: [email-masked]; [email-masked]

---

From: [email-masked]
Date: Fri, 11 Feb 2000 13:19:59 -0500

Walter,

Let me see how far I can get with your cases before I get into
trouble:

CASE 1:

PolicyRule 1
  PolicyKeywords {TrafficManagement, Engineering, ByWalter}
  PolicyRoles {EdgeIntf&&EngineeringIntf} -- role combination

CASE 2:

PolicyGroup A
  PolicyKeywords {DHCP, UserAccess, ByWalter}
  -- contains two PolicyRules A1 and A2

PolicyRule A1
  PolicyKeywords {DHCP, UserAccess, ByWalter}
  PolicyRoles {DHCP}

PolicyRule A2
  PolicyKeywords {DHCP, UserAccess, ByWalter}
  PolicyRoles {EndUserIntf}

I've represented your second "policy" as a PolicyGroup rather
than a PolicyRule, because it seems like there would be nothing
in common between the conditions / actions for the DHCP server
and the subsequent conditions / actions for the router.
Because of this, each of the rules has only a single value in
its PolicyRoles.  The property itself, however, is multivalued,
so in a different case it could have multiple valued which
would be ORed, say

  PolicyRoles {EndUserIntf, EdgeIntf}.

What's left unspecified here is the "magic" that gets you from
an event at the DHCP server (the user gets an IP address) to
events at the routers (this IP address gets added to their
filters).  I don't think this magic has anything to do with
the PolicyRoles property, though.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

"Weiss, Walter" <[email-masked]> on 02/11/2000 12:05:09 PM

To:   Robert Moore/Raleigh/IBM@IBMUS
cc:   [email-masked], [email-masked]
Subject:  RE: Policy issues: definition of Roles

Bob,

has been given by the DHCP server. Thus when the IP address is assigned,
the

role (a logical OR of the roles). If we go with a AND semantic or we go
with

regards,

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 11 Feb 2000 14:14:00 -0500

Bob, 

>   PolicyRoles {EdgeIntf&&EngineeringIntf} -- role combination
This is fine.

>   PolicyRoles {EndUserIntf, EdgeIntf}.
I don't think so. The fact of the matter is that the condition is in the
DHCP server and the action is in the router. Therefore, DHCP and
EndUserInterface do in fact exist within the same rule. Again, if you are
going to suggest that policy rules can't operate across technologies as your
example implies, then it is fair to say that this is a limitation of your
proposal. We can then discuss if this is reasonable or not. As I have
suggested before, I think it is not. I can think of many instances of
policies where it would be desirable to have a condition in one system
(whether it is a server like DHCP or a software element like BGP) invoke
actions in one or more other systems.

---

From: "John C. Strassner" <[email-masked]>
Date: Fri, 11 Feb 2000 21:13:16 -0800

Comments inline. You argue that CASE 1 below demands AND semantics and CASE 
2 below demands OR semantics. You further posit that this is the case 
because we are crossing two technology domains, and "...the roles need to 
represent both domains so that the policy (or portions of the policy) can 
be distributed (or processed on behalf of) the DHCP server and the router 
managing the filter".

I disagree. Rather than formulating this problem as one policyRule, why not 
divide it into two separate rules?

regards,
John

At 02:14 PM 2/11/00 -0500, Weiss, Walter wrote:
>EndUserInterface do in fact exist within the same rule.

<js>
Sorry, I disagree. These resolve into completely separate actions. Changing 
ACLs on the router is independent of whether the user gets an IP address, 
since you're probably allocating from a pool as opposed to filtering on an 
individual address. And even if you are filtering on an individual address, 
you have to assume that at some point the user will be allowed a legal IP 
address. So as far as I can tell, you don't have "...a condition in the 
DHCP server and an action in the router"; rather, you have a logon Event 
that generates two actions, one for the DHCP server and one for the router. 
They don't in fact have to be directly associated at all.
</js>

>Again, if you are

<js> No one suggested that. I think that the problem was mal-formed. </js>

---

From: "John C. Strassner" <[email-masked]>
Date: Fri, 11 Feb 2000 21:15:53 -0800

Fair enough. However, the PCIM is an information model. It is not directly 
instantiable, and the binding that you are talking about is relevant to the 
various mappings from the PCIM to their respective repositories. For 
example, if I am mapping to a database, then I can use triggers and stored 
procedures to add constraints and metadata to help me interpret the 
binding. I can't do this when mapping to a directory.

So I think that we should defer this to the next round of specs (e.g., the 
Policy Core Schema Spec), and not deal with it here anymore.

regards,
John

At 03:48 PM 2/11/00 -0500, Weiss, Walter wrote:
>John,
>
>I would agree that this is somewhat unrelated to the concept of roles,
>assuming that roles focus on distribution issues. However, at some point we
>will have to agree on how we can achieve the unambiguous interpretation of
>the policy conditions and actions.
>
>regards,
>
>-Walter
>
> > From: John C. Strassner [mailto:[email-masked]]
> > Sent: Sunday, February 06, 2000 8:37 PM
> > To: Weiss, Walter; 'Jon Sjoberg'

---

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 14 Feb 2000 11:09:08 -0500

John,
 
I think you are suggesting a condition independent of action in one rule and
an action independent of condition in another rule. Since the relationship
between the condition and action is causal, you need some type of binding to
represent this causal relationship. Hence, If <condition> then <Action>.
Hence, if you want to have a condition on a DHCP server influence an action
in one or more routers, you somehow need to indicate this relationship. Two
disjoint rules do not achieve this objective.
 
Perhaps you could ellaborate on how this would work. I do not believe Bob's
approach will work. However, perhaps there are other mechanisms in the model
I am missing.
 
regards,
 
-Walter

Comments inline. You argue that CASE 1 below demands AND semantics and CASE
2 below demands OR semantics. You further posit that this is the case
because we are crossing two technology domains, and "...the roles need to
represent both domains so that the policy (or portions of the policy) can be
distributed (or processed on behalf of) the DHCP server and the router
managing the filter".

regards,
John

Bob, 

This is fine.

<js>
Sorry, I disagree. These resolve into completely separate actions. Changing
ACLs on the router is independent of whether the user gets an IP address,
since you're probably allocating from a pool as opposed to filtering on an
individual address. And even if you are filtering on an individual address,
you have to assume that at some point the user will be allowed a legal IP
address. So as far as I can tell, you don't have "...a condition in the DHCP
server and an action in the router"; rather, you have a logon Event that
generates two actions, one for the DHCP server and one for the router. They
don't in fact have to be directly associated at all.
</js>

Again, if you are

> > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: [email-masked]
Date: Mon, 14 Feb 2000 11:36:52 -0500

Walter,

I want to make sure we're all in agreement about what we're
discussing.  Modeling policies that span two or more technologies,
as well as modeling policies that span two or more systems, are
both Very Hard problems.  But I don't think we have to solve these
problems, or even go very far down the path towards solving them,
in order to determine that the structure I've proposed for the
PolicyRoles property will be able to do the job in these cases.

Do you agree that we're now discussing how to model cross-system
and/or cross-technology policies, not whether PolicyRoles as I've
proposed that it be defined is adequate for these cases?  If so,
is there anything else in the PCIM that needs to be changed in
order to leave us room to address these Very Hard problems later,
in the context of a subclass schema such as QoS?

By the way, I hope you're not saying that we need to have solutions
for these two Very Hard problems *in* the PCIM, and that it can't
be approved without these solutions.  As we can all attest, coming
up with solutions, especially general solutions, to Very Hard
problems ordinarily takes a <Very> Long Time.  So I think the
correct precondition for advancing the PCIM is not that it solve
these problems itself, but rather that it not introduce anything
that makes the problems harder to solve than they would otherwise be.
I think the PCIM passes this second test.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

"Weiss, Walter" <[email-masked]> on 02/14/2000 11:09:08 AM

To:   "'John C. Strassner'" <[email-masked]>, Robert
      Moore/Raleigh/IBM@IBMUS
cc:   [email-masked], [email-masked]
Subject:  RE: Policy issues: definition of Roles

John,

I think you are suggesting a condition independent of action in one rule
and
an action independent of condition in another rule. Since the relationship
between the condition and action is causal, you need some type of binding
to
represent this causal relationship. Hence, If <condition> then <Action>.
Hence, if you want to have a condition on a DHCP server influence an action
in one or more routers, you somehow need to indicate this relationship. Two
disjoint rules do not achieve this objective.

Perhaps you could ellaborate on how this would work. I do not believe Bob's
approach will work. However, perhaps there are other mechanisms in the
model
I am missing.

regards,

-Walter

be

regards,
John

Bob,

This is fine.

<js>
DHCP

Again, if you are
going to suggest that policy rules can't operate across technologies as
your

---

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 14 Feb 2000 17:42:47 -0500

Yoram,

At the begining of this thread, I posited two possible definitions for
Roles. One emphasized distribution issues. The other emphasized consistent
policy interpretation. We seem to have agreed since then that roles are
specified to address distribution issues, with which I agree. This does not
make the other issue go away. However, I have no problem with John's
suggestion to wait with this issue until after PFCIM is out.

regards,

-Walter

> From: Yoram Snir [mailto:[email-masked]]
> Sent: Sunday, February 13, 2000 8:46 AM
> To: 'Weiss, Walter'; 'John C. Strassner'
> Walter
> Wouldn't distribution issues and unambiguous interpretations 
> of policy rules
> (conditions and actions) are 2 different issues?
> The methods used to solve the first issue, Roles for example, 
> is not the
> method to solve consistent decision making (clear priorities, decision
> strategy...).
> Thanks.
> 
> Yoram Snir
> Cisco Systems
> Tel.   972-9-9700085
> Mobile 972-54-970085
> 
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Weiss, Walter
> > Sent: Friday, February 11, 2000 10:48 PM
> > To: 'John C. Strassner'

---

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 14 Feb 2000 18:07:27 -0500

Bob,
> PolicyRoles property will be able to do the job in these cases.
I would agree that these are hard problems given your current approach.
However, I also believe the problem is a fundamental one. Either this model
can support cross technology or cross service rules or it can't. Once we
actually start using policies, I am fairly convinced that the cross service
policies will be more prevalent then the single service policies. Here is
another example. Let's suppose that I have two ports A and B connected to
another router. Port B is a standby port that becomes active when port A
fails. Port C mirrors all traffic arriving on port A. Suppose I want a
policy that says "If port A fails, change the configuration of port C to
start mirroring traffic from port B." In this case, I have another condition
that is bound to one interface and an action bound to a different interface.
 
> in the context of a subclass schema such as QoS?
I think it is rather easy to model the policies, as I hope the last example
demonstrates. What is difficult is modeling the distribution of the
policies. If a policy can only be distributed to a specific service
instance, then it is also only applicable to that service instance.

> I think the PCIM passes this second test.

I don't have a problem with standardizing PCIM without specifying this.
However, I would argue that if you want to avoid this issue, you can simply
state that the current model for describing roles does not support this
cabability.

regards,

-Walter