Subject: Re: Policy issues: definition of Roles

From: Keith McCloghrie <[email-masked]>
Date: Tue, 1 Feb 2000 00:39:07 -0800 (PST)

> [js] A role-combination is a set of attribute that are used
>       to select one or more policies for a set of entities
>       and/or components from among a much larger set of
>       available policies. The selection process is equivalent
>       to a logical ANDing of each attribute, such that the
>       set of policies that are selected are defined by the
>       intersection of all roles in the role-combination.
> 
> Note that you and Glenn are questioning the use of the logical AND as the 
> selection process, and that in a previous message I've said that I'm ok in 
> defining other types of selection processes, but want to hear from Keith, 
> Michael and Shai (at least) first. If we did want to do that, then we 
> probably need at least an associated attribute that defines how the 
> selection process for the role combination is done.

I believe conflict detection is hard, and I believe that operator
input is required to resolve detected conflicts.  Therefore, conflicts
need to be detected as early as possible.

Consider four types of scenarios where roles are specified:

1. policies entered by an operator are associated with roles.

2. policies stored in a repository are associated with roles, and
   valid role-combinations are stored in a repository,

3. a PEP communicates with a PDP to obtain policies based on its
   role-combinations,

4. a device/entity needs to be configured with the roles that it has,
   and the roles that its components have.

Any or no use of role-combination in #4 is OK by me.

It's #3 where requiring the role-combination to be the logical AND of
all a component's roles provides the ability to detect conflicts prior
to downloading the policies into a PEP.  A PEP may not be able to
detect all conflicts, and those that it does detect are harder to get
resolved because they are detected at run-time when there's no
convenient operator around to supply the resolution.

We are not standardizing #1, and so anybody can do what they like there.

If Bob/Glenn are asking for more flexibility in how policies are
associated with roles in #2, that's fine with me providing the valid
role-combinations are also specified.  For example, suppose four roles
are defined: A, B, C and D, and three valid role-combinations are
defined: A+C, A+B+C and A+B+D; then I have no problem with a policy
being defined for A+B; thereby, that policy is not associated with A+C,
but is associated with A+B+C and A+B+D.  In this example, I don't
consider A+B to be a "role-combination", although perhaps that is what
Bob has been suggesting ??

Keith.

---

From: Bob Natale <[email-masked]>
Date: Tue, 01 Feb 2000 08:50:56 -0500

At 2/1/2000:03:39 AM, Keith McCloghrie wrote:

Hi Keith,

><...>
>defined: A+C, A+B+C and A+B+D;

Note that you refer to them here as "three valid role-combinations".

>then I have no problem with a policy being defined for A+B;

Excellent...that is what I was trying to understand.

>thereby, that policy is not associated with A+C, but is associated
>with A+B+C and A+B+D.

Exactly.

>In this example, I don't consider A+B to be a "role-combination",

You did refer to it as such (above)...in any case, what term
would you use to refer to it then?

>although perhaps that is what Bob has been suggesting ??

Yes, precisely that.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

---

From: "Glenn Waters" <[email-masked]>
Date: Tue, 1 Feb 2000 17:30:36 -0500

Keith, thanks for the reply. However I am still confused about the intent of
roles and role-combinations. First, let me say that at this point I am not
asking for more flexibility - I am still trying to understand the intent of
all this stuff.  Why don't I try an example or two and see if I can point
out where the confusions still lie.

Let's assume we have three policies, P1, P2, and P3 and that we have four
roles Ethernet, TokenRing, Engineering, and John (cause we all know that
John gets gold :) ).

I believe that I can associate one or more roles to a policy, so for
example:

P1 <-- Ethernet, TokenRing;
	P2 <-- Engineering;
	P3 <-- John

So, first I am assuming that you associate roles with policies. Correct?
Second, I am assuming that you can associate more than one role with a
policy. Correct?
Third, none of the above examples has anything to do with role combinations
at this point. Correct?
Fourth, can you associate a role-combination with a policy? I don't know. I
have heard both yes and no on this thread.

Now, on the fourth point you (Keith) suggest that we should model the
role-combinations but not associate the role-combinations with a policy. You
say "2. policies stored in a repository are associated with roles, and
   valid role-combinations are stored in a repository,"  which implies to me
