RE: Replica Management - subtreespecification attribute

"Timothy Hahn" <[email protected]>
Newsgroups gmane.ietf.ldup
Message-ID <[email protected]>
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.

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).

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.

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: [email protected]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681





"Steven Legg" <[email protected]>
Sent by: [email protected]
01/28/2002 11:45 PM
Please respond to steven.legg

 
        To:     "'Richard V Huber'" <[email protected]>
        cc:     <[email protected]>
        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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.