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

From: "Ryan Moats" <[email-masked]>
Date: Mon, 16 Aug 1999 08:37:08 -0500

My comments are inline...

| [This message is a follow-up to a thread started by Ryan Moats'
| proposals for improvement of the schemata presented in Oslo (both Core
| and QoS Schema (draft-snir-qos-policy-infomodel.txt))].

I'm going to delete most of the requirements to save BW. However,

| 6. The policy schema does not own the DIT, but uses it. Counting on
| location as the policy definition tools is not a good idea.

This has got to be turning into a "urban legend".  Yes, the policy
schema does not own the ENTIRE DIT.  But, the policy schema has
every right to say "this object should go under this other object
which can go anywhere" which is what my proposal does. If you say
the policy schema does not own ANY PORTION OF THE DIT, then you
are removing some of your tools in LDAP.  Why do it?

| Strong location requirement and SDNs
| -----------------------------------------------------
| Ryan Moats proposes several techniques. The proposals all require DIT
| location management. Let's start simple: To construct a complex
| condition that can be fetched with one LDAP query, Ryan places all
| components of the complex condition in the DIT under the rule. This
| means that when you need to fetch a rule, you fetch the rule's subtree.
| Ryan guarantees to you that if you fetch the subtree you fetch
| everything needed to interpret the rule: All actions, conditions, values
| and variables will be in that subtree. We'll call this the strong
| location requirement.

One reason for doing this is that X.500 and LDAP are currently working
towards a method for storing groups of attributes.  They plan on using
DIT containment to do it.  Why re-invent the wheel?

| Strong location requirement may be too strong. It requires that *all*
| objects are organized in the DIT in such a way that reading a rule and
| its subtree will always bring back all the components of the complex
| object (the rule, in this case). This is clearly not supportive of
| reusability, thus violating requirement #2 above. By definition, if all
| objects used by a rule must reside in a certain place, another rule
| would not be able to make use of a component if it's already strongly
| located elsewhere. The need for DNs at the rule level is also
| questionable and is used merely for validation (it allows us to separate
| rule components from other things that happen to be in the subtree. It
| also allows us to insure that all components are present). Non reusable
| objects are perfectly legal in the QoS schema, but they have a lightly
| different structure and arguably stricter semantic rules.

What I am proposing is not how "all" objects are organized in the
tree.  What I am proposing is how individual items are grouped under a
policy rule.  Further, I have stated that my original proposal should be
changed to allow simple conditions to be included in an individual item
condition either by DN reference (reusable) or by attached object class
(not-reusable).

| Even more disturbing is the encoding of group nr. and negation flag
| inside the component itself. What this means is that we add specialized
| information to a simple condition, which may render it useless for
| referencing. For example: The condition 'SourceIP == MyServer AND
| SourcePort == WebPort' has two component simple condition. If we encode
| group nr. into both simple conditions we'll never be able to reuse these
| simple condition to form the complex condition 'SourceIP == MyServer OR
| SourcePort == WebPort'. Certainly an unfortunate consequences of this
| form of encoding.

Look, I'm talking about the LDAP schema, not the information model.  We
need to use DIT containment to improve LDAP storage and retrieval
efficiency and we should allow simple conditions to be included either
by DN reference or buy aux class attachment to give administrators the
freedom to make their own optimization decisions.

