Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01

From: "John Strassner" <[email-masked]>
Date: Fri, 2 Feb 2001 14:09:43 -0800

Sorry for the delay, I've been out of the country. Comments
inline, look for <js>..</js>.

John
----- Original Message -----
From: "Robert Moore" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 30, 2001 8:01 AM
Subject: Preliminary results from PCIMe technical meeting,
1/24/01 - 1/26/01

> A subset of the PCIM, QPIM, ICIM, and MQPIM (Policy
> Framework MPLS Information Model for QoS and TE)
> authors met last week, to begin work on the PCIM
> Extensions (PCIMe) draft.  The goal was to take the
> "implementation" experience from the three submodels of
> PCIM, and determine what changes and extensions they
> suggested for the proposed-standard PCIM document
> (currently sitting in the RFC Editor's queue as
> draft-ietf-policy-core-info-model-08.txt).
>
> The following is the list of changes that we agreed to
> pursue documenting in the -00 version of the PCIMe draft.
> Rather than springing these changes cold on the WG at
> the I-D cutoff date, we'll provide a brief summary of
> them here.  This is still work in progress for the people
> who attended last week's meeting, so these formulations
> of the issues may change.  But here's a snapshot of where
> we stand right now.
>
>  The following subsections provide a very brief overview
> of the changes to PCIM being proposed in PCIMe.
>
>  2.2.1. Changes to PolicyRepository
>
>    Because of the potential for confusion with the Policy
> Framework component Policy Repository (from the four-box
> picture: Policy Management Tool, Policy Repository, PDP,
> PEP), it was determined that "PolicyRepository" is a bad
> name for the PCIM class representing a container of
> reusable policy elements.  Thus the class PolicyRepository
> has been replaced with the class ReusablePolicyContainer.
> To accomplish this change, it was necessary to deprecate
> the PCIM class PolicyRepository and its three
associations,
> and replace them with a new class ReusablePolicyContainer
> and new associations.

<js>
I don't agree with this change. If this was so confusing,
why has the name withstood the examination of all for over a
year in this working group? Deprecating a class and its
associations to fix a problem that has not been complained
about is a bad decision.
</js>

>    As a separate change, the definition of a
> ReusablePolicyContainer was broadened, to allow it to
> contain any reusable policy elements.  In PCIM, a
> PolicyRepository was allowed to contain only policy
> conditions and policy actions.

<js>
Huh? The definition of this class, from PCIM, is:

  "A class representing an administratively defined
   container for reusable policy-related information."

I've searched PCIM, and there is no text describing the
restriction you talk about above defined anywhere. This
*used* to be a restriction of QPIM, but that was removed a
long time ago.
</js>

>  2.2.2. Additional Associations and Additional Reusable
Elements
>
> The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule
> associations were imported from QPIM.  These associations
> make it possible to define larger "chunks" of reusable
> policy to place in a ReusablePolicyContainer.  The
> PolicyRuleInPolicyRule association also introduces new
> semantics representing the contextual implications of
> having one PolicyRule executing within the scope of
> another PolicyRule.

<js> Great </js>

>  2.2.3. CompoundPolicyConditions and CompoundPolicyActions
>
>  The concept of a CompoundPolicyCondition was imported
> into PCIMe from QPIM, and broadened to include a parallel
> CompoundPolicyAction.  In both cases the idea is to create
> reusable "chunks" of policy that can exist as named
> elements in a ReusablePolicyContainer.  The "Compound"
> classes and their associations incorporate the condition
> and action semantics that PCIM defines at the PolicyRule
> level: DNF/CNF for conditions, and ordering for actions.
>
>    Compound conditions and actions were defined to work
> with any component conditions and actions.  In other
> words, while the components may be instances,
> respectively, of SimplePolicyCondition and
> SimplePolicyAction (discussed immediately below),
> they need not be.

<js>
This seems fine. We didn't define CompoundActions in QPIM
because we didn't need them, but this does seem like a
generally useful idea.
</js>

>  2.2.4. Variables and Values
>
>    The SimplePolicyCondition / PolicyVariable /
> PolicyValue structure was imported into PCIMe from QPIM.
> A list of PCIMe-level variables was defined, as was a
> list of PCIMe-level values.  Other variables and values
> may, if necessary, be defined in submodels of PCIMe.
>
>  A corresponding SimplePolicyAction / PolicyVariable /
> PolicyValue structure was also defined.  While the
> semantics of a SimplePolicyCondition are "variable
> matches value", a SimplePolicyAction has the
> semantics "set variable to value".

