Skip to main content

Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)
draft-ietf-ldup-lcup-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ldup mailing list <ietf-ldup@imc.org>, 
    ldup chair <ldup-chairs@tools.ietf.org>
Subject: Protocol Action: 'LDAP Client Update Protocol' to 
         Proposed Standard 

The IESG has approved the following document:

- 'LDAP Client Update Protocol '
   <draft-ietf-ldup-lcup-07.txt> as a Proposed Standard

This document is the product of the LDAP Duplication/Replication/Update 
Protocols Working Group. 

The IESG contact persons are Ted Hardie and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-07.txt

Ballot Text

Technical Summary
 
The LCUP protocol allows LDAP clients to synchronize 
with the content stored by LDAP servers; it does not
 address server to server synchronization.  It has three
main proposed use cases:  limited clients that need to
maintain read-only copies of directory data for use while
off-line; applications synchronizing local data with multiple
data stores to create a different view of the data (e.g. a
meta directory); and clients which perform automated tasks
based on directory information triggers (e.g. a client that
creates new mailboxes when a new directory entry is created).

Working Group Summary
 
The group achieved rough consensus after significant debate.
A minority view that this protocol represented the wrong engineering
choice in the face of common implementations was discussed extensively
on the mailing list and the issues raised again during last call.  The
key point of contention was how the balance between server state
and on-the-wire traffic should be struck.  The draft's applicability statement
indicates that some level of server state would be required to
avoid full synchronization (and its implied cost in traffic and
processing), and there was debate over the relative costs for
current and furture implementations.  After a focused period
of discussion, the working group came to rough consensus
that the protocol contained sufficient mechanisms to handle cases
where incremental update was sub-optimal and the document
clear enough in its applicability statement to prevent misunderstanding.

 
Protocol Quality
 
Ted Hardie reviewed this document for the IESG.

RFC Editor Note