Subject: RE: LDAP, the Core & the QoS inf. model

From: [email-masked]
Date: Thu, 19 Aug 1999 11:01:03 -0400

Yoram,

First a question for clarification, then a more fundamental question.

The clarification question is this:  in a scenario where there's a
reusable condition object in a Policy Repository, did you mean for
the new DN-valued attribute in policyRule to point to the instance
of policyRuleConditionAssociation in the DIT under the instance of
policyRule, or to the condition object in the repository that
policyRuleConditionAssociation points to?

The more fundamental question is whether detecting this sort of
rule corruption is worth the cost of maintaining the extra sets of
DN pointers.  (It is *two* sets of pointers, right:  one pointing
to conditions, one pointing to actions?)  I thought that by using
the order for inputting data that you documented in your draft, it
was possible to minimize timing problems associated with the input
phase.  I also thought that replication consistency problems were
minimized by putting related data into DIT subtrees.  By introducing
DN-valued attributes into policyRule, it seems like you're opening
the door for still more consistency problems.  (For example, if you
want to remove a condition from a rule, which do you do first --
delete the condition (or the reference to it, for a reusable
condition) or update the DN pointer?  Either way, there's a chance
that a client will "catch" the rule in an inconsistent state.

I think this gets to my basic question.  If a policyRule is being
updated by a policy administrator, what's the benefit of having
the sequence (time reads downward):

   - Old version of the rule (consistent)
   - Inconsistent state
   - New version of the rule (consistent)

rather than just

   - Old version of the rule (consistent)
   - New version of the rule (consistent)?

I'll admit that you might be able to demonstrate a benefit if
a rule is undergoing multiple changes at once -- e.g., the
addition of two conditions.  Then you could add the two DN pointers
first (atomically), and be sure that a client that stumbled onto
the rule during the small window of time when one of the conditions
had been added but the other one had not, would know that it wasn't
supposed to use the rule.  But this seems like a mighty rare case
to worry about.

It's also the case that the DN pointers you've proposed don't
close all the possible consistency holes.  Suppose, for example,
that the policy administrator wants to change from (A AND NOT B)
to (NOT A AND B).  Since the two policyRuleConditionAssociation
objects can't be updated atomically, an extremely unlucky client
might retrieve a subtree that contains either (A AND B) or
(NOT A AND NOT B).  Other cases could be constructed as well:
reordering actions, moving a condition from one group to another,
etc.

So, my question to you (and to others following this thread) is
this:  given that we aren't going to be able to close 100% of
these holes, is the hole closed by your DN pointer attributes
a sufficiently common (and sufficiently damaging) one to
justify the cost of implementing the attributes?  In answering
this question, I think we should assume that policy input is
being handled by a Policy Management Tool (as opposed to
something like a command line), and that this tool enforces
directory update practices that minimize the windows of
inconsistency as much as the LDAPv3 protocol itself allows.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

"Yoram Snir" <[email-masked]> on 08/19/99 03:11:54 AM

Please respond to [email-masked]

To:   "'Ryan Moats'" <[email-masked]>, Robert Moore/Raleigh/IBM@IBMUS
cc:   "'Yoram Ramberg'" <[email-masked]>, "'Policy Mailing List'"
      <[email-masked]>
Subject:  RE: LDAP, the Core & the QoS inf. model

Bob, Ryan
There is still the problem of identifying corrupt rules, i.e., rules that
some conditions are missing from their condition list, the same goes for
actions and triggers. Relying on the location of the conditions.

The SDN mechanism had a lot of problems but it did allow "rule corruption"
check with in the rule:
* check that every condition (by SDN values) exist and is not corrupt.
* Do not include conditions that are located under the rule an are not in
the SDN value set.

If we choose what Ryan suggest we need an alternative.
The alternative mechanism is to have a conditionlist of type DN, in the
rule. It means that such rule corruption test is possible, although we do
not use non-standard mechanisms.
The rule's Boolean expression would be interpreted by the conditionItem
attribute, but the rule's conditionlist would be used to check that all
relevant conditions exist and conditions were not added just based on their
location.

Yoram Snir
Cisco Systems
mailto:\\[email-masked]
Tel. 972-9-9700085

> -----Original Message-----
> From: Ryan Moats [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 7:03 PM
> To: [email-masked]
> Cc: [email-masked]; Yoram Ramberg; 'Policy Mailing List'
> Subject: RE: LDAP, the Core & the QoS inf. model
>
>
> | The end of the week is fine if you can do the updates.  It might be
> | easier if you just supplied the ABNF, rather than interleaving it
> | with the old format to be removed.
>
> No problem, its on my list of to do things to finish by Friday, and I
> will send ABNF without the old format
>
> | One other thought has occurred to me.  I think we could simplify
> | the CIM-to-LDAP mapping, and also remove an aspect of the LDAP
> | schema that some people have questioned, by replacing policyInstance
> | with two structural classes policyConditionInstance and
> | policyActionInstance.  Then we could move the naming attributes out
> | of the AUX classes, and put them into the structural classes.  Thus,
> | for example, the same attribute policyConditionName would
> be included
> | as the naming attribute in both policyRuleConditionAssociation and
> | policyConditionInstance.  Discipline-specific schemata could then
> | subclass from policyCondition and policyAction, while using the two
> | fixed pairs of instance anchors from the Core Schema:
> | policyRule*Association for rule-specific conditions and actions, and
> | policy*Instance for reusable ones.
>
> I have to think about this some more to make sure that we aren't
> losing anything.  I plan on doing that as I put together the
> updated ABNF.
>
> Ryan
>
>

---

From: "Yoram Snir" <[email-masked]>
Date: Fri, 20 Aug 1999 12:30:13 +0200

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: 'Ryan Moats' <[email-masked]>; 'Yoram Ramberg' <[email-masked]>;
'Policy Mailing List' <[email-masked]>
Sent: Thursday, August 19, 1999 5:01 PM
Subject: RE: LDAP, the Core & the QoS inf. model

> policyRuleConditionAssociation points to?
The DN points to every conditionItem (all of them under the PolicyRule),
whether the conditionItem has a local condition attached or has a dn pointer
to a reusable condition in the repository.

> to conditions, one pointing to actions?)

No, just one pointing to its sons (let the "policy readers" be sure that the
right conditionItems are located under the rule, and no one is missing).
The other pointers are the one from the conditionItem to a reusable
condition (attached to a policyInstance entry), but these poinetrs are in
this proposal anyway.

 I thought that by using
> that a client will "catch" the rule in an inconsistent state.

That is exactly my point, you can always know when a rule is inconsistent
and deal with it, meaning you will remove the son and then update the rule.
Durring the editing process the rule is unusable, as it should be. If for
example you would want to remove 2 conditions:
After the first condition is removed, the rule is logically corrupt, but
perferctly valid for a reader that reads the DIT.
If you add the DN attribute, the rule will be checked by the reader and he
will know that it is broken.
The process would look like that:
1. remove condition1
now the rule is broken - DN set  does match condition sons
2. remove condition2
rule is still broken
3. update DN list
Rule is updated and consistent.

If we do not have the DN list, afer step 2, the rule looks consistent,
although it is broken logically.

> supposed to use the rule.  But this seems like a mighty rare case

I am not sure we can have incosistency in network policy information.
> reordering actions, moving a condition from one group to another,
True, if done in the the wrong sequence.
The right should be:
1. dn list to null or add some arbitrary DN that does not match - meaning
the "rule is broken"
2. Update conditions
3. fix DN list in rule  meaning " rule could be used".

> inconsistency as much as the LDAPv3 protocol itself allows.

I think it is very important, especially for network policy, and I think we
can supply the mechanism in the schema to overcome these small, or not so
small, periods of inconsistencies while updating the policies.