| A slightly modified version of Ryan's proposal may help. Instead of
| *requiring* all components to reside in the subtree, we
| *recommened* it but the reader should not assume that it is the case.
| Therefore, a complex condition could be made of several simple
| conditions, where some are located as rule leaves and some are
| pointed to by DNs. This appears to provide some reusability and
| makes use of the DN list in the parent (the rule). When reading a rule,
| it is *recommended* to read the subtree because
| we *encourage* people to collocate rule components as described
| above. However, the reader must verify that all components are indeed
| collocated. This is done by going over the DN list and marking the
| objects that need to be fetched. One could form a complex condition
| locally most of the time. This reduces the overall round-trip count, under
| some assumptions about how designers should bias their design.
| The strongest strike against weak location is that it still does nothing
| for the SDN problem (already mentioned before): SDNs model the
| relationships among condition components -outside- of the component
| object, while weak location schemes place this info -inside- the
| reusable component. We deem this restriction very harsh. The complex
| condition in the previous example would not be able to share objects or
| they lose the AND/OR semantics. Unfortunately, LDAP lacks a facility to
| model ordered lists (vectors, arrays, tables, whatever). This LDAP
weakness
| prevents us from modeling the intra-condition relationships in a parent
| resident array. In fact, SDNs were conceived to tackle this very
difficulty
| to create a three-tuple table {DN, group, negation} It is worth noting
that
| even SDNs can't model order. LDAP can model sets in multi-valued
| attributes, but LDAP guarantee no order among members. This means that
| the use of SDN is restricted. Fortunately, Boolean conditions can be
| fully modeled as unordered lists of SDNs.
|
| What if we compromised on this:
|
| The schema is based on the weak location requirement as described in the
| previous paragraph. However, we move the "extra" Boolean relations back
| into the parent. SDN appears to be not liked by some, but for now it is
| the best mechanism that allows for locating this information at the
| parent (which, it appears, is desired).

I do not view this as a compromise.  SDNs are superfulous because they are
not a standard syntax and don't add anything beyond what you get with
DIT containment when you allow simple conditions to be included in child
objects
either by DN reference or by aux class attachment.

| #1 is clearly supported. The modified model has the very same expressive
| power as the one proposed in the QoS schema draft. The retention of SDNs
| is the key.

I claim that the DIT containment model (using either DN references or
aux class attachment) has the same expressive power and doesn't rely
on non-standard syntax.

| #2 is also in a pretty good shape. We can model reusable objects
| repository and manage them centrally (including limited integrity
| constraints). Furthermore: We now can assume that caching repositories
| would be a single LDAP operation. (Note that there's ample room for
| refinements here)

Because the child-class method can use DNs, simple rule object reusability
is maintained.

| #3 the schema allows the users, even encourages to organize the
| DIT in collocation hierarchical model. Implementers should assume
| that this is the common case, but while digesting the policy information
| make sure the expression are full and consistent with the help of the SDN
| values. Adding this usage recommendation will cut down the number of LDAP
| roundtrips for policy retrieval with out breaking the flexibility and
| consistency of the model.

My comments about using SDNs as "checking" information are below.

| #5 Retrieved objects residing under a specific rule will be
| checked to make sure they are the full set of conditions relevant to this
specific
| rule, unrelevant ones would be ignored and missing conditions will be
retrieved.
| This will be done by comparing the retrieved set of condition to the SDN
| values in the rule. The same goes for the action and trigger  list.

