Response to LCUP WG Last Call Issues

[richm@xxxxxxxxxxxx (Rich Megginson)]

>    
> Issue Number: 1
>
> Description: Complete LCUP Client Update is Problematic
>
> Summary:
>
> Concern was expressed over an LCUP Client that repeats an original
> request may find that the copy "synchronized" by LCUP has changed
> significantly.
>
> Concensus:
>
> 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.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01511.html
>  
 Response:
 
 The other authors and I don't think this is necessary.  The main reason
this is needed is that it is difficult for servers to keep track of which
entries have left the result set due to meta data changes such as access
control, configuration, etc.  So, a server could simply send unchanged entries
instead of sending entry left set notifications.  We don't think this needs
to be addressed in LCUP for the following reasons:
 1) It is expected that changes which would cause the server to have a hard 
time calculating which entries have left the result set will be very infrequent.
 2) The 04 version of the LCUP draft provides a mechanism to have the server 
tell the client that a reload is required at any time.  We feel that, in most
cases, returning all present entries will be nearly as expensive as a full
reload.
 3) There will be cases where the server may have a hard time figuring out 
which entries are even present, much less have left the result set, so a reload
will be required in those cases as well.
 
>    
> Issue Number: 2
>
> Description: Persist Doesn't Support Eventual Convergence
>
> Summary:
>
> This issue was raised in the context of Issue #1. It basically
> states that the server should support eventual convergence of
> the client's information with equivalent information on the server.
>
> Concensus:
>
> 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.
>
> The spec currently only appears to support "lossy convergence."
>
> Relevant Postings:
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01511.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01594.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01595.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01596.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01597.html
>  
 Response:
 I think the majority of this was answered in the response to #1 above.  If 
I missed something, please let me know.
 
>    
> Issue Number: 3
>
> Description: Confusing Cookie/Scheme Text
>
> Summary:
>
> The document defines a cookie as representing client state,
> but it then says it may be sent initially (without value)
> to indicating the desired scheme.
>
> Concensus:
>
> The specification would be a lot clearer if the cookie/scheme
> were defined as:
>
>   LCUPScheme ::= LDAPOID
>   LCUPCookie ::= SEQUENCE {
> 	scheme          LCUPScheme,
> 	value           OCTET STRING
>   }
>
> and request control was defined as:
>
>   ClientUpdateControlValue ::= SEQUENCE {
>       updateType         ENUMERATED {
>                                synchronizeOnly         (0),
>                                synchronizeAndPersist   (1),
>                                persistOnly             (2) },
>       sendCookieInterval INTEGER    OPTIONAL,
>       scheme		  LCUPScheme OPTIONAL,
>       cookie             LCUPCookie OPTIONAL
>   }
>
> where scheme may only be specified on initial request to indicate
> desired scheme and cookie must be provided on subsequent
> requests.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01606.html
>  
 Response:
 Changed, and the scheme is no longer a part of the cookie.  Thanks for the 
suggestion.
 
>    
> Issue Number: 4
>
> Description: Clarification of Cookie Specification
>
> Summary:
>
> Section 4.2 states: "The cookie value MUST be included except when a
> client has no stored state; i.e., when the client is requesting a full
> synchronization"
>
> Concensus:
>
> Clarification is needed as to which of the following this text refers
> to (or an indication that it refers to all of the following):
>
>    + ClientUpdateControlValue
>
>    + EntryUpdateControlValue
>
>    + ClientUpdateDoneControlValue
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01506.html
>  
 Response:
 The LCUP 04 draft is much clearer about when and how a cookie should be
returned.
 
>    
> Issue Number: 5
>
> Description: New Cookie w/No Entry Mechanism
>
> Summary:
>
> LCUP needs to provide a mechanism which allows the server to send,
> at any time, a new cookie to the client without requiring the server
> to send an entry.
>
> Concensus:
>
> This is useful in cases where the cookie the server previously
> sent is too old to be useful and a new cookie would allow more
> efficient resync if the session where to be unexpectedly dropped.
> In fact, the cookie may be so old to cause a full sync to occur
> when no changes would be necessary if the cookie were updated.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01518.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01520.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01521.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01522.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01524.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01526.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01532.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01534.html
>  
 Response:
 The LCUP 04 allows for a "Sync Update Informational Response" which can
