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

From: "Mark Brown (REDMOND)" <[email-masked]>
Date: Tue, 6 Feb 2001 10:19:10 -0800

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: [email-masked] (Richard V Huber)
Date: Tue, 6 Feb 2001 15:52:13 -0500

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: <[email-masked]>
Date: Sat, 17 Feb 2001 15:12:39 -0500

---- Original message ----
>Date: Sat, 17 Feb 2001 09:13:05 -0800
>From: "Kurt D. Zeilenga" <[email-masked]>
>Subject: RE: WG Last Call on the LDAPv3 Directory 
Replication I-D
>To: "'Ryan Moats'" <[email-masked]>
>Cc: <[email-masked]>
>
>At 04:39 PM 2/17/01 +1100, Ryan Moats wrote:
>><rm^2>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.</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

Well, I think LDUP should NOT be responsible for trying to
address the replication issues of a to be standard document
that isn't finished yet in another WG.  That's not the way
things have been handled in the IETF in my experience and I
believe its a real good way to halt progress through
charter creep.  I say this because I fear someone whould
take your argument and publish a -00 I-D draft related to
LDAP, have LDAPEXT (or some other WG) agree that it should
eventually be standard track and then come to LDUP and
say "LDUP must handle replicating this -00 draft".  I don't
believe this is a desireable situation.

Ryan

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 18 Feb 2001 08:10:16 -0800

At 01.13 +1100 01-02-19, Albert Langer wrote:
>[Albert]
>I don't understand this statement. Do you mean:
>
>a) The version dated 10 February 2001 is wrong and will be withdrawn.

That very paragraph talking about liasons in the version of the 
charter will be replaced by a new paragraph. The rest of the charter 
will not be changed.

The new paragraph will read:

>    The work being done in the LDUP WG should be coordinated
>    to the closest extent possible with similar work being
>    done in the ITU. This is necessary both because LDAP
>    depends on X.500 and because it makes sense from an
>    operational perspective.

    paf

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 16 Feb 2001 23:18:03 -0800

You're right -- it isn't the job of LDUP to say how to replicate ACLs.

However, it is appropriate to point out that until such a standard
exists, LDAP conformant directories will not be able to be replicated
via LDUP.

So, one of the requirements for replication between multiple standards
conformant LDAP servers using LDUP is that said servers not implement
anything other than standard LDAP acess to totally passive data.

> From: Ryan Moats [mailto:[email-masked]]
> Sent: Friday, February 16, 2001 5:57 PM
> To: Mark Brown (REDMOND); Ryan Moats; Richard V Huber;
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> 
> 
> 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
> 
> From: Mark Brown (REDMOND) [mailto:[email-masked]]
> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> 
> 
>   <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.
> 
> <rm>Never said it didn't</rm>
> 
> 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.
> 
> <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
> implications of the new standard.  That avoids
> a "boil the ocean" conundrum preventing progress.</rm^2>
> 
> Similarly, a server that implements internal
> triggers for the purpose of maintaining certain
> invariants in the directory can conform with
> the LDAP standard.
> 
> <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>
> 
> 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.
> 
> <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
> 
> 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
> 
> 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
> 
> 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
> 
> 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
> 
>

---

From: "Paul Leach" <[email-masked]>
Date: Mon, 19 Feb 2001 17:50:43 -0800

> From: John Strassner [mailto:[email-masked]]
> Sent: Monday, February 19, 2001 10:27 AM
> To: [email-masked]
> Cc: Kurt D. Zeilenga; [email-masked]
> <js>
> Not true. First, applications can certainly build locking and other 
> mechanisms to isolate operations affecting an update.

Huh? The application instances could be operating on different replicas,
so will never even see the "locking" operations of the other. They will
proceed as if they were isolated, and then their updates will clash
laters. When the attributes being modified overlap partially but not
completely, neither one of them will get a consistent set.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Feb 2001 20:07:19 -0800

>completely, neither one of them will get a consistent set.

Unless the directory was using single master replication or
multiple master with "transactional consistency" (model 1).

Kurt

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 20 Feb 2001 01:53:06 -0800

