7. "Revocation notices"

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

Steve,

Here's the response to item 7, which I summarized as:

***
7. "Revocation notices". Implicit agreement that MDCR could add them and
that URP makes no provision for them because it does not revoke anything.
Disagreement as to whether they are useful.

http://www.imc.org/ietf-ldup/mail-archive/msg00614.html

***
Comments follow original below.
***

[Albert]
> The conflicts form a tree in reality, whether it is
> recognized or not. If
> that tree becomes large then URP would produce a high rate of
> "Extraordinary
> States" and "Transient Extraordinary States" while MDCR would
> produce a high
> rate of revocation notices because it has at least recognized
> the reality.
> Neither is appropriate for directory applications. (In my view even an
> extremely low rate of "Extraordinary States" without any
> means except manual
> administration to recover from them is completely unacceptable).

[Steve]
I don't expect many LDAP client application developers will want to
deal with the complexities of out-of-band revocation notices, or deal
with restoring the application context of the original change so it
can be repeated. The enterprising ones will probably just send a series
of spurious changes to an entry after each real change just to "up" the
version number and so increase the chance of the real change sticking.

In effect, what we have done with URP is hardwire a reasonable conflict
resolution mechanism (best effort merge) that is (we think) good enough
for most uses of the directory.

[... Remainder already replied to as item 8, at end of URL above]

***

[Albert]
As you mentioned when changing the name from "Conflict Resolution" to
"Update Reconciliation", best effort merge is not a conflict resolution
method at all, because it sees no modify "conflicts".

URP does recognize conflicts when a child is created concurrently with the
parent being deleted, or two entries are given the same DN via concurrent
creates and/or modifyDN operations.

In that situation URP does store all the information necessary for users
to fix the problem without sysadmin intervention, and therefore also does
store all the information necessary to be able to issue revocation notices.

When you publish a draft with a sufficiently robust purge mechanism to
maintain eventual convergence despite clock non-monotonicity and DSAs
crashing and being restored from backups, you will find that you also have
sufficient information to be able to issue confirmation notices (ie notices
that no such naming collision can occur), and should then also be able to
rename just one of the entries in conflict rather than all of them, without
excessive complication. That is necessary avoid entire existing entries, not
just changes, mysteriously disappearing silently and without notification.

Naming conflicts should be much less frequent than modify conflicts
and are immediately obvious. So I have no objection to simply leaving
revocation and confirmation notices about them for possible future
extensions. No obstacle has been placed in the way of doing it later and you
have enabled users to fix the problem themselves (when the renaming is
restricted
to the results of new operations and not also applied to existing entries).

However the trade off for MDCR in avoiding the problems URP has with simple
modify
conflicts is that even a very low rate of concurrent modify operations
eventually
failing after a success response to a DUA, would still be a much higher rate
than is likely for modifyDN and create operations. Also the eventual
suppression of the operation during convergence would be much less obvious
than for naming conflicts.

Far from being "good enough for most uses of the directory" I regard ANY
regular manual sysadmin intervention as completely unacceptable.

As you have mentioned, it is especially unacceptable for suppressed ACI
changes, but there are also many other situations where silently
suppressing a change that has been reported as successful just won't work.

Just after its clear requirement for atomicity, RFC 2251 adds:

   The server will return to the client a single Modify Response
   indicating either the successful completion of the DIT modification,
   or the reason that the modification failed. Note that due to the
   requirement for atomicity in applying the list of modifications in
   the Modify Request, the client may expect that no modifications of
   the DIT have been performed if the Modify Response received indicates
   any sort of error, and that all requested modifications have been
   performed if the Modify Response indicates successful completion of
   the Modify Operation.  If the connection fails, whether the
   modification occurred or not is indeterminate.

(4.6 Modify Operation, p34)

Current client applications ARE designed with that expectation that all
requested modifications have been performed when they get a success
response. Any for which this is absolutely critical will of course also be
aware that servers sometimes crash before being backed up and will be
designed accordingly, but most applications do simply rely on that
expectation.

In a multi-master environment there is no alternative but to either drop
atomicity (and isolation) of operations or have some operations eventually
suppressed during convergence. That is a harsh reality.

In maintaining atomicity and isolation only for naming conflicts, URP
suffers
from the problems discussed elsewhere.

In taking the opposite approach, MDCR has to provide a "best effort" to
deal with the very real problems that result from that opposite approach.

The best that CAN be done is to issue revocation notices. That isn't
difficult
since all the information needed to do so is stored anyway.

LDUP standards HAVE to work with EXISTING LDAP client APIs and applications.
The whole reason LDAP is an important standard is the widespread adoption of
standardized client access.

I can't think of any application that would achieve anything useful to that
application by adding spurious changes to increase the chances of some other
instance of that application being suppressed during a conflict. Developers
doing so would be stupid, not "enterprising". However if I'm wrong about
that,
then it's good the facility is available.

Email revocation notices just ensure users (and sysadmins) know that a
change
was eventually suppressed, so they can do something about it before
something
else breaks as a result.

There is unfortunately nothing better that CAN be done about such conflicts
in a multi-master LDAP environment with existing clients. I can't see many
LDAP application developers dealing with the complexities of automatically
restoring application state either.

There are of course even less who COULD deal with the complexities of
maintaining, let alone restoring, application state based on merging
of unknown and unknowable concurrent changes as in URP.

NOBODY knows how to develop applications in an environment where the data
you
thought you were changing isn't necessarily the data you actually changed.

So to avoid that absurdity, MDCR just has to do the best it can, which is
revocation notices.

Of course the more important mitigation is moving attributes and attribute
values
that can safely be updated concurrently into separate child entries and
providing
a merged view of the parent as a compound family for existing LDAP clients.

Active Directory seems to be getting away with having just one of the
concurrent
additions or deletions to a security group or distribution list overwriting
any
others, but I can't see that scaling to really large organizational
environments,
let alone the global internet environment. So I'm trying to avoid the sort
of
problems that would result from an organization that just doesn't have any
real
concept of enterprise scalability, let alone global internet scalability,
dominating de facto LDAP standards, as currently looks very likely if LDUP
doesn't get its act together.

Once replication and distribution is standardized, LDAP will become even
more
deeply entrenched in internet infrastructure and more complex applications
with
transactional and synchronization requirements will become more common.

The LCUP drafts look like an excellent basis for handling notifications and
I am
quite confident that client APIs for that will become as widespread as
current
LDAP client APIs are now. Even without standardization, client APIs that
handle
three varieties of Microsoft proprietary asynchronous and "out of band"
synchronization notifications are already included in every copy of the
latest
version of the dominant client OS.

The information stored by MDCR anyway for actually resolving conflicts and
implementing weeding and summarizing robustly, can also be used to simplify
implementation of LCUP and servers can combine it with non-email
notifications for
revocation and confirmation.

In that (future) environment it is much more likely that application
developers
will start dealing with the complexities of restoring application context.
It is
already being done in Distributed File System projects for mobile and
disconnected
environments such as Coda, Intermezzo and Bayou and Lotus Notes has been
doing
something similar for many years.

Directory services WILL need to support this, so failing to provide for it
in
standards being developed now would be a mistake.

Incidentally, the same information stored that supports revocation and
confirmation
notices can also support signed operations per RFC 2649 and will be very
useful in
future support of transactions.