be used to return the cookie (or other information) at any time, without
using an intermediate response.
 
>    
> Issue Number: 6
>
> Description: UUID Syntax and Matching Rule
>
> Summary:
>
> The syntax of UUID is directory string, and moreover, the matching rule
> is case ignore match. It was suggested that this combination is overly
> limiting and that the syntax be changed to octet string. This is made
> even more apparent by the fact that this document leaves standardization
> of the value generation to a future specification.
>
>
> Concensus:
>
> First and foremost, UUID support needs to be mandatory. The
> protocol won't work otherwise.
>
> Instead of returning the UUID as an attribute value (which
> are subject to normal access controls), it should be returned
> within the control (which *should* be subject to some kind of
> access restrictions).  This to avoid having to deal with no
> UUID as being a valid response to a CRITICAL update request.
> Instead, if the server is unwilling to provide the UUID, the
> CRITICAL request will fail.
>
> A specification of how the server represents UUIDs (and CSNs)
> in the directory should be standardized, but suggest this be
> done in a separate document... as, if UUIDs are passed in the
> control, LCUP doesn't depend on the particulars representation
> in the DIT.
>
> For the specifications of entryUUID (and entryCSN), using
> either octetString/octetStringMatch or UUID/UUIDMatch
> (where UUID was a constrained OCTET STRING with a string
> syntax). The later is preferable.
>
> There is no need to leave the string syntax up to future
> standardization.  ISO/IEC 11578:1996 can be referenced.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01505.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01508.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01544.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01510.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01546.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01552.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01553.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01555.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01557.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01558.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01563.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01567.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01568.html
>  
 Response:
 Done, and thanks for the suggestion.  The new LCUP draft specifies a mechanism
by which the server's UUIDAttribute (name or OID) can be returned to the
client so that the client can do searches.  This element is optional - only
for servers that have a UUID attribute and support searches.
 
>    
> Issue Number: 7
>
> Description: Trigger Mechanism or Not?
>
> Summary:
>
> The draft states that it "is intended to allow LDAP clients to
> synchronize with the content stored by LDAP servers". but also states
> that it wants to solve the problem of triggered actions (Section 3,
> Bullet 3).
>
> Concensus:
>
> Most of the rest of the draft is consistent with the notion of
> synchronization, but tends to downplay support for triggered responses.
> Do we want this to be a useful event driver, or is the idea that we just
> preserve the easy stuff of what prior drafts could do?
>
> Specifically, the left-out items in Sections 5.1, 5.2, and 5.3 deter
> from the effectiveness of the "persist" mode.
>
> Curent users of Persistent Search rely on the notion of change types.
> Section 5.2 assumes that change types are used for partial replication,
> and thus discounts them as useful for LCUP.
>
> Triggered actions should be within LCUP's scope. The LCUP authors have
> tried to balance the server implementation burden with the client
> implementation burden. In particular, I would really like to 
> avoid creating an LCUP protocol that requires a server to store 
> client-specific state (that just won't scale when their are thousands
> or hundreds of thousands of clients).
>
> A related comment: section 5 should be moved to an appendix that 
> is named "Features Left Out of LCUP." It is not core to LCUP, but is 
> useful to provide historical context and rationale for why some things 
> are not included in LCUP.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01519.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01554.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01556.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01562.html
>  
 Response:
 We made it clear in the new 04 LCUP draft that it is not the intention of 
LCUP to fully replace all existing persistent and triggered search applications. 
 We also moved those sections mentioned to a "Features Left Out of LCUP" appendix
as suggested.
 
>    
> Issue Number: 8
>
> Description: Alias Dereferencing
>
> Summary:
>
> The server instructions for alias deferencing are found in the Client
> Side Considerations section.
>
> Concensus:
>
> Specifically, it says that a server will respond with protocolError if
> any other than neverDerefAliases or derefFindingBaseObj is specified.
> This should be moved to, copied to, or referenced in a more server-centric
> part of the draft. It should say "... the server MUST return protocolError..."
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01516.html
>  
 Response:
 Done.  Thanks for the suggestion.
 