> Sent: Monday, February 19, 2001 8:07 PM
> To: Paul Leach
> Cc: [email-masked]
[Summary: I asked: How can you do locking in replicated environment?
They won't see the locking operations... ]
> multiple master with "transactional consistency" (model 1).

I agree that it would work with single master -- I thought the context
of the thread was multimaster.

I don't see how even transactional consistency would make locking
operations work with multi-master. Nor do I have any idea how to make
transactional consistency work with multimaster in the face of partially
overlapping write sets, for that matter. (Unless you're prepared to undo
transactions that the clients were told had committed, which I think is
a horrible idea -- programmers will never get it.)

Paul

---

From: "Ed Reed" <[email-masked]>
Date: Tue, 20 Feb 2001 10:23:50 -0700

Ahh - the crux of the matter...

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Albert Langer" <[email-masked]> 02/17/01 04:59PM >>>
[snip]
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.

[eer]

My view is exactly, precisely, and PROFOUNDLY the oposite - that it is critically
important that changes to different attributes made at the "same time" to
the same entry at two different master replicas MUST interleave and both
be preserved.  

That, in fact, the expected (by reasonable application users sharing
information for multiple applications using LDUP replication to facilitate locally
improved performance and availability of directory content for those applications)
behavior is atomic at the attribute level (if, indeed, not at the attribute-value level) 
for each attribute being changed.  This is, of course, the administration 
application of the directory as a distributed nameservice for which vendors
like Microsoft, Novell, and Lotus use directories.

That there is no practical way to utter the request "change
attribute A to have value "alpha" if and only if attribute B has exactly the
value "beta"" using LDAP and X.500 absent locking mechanisms (theoretical
discussions to the contrary being considerably outside the scope of "normal
and customary" usage to be expected of application developers).

That distributed databases of whatever nature which support such things
do so outside the scope of what can reasonably considered "LDAP".  And
that LDUP is not appropriate for preserving such locking semantics, and
is not intended to be.

That when such locking semantics are defined for LDAP, that LDUP may
then consider how or indeed if they can be reliably replicated via some
use of LDUP or some modification of LDUP, but that until such semantics
are defined that it is foolish to attempt to preserve them in LDUP.

That the simple perspective that because it is possible (by standing
on your head and waving a chicken about with precisely the correct
flapping pattern of your legs) to achieve some sort of "test and set"
behavior against a single server, that the ability to continue to 
provide the behavior to a group of distributed, replicated servers
operating without benefit of distributed memory of any sort (and
thus, operating locally autonomously - which IS the desired behavior
to provide continued access and availability to the data that ARE
present for local applications in the face of network outages) should
somehow be a show-stopper represents a fundamental disagreement
over what is desired from a "loose consistency multi-master replication
scheme for directories supporting LDAP".

That there are LOTS of alternative approaches to providing shared
application profile information, ranging from ACAP (which I
would characterize as a network accessible associative
memory service) to a distributed shared memory system intended
to provide cluster-level disk sector semaphores (with or without
write-down mandatory access control prohibitions).  These are
things LDAP and LDUP are not suitable to support.

That if needed to move things forward, to encourage multi-vendor
inter-replication of LDAP directory content, I would gladly advise
developers who attempt to create their own locking or test-and-set
operations to be sure that, as Albert has correctly described "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 they
do so at their own peril when operating against directories supporting
LDUP.

Look, folks - this all would have been easy to provide for fully
atomic operations against multiple-master replicas...just add XA
semantics to LDAP for enforcement among all master (updateable) 
replicas with full two-phase commit support for each required
atomic operation.  Phase one, all masters would verify that
they had no pending operations which are in conflict with
the proposed changes and that they're blocking any new such
requests until the commit or rollback command is received.  Phase
two, commit or rollback after all updateable replicas reply "ready".

But that's NOT WHAT WE SET OUT TO DO.  THAT'S NOT WHAT
ANY OF US WANTED TO IMPOSE.  THAT'S NOT WHY WE'RE
USING LDAP.  

STOP TRYING TO MOVE US THERE!

Albert - as far as I can tell, even Microsoft has moved towards
interleaving attribute changes, away from the entry-level sequence
number scheme that CODA and ADSv1 used.  No, LDUP won't
do that.  I personally don't think it SHOULD do that.  We may
agree to disagree on that point.

Best regards,
Ed

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 20 Feb 2001 10:19:14 -0800

> From: Ed Reed [mailto:[email-masked]]
> Sent: Tuesday, February 20, 2001 9:24 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

I view this as an unfortunate side effect of the ability to
independently change one replica even when others are not accessible,
not as a requirement.

Suppose one app does an atomic update of attributes A, B and C on object
with DN X at replica R1 and another app does an atomic update of X with
attributes B, C, and D. If the result is that B's ultimate value after
all replication ends comes from the first app and C's comes from the
second, I can guarantee you that many programmers will not have
correctly programmed their apps to handle that.
  
> do so at their own peril when operating against directories supporting

I think this should be pointed out.

> two, commit or rollback after all updateable replicas reply "ready".

I would not even call this "multi-master". It does not permit operations
to proceed in the face of a network partition. I.e., there's really only
one master (dynamically selected, perhaps, and distributed), but unless
the master is accessible to a client, no updates can be done by that
client.

> number scheme that CODA and ADSv1 used.

This is not a correct understanding of what we do now nor any future
direction. We have always interleaved attribute changes -- replication
is on an individual attribute basis (not an object basis).

Paul

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 20 Feb 2001 11:29:22 -0800

> Sent: Sunday, February 18, 2001 9:47 PM
> To: Paul Leach
> Cc: Ryan Moats; Mark Brown (REDMOND); Richard V Huber;
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> I disagree on several counts.
> 
> First, if we start singling out particular types of 
> information that can or 
> can not be replicated, where do we stop?

We should describe the general class of information that can not be
replicated, plus some examples, and stop
at the place where enough examples are listed to make the issue clear.

> 
> Second, please stop using the term "passive data" as no one 
> on this list 
> has defined it in an unambiguous and satisfactory manner. It 
> is impossible 
> to consider using LDUP in this fashion until a definition for 
> this term 
> that we can all agree with is offered and agreed to.

I did post such a definition. I had thought that the term was generally
understood.

> 
> Third, what you're basically saying is that we should close 
> up shop until 
> LDAPext has finished a standards-track access control model 
> RFC. I don't 
> agree at all. First of all, RFC 2251, section 3.2, says that 
> "Servers which 
> perform caching or shadowing MUST ensure that they do not violate any 
> access control constraints placed on the data by the 
> originating server."

No, I'm not. I just said we should point out that such a standard has to
be finished, and until it is, otherwise standards compliant LDAP servers
that use ACLs won't be able to interoperably replicate. And that such a
situation is just one example of a general problem -- some of which
won't be able to be solved as easily.

The two general cases that will present issues are
1. Active data. Subcases are virtual attributes and writes with side
effects
2. "Hidden data". By this I mean state the effect the behavior of the
directory, but which is manipulated by 
 by means outside the LDAP standard, and effect LDAP behavior. ACLs
currently fall in this category.

Currently, LDAP directories can do both of these things, and yet be
totally conformant to the LDAP standard.

In every such case, before interoperability can take place, a standard
which maps the effects onto some standard replication interchange format
will have to be put in place.

That means that any two directories that are totally LDAP compliant and
which support _any_ thing falling into those two categories, can not
interoperably replicate. I claim this is counter-intuitive: each is
totally LDAP compliant, after all, so most people would think that of
course they should replicate correctly. I therefore think it is
important to make clear that there is no requirement that LDUP be able
to replicate such directories -- otherwise we will be setting ourselves
an impossible task.

> 
> Finally, we have a lot of work to do in this wg, and all of 
> it hinges on 
> this draft.

Good reason to make sure its a solid spec and doesn't require
impossibilities.

 We can't go forward with anything else until this 
> draft goes 
> forward. I don't think our ADs nor the wg as a whole wants to 
> wait any longer.

Seems like there a quite a few people who still have comments on the
draft.

---

From: John Strassner <[email-masked]>
Date: Tue, 20 Feb 2001 13:23:30 -0800

First, this seems to prove my point. Second, if your system was calling for 
a hundred updates a minute, and the replication frequency was 15 minutes, 
you would know by inspection that your system couldn't handle the load.

So, if you're still convinced that replication frequency has nothing to do 
with it, please come up with some other characterization that is better 
than "we can't support a high rate of updates".

John

At 09:35 AM 2/20/2001 -0800, Paul Leach wrote:
>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).
>
> > Sent: Tuesday, February 20, 2001 8:21 AM
> > To: Ed Reed
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > This seems reasonable, but I would suggest that we quantify
> > this, perhaps
> > in terms relative to the (average) replication frequency of
> > the system.
> > Thoughts?
> >
> > regards,
> > John
> >
> > At 08:41 AM 2/20/2001 -0700, Ed Reed wrote:
> > >Hmmm...I've found a point of agreement with Albert ;-)... see [eer]
> > >
> > >=================
> > >Ed Reed
> > >Reed-Matthews, Inc.
> > >+1 801 796 7065
> > > >>> "Albert Langer" <[email-masked]> 02/17/01
> > > 01:30PM >>>
> > >[Kurt]
> > >At 04:39 PM 2/17/01 +1100, Albert Langer wrote:
> > > >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.
> > >
> > >[Albert]
> > >
> > >...snip...
> > >
> > >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.
> > >
> > >[eer] 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...".
> > >
> > >[/eer]
> >

