Subject: Other mappings? (Was LDAP or RDBMS for policy storage?)

From: Andrew Milne <[email-masked]>
Date: Thu, 5 Aug 1999 11:50:56 -0400

Guess the next question then probably is: what are the advantages for the
vendors and the network as a whole of proposing additional mappings
(OODBMS/RDBMS) of the core data model as actual IETF standards? And I'm not
claiming to be the one to answer it -- I'm not going to claim I even fully
understand the point of the LDAP mapping (that is *not* a criticism of the
action that proposed it, by any means, it's just that my involvement in
implementation of these things actually places my concerns elsewhere for the
moment -- namely, interdomain policy negotiation methods and protocols, and
I think this is more the purview of a protocol -- like SPP or COPS -- more
specialized for the kinds of queries and responses the problem space forces
upon us). But it seems to me those looking at other mappings should at least
ask: do the reasons that recommend that we make the LDAP mapping a standard
(if someone more in the know could fill out those reasons, I'd be most
appreciative, of course) apply also to other mappings?

Should note also, that really, we do have one other mapping. It looks a lot
to me like the SPSL draft provides a mapping more friendly to flat file/text
file storage systems.

Anyway, personally, right now, I see the most valuable activities of this
group *with respect to mappings and the model* as (a) beating the policy
model into shape, assuring that it does what we need it to do and (b)
getting the existing mappings into full conformance with it. For additional
mappings, I'd expect anyone proposing it to suggest where it's actually
going to be used in the architecture of real-world policy systems, and what
is the advantage of that use complying to a published standard.

-----Original Message-----
From: Donkin, Richard [mailto:[email-masked]]
Sent: Wednesday, August 04, 1999 1:17 PM
To: 'Andrew Milne'; 'Jason, Jamie'; 'Atul Jain'; Policy mailing list
Cc: Paul Kierstead
Subject: RE: LDAP or RDBMS for policy storage?

> -----Original Message-----
> From: Andrew Milne [mailto:[email-masked]]
>
> 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.

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

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

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