Re: the change log draft and the signed directory operations draft

[ggood@netscape.com (Gordon Good)]

Bruce, there is some overlap, but I think that the fundamental purposes of
these two drafts are quite different. There are three interesting problems we
might look at solving:

1) Auditability of operations made to directory entries (which seems to be the
central focus of the sigops draft).
2) Synchronization of LDAP servers with each other.
3) Synchronization of offline LDAP clients, e.g. address book synchronization.

I'm arriving at the conclusion that LDAP-accessible changelogs, at least as
specified in the current draft, don't solve #2 or #3 very well (although they
can be made to work, and we've implemented both).

#2 is largely unnecessary - having both a "push" and "pull" model of
replication adds unnecessary complexity. A better approach is to allow
initiation from either supplier or consumer, but to always use a "push" model
for propagating changes. This is the direction that the LDUP group is going.

#3 is quite useful, but the current changelog spec doesn't do agood job. The
main problem has to do with security of the "changes" attribute. In any
practical deployment, you cannot grant anonymous access to this attribute,
since it may contain sensitive information like password changes. Unless, of
course, the server provides different views of this attribute to clients based
on their identities and access rights. Another problem is that it's quite
inefficient.

An approach to offline address book sync that would be more fruitful, in my
opinion, is to leverage some of the work we're doing in the LDUP working group
and place UUIDs (Universally Unique Identifiers) and versioning information in
entries, and make those visible to clients. I haven't thought through this too
extensively, and there are a number of thorny issues involving deleted and
renamed entries, but it seems much more efficient than the changelog approach.

So, I think it's probably not worthwhile to reconcile sigops and changelog. But
it is worth thinking about if and when we tackle offline client synchronization
issues.

Bruce Greenblatt wrote:

> As I see it, these two drafts  have significant overlaps.  They both
> present object classes that are designed to represent changes that have
> been applied to a directory entry.  Do we need both of these? The signed
> directory operations draft provides a way to have the journal of changes
> signed by either the client or server, at the expense of the overhead of
> creating a signed object.  I think that we need only one approach.  Does
> the group think that the journal of changes needs to have the ability to be
> signed?  What should we do?
>
> Bruce
> ================================================
> Bruce Greenblatt              bruceg@innetix.com
> http://www.innetix.com/~bruceg
> ================================================