that role-combinations are only stored and are not associated with policies.

So far I have just shown what is in the repository. Now to continue on with
the example let's add a COPS-PR client and policy server to the picture.
Let's say the COPS-PR client connects to the server and reports the
following role-combinations:

	Ethernet+Engineering, TokenRing+Engineering, and Ethernet+John

One could say that for each role-combination you send any policy that
contains any one of the roles in the role-combination. So for example the
following would be sent for the three role-combinations:

	A+B sends P1, P2 since P1 contains A/B and P2 contains B
	B+C sends P1, P2 since P1 contains B  and P2 contains B/C
	A+D sends P1, P3 since P1 contains A and P3 contains D

Now, one problem with this (as Keith says, and I agree) is that conflict
detection is done in the policy server and an operator is not there to
correct a conflict when it occurs.  The advantage of the above approach is
that the administrator does not need to know a priori what all the role
combinations will be.

Further, to the above, Keith suggests that we model the role combinations in
the repository so that we can combine the policies and the administrator can
look for the conflicts before an attempt is made to send the combined
policies to the COPS-PR client.

Now I have seen on this list alternative interpretations of
role-combination. I don't think I have seen consensus.

So, what did I get right and what did I get wrong in this scenario.

Thanks in advance!

Cheers, /gww

---
Glenn Waters, Nortel Networks, Ottawa ON, Canada

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Keith McCloghrie
Sent: February 1, 2000 03:39
To: [email-masked]
Cc: Bob Natale; [email-masked]
Subject: Re: Policy issues: definition of Roles

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 2 Feb 2000 01:01:43 -0800 (PST)

Glenn,
 
> So, first I am assuming that you associate roles with policies. Correct?

Right.

> Second, I am assuming that you can associate more than one role with a

I'll agree with this.  (Note there is an alternate view of having multiple
identical policies, each of which is associated with a different role).

Also note that you can associate a role with more than one policy, and
so, given your statement ("associate more than one role with a policy"),
the relationship between role and policy is many-to-many, and thus, it
cannot be stated that "a policy contains a role", as you do later.

> Third, none of the above examples has anything to do with role combinations

Right.

> have heard both yes and no on this thread.

In my view: not directly; only indirectly through the roles contained
within the role combination.

> that role-combinations are only stored and are not associated with policies.

Not directly; only indirectly through the roles contained within the role
combination.

> 	A+D sends P1, P3 since P1 contains A and P3 contains D

While this looks OK, I cannot say for sure because I'm not certain how you
define A, B, C and D.

> detection is done in the policy server and an operator is not there to

Do you mean "... in the policy server, rather than in the PEP where an
operator ..." ?

> So, what did I get right and what did I get wrong in this scenario.

Just about everything, in my view :-).

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 2 Feb 2000 01:28:22 -0800 (PST)

So, we agree on the concepts, but not on their names.

I agree that A+B is a combination of roles.  What you want to call
"role-combination" is a superset of my definition.  Perhaps, what I
call a role-combination could be called a "PEP role-combination",
whereas A+B is only a "PDP role-combination", where the set of "PDP
role-combinations" is a superset of the set of "PEP role-combinations".

Keith.

> Note that you refer to them here as "three valid role-combinations".
 
Yes, and note that A+B is not one of them.

---

From: "Jon Sjoberg" <[email-masked]>
Date: Wed, 2 Feb 2000 07:07:28 -0500

Glenn,

> following role-combinations:
LABELS:   A        B            C        B                A       D
> 	A+D sends P1, P3 since P1 contains A and P3 contains D

I think for a role combination, the way I understand it :), the policy goes
to only those policy targets for which the role combination is a proper
subset to the set of all roles that the target participates in.

So for the example above:
A+B sends to P1
B+C sends to P2
A+D sends to P3
A   sends to P1 and P3
B   sends to P1 and P2
C   sends to P2
D   sends to P3
A+C sends to nobody

This would be using the + as an AND symbol, as Andrew had suggested.

Am I way off base here?

If not:

The following definitions come to mind:
- A policy target is defined by a set of roles*.
- A role combination is a set of roles, which in combination, define the
policy target(s) for a policy rule.
- Each policy rule, therefore, must be associated to at least one role
combination.  (In the comments made by Bob and Andrew it seems like there is
wisdom in keeping this a one-to-one association for now and expanding as
needed).
- A policy target, T, is a target of a specific policy rule, P, iff the role
combination, C, associated with P has the following relationship with the
set of ALL roles supported by T, called Tr: C is a proper subset of Tr.

*What is a role then, that it defines a policy target?  Perhaps a
combination (in the discrete math sense) of any standard roles (Ethernet,
Diff-Serv_Interface, etc.) and customer specified roles (Engineering, Sales,
etc.).   So one can posit a set of standard roles that define general
functionality and a set of customer or vender roles that define partitioning
of a network or vendor differentiator functionality.

This all seems well within the specification put forth by the PCIM draft.

Jon

---

From: Bob Natale <[email-masked]>
Date: Wed, 02 Feb 2000 07:48:26 -0500

At 2/2/2000:07:07 AM, Jon Sjoberg wrote:

Hi John,

>subset to the set of all roles that the target participates in.

Yes, that's the way I have understood it too.

>set of ALL roles supported by T, called Tr: C is a proper subset of Tr.

I like that set of defs.

>*What is a role then, that it defines a policy target?

That's good.

>Perhaps a combination (in the discrete math sense) of any standard roles (Ethernet,

Sounds promising.

>This all seems well within the specification put forth by the PCIM draft.

Excellent...I agree.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: Bob Natale <[email-masked]>
Date: Wed, 02 Feb 2000 08:04:25 -0500

At 2/2/2000:04:28 AM, Keith McCloghrie wrote:

Hi Keith,

>So, we agree on the concepts, but not on their names.

The remaining (slight) "disagreement" here is not important,
from my view.

>I agree that A+B is a combination of roles.

Good.  But, yes, I should have gone with "A+C" in my earlier
response to your example...while any one such subset combination
establishes the point I was trying to make (namely, that a role-
combination may be a valid *subset* of all roles supported by a
policy target...e.g., "A+C" in your example), I also agree with
your point that some subsets might not make a valid role-
coombination...e.g., "A+B" in your example).

>What you want to call "role-combination" is a superset of my
>definition.

I don't see any significant difference from my perspective...
I feel that that your explanations, plus the latest rounds
from Glenn, Andrew, John, and Jon, have made the point
quite clearly that a valid role-combination may be a subset
of the set of roles supported by a policy target.

>Perhaps, what I call a role-combination could be called a "PEP
>role-combination", whereas A+B is only a "PDP role-combination",
>where the set of "PDP role-combinations" is a superset of the
>set of "PEP role-combinations".

I am not asking that any new terms be introduced.

Thanks.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: "Glenn Waters" <[email-masked]>
Date: Wed, 2 Feb 2000 11:36:06 -0500

In my view: not directly; only indirectly through the roles contained
within the role combination.
[gww] I'm not sure how to interpret the word indirectly, does it mean that
the way a role-combination is stored is by referencing a set of roles?

[...]

While this looks OK, I cannot say for sure because I'm not certain how you
define A, B, C and D.
[gww] Ooops. I changed labels at the last minute and missed these A, B...
They should be:
	A = Ethernet, B = TokenRing, C = Engineering, and D = John
Thus:
    Ethernet+Engineering sends P1, P2 since P1 contains Ethernet  and P2
contains Engineering
    TokenRing+Engineering sends P1, P2 since P1 contains TokenRing  and P2
contains Engineering
    Ethernet+John sends P1, P3 since P1 contains Ethernet and P3 contains
John

Do you mean "... in the policy server, rather than in the PEP where an
operator ..." ?
[gww] I am saying that, assuming that role-combinations are not stored in
the repository, then conflict detection cannot be performed when the policy
is entered into the repository since there is no notion of the
role-combinations at that point.
If the role-combinations were modeled/stored then an operator could look for
conflicts. If you model the role-combination then what should happen when a
role-combination is reported from a COPS-PR client that has not been
modeled. Two things could happen: you put together the policies in the way
described above and send them out or you could say that there are no
policies modeled against that requested role-combination.

Just about everything, in my view :-).
[gww] I guess I understand better than I thought if I got everything right
:)

Keith.
Thanks,  /gww