---

From: "Albert Langer" <[email-masked]>
Date: Wed, 21 Feb 2001 18:09:42 +1100

[Ed]

[Albert]
Agreed.

I am still working on meeting John's request for an elaboration on why I say
the URP
(and architecture) drafts do not comply with the requirements draft (and
will not finish
today). I am therefore postponing replies to the many other issues John has
since directed
towards me.

However your message does go to the crux of the matter as far as I am
concerned, so I'm
taking time off to respond and I hope the reply below will be helpful as
background for
meeting John's request as well.

(Though I hope you have also noticed - as Paul just remarked and Chris, John
and Patrik
are bound to eventually notice too, that there are *many* people with *many*
concerns about *various* different matters and Pandora's box is now well and
truly open. That means LDUP
WG is now actually *functioning*, which is great!)

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065

>>> "Albert Langer" <[email-masked]> 02/17/01 04:59PM
>>>
[snip]
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.

[eer]

My view is exactly, precisely, and PROFOUNDLY the oposite - that it is
critically
important that changes to different attributes made at the "same time" to
the same entry at two different master replicas MUST interleave and both
be preserved.

That, in fact, the expected (by reasonable application users sharing
information for multiple applications using LDUP replication to facilitate
locally
improved performance and availability of directory content for those
applications)
behavior is atomic at the attribute level (if, indeed, not at the
attribute-value level)
for each attribute being changed.  This is, of course, the administration
application of the directory as a distributed nameservice for which vendors
like Microsoft, Novell, and Lotus use directories.

[Albert]
Our views are indeed opposite.

However your explanation of your view below, together with your agreement in
another
message that multi-master is inherently unsuitable for situations with a
high rate of
concurrent changes to the same entry (with the meaning of "high" to be
specified),
suggests to me that there is more common ground than might be thought.

I agree with your assumption above that the dominant application for
multi-master
is "to facilitate locally improved performance and availability of directory
content [...]".

Incidentally I do not believe that is brought out clearly enough in the
usage examples
given in the requirements draft.

Locally improved performance and availability is the driving force behind
multi-master.
There are other means of distributing the directory and other means of
providing high
availability. But there is no other means of providing locally available
changeable
copies.

Changes made to a particular local DSA need to be immediately available
within the local
area serviced by that DSA, regardless of replication schedules, connectivity
etc.