<js>
This seems fine. I would recommend that you also copy the
binding between variable and value that we defined in QPIM
qosPolicySimpleCondition to SimplePolicyAction.
</js>

>  2.2.5. Packet Filtering
>
>    For packet filtering done in the context of a
> PolicyCondition, a set of PolicyVariables and
> PolicyValues were defined, corresponding to the
> fields in an IP packet header plus the most common
> Layer 2 frame header fields.  It is expected that policy
> conditions that filter on these header fields will be
> expressed in terms of CompoundPolicyConditions built up
> from SimplePolicyConditions that use these variables and
> values.
> An additional PolicyVariable, PacketDirection, was also
> defined, to indicate whether a packet being filtered is
> traveling inbound or outbound on an interface.
>
>    For packet filtering in other contexts (specifically,
> for the packet classifier filters modeled in QDDIM),
> these variables and values need not be used.  Filter
> classes derived from the CIM FilterEntryBase class
> hierarchy may still be used in these contexts.

<js>
This last sentence is misleading. One can easily define
equivalences between the FilterEntry.MatchConditionType and
the PolicyVariable classes and also between the
FilterEntry.MatchConditionValue and the PolicyValue classes.
The perception that PolicyVariables and PolicyValues somehow
break FilterEntries is just plain wrong.

Perhaps some additional wording to this effect should be
included in PCIMe. The designer can specify a filter using
either FilterEntries and/or {variable, operator, value}
triplets.
</js>

>  2.2.6. Priorities and Decision Strategies
>
> Drawing from both QPIM and ICIM, the priority property
> has been deprecated in PolicyRule, and placed instead on
> the associations PolicyRuleInPolicyGroup,
> PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and
> PolicyRuleInPolicyRule. (Obvious question: would it be
> better to introduce a superclass
> PrioritizedPolicyComponent for these four associations,
> just to contain the priority property?  The answer is
> probably "yes".)  The QPIM rules for resolving relative
> priorities across nested PolicyGroups and PolicyRules
> have been incorporated into PCIMe as well.

<js>
What's the point of having a PrioritizedPolicyComponent
aggregation (these are aggregations, not associations)? This
only makes sense if there is also a
NonPrioritizedPolicyComponent aggregation. Because
eventually, someone is going to want order or some other
semantic added to one or more of these aggregations, and
then we are going to have to go through the hell of
deprecating things again. Since this is clearly an
optimization, why not wait and get some implementation
experience first?
</js>

> With the removal of the priority property from
> PolicyRule, a new modeling dependency has been
> introduced: in order to prioritize a PolicyRule
> relative to other PolicyRules, the rules must be
> placed in a PolicyGroup.

<js>
I think you missed the reusable case. Assuming that you do
add explicit text saying that you can put anything in a
PolicyRepository, then what if you have a PolicyRule that
contains two reusable PolicyRules? Here, you use the
association (not aggregation)
PolicyElementInPolicyRepository to associate any subclass of
Policy to a PolicyRepository. Therefore, if you REALLY want
to do this, you should add the
PolicyElementInPolicyRepository association, defined in
QPIM, to PCIMe.

Note that this produces a LOT of additional complexity. I'm
not sure it's a Good Thing. But the facility is there if you
want to explore it.
</js>

>    In the absence of any clear, general criterion for
> detecting policy conflicts, the PCIM restriction stating
> that priorities are relevant only in the case of
> conflicts has been removed.  In its place, a
> DecisionStrategy property has been added to PolicyGroup
> class, to allow the policy administrator to select one
> of two behaviors with respect to rule evaluation: either
> perform the actions for all PolicyRules whose
> conditions evaluate to TRUE, or perform the actions
> only for the highest-priority PolicyRule whose conditions
> evaluate to TRUE. The QPIM rules for applying decision
> strategies to a nested set of PolicyGroups and
> PolicyRules were also imported.

<js>
This begs the question, "What happens if there are multiple
PolicyRules of the same priority"? Then the DecisionStrategy
property doesn't help. So, looking at the paragraph below, I
*guess* that your answer would be that it doesn't matter
which PolicyRule executes, as long as only one executes.
This behavior is inconsistent with introducing the property
in the first place.
</js>

>    The question of whether to require unique priority
> values for the PolicyRules in a PolicyGroup was raised and
> discussed, but the decision was to allow these values to
> collide within a PolicyGroup, to indicate "don't care".
> Submodels of PCIMe are free to add the restriction that
> priority values not collide within a PolicyGroup.
>
>  2.2.7. Policy Roles
>
>    Policy roles were removed from PolicyRules (that is,
> the PolicyRoles property was deprecated there), and placed
> instead on PolicyGroups.

