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

From: [email-masked]
Date: Wed, 18 Aug 1999 09:28:06 -0400

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.

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.

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?

Regards,
Bob

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

---

From: "Ryan Moats" <[email-masked]>
Date: Wed, 18 Aug 1999 08:51:34 -0500

| 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