Subject: Comments on LCUP draft

From: [email-masked] (Richard V Huber)
Date: Wed, 16 May 2001 17:28:35 -0400

These comments refer to <draft-ietf-ldup-lcup-00.txt>.

At the end of Section 3 there is a paragraph:

  A server can define a naming context or some part thereof to
  participate in LCUP.  This document will refer to this as an LCUP
  Context.  For example, LDUP defines a replica, a part of the DIT
  which may participate in replication.  The LCUP context may be
  coincident with the replicated area, depending on the server's
  implementation.  It is assumed that most server implementations of
  LCUP will make use of the server's underlying replication mechanism,
  but this does not have to be LDUP compliant.

I assume there can be more than one LCUP Context per server.  It should
probably be explicitly stated one way or the other.

----- -----

Section 4.3 includes the paragraph:

  entryDeleted - if set to TRUE, indicates that the entry to which
      the control is attached was deleted.  The server MAY also set
      this to TRUE if the entry has left the client's search result
      set.  As far as the client is concerned, a deleted entry is no
      different than an entry which has left the result set.

Why is this a "MAY"?  If LCUP doesn't inform clients of entries that
have been renamed out of the search result set, it will never
synchronize properly.  As the text notes, to the client, this IS a
delete.

----- -----

Section 4.8 says:

  Since the server sends to the client the modified entries rather than
  the operations, a MODDN operation performed on a subtree will be seen
  by the client as a sequence of added or modified entries depending on
  whether the operation moved the entries into the scope of the
  client's search specification.

Since the server sends entries rather than operations, a MODDN might
also be seen as a delete (if the new name was outside the clients
search scope).

If the MODDN is entirely within the search scope, what is sent?  A
delete and an add, or a modified entry with the existing entryUUID and
a new RDN?  Or LCUP doesn't care since the result ends up the same
either way?

----- -----

In Section 5.1, discussion of the leftset feature includes the
sentence:

  Ironically, this feature is the hardest to implement on the server
  because the server does not keep track of the client's state and has
  no easy way of telling which entries moved out of scope between
  synchronization sessions with the client.

This ties to my comment on 4.3.  The entry that moved out of scope
should be sent as a delete in the next synchronization session.  If it
isn't, you will never synchronize.  If the server doesn't know when an
entry has moved out of scope, how are these deletes correctly
generated?

----- -----

In Section 5.4, I agree with Michael Armijo's comment.  Especially
since the draft allows the server to terminate a session at any time
due to load.  And even with his suggested addition, the client may find
itself with parentless entries after an unexpected disconnect due to
communications errors.  If  parents were always sent before children it
would be much easier to clean up after unexpected disconnects.

Rick Huber

---

From: [email-masked] (Rich Megginson)
Date: Fri, 18 May 2001 10:12:08 -0600

> probably be explicitly stated one way or the other.

Good idea.

Yes, but it may be very difficult for server implementers if this becomes a

MUST.  Sure, the client may have some entries locally which don't anymore
exist in the search result set on the server.  But for many client
applications, this is acceptable.

What we envision is that in the future, there may be different levels of
LCUP support.  The server will be able to publish if it is a MAY or  MUST.

Correct.

> a new RDN?  Or LCUP doesn't care since the result ends up the same

I don't think it makes much difference either way.  What do you think?

> isn't, you will never synchronize.

For certain classes of client applications, this will be acceptable.

> If the server doesn't know when an

The problem is that it may be very difficult for server implementers to
know that some meta data change affects some LCUP search.

> communications errors.

Why would this be a problem?

> If  parents were always sent before children it