At the same time changes made within the local area need to be replicated as
information
available to other local areas and conversely and it must be possible for
one local DSA
to smoothly takeover the local area normally serviced by another that has
failed
without much delay and additional complexity and costs for fully
transactional
database replication. All local DSAs therefore need to be able to support
both reads and
writes about data that needs to be immediately changeable in other local
areas as well
as in their own. Data about the organization as a whole needs to be
available everywhere
and often changeable everywhere. There may also of course be multiple
"local" DSAs with
load sharing and the organization may be partitioned in various ways
including separate
"central" partitions.

That is a common situation in which multi-master is applicable and useful
and where what it
offers can provide benefits not available from single master with failover.

In that situation one can:

a) Expect a reasonably low rate of concurrent changes to attributes and
attribute values
of a single entry. That is because changes are predominantly (though not
exclusively)
being made locally to the local DSA (or it's replacement on failure) and are
therefore
largely, though not entirely serialized as though in single master mode.
(Provided of
course that one isn't using Novell client libraries with load sharing ;-)

b) Expect that applications are generally changing attributes of an entry
that are largely
independent of each other but simply share a common name tying together a
loose bundle
of properties (several hundred in some deployed multi-master DSAs for
enterprise LAN/WAN
"single sign on" directory applications).

Thus the large majority of users of multi-master view directory data with a
granularity
of an attribute rather than an entry, and are not particularly interested in
any form
of "locking" while making related changes to different attributes of a
single entry.

As your recent anecdote illustrated, problems are just as likely to arise
from writing
and reading from different load sharing servers.

Now I'm going to get less agreeable below. Could you please pause before
reading on, to
check the above carefully to confirm that I do have a reasonable
appreciation of where you
are coming from. If not, I need to know what I have misunderstood because
only you can
actually *know* where you are coming from and I have to get it right when
arguing with you.

I don't expect you to agree with what comes below but I'd really hope
that if you do confirm that first, a natural assumption that my disagreement
below
arises from "just not getting the practical realities" could be less likely.

PAUSE HERE (CHECK ABOVE ;-)
****************************************************************************
**********
****************************************************************************
**********

Ok, well I hope you paused... and I hope I got it right.

What follows as a logical necessity from any attempt to meet the actual,
real world requirements for multi-master is that concurrent changes to
the same entry by different DUAs *will* occur. That is a logical necessity
from the very definition of multi-master - the DSAs do not contact each
other before processing changes from DUAs (that is the means they use - in
order to satisfy the need for "locally improved performance and
availability").

Now you describe that logical necessity "that changes to different
attributes made at the 'same time' to the same entry at two different
master replicas MUST interleave" as a "critical requirement" and add
"both must be preserved".

Three subtle shifts have occurred in that one sentence:

1) You have turned a necessity in order to meet a requirement ("locally
improved performance and availability") into a requirement - and indeed
a "critical requirement".

2) You have focussed only on changes to *unrelated* attributes, when in
fact exactly the same phenomena occurs for:

a) Changes to different values of a single attribute.
b) Changes to related attribute values, including RDN name components.

3) You have added "both must be preserved" as though it follows logically
from the necessity that they MUST interleave, when in fact this is clearly
impossible for case b) and therefore cannot be a logical necessity in
other cases.

I agree with Paul's response:

"I view this as an unfortunate side effect of the ability to
independently change one replica even when others are not accessible,
not as a requirement."

My own words in MDCR were:

   The goals of
   Multi-Master replication are high availability and local
   availability of changeable copies. Occasional concurrent changes to
   the same entry are not a goal but an unavoidable consequence.

You have adopted preservation of concurrent changes as a goal
and the architecture and URP are designed to meet that goal. They meet
it very simply, for the case of changes to different attributes
of an entry, by just accepting *both* changes.

However:

1. Different attributes are not always independent attributes.

According to Alison's
consistency summary, URP will even cheerfully delete a component from
an RDN that has two components at each of two different DSAs and leave the
entry with no name. But is that really a "critical requirement"?
You really need to explain why both deletions MUST be preserved.
The only relevant requirement I can see is the one in the current
draft - that information about what happened must be preserved so
somebody can FIX the mess.

2. They do exactly the same thing for different values of a single
attribute, including ldapACI attribute values which are highly dependent.

You really need to explain *precisely* how an access control model like
the one in the current LDAP-EXT draft is supposed to work with your
architecture. Because it really IS a "critical requirement" that
a multi-master standard be able to support standardized access controls.

This is a requirements discussion as part of a final call on a
requirements draft, which does not contain *your* goal, on which
the architecture and URP have been designed, at all.

You need to explain *why* we should try to meet *your* goal, and why
we should do so at the expense of other goals, including conformance
to LDAP standards relied on by other standards track WGs developing
other proposals.

You have not done so in the message below and have just gone ahead
and designed an architecture without actually getting a signoff on
the goals first.

[EER]
That there is no practical way to utter the request "change
attribute A to have value 'alpha' if and only if attribute B has exactly the
value 'beta'" using LDAP and X.500 absent locking mechanisms (theoretical
discussions to the contrary being considerably outside the scope of "normal
and customary" usage to be expected of application developers).

