Subject: replication transfer protocol spec (+ more comments)

From: Ellen Stokes <[email-masked]>
Date: Mon, 25 Oct 1999 08:31:07 -0500

Please find attached the draft for the replication transfer protocol
that was submitted last week.
Also, I attached a list of items that need to be addressed in that
draft.
Ellen

****************
- As we've started working on a prototype implementation, we decided 
that part of the initial replication exchange should also include the 
supplier sending the consumer a "recent" CSN (e.g. maybe the next CSN it 
would generate), so that the supplier can detect excessive clock skew 
(either its own clock, or the supplier's). There would also be a new 
return code that means "your clock is messed up - go away".
I think the architecture document, or some other document, ought to talk 
about CSNs and what happens when a server's CSN generator regresses or 
advances relative to another's, but that's not something we'd want to 
tackle in the protocol document.

- We may need to state something about ordering of updates in the 
protocol and how that relates to the order in which the updates are 
processed. For example, in our server implementation, normal 
LDAP operations are assigned to any available worked thread, which means 
that two operations received in one order might actually complete in the 
reverse order. This may not be acceptable for replication updates, e.g. 
you might end up processing an entry modification before the addition of 
the entry. All umich-derived servers are probably going to have this 
issue.

- Address whether the LDAP bulk update/replication protocol should
be included in this draft or continue to be in its separate draft 
(draft submitted by Roger Harrison).

- Add to semantics section:  As long as consumer knows it is talking
to a log-based supplier, the consumer can update its update vector
at connection loss time, so this behavior needs to be expressed as
a parameter

- Add to semantics section:  Replication status needs to be updated 
at end of each replication attempt

- Add ordering flag to supplier init protocol flow

- Use RFC 23xx (not RFC 822) for BNF

- Look at constraints and use as appropriate in the protocol doc

- Describe semantics with respect to access control

- Describe error codes/conditions in the semantics

- Rename the extended ops

- Question to resolve:  If the C API or Java API draft sufficient
for the replication API?

***************