Subject: Re: Subentries decision - internet draft withdrawn

From: "Ed Reed" <[email-masked]>
Date: Fri, 02 Nov 2001 15:53:20 -0700

<eer> comments </eer>

=================
Ed Reed
Reed-Matthews, Inc.
+1 716 624 2402 (new!)
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <[email-masked]> 10/31/01 09:21AM >>>
At 08:17 AM 2001-10-30, Ed Reed wrote:
>1) encourage Kurt to revise the draft to make it "Standards Track"
>instead of "Informational", so we can refer to it;

no problem.  <eer> thanks </eer>

>2) Follow David Chadwick's suggestion that we define the
>replicationAgreementSubentry class as a subclass of the X.500
>subentry, and define a structure rule for it that allows containment
>of the replicationAgreementSubentry class entries by replicaSubentry class
>entries.

no problem.  <eer> thanks </eer>

>3) discourage use of the specificationFilter in the SubtreeSpecification,

I note that specificationFilter seems to a useful in supporting
sparse replication.

<eer>

Yeah, I know.  But that's what I"m afraid of right now, because I'm having
trouble visualizing how the administration tool (built on Microsoft's Console
or Novell's ConsoleOne or NetScape's Directory Manager) will represent
the sparse replication, and worse yet, the overlap, if any, of two
different replicaSubentry specifications of the same replicationArea when
they choose different subsets of entries, or possibly overlapping subsets
of entries.

I know there are uses of such things, but it seems to me that the 80-20
rule would dictate that 80% of the time such sparse replication won't
be needed, or wanted, and support for the other 20% will, while
possible, more difficult to manage correctly.  If we don't discourage its
use, then it will have to be supported by everyone, whether they can
create a management tool to make sense of it by administrators, or not.

I confess, this is an area of my own bias.  I can certainly be persuaded
to just let it go and see what the market creates.  But I've felt that I
owed the community that would listen this one last appeal for simplicity
of required implementation.  Nuff said.

</eer>

Kurt