Subject: RE: LDAP or RDBMS for policy storage?

From: "Beadles, Mark A." <[email-masked]>
Date: Tue, 3 Aug 1999 13:18:54 -0400

>what if the semantic limitations of ldap's hierarchic directory assumptions
>are so visible through the interface that they cause impedence mismatches
>with the structures needed to represent the policy?

A valid concern.  But two things  - first, I believe it is still possible to
map from the hierarchical LDAP model onto a RDBMS model without significant
impedance mismatch, if you implement it right.  I say this because
directories are actually built on top of some other database, which can be a
RDBMS.

Second, I believe we may find that hierarchy is actually required to
adequately describe Policy in general.  It certainly has been found to be
useful in other similar problem areas.

One thing you do NOT want to do, however, is expose things in the interface
that are not strictly part of the policy schema.  And, one must be very
careful not to make assumptions about where things _absolutely_ are in the
data store.  You want the schema flexible enough to live in any data store,
even one that does not place things in the same absolute location.  e.g.
don't make the assumption that there is some geography-based hierarchy where
objects called "users" are always kept, if the "user" object is relevant to
the bit of schema in question.  Otherwise you will find that it really is
impossible to make the schema storage-neutral.

+ Mark Anthony Beadles +  UUNET Product Development  + 
+  [email-masked]   + http://networking.us.uu.net +
+  Voice 614.723.1941  +       Fax 614.723.8407      +

---

From: "Ryan Moats" <[email-masked]>
Date: Tue, 3 Aug 1999 12:28:07 -0500

| >what if the semantic limitations of ldap's hierarchic directory
| assumptions
| >are so visible through the interface that they cause impedence mismatches
| >with the structures needed to represent the policy?
|
| A valid concern.  But two things  - first, I believe it is still
| possible to
| map from the hierarchical LDAP model onto a RDBMS model without
| significant
| impedance mismatch, if you implement it right.  I say this because
| directories are actually built on top of some other database,
| which can be a
| RDBMS.
|
| Second, I believe we may find that hierarchy is actually required to
| adequately describe Policy in general.  It certainly has been found to be
| useful in other similar problem areas.
|
| One thing you do NOT want to do, however, is expose things in the
| interface
| that are not strictly part of the policy schema.  And, one must be very
| careful not to make assumptions about where things _absolutely_ are in the
| data store.  You want the schema flexible enough to live in any
| data store, even one that does not place things in the same absolute
location.  e.g.
| don't make the assumption that there is some geography-based
| hierarchy where objects called "users" are always kept, if the "user"
object is
| relevant to the bit of schema in question.  Otherwise you will find that
it really is
| impossible to make the schema storage-neutral.

While I agree with Mark's statement, I want to make sure that "not to make
assumptions about where things _absolutely_ are in the data store" is not
the same is "not to make assumptions about where _anything_ is in the data
store".  As my earlier discussion with the Yorams points out, using
judiciously
chosen local containment rules can be very useful in organizing the schema.

Ryan

---

From: "John Strassner" <[email-masked]>
Date: Tue, 3 Aug 1999 14:32:05 -0700

comments inline.

regards,
John Strassner
Co-Chair, Policy Framework working group

----- Original Message -----
From: Beadles, Mark A. <[email-masked]>
To: 'Randy Bush' <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Policy mailing list
<[email-masked]>
Sent: Tuesday, August 03, 1999 10:18 AM
Subject: RE: LDAP or RDBMS for policy storage?

> directories are actually built on top of some other database, which
can be a

[js] True, but then you will usually give up something (e.g., read
performance). This is an implementation-specific rathole that I will
side-step for now ;-)  I think that Randy was getting at the
underlying data model of LDAP, and whether it was sufficient or not to
handle all aspects of policy.

> useful in other similar problem areas.

[js] One good example of hierarchy is to implement containment.
Another is to limit scoping of, for example, searches. So I generally
agree with you.

> impossible to make the schema storage-neutral.

[js] agreed

---

From: "Yoram Ramberg" <[email-masked]>
Date: Wed, 4 Aug 1999 14:38:14 -0500

> chosen local containment rules can be very useful in organizing the
schema.
I figured you might want to respond to that. However, I don't understand
your response. If it's true that assuming location of objects in the DIT is
not advised, why, then, placing objects in a specific location in the
hierarchy is legitimate? Your argument justifying placing rule elements
(conditions, actions) directly "under" the rule in order to optimize access
does exactly that, no? You assume that fetching the complete rule would
require one LDAP search that brings back a node and its sub-tree. Isn't that
the very location-dependent assumption so strongly advised against? Don't we
assume a lot about the storage model by requiring a single LDAP search to
fetch a sub-tree?

I know I'm not unraveling a major new truth to you, just want to hear an
explanation for my personal education...
Thanx, *Yoram

---

From: "Ryan Moats" <[email-masked]>
Date: Wed, 4 Aug 1999 07:57:58 -0500

More inline comments

[snip...]

| > | data store.  You want the schema flexible enough
| > | to live in any data store, even one that does not
| > | place things in the same absolute location.  e.g.
| > | don't make the assumption that there is some
| > | geography-based hierarchy where objects called
| > | "users" are always kept, if the "user" object is
| > | relevant to the bit of schema in question.
| > |  Otherwise you will find that it really is
| > | impossible to make the schema storage-neutral.
| >
| > While I agree with Mark's statement, I want to make sure
| > that "not to make assumptions about where things 
| > _absolutely_ are in the data store" is not the same is
| > "not to make assumptions about where _anything_ is in the
| > data store".  As my earlier discussion with the Yorams
| > points out, using judiciously chosen local containment
| > rules can be very useful in organizing the schema.
|
| I figured you might want to respond to that. However,
| I don't understand your response. If it's true that
| assuming location of objects in the DIT is not advised,
| why, then, placing objects in a specific location in the
| hierarchy is legitimate? Your argument justifying placing
| rule elements (conditions, actions) directly "under" the
| rule in order to optimize access does exactly that, no?
| You assume that fetching the complete rule would
| require one LDAP search that brings back a node and its
| sub-tree. Isn't that the very location-dependent assumption
| so strongly advised against? Don't we assume a lot about
| the storage model by requiring a single LDAP search to
| fetch a sub-tree?

I think there is some confusion (likely because my original
explanation wasn't clear enough).  What I read (and I think
Mark agreed to) 'absolutely' to mean above is that we
have specified all structural rules and RDNs for the DIT so that
everything is in a fixed place.  I agree that this is
a BAD idea. However, this is not the same as specifying
any structural rules (which is what I was trying to say
above).  If it helps, think of it as "its bad to specify
the global environment, but its ok to specify the local
environment, so long as there aren't enough local rules to
result in a global specification when combined."

Ryan

Ryan