Subject: Fw: [Policy] Roles and [un]rooted PolicySets

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 19 Sep 2001 10:54:41 -0400

Micea,  I'm sorry!  In my haste to get this out, I misstated this
clarification as an agreement on your first interpretation.  On the
contrary, the 2nd interpretation is the intended interpretation: the roles
have nothing to do whether a PolicySet instance is rooted or not in the
context of a given ManagedElement instance.
----- Original Message -----
From: "Lee Rafalow" <[email-masked]>
To: "IETF Policy" <[email-masked]>
Sent: Wednesday, September 19, 2001 10:39 AM
Subject: Re: [Policy] Roles and [un]rooted PolicySets

> Mircea,
>
> Your first interpretation is correct.  One might select both roles A & B
if
> B is not a subset of A but simply has some intersection set.  How's this
for
> a clarification?
>
> "A PolicySet instance is unrooted in that context if and only if there is
no
> PolicySetComponent association to a parent PolicySet that is also related
to
> the same managed element."
>
> And insert:
>
> "These PolicySetComponent associations are traversed up the tree without
> regard to how a PolicySet instance came to be associated with the
> ManagedElement."
>
> Lee
>
> ----- Original Message -----
> From: "Mircea Pana" <[email-masked]>
> To: "IETF Policy" <[email-masked]>
> Sent: Tuesday, September 18, 2001 5:42 PM
> Subject: [Policy] Roles and [un]rooted PolicySets
>
>
> > PCIMe-03 states that:
> > "A PolicySet instance is unrooted in that context if and only if there
> > is no PolicySetComponent association to a parent PolicySet that is also
> > related to the same managed element."
> >
> > How should the following situation be interpreted?
> >
> >             +---+                      +-----------+
> >             | A |                      |  I/F  X   |
> >             +---+                      | has roles |
> >              / \                       |   A & B   |
> >             /   \                      +-----------+
> >         +---+    ooo
> >         | B |
> >         +---+
> >          /
> >         /
> >         ooo
> >
> > In the context of the interface X:
> >
> > 1. PolicySets A and B are unrooted because they are independently
> > selected using  the role-based policy selection (according to rfc3060).
> > However B is selected
> > a second time (rooted this time) through the inherited role A.
> >
> > 2. PolicySet A is unrooted but PolicySet B is rooted (under A) because B
> > is associated to a parent (PolicySet A) that is also related to the same
> > managed element. (according to the definition from PCIMe-03)
> >
> > IMO the first option is right and PCIMe needs a little clarification.
> >
> >
> > Regards,
> > Mircea.
> >
> > _______________________________________________
> > Policy mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/policy
> >
>
>

_______________________________________________
Policy mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/policy

---

From: "Mircea Pana" <[email-masked]>
Date: Wed, 19 Sep 2001 16:13:43 -0400

Lee,

I am not comfortable with the second interpretation for the following
reasons:
(A, B and X here are the same as the ones from the previous example)

1. It somewhat contradicts (in spirit) RFC3060: The fact that PolicySet
B is independently related to i/f/ X (through its own role) is ignored
due to B's subordination to PolicySet A (that happens to be also related
to i/f X).

2. Loss of functionality: An i/f X with roles A & B and an i/f Y with
just the role A get the same PolicySet(s) with no distinction.

3. Difficult implementation and possible performance hit: In the
creation and in the selection phases it is required to detect if
PolicySet B is subordinated to PolicySet A (how deep?). For this purpose
an arbitrary number of PolicySetComponent associations must be traversed
up.

I would rather go for the first interpretation and define the unrooted
PolicySet as follows:

"A PolicySet instance is unrooted in that context if and only if it is
related to a managed element through one if its own (versus an
inherited) role combinations."

Please correct me if I'm wrong.
Thanks,
Mircea.

---

From: "Lee Rafalow" <[email-masked]>
Date: Thu, 20 Sep 2001 15:15:17 -0400

