RE: Is State-based LDUP needed?

I'm okay with answering it "yes" to both your questions, and in so doing
relegating all references state-based replication to the dust bin.

I would further assert that unless at least two directory service implementors
object, that the current "concensus" of "yes" to both will prevail.  I don't think
the plans of only one party to implement the option should result it retaining
it in the face of the (a) added complexity, and (b) transient inconsistencies
that would result.

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/29/02 05:28PM >>>


Tim,

Timothy Hahn wrote:
> Hi all,
>
> Steven Legg wrote:
>>
>> I think it boils down to two questions.
>>
>> Q1: Do we insist that replication primitives are always sent in
>> CSN order per replica ID ?
>>
>> Q2: Do we insist that superseded primitives are propagated anyway ?
>
> My opinion on these two questions are:
>
> Q1: I vote "yes" to this one.
>
> Q2: I could go either way on this.  It would seem we would be "more
correct,
> more of the time" if we insisted that superseded primitives are
propagated -
> at the expense of a little more information being sent during replication
> sessions.  However, it would appear that LDUP will work either way (after
> all, "eventual consistency" is what is required).  Thus, I would allow
this
> as an implementation choice - i.e. superseded primitives MAY (or MAY NOT)
be
> propagated.  I also think that it is in the best interests of all involved
if
> the update reconciliation procedures draft (or the update replication
> protocol draft) points out the issues involved if superseded primitives
are
> NOT sent.  (It seems a shame that this analysis would only be documented
in
> the mailing list archives).

I can expand the section in URP on superseded primitives to point out the
issues if the consensus on Q2 is "no". If the consensus is "yes" then I
will instead be taking out all the provisions for state-based
implementations.

Regards,
Steven