<js>
I object. This requires implementations to have PolicyGroups
to contain PolicyRules. This in turn only makes sense if
there is a reason to treat these PolicyRules as an atomic
unit. There may well not be such a reason. Implementations
should be able to use PolicyRules and the benefits of roles
without having to have an artificial grouping class.
</js>

>    nested PolicyGroups, any roles associated with the
> outer PolicyGroup are automatically "inherited" by the
> nested PolicyGroup. Additional roles may be added at the
> level of the nested group, but inherited roles
> cannot be canceled or overridden there.

<js>
This exacerbates the above problem. This means that I have
to two or more PolicyRules inside a PolicyGroup, but want
them to have different roles, I now have to add another
PolicyGroup for each different role that I want. This makes
the system unnecessarily complicated.
</js>

<js>
To sum up, here's why I object to both of the above
paragraphs: Grouping is for grouping, and roles are for
selecting. The two have completely different semantics, and
trying to mush them together looses those semantics.
</js>

>    It was also observed that there was no mechanism at all
> in PCIM for assigning roles to resources.  For example,
> while it was possible to associate a PolicyRule with the
> role combination "FrameRelay&&WAN", there was no way to
> indicate which interfaces had this role combination.  A
> new PolicyRole class was defined, representing the
> collection of resources associated with a particular role
> combination.  The linkage between a PolicyGroup and a set
> of resources is then represented by having an instance of
> PolicyRole that shares its name with a role combination
> value for the PolicyGroup, and is associated with the set
> of resources having that role combination.

<js>
I don't like this at all. First, you complained earlier
about the potential confusion (though the mail list had
none) between PolicyRepository the class and Policy
Repository the component. Yet it's fine to have a class
PolicyRole and a property PolicyRoles within another class?

Second, this is a bizarre form of referential integrity.
There are no semantics to enforce this in the rest of the
model. And some data stores probably couldn't enforce these
semantics anyway.

Third, hoping that someone gets the names right is a Bad
Thing, because they won't.

Fourth, from a modeling point-of-view, this should be done
by an association. Why isn't it done this way?
</js>

> If you have any comments on these proposed updates to
> PCIM, please post them to the mailing list.
>
> Regards,
> Bob
>
> Bob Moore
> IBM Networking Software
> +1-919-254-4436
> [email-masked]

---

From: Mahadevan Iyer <[email-masked]>
Date: Tue, 6 Feb 2001 01:09:32 -0800 (PST)

> break FilterEntries is just plain wrong.

Can someone summarize the reasons why we will continue
to have the notion of FilterEntry in IPSP drafts. If
the reasons have been summarized in a thread, a
pointer to the thread would be sufficient.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

---

From: Mahadevan Iyer <[email-masked]>
Date: Tue, 6 Feb 2001 01:01:16 -0800 (PST)

Hello Bob,

I like the idea of PolicyRole being a first class
object which can be extended. I don't see why we
shouldn't go ahead and formally recognize the 3
possible roles(Admintration, Functional &
Enforcement). 

Are there any objections to this ?

Regardless of the application domain, these are basic
features of any rule or policy modeling system. These
are the points at which there needs to be a common
understanding across multiple parties reading/writing
to the policy repository.

Thanks

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 6 Feb 2001 09:18:12 -0500

Mahadevan, There has been some discussion on this list and, of course, on
the IPSP list but there's no conclusive answer as yet.  Jamie and I have
discussed this and we'll leave the IPsec Config Policy Model (ICPM, aka
ICIM) as it is for now.  The reason is primarily one of timing: the PCIMe
draft is being written right now and ICPM needs to be updated in time for
the March meeting.  We need stability in the technical content and these
kind of representation details are really secondary right now.

That said, in the long run whether we use FilterEntry or
PolicyVariable/PolicyValue pairs is tbd, but the answer will lie in how the
IPSP WG sees the trade-offs between common policy representation vs. a model
that's close to its device-level implementation.

Lee

----- Original Message -----
From: "Mahadevan Iyer" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 06, 2001 4:09 AM
Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 -
1/26/01

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 6 Feb 2001 11:17:50 -0500

John,  Thanks for your comments.  I'm breaking responses into different
threads for the different topics.  I think this one is easy.

> associations to fix a problem that has not been complained