>    
> Issue Number: 9
>
> Description: Laundry List
>
> Summary:
>
> This posting contains a copy of feedback provided to the document
> editors privately.
>
> Concensus:
>
> Some of the specific comments in the postings below have been discussed and
> addressed as a part of other issues. Other comments are strictly editorial
> in nature and should be incorporated. The document editors should raise
> comments otherwise classified to the mailing list and obtain clarification
> from the WG members.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01514.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01515.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01517.html
>  
 Response:
 There are a lot of issues here, most (if not all) of which have been addressed 
in the LCUP 04 draft.  I would suggest that Kurt (and others) take a look 
at the new draft to see if the issues have been addressed appropriately and 
sufficiently.
 
>    
> Issue Number: 10
>
> Description: Search Filter and Returned Entries
>
> Summary:
>
> The draft states in Section 5.2 that "For LCUP, the intention is full
> synchronization, not partial.".
>
> Concensus:
>
> LCUP must support both partial (not necessarily all entries within
> scope) and fractional (not necessarily all attributes of each entry)
> synchronization.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01523.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01530.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01539.html
>  
 Response:
 That section mentioned above has been moved to the appendix and is no longer 
relevant to the LCUP protocol.
 LCUP does support partial and fractional synchronization.
 
>    
> Issue Number: 11
>
> Description: Does entryDeleted break the protocol?
>
> Summary:
>
> The description for entryDeleted states at first that it indicates that
> the entry being returned has been deleted--then goes on to say that it
> also might indicate that the entry has left the result set. In the case
> of it being due to the entry has left the result set, we need to answer
> these:
> 1) If due to a rename, what DN is used (old or new)
> 2) If the entry is not in the result set, doesn't it break the LDAP
> protocol to return it (it doesn't match the filter)?
>
> Concensus:
>
> No change required. Clarification was provided on the mailing list.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01525.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01545.html
>  
 Response:
 LCUP 04 makes it clear what it means for an entry to have left the result 
set.  And yes, this does "break" the LDAP protocol (specifically as regards 
to search responses), but it is a necessary break to provide a lightweight 
sync mechanism.
 
>    
> Issue Number: 12
>
> Description: Is the EntryUpdateControlValue optional?
>
> Summary:
>
> First, is the EntryUpdateControlValue supposed to be returned during an
> initial synchronization session?
>
> Next, Section 4.8 states: "Each SearchResultEntry may have an
> entryUpdate control attached. ". This indicates that the control is
> optional. Is it?
>
> Concensus:
>
> No further discussion took place on the list on this topic.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01527.html
>  
 Response:
 LCUP 04 makes this much more clear.
 
>    
> Issue Number: 13
>
> Description: What is "a while"?
>
> Summary:
>
> Section 4.8 states "it MUST wait for a while before attempting another
> synchronization session with the server. "
>
>
> Concensus:
>
> If we're going to use an imperative like MUST, we ought to not use
> vague language like "a while". I suggest we drop the MUST anyway--is
> there an interoperability issue here?
>
> The "MUST wait for a while" would be consistent with most other network
> algorithms. If it doesn't wait, it may cause unintentional denial of
> service attacks by swamping the server with connection requests. 
>
> Since LCUP is proposing persistent open TCP connections and
> the use of an error code for resources exhaustion, "acceptable" client
> behavior ought to be specified to help determine a "malicious" client.
>
> Since list comments imply that different use cases of LCUP require
> different back off periods, I'd think that having the server specify
> the initial backoff period in seconds with the lcupResorcesExhausted error
> would be worth consideration.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01528.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01547.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01559.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01569.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01571.html
>  
 Response:
 The LCUP 04 draft says that a "client SHOULD wait 5 seconds before attempting 
a retry".  It also goes on to say that clients SHOULD use an exponential backoff
strategy, but this is not required, as different clients may want to use
different backoff strategies.
 
>    
> Issue Number: 14
>
> Description: note about syncing to different servers
>
> Summary:
>
> What does the "(Note that the client can synchronize with different
> servers during different synchronization sessions.) " mean in the
> context of the paragraph it's in?
>
> Concensus:
>
> No further discussion took place on the list on this topic.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01529.html
>  
 Response:
 This has been removed.
 
