RE: I-D ACTION:draft-langer-ldup-mdcr-00.txt

["Payne, Alison" <Alison.Payne@xxxxxxxxxxxxxxxx>]

Hi John,

Some thoughts on your questions.

>  1) is the requirements document as currently written
>     too vague? That is, should we delay sending it to
>     IETF last call? Please read sections 1 and 3 of
>     this draft to answer this question.

Is it possible to state as a requirement that it is undesirable to have the
following happen? :
- update is accepted at DSA 1, 
- administrator leaves terminal thinking that update has occurred,
- conflict later detected at DSA x and update is "rolled back" (i.e. return
to the previous state)
- administrator comes back and notices that entry is back to the state prior
to the update done some time ago.

The other issue with the requirements is whether reducing the complexity of
implementation is important.  We have made some hard choices about
consistency in the interests of getting a workable solution.

>  2) should we add this draft as another possible
>     conflict resolution method, or should we replace
>     URP with this draft, or should URP stay as the
>     only method of conflict resolution.

A couple of quick comments about the alternative to URP :
- We went part of the way along this track but attempted to reduce the
detected conflicts to conflicts which really occur.  This becomes quite a
complex exercise of comparison between operations/states requiring
additional information to be stored to be able to track what has happened
and resolve it consistently.  Albert has chosen to make the conflict
detection fairly simple - as I understand it, any two operations which occur
on the same entry without knowledge of each other conflict and one won't
take effect. Again, its a trade off.
- I think that the proposed mechanism doesn't propose a solution to some of
the conflicts on parent nodes etc so we would still need to use URP for
them.  How do we integrate the two if Albert's proposal takes over only the
entry attribute conflicts?

Cheers,
Alison