Subject: Initial thoughts on directory containment hierarchies and finding policies

From: [email-masked]
Date: Tue, 23 Feb 1999 13:46:37 -0500

There was a brief discussion at the Interim about directory containment
hierarchy and its implications for interoperability and performance.  The
interoperability issue is what configuration information is needed by a
system to find its policy information:  is it a role name, a role dn, a
ComputerSystem dn, a profile name, ...?  Further, how the information is
structured will impact start-up performance of the using systems:  a single
LDAP call from a portion of the directory containment tree or DNs being
traversed to gather appropriate entries that may be scattered throughout
the directory tree.

Since, in issues of configuration, less is more, it would be better to only
have a single DN configured on a directory client system.  The most general
usage is where that DN provides the rest of the configuration information.
There is a substantial amount of work currently being done by the Network
WG of the DMTF in this area,  but that work is not yet complete.   It
suggests, however, that a system object might be instantiated for each PEP
and that the policy consumer, the PDP service, would have an object entry
with pointers to their client PEP object entries which would, in turn, be
the base object for other searches that would yield structural object
entries with an attached policyXxxxxContainmentAuxClass entry appropriate
to associated interfaces. This may be more than can be standardized at this
point, but short of some agreement like this, there are interoperability
problems.

With the schema as currently specified, the only interoperable directory
traversals use the various DN pointers in the policyGroup and policyRule
classes.  This can cause a very slow initial load.  To provide for reuse,
it seems to be agreed that conditions and actions cannot be required to
contained by the rule and, similarly, the rules cannot be contained by the
groups.  However, it is possible to specify a set of base objects that
would permit bulk retrievals of policy information.  These base objects are
policy discipline and directory installation unique, that is, the QOS
policy for a given ATM network may have a different structure than another
ATM network and certainly from an IPSEC policy or a DHCP policy.  To
facilitate flexibility for both the administrator and the policy-exploiting
products, these base objects can be stored in an object entry that can be
found by all policy consumers.  This can either be a well-known entry
(e.g., policyDirectoryContainment named and typed by discipline) or, more
generally, the DN for the base object entry(ies) can be added to the
policyXxxxxContainmentAuxClass.  This latter approach has the flexibility
that permits different groups (or rules) to have different containment
relationships and still enable more efficient retrievals.  The former
approach has the advantage that all retrievals can be done prior to
examining any of policyXxxxxContainmentAuxClass.

What do y'all think?  Cheers, Lee

Lee M. Rafalow
Voice: 1-919-254-4455 (8-444-4455); Fax: 1-919-254-6243 (8-444-6243)
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, JDGA/501
RTP, NC 27709 USA
Work email: [email-masked]
Intranet: http://rafalow.raleigh.ibm.com/
Home email: [email-masked]