>    
> Issue Number: 15
>
> Description: Need for lcupReloadRequired
>
> Summary:
>
> Why is this error needed? It seems that if this scenario exists, the
> server would simply send the full set of entries, and a new cookie. The
> current specification indicates that the client would try to sync,
> receive an error, then try to sync again with an empty cookie. Is there
> a benefit to the extra step?
>
> Concensus:
>
> Yes, it tells the client to delete everything it has.  Otherwise
> it might be left with entries which should be have been deleted
> but were not.
>
> Of course, given that LCUP doesn't ensure this doesn't happen
> under success resync is of concern.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01531.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01535.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01533.html
>  
 Response:
 LCUP 04 provides a mechanism for servers to tell clients, at any time, that 
a reload is required.  I believe the extra step is nice if the client is not
currently prepared to do a resync.  Why?  Is it really that much trouble for
the client to issue another LCUP search request for a full resync?
 
>    
> Issue Number: 16
>
> Description: sync, then sync and persist
>
> Summary:
>
> Why is there a suggestion in Section 6 to "perform an initial
> synchronization...(synchronizeOnly)" and then immediately perform a
> synchronizeAndPersist session? Why not just perform a
> synchronizeAndPersist session to begin with?
>
> Concensus:
>
> What's needed is a intermediate response PDU indicating
> the end of the synchronize phase and provide a new cookie.
> This not only works when there are no sync events, but also
> works when there are persist event occurring during
> synchronization.  Calling it an "end of sync phase" marker
> doesn't prevent an overlapping "persist" phase.
>
> There should be no problem with allowing an overlapping
> "persist" phase (as the current I-D does) AS LONG AS it
> is clear to the client when it has a complete copy of the
> DIT fragment.
>
> Then, we can work on providing the client with a complete
> and accurate copy...
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01536.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01541.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01550.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01551.html
>  
 Response:
 No intermediate response PDU is required.  The LCUP 04 draft provides a
"Sync Update Informational Response" to handle this case.  Also, the new
draft clearly states that overlap of sync and persist phase is not permitted.
 
>    
> Issue Number: 17
>
> Description: rename of baseObject (was something else)
>
> Summary:
>
> At 10:20 PM 2002-09-03, Jim Sermersheim wrote:
>    
> >      
> > The scenario I was thinking of is one where the base existed when a
> > persistent LCUP session starts, but later is renamed or deleted.
> >    
>    
>
> Concensus:
>
> Client Considerations implies noSuchObject is
> returned in this case.  This needs to be detailed
> in Section 4 (along with many other protocol
> details found in sections 6 and 7).
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01538.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01543.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01548.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01549.html
>  
 Response:
 This is addressed in section "4.2 Renaming the Base Object" in the LCUP
04 draft.
 
>    
> Issue Number: 18
>
> Description: subordinate references
>
> Summary:
>
> The document is quite unclear how references are to be
> handled.  What happens when a named subordinate referral
> object [RFC 3296] within scope of the search is added,
> deleted, or modified?
>
> Concensus:
>
> One approach would be to return a searchResultReference
> with a control much like the EntryUpdateControl, but with
> the UUID of the referral object.
>
> Or one could just redefine (and rename) the
> EntryUpdateControl to include the UUID.
>
> Another approach would be require the presence of
> the ManageDsaIT control in the request.  This, basically,
> requests that all referral objects be treated as
> entry objects.  However, the problem with this, is that
> the ManageDsaIT control may be used to manage other kinds
> of knowledge information.  It selects a management plane
> within the DsaIT.  An LCUP with ManageDsaIT should be
> treated as a LCUP request within the management plane
> normally selected by the ManageDsaIt.
>
> Another option is to just to say the all referral objects
> are treated as entry objects when the LCUP control is
> present.
>
> There may be other options.
>
> A preference was expressed for something like the first approach
> (for add, and mod). And a comment was made that a "delete would
> just be a delete."
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01560.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01564.html
>  
 Response:
 We decided to go with something like the first approach, which Kurt elaborated 