I don't believe the name has withstood the examination.  I've been confused
about PolicyRepository since its inception and we've talked about this
several times.  I know others are also confused (including some people in
your own company).  One suggestion has been made that we change the name of
the policy repository in the architecture drawing but that IS a policy
repository by the English use of the words whereas the PolicyRepository
class isn't a repository at all, it's an admindomain subclassed container
object for reusable policy components.  So, we concluded we ought to call it
that: ReusablePolicyContainer.  If we were going to do something dramatic
here, we'd change its superclass to a collection...but that hasn't been
proposed.

What's the harm in what we're proposing?  Well, it does necessitate
deprecating a few classes but this is the time to do that if we're going to.
PCIM is Proposed and we've been asked to reconcile PCIM and the other
drafts.  Is it essential to do this?  No, I don't think so, but I do think
we should.  If there are any implementations out there that have carved this
in stone...we'll, we're deprecating its use, we're not deleting it.

I think this is a red herring and not worth debating unless there's some
reason for concern that I don't grok.  But if someone thinks it's a critical
error to change the names of some classes in an Information Model, well, I
yield...but tell me why it's critical.  We're going to deprecate other
things in the process, so it can't be that we can't change PCIM.

> *used* to be a restriction of QPIM, but that was removed a

The only associations that were defined in PCIM were associations for
conditions and actions.  The broadening that Bob referred to is that we're
now explicitly extending the list in PCIMe rather than leaving it up to
derived models to do so.  Again, nothing to debate here either.

Cheers, Lee

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 6 Feb 2001 12:16:42 -0500

John, Here are some responses to your comments on priorities and decision
strategies.  Cheers, Lee

> optimization, why not wait and get some implementation

Bob was, I think, correctly hinting at re-examining some of the inheritance
hierarchy for a couple of classes.  While working on the section about
decision strategies, I found myself writing about decision strategy sets,
i.e., the abstraction for PolicyGroup and PolicyRule that contain other
policy groups and rules and have a homogeneous decision strategy.  This
abstraction is natural for the inheritance hierarchy in that a PolicySet
(pick a better name of you like) is an abstraction for PolicyGroup and
PolicyRule and it defines the PolicyDecisionStrategy property.  It would
then have the PolicySetComponent aggregation (my rename of Bob's
PrioritizedPolicyComponent) as an abstraction for the
PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, PolicyRuleInPolicyGroup
and PolicyRuleInPolicyRule aggregations wherein the Priority property is
defined.  With the complexity being added to groups and rules, this
abstraction makes it much easier to think about the concepts of decision
strategies and priorities. I've asked the other authors to render an opinion
on this suggestion but I haven't heard back yet.  Opinions from the broader
community are also welcome.

> not sure it's a Good Thing. But the facility is there if you

What Bob missed in his summary was that rules can be in other rules in the
proposed rule structure.  But the essential point that rules need a context
to have priority is correct and, as a byproduct of the agreement to
deprecate the use of PolicyRule.Priority, that context is proposed to be
explicitly defined by the aggregation discussed above.
PolicyElementInPolicyRepository has nothing to do with priority...the
repository (or "ReusablePolicyContainer" or whatever we call it) does not
establish a context for priority evaluation; it's simply a container for
reusable policy components.  The context for priority is tied to the
decision strategy on a containing group or rule.  Hopefully, this will all
be clearer when I've written the section in the new draft.

> This behavior is inconsistent with introducing the property

Yes.  For "FirstMatching" only one rule gets executed, so if the submodel
and adminstrator decide to permit non-deterministic rules, then it up to the
implementation to decide which of the equal priority rules to execute when
more than one matches.