If you need a check, then the check goes both ways ("why should I believe
that the SDN is correct and not the children when there's a difference").
Therefore you would need to check both, which results in the inefficiencies
of both solutions and the efficiencies of neither.

| #6 See #5.

My comments about #6 are above.

We seem to be in agreement in everything except the "DIT containment issue".
My proposal is consistent with current LDAP standards, while SDNs would
require either special client code or work to standardize the SDN syntax
in LDAP.  Futher, while my proposal is structured to take advantage of
ongoing work in X.500 and LDAP, e.g. families and dereferencing match, it
can be implemented today before that work is finished.

Ryan

---

From: "Yoram Snir" <[email-masked]>
Date: Tue, 17 Aug 1999 17:31:37 +0200

My comments inline.

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

> -----Original Message-----
> From: Ryan Moats [mailto:[email-masked]]
> Sent: Monday, August 16, 1999 3:37 PM
> To: Policy Mailing List
> Cc: John Strassner; Yoram Snir; Yoram Ramberg
> Subject: Re: LDAP, the Core & the QoS inf. model
>
>

You should use the tools LDAP gives you, but LDAP should not enforce your
information model to be weak, for example, loose the ability to use an
object that is located somewhere else, either reusable object or not.

> | Strong location requirement and SDNs
We do not disagree.
> condition either by DN reference (reusable) or by attached

Now the problem of defining the Boolean operators on these conditions, such
as negation or grouping, comes up.
If you place the Boolean operator definition in the condition itself, it
can't be used by another object.
Example:
Rule1: C1 & ! C2 then A1.
Rule2: C2 & C3 then A2
C2 should be reused by both Rule 1 and Rule 2.
The DIT should be built in such a way that rule1 is the father of C1 and A1,
and Rule 2 is the father of C3 and A2.
The location of C2 according to our proposal is in the condition repository.
In order to fetch Rule 1, you will use one LDAP search for the rule and its
sons (C1 and A1) and another search to bring all the reusable conditions, C2
included.
Fetching Rule2 means a single LDAP search, the reusable conditions have been
fetched already.
The conditionlist type(CNF/DNF) and SDN are now used to build type Boolean
equation, for example, negate C2 in rule1.

If we drop the SDN, and rely on the location of the condition objects, we
either define two C2 objects, one with a negate sign, and place each object
under the right rule or define it once (reusable object) and refer to it
using DN from rule1 and rule2. The question is how do we know that C2 should
be negated in Rule1?
The same problem exist with parenthesis (grouping).

SDNs and condition list type definition are not ideal, but they allow the
required flexibility.

> of both solutions and the efficiencies of neither.

The checks are rule based, meaning we check the validity of a rule, not the
validity of a condition, or a condition group if a rule does not use them.
For each rule, we must check that the relevant conditions exist and are not
corrupt, for that we use the SDN. We could have used DNs but then we would
have the problem of missing Boolean operators, see example above.
I don't think you have to check both ways, a condition that is not used by
any rule should not be checked, the same for actions or triggers.

The bottom line, IMHO, is that the only real different between these two
approaches are the use of SDNs as defined in the Core schema. As far as
placing objects under their logical father for LDAP efficient searches, we
agree, unless these are reusable objects. Reusable objects should be fetched
anyway, so I don't think this is a real issue.
As for SDN, alternatives must supply the flexibility in expressive power SDN
has.

---

From: "Ryan Moats" <[email-masked]>
Date: Tue, 17 Aug 1999 10:06:32 -0500

| My comments inline.

Ditto

| > My comments are inline...
| >
| > | [This message is a follow-up to a thread started by Ryan Moats'
| > | proposals for improvement of the schemata presented in Oslo
| > (both Core
| > | and QoS Schema (draft-snir-qos-policy-infomodel.txt))].
| >
| > I'm going to delete most of the requirements to save BW. However,
| >
| > | 6. The policy schema does not own the DIT, but uses it. Counting on
| > | location as the policy definition tools is not a good idea.
| >
| > This has got to be turning into a "urban legend".  Yes, the policy
| > schema does not own the ENTIRE DIT.  But, the policy schema has
| > every right to say "this object should go under this other object
| > which can go anywhere" which is what my proposal does. If you say
| > the policy schema does not own ANY PORTION OF THE DIT, then you
| > are removing some of your tools in LDAP.  Why do it?
| >
|
| You should use the tools LDAP gives you, but LDAP should not enforce your
| information model to be weak, for example, loose the ability to use an
| object that is located somewhere else, either reusable object or not.

I'll pass on this one, because I think it stems from confusion below...

| > | Ryan Moats proposes several techniques. The proposals all
| > require DIT
| > | location management. Let's start simple: To construct a complex
| > | condition that can be fetched with one LDAP query, Ryan places all
| > | components of the complex condition in the DIT under the rule. This
| > | means that when you need to fetch a rule, you fetch the
| > rule's subtree.
| > | Ryan guarantees to you that if you fetch the subtree you fetch
| > | everything needed to interpret the rule: All actions,
| > conditions, values
| > | and variables will be in that subtree. We'll call this the strong
| > | location requirement.
| >
| > One reason for doing this is that X.500 and LDAP are currently working
| > towards a method for storing groups of attributes.  They plan on using
| > DIT containment to do it.  Why re-invent the wheel?
| We do not disagree.

Good

| >
| > | Strong location requirement may be too strong. It requires
| > that *all*
| > | objects are organized in the DIT in such a way that reading
| > a rule and
| > | its subtree will always bring back all the components of the complex
| > | object (the rule, in this case). This is clearly not supportive of
| > | reusability, thus violating requirement #2 above. By
| > definition, if all
| > | objects used by a rule must reside in a certain place, another rule
| > | would not be able to make use of a component if it's
| > already strongly
| > | located elsewhere. The need for DNs at the rule level is also
| > | questionable and is used merely for validation (it allows
| > us to separate
| > | rule components from other things that happen to be in the
| > subtree. It
| > | also allows us to insure that all components are present).
| > Non reusable
| > | objects are perfectly legal in the QoS schema, but they
| > have a lightly
| > | different structure and arguably stricter semantic rules.
| >
| > What I am proposing is not how "all" objects are organized in the
| > tree.  What I am proposing is how individual items are grouped under a
| > policy rule.  Further, I have stated that my original
| > proposal should be
| > changed to allow simple conditions to be included in an
| > individual item
| > condition either by DN reference (reusable) or by attached
| > object class
| > (not-reusable).
|
| Now the problem of defining the Boolean operators on these
| conditions, such
| as negation or grouping, comes up.
| If you place the Boolean operator definition in the condition itself, it
| can't be used by another object.
| Example:
| Rule1: C1 & ! C2 then A1.
| Rule2: C2 & C3 then A2
| C2 should be reused by both Rule 1 and Rule 2.
| The DIT should be built in such a way that rule1 is the father of
| C1 and A1,
| and Rule 2 is the father of C3 and A2.
| The location of C2 according to our proposal is in the condition
| repository.
| In order to fetch Rule 1, you will use one LDAP search for the
| rule and its
| sons (C1 and A1) and another search to bring all the reusable
| conditions, C2
| included.
| Fetching Rule2 means a single LDAP search, the reusable
| conditions have been
| fetched already.
| The conditionlist type(CNF/DNF) and SDN are now used to build type Boolean
| equation, for example, negate C2 in rule1.
|
| If we drop the SDN, and rely on the location of the condition objects, we
| either define two C2 objects, one with a negate sign, and place
| each object
| under the right rule or define it once (reusable object) and refer to it
| using DN from rule1 and rule2. The question is how do we know
| that C2 should
| be negated in Rule1?
| The same problem exist with parenthesis (grouping).
|
| SDNs and condition list type definition are not ideal, but they allow the
| required flexibility.

AHA!  I think I see the point of confusion now.  Let me try and "draw" a
picture of how I see the children working, because I think I see the
confusion
(My apologies to anybody who isn't using fixed font widths):

+-------------+
| policyRule1 |
+-------------+
      |         +------------------------------+
      +---------| policyRuleConditionItem1     |
    c |         | policyRuleItemGroupNumber: 1 |
    h |         | policyRuleItemNegated: FALSE |
    i |         | policyRuleItemDN: ptr to C1  |
    l |         +------------------------------+
    d |
    r |         +------------------------------+
    e +---------| policyRuleConditionItem2     |
    n |         | policyRuleItemGroupNumber: 1 |
      |         | policyRuleItemNegated: TRUE  |
      |         | policyRuleItemDN: ptr to C2  |
      |         +------------------------------+
      |
      |         +------------------------------+
      +---------| policyRuleActionItem1        |
                | policyRuleItemGroupNumber: 1 |
                | policyRuleItemDN: ptr to A1  |
                +------------------------------+

+-------------+
| policyRule2 |
+-------------+
      |         +------------------------------+
      +---------| policyRuleConditionItem1     |
    c |         | policyRuleItemGroupNumber: 1 |
    h |         | policyRuleItemNegated: FALSE |
    i |         | policyRuleItemDN: ptr to C2  |
    l |         +------------------------------+
    d |
    r |         +------------------------------+
    e +---------| policyRuleConditionItem2     |
    n |         | policyRuleItemGroupNumber: 1 |
      |         | policyRuleItemNegated: FALSE |
      |         | policyRuleItemDN: ptr to C3  |
      |         +------------------------------+
      |
      |         +------------------------------+
      +---------| policyRuleActionItem1        |
                | policyRuleItemGroupNumber: 1 |
                | policyRuleItemDN: ptr to A2  |
                +------------------------------+

As you can see, the pointer to C2 is reused in the two children objects.
The attribute policyRuleItemNegated handles the statement of whether
the condition C2 is to be negated or not.  We don't define two C2 objects,
we define 2 children: one with the group number/negation rules for Rule1
and one with the group number/negation rules for Rule2.

| > | #5 Retrieved objects residing under a specific rule will be
| > | checked to make sure they are the full set of conditions
| > relevant to this
| > specific
| > | rule, unrelevant ones would be ignored and missing
| > conditions will be
| > retrieved.
| > | This will be done by comparing the retrieved set of
| > condition to the SDN
| > | values in the rule. The same goes for the action and trigger  list.
| >
| > If you need a check, then the check goes both ways ("why
| > should I believe
| > that the SDN is correct and not the children when there's a
| > difference").
| > Therefore you would need to check both, which results in the
| > inefficiencies
| > of both solutions and the efficiencies of neither.
| >
|
| The checks are rule based, meaning we check the validity of a
| rule, not the
| validity of a condition, or a condition group if a rule does not use them.
| For each rule, we must check that the relevant conditions exist
| and are not
| corrupt, for that we use the SDN. We could have used DNs but then we would
| have the problem of missing Boolean operators, see example above.
| I don't think you have to check both ways, a condition that is not used by
| any rule should not be checked, the same for actions or triggers.

I don't see (given the example above) the problem of missing Boolean
operators.

| The bottom line, IMHO, is that the only real different between these two
| approaches are the use of SDNs as defined in the Core schema. As far as
| placing objects under their logical father for LDAP efficient searches, we
| agree, unless these are reusable objects. Reusable objects should
| be fetched anyway, so I don't think this is a real issue.
| As for SDN, alternatives must supply the flexibility in
| expressive power SDN has.

I still see both solutions as equal flexibility, so I favor the
solution more in line with standards.  I don't see SDNs adding
anything except a syntactical burden.

Ryan

---

From: "Yoram Snir" <[email-masked]>
Date: Tue, 17 Aug 1999 21:45:15 +0200

Yoram Snir
Cisco Systems
[email-masked]
Tel. 972-9-9700085
----- Original Message -----
From: Ryan Moats <[email-masked]>
To: <[email-masked]>; 'Policy Mailing List' <[email-masked]>
Cc: 'John Strassner' <[email-masked]>; 'Yoram Ramberg' <[email-masked]>
Sent: Tuesday, August 17, 1999 5:06 PM
Subject: RE: LDAP, the Core & the QoS inf. model

> (My apologies to anybody who isn't using fixed font widths):
What you propose indeed works, the downside is the requirement of a
"wrapper" class for the condition, action and trigger classes.
That pro is that indeed you enjoy the standard DN capabilities defined in
LDAP.
If we are to move to the mechanism you propose, the change must be made in
the core schema, since the SDN mechanism was introduced there, and this
change is relevant to any policy system, not just QoS.
BTW, the condition list type stays in the rule, right?

> I don't see (given the example above) the problem of missing Boolean
true

> anything except a syntactical burden.
Lets here some other opinions, but you are right, they both offer the same
flexibility.

One general thing that your offer requires is the understanding that the
rule integrity relies on objects (condition items, action items and trigger
items) location. This is a major change to the current mechanism that is
location independent.

---

From: "Ryan Moats" <[email-masked]>
Date: Tue, 17 Aug 1999 14:05:22 -0500

| > | Now the problem of defining the Boolean operators on these
| > | conditions, such
| > | as negation or grouping, comes up.
| > | If you place the Boolean operator definition in the condition
| itself, it
| > | can't be used by another object.
| > | Example:
| > | Rule1: C1 & ! C2 then A1.
| > | Rule2: C2 & C3 then A2
| > | C2 should be reused by both Rule 1 and Rule 2.
| > | The DIT should be built in such a way that rule1 is the father of
| > | C1 and A1,
| > | and Rule 2 is the father of C3 and A2.
| > | The location of C2 according to our proposal is in the condition
| > | repository.
| > | In order to fetch Rule 1, you will use one LDAP search for the
| > | rule and its
| > | sons (C1 and A1) and another search to bring all the reusable
| > | conditions, C2
| > | included.
| > | Fetching Rule2 means a single LDAP search, the reusable
| > | conditions have been
| > | fetched already.
| > | The conditionlist type(CNF/DNF) and SDN are now used to build type
| Boolean
| > | equation, for example, negate C2 in rule1.
| > |
| > | If we drop the SDN, and rely on the location of the condition objects,
| we
| > | either define two C2 objects, one with a negate sign, and place
| > | each object
| > | under the right rule or define it once (reusable object) and
| refer to it
| > | using DN from rule1 and rule2. The question is how do we know
| > | that C2 should
| > | be negated in Rule1?
| > | The same problem exist with parenthesis (grouping).
| > |
| > | SDNs and condition list type definition are not ideal, but they allow
| the
| > | required flexibility.
| >
| > AHA!  I think I see the point of confusion now.  Let me try and "draw" a
| > picture of how I see the children working, because I think I see the
| > confusion
| > (My apologies to anybody who isn't using fixed font widths):
| >
| > +-------------+
| > | policyRule1 |
| > +-------------+
| >       |         +------------------------------+
| >       +---------| policyRuleConditionItem1     |
| >     c |         | policyRuleItemGroupNumber: 1 |
| >     h |         | policyRuleItemNegated: FALSE |
| >     i |         | policyRuleItemDN: ptr to C1  |
| >     l |         +------------------------------+
| >     d |
| >     r |         +------------------------------+
| >     e +---------| policyRuleConditionItem2     |
| >     n |         | policyRuleItemGroupNumber: 1 |
| >       |         | policyRuleItemNegated: TRUE  |
| >       |         | policyRuleItemDN: ptr to C2  |
| >       |         +------------------------------+
| >       |
| >       |         +------------------------------+
| >       +---------| policyRuleActionItem1        |
| >                 | policyRuleItemGroupNumber: 1 |
| >                 | policyRuleItemDN: ptr to A1  |
| >                 +------------------------------+
| >
| > +-------------+
| > | policyRule2 |
| > +-------------+
| >       |         +------------------------------+
| >       +---------| policyRuleConditionItem1     |
| >     c |         | policyRuleItemGroupNumber: 1 |
| >     h |         | policyRuleItemNegated: FALSE |
| >     i |         | policyRuleItemDN: ptr to C2  |
| >     l |         +------------------------------+
| >     d |
| >     r |         +------------------------------+
| >     e +---------| policyRuleConditionItem2     |
| >     n |         | policyRuleItemGroupNumber: 1 |
| >       |         | policyRuleItemNegated: FALSE |
| >       |         | policyRuleItemDN: ptr to C3  |
| >       |         +------------------------------+
| >       |
| >       |         +------------------------------+
| >       +---------| policyRuleActionItem1        |
| >                 | policyRuleItemGroupNumber: 1 |
| >                 | policyRuleItemDN: ptr to A2  |
| >                 +------------------------------+
| >
| > As you can see, the pointer to C2 is reused in the two children objects.
| > The attribute policyRuleItemNegated handles the statement of whether
| > the condition C2 is to be negated or not.  We don't define two
| C2 objects,
| > we define 2 children: one with the group number/negation rules for Rule1
| > and one with the group number/negation rules for Rule2.
| >
| What you propose indeed works, the downside is the requirement of a
| "wrapper" class for the condition, action and trigger classes.
| That pro is that indeed you enjoy the standard DN capabilities defined in
| LDAP.
| If we are to move to the mechanism you propose, the change must be made in
| the core schema, since the SDN mechanism was introduced there, and this
| change is relevant to any policy system, not just QoS.
| BTW, the condition list type stays in the rule, right?

The ABNF that I proposed already has these changes (In fact the example
above uses the attribute/class names from the ABNF).

As to the condition list type, yes, that remains as an attribute
of policyRule in the ABNF that I proposed.

 > | The bottom line, IMHO, is that the only real different
| between these two
| > | approaches are the use of SDNs as defined in the Core schema.
| As far as
| > | placing objects under their logical father for LDAP efficient
| searches,
| we
| > | agree, unless these are reusable objects. Reusable objects should
| > | be fetched anyway, so I don't think this is a real issue.
| > | As for SDN, alternatives must supply the flexibility in
| > | expressive power SDN has.
| >
| > I still see both solutions as equal flexibility, so I favor the
| > solution more in line with standards.  I don't see SDNs adding
| > anything except a syntactical burden.
| Lets here some other opinions, but you are right, they both offer the same
| flexibility.

Good!  Other opinions?

| One general thing that your offer requires is the understanding that the
| rule integrity relies on objects (condition items, action items
| and trigger items) location. This is a major change to the current
mechanism
| that is location independent.

Can you clarify what you are saying here?  I don't think I understand it...

Ryan

---

From: "Yoram Snir" <[email-masked]>
Date: Wed, 18 Aug 1999 08:57:08 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ryan Moats
> Sent: Tuesday, August 17, 1999 9:05 PM
> To: Yoram Snir; 'Policy Mailing List'
> Cc: 'John Strassner'; 'Yoram Ramberg'
What I mean is that the rule does not include the DNs of its conditions
(ConditionItems to be exact) but the conditions are associated to a rule
based on their location, as children of the rule.
This is different then the current SDN mechanism that has no requirement on
the location of the conditions. The same goes for actions and triggers.

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

---

From: "Yoram Ramberg" <[email-masked]>
Date: Wed, 18 Aug 1999 10:18:29 -0500

Ryan -

I have to admit that until I saw your example I hadn't fully understood your
approach. Maybe I should've worked some more examples with your ABNF
(although I think the presentation here differs from the original ABNF you
proposed, right?).

I agree that placing  "proxy" objects for simple conditions under the rule
to model complex condition does work. The CNF/DNF flag is part of the rule,
so no problem with flexibility and expressive power. Reusability is
supported without having to give up anything. You have added another degree
of indirection to compensate for the ditching of SDNs. Fine and dandy.

Now, a silly question: I hear a lot about DIT ownership (or absence
thereof). You labeled this an urban legend, but what's the real story with
this? How does one make sure that the rules are constructed according to
one's location requirement (even for the proxy objects) and that components
are correctly co-located? Obviously this can't be part of the schema because
there's no way to express DIT structure, is there?

I do feel somewhat uncomfortable with placing requirements that can't be
enforced (or even checked) on DIT constructors. After all, we're specifying
a schema, not DIT construction rules (or do we?)

While SDNs were always funny creatures, they provided a lightweight
solution, which was, arguably, politically incorrect. SDNs had a nice side
effect in that they allowed a completeness check for the complex condition
(you'd know if something was missing -- nice when you depend on
location...). It's maybe worth giving up for the cleaner proxy object
approach. Another alternative would be to place an attribute in the rule
that counts the number of components. This also suffers from the problem of
adding an unenforceable requirement (to assign a correct value to this
attribute).

...and yes, I'd like to hear other people's opinions as we're about to reach
agreement in this thread.

*Yoram

---

From: "Yoram Snir" <[email-masked]>
Date: Wed, 18 Aug 1999 11:00:53 +0200

Comments inline.

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

> From: Yoram Ramberg [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 5:18 PM
> To: Ryan Moats; [email-masked]; 'Policy Mailing List'
> Cc: 'John Strassner'

Counters will not do. What would is a list of DNs (for conditions, actions
and triggers), instead of SDNs.
The consistency of a rule, could then be checked without relying on the non
standard SDNs.

> > | You should use the tools LDAP gives you, but LDAP should
> not enforce
> your
> > | If we drop the SDN, and rely on the location of the
> condition objects,
> we
> > | SDNs and condition list type definition are not ideal,
> but they allow
> the
> > | required flexibility.
> >
> > | validity of a condition, or a condition group if a rule
> does not use
> them.
> > | corrupt, for that we use the SDN. We could have used DNs
> but then we
> would
> > | I don't think you have to check both ways, a condition
> that is not used
> by
> between these two
> > | placing objects under their logical father for LDAP
> efficient searches,
> we