on in his sync I-D.
 
>    
> Issue Number: 19
>
> Description: collective attributes, subentries, etc.
>
> Summary:
>
> Some statement should be made with how LCUP interacts
> with collective attributes appearing both in the
> filter and returned entries.  The simple approach
> would be to say: 1) filter should not contain
> assertions upon collective attributes, 2) changes to
> an collective subentry will not cause entries within
> the collection to be "updated", 3) clients are interested
> in maintaining sync with collective attributes should
> include the collective subentry within an LCUP request.
>
> Which leads to another question:
> 	how does a client ask for update of both entry
> 	and subentry DSEs subordinate to the baseObject object?
>
> This is similar to the subordinate referral issue.  One
> could generalize the question to:
>
> 	How does a client ask for update of all DSEs of
> 	a particular combination of DSE types subordinate
> 	to the baseObject?
>
>
> Concensus:
>
> No other discussion took place on the list on this topic.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01561.html
>  
 Response:
 If subentries are within the scope of the request, and the subentry control 
is present, the subentries are treated and returned just like normal entries.
 Virtual (collective, et. al.) attributes are handled just like regular attributes.
 This means that if you change a virtual attribute definition, you may cause
many entries within the search scope to be returned as modified.  Alternately,
the server may decide that would be too expensive of an operation and simply
force the client to resync.

It would be nice if there were a search control which would allow the client
to specify that no virtual attributes are to be returned.
 
>    
> Issue Number: 20
>
> Description: operational attributes
>
> Summary:
>
> We need to state how updates to operational attributes (both stored
> and not stored) affect LCUP.
>
> Concensus:
>
> There are different classes of this:
>
> 1) A server internally increments a numSubordinates attribute on the
> parent of an entry being added or deleted (server responding to client
> action)
> 2) A server modifies replication-related information (server responding
> to bilateral processes)
> 3) A server updates the state of a transitional attribute (response to
> an internal, timed operation)
> 4) An entire set of operations like those above that affect the value
> of an operational attribute, but the value is generated dynamically,
> only when read by a client.
> 5) A client updates an operational attribute.
>
> We should also discuss any differences in behavior among the three
> different types of operational attribute (directoryOperation,
> distributedOperation, dSAOperation).
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01565.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01572.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01573.html
> http://www.imc.org/ietf-ldup/mail-archive/msg01574.html
>  
 Response:
 If a client requests an operational attribute, then the client should get 
it - no special handling.
 
>    
> Issue Number: 21
>
> Description: Changes to attributes not in attributes list
>
> Summary:
>
> When we implemented psearch, there was contention over whether
> or not the client should be updated when a modification is made
> to an attribute that was not requested by the client.
>
> Concensus:
>
> No other discussion occured on the list on this topic, however,
> in this case, silence seems to indicate the following intent.
>
> The case for NOT sending these entries is pretty strong. I'm not
> sure what arguments can be made for sending them. In either case,
> this needs to be spelled out in the draft.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01566.html
>  
 Response:
 The client will only be notified of changes to requested attributes.  If 
a non requested attribute changes, the client will not be notified.
 For deleted entries, especially in servers that use tombstones that do not 
contain the full attributes and values of the entry, the server MAY send deleted
entry notifications for entries that are not and have never been in the client's
result set - the client MUST ignore these.
 
>    
> Issue Number: 22
>
> Description: Interaction with other controls?
>
> Summary:
>
> How does this control interact with other controls?
> How does this control interact with existing search controls?
> Paging? Sorting? Matched Values? Duplicate Entries? VLV? etc.
>
> Concensus:
>
> There was no further discussion about this topic on the list.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01570.html
>  
 Response:
 "LCUP defines neither restrictions nor guarantees about the ability to use 
