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

From: "Yoram Snir" <[email-masked]>
Date: Mon, 9 Aug 1999 18:02:35 +0200

[This message is a follow-up to a thread started by Ryan Moats'
proposals for improvement of the schemata presented in Oslo (both Core
and QoS Schema (draft-snir-qos-policy-infomodel.txt))].

We've been going over Ryan's arguments and proposals and have come up
with a few questions, comments and suggestions.
This is a summary of those and is aimed at reviving the thread and hoping
for soon-to-be-reached
consensus.

The question before us is how to reconcile six requirements:

1. Provide enough expressive power to define and create "complex
objects" as described by the information model. Complex conditions are a
good enough model for complex objects (rules, etc.), so we can use them
interchangeably when we analyze complex objects. A complex condition is,
to refresh mem, made of simple conditions (Boolean expressions of the
form '<variable> <logical relation> <constant | value>'), plus the
necessary stuff (ORs, ANDs, balanced params and negation(s), no need to
dwell on that). A complex condition, for instance, is '(DestIP == myIP
OR DestIP IN VIP_GROUP) AND SourcePort IN WebPorts'.

Original QoS schema provides support for this requirement by means of
SDNs (from core, nothing added, nothing taken away) and object classes
for atoms (variables and constants plus value modeling) and simple
conditions, which are the building blocks of complex conditions.

2. Provide an extensible facility for managing "reusable objects". These
are containers of sets of named objects (not object classes!) that can
be "used" by referencing objects. For example, the expression above,
the simple condition 'DestIP IN VIP_GROUP', VIP_GROUP is a constant that
represents a group of addresses. That group is named VIP_GROUP. If the
VIP_GROUP constant is made reusable, another condition would be able to
be formed, using the name VIP_GROUP'. In fact, the complex condition
above can be a reusable object and used as a condition is more than one
rule.

Original QoS schema supports reusability of objects by modeling reusable
objects repositories. Reusability is a quality that can be inherited.
Thus, an implementation specific schemata may form reusable objects and
create repositories for them. The structure of the objects and the
repositories are transparent; it can be
read and understood by anyone -- more on this later. Repositories also
satisfy another requirement (not among the "big six"): It provide a place
for central management of reusable objects. Some level of data
integrity may be enforced by the fact that all objects referenced by
numerous users must also be referenced by the repository itself. It is
possible, for example, to prevent a deletion of an object that's still
referenced by another policy element.

3. Support efficient retrieval. The LDAP schema design should allow for
retrieval optimization. The schema should be designed to allow readers to
fetch objects efficiently, i.e., with minimal server round trips.
Common cases should be optimized for. LDAP queries should be minimized, but
digesting the data retrieved locally is not a major consideration in the
design of the policy schema.

The QoS schema follows the spirit and techniques of the Core schema and
makes extensive use of LDAP attachments. Simple conditions, for example,
can be compacted into a single object by attaching variables and values
to the condition. The condition can be attached to the rule, making the
complete rule accessible by a single round-trip. However, complex
conditions, event the most common ones, can't rely on attachments. In
addition, reusable objects aren't attachable. To fetch a complex
condition made of reusable components, requires several roundtrips.

4. Extensibility and transparency. The schema does not provide object
classes to model all possible policy components. Rather, building blocks are
supplied to allow implementation specific schemata to augment the
model with rich derived object classes. The desire to support
interoperability leads in the direction of transparent building blocks.
If the building blocks are supplied in the schema and the rules for
extending the schema are clear and simple, then the resulting extensions are
accessible to all readers. All readers should assign the same
semantics to the DIT. The QoS schema support extensibility and transparency
by providing
several building blocks for making complex objects. Of course, some schemata
may contain proprietary classes that are opaque to outside readers. However,
a schema designer has the option of supporting full transparency.

5. Consistency and non-ambiguity of policies.
The semantics of complex objects should be interpreted in the very same way
by all readers.
Corrupt statements should be easily identified.  The definition of the
Boolean expression is not only the SDI (group NR.,  negate sign and DN. of
condition) but also the policyRuleConditionListType attribute that specifies
if the Boolean expression is of in disjunctive  normal form (DNF) or
conjunctive normal form (CNF).  The same goes for Action lists, regarding
priorities

6. The policy schema does not own the DIT, but uses it. Counting on location
as the policy definition tools is not a good idea.

It is difficult to reconcile the six requirements above without any
compromise. Obviously, reusability doesn't lend itself easily to
efficient retrieval. A reusable object residing in a repository requires
an LDAP operation to be fetched. The rule referencing this reusable
object (a simple condition, for instance) must be fetched separately.

Two alternative approaches:

Strong location requirement and SDNs
-----------------------------------------------------
Ryan Moat proposes several techniques. The proposals all require DIT
location management. Let's start simple: To construct a complex
condition that can be fetched with one LDAP query, Ryan places all
components of the complex condition in the DIT under the rule. This
means that when you need to fetch a rule, you fetch the rule's subtree.
Ryan guarantees to you that if you fetch the subtree you fetch
everything needed to interpret the rule: All actions, conditions, values
and variables will be in that subtree. We'll call this the strong
location requirement.

