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

From: [email-masked]
Date: Wed, 18 Aug 1999 10:50:50 -0400

Ryan,

OK, I found the new classes in your earlier ABNF -- it's going to
take me a while to get used to reading it!

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.

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.

Regards,
Bob

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

"Ryan Moats" <[email-masked]> on 08/18/99 09:51:34 AM

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

| I've been following this thread, and I'm in basic agreement with
| where it seems to be coming out.  I've started looking at what this
| approach will mean on the DMTF side (and hence on the information
| model I-D in the IETF).  I expect to have something preliminary on
| this by the end of the week.

| Ryan, I agree with Yoram (although I forget *which* Yoram:-) that
| the discussion has moved beyond the original ABNF that you provided.
| Specifically, I think you've added two more classes, to contain the
| attributes from the CIM associations, and optionally a pointer to a
| policy condition or policy action.  In your example you implied that
| these classes could be named policyRuleConditionItem and
| policyRuleActionItem, but I think a better choice would be
| policyRuleConditionAssociation and policyRuleActionAssociation.
| In my mind these would be structural subclasses of the abstract
| class policy, with the association attributes (plus a class-specific
| naming attribute) mandatory and the DN pointer attributes optional.
| The DN pointer would be omitted if and only if an instance had its
| condition / action AUX-attached to itself.

I don't think I care about the name of the classes so I can
make the changes you suggest. BTW, the ABNF already
has these classes and rules.

| One other simplification occurs to me.  Rather than having *three*
| places to put a condition or action, I think we could eliminate the
| option of AUX-attachment to a policyRule, since a client will
| (or at least should) always retrieve the subtree under a policyRule
| when it retrieves the policyRule.  What was formerly a simple rule
| would thus become a policy rule that DIT-contains a
| policyRuleConditionAssociation object and a policyRuleActionAssociation
| object, which in turn have a condition and an action AUX-attached
| to them.

If you do a subtree search, you will always retrieve the subtree, so
I can live with this simplification.

| Ryan, I'm going to try to produce an updated LDAP schema I-D by the
| end of the month.  Will you have a chance to update your ABNF, or am
| I on my own trying to tweak it to represent what we're now saying?

Well, I can't do anything today, but I can do something by the end
of the week.  Do you want in a similar format to the previous changes
or what?

Ryan

---

From: "Ryan Moats" <[email-masked]>
Date: Wed, 18 Aug 1999 12:03:17 -0500

| 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: Thu, 19 Aug 1999 09:11:54 +0200

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'

---

From: "Ryan Moats" <[email-masked]>
Date: Thu, 19 Aug 1999 10:04:03 -0500

Having started to work on the ABNF, I now understand this suggestion
and I LIKE it.  It meshes with the rest of whats going on quite nicely,
so the new ABNF will include it.

Ryan