the controls defined in this document in conjunction with other LDAP controls, 
except for the following:  A server MAY ignore non-critical controls supplied 
with the LCUP control.  A server MAY ignore an LCUP defined control if it 
is non-critical and it is supplied with other critical controls.  If a server 
receives a critical LCUP control with another critical control, and the server 
does not support both controls at the same time, the server SHOULD return 
unavailableCriticalExtension.
 
 It is up to the server implementation to determine if the server supports 
controls such as the Sort or VLV or similar controls that change the order 
of the entries sent to the client.  But note that it may be difficult or impossible
for a server to perform an incremental synchronization in the presence of
such controls, since the cookie will typically be based off a change number,
or CSN, or timestamp, or some criteria other than an alphabetical order."
 
>    
> Issue Number: 23
>
> Description: cookie schemes, why?
>
> Summary:
>
> The document doesn't adequately describe why cookie schemes
> are necessary...  in particular, why would a client ever
> want to request a particular scheme?  How would a client
> determine which schemes where supported by the server?  And,
> if the server is allowed to support differ schemes in different
> subtrees, how would a client determine which schemes where
> supported in which subtrees. 
>
> The need to allow the client to request particular cookie
> schemes is being questioned after prior concensus was
> established on this topic. It was suggested that there
> if there is a need for this, then we need to make sure
> adequate discovery mechanisms are provided so that client
> can which schemes are supported where (yuk). Which is
> a topic that has been discussed during the WG meeting
> prior to the issuance of this WG Last Call.
>
> It was also suggested that if there is no reason, that no
> means be provided to allow a client to request a particular
> scheme.  If later some need arises, LCUP can be extended.
> That extension would have to deal with scheme discovery
> issues.
>
> Concensus:
>
> >From past discussions, the main purpose of the scheme was
> to facilitate protocol operations in replicated environments.
> That is, where the client resumes an LCUP session on a
> different server then that which provided the cookie, the
> scheme allows the server to determine the cookie format
> used by the other server.  If the doesn't recognize the
> scheme, it can return an error (or a referral to the
> servers which do understand the scheme?).
>
> Concensus in the WG Meeting Prior to the issuance of
> this WG Last Call was that a cookie discovery mechanism
> was not needed. This was posted to the mailing list in the
> form of meeting minutes from that WG Meeting.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01607.html
>  
 Response:
 The cookie discovery mechanism has been removed.
 
>    
> Issue Number: 24
>
> Description: various LCUP issues
>
> Summary:
>
> A posting was made shortly prior to the end of the WG Last call
> period containing several comments/issues.
>
> Concensus:
>
> No further discussion took place on the list in response to this posting.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01608.html
>  
 Response:

(Below, I assumed RUV (as in section 7) as the cookie.)
In the case that RUV is returned to the client periodically

during a synchronize session, it may not have much

meaning unless the returned entries are sorted

(as in size limit case in section 7).

  I would consider that to be a server implementation detail - if the server
 returns a cookie, it should be able to accept it and use it whenever it
is  presented with an LCUP search request.  I think it is outside the scope
of  the LCUP draft to impose this sort of implementation detail.

Otherwise, upon error during a synchronization session,

the next synchronization should restart from
the RUV before the failed synchronization not from the last

received RUV before error.
If this is the case, periodic delivery of cookies during

a synchronize section may be meaningless.

  It's up to the server implementation - if the server returns a cookie,
it  should be able to use it.

> It seems that the above paragraph also holds when a time limit is imposed.
> A possible issue with the time limit is that the time to sort the result set
> may be larger than the time limit itself.
> The sorting may also be required when we decided to cope with errors during
> a synchronization session in such a way that avoids restart from the pre-session state.

 Again, that is a server implementation detail that won't be specified by
