Re: Open issues / questions re: Architecture of LDUP

<eer>
Maybe it's early in the AM, Kurt, but I'm unsure as to your meaning...

In the LDUP information model, we use subentries in several places...

a) as the definition of the "area of replication" associated with an
LDUP administration point, 
b) as the specification of the contents (may be either the same
set or a subset of the one defined for the "area of replication")
held by a particular replica on a particular server, and 
c) as the set (may be either the same or a subset of the one
defined for the supplier replica) of entries about
which change information is to flow along a particular replication
agreement between two (or possibly more, tbd) particular replicas.

Which of those do you mean in your remarks??
</eer>

>>> "Kurt D. Zeilenga" <[email protected]> 03/05/02 11:32PM >>>

At 02:54 PM 2002-03-01, Ed Reed wrote:

>Hello, all.
>
>In compiling the latest version of the architecture document (draf-ietf-ldup-model-07.txt, just submitted and copied to the list), I tried to keep track of the things I don't know about what we're doing.  Here's a summary...
>
>1) what administrative model will be used for managing replica topology information?  There are three offerings on the table:  a retracted proposal from me with my ldapSubentry definition, Kurt's Subentry schema entry implies certain things that would come from the X.500 admin model, and Steven Legg's description of the X.500 model as adapted for LDAP for use with a Basic or Simple Access Control models.  I hope we'll arrive at a concensus (quickly) to adopt the work Steven's worked on (since my own offering was shot down out of the gate).
>
>2) Replica Context and Replicas with regard to DSAs - is it allowed to define two or more DIFFERENT Replica Contexts for the same portion of the DIT (for instance, one full and the others fractional in different ways)?  Are those different Replica Contexts, or different replica configurations of the same Replica Context?  

I would argue that all entries within scope of a subentry
define a "area of replication" or "replica context".  (I would
use only the term "area of replication".)  Each subentry
defines one replication agreement.  It may be appropriate to
limit the scope of that agreement to only a pair of replication
peers and possibly even to one replication flow.

>4) Are sparse replicas in or out?  right now, they're out of the architecture, but read-only franctional replicas are in.

Not to further wrapped around terminology, I'd say in.  In
fact, I suggest one use the subentry's subtree refinement
mechanism to define a sparse set of entries to replicate.

Kurt