RE: Replica Management - subtreespecification attribute

["Ed Reed" <eer@xxxxxxxxxxxxx>]

<eer> remarks </eer>

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

>>> "Timothy Hahn" <hahnt@xxxxxxxxxx> 01/29/02 08:33AM >>>
Hi all,

With respect to "area of replication" terminology used in the infomodel 
draft, I meant it to be synonymous with "replication context", i.e. the 
set of entries in the directory (or "area" in the directory) that is 
"covered" by the replication agreement(s) and replica subentries defined.

<eer> Agreed.  I think.  But see below. </eer>

With respect to subtreespecification, I had expected that the 
subtreespecification of the replicaSubentry would be the value that is 
used and that the value would be FORCED to be identical across all 
replicaSubEntry entries that have the same parent (that parent being the 
"root" of the replication context).

<eer> My vision is subtly different, but depends on the authority of
the "primary" master.  I would treat the subtreespecification on the
"primary" master replicaSubentry to be "authoritative" for the replication
context, and that the subtreespecifications on other replicaSutentries
for other replicas might SUBSET the one on the "primary" master, but
not SUPERSET it.  More naturally, it might have been easier to
put a subtreespecification on the root of the replication area itself
as part of an auxilliary class that designates that entry as the root of
the area...but I consider that approach now depreciated in favor of
using subentries...

So...in the absence of a "primary" master to treat as authoritative, 
it would make sense that there be a possibly new subentry specifically
to document the shape, extent, and scope of the replication area.  Then
one would look to each of the replicaSubentries to find what SUBSET
of the whole replication area they held.  And to the replicationAgreement
subtreespecifications to find what SUBSET of the entries held by the
replicas using that replication agreement are to be transmitted under
the auspices of that agreement.  

This process of iterative refinement should keep replicas from ADDING
data to the replication area, but allow them to reduce the set of data
they hold from all available data.

Note that if you allow each master to SUPERSET the definitions, you're
implicitly providing a way to create local islands of private data...an
interesting notion, but not one I'd like to experiment with, here.

I have fixed clearly in my own head that there is a server somewhere
that holds all the data for all the entries in the replication area.  There
are very interesting problems that might be solved in the area of
data ownership, for instance, where that would not be the case.  But
I lack operational experience (or even theoretical insight) as to how
to make sure that such an environment works "correctly" for some
definition of "correct".

</eer>

I expected that each replicationAgreement would potentially have a 
DIFFERENT set of attributeInclusion and attributeExclusion values (or none 
at all) and thus allow different replicas to have different fractional 
characteristics.  I also expected that the subtreespecification value in 
replicaAgreement sub entries would be IGNORED (preferably set to a 
zero-length value), but ignored regardless.

<eer> Not ignored, but used as a scoping operator on what the
replication agreements said should be included...UNLESS you allow
SUPERSETTING of the subtreespecifications.  I don't know how to create
a coherant description of data ownership and authority where there
are supersets allowed by subordinates.  In my scenario, it would be
as though you took a logical AND of each of the subtreespecifications
involved - what you'll send on the replicationAgreement, what you
hold on your replicaSubentry, what the receiver holds on their
replicaSubentry, and what is defined in the authoritative subtreeSpecification
for the replication area.  </eer>

These statements are not explicit in the infomodel draft today, thus the 
confusion.

What is the working group's concensus on handling them?

Regards,
Tim Hahn

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





"Steven Legg" <steven.legg@xxxxxxxxxxxxx>
Sent by: owner-ietf-ldup@xxxxxxxxxxxx 
01/28/2002 11:45 PM
Please respond to steven.legg

 
        To:     "'Richard V Huber'" <rvh@xxxxxxxxxxxxxxx>
        cc:     <ietf-ldup@xxxxxxx>
        Subject:        RE: Replica Management - subtreespecification attribute

 



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.
>
> Rick Huber
> John McMeeking
> Ryan Moats
>