RE: Replica Management - subtreespecification attribute

I can't tell if concensus was reached on this or not, so I'll bring it up again...

The purpose of placing the subtree specification, along with other scoping
information, onto the replicaSubentry was precisely to create a single entry
that would define the replication context.

The purpose of allowing additional scoping information to refine what is
to be passed along certain replicationAgreements between particular
replicas was to control the flow of changes across certain links in the
replica topology.  By refinement, I mean further contraint.  ReplicaAgreements
inherit, by subordination in the namespace, the knowledge about
what entries and attributes are contained in the replica they're subordinate
to, and to which they refer (by the very DN syntax method you suggest).

If my proposed model of name subordination is abandoned for replicaAgreements,
then of course, there will need to be a DN reference to the second endpoint of
the replicaAgreement association (falling into DEN-eese, here).  Or to all of them,
if it's to be multivalued.

Tim - have we decided to move away from hierarchical subentries, so as to
more completely and "purely" embrace the X.501 subentry syntax?

If so, you'll wind up with a "bag" of replicaSubentries, together with a "bag"
of replicationAgreements, all necessarily shared/known by all replicas, with
some arbitrary graph where replicaSubentries are nodes of the graph and
replicationAgreements are the edges.  It will then be encombant on
administrators (and their tools) to ensure that the graph remains connected,
that there are no black holes (replicaSubentries which are updateable but
have no outbound path of propagating changes to others), etc.  In otherwords,
that there remains a "correct" graph, for some definition of "correct".

I must say I dislike designs that place the responsibility for insuring "correct"
deployment on the administrators.  I much prefer designs which create
systems that are correct to begin with, and that can then be broken, if
necessary, with enough mule-headed persistance of those administrators.

Anyway.

Rick - I think your desire for an entry, somewhere, that describes the
replication context (scope) that will be shared by all the replicaSubentries
(and possibly refined by them) is a good one.  In the absense of a "primary"
replica (my preferred method of solving this problem), I suggest that a
subentry be defined that explicitly is used to designate the anchor point
for the ldup administrative area that coincides with the replication context.

For clarity, here, I reproduce from memory what I mean by those words...

A replication context is a partion of the DIT for which there are one or
more replicas.  Each replica is represented by a replicationSubentry
immediately subordinate to the base entry of the replication context.
Replicas of the replication context may be full or partial.  If they are
administratively constrained to hold less than the full replication context
(ie, all the entries and all their attributes in the partion of the DIT
represented by the replication context), the refinements (constraints)
for each replica are represented by filters on the respective replicaSubentry
for that replica.  Note that I'm explicitly using terminology here to
preclude the notion that a replica holds MORE than ALL the entries
and attributes of the DIT, because that seems nonsensical.  The data in the
DIT is the data in the DIT.  

(Aside - if the replica context EXPLICITLY
lists the entries or attributes, by including filters in its very definition, then
it is effectively PROHIBITING subordinate replicas from holding information
not permitted in those filters.  On the other hand, if it's not prohibited,
as would be the case when there are no filters on the replica context
definition, then subordinate replicas MIGHT define schema elements
locally that THEY can hold, but which cannot be held by other replicas
unless the changes to the schema can be propagated via LDUP - which
may or may not be possible, depending on the replication agreements
and constraints defined on those other replicas).

As aluded to, above, replicationAgreements, which document the
dataflow between replicas, may themselves have constraints as to
the entries and/or attributes which may be passed across them.  Again,
though, those constraints, if present, cannot by definition exceed the
set of entries and attributes permitted by replica context definition (however
it is represented).  So, again, if the replica context definition is permissive,
subordinate replicas and their replicationAgreements can create local
extensions of the schema they share among themselves.  But if
explicitly defined through constraints, the replica context schema definition
cannot be expanded upon in ways to permit in a replica or replicationAgreement
what is prohibited by the replica context definition.

Make sense?

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Steven Legg" <[email protected]> 01/28/02 11:45PM >>>


Rick,

Richard V Huber wrote:
> We noted in a previous email that, to allow overlapping areas of
> replication, we feel that an area of replication is defined by a
> replicaSubentry.  The replicaSubentry defines the boundary of the area
> via the subtreespecification attribute.

Note that a subtree specification identifies a collection of entries,
but not a subset of the attributes within them. That is, it specifies the
sparseness of a partial replica. Something else in addition to the subtree
specification is required to specify the fractionalness of a partial
replica,
i.e. the attributeExclusionFilter and attributeInclusionFilter attributes.

Regarding terminology, you appear to be using "area of replication" to mean
some part, possibly but not necessarily all, of the information in a
replication
context. Thus a single replication context can have more than one area
of replication within its scope. This is what I assume it means, however
areas of replication (a.k.a replication areas) are not defined in the
architecture and model drafts and tend to be used as synonyms for
"replication context".


> Because a subtreespecification may need to be shared across a
> number of
> subentries (e.g. all the replicaSubentries that refer to a common area
> of replication), we would like to have a single subtreespecification
> that can be referenced from multiple subentries.  Accordingly, we
> would like to change the subentry objectclass to use
> subtreeSpecificationDN and allow the subtree specification to
> be stored
> as a separate entry which can be referenced as needed.

This separate (sub?)entry would contain the attributeExclusionFilter and
attributeInclusionFilter attributes as well.

An alternative to a subtreeSpecificationDN attribute would be to place
the replica subentries subordinate to the (sub)entry describing their
area of replication.

Either way, I would support making such a change to the information model.

Regards,
Steven

>
> This may be useful in other cases where a single subtreespecification
> needs to be used consistently in several places.
>nis effectively PROHIBITING subordinate r
> Rick Huber
> John McMeeking
> Ryan Moats
>