Subject: Consolidation of WG Comments on Requirements I-D Last Call Thread

From: John Strassner <[email-masked]>
Date: Sat, 24 Feb 2001 22:02:26 -0800

LDUPers,

this is the first memo, summarizing the  thread: RE: WG Last Call on the 
LDAPv3 Directory Replication I-D. Note that there were a lot of subjects 
covered in this thread. Only those subjects that directly pertain to the 
requirements I-D will be discussed here. Other subjects having merit will 
be discussed later.

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 1: text describing objectives (in Section 3), passive store
Chair Summary: This was a long thread. The idea was to define the notion of 
a "passive store" and then to limit LDUP to directory servers which 
implement a passive store. It also gave several specific examples of 
functionality that were not passive in nature. I believe that the WG has 
rejected this notion because of the difficulty in precisely defining a 
passive store, and also because the examples repeatedly referred to 
functions that do not exist as LDAP standards yet. While one of the 
examples, access control, is being handled in LDAPext, the other examples 
don't even have drafts written for them. As chair, I am unwilling to delay 
the requirements document any longer, and do not want to hold it hostage to 
mechanisms that may, one day, be written in a WG.

Action: none required in the I-D

Sub-issue 2: text describing objectives (in Section 3), clarity of text
Some people wondered if the text was clear enough in pointing out that LDUP 
was providing "...interoperability between directories rather than between 
their representations". I think that, in order to move on, it would be 
helpful to have a brief sentence or two added to the draft that clarifies 
this point.

Action: add clarification that when LDUP is used to replicate information 
that is interpreted by a directory server in ways that are not standardized 
by LDAP, the results are unpredictable.

Sub-issue 3: access control. This draft is being developed in LDAPEXT. A 
question was raised as to whether the LDUP WG should be responsible for 
supporting replication of ACI. The answer is NO. There are several reasons 
why, the most important of which is that unless the original authors in the 
original WG that wrote the draft write the requirements for LDUP, there 
will be conflicts. Then, we have a mess, because the LDUP ACM wouldn't 
agree with the more general LDAPext ACM. The **only** solution to this 
dilemma is to have the LDAPext authors take on this work.

Action: none required in the requirements I-D; LDUP chairs to bring this up 
with LDAPext chairs and report to the LDUP WG

Sub-issue 4: locking
Locking is not germane to the requirements draft. It is up to the 
architecture and other drafts, as required, to address locking. However, 
several people have suggested that if developers attempt to create their 
own locking or other similar control mechanisms, the requirements draft 
should state that they do so at their own peril when operating against 
directories supporting LDUP. I agree.

Action: a brief explanatory note pointing this out should be added to the 
requirements I-D.

Sub-issue 5: defining what types of information should be replicated
Several people suggested that 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. Since there was no clear consensus 
here, I'll state my views. I don't think that this is a good idea. The list 
that we will come up with will not be complete, and this will confuse 
people. Second, what's the point? Such information is either being 
controlled via non-standardized mechanisms, or is handled in 
application-specific manners. If the mechanism is not standardized, I don't 
see how it can be replicated.

Action: none required in the I-D

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

Sub-issue 7: removal of P6 (atomicity information)
We've had one argument and one reply which said "yes it does" without 
technical justification. The request centered around replicating and 
converging state, and defined atomicity in an application-specific sense. 
While I don't believe that the requirements draft was concerned with 
application-specific atomicity information, I do think that this needs a 
response, and likely better definition of what, specifically, propagating 
atomicity information means.

Action: This requirement needs to be explained and justified in the I-D. 
The I-D should answer the question of whether it is propagating end-state 
or propagating a set of operations required to replicate that end-state, 
and WHY it is doing so.

Sub-issue 8: do the examples need modification?
The specific issue was whether the examples bring out sufficiently whether 
the dominant application of multi-master replication is to facilitate 
locally improved performance and availability of directory content.

First, this WG is not in a position to decide what is or is not a dominant 
use of directories. Second, I only have one person asserting that the 
example does not bring out this point. It is fruitless to argue this point, 
it **is** after all just an example.

Action: no action required for the I-D.

regards,
John Strassner
Co-Chair, LDUP WG