Mircea, There are several reasons, I think, for ignoring roles in the
analysis of PolicySet trees for assigning absolute priorities.  To determine
the absolute priority of a rule, one must first construct a tree of the
PolicySet instances and the relative priorities associated with each of the
edges in the tree.  The question at hand is what is the traversal from leaf
nodes to the root that is needed to determine priorities in the context of a
given ManagedElement.

1.  The fundamental reason for ignoring role is that there is no semantic
relationship between roles and priorities.  The spirit of 3060 doesn't
include the priority semantic as part of role; rather it's included as part
of the rule.  For completeness, PCIMe expands that semantic to include
groups (moves it up to PolicySet) and, for simplicity, it moves the encoding
of the semantic onto the relationship in the tree of PolicySets.  Further,
there is no requirement that roles be used to relate PolicySet instances to
a ManagedElement.   The IPSP model, which is a device-level model, has
specific associations for that relationship.  If in a theoretical
domain-level IPSP model we were to have roles, they have been removed at the
device level.

2.  When an unrooted PolicySet is identified, the relative priority for that
Set falls back to the System context (i.e., the priority on the
PolicySetInSystem association).  As alluded to above, the complexity of
assigning a priority to a PolicySet in that larger System context is
difficult.  The larger the number of PolicySets that are prioritized in the
System context, the more complex the job of assigning a single value for its
position in absolute priority calculations.  This is why we moved priority
from PolicyRule to PolicySetComponent in the first place.

3.  Lastly, I'm unclear why you think this might be more difficult.  As I
said in the intro above, the tree needs to be built and traversed (probably
once per policy update rather than on use) to calculate the absolute
priority for the rules.  And, I think the tree traversal to find unrooted
sets in the context of a ManagedElement is pretty straightforward.  For each
PolicySet, find all of the matching PolicySetComponent.PartComponent to see
if the PolicySetComponent.GroupComponent is also an associated PolicySet.
If none of the PolicySet's parents are associated with the ManagedElement,
the PolicySet is unrooted and it's parent is the System class.  The only
difference, I think, is that you don't have to keep track of the roles (if
used) that caused the set to be related in the first place.

I hope this helps.  Cheers, Lee

----- Original Message -----
From: "Mircea Pana" <[email-masked]>
To: "policy" <[email-masked]>
Sent: Wednesday, September 19, 2001 4:13 PM
Subject: Re: Fw: [Policy] Roles and [un]rooted PolicySets

> > > "A PolicySet instance is unrooted in that context if and only if there
is

---

From: "Mircea Pana" <[email-masked]>
Date: Thu, 20 Sep 2001 18:02:23 -0400

Lee,

From what I understand (in PCIMe), the PolicySet is a reusable entity
that may be related to a managed element both directly as a stand alone
policy, and also indirectly as a component of a larger policy (group or
rule) related to the managed element. PCIMe does not restrict the
PolicySet instance reusability. If a PolicySet instance is directly
related to a managed element *and* also as component of other PolicySets
related to the *same* managed element, then this would result in that
PolicySet having multiple positions in the absolute priority list for
that managed element.

So, if we use the same example and let's say PolicySet A has
priorityInSystem = 2 and PolicySet B has priorityInSystem = 1. Then
because i/f X is directly related (through roles or explicitly) to both
A and B, then X gets:

PolicyGroup Default (decisionStrategy=firstMatching)
 priority=2: PolicySet A {includes PolicySet B (*)}
 priority=1: PolicySet B (**)

(*)evaluated/executed in the context of A
(**)evaluated/executed in the global context

Therefore, B appears to the managed element as two instances: one
unrooted and one rooted (under A). Isn't this in line with the intent of
PCIMe?

Thanks,
Mircea.

P.S. Given the fact that PolicySets are allowed to have an arbitrarily
complex nesting, detecting whether or not a parent of PolicySet is also
related to the same m.e. involves finding and comparing the parents of
each related PolicySet, then the parents of every parent, then the
parents of the parents of every parent, ....