Subject: LDAP or RDBMS for policy storage?

From: Atul Jain <[email-masked]>
Date: Tue, 03 Aug 1999 10:27:01 +0530

Hi,

My question is as what is better suited for policy storage: LDAP
directory or RDBMS?
The drafts in working group and the discussion in the mailing list
suggest that LDAP should be used for policy storage.

Following are some pros and cons of storing data in LDAP vs. RDBMS:
Pros:
-----
· This working group has given a standard LDAP schema for policies.
· Conforming to the LDAP schema makes the policy database standards
compliant which can then be read by any third party LDAP client.
· LDAP is optimized for few writes and lots of reads. This model suits
for polcies storage which will not be modified very often but may be
read very often.
· Most of the enterprises may already have an LDAP directory which they
may be using for storing user information etc. So that directory can be
enhanced to store the policies also.

Cons:
------
· LDAP does not have transaction support. Which makes it difficult to
maintain data consistency when multiple admnistrators are modifying the
policies in an organization.
This deficiency itself may decide one to choose and RDBMS rather than
LDAP directory. Any comments?

Regards
Atul

--
*****************************************
Atul Jain
Duet Technologies(I) Pvt. Ltd.
SDF #B1, NEPZ, Noida (U.P.) - 201305
India
Phone(Office): +(91)-(1191)-567001 to 567005
Phone(Home):   +(91)-(1191)-541919
mailto:[email-masked]
*****************************************

---

From: "Jason, Jamie" <[email-masked]>
Date: Tue, 3 Aug 1999 07:47:51 -0700

In my opinion, that is a matter of your requirements.  The core information
model is storage independent and LDAP is just one derivation of the core
information model.

Jamie

> -----Original Message-----
> From: Atul Jain [mailto:[email-masked]]
> Sent: Monday, August 02, 1999 9:57 PM
> To: Policy mailing list
> Cc: [email-masked]; [email-masked]
> Subject: LDAP or RDBMS for policy storage?
> 
> 
> Hi,
>

---

From: Andrew Milne <[email-masked]>
Date: Tue, 3 Aug 1999 11:18:28 -0400

Also, IMHO, suspect almost any implementation is going to need an RDBMS or
OODBMS at some stage of the implementation, probably adjacent to the policy
server. It's the nature of LDAP that it's pretty hard to search
intelligently on the kinds of selectors that matter in this problem space
(address ranges in particular), and this starts to smart when you're dealing
with a policy server standing right in the path of performance of
enforcement agents.

Solutions using both, I'd argue, aren't so crazy either. Local policy
published in LDAP using a schema so you can swap another policy server in
easily and pick up the same policy, OODBMS/RDBMS in the implementation layer
for easier searching.

-----Original Message-----
From: Jason, Jamie [mailto:[email-masked]]
Sent: Tuesday, August 03, 1999 10:48 AM
To: 'Atul Jain'; Policy mailing list
Subject: RE: LDAP or RDBMS for policy storage?

Jamie

---

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

>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.

Concur.

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

---

From: "Donkin, Richard" <[email-masked]>
Date: Wed, 4 Aug 1999 18:17:14 +0100

> From: Andrew Milne [mailto:[email-masked]]
>

Some other reasons to use an RDBMS or OODBMS alongside a directory include
ease of implementing concurrency control, availability of various tools for
quickly writing reports on policy data, and ease of modelling more complex
data (including topology).

> easily and pick up the same policy, OODBMS/RDBMS in the 

LDAP is a great way to allow various applications to retrieve and update
policies, and a dual solution does make sense as you say - publishing to a
directory for read-only access is easy, but read-write access is more
useful.   There are various solutions but using some form of synchronization
between the directory and the database seems to fit in with the directory
replication approach, providing loose consistency.  This means that
LDAP-enabled tools can modify policies and have them propagated through to
the database, which could be considered part of the implementation layer.
The challenge is to enable this replication to happen seamlessly and handle
conflicts appropriately, while conforming to the LDAP schema on one side and
the information model on the other.

One interesting issue in such a dual scenario is integrity - are consistency
checks performed at update time, at synchronisation time, or some other
time?  How are integrity violations flagged to the original updater if not
done at update time? Some form of centralised integrity checking is
desirable, rather than duplicating the integrity rules in the directory and
database domains.

Centralising integrity checking is in fact an issue even with two policy
management tools directly updating an LDAP-enabled policy datastore - which
tool maintains the integrity of the policy data (beyond the basic schema
semantics), or is this duplicated?  Validation was in
draft-sgai-policy-framework-00.txt as a separate component but seems to be
bundled into the policy management tool in draft-waters-policy-arch-00.txt.

Richard
-- 
[email-masked]                   http://www.orchestream.com
Tel: +44 (0)20 7598 7554 (direct)         Orchestream Ltd.
     +44 (0)20 7460 4460 (switchboard)    125 Old Brompton Road
Fax: +44 (0)20 7460 4461                  London SW7 3RP, UK
>>>>>>>>>>>>>>>>>>>>>> Bandwidth To Bank On >>>>>>>>>>>>>>>>>>>>>>>>