Subject: RE: LDAP or RDBMS for policy storage?

From: Randy Bush <[email-masked]>
Date: Tue, 3 Aug 1999 10:05:35 -0700 (PDT)

> LDAP is simply an interface, not a specification of storage.  There really
> is no such thing as an "LDAP directory" - any data store that exposes an
> LDAP interface can be called that.  Certainly through convention, there are
> things we call "LDAP directories" - but the point is, the internals of those
> directories can have ANY structure.

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?

randy

---

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

What is really required of the data store is that there is a means of
mapping the Policy schema into it.  And LDAP is a convenient, standard way
of describing schema, which can then be mapped on to whatever internal
representation the data store has.

So personally, I don't see a conflict between the two statements - as long
as the above is taken into account.

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

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Tuesday, 03 August 1999 12:35 PM
To: Michael Richardson
Cc: Policy mailing list
Subject: Re: LDAP or RDBMS for policy storage? 

> The Policy WG is not supposed to be storage centric.

please explain how this relates to statements i thought i heard that the
actual definition of the policy would be the ldap interface to it.

randy

---

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

| > LDAP is simply an interface, not a specification of storage.
| There really
| > is no such thing as an "LDAP directory" - any data store that exposes an
| > LDAP interface can be called that.  Certainly through
| convention, there are
| > things we call "LDAP directories" - but the point is, the
| internals of those
| > directories can have ANY structure.
|
| 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?
|
| randy

Well, in my opinion ;-) the ABNF that I've proposed (with Al's correction)
and a small edit to the containment rules (which need to get added... I'll
see about adding them later this week or next week) handle most of the
impedence mismatches that can be handled with LDAP.

One thing that didn't seem to show up in the minutes of the Colorado
interim meeting were the discussions about the security requirements and
how LDAP meets (or doesn't meet) them.  Does somebody have the list
of requirements handy so we can thrash this out on the mailing list and
get that discussion captured in the LDAP schema document [my memory is that
they aren't there and should be]?

Ryan

---

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

Although its hierarchical implementation presents some problems, I
think a greater concern is the simplicity of the underlying data model
of LDAP. But on the other hand, I would argue that if you get into
those types of issues (e.g., transactional and referential integrity)
you are probably misusing the directory. This is why we recommended a
directory as ONE of possibly several data stores in the policy system.

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

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

---

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

I heartily agree about the misnomer "LDAP directory" - that phrase is
completely meaningless. Let me expand a little on what Mark is saying.
Note that the information model uses some powerful OO concepts, such
as association and aggregation, that are not directly expressible in a
directory implementation. Hence, the use of the term "mapping" to
translate such concepts to a form that is implementable using a
directory. Furthermore, such mappings will be necessarily different
for different target repositories (e.g., the mappings to a directory,
RDBMS, and OODBMS will all be different to some degree).

However, as we get deeper and deeper into policy implementations, I
suspect that there will be some policy data and concepts that simply
are not amenable to storage in a directory. Data examples are easy to
think of (e.g., counters that are required to report on the current
state of the network). Concepts, such as constraints between two
objects, will also be next to impossible to represent in a directory.
In addition, the policy data itself may require sufficient structure
as to make its implementation problematic using a directory.

On the other hand, no one has used examples such as these yet.

regards,
John Strassner

---

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

Inline.
*Yoram
----- Original Message -----
From: John Strassner <[email-masked]>
To: Beadles, Mark A. <[email-masked]>; 'Randy Bush' <[email-masked]>;
Michael Richardson <[email-masked]>
Cc: Policy mailing list <[email-masked]>
Sent: Tuesday, August 03, 1999 4:22 PM
Subject: Re: LDAP or RDBMS for policy storage?

> On the other hand, no one has used examples such as these yet.

Constraints were quite a challenge. We ended up describing the constraints
but not modeling them in the schema. We completely gave up on representing
transient information, such as run-time status, in the directory (and
modelling this in the schema, of course). As it turns out, LDAP access is
available to policy data only. This is incomplete and requires a lot of
implementation around the repository. Clearly, commodity RDBMS would be a
richer storage platform for policy data. We use LDAP because this is what
the world wants. A reasonably justified excuse.

This leaves us with an interesting interoperability problem. If we want
policy servers (for those who want to think about them as PDPs -- by all
means, do that) from diferent vendors to enforce the very same policy given
the same policy DIT, we have to have something more than just the DIT. This
may include non-directory storage and even some "thick" API layer as well.
The dilema is that doing that defeats the cause of providing a standard
policy repository. Maybe we can have a standrd schema and standard access
(LDAP) but we can't model a policy system based on that alone. Disappointing
indeed. (Some might view that as an opportunity...)
*Yoram

---

From: "Yoram Snir" <[email-masked]>
Date: Wed, 4 Aug 1999 17:29:02 +0200

Please see comments inline.

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Yoram Ramberg
> Sent: Wednesday, August 04, 1999 9:54 PM
> To: John Strassner; Beadles, Mark A.; 'Randy Bush'; Michael Richardson
> Cc: Policy mailing list
I disagree with the last statement, if the policies AND the decision
strategy to be applied on these policy rules are defined in a consistent way
that does not leave any room for interpretation, a policy model can rely on
LDAP.
Implementations need to deal with the lack of capabilities LDAP suffers
compared to RDBMs, but it can be done.

The decision process needs to deal not only with the type of decision (first
match, match all...) but with complete order between rules and single
interpretation of conditions and action.
This will be part in the soon to be released next version of the
draft-snir-qos-policy-infomodel-01.txt.

In general the information model should be separated from the schema (LDAP).

As for placing constraints on the way DITs are built to allow for more
efficient LDAP operations, this, IMHO, is an implementation issue. You may
choose to place conditions under rules but you must also have their DNs in
the rule itself. It is necessary to do so sense in most cases the management
tool configuring the policy in the directory does not own the directory.
Another reason is the ability for sharing objects between policy rules
(reusable objects).

Yoram Snir

> > > LDAP is simply an interface, not a specification of
> storage.  There
> > really
> > > things we call "LDAP directories" - but the point is, the
> internals
> > of those
> > > please explain how this relates to statements i thought i
> heard that
> > the