Replica Management - high-level state of a replica

As we work on the next draft of MRM, we have a number of questions we
would like to ask the WG and the authors of the other drafts
(particularly the Architecture and InfoMod drafts).  There will be a
set of emails dealing with different issues coming out at odd
intervals - we want to get questions on the table as soon as we can
rather than wait for the one grand summary email that covers
everything.

So here is the first issue - it has to do with the major states of
replication and how we switch among them.

We see three major states that can exist:

 1 - A particular instance of a directory is NOT PARTICIPATING in
     replication for a given area of replication and a given second
     instance.  In this state the instance need not record change
     information for changes made in the context.

 2 - A particular instance of a directory is PARTICIPATING but NOT
     ONLINE for a given area of replication and second instance.  In
     this case changes are recorded and will be sent when the instance
     goes ONLINE.

 3 - A particular instance is PARTICIPATING and ONLINE for a given area
     of replication and second instance.  In this case changes are
     being exchanged (subject to replication schedules, etc.).  It is
     possible for a given server to be ONLINE with some of the other
     servers in the replica group and NOT ONLINE with others.

The fourth case (ONLINE and NOT PARTICIPATING) cannot occur.

If we accept these major states, we also have to know what events
trigger changes among the states.  We propose the following:

 - A directory instance starts PARTICIPATING with a given second
   instance when the replicaSubentry with its replicaURI pointing to
   the second instance is created in the first instance.  It stops
   PARTICIPATING when this replicaSubentry is removed.

 - Per InfoMod, each instance of a replica has a replicaSubentry object
   representing each of the replicas - one for itself and one for each
   of the other replicas.  Each of these replicaSubentry objects
   contains a replicaOnline attribute.

   To allow control of the replication process, we propose that the
   replicaOnline attribute DOES NOT REPLICATE (e.g. it is a
   DSA-specific attribute).

   A directory instance A is ONLINE with a second instance B when ALL
   of conditions a-d below are met:

     a - Instance A's replicaOnline attribute for instance A is TRUE

     b - Instance A's replicaOnline attribute for instance B is TRUE

     c - Instance B's replicaOnline attribute for instance B is TRUE

     d - Instance B's replicaOnline attribute for instance A is TRUE

   So if an instance's own replicaOnline attribute is FALSE, it is NOT
   ONLINE with any other instance in that area of replication.  Also,
   both participants in a replication session must agree that they are
   ONLINE for the session to proceed.

 - Since an instance starts PARTICIPATING when the replicaSubentry is
   created and since the replicaOnline attribute is in the
   replicaSubentry, it is impossible for an instance to be set ONLINE
   if it is NOT PARTICIPATING.

Any comments? :-)

A related question:

 - InfoMod specifies that servers MUST automatically add and delete
   values from the root DSE attribute replicaContextRoots.  For the
   root DSE attribute replicaSubentries, InfoMod says that values must
   be automatically deleted but says nothing about automatically adding
   values.  We hope this is a typo and would like to see entries
   automatically added as well as deleted.

One reason this is important is that we want to allow for overlapping
areas of replication per the Requirements.  Since this means that a
given replica context root may be the root of more than one area of
replication, we feel that the area of replication is really defined by
the replicaSubentry,

Rick Huber
John McMeeking
Ryan Moats