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

From: "Lee Rafalow" <[email-masked]>
Date: Fri, 21 Sep 2001 09:38:37 -0400

Mircea,  I think I understand your concern now:  we permit the reuse of the
PolicySet instances with their own parent relationship priority as rooted
nodes in the tree but not as unrooted nodes.  And I agree that it's a
reasonable assertion.

PolicyRole is really a set of implicit associations between PolicySet
instances and ManagedElement instances and, as such, it cannot have any
additional properties with it.  So, you propose that we use the "default"
priority as specified in the PolicySetInSystem association rather than
define the role association explicitly.   The authors did briefly consider
an alternative that put decision strategy and priority in
PolicyRoleCollection but it seemed redundant, added to the already
complicated semantics of PolicyRole and added configuration to the PEPs.
Using the default priority solves the last of those concerns.

So, for the reasons I gave in my previous message below, and because I think
the relationship between role and the default priority is not particularly
clean and because I think role is fragile and this would further overload
it, I still prefer to keep what we have (with a clarifying sentence like I
suggested earlier).

That said, I do think a reasonable case exists for your point of view.  Are
there any others that have an opinion on this topic?

I'm not sure I understood your P.S.  You have to build the tree in order to
figure out the absolute priorities regardless of our decision on whether we
add a priority semantic to role and, as I said, I think adding role only
complicates it further.

Lee

----- Original Message -----
> From: "Mircea Pana" <[email-masked]>
> To: "policy" <[email-masked]>
> Sent: Thu, 20 Sep 2001 18:02:23 -0400
> Subject: Re: Fw: [Policy] Roles and [un]rooted
>
> 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, ....
>
>
>
>
> Lee Rafalow wrote:
> >
> > 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
>
>
>

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

---

From: "Mircea Pana" <[email-masked]>
Date: Fri, 21 Sep 2001 12:27:20 -0400

Lee,

I share your concerns wrt. the role and role combination. It doesn't
have to be used in defining priority and decision strategy. The example
in PCIMe (fig.4) is using roles so I used roles too. IMO just using the
word "related" to describe the association between a PolicySet and a
ManagedElement should suffice.

But I do make a difference between 1 and 2 below:

1. A PolicySet is directly related to a ManagedElement if they share an
explicit association, role combination or other direct (not inherited)
relationship. In this case the PolicySet is unrooted from a priority
point of view and the PriorityInSystem is used.

2. A PolicySet is indirectly related to a ManagedElement if its parent
is directly or indirectly related to that ManagedElement. The PolicySet
inherits the relationship from its parent. In this case the PolicySet is
rooted
under its parent, therefore it is prioritized relative to the other
PolicySets under the same parent.

In addition, I think it is valid to have a same PolicySet instance in
both situations simultaneously. So, saying about a PolicySet that it is
rooted if its parent is also related to the same ManagedElement would
not be entirely true.

In conclusion, I think we are in agreement on the semantics. All that
may be needed is a clarification.

Thanks a lot,
Mircea.