[Albert]
What you describe, with increasing sarcasm and vehemence below, happens
to be *precisely* the semantics elaborately prescribed for the LDAP
"Modify Operation" in section 4.6 of LADPv3, RFC 2251. That RFC is not a
"theoretical discussion" and it has nothing to do with "normal and
customary" usage to be expected of application developers. It is a
mandatory requirement of a standards track IETF protocol which imposes
certain obligations on DSA implementations claiming to conform to LDAP.
IETF standardizes internet protocols, not application development.

I do not share the contempt for those semantics which you display below.

On the contrary, despite its apparant "complication" of LDAP, I regard it as
a *classic* example of the IETF talent for standardizing "lightweight"
protocols that actually get implemented in the real world, doing just
enough, and no more than, what is required to ensure they meet global
internet
rather than "enterprise" or "vendor" or "academic" requirements.

Application developers are of course free to ignore the precise modify,
semantics and for many purposes are right to do so.

Only applications that need a high level of data integrity need to use
it. (Applications that need an even higher level should not use the
directory at all but fully transactional DBMS implementations).

Likewise deployments are free to combine ridiculously large numbers
of attributes under a single entry rather than respecting the natural
granularity of the directory as being entries.

What the standard requires is simply that DSAs observe certain
very minimal rules to ensure that the *various* different applications
for LDAP directories can *interoperate* using a standard client
server protocol instead of having to figure out what the particular
server will or will not do in a particular situation and thus limiting
the applications that can be deployed *globally* on the internet to
whatever happens to have been thought useful by a particular implementor.

I suspect the hardest part of the original LDAP standardization work
was coming up with that simplification of the X.500 standard for
modify operations in a way that provided the necessary interoperability
without implementors having to cope with all the cruft in the
corresponding X.511 section 11.3.

[EER]

[Albert]
Single master LDAP is and always has been a *distributed* database intended
to become part of a scalable global directory service. The IETF doesn't do
much standardization work on things that aren't distributed. Its primary
concern is with global scalability, not "enterprise" level. It has a solid
reputation for trying to keep protocols as "light" as possible by stripping
out of them *anything* that can not be demonstrated to be *necessary*.

LDAP is widely considered an excellent example of that philosophy.

Here is the relevant text from 4.6:

   - modification: A list of modifications to be performed on the entry.
     The entire list of entry modifications MUST be performed
     in the order they are listed, as a single atomic operation.  While
     individual modifications may violate the directory schema, the
     resulting entry after the entire list of modifications is performed
     MUST conform to the requirements of the directory schema. The
     values that may be taken on by the 'operation' field in each
     modification construct have the following semantics respectively:

             add: add values listed to the given attribute, creating
             the attribute if necessary;

             delete: delete values listed from the given attribute,
             removing the entire attribute if no values are listed, or
             if all current values of the attribute are listed for
             deletion;

             replace: replace all existing values of the given attribute
             with the new values listed, creating the attribute if it
             did not already exist.  A replace with no value will delete
             the entire attribute if it exists, and is ignored if the
             attribute does not exist.

	[...]

   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.

This elaborate provision would be completely unecessary if all that
was needed for LDAP interoperability was "add any values that aren't
already there, delete any values that are". It adds something
quite different and significantly more complex - do each requested
part of the change in the exact order requested and fail the
entire operation, leaving the entry unchanged, if any one of
them fails. It wouldn't be there if a formal determination had not
been made by a WG charged with that responsibility, and that takes
its responsibilities seriously, that this feature is *necessary*
and if that determination had not withstood scrutiny by people
trying to show that it can be done "simpler".

The whole point of specifying that each individual add or delete
must be performed separately in the exact order listed and that
the whole operation be atomic, either succeeding entirely or
failing entirely if any part of it fails, is precisely so that
you can specify:

delete: B, beta
add: A, alpha
add: B, beta

and be guaranteed that you will get A=alpha, B=beta if and only if
B already had the value beta and A did not already have the value
alpha.

There isn't anything else supported by those semantics that could not
be specified much more simply without them.

Now isn't that *exactly* what you said is "outside the scope of what
can reasonably considered 'LDAP'".

How about we pause again, so you can check back and confirm that is
*exactly* what you said and that you are 100% dead wrong.

PAUSE
******************************************************************
******************************************************************

So we as an IETF WG have a responsibility to find out who needs it,
what they need it for and what can be done about that. This is
done by *asking*, not proclaiming. A "requirements" RFC is a very
good place to *ask*. Common sense says that you do that *before*
signing off on architecture and you sign off on architecture
*before* doing detailed protocol implementation.

Most application developers do not really need to know about the
detailed modify semantics or understand it, let alone use it.
Even DSA implentors do not need to understand it.

They just have to implement it. That is so that those applications
which *do* need it do not get broken by ignorant vandalism. Remember
this is global internet standards we're working on, not enterprise
standards. We don't get to decide what applications are going to
be installed *anywhere*, let alone everywhere.

Now here's a simple question for you. Have you ever found it necessary
to *disable* the implementation of LDAP modify as described above in
a local DSA? Do you know of any applications common in the environment
that is a typical use of multi-master, that are hindered in any way by
the fact that a local DSA will fail a request like the one
above if a DUA happens to make it and the value beta was not there?

It seems to me highly unlikely, since any application that would be
hindered would simply not make such very specificly contrived
requests that are *intended* to fail under *exactly* those circumstances.

