Subject: Candidate LDAP Administration Model

From: "Ed Reed" <[email-masked]>
Date: Thu, 22 Mar 2001 07:49:05 -0700

Well - I tried to just add a sentence to the LDAP Subentries text describing an administrative area, and couldn't convince myself that it was sufficient.  Instead, I studied the X.501 (2001) draft and came up with the following description of what is, I think, a compatible, simpler subset of the X.500 model.  I present it here for your comment and feedback to see (1) if it is indeed simpler (2) if it is indeed compatible (3) if it is indeed a subset.

Thanks.  Your comments are requested.  I suggest this be part of the LDAP Subentry draft, that should go onto the proposed standard track.

Ed
=============================================
4	Administrative Areas in the Directory
4.1	X.501 Administrative Model Overview
[X501] contains an extensive description of Administrative Areas and their role in the management and administration of directories.  The LDAP administrative model defined here is intended to be a compatible, proper subset of the [X501] model.  The description here draws heavily on the descriptions and concepts laid out in [X501].

An administrative area is a sub-tree of the directory information tree, rooted at an administrative point (the root-most entry in the sub-tree), where administrative entries (perhaps including subentries, operational attributes, or both) are located.  Autonomous administrative areas are distinct partitions of the directory information tree whose entries are all administered by a single administrative authority.  Each entry in the directory information tree is administered by exactly one autonomous administrative authority.

There may be many aspects of administration defined by the directory and other applications for specific purposes, such as subschema administration areas, access control administration areas, collective-attribute administration areas, context default administrative areas, and service administrative areas.  Within an autonomous administrative area, specific administrative areas for these (and other) different aspects may overlap one another.  

Specific administrative areas may be sub-partitioned by the applications or services which define them to facilitate delegation of authority or for other purposes.  That means that a single entry in the directory may be part of many different specific administrative areas, but only be part of one specific administrative area (or sub-area) of each aspect of administration.

The [X501] subentry specification optionally uses a SubtreeSpecification to indicate a subset of entries in a sub-tree with which the subentry is concerned.  When the SubtreeSpecification is empty the scope of the [X501] subentry is implicitly defined by the context in which it occurs.  
4.2	An LDAP Administrative Model
The administrative model for LDAP defined here is a simplified version of the one described in [X501], in that the scope defined for the ldapSubentry object class is limited.  

The LDAP Subentry definition below specifically does not include a SubtreeSpecification, so its scope is explicitly the complete set of entries in the specific administrative area (or sub-area) in which it occurs.  All administrative areas are considered to be specific administrative areas within an autonomous administrative area.  

If a specific administration area is not partitioned, then its extent (or scope) is said to be that of the autonomous administrative area in which it is defined.

Applications and services which define specific administrative areas must specify whether the areas may be partitioned or not.  By default, the scope of LDAP Subentries is limited to the sub-area of the partitioned specific administrative area in which they are present. 

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 26 Mar 2001 23:39:17 +1000

Following links highlight serious problems that can arise from
not not working out access control together with replication
carefully enough.

Microsoft unable to supply a fix for more than a year due to
having to fundamentally redesign Active Directory to fix it:

http://www.nwfusion.com/archive/2001/117574_02-26-2001.html

http://www.microsoft.com/windows2000/news/bulletins/multivalrep.asp

Similar issues can arise with replication of administrative
policy etc.

Workarounds like Microsoft proposes are simply bizarre and
negate the point of a directory. The description of their
proposed future fix also looks like just a kludge.

Workarounds like notifications to directory administrators
are also unworkable in the long run. Changes to access
control information (including group membership) are
increasingly made directly by end users and their
applications - such delegation being one of the main
advantages of large scale directory deployment.

In order to satisfy the currently recognized requirement for
replication of access controls to work it will be necessary
to actually implement both:

1) preservation of atomic operations

2) preservations of the sequence between access control
related changes and changes to affected entries

as specified in the current LDUP requirements draft.

This will still not eliminate all possible anomalies,
even together with profile advice on avoiding situations
where changes are frequently made before previous changes
have fully replicated.

I therefore believe it is essential to add:

3) automatic notification to the DUA that made a change
when that change is revoked as a result of a conflicting
atomic operation.

The current requirement for notification to
administrators ensures that an architecture
capable of being extended to also meet item 3)
will not need complete redesign to provide
that extension.

Therefore I do not think it is necessary to oppose the
current requirements draft at IETF final call, although
it would certainly be better if this requirement was
recognized now.

However I would be opposed to adoption of
any architecture that did not actually implement
item 3 and am putting that on the record now.

Some work will be necessary to actually
standardize notification mechanisms - eg by
email to the address given in DUA entries or
via LCUP. It would be better if that work was
started earlier rather than later.

(Other objections to the meaningless requirements
concerning "model 1" and "model 3" likewise don't
really matter precisely because they are meaningless,
though it would obviously be better to not include
meaningless requirements. Ditto for the unhelpful
examples which obscure the reasons for needing
multi-master replication.)