LCUP.  The server should ensure that it returns a cookie to the client if
a size or time limit is exceeded. 
>    
> Issue Number: 25
>
> Description: LCUP Draft inline comments
>
> Summary:
>
> Many comments, some of which were editorial, are included in the posting
> associated with this issue.
>
> Concensus:
>
> Some of these issues were discussed separately and would be duplicates of
> those above if documented seperately here. Some of them are editorial and
> should be incorporated. Comments classified otherwise should be posted to
> the mailing list by the document editors for further discussion.
>
> Relevant Posting(s):
>
> http://www.imc.org/ietf-ldup/mail-archive/msg01598.html
>  
 Response:
 
>  
>     Several features of the protocol distinguish it from LDUP 
>     replication. LCUP is designed such that the server does not need to 
>     maintain state information on behalf of the client. 
>   
>  TJH: I don't understand how servers won't have to maintain some level 
>  of information related to the client if deleted entries are going 
>  to have to be "remembered" 
>  
  Tombstones?  No client state information needs to be saved.  
> and potentially "cookie" values will 
>  have to be "remembered" as well. 
>  
  If the cookie value is an RUV, then server will have to store this, but 
 it doesn't have to store them on a client by client basis.  Each client 
will just refer to the RUV used by the server.  Unless I misunderstand  what 
you're getting at here?  
>    LCUP operations are subject to administrative and
> access             control policies enforced by the server. 
>   
>  TJH: Might be good to note that something like a change 
>  to a server's access control settings may cause a client to be 
>  UNABLE to synchronize (for all of the information that it might 
>  be holding already). 
>  
  Right. The server may then, at any time, return to the client that a reload 
is required. 
>    A part of the DIT 
>   
>  TJH: clarify "part". 
>   which is enabled for LCUP is referred to as an 
>     LCUP Context.  A server may support one or more LCUP Contexts.  
  Done.  For example, a naming context can be an LCUP context.
 
  
 >      synchronizeOnly - the server sends all the data needed to 
 >        synchronize the client with the server, then closes the 
 >        connection 
  >
 > TJH: When this is specified, is it possible that the same entry may
 > be sent to the client MULTIPLE times, if, for example, the entry 
 > was modified by some other client while the LCUP session was still
 > processing/returning data?  If so, this should be noted. 
 
 Right.  This is noted in detail in the new draft.
 
  
 
>  
>      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 that has left the result set. 
>   
>  TJH: How long must a server "remember" that a client "knew" 
>  about an entry in order to know when to send/set this flag on 
>  an entry returned to the client over the LCUP session? 
>  
  
 It is entirely up to the server implementation.  The server implementer
 and administrator will need to keep in mind the presence of replication
 and LCUP clients in order to set the tombstone reap policy, for example.
 
>     S->C   Stops sending changes to the client 
> and closes the connection. 
>   
>  TJH: Why does it close the connection?  What if other concurrent  operations
>    
>  are being performed over the connection? 
>  
  You're right.  It doesn't need to close the connection - it just needs
 to finish the LCUP request. 
 
  
 
> .  The client SHOULD maintain a cache of the LDAP 
> URLs returned 
>     in the continuation references and the cookies associated with them.  
>     The client is responsible for performing another LCUP search to 
>     follow the references, and SHOULD use the cookie corresponding to 
>     the LDAP URL for that reference (if it has a cookie). 
>   
>  TJH: I don't think I understand this one.  Does this imply that one server
>    
>  can add cookies that would be interpretable by some other server that is
>   
>  pointed to by the searchResultReference? 
>  
  No, it means a server can send references to itself, in order to  maintain 
different cookies for different LCUP contexts.  
> The server SHOULD send a 
>     SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context
>   
>     for a returned entry changes.  The server SHOULD return all entries 
>     for a particular LCUP Context before returning a reference to other 
>     LCUP Contexts or non-LCUP enabled parts of the DIT, in order to 
>     minimize the processing burden on the clients. 
>   
>  TJH: I disagree with this SHOULD.  By sending references "early", 
>  a multi-threaded client has the "opportunity" to do things in parallel.
>   
>  But by sending the references "late", the client has no choice but to 
>  serialize the operations - prohibiting parallel operation. 
>  
  That's a good idea.  I'll change the wording so that the server MAY  return 
all searchResultReferences first.