Subject: Policy Execution Semantics: New Proposal

From: [email-masked]
Date: Sun, 16 Apr 2000 20:39:28 -0400

Let me take another crack at this and see if I can
come up with something that makes everyone happy.

Proposal:

(1) Add a new mandatory attribute to every Rule, Rule Number,
a positive integer.  Require that no two Rules in a
policy and/or repository have the same Rule Number.
Rule Number is used to determine what Rule to
perform first when multiple Rules are eligible and all
other means, including the Priority attributes (on Rule,
Group, Container, etc.) have failed to select a single
most eligible Rule.  In such a case, the Rule with the
larger Rule Number is performed first.

(2) Rule Number is intended to be set automatically by a
tool, such as a policy authoring tool.  The Rule Numbers
could also be assigned in cooperation with or solely by
a policy repository as part of the operation of inserting
each Rule into the repository.  Manual/human/administrative
control over policy execution should be accomplished via
the various Priority attributes, not Rule Number. It is
a good idea to preserve the Rule Number when a rule is
modified, but there is no absolute requirement to do so.

(3) Correct operation of policy clients must not depend
on all policy rules having unique numbers, and policy
clients should check that all retrieved rules
do have unique numbers.  This is of particular importance
when a single client retrieves rules from more than one
policy repository.

(4) If a policy is resident in multiple repositories, and
consistent predictable operation across the clients of
those repositories is required, then the relative order of
Rule Numbers should be the same in all of the repositories.
Means for doing this need not be specified here, but could
include adding or subtracting a fixed offset to/from all
the Rule Numbers as part of the insertion operation
if a set of rules retrieved from one repository conflicts
with Rule Numbers already in use in another.

Rationale:

This is basically a brute force solution.  Returning
to the scenario from Minneapolis, and assuming that only
one of the two rules is to be performed ...

	Example:
		Rule 1: Engineers get Bronze service.
		Rule 2: John gets Gold service.
		Fact: John is an Engineer.
		Oops: No rule priority specified
	When and where does John get Gold service?

... the answer is "All the time, and everywhere" because
Rule 2 has the higher number.  The fact that the answer
is this simple is a good sign.

The detailed rationale for the proposal is:

(1) A new attribute is proposed because my attempts to use the
existing Priority attribute aren't working.  It is clearly
intended that multiple objects be allowed to have the same
Priority, therefore something else is needed.  

(2) My concerns about global priority not scaling were based
on the use of the existing Priority attribute, which is intended
to be set by the policy author.  Inserting a rule into a 500+
rule policy and having to change the Priority of several hundred
other rules is an example of the scaling problem.  By separating
the Rule Number attribute from Priority, and making it clear
that Rule Number is intended to be set/generated automatically,
this scaling problem is eliminated; a program has no problem
changing thousands of rule numbers if that's called for.

(3) This satisfies Andrew Smith's request that there be
a way for a PDP to detect unresolvable conflicts when rules
are downloaded.  The PDP checks all the rule numbers, and
complains if any two match; this seems reasonable to implement,
and there are a number of ways of doing so.

(4) This is a consequence of having multiple repositories
An alternative that would get rid of this concern would be
to use 128 bit UUIDs for Rule Numbers, as then one would have
a strong guarantee that no two Rules could have the same
Rule Number no matter how many repositories are involved.
UUIDs would avoid the need to make Rule Numbers visible
through the administrative interface for policy repositories,
but 128 bits per rule seems excessive to me.

What do people think of this?

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]  Cellular: +1 (978) 394-7754
---------------------------------------------------

---

From: "Jensen, Kell Michael" <[email-masked]>
Date: Tue, 25 Apr 2000 02:47:50 -0700

I think it would be an easy way to solve some of the unambigous issue raised
before.

However we need a method to change Rule Number, if we want to swap the order
of a set of rules, and doesn't have any free rule Number in the area.

Do we then still need the priority attribute?

/Kell Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 17. april 2000 02:39
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Policy Execution Semantics: New Proposal

Proposal:

Rationale:

	Example:

--David

---

From: [email-masked]
Date: Tue, 25 Apr 2000 08:52:21 -0400

> I think it would be an easy way to solve some of the unambigous issue
> raised before.
> 

The intention is to retain Priority for this purpose -- i.e., Rule Number
provides a default ordering, and if someone doesn't like it, Priority
can be set to achieve the desired order.  There's nothing to stop a
tool/administrator from setting Rule Number, but Priority is likely
to provide more effective means - for the specific example of swapping
the order of a set of rules, there may be a single rule group Priority
or rule container Priority that does the job.  Relying solely on
Rule Number for all rule ordering makes it harder to have a tool
automatically renumber the rules when a new one is inserted
in the middle

--David