Yet it's pretty obvious that if multi-master DSAs that don't support
this behaviour are deploysed in the same global scalable directory
service with referrals etc as existing DSAs that do support it, any
applications that rely on it are going to break immediately. *That's*
the sort of interoperability issues that IETF standards are *about*.

Conflicting writes to the same entry may occur at a local DSA due to
an application reading an entry, deciding on the basis of what it has
read to add or delete a value and then have that write operation
fail because some other DUA has in the meantime added a value it
intended to add, or deleted a value it intended to delete at the same
DSA.

Such failures are *normal* and any properly designed LDAP client
application will recover from them by re-reading the entry and
deciding what it wants to do again. (Some applications don't
bother, because the interval is short, but no applications
whatever have any "problem" from this feature of LDAP that is
not simply a bug in their own programming).

In fact the LDUP architecture draft specifies that each multi-master
DSA MUST implement this behaviour, as constraint 6 in Appendix A.

6) Elements of Protocol - Modify Operation - The entire list
  of entry modifications MUST be performed in the order
  they are listed, as a single atomic operation. (p33)

That completely refutes your claim that "it is critically
important that changes to different attributes made at the 'same time' to
the same entry at two different master replicas MUST interleave and both
be preserved".

If it was "critically important" you would not have specified that it
only be allowed when the two DUAs happen to be communicating with
different DSAs - after all, most changes important to multi-master
are made locally - that's the point of it - and LDAP is designed
to conceal as far as possible from application users what DSA they
are using.

So as well as your view being "exactly, precisely, and
PROFOUNDLY the oposite" to mine, it is equally "exactly,
precisely, and PROFOUNDLY the oposite" to your own.

Forgive me for not being greatly impressed by how
PROFOUNDLY you refute yourself.

Furthermore, you *concurrently* wrote that interleaved
changes are inherently unsuitable for multi-master *and*
that preserving them is critically important to it. That
is a classic "write conflict" which would have benefited
from "conflict resolution" rather than "update reconciliation".

[EER]

[Albert]
They are defined for LDAP and have been ever since it first got on
the standards track. The same wording has survived through the
revisions for RFC 1487, 1777 right through to 2251.

"Now why would anyone want to do that". Perhaps it's about time
you tried to find out.

BTW, have you ever wondered why Microsoft doesn't implement
"modifiersName"? It is a rather important
operational attribute sadly missed by sysadmins trying to figure
out "who done what" when something goes wrong and is needed to
support "critical requirements" like audit trails. What is there about
*their* design that makes it impossible for them to include it
in a schema with many hundreds of attribute definitions?

BTW does Novell implement it?

Incidentally this requirement is *very* carefully designed to avoid
any need for "locking semantics". It does not require DSAs to maintain
any kind of "locking" at all. They can process each operation as it
comes without maintaining any state about other operations apart from
the results. This is very precisely calibrated to *not* impose any
burden on DSA implementations and provide *exactly* the minimalist
degree of support for applications that require high data integrity
that is possible, without compromising the characteristics of a highly
scalable global distributed directory service.

There is no "may" about it. LDUP MUST now consider "how or indeed if
they can be replicated via some use of LDUP or some modification of
LDUP". Until that consideration has been given it is "foolish" to
assume that IETF will not preserve the requirements of an existing and
widely adopted standards track protocol to meet the unsupported claims
of a rather minor and somewhat vendor dominated WG.

There are procedures by which mandatory requirements of existing
standards can be altered or waived. But they do not consist, as some
seem to imagine, of repeatedly telling me to stop mentioning
that they are there because some undocumented "consensus" of the
flat earth society has decided that they aren't. (BTW sincere thanks
for having not done that - it is the mark of people who at least
believe they have a valid argument that they do put it forward
rather than repeatedly claiming the issue is "settled" no matter
how obviously the mere fact that they need to keep repeating
themselves shows that it is not).

[EER]

[Albert]
I just *loved* the bit about waving a chicken, but I got a bit lost
in the rest and have missed any point you were making that is
responsive to anything I have actually said.

I think the key point you are making is in the words "show stopper".

It is possible using the semantics *required* by LDAP, to implement
various forms of counters, semaphores etc as described by Kurt. Such
use could plausibly be described as "by standing on your head and
waving a chicken about with precisely the correct flapping pattern
of your legs". However that description is not entirely fair. There
is no reason to assume that Kurt is wrong about some applications
making use of that possibility for good reasons and such
experimentation is very much part of what internet protocol
development is about, so I wouldn't be so dismissive.

Incidentally, even if Kurt is still the only committer, I suspect
that OpenLDAP will eventually take off as the dominant LDAP
implementation and Kurt may therefore be the most significant
implementor here. Don't forget that the whole LDAP "industry" owes
its existence to the open source Umich implementations, *not* to either the
proprietary directories developed by vendors like Novell or to
the X.500 standards work which never got as widely implemented (though
the latter did make a *major* contribution - unlike "vendors").

The simple answer to Kurt's point is that multi-master *unfortunately*
cannot, and therefore does not, work with applications that use such
facilities. That need not be a show stopper.

If it could likewise be shown that multi-master *cannot* provide for
the normal use of the *required* modify semantics to ensure "what you
changed
is what you saw", then that need not be a show stopper either.

Even if LDUP could simply show that it has very good reasons for
needing a waiver, despite it being *possible* to conform - and that the
damage would be minimal and the benefits great, I suspect that
would not be a show stopper either. In fact you might only need
to show that you have seriously considered alternative options
and give good reasons for your approach being better.

