9. "Replication of ACI changes"

["Albert Langer" <Albert.Langer@xxxxxxxxxxxxxxxxxxxxx>]

Steve,

I am deferring responses to your replies on items 3 and 5 for now, while
catching up with the rest of my original list:

Done 3,4,5 and 8 so 1,2,6 and 7 still to go.

However I am also starting a separate thread 9 on this issue as it doesn't
really belong with item 3 and should be dealt with fully. Hoping you can
kick off the discussion.

At the end of my item 3 I mentioned in passing that:

> MDCR also carries the full DN of each modify
> operation within the
> protocolOp, which is not strictly necessary for the current
> draft (00), and
> could be omitted as URP does, if the number of bytes was a
> dominant concern.
> However I believe it will be necessary for dealing with
> potential conflicts
> between replication of prescriptive ACI information applying
> to an entry and
> changes to the entry. I do not believe URP is capable of
> addressing that at
> all.

You responded briefly:

[Steve]
It's not obvious to me what sort of conflicts you are talking about.
Changes to prescriptive ACIs are much rarer than changes to entries
and unlikely to be directly linked. If there is a concern then wouldn't
MDCR be in bigger trouble because it is liable to completely discard
one of the linked changes ? Merging has fewer failure modes.

[Albert]
The sort of conflicts I was thinking about and preparing for, but did not
attempt to explain, and have not dealt with in my draft, (nor you in yours),
relate to the interaction between concurrent changes to any entry affected
by changes to prescriptive ACI applicable to entries depending on what the
entry's DN actually is (ie whether or not it is actually in a particular
subtree or subtree refinement regardless of its UUID). I do not think any
solution should attempt to directly link the changes. It is not obvious to
me either, as to exactly what problems there might be - but those are the
sort of problems I worry about most, as potential problems that are clear
are easily dealt with ;-0

Anyway, it is even less obvious what the solutions to unobvious problems
might require, so I didn't want to throw DN away and propagate only entryID.

As you know I have not proposed an alternative to URP's basic approach for
dealing with modifyDN, create and delete operations, but only for modify
operations, since your approach to the former does maintain atomicity.

I have suggested to both of you (via email twice to Alison with no reply)
that we get together again face to face over at least ACI issues, as we are
all in Melbourne. I'd still welcome that if you are interested.

Meanwhile, on the simpler issue of just replicating ACI *at all*, I believe
that MDCR behaves correctly by accepting only one change at a time, and that
the consequences of non-atomicity in URP are vividly illustrated by
considering its impact on simple ACI replication.

Could you please elaborate on your remark that "merging has fewer failure
modes", in this simpler context, with particular reference to the scenarios
that could result from merging concurrent changes to different ACI
attributes and attribute values as currently proposed in:

http://search.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-06.txt

(BTW as already mentioned I agree with your remark that the number of bytes
is really a "non-issue").