In addition, Ryan did away with SDNs. SDNs are weird creatures: The
encode a three-tuple object: A DN, a group nr. and a negation flag. Ryan
separated the last three from the DN and places the contents in the
simple condition. For example, a complex condition made of two simple
conditions two SDNs is constructed as follows: The SDNs are decomposed
into their three elements. Each simple condition contains a group number
attribute and a negation flag attribute. Now, the two simple conditions
must reside in the DIT right under the rule. A client fetches the rule
and its subtree in one LDAP operation. The list of simple condition DNs
tell the reader what are the simple conditions necessary to construct
the complex conditions in the rule. Those simple conditions are already
on the client's machine. Next, the reader goes through the simple
conditions and reads their group members and negation flags and
reconstruct the full complex condition.
The condition list type attribute will be left in the Rule, so some
information defining the Boolean expression syntax will be left in the
parent, this in inconsistent.

Strong location requirement may be too strong. It requires that *all*
objects are organized in the DIT in such a way that reading a rule and
its subtree will always bring back all the components of the complex
object (the rule, in this case). This is clearly not supportive of
reusability, thus violating requirement #2 above. By definition, if all
objects used by a rule must reside in a certain place, another rule
would not be able to make use of a component if it's already strongly
located elsewhere. The need for DNs at the rule level is also
questionable and is used merely for validation (it allows us to separate
rule components from other things that happen to be in the subtree. It
also allows us to insure that all components are present). Non reusable
objects are perfectly legal in the QoS schema, but they have a lightly
different structure and arguably stricter semantic rules.

Even more disturbing is the encoding of group nr. and negation flag
inside the component itself. What this means is that we add specialized
information to a simple condition, which may render it useless for
referencing. For example: The condition 'SourceIP == MyServer AND
SourcePort == WebPort' has two component simple condition. If we encode
group nr. into both simple conditions we'll never be able to reuse these
simple condition to form the complex condition 'SourceIP == MyServer OR
SourcePort == WebPort'. Certainly an unfortunate consequences of this
form of encoding.

Weak location requirement - or improved QOS Schema
------------------------------------

A slightly modified version of Ryan's proposal may help. Instead of
*requiring* all components to reside in the subtree, we *recommened* it but
the reader should not assume that it is the case. Therefore, a complex
condition could be made of several simple conditions, where some are located
as rule leaves and some are pointed to by DNs. This appears
to provide some reusability and makes use of the DN list in the parent (the
rule). When reading a rule, it is *recommended* to read the subtree because
we *encourage* people to collocate rule components as described
above. However, the reader must verify that all components are indeed
collocated. This is done by going over the DN list and marking the
objects that need to be fetched. One could form a complex condition
locally most of the time. This reduces the overall round-trip count, under
some assumptions about how designers should bias their design.
The strongest strike against weak location is that it still does nothing
for the SDN problem (already mentioned before): SDNs model the
relationships among condition components -outside- of the component
object, while weak location schemes place this info -inside- the
reusable component. We deem this restriction very harsh. The complex
condition in the previous example would not be able to share objects or
they lose the AND/OR semantics.
Unfortunately, LDAP lacks a facility to model ordered lists (vectors,
arrays, tables, whatever). This LDAP weakness prevents us from modeling
the intra-condition relationships in a parent resident array. In fact, SDNs
were conceived to tackle this very difficulty to create a three-tuple table
{DN, group, negation} It is worth noting that
even SDNs can't model order. LDAP can model sets in multi-valued
attributes, but LDAP guarantee no order among members. This means that
the use of SDN is restricted. Fortunately, Boolean conditions can be
fully modeled as unordered lists of SDNs.

What if we compromised on this:

The schema is based on the weak location requirement as described in the
previous paragraph. However, we move the "extra" Boolean relations back
into the parent. SDN appears to be not liked by some, but for now it is
the best mechanism that allows for locating this information at the
parent (which, it appears, is desired).

DIT creators are strongly encourage to collocate objects in the sense
described above. Reusable objects repositories are modeled (again, in
the very same sense as described in the draft). It may be fine to either
require or encourage to place all reusable objects in collocation as the
repository itself. This way, readers would be able to download the required
repository in a single LDAP query and cache it. It is reasonable to
cache (some) reusable objects.
Given this scheme, a DIT reader would only have to know one rule:
When retrieving a potentially complex object, read in the subtree as
well.

A rule would be modeled as described in the QoS schema using a set of
SDNs.

Interpreting a complex condition would go like this: Get the rule and
its subtree. For each SDN in the condition list, if the condition ain't
here already (in the subtree), then go get it using its DN.

====================================================
How does the proposed scheme above fulfill the six requirements
enumerated at the top?

#1 is clearly supported. The modified model has the very same expressive
power as the one proposed in the QoS schema draft. The retention of SDNs
is the key.

#2 is also in a pretty good shape. We can model reusable objects
repository and manage them centrally (including limited integrity
constraints). Furthermore: We now can assume that caching repositories
would be a single LDAP operation. (Note that there's ample room for
refinements here)

#3 the schema allows the users, even encourages to organize the
DIT in collocation hierarchical model. Implementers should assume
that this is the common case, but while digesting the policy information
make sure the expression are full and consistent with the help of the SDN
values. Adding this usage recommendation will cut down the number of LDAP
roundtrips for policy retrieval with out breaking the flexibility and
consistency of the model.

#4 is easily supported.
#5 Retrieved objects residing under a specific rule will be checked to make
sure they are the full set of conditions relevant to this specific rule,
unrelevant ones would be ignored and missing conditions will be retrieved.
This will be done by comparing the retrieved set of condition to the SDN
values in the rule. The same goes for the action and trigger  list.
#6 See #5.

Yoram Ramberg  + Yoram Snir