But you will have to give *some* reasons that actually stand up
to scrutiny, not just unsustainable assertions and demands.

BTW I have already published an I-D showing that supporting
the existing standards is not impossible, within the inherent
limitations of multi-master. So the obligation on
you is to demonstrate why *your* goal, never adopted even by
the LDUP WG, should be met instead. I'm sure you can show
a *better* way to do it than I did - all I claim to have
established is that it is *possible*.

In fact your own architecture draft makes it obvious in 3.7 that the
required semantics *can* be implemented, within the limitations
of multi-master:

***
In the case of a single-server or single-mastered
Replication Context all LDAP Constraints are immediately
enforced at the single updateable replica. An error result
code is returned to an LDAP Client that presents an
operation that would violate the constraints.

In the case of a multi-mastered Replication Context not all
LDAP Constraints can be immediately enforced at the
updateable replica to which the LDAP Update Operation is
applied. This loosely consistent replication architecture
ensures that at each replica all constraints are imposed,
but as updates are replicated constraint violations arise
that cannot be reported to the appropriate client. Any
constraint violations that occur are repaired by a set of
update resolution procedures.

Any LDAP client that has been implemented to expect
immediate enforcement of all LDAP Constraints may not behave
as expected against a multi-mastered Replication Context.
***

Unlike your assumptions in this message, the above, which I
assume you also had at least a hand in writing, is an *accurate*
assessment of the limitations and necessities of multi-master.

Certain LDAP constraints which an application can expect to
be enforced immediately in a single master environment can
only be enforced after the fact in a multi-master environment.

That is a simple objective limitation of the applicability
of multi-master, which cannot be a show stopper
or LDUP would not have been assigned a charter to develop
multi-master standards.

The architecture draft *does* enforce those constraints it
acknowledges. In particular it resolves conflicts between
rename and create operations in the only way feasible. It does
so after the fact because that is the only possibility for
multi-master and it preserves all the information available
for users or administrators to sort out the problems that
inevitably *do* arise as a result of only being able to
enforce the constraints after violations have already
happened - because that is the common sense thing to do.

But for the constraints specified by the modify operation the
architecture, and consequently URP, has adopted the exact
opposite approach - of simply pretending those constraints
are not there, except locally. It does not even retain sufficient
information to enable administrators to fix the problems
- as explicitly required by the current requirements draft.

That's what happens when you go ahead with architecture
before finalizing requirements.

The "goal" you are trying to meet was never agreed on as
an LDUP WG goal, let alone put forward to IETF seeking
a waiver or alteration to existing LDAP standards, and
is not even stated as a requirement in the current
LDUP requirements draft now at final call.

You need to explain *why* you have chosen
*not* to enforce the constraints of the LDAP modify
operation semantics. I doubt that saying that they don't exist
and you "may then consider" them if they should
happen to come into existence at some future time
will be an acceptable explanation.

You need to explain *why* LDUP could not, or at least should
not, adopt the same approach for modify operations as it
has adopted for create and rename.

In particular you need to explain that in a context where
you have already *agreed* that multi-master is unsuitable
for situations with a high rate of concurrent changes.

If all you can demonstrate is that you neither know nor care
about the existing standards work but are very convincing
and witty, you are in the wrong place.

[EER]

[Albert]
There are also LOTS of alternative approaches to providing
directory services, and even directory services that can be
used with standard LDAP clients. For example you can even
just bolt-on a non-standard semi-LDAP veneer over a fundamentally
non-compliant existing proprietary directory server and call it
an LDAP server as Novell has done, or design one from the ground
up adopting those aspects of the standards that seem convenient
and ignoring those that don't, like Microsoft. Nobody will stop
you. IETF doesn't need to go around trying to enforce non-use
of an "LDAP service mark" or anything silly like that.

It just so happens that the requirements of internet
interoperability do eventually drive all sorts of vendors
with different agendas to the conclusion that they need to
conform to objective common standards that they are unable
to impose themselves and which they often find more useful
to develop through the IETF process than through industry
forums etc.

Meeting vendor requirements to support their pet design ideas
is not one of the things that IETF standards process are good
for. If you benefitted from LDAP standards work, think very
carefully about those benefits.

At this stage, after more than two years work, you have not
yet reached the level of having even 2 interoperable actual
implementations conforming to a published specification that
demonstrates that your architecture at least *can* be
standardized, whether or not it should be.

No more experience of the practical
operational implications of multi-master standardization has
been acquired by the IETF so far as a result of chartering
this WG, than would have been obtained by just monitoring the
experience of the non-interoperable Microsoft and Novell
implementations.

You are in no position to be making demands that the requirements
of existing standards be ignored to meet the goals of your
architecture.

[EER]

[Albert]
If you develop an architecture that ignores existing standards and
makes interoperation with applications based on those standards
"perilous" you had better be prepared to justify it.

If your justification is that you think:

"it is critically important that changes to different attributes
made at the 'same time' to the same entry at two different master
replicas MUST interleave and both be preserved"

then you had better be prepared to present an explanation that
actually stands up to scrutiny, because that is what it will
receive at IETF last call.

You have agreed that this is "correctly described" as meaning
applications which expect "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" do so at their own peril when operating against
directories implementing your architecure.

