Re: WG Last Call: LCUP Draft

["Kurt D. Zeilenga" <Kurt@xxxxxxxxxxxx>]

A month or so ago, I provided the authors with a laundry
list of technical and editorial comments.  Before I echo
each of these on the list (which I will before the end
of comment period), I like to raise what I consider my
biggest concern.

My biggest concern is that this protocol provide the
client will all the events necessary for it to "synchronize"
update its copy of the fragment of the DIT previously returned
to that which would be returned if the original request would
have been repeated.

In the worst case, a client repeating the original request
may find that the copy "synchronized" by LCUP is MOSTLY changed!

The protocol basically needs not only to send a copy of
all entries which are within scope which have significantly
changed, but also send a list of UUIDs and CSNs of all the
entries which have not changed.  This would not only allows
the client to determine the set of entries which have been
deleted from the fragment, but also determine if an entry
returned but not updated needs to be refreshed.  In which
case, it can request a copy of those entries which it
believes need to be refreshed.  This can be done out of
band with a persist operation.

The persist needs a bit of work as well.  Basically, the
server needs to be required to generate the set of
events necessary for eventual convergence of the client's
copy of the DIT fragment.

Kurt
 
At 09:49 AM 2002-09-01, Chris Apple wrote:

>The purpose of this message is to initiate the LDUP
>working group last call on the LDAP Client Update Protocol
>draft.
>
>WHAT DOCUMENT?
>
>The document in last call is:
>
>http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.txt
>
>WHAT IS A LAST CALL FOR?
>
>The purpose of the working group last call is to ensure
>that the working group has reached consensus on the
>document, believes that all the known outstanding issues
>have been addressed, and is ready to put the document
>forward for Proposed Standard status.
>
>During the last call, any comments on the documents are
>collected and discussed on the mailing list.
>
>HOW LONG DOES IT LAST?
>
>The last call starts Tuesday, September 3, 2002 and will
>Last approximately two weeks.
>
>It will end on Tuesday, September 17, 2002 at 1700 ET.
>
>WHAT'S THE NEXT STEP?
>
>After the last call completes, there are three possible
>outcomes:
>
>1) No changes are required and we request our ADs to put
>   forward the documents to the IESG for Proposed Standard
>   status.
>
>2) Minor changes agreed to on the list are required, and
>   the documents are revised. We then ask our ADs to put
>   forward the revised documents to the IESG for
>   Proposed Standard status.
>
>3) Major issues are raised and no consensus is reached on
>   the list. In this case, we discuss things until consensus
>   is reached, at which time another working group last call
>   will be issued.
>
>Assuming we achieve outcome 1) or 2), and that the ADs
>agree with our assessment, the next stop for the documents
>is with the IESG. The IESG reads them and may approve the
>documents (with or without changes), or send the documents
>back to the working group to have major issues addressed.
>
>If the first outcome happens, the documents are put forward
>for a two-week last call to the entire IETF, and after
>successful completion the documents are published as RFCs
>with Proposed Standard status.
>
>If the second outcome happens, we go back and address
>the issues, putting the documents forward again when we
>believe they're ready.
>
>WHAT SHOULD YOU DO?
>
>You should read the documents, making sure that 1) there
>are no problems or deficiencies or outstanding issues that
>need to be resolved; and 2) that there are no typos,
>formatting problems, grammatical errors, etc.
>
>Any substantive problems you find, you should send to the
>list. Any minor problems (typos, etc.) you may send to the
>list or just to the authors. If, for some reason, you have
>comments you don't want to send to the entire list, you may
>send them to me and/or LDUP WG co-chair John Strassner.
>
>Silence means consent.
>
>Read, enjoy, and send your comments in!
>
>regards,
>Chris Apple and John Strassner
>
>Chris Apple - Principal Architect
>
>DSI Consulting, Inc.
>
>mailto:capple@xxxxxxxxxxxxxxxxxx
>
>http://www.dsi-consulting.com