I don't understand how this behavior is inconsistent with the introduction
of a priority property.  I don't personally recommend that derived models
permit non-deterministic priorities, but when they do, this is the only
reasonable interpretation.  The PCIM notion that priority applies only to
conflicts has two problems: 1) it doesn't explain the "FirstMatching" use of
priority and 2) it relies on an undefined notion of "conflicting."  The
obvious conflicts (e.g., set DSCP to x and set DSCP to y are still resolved
by priority in both a FirstMatching and AllMatching strategy; either only
one gets executed or both get executed and the one evaluated last wins (an
interesting notion of priority, I admit).  Perhaps we should rename the
Priority property to EvaluationOrder?  (We discussed this as well and
decided to leave it alone, but I'm guessing we could be persuaded
otherwise.)

Again, hopefully this will all be clear when I've written the section in the
new draft.  We discussed having 3 decision strategies: FirstMatching,
AllMatching, AllNonConflictingMatching and decided to only have two...unless
someone can define the AllNonConflictingMatching strategy and the underlying
definition of "conflicting."

---

From: Mahadevan Iyer <[email-masked]>
Date: Tue, 6 Feb 2001 21:37:22 -0800 (PST)

> that's close to its device-level implementation.

What is the device-level implementation aspect that
points to FilterEntries. As far as I know IKE itself
has a notion of proxy id's(not filterentries) which at
this point are specified as IP subnets. 

Thanks

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 7 Feb 2001 09:32:34 -0500

Mahadevan,

First, let's make sure everyone understands that the IPSP model is for a PEP
not for a PDP.  It's a device-level configuration model of an IKE service
and related stack components in a security client or security gateway; it's
not a domain policy.

Implementations vary, of course, but the notion that filter entries are
closer to a device-level policy implementation has to do with the fact that
parsing a general grammar (Variable, Operator, Value) is not the most
efficient implementation of a filter.  One of our implementations, for
example, uses the stack's 5-tuple filters to not only find the outbound SAs
but to also test the address-based conditions for the rules...it's pretty
efficient.  A parser for the VOV syntax wouldn't be implemented in that
product.

But that doesn't mean we shouldn't express the conditions in a VOV syntax in
the information model just that there are trade-offs.  It's very tempting to
try to find an algorithmic mapping from an information model to an
implementable data model.  Such a mapping for VOV won't even be close for
some implementations whereas it'll be close for Filters.  But as long as the
PIB, MIB, LDAP, et al mapping activities aren't tempted to do that, then
this concern is diminished.

Another thing to consider here is that a general grammar can specify
conditions that a PEP might not be able to parse into its limited set of
filter options.  A PDP can take a general specification of a domain-level
policy and map it to a set of device-level policies that match the
capabilities of a given PEP.  A PEP cannot be expected to handle any policy,
just the ones appropriate for it.  This concern doesn't disappear if we use
filters, but it's easier to spot the conditions that can be specified that
may not be supported.

Just a few things to consider.  Cheers, Lee

----- Original Message -----
From: "Mahadevan Iyer" <[email-masked]>
To: "Lee Rafalow" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 07, 2001 12:37 AM
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe
technical meeting, 1/24/01 - 1/26/01)

---

From: Yoram Ramberg <[email-masked]>
Date: Thu, 08 Feb 2001 10:20:03 +0200

(finally we have a thread to talk about it and I can't be blamed for 
starting it!)

I admit that I've experienced some confusion in the way we use the term 
'repository' to denote various things. Here's an attempt to organize this 
somewhat:

Policy repository: This term has been used mostly to refer to storage. It 
has been synonymous at times with the term 'policy database'.

Reusable-objects repository: This term has been used to refer to the 
classes that model the collection(s) of objects that are "reusable", i.e., 
can be managed centrally but referred to ("used") by other objects. An 
example is a reusable condition used by many rules.

Repository: Has also been used to refer to a directory (LDAP). This was 
mostly used in schema documents but sipped sometime into info model docs as 
well.

To me the first two have been confusing and required me to do a double take 
several times while reading (even text I myself had written!). In 
particular this becomes tricky when reading through text such as this (not 
a real example, just a possible one, but we have a couple of places that 
almost read like this):

"The object may be placed in the reusable-objects repository. Several 
reusable-objects repositories may exist in the policy repository. The 
administrator is free to locate the repositories anywhere within his/her 
own organization repository as long as objects associated with 
reusable-objects have access to the repositories where they 
reside.'"    Not easy, is it?

While I learned to deal with it (after all, life has presented me with 
greater challenges before and since), it would be nice to take this 
opportunity and get it cleared out once and for all.

I'll refrain from making a proposal for new terminology but I support this 
effort for the reasons explained above.

*Yoram

---

From: John Strassner <[email-masked]>
Date: Thu, 08 Feb 2001 10:30:22 -0800

Hi Lee,

thanks for the response, comments inline using <js2>..</js2>

regards,
John

>here, we'd change its superclass to a collection...but that hasn't been

<js2>
How can you say that the name has withstood the examination? There is not 
one single message to the policy list questioning the name of this class. 
Furthermore, we could call the policy repository in the architecture 
drawing a data store, too. The PolicyRepository class IS a repository in 
how we're using it - in the QPIM text and presentations, we've emphasized 
the fact that this is a repository in a repository, specifically for 
containing reusable policy components. But my main argument is in the next 
paragraph below.
</js2>

