Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

From: "Mark Brown (REDMOND)" <[email-masked]>
Date: Fri, 16 Feb 2001 13:43:11 -0800

<rm> ...
  ... A standard mechanism for directory replication in a
  multi-vendor environment is critical to the continued
  success of LDAP in the market place. This document sets
  out the requirements for replication between multiple
  standard-conformant LDAP servers. ...
  ^^^^^^^^^^^^^^^^^^^ <- new text
  ... </rm>

An LDAP server that implements semantics not
mentioned in the LDAP RFCs does not thereby
become non-standard-conformant.

For instance, most LDAP servers today implement an
access control scheme. No access control scheme
is mentioned in the LDAP RFCs. Yet LDAP servers
that implement access control are conformant with
the LDAP standard.

Similarly, a server that implements internal
triggers for the purpose of maintaining certain
invariants in the directory can conform with
the LDAP standard.

LDUP is designed to solve the problem of replicating
the representations of directories. But the
correspondence between these representations and the
LDAP protocol is not a simple one in general -- it is
only simple for directories that are completely passive
stores. When LDUP is used to replicate (the representations
of) non-passive stores, it is up to the developers of those
stores, not LDUP, to define how to achieve
interoperability. (Most likely, they'll do this pairwise.)

Readers of the requirements draft, even with your
proposed amendment, are likely to think that LDUP
is meant to provide interoperability between directories
rather than between their representations. They are
likely to blame LDAP directory implementors for not
providing the same degree of interoperability as, say,
DNS server implementors do.

As Kurt says down at the start of this thread, that's not
LDUP's job. It is worth adding a paragraph to the draft
so that it says so clearly.

--mark

-----Original Message-----
From: Ryan Moats [mailto:[email-masked]]
Sent: Friday, February 16, 2001 12:40 PM
To: Mark Brown (REDMOND); Richard V Huber; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

See <rm>...</rm> below... Ryan

-----Original Message-----
From: Mark Brown (REDMOND) [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 8:38 PM
To: Richard V Huber; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

So sorry -- I missed those changes when the -06 version came out.

Shortening my suggested addition seems like a good idea.

<rm>Good</rm>

But the intent of my suggestion was to set a clear requirement for
LDUP's ability to provide interoperability. That way, as other LDUP
drafts progress, we'll be able to tell if they are meeting the goal
set in the requirements.

<rm>I personally am willing to do the following text adjustment,
(the other authors still get to comment)...

  ... A standard mechanism for directory replication in a
  multi-vendor environment is critical to the continued
  success of LDAP in the market place. This document sets
  out the requirements for replication between multiple
  standard-conformant LDAP servers. ...
  ^^^^^^^^^^^^^^^^^^^ <- new text

Beyond this, I disagree that LDUP requirements need to be stated
to cover items that don't have an LDAP standard yet.  Any new LDAP
standard should cover the impact of replication on that standard,
not the other way around.</rm>

Since we are doing this work in the IETF, interoperability should be
one of the primary concerns of the work.

But the proposed text

:   Interoperability of replicas between directory servers may be
limited
:   by servers that implement semantics that go beyond what the LDAP
:   access protocol defines.  Examples (not an exhaustive list) of such
:   semantics include: (1) replication among directory servers with
:   different access control systems/semantics may compromise directory
:   security, and (2) replication among directory servers with different
:   application trigger semantics may compromise directory data
:   integrity.

does not set a clear requirement for LDUP's ability to provide
interoperability. It says that when we are done designing LDUP, it is
OK that certain directory servers will not be able to replicate. It
does not say that for the LDUP design to be considered a viable IETF
standard, it is necessary that there is some pair of directory
servers (not from the same code base) that LDUP enables to replicate.

Of course, we don't want to state such a goal in terms like "LDUP will
enable OpenLDAP and the Siemens DS to replicate," we want to state the
goal in terms of the functional characteristics of a pair of systems
that
are able to replicate. That's what my suggested text tried to do.

How about this:

: The goal of LDUP is to support replication between directory servers
: that each implements a passive store fully described by its LDAP
interface.
: "Passive store" means that the servers are limited to storing entries
that
: come in via LDAP and retrieving those identical entries later in
response
: to LDAP requests. The entire semantics of such a store is defined by
its
: LDAP interface. Any restrictions on what the server can store must be
: expressed in the server's schema, and any restrictions on the access
that
: clients have to the store must be expressed in terms of a standardized
: LDAP access control scheme.
:
: LDUP is not required to support replication between directory
: servers that each implements an active store extending LDAP
: semantics with non-standard access control rules or with triggers.
: Examples of triggers include password length/complexity policies and
: automatic storage of secure password hashes instead of passwords.

--mark

-----Original Message-----
From: Richard V Huber [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 12:52 PM
To: [email-masked]; [email-masked]; Mark Brown (REDMOND)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

We addressed these issues in version -06, though we cut down the text.

Here is the summary that was included when I sent version -06 to the
list.  I haven't seen any comments on it since it was posted.

: Internet Drafts Editor -
: 
: Please publish the draft below as draft-ietf-ldup-replica-req-06.txt
: It replaces the -05 draft from November.
: 
: LDUP Mailing list -
: 
: The attached version of the draft incorporates changes to address the
: comments from San Diego.  We trimmed Mark's proposed changes since we
: were concerned that they went into too much detail that wasn't really
: LDUP related.
: 
: Our specific changes are:
: 
: Insert the following as the last paragraph in Section 3:
: 
:   Interoperability of replicas between directory servers may be
limited
:   by servers that implement semantics that go beyond what the LDAP
:   access protocol defines.  Examples (not an exhaustive list) of such
:   semantics include: (1) replication among directory servers with
:   different access control systems/semantics may compromise directory
:   security, and (2) replication among directory servers with different
:   application trigger semantics may compromise directory data
:   integrity.
: 
: Add the following at the end of the Security Considerations Section:
: 
:   As noted in Section 3, security may be impacted when replicating
:   among servers that implement non-standard extensions to basic LDAP
:   semantics.  Access control is one common case which affects
security;
:   work to address this issue is documented in RFC 2820 [RFC2820].
: 
: Add the new reference to the References:
: 
:   [RFC2820]  E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access
:   Control Requirements for LDAP", RFC 2820, May 2000.
: 
: Change the draft number and the publication and expiration dates.
: 
: As always, please send comments to the list.

Rick Huber

--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
: Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D
: Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ
: From: "Mark Brown (REDMOND)" <[email-masked]>
: To: "John Strassner" <[email-masked]>, <[email-masked]>
: Cc: "Chris Apple" <[email-masked]>,
:         =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
: Sender: [email-masked]
: 
: The LDAPv3 Directory Replication Requirements I-D document does
: not address the interoperability limits issue that we discussed
: in December-January.
: 
: I append the most recent message on the topic.
: 
: --mark
: 
: -----Original Message-----
: From: Mark Brown (REDMOND)
: Sent: Thursday, January 11, 2001 7:41 PM
: To: Ellen Stokes; Kurt D. Zeilenga
: Cc: [email-masked]
: Subject: RE: interoperability limits: proposed addition to
: draft-ietf-ldup-replica-req-05.txt
: 
: Oops, I left off the examples. Let's try again:
: 
: I suggest inserting the following material right after
: the first paragraph of Section 3 ("The Models") of the
: requirements draft (just before the sentence "There are five
: data consistency models.")
: 
: --mark
: 
: * * * * *
: 
: The objective is limited to replication between directory servers
: that implement a passive store fully described by its LDAP
: interface. "Passive store" means that the servers are limited to
: storing entries that come in via LDAP and retrieving those entries
: later in response to LDAP requests. The entire semantics of
: the passive store is defined by its LDAP interface. Any
: restrictions on what the server can store must be
: expressed in the server's schema, and any restrictions on the
: access that clients have to the store must be expressed in terms
: of a standardized LDAP access control scheme. This is in
: contrast to an "active store" that implements triggers
: or other rules that extend the semantics of entries beyond
: what's implied by LDAP. Replication between such active
: stores should be specified in extensions to LDUP.
: 
: Here are some examples of ways in which directory servers
: implement semantics that go beyond what the LDAP access
: protocol defines:
: 
: * Access control. LDAP does not currently define an access
:   control scheme. (The ldapext WG is working to extend LDAP
:   with an access control scheme.) Most directory servers
:   implement an access control scheme.
: 
:   Replication between directory servers with different
:   access control schemes would compromise directory security,
:   so such replication is not supported by LDUP.
: 
: * Password policy. Some directory servers restrict changes
:   to password attributes, requiring that the new password
:   value conform to a specific security policy (e.g. the value
:   is sufficiently long and complex.) Doing so reduces the
:   security risk associated with passwords that are easy to
:   attack.
: 
:   Replication between directory servers with different
:   password policies (e.g. one server implements a password
:   policy and a second server implements no policy) would
:   compromise directory security, so such replication is not
:   supported by LDUP.
: 
: * Password hashing. Some directory servers don't store a user's
:   password directly, but instead store one or more secure
:   hashes of the password. Doing so makes it less likely that
:   anyone (even an administrator) can discover the password.
: 
:   Replication between a directory server that stores passwords
:   and a directory server that stores only hashes will compromise
:   directory integrity, causing authentications to fail
:   unexpectedly, so such replication is not supported by LDUP.
: 
: * * * * *
: 
: -----Original Message-----
: From: Mark Brown (REDMOND) 
: Sent: Thursday, January 11, 2001 3:10 PM
: To: Ellen Stokes; 'Kurt D. Zeilenga'
: Cc: [email-masked]
: Subject: RE: interoperability limits: proposed addition to
: draft-ietf-ldup-replica-req-05.txt
: 
: 
: We appear to be in total agreement.
: 
: So I suggest inserting the following paragraph right after
: the first paragraph of Section 3 ("The Models") of the
: requirements draft (just before the sentence "There are five
: data consistency models.")
: 
: --mark
: 
: * * * * *
: 
: The objective is limited to replication between directory servers
: that implement a passive store fully described by its LDAP
: interface. "Passive store" means that the servers are limited to
: storing entries that come in via LDAP and retrieving those entries
: later in response to LDAP requests. The entire semantics of
: the passive store is defined by its LDAP interface. Any
: restrictions on what the server can store must be
: expressed in the server's schema, and any restrictions on the
: access that clients have to the store must be expressed in terms
: of a standardized LDAP access control scheme. This is in
: contrast to an "active store" that implements triggers
: or other rules that extend the semantics of entries beyond
: what's implied by LDAP. Replication between such active
: stores should be specified in extensions to LDUP.
: 
: * * * * *
: 
: --mark
: 
: -----Original Message-----
: From: Kurt D. Zeilenga [mailto:[email-masked]]
: Sent: Tuesday, January 09, 2001 4:54 PM
: To: Mark Brown (REDMOND)
: Cc: Ellen Stokes; [email-masked]
: Subject: RE: interoperability limits: proposed addition to
: draft-ietf-ldup-replica-req-05.txt
: 
: 
: Mark,
: 
: Replication in the face of triggers or any other LDAP extension
: should be specified in extensions to the LDUP.
: 
: LDUP should assume 'passive' servers as this, I believe, is the
: LDAP/X.500 data model.  That is, servers should not muck with
: user data.
: 
: Kurt

---

From: "Ryan Moats" <[email-masked]>
Date: Fri, 16 Feb 2001 19:57:24 -0600

John, Chris, do you have a sense of the working group from
the list messages?  I've not seen enough reaction to see
whether we've got rough consensus one way or another, and
I'm worried that this discussion threatens to become a
rat-hole.

See <rm^2>...</rm^2> below...  Ryan

-----Original Message-----
From: Mark Brown (REDMOND) [mailto:[email-masked]]
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

  <rm> ...

<rm>Never said it didn't</rm>

<rm^2>In the absence of an LDAP standard for access
control, you can't have interoperability of access
control in the IETF sense.  However, I am not willing
to delay this document for something that is the
responsibility of another working group.  The proper
IETF procedure (as I understand it) is for this document
to go forward and it become the responsibility of
the access control draft authors to include the replication
implications of the new standard.  That avoids
a "boil the ocean" conundrum preventing progress.</rm^2>

<rm^2>Again, in the absence of an LDAP standard for internal
triggers you can't have IETF interoperability to
replicate that information with LDUP. If you want 
interoperability in replicating internal triggers,
the proper process is to develop an RFC and address
the issues there.</rm^2>

<rm^2>I claim we've addressed the issue already in -06
and with the suggested text above. Therefore, at
this point, I think I'd like to ask the chairs to get a
sense of the mailing list to see if we have rough-consensus,
because I can see argument turning into a rat-hole.</rm^2>

--mark

-----Original Message-----
From: Ryan Moats [mailto:[email-masked]]
Sent: Friday, February 16, 2001 12:40 PM
To: Mark Brown (REDMOND); Richard V Huber; [email-masked];
[email-masked]

-----Original Message-----
From: Mark Brown (REDMOND) [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 8:38 PM
To: Richard V Huber; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

<rm>Good</rm>

But the proposed text

How about this:

--mark

-----Original Message-----
From: Richard V Huber [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 12:52 PM
To: [email-masked]; [email-masked]; Mark Brown (REDMOND)
Cc: [email-masked]; [email-masked]; [email-masked];

Rick Huber

---

From: "Albert Langer" <[email-masked]>
Date: Sat, 17 Feb 2001 16:39:38 +1100

[Ryan]

[...]

[Albert]
There is an overlap between the authors of the requirements draft and the
authors of LDAP access control requirements and other drafts but a radical
inconsistency between currently proposed access control schemes that rely on
atomicity and the lack of understanding of atomicity issues in LDUP.

The actual wording of the LDUP requirements does now require both atomicity
and eventual convergence and is certainly a vast improvement on previous
drafts, although it proposes that sysadmins should "boil the ocean" by
resolving resulting problems manually.

Unfortunately neither the wording nor that implication appears to be based
on the actual understanding of members of the WG, as reflected in the
current drafts for implementation, the minutes of WG meetings at IETF and
non-normative explanatory notes in the draft.

Chris has apparantly decided not to comment on the access control issue
after first indicating that he would do so and being reminded of that.

There may well be a "rough consensus" for proceeding on this basis, but I am
certainly not part of it.

As my views are already on the record I won't waste time repeating them here
unless somebody else expresses interest.

Put succinctly: LDUP directories won't interoperate. Period.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Feb 2001 07:55:08 -0800

>Put succinctly: LDUP directories won't interoperate. Period.

I would say that two LDUP peers could interoperate (from
a protocol perspective) but that this, in itself, does
not:
        1) preserve LDAP/X.500 semantics nor
        2) provide "equally capable" replicas.

The former issue can not be resolved unless one requires
transactional consistency in multiple master replication.
The latter issue can be tackled by writing a very tight
applicability statements.

Kurt

---

From: "Ryan Moats" <[email-masked]>
Date: Sat, 17 Feb 2001 10:08:07 -0600

Ok, since <rm^2> is quoted, I'll use <rm3>...</rm3> this time... Ryan

-----Original Message-----
From: Albert Langer [mailto:[email-masked]]
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

[Ryan]

[...]

[Albert]

<rm3>I'll admit I don't understand the technical point of this comment.
</rm3>

...

<rm3> Uh, it must support the propagation of atomicity information,
that's different than requiring atomicity, imho.</rm^3>

...and eventual convergence and is certainly a vast improvement on previous
drafts, although it proposes that sysadmins should
"boil the ocean" by resolving resulting problems manually.

<rm3>I disagree.  What it requires is that if conflict resolution
would result in loss of data, ensure that the sysadmin is notified
and can override if the algorithm is wrong.  That is not unreasonable
given the issues raised in Appendix B.</rm3>

Unfortunately neither the wording nor that implication appears to be based
on the actual understanding of members of the WG, as reflected
in the current drafts for implementation, the minutes of WG meetings
at IETF and non-normative explanatory notes in the draft.

<rm3>Again I don't see the point of this comment.</rm3>

---

From: "Ryan Moats" <[email-masked]>
Date: Sat, 17 Feb 2001 10:16:40 -0600

After some more reflection, I want to add some other comments
to this thread that I hope will help...

See <rm3>...</rm3> below... Ryan

-----Original Message-----
From: Mark Brown (REDMOND) [mailto:[email-masked]]
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

  <rm> ...

<rm3>These two cases are examples of where LDUP won't
replicate the semantics.  My point is that while it
is probably worthwhile to point out this issue in an
LDUP document (and I think I know which one should
handle it), I don't think its right to point it out
in *this* document.

As to active versus passive, I can (as a gedanken experiment)
postulate a system that uses application triggers for
some purpose and whose information, including that used in
the triggers could be replicated via LDUP in a 
single-master environment. While this is a convoluted case,
I think it does point out that making the "passive" comment
is too restrictive.</rm3>

--mark

-----Original Message-----
From: Ryan Moats [mailto:[email-masked]]
Sent: Friday, February 16, 2001 12:40 PM
To: Mark Brown (REDMOND); Richard V Huber; [email-masked];
[email-masked]

-----Original Message-----
From: Mark Brown (REDMOND) [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 8:38 PM
To: Richard V Huber; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

<rm>Good</rm>

But the proposed text

How about this:

--mark

-----Original Message-----
From: Richard V Huber [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 12:52 PM
To: [email-masked]; [email-masked]; Mark Brown (REDMOND)
Cc: [email-masked]; [email-masked]; [email-masked];

Rick Huber

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Feb 2001 09:13:05 -0800

At 04:39 PM 2/17/01 +1100, Ryan Moats wrote:
><rm^2>However, I am not willing
>implications of the new standard.</rm^2>

I disagree.  I assert that LDAP ACM replication issues are
NOT within scope of LDAPext WG and are properly addressed
within documents produced by the LDUP WG.

Kurt

---

From: "Albert Langer" <[email-masked]>
Date: Sun, 18 Feb 2001 07:30:51 +1100

[Kurt]

[Albert]
We seem to be agreed that "LDUP directories won't interoperate"
(unless of course you mean that an LDUP directory need not preserve LDAP
semantics - which seems implausible ;-)

If by "transactional" consistency you are referring to updates affecting
more than one directory entry, that is not part of LDAP semantics.

If you mean "atomic operations", that is part of LDAP semantics and I
certainly agree that the issue cannot be resolved without it ;-)

A necessary consequence of multi-master, as opposed to single master,
is that in addition to transient inconsitencies between data read from
different directory servers there will also be problems with data read
from a single server. There are 2 options possible for multi-master:

1) Conflicting updates to the same entry are prioritized so that only
one succeeds and the others are rolled back. That necessarily results
in different behaviour to single master directories but is not
fundamentally inconsistent with LDAP semantics and does not prevent
interoperability. Problems arising can be resolved by users rather than
sysadmins by notifying them of lost updates (whether due to name conflicts
or
other conflicts). An applicability statement should clearly indicate
that multi-master is unsuitable in any situation with a high rate of
concurrent changes to the same entries.

2) Changes are not "rolled back" so, by definition, atomicity is not
preserved when updates conflict. This necessarily results in both transient
and permanent loss of data integrity. In particular it breaks
currently proposed access control mechanisms. I mention it as an
"option" only because it is the current architecture, not because it
has any technical merit whatever. An "inapplicability statement" should
then clearly indicate that multi-master is unsuitable in any situation that
requires data integrity. Since interoperable directories require high
integrity access control mechanisms that means it is simply "not
applicable".

---

From: "Albert Langer" <[email-masked]>
Date: Sun, 18 Feb 2001 07:33:41 +1100

[Albert]

[Albert]
Try plugging examples similar to those discussed in Appendix B using access
control attributes as specified in current access control drafts, taking
into account the transient outcomes I quoted from Alison's discussion of
URP consistency model in:

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

BTW That message is actually Chris's reply, disrupting an attempt to discuss
this issue and other issues with Rick, from which I hope you will understand
why I am not currently inclined to pursue the issue in this forum. I believe
Chris should respond as he said he would, instead of just forgetting about
it after delivering himself of that tirade.

[Albert]

[Albert]
Ok, "support the propagation of atomicity information" is different from
requiring atomicity. The difference is essentially that the protocols are
required to maintain all the information necessary to notify admins about
problems but are not required to fix the problems. That is what I meant by
"it proposes that sysadmins should 'boil the ocean' by resolving resulting
problems manually".

I still regard it as a vast improvement on the previous because it clearly
rules out the current architecture and URP, which is not capable of
maintaining
the information needed to notify admins as required.

I disagree with the analysis in appendix B, but it is explicitly stated to
be
not part of the actual requirements.

Once an architecture is adopted that *is* capable of meeting the
requirements
mandated for notification to sysadmins, I believe it will become obvious
that it makes more sense to actually fix the problems by rollbacks and
notifications
to users.

[Albert]

[Albert]
The minutes show that the same meeting which agreed the requirements draft
was ready for final call also agreed that the URP was ready for final call
despite the fact that it is incapable of meeting the requirements as stated.
The "non-normative explanatory notes" I was referring to are mainly the
Appendix B you mention. In addition the current drafts do not meet the
requirement for eventual convergence (although they are capable of being
fixed to do so, unlike their fundamental inability to propagate atomicity
information needed for notification requirements).

Although the plain words of the document unambiguously rule out URP, I am
not under any illusion that this reflects a consensus of the WG to do so.
Consequently I do not believe adoption of the requirements will in fact
resolve the most important requirements issues and am therefore not part of
any consensus to adopt them - although I will certainly elaborate on the
requirements not met by URP when that comes up.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Feb 2001 13:47:35 -0800

>more than one directory entry, that is not part of LDAP semantics.

I am using the term "transactional consistency", I hope, as
defined by LDUP requirements I-D.   X.500 and LDAP state that
all modifications requested as part of a single modify happen
as a single atomic action.  Using this feature, applications can
(and do) build mutually exclusive locks, semaphores, monotonically
increasing counters, and other structures used for application
synchronization purposes.  This feature is preserved by X.500
data model as it supports only single master replication.

It is not possible to build these structures in multiple
master environments without "transactional consistency". 

>An applicability statement should clearly indicate

Change "high" to "any" and I would concur.

Kurt

---

From: "Albert Langer" <[email-masked]>
Date: Sun, 18 Feb 2001 10:59:15 +1100

[Kurt]

[Albert]
Since X.500 and LDAP refer to a "single atomic action" I prefer to use the
term
"atomic" for this issue because reference to "transactions" is easily
confused with
updates affecting multiple entries rather than just modifications to
multiple
attributes of a single entry, which is the only guarantee provided by X.500
and
LDAP and is deliberately much weaker than a DBMS style requirement to
maintain
consistency for updates to different entries.

Leaving aside terminology, we seem to be broadly in agreement.

However the way you have put it sounds like you are opposed to LDUP
developing
multi-master standards at all, since it is technically impossible to
maintain
such things as monotonically increasing counters for application
synchronization.
Is that the case?

If so, could you please elaborate on applications that depend on such
features.

My view is that the critically important requirement that applications
depend on
is simply that a change can be reliably made to exactly the entry you
thought you
were changing and not result in some mixture of updates combined with
unknown
concurrent changes by some other application.

That is essential for basic data integrity and easily achieved by the
provisions
regarding modify operations in the LDAP standards. The whole point of those
provisions is that by explicitly asserting that all relevant attributes have
particular values at the start of a modify and particular values at the end,
you are guaranteed that the operation will fail if that turns out not to be
the case due to some other change between when you read an entry and when
you modified it, rather than ending up with randomly garbled entries.

Although it is possible to use that mechanism for such things as
(cooperative)
locking, semaphores and counters, that is not it's intended use and I agree
with
the requirements draft characterization of applications doing that as making
inappropriate use of the directory.

What I disagree with in Appendix B is the confusion of such inappropriate
use with the perfectly
normal use of the carefully designed characteristics of "modify" atomicity
to
ensure data integrity. That normal use can be achieved with multi-master (at
the cost of
notifications about operations failing after intially appearing to have
succeeded). The
statement that rolling back a change to one attribute of a single entry
would cause "more
surprise" than letting two separate users/applications mixup changes to the
same data
without knowing what the results of their combined activity would be, shows
a quite
breathtaking incomprehension of very basic data integrity issues.

It seems to me that multi-master does have important operational benefits
that would
justify deployment so long as basic data integrity is not compromised.

Are you saying it should not be deployed at all?

[Kurt]

[Albert]
That does seem to be saying multi-master should not be deployed at all,
since by definition
of multi-master, DSAs do not contact each other before performing updates
and therefore
the *possibility* of concurrent changes *cannot* be excluded.

That breaks any application relying on semaphores etc. But rollbacks are
quite sufficient for applications that merely require data integrity (such
as access control).

Surely a directory service that guarantees that only changes actually made
by DUAs will ever be visible could be useful even though occasional
notifications about changes that have been revoked would be necessary? After
all, even in a single master situation a change made can be subsequently
unmade by another DUA and there is no mechanism for *enforcing* cooperative
use of semaphores, counters etc, so no properly designed application could
depend on no other
DUA interfering.

If you have specific applications in mind that do depend on single master
semantics, please list them.

Discussion of such issues is what requirements analysis should be about.

For my part, I think it is sufficient to just list access control as an
example of a directory application that requires a level of data integrity
that simply cannot be met without atomicity.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Feb 2001 23:01:15 -0800

>such things as monotonically increasing counters for application

Though I have voiced in the past an opinion that I felt this
work on multiple-master replication was more suitable for
the Experimental track, I do not object to this WG attempting
to produce Standard Track protocol.  That's what they were
chartered to do.

I raised the point only because the requirement document
dismisses Model 1 "Transactional Consistency" without noting
the consequences of this choice.  I wouldn't mind seeing
more discussion of these consequences.  However, as this
discussion would likely not alter the actual requirements,
it's not a critical issue.

>If so, could you please elaborate on applications that depend on such

Provisioning of services.

>locking, semaphores and counters, that is not it's intended use

I cannot argue wether it was an intended use or not.  I wasn't
there.  However, this use is common.  I've even seen this use
in LDAP/X.500 educational materials and numerous real world
applications (namely custom provision solutions).

>and I agree

I do not concur with this characterization nor a good deal of the
rational behind it.  However, I don't think changing it would have
a significant impact on the stated requirements (as I believe the
consensus of the WG is not to provide Model 1, "transactional
consistency").

>Are you saying it should not be deployed at all?

No.  I'm saying I don't believe LDUP multiple master replication as
maintaining full LDAP semantics.

---

From: "Ryan Moats" <[email-masked]>
Date: Sun, 18 Feb 2001 08:15:50 -0600

Hmm, I see something in here that really bothers me, I'm going
to use <rm>...</rm> since this is my first comment on this part
of the thread... Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

<rm>Whoa!  This is something I'm not unfamiliar with and I claim that
it can be done without relying on things like implementing locks or 
semaphores in the directory that won't replicate, thus I can't support
the idea that provisioning of services "depend" on such features</rm>.

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 19 Feb 2001 02:24:26 +1100

[Kurt]

[Albert]
Ok, well as I agree with the consensus on this and you seem to be
resigned to it, I won't attempt to convince you that it's correct.

Let's just take it as a given, the requirements we are discussing, for good
or ill
are not attempting to support model 1, but model 2 (X.500/LDAP).

[Kurt]

[Albert]
Well, provisioning of services is almost as relevant to general LDAP
user requirements as access controls. So I would like to discuss what
is needed to support it, given that model 1 transactions and cooperative,
locking, semaphores and counters will not be available with multi-master.

BTW I'd also be interested in any URLs you could provide on the educational
materials
and real world applications including custom provision solutions, whether or
not
they require single master semantics - both for this discussion or if you
consider
them irrelevant to it, then by direct email.

As it happens I've been working on a project in precisely this area. My
conclusions
have been as folows:

1. Service provisioning needs various forms of strict transactional support,
including mandatory (not just cooperative) locking as well as semaphores and
counters,
that simply cannot by provided by even a single master distributed directory
as
distribution of subtrees among different servers results in synchronization
becoming
unscalable. It also has requirements for updates that are written almost as
often
as they are read, while processing changes. Therefore it requires the use of
full DBMS
facilities.

2. Service provisioning also needs a lot of information that is relatively
static but
must be efficiently available for frequent lookups by the provisioned
services and
also needs to be searchable by their users and administrators. This aspect
is ideally suited
to directories. It can be and I suspect usually is, handled by single master
directories
with failover.

3. Service provisioning also needs multi-master replication. This is both to
support a more
robust and scalable form of failover than is possible with single master
and, less importantly,
for the normal reasons of enabling immediate availability of local changes.
DBMS replication
is far too complex and expensive but the full semantics of DBMS replication
are not needed
to meet the service provisioning requirements for multi-master replication.

The result is that the data and operations have to be partitioned, rendering
unto the DBMS
that which belongs to the DBMS and rendering unto the Directory, that which
belongs to the
Directory. (There is also an important role for DNS as much of the static
data is just
"lookup only" and does not need to be searchable).

Unfortunately actually available multi-master directory services do not fit
the directory
requirements well - eg Active Directory replicates each attribute
independently instead of
complying with the LDAP/X.500 standards requiring that granularity of a
directory is at the
level of individual entries, not individual attributes. As a result it has
to maintain
ACI information in a single attribute that cannot have independent changes
to separate
attribute values and similar encoding work arounds are necessary for other
aspects. Nevertheless,
I believe it *can* be worked around whereas if it had adopted the
granularity of an individual
attribute value, like URP, it would be completely useless.

I do not believe it will be possible to eliminate the requirements for
DBMSes in service provisioning applications (after having tried long and
hard to find a way to do so). But it
would certainly be possible to provide multi-master directory support far
superior to Borg
technology, which naturally enough is based on the usual Borg assumptions
about a hierarchically
administered hive rather than the emerging reality of interweaved federated
webs of use,
administration and service provision.

[Kurt]

[Albert]
Ok, I think I understand your position now. But surely just because you
can't have
model 1 from multi-master that doesn't mean you can't have model 2 which is
explicitly defined as the LDAP/X.500 model. That model does not support
transactions,
because it can't in a globally scalable distributed directory. But it does
support
atomic operations so that "what you changed is what you saw", as well as
supporting
"eventual convergence".

It is logically impossible to support semaphores and counters with
multi-master,
but quite feasible to support the semantics of LDAP modify operations as you
described them. Surely that is a goal that should be required (and indeed
must be
required for a standard claiming to be consistent with LDAP).

"All or nothing" is seldom a useful attitude.

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 19 Feb 2001 02:34:23 +1100

[Albert]

[Kurt]

[Ryan]

[Albert]
Just a note to clarify my message that crossed with this.

I agree with Kurt that service provisioning does need locks and semaphores -
as
with any other resource allocation problem. In particular if a service is
being
paid for it can't be supplied until the payment is authorized and the
payment
cannot be captured unless the service provision has been successfully
fulfilled.
That involves ye olde transactions.

I also agree with Ryan that it "can be done wihtout relying on things like
implementing locks and semaphores in the directory". That is because those
aspects should be done outside the directory in a DBMS that is specifically
designed for that sort of thing.

Other aspects of service provisioning should be done in the directory, but
not the transactional aspects.

Of course if a directory doesn't support "what you changed is what you saw"
data integrity then it can't support reliable access controls and is
therefore
useless for service provisioning, or anything else for that matter.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 18 Feb 2001 08:55:24 -0800

>the idea that provisioning of services "depend" on such features</rm>.

Obviously you can rely on some form of external synchronization
to implement these services.  In that one can always use external
synchronization, no application "depends" on the well defined
semantics of LDAP/X.500 operations for synchronization purposes.

The fact is that there are numerous applications using these
semantics to provide synchronization between clients.  There is
also sufficient demand for multiple-master replication with
less than "transactional consistency (model 1)".  My point is
that folks should realize that they cannot have both.  I think
you and most folks in the LDUP community realize this.  My
point is I'd like to make it more clear to those reading LDUP
specifications that LDUP does not support applications relying
on synchronization structures built using atomic semantics of
LDAP operations.  Specifically, I suggest a brief note in a
"Background and Intended Use" section within the TS.

Same applies to extensions providing "LDAP Transactions," but
here the extension can note the limitation.

I don't it necessary for the Requirements I-D to require this
explicitly.

Kurt

---

From: John Strassner <[email-masked]>
Date: Mon, 19 Feb 2001 10:26:44 -0800

Please see comments inline, delineated by <js>..</js>.

regards,
John

At 07:30 AM 2/18/2001 +1100, Albert Langer wrote:
>or other conflicts).

<js>
Albert, the wg looked at this option and rejected it. We thought that it 
would be a Bad Thing to have different behavior in the multi-master system 
compared to the single-master system. While it may not be inconsistent with 
LDAP semantics, it is inconsistent with what the user would expect. This 
has been clearly documented in both the minutes and presentations of past 
meetings. Why are you bringing it up again?
</js>

>concurrent changes to the same entries.

<js>
Again, the wg doesn't concur. Plus, I'm confused why you would make this 
statement, as you positioned your proposal as solving these problems.

We have figured out that you don't agree with the design. ;-) The bottom 
line is that as chair, I need positive comments detailing how to fix a 
problem. We've had enough complaints through these threads, so I'm asking 
you to please contain your commentary to clear, explicit corrective action. 
</js>

>and permanent loss of data integrity.

<js>
Not true. First, applications can certainly build locking and other 
mechanisms to isolate operations affecting an update. The requirement I-D 
states that IF data loss could occur, then the sysadmin should be notified. 
This is not the same as just throwing away the update.

Furthermore, I don't see how you are going to "roll back" changes given the 
current LDAP data model. If you'd like to talk to me off-line, I'd be happy 
to discuss this point with you.
</js>

>In particular it breaks

<js>
Statements such as this are not helpful. Please try and comment in a 
positive manner.
</js>

---

From: John Strassner <[email-masked]>
Date: Mon, 19 Feb 2001 18:37:21 -0800

Please see comments inline, delineated by <js>..</js>

regards,
John

>consistency for updates to different entries.

<js>
Being an ex-database person, I tend to agree with Albert here.
</js>

>such things as monotonically increasing counters for application

<js>
Please clarify if you mean that it is technically impossible to build and 
maintain monotonically increasing counters and the like within the 
directory server itself. You've got an argument on your hands if you think 
that it can't be done externally, by the way.
</js>

>concurrent changes by some other application.

<js>
Albert, you presented your way, and it was the consensus of the working 
group that the behavior you proposed was NOT what the user would have 
expected. That is why the working group has adopted the approach it has.

With the chair hat on, I would therefore ask you to stop bringing this up. 
If you have an explicit suggestion that would make our current approach 
better in some way, please say it. But simply stating that it won't work, 
or talking about your alternative, are not helping the working group make 
progress. Please stop.
</js>

>you modified it, rather than ending up with randomly garbled entries.

<js> same comment as above, this doesn't help </js>

>ensure data integrity.

<js>
Sorry, but I don't understand your point. Could you please restate it?
</js>

>That normal use can be achieved with multi-master (at
>the cost of
>succeeded).

<js>
So, how do you propose to handle this? There is no standard notification 
mechanism, though there are a lot of conflicting vendor-specific mechanisms 
that **might** be able to be used for this purpose. Remember, please answer 
assuming the current approach of the WG, or please don't answer.
</js>

>The

<js>
First, that's insulting. You'll probably convince people in the working 
group to listen to you if you don't call them stupid.

Second, your refusal to acknowledge that your approach was rejected is not 
productive. Especially when you make outrageous statements like the above 
with no backup whatsoever. Note that the working group discussed your 
contrary proposal, and rejected it. It discussed the current proposal and 
accepted it.
</js>

>Change "high" to "any" and I would concur.

<js>
Kurt, I don't follow you here. Any could be interpreted as once per day or 
week. I don't think that that's what you meant. Could you please elaborate 
on what you meant by "any"?
</js>

---

From: "Albert Langer" <[email-masked]>
Date: Thu, 1 Mar 2001 12:24:08 +1100

[Albert]
I do not believe it would be useful for me to respond to the large number
of questions and comments that John specifically directed to me recently.
I am responding below to only 1 of them, but I will respond to the rest if
John
insists, as he is a WG co-chair. I do have a clear explicit recommendation
for
corrective action to fix a problem, which follows the chronological
documentation of the problem.

<js>

[Albert 20 June 2000]
(discussing MDCR conflict resolution tree with Ryan 8 months ago and
referring to the original requirements draft)

I don't see a large tree as an implementation problem in itself - the
overhead is only about 12 bytes of RAM per conflicting change.

However a large tree would indicate an inappropriate use of multi-master
replication in situations where conflicting changes are common relative to
the replication interval. The directory model of loose consistency is
intended only for situations with a high ratio of reads to writes and
therefore a low proportion of conflicts relative to the replication
interval.

This is completely obscured in the requirements draft which treats
multi-master as solving all sorts of problems it has no relevance to
whatever, while ignoring its primary importance for enabling local
availability of changeable entries and not explaining that conflicting
changes to the same entry are an unavoidable consequence of that rather than
a useful feature.

Entries should be re-structured as families of entries for different sets of
attributes or attribute values where local availability of changes is
required with a ratio of conflicting changes high relative to the
replication interval (eg for maintaining distribution lists).

If that is not possible, multi-master replication should not be used at all.
(Or equivalently, a "primary replica" used for writes).

If a high rate of conflicts and therefore large trees is due to coordinated
transactions, these should use a database designed for that rather than a
directory. They will not work well when "sporadically-connected" however one
does it.

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).

============================================================================
Eight months later
============================================================================

[Albert 18 Feb 2001]

[John 20 Feb]

[Ed 21 Feb]
I certainly agree that we should make clear (if we have not
already), that multi-master is unsuitable in any situation with a
high rate (say, frequently faster than the time it takes for a change
to fully propagate to all registered replicas) of concurrent changes
to the same entries at different master replicas.

The "frequently..." qualifier represents my own bias as to what
is "reasonable" and might be changed to simply say "faster than...

[John 21 Feb]
This seems reasonable, but I would suggest that we quantify this, perhaps
in terms relative to the (average) replication frequency of the system.
Thoughts?

[Paul 21 Feb]
Very roughly, if there are N replicas, and each can tolerate an update
rate (if it were the only replica) of R, then the total update rate
supportable by the replicated directory would be R/N.

I do not believe that the replication frequency has much to do with it,
unless a low-ish frequency causes many updates to be transferred per
replication interval and thereby leads to increased efficiency (due to
some batching effect or other).

[Rick 21 Feb]
John, I really don't think the requirements document is the place to
quantify
this.  If the list really thinks we need to quantify it, let's do it in the
profile document (though it probably won't make the -00 draft which needs to
get in by Friday).

As for Albert's/Ed's original point, I agree.  The requirements already note
in
B.5.5 that  having multiple users/applications changing the same data at the
same time is a way to get into trouble.  I suppose we could change "at the
same
time" to "before previous changes have replicated" if that makes it clearer.

[John 25 Feb]
This memo is written as a summarization by the WG Co-Chair of declaring
consensus on discussed items and requesting changes to be made to the
current (-06) version of the requirements I-D prior to it being reissued
for WG Last Call.

[...]

Sub-issue 6: noting unsuitability of LDUP for environments with "high rate
of change"

While everyone agrees with this, no one could come up with a reasonable
definition of "high rate of change". However, there is consensus that this
should not be specified in the requirements draft, but rather in other
drafts (architecture and profile are obvious candidates). A suggestion was
to change in section B.5.5 from "They are changing the data at the same
time" to "They are changing the data before previous changes have
replicated".

Action: change in section B.5.5 from "They are changing the data at the
same time" to "They are changing the data before previous changes have
replicated".

=======================================================================

[Albert]
The problem I see is that John believes the WG has reached a conclusion
when he forms an opinion, or even when he is merely "confused", that
everyone has agreed when he has changed his mind, and that no one could
come up with a reasonable answer to a question that has not been asked.

Unlike normal WG technical business I do not believe this problem can
best be resolved through email discussions and I am not calling for such
a discussion now. It is better suited to face to face meetings.

The corrective action I recommend is that during the coming IETF meeting
people try to convince John that the business of an IETF WG is primarily
conducted through the email list and that the only way to find out what
the WG thinks about an issue is to *ask* it by putting that issue to the
list for a decision, not by telling us what we think. If that fails,
find a replacement.

"IETFers are fiercely independent. It's safe to question opinions and
offer alternatives, but don't expect an IETFer to follow orders."

http://www.ietf.org/tao.html