On item 2, there is no practical way to achieve
it without implementing delivery of change reports from
each originator DSA to each other DSA in exactly the
same sequence as generated by the originator. This
follows from the fact that an ACI change can affect
an entire subtree, even leaving aside the fact that
group membership can be from other parts of the DIT
entirely. It is also necessary for minimizing restarts
of replication sessions and use of full instead of
incremental replication.

Similar considerations may apply to administrative
areas - perhaps with more problematic implications
due to administration points being at the
intersection between replicated areas. Single
master replication (with failover) may well be
essential for administrative points (and acceptable
due to not needing the same fault tolerance and
local availability of changeable copies as for
other changes).

Even namespace management is currently unclear.
How is a modifyDN operation actually performed
between different replicated areas within a
single "Naming Context"?

Changes from different originator DSAs would of
course still be interleaved arbitrarily due to
replication schedules and replication network links.

As far as I can see items 1 and 2 can only be
achieved by some method similar to the "tree"
proposed in my MDCR draft (expired). That is
because each DSA has to converge on the same
serialized sequence of atomic operations and
that sequence has to be consistent with the
sequence in which changes were originally made
at each originator DSA. Since the operations
form a tree in reality, I cannot see any way
to avoid modelling that tree within the
conflict resolution protocol. There simply
isn't any actual total ordering available.

If there are any other ideas for meeting the
proposed requirements, or if anyone believes
that URP can meet them, it would be useful to
provide an outline before the next LDUP
requirements last call, so that there is time
to think about it and avoid confusion during
discussion.

Concerning replication of admin policy and
Ed's sub-entry draft I am not clear on the
intended function of the paragraph about
X.500. If the intention is simply to refer
to the X.500 standards as the basis for
expected future work on standardization of
LDAP administrative areas and their
relation to replication, I believe that is
a very good idea.

What should follow from that is promptly
taking up the proposals for liasion put
forward by an X.500 working group and
doing detailed analysis on whether and
how it maps to the sub-entry and replication
proposals.

Certainly the paragraph cannot actually
substitute for that work. Defining any
simplified subset requires very detailed
work similar to the original LDAP standards.

It is unclear to me whether the sub-entry
draft is adequate for supporting appropriate
administrative areas and replicating them.
That could only be determined by actually
doing the detailed analysis and mapping.

It may turn out that the full
"chop specification" with lower bounds
as well as a base entry is necessary
when taking into account the knowledge
needed for distribution and replication.

Administrative areas for some purposes
such as access control may well need to
be nestable rather than partitions.

This needs a close inspection of the
X.501 (2000) standard referenced by Ed,
which is available from:

ftp://ftp.bull.com/OSIdirectory/4thEditionTexts/

As background reading I would strongly
recommend David Chadwick's online book on
earlier versions:

http://www.salford.ac.uk/its024/Version.Web/Contents.htm

Section 11 of chapter 2 actually succeeds in making the administrative
framework intelligible!

BTW I believe adopting an access control model incompatible with
X.500 and omitting the concept of a Directory Access Control
Domain applying only to a subset of entry types is a mistake.

Interoperability can best be facilitated by
simplifying existing standards where possible, not by adopting
"options" for different fundamental models. Such options conflict
with well known internet architectural principles.

Both administrative areas and access controls are more within
LDAP-EXT than LDUP since they are just as important without
replication. Liaison with replication work in LDUP and with
the X.500 people themselves is clearly essential.

These two areas relate closely to a third area - directory
distribution - including operational bindings between DSAs
(and replicated areas) within the global DIT.

Lack of clarify about the interoperability issues arising
in connection with that is hindering progress on other issues.
A global internet scalable directory service really requires
that this be dealt with first - and fortunately much of the
work has already been done for it in X.500 as was the case
with the original LDAP access standards as a compatible
"Lightweight" substitute for X.500 DAP.

LDAP was possible without having to do the work on
access controls, replication, administrative boundaries
or distribution because it was just an "Access Protocol".

In standardizing replication it has become obvious that
standardization of access controls, and administrative
areas is closely related. In moving into these areas
IETF is going far beyond issues for an "Access Protocol"
and needs to take an architecturally coherent approach
based on the X.500 standards. Distribution and then
administrative areas is really the foundation for the
others and needs serious work now in conjunction with
the liason project alredy setup from the X.500 side.

Who is doing that work?

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 26 Mar 2001 23:39:17 +1000

Who is doing that work?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Mar 2001 11:27:06 -0800

At 11:39 PM 3/26/01 +1000, Albert Langer wrote:
>areas is closely related.

I'd expand on this to say:
  In standardizing multi-master replication, it is
  obvious that the LDAP/X.500 data model will have to
  be redesigned as it only support single-master
  replication.

>Who is doing that work?

Personally, I rather we, the IETF, leave the redesign of
the data model to ITU, and only deal with how to represent
whatever model the ITU produces in LDAP.

Kurt