>in stone...we'll, we're deprecating its use, we're not deleting it.

<js2>
The harm is exactly what you mentioned. I feel that we are unnecessarily 
deprecating classes in an RFC in advance of implementation. We have product 
that uses this class, and we've had no problems in distinguishing the class 
from the data store. ;-)
</js2>

>things in the process, so it can't be that we can't change PCIM.

<js2>
You're right, there's no rule saying that we can't deprecate things. But I 
would hope that we do deprecate things with caution, and based on 
implementation experience. I don't see either of these steps being taken 
here, and since we do have product using this, I objected.
</js2>

>derived models to do so.  Again, nothing to debate here either.

<js2>
 >> conditions and policy actions.

This clearly implies that the PolicyRepository/ReusablePolicyContainer was 
somehow limited and could not contain any reusable policy elements, but 
only a limited set. Your argument is somewhat of a red herring - while we 
only defined associations to put conditions and actions in the 
PolicyRepository, remember that the PolicyRepository came from QPIM in the 
first place. One of the first things we did in QPIM was to also define the 
storage of other policy elements in the PolicyRepository.

Put another way, we started by taking things from QPIM and putting them 
into PCIM. Now we're taking more things (but not enough, as I argue in the 
author's meetings of PCIMe) from QPIM and putting it into PCIMe. I don't 
think it does anyone any good to say that such things are new concepts, 
because they're not. They've been defined in QPIM, and now we're trying to 
generalize them.

This is why I object to the literal wording of Bob's message, and as proof 
attached the definition of what's in PCIM now. So please delete that 
statement, and I'll shut up.
</js2>

---

From: John Strassner <[email-masked]>
Date: Fri, 09 Feb 2001 06:04:14 -0800

Hi Lee,

thanks for the comments. Please see inline comments, demarcated by 
<js2>..</js2>.

regards,
John

>community are also welcome.

<js2>
I didn't get any of this from Bob's message, and am still not sure I follow 
completely what you're proposing. So let me ask a couple of questions to 
ensure I understand.

   - you're proposing a new class, PolicySet, that is a collection
     that can contain PolicyGroups and PolicyRules.
     - is that ALL that it can contain?
     - what is the superclass of PolicySet?
   - you're proposing a new aggregation, PolicySetComponent
     - is this the superclass for the 4 existing
       PolicyGroup/RuleInPolicyGroup/Rule aggregations, or
       does it replace it?
   - are you still proposing to deprecate PolicyRule.Priority?
</js2>

>explicitly defined by the aggregation discussed above.

<js2>
A sub-rule, by definition, is already scoped by its parent rule. In other 
words, it already has a context.

In QPIM, we put decision strategies on containers, so that the container 
could establish a decision strategy for the rules that it contained. We 
combined this so that one could equate grouping with decision strategy. I 
don't see how you accomplish that with the PolicySet construct above. Can you?
</js2>

>be clearer when I've written the section in the new draft.

<js2>
Let me try again. The point about PolicyElementInPolicyRepository is that 
you may want to include a reusable PolicyRule in your PolicySet. So how do 
you do this with your new constructs? You can't use your new 
PolicySetComponent aggregation, because its definition doesn't allow the 
inclusion of PolicyRepositories. Therefore, you either need to reuse 
PolicyElementInPolicyRepository or define a new association.
</js2>

>implementation to decide which of the equal priority rules to execute when

<js2>
No! Why are we allowing non-deterministic behavior? As long as "the hood is 
open", why don't we prevent this?
</js2>

>of a priority property.

<js2>
Priority implies no ties and deterministic behavior.
/js2>

>   I don't personally recommend that derived models
>reasonable interpretation.

<js2>
No, a better interpretation is to prevent non-deterministic behavior in the 
first place.
</js2>

>   The PCIM notion that priority applies only to

<js2>
First, I would note that we can't define "conflicting" because a complete 
definition of "conflicting" is dependent on application-specific semantics, 
which by definition can't be standardized. Second, I would argue that PCIM 
does NOT say that the only purpose of priority is to provide conflict 
resolution. So as to how to resolve this, it depends on what you want to 
accomplish. Renaming Priority to EvaluationOrder would help emphasize that 
Priority is solely for determining the order of execution of rules. One use 
of this is to allow a policy rule to temporarily override another policy 
rule. This has **nothing** to do with conflict resolution. My fear is that 
there are already implementations out there that also use Priority for 
helping to resolve conflicts.

So, what did you want to accomplish? ;-)
</js2>