RE: Replica Management - subtreespecification attribute

Hi all,

Sorry for being silent for awhile on this topic - too many things to do.

I've put some comments below with <TJH> ... </TJH>

I have NOT updated the infomod document yet, we'll see how this line of
discussion pans out before I do that.

Regards,
Tim Hahn

Internet: [email protected]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681



                                                                                                                                       
                      "Ed Reed"                                                                                                        
                      <[email protected]        To:       <[email protected]>, <[email protected]>                            
                      M>                       cc:       <[email protected]>                                                           
                      Sent by:                 Subject:  RE: Replica Management - subtreespecification attribute                       
                      owner-ietf-ldup@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      02/26/2002 10:04                                                                                                 
                      AM                                                                                                               
                                                                                                                                       
                                                                                                                                       




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.
<TJH>
I agree with this.
</TJH>

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).
<TJH>
I don't agree with this "subtle change in usage" of the
subtreespecification
setting in the replicationAgreement entries.  Why?  I guess I just see this
as
too confusing.  I'm sort of "on the fence" on this one, so I could be
convinced otherwise I guess.  What's the consensus?
</TJH>

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?
<TJH>
I have NOT moved away from name subordination - I still think it is a good
idea to make use of the hierachy of entries to organize these.
</TJH>

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.
<TJH>
I've been hoping, perhaps naively, that the update reconciliation rules and
update replication protocol itself would be used to transfer the subentry
information between servers as well, allowing the "administration point"
to contact the server of its choice (within bounds of course) in
setting things up.  I've been reluctant to require the designation of any
one server in the replication topology as the "master master" or "primary
master", in hopes that the LDUP models would allow administration of
topology to be done in a distributed manner as well.
</TJH>

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).
<TJH>
In light of what I said above, perhaps replication and/or subentry
information must be replicated all the time, without regard to the
scoping and filtering done for "other entries".  Further, administration
of topology MUST be performed on SOME server that will allow this
information to "eventually appear" on ALL servers in the topology (e.g.
you can't administer replication agreements on a server that is
not configured to replicate TO anyone else)
</TJH>

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
>