Evaluation: draft-ietf-ldup-lcup - LDAP Client Update Protocol

[IESG Secretary <iesg-secretary@ietf.org>]

--------

Last Call to expire on: 2003-09-23

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [   ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [   ]     [   ]
Randy Bush           [   ]     [   ]     [   ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ned Freed            [   ]     [   ]     [   ]     [   ]
Ted Hardie           [ X ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [   ]     [   ]
Allison Mankin       [   ]     [   ]     [   ]     [   ]
Thomas Narten        [   ]     [   ]     [   ]     [   ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Margaret Wasserman   [   ]     [   ]     [   ]     [   ]
Bert Wijnen          [   ]     [   ]     [   ]     [   ]
Alex Zinin           [   ]     [   ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L 
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, <ietf-ldup@imc.org>
Subject: Protocol Action: 'LDAP Client Update Protocol' to 
         Proposed Standard 

The IESG has approved following document:

- 'LDAP Client Update Protocol'
   <draft-ietf-ldup-lcup-06.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 Ned Freed.

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
 
 (Who has reviewed the spec for the IESG? Are there implementations?)