You had better be prepared to do some actual requirements analysis
and document the effect on existing applications and the measures
you have taken to minimize the "peril".

In particular you had better take a look at parallel standardization
work on access control - without which LDUP deployment would be
useless, and which is fundamentally broken by your architecture.

[EER]

[Albert]
Ok, so I'm Australian. But I've never worked for ICL and you are
shouting at the wrong person.

delete: B, beta
add: A, alpha
add: B, beta

Look Ma, no locks! No two phase commit. No XA transaction protocol monitors.
No acres of glistening dinosaurs with hundreds of kilometres of optical
fibre. Isn't it amazing what those crude amateurs can achieve by ignoring
the advice of experts from established vendors well known by their fame.
Just two extra lines of code and no waving of chickens between our legs in
precisely the right flapping pattern. And a draft showing it's possible to
implement in a distributed multi-master environment can be written in a week
when it takes "engineering teams" *years* to write drafts that don't even
meet the requirements developed in the same WG.

But now that you have started SHOUTING, perhaps it's a good time to ask.

Just why *are* you here? And why are you using LDAP?

Why are you trying to move IETF somewhere. If you don't think
much of the LDAP standard, and can't even be bothered proposing
an amendment to it when you think some aspect of it is useless
or harmful? Why not develop your own through a vendor forum?

I assume you are here because you want the IETF to adopt a new
standards track protocol which will provide interoperability
benefits for implementations of directory services. You are
using LDAP because it turned out be one hell of a lot more
deployable in practice on the internet than the proprietary
clients you had already developed for a very widely deployed
and indeed completely dominant enterprise LAN/WAN directory
server.

If so, you are going to have to go through the IETF process,
whether you like it or not. This includes the benefit of
helpful and thoughtful comments from people who have a lot
of experience and know exactly what they are talking about.
It also comes with having to put up with ignorant comments
from people who don't. You have to answer both and show
that your proposals are technically justified.

If you think my comments are in the latter category, that's
up to you. But you still have to answer them.

You might want to pause to consider whether it would have
been easier to do so if you had paid more attention to the
very quietly spoken, non-obnoxious guy who dropped in
briefly to the LDUP WG very early on and offered this
"two cents worth" of advice before disappearing again:

***
Each LDAP operation (add, modify, delete, moddn) as
a whole is atomic. The whole operation either happens
or it doesn't. Changes cannot be half-applied to any
single LDAP server.

The replication consistency model must assume and
build on this basic fact to define how multiple LDAP
replicas converge to the same state over time, in
the absence of additional changes. This kind of loose
consistency model is pretty fundamental to the notion
of a directory.

My two cents on what's important in a replication
consistency model are that it must be 1) predictable,
and that it should 2) make some kind of sense to
people using the system.

All this talk of consistency at different levels
(e.g., between applications using the directory at
the same time) is a red herring. Our job is to define
a consistency model for the directory itself. Some
applications may find this model sufficient for their
needs. Others may have to build more elaborate models
on top. But let's start with the basics.    -- Tim

***

It isn't as though you ended up with me getting obnoxious
about it without having been told very politely by
people who are much more authoriative. The advice was worth
a lot more than 2 cents.

Note the word "must". It doesn't have to spelled MUST for
most people to pay attention.

Would you characterize the 9 transient states that can
arise with URP from changes to just two attribute values
as "predictable"?

Can you point me to any standards track protocol that
is more convoluted and harder to make sense of than URP?

You didn't listen and you've been going around in
circles for more than two years since. Start listening.

[EER]

[Albert]
Ed you have been the architect for Novell directory services,
and your most critical competitor has been Microsoft. They
did their homework and studied your design very carefully
because they knew they had to beat it.

You should have done *your* home work and studied theirs.

As far as I can tell, I know a *lot* more about Active Directory
then you do - so I knew you were wrong about that before Paul
pointed it out. I can tell, because I did spend several hours
discussing things with you before writing my draft, in which
I benefited greatly from a lot of insights from you - duly
acknowedged in the draft, but in which you were the one asking me
questions about AD. Do your homework.

"Even Microsoft" used sequence numbers rather than timestamps so
that their non-compliant directory is at least capable of
satisfying "eventual convergence" - which your architecture does not.

"Even Microsoft" at least maintained the granularity
of replication at the attribute level, which means that it is
*possible* for application developers to maintain data integrity
(by using Microsoft APIs rather than LDAP standard APIs) whereas
your architecture actually goes down to the attribute value
level, thus making it impossible - despite the fact that your
own explanation points to attribute level granularity.

They haven't "moved" anywhere - they broke atomicity right from
the start, but did so in a way that was at least viable and
suited their own commercial interests.

And "even Microsoft" *learns* from its participation in IETF WGs
and leaves the spouting to the marketing department outside.

The only thing that will supplant them is a *better* design,
not a worse one - and they are probably smart enough to adopt
one rather than stick their heads in the sand. So you'd better
be prepared to really think about being willing to evolve
rather than just persisting with "WHAT WE SET OUT TO DO".

Sorry I'm picking on you. But please take it as a compliment,
because I have spent several hours learning from you and I
think there is at least the possibility that you *could* start
listening, because you actually do know what you are talking
about. Likewise I have been willing to argue with Steve, whose
draft I completely reject, whereas I am far too "respectful" of
some to take them on in a way I don't think they could handle.