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

From: <[email-masked]>
Date: Sat, 17 Feb 2001 16:52:59 -0500

I think I'm using <rm4>...</rm4> this time... Ryan

>Date: Sun, 18 Feb 2001 07:33:41 +1100
>Subject: RE: WG Last Call on the LDAPv3 Directory 
Replication I-D
>
>[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.
>
><rm3>I'll admit I don't understand the technical point of 
this comment.
></rm3>
>
>[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

<rm4>Well, as I explained to Mark, in the absense of an
access control standard, I don't see the point and (here's
where folks disagree) I don't think we should talk about
it here, but rather in LDAPEXT where the access control
work is being done. Mind you, I'm not saying access
control will or won't be replicated, I'm making a procedural 
distinction.  If the chairs of LDAPEXT/LDUP disagree with
me, we can certainly open it here, but its (IMHO) a done
deal that LDUP won't make any progress until the access
control model is finished, and I'm certainly not in favor
of that.</rm4>

>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]
>The actual wording of the LDUP requirements does now require 
both atomicity
>...
>
><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>
>
>[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 problem. That is 
what I meant by
>"it proposes that sysadmins should 'boil the ocean' by 
resolving resulting
>problems manually".

<rm4>I'm going to make another slight distinction.  The
requirements don't say "don't fix the problem", they say
"if fixing the problem involves loss of data, you'd better
tell somebody about because if the fix is wrong, losing
what was the correct data is a BAD Thing".  I don't claim
to know what every directory administrator will want in
every case, so I think that some administrator notification  
in cases where data would be lost (even including your
preference below of rollbacks/notifications) is a GOOD 
Thing.</rm4>

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

<rm4>Another IETF procedural point:  I don't believe that
the requirements "rule out" the current architecture and
protocol.  I believe the ADs/charis will agree that what
this does is put the onus on the architecture and protocol
drafts to explain WHY (in acceptable detail) they are ignoring
specific requirements.  Of course, if the ADs/chairs
disagree, that would be good to know too :-)</rm4> 

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

<rm4>That's a fair opinion, although I believe that most
"if not all" of those examples are taken from real life
cases.</rm4>

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

<rm4>That could be true, and we shall certainly see.</rm4>

>[Albert]
>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>
>
>[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).

<rm4>Thanks, now I have a clearer picture.  I don't remember
seeing a "last call" call for the URP draft yet (although
I'm not looking at the archives at this moment) and I
do believe that the point I raised above is a fair comment
for the URP draft to answer when it goes to last call</rm4>

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

<rm4>I believe the reason for this is the procedural
distinction I made above.</rm4>

>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 22:30:21 -0800

At 04:52 PM 2/17/01 -0500, [email-masked] wrote:
>work is being done.

In general, I concur.  But I do note that LDUP must take
an active role in ensuring their needs (whatever they might
be) are being met as LDAPext has no specific requirement to
met replication demands.

>Mind you, I'm not saying access control will or won't be replicated,

Neither am I.  I however note that it's likely not wise to assume
that LDAP ACM will support replication, especially multiple
master replication, when there is no specific requirement.

>I'm making a procedural 

And neither do I.

I believe the LDUP Requirements I-D should not state that the
LDAP ACM is addressing replication requirements/issues as clearly
RFC 2820 has no specific requirement for LDAP ACMs to address
any replication issue [nor is the current LDAP ACM actually
addressing replication issues].

However, if LDUP requires an ACM which does support replication
it should clearly state so.

Kurt

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 19 Feb 2001 01:07:31 +1100

[Ryan]

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

[Albert]
I will just provide the link above to your original message and select bits
for reply.

B using access
drafts, taking
discussion of
>http://www.imc.org/ietf-ldup/mail-archive/msg00738.html

[Ryan]

[Albert]
Nevertheless access control mechanisms proposed by one of the
authors of this requirements draft provide an excellent
illustration of application mechanisms that one might assume
would work ok with the approach discussed in appendix B but which
don't when you take a closer look. I repeat my advice to take
that closer look.

As to "not saying access control will or won't be replicated" and the
"procedural distinction", the draft clearly states:

"M4.  LDAP replication MUST encompass schema definitions, attribute
names and values, access control information, and name space
information."

and

"AM6.  Access control information (ACI) associated with sensitive data
MUST be deleted after or simultaneously with the deletion of the
sensitive data.  Likewise, during Adds, ACI MUST be added first or
simultaneously with the addition of that data."

Certainly there isn't going to be much deployment of LDUP without
an access control standard and that is clearly recognized in the
WG charter. But given that, it is all the more important to understand
what LDUP protocols will be required to achieve in order for access
controls to *work*.

The most recent draft for an access control model is:

http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-06.txt
(expired 14 January 2001)

This uses multiple attribute values for a single ldapACI attribute and
relies on atomic semantics of LDAP modify operations.

The most recent draft for LDUP URP is:

http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt
(expired 29 December 2000 - but listed for final call in January 2001
in a WG charter posted on 10 February 2001)

That splits a single ldapACI or any other attribute into independent
attribute
values each of which can be updated independently by "primitives" not
corresponding
to a single LDAP modify operation, but processed and forwarded as they
arrive from
different operations by different DUAs via different DSAs. This completely
breaks both the semantics of the LDAP modify operation and the proposed
access control mechanism.

Given adoption of M4 and AM6, LDUP would be precluded from adopting URP
unless LADP-EXT
drops its current acl model. I see no problem in that, and presumably Ellen
doesn't either
as an author of both those requirements and the acl draft, but Steve and
Alison might and
should not be left under any illusions about it.

[...]

[Ryan]

[Albert]
When I first drafted MDCR I personally thought that notificatins would
be essential but left it open because of likely (and indeed subsequently
expressed) opposition to adding that burden on implementors. If indeed
that resistance has been overcome and there is now a consensus on mandatory
storage and notification I think that's great.

As to what can be done to minimize the burden on administrators by using
rollbacks
and notifications to users, I agree with your remark below that this can be
left to emerge from later discussion.

I agree with the requirements as stated:

"MM5.  Multi-master replication MUST NOT lose information during
replication.  If conflict resolution would result in the loss of
directory information, the replication process MUST store that
information, notify the administrator of the nature of the conflict and
the information that was lost, and provide a mechanism for possible
override by the administrator."

"MM6.  Multi-master replication MUST support convergence of the values
of attributes and entries.  Convergence may result in an event as
described in MM5."

"P6.  The protocol MUST support propagation of atomicity information."

The discussion of create and rename conflicts in B.5.1 and B.5.2 makes it
quite
clear that the intended meaning as well as the actual words precludes a
specification
that has no means of storing information about conflicts and no means of
propagating
such information.

***
"Whichever change arrives first, requirement MM6 says that the values
from replica A must be those in place on all replicas at the end of the
replication cycle.  Requirement MM5 states that the system cannot
quietly ignore the values from replica B.

The values from replica B might be logged with some notice to the
administrators, or they might be added to the DIT with a machine
generated DN (again with notice to the administrators).  If they are
stored with a machine generated DN, the same DN must be used on all
servers in the replica ring (otherwise requirement M3 would be
violated).  Note that in the case where the entry in question is a
container, storage with a machine generated DN provides a place where
descendent entries may be stored if any descendents were generated
before the replication cycle was completed.

In any case, some mechanism must be provided to allow the administrator
to reverse the conflict resolution algorithm and force the values
originally created on B into place on all replicas if desired."
***

The discussion in B.5.3 confuses the issue as involving some sort of
"locking" when it is simply a matter of ensuring that "what you changed
is what you saw". Nevertheless the reference there to the necessity for any
mechanism that resolves mody conflicts as opposed to create and rename
conflicts
to not violate G6 leaves no doubt that the natural meaning of the
requirements
language used in the actual numbered requirements is in fact what the
authors intended.

Obviously URP cannot propagate atomicity information since it has
no such concept but replicates each attribute value independently and will
therefore
forward changes originating concurrently from different DUAs at different
servers
to values of the same attribute with no means of unscrambling the omelette.
That is the whole point of the design (which avoids logging). Consequently
it
*fundamentally* cannot notify anybody about events it has no concept of.

In addition of course URP and the architecture currently fails to support:

"G1.  LDAP Replication MUST support models 2 (Eventual Consistency) and
3 (Limited Effort Eventual Consistency) above."

Though that is easily fixed by abandoning the reliance on timestamps, just
as
I believe MDCR could be easily fixed to comply with G6.

I object to the failure to require actual atomic operations in P6, just as I
object
to the requirement to also support "eventual divergence" in G1. More
fundamentally
I doubt that adoption of the requirements document will actually resolve the
requirements issues since it is quite clear that the same meeting which
considered
this draft ready for "final call" also considered URP equally "ready",
despite the
unambiguous conflict between them.

because it clearly
capable of
>the information needed to notify admins as required.

[Ryan]

[Albert]
Surely that is the distinction between MUST and SHOULD as
used consistently in the draft, with an explicit reference
to RFC 2119. In this context a SHOULD requirement could be
met by an explanation in acceptable detail of why other
design constraints made it necessary to not satisfy (as
opposed to "ignore") the SHOULD. But if a MUST requirement
is not met, then either the proposed specification or the
requirements document would have to be amended. Otherwise
what could possibly be the point of using the word MUST
in this context?

For example:

"G6.  Meta-data collected by the LDAP replication mechanism MUST NOT
grow without bound."

I read that as "ruling out" my MDCR proposal in its current form. Once
adopted
as a "requirement" I would be obliged to modify the proposal to meet that
requirement rather than waste the WG's time rehashing a settled issue, by
submitting another version without fixing the problem - and rightly so.

In the same sense, the MUST requirements cited above "rule out" the current
architecture and URP proposals. Otherwise they simply don't mean anything
at all, and the whole exercise is pointless. That may well be the case,
given the current level of understanding, but I'm certainly not going to
be a party to a "consensus" about nothing in particular.

[Ryan]

[Albert]
Yes, and they therefore could provide a useful basis for
discussing concrete issues about conflict resolution.

Unfortunately such discussion was squelched by Chris when it
was about to start between Rick and me and I am not willing to
make a second attempt at the moment.

>actually fix the problems by rollbacks and notifications

[Ryan]

[Albert]
Agreed.

[...]
[Ryan]

[Albert]
There has been no "last call" on URP yet. Just a charter
posted that announced that it was scheduled to be done
together with the requirements last call in January
and a recent explanation by John that it will now
be after requirements have gone through. Hopefully somebody
will ensure an unexpired version is available before
issuing a final call this time.

Anyway, the authors of URP and the current architecture
have now had the requirements issues explicitly drawn to their attention
and should not be surprised about being expected to address any
requirements that have been adopted when those documents go to last call.

---

From: "Ryan Moats" <[email-masked]>
Date: Mon, 19 Feb 2001 15:18:10 -0600

Sure John,

I'm extracting the relavant pieces and using <rm5> this time.

Ryan

[...snip...]
>disagree, that would be good to know too :-)</rm4>

<js>
I agree with Ryan's characterization.
</js>

[...snip...]

>for the URP draft to answer when it goes to last call</rm4>

<js>
The URP draft has NOT been issued as a last call yet.

Sorry Ryan, but I'm not sure that I know which "point above" you are 
referring to. Could you please point this out?
</js>

<rm5>If URP goes to last call without (at least for me)
acceptible statements as to why it doesn't meet certain 
requirements, I'll try to be first in line saying "uh, I don't
see that you've met requirement <fill in blank> nor do I see
a statement as to why", that's all.</rm5>

---

From: John Strassner <[email-masked]>
Date: Mon, 19 Feb 2001 11:04:32 -0800

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

regards,
John

>control model is finished, and I'm certainly not in favor

<js>
With chair hat on, I for one think that access control replication needs to 
happen in LDAPext. There are two reasons that I think this.

First, LDAPext is currently chartered to do access control. Suppose they 
finish and produce a standards-track RFC, and LDUP comes along and says 
"wait a minute, something's wrong". Shouldn't the original authors fix the 
problems?

Second, and more troubling, if we follow this model, then every draft that 
presents unique information, or information that should be specially 
handled, should require LDUP to fix it. This will ensure that we have a 
never-diminishing charter, which is a Bad Thing.
</js>

> >it after delivering himself of that tirade.

<js>
Sorry, I've lost the context here. What is Chris's (Apple?) reply, and what 
issue are you talking about that it disrupted?
</js>

> >"it proposes that sysadmins should 'boil the ocean' by

<js>
But in this case, we're talking about losing data. There is no way for the 
protocol to fix the problem by itself without introducing semantics that 
will confuse users, as previously documented. I personally don't see any 
other option than requiring the sysadmin to fix the problem, and the wg has 
concurred.

What concrete suggestion or improvement, other than replacing URP, do you have?
</js>

<js>

> >actually fix the problems by rollbacks and notifications

<js>
Since LDAP does not have rollback and notification semantics, how do you 
propose to do this?
</js>

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

<js>
Not only do I also not see the point of this comment, I think the WG 
disagrees with you. You are postulating, without any evidence to the 
contrary, that the WG doesn't understand why it agreed to put the I-D into 
last call. That's absurd.
</js>

> >that it is incapable of meeting the requirements as stated.

<js>
<Chair hat on>
The working group has made a set of decisions, and I as one of the chairs 
respect those decisions and see a consensus. Therefore, please stop making 
blanket statements and instead provide facts. Please don't reissue your 
proposal, as it has already been rejected by the working group. Rather, 
please try and make constructive comments to the existing drafts. If you 
would like, I'd be happy to discuss this with you off-line. Otherwise, 
please detail exactly what is wrong and, more importantly, exactly how to 
fix it. Thanks.
<Chair hat off>
</js>

> >propagate atomicity information needed for notification

<js>
Again, this comment is not helpful. Please follow the guidelines in my 
previous comment.
</js>

<js>

> >requirements not met by URP when that comes up.

<js>
Albert, if you're this convinced that URP does not meet the requirements 
document, please elaborate now, rather than later, in a separate thread 
(since this one is already so long). Thanks.
</js>

---

From: "Albert Langer" <[email-masked]>
Date: Tue, 20 Feb 2001 09:20:17 +1100

<js>

[Albert]
An excellent request of exactly the sort that I indicated has been lacking
from
WG chairs in a message that crossed in in the ether with this one. So I will
comply with it fully, despite the fact that you have still not withdrawn
your
remark about "unprofessional" comments. I will also take it as an excuse not
to
respond directly to the several specific points you directed towards me in
your
recent messages and concentrate instead on fulfilling the above, as a good
way of starting afresh rather than getting entangled in the various bits and
pieces. I have now said what I think
needed to be said in response to other things and would greatly prefer to
turn to positive technical dialogue as you propose, rather than continuing
on those matters.

Also I agree with your comment in your other recent message, concerning my
statement:

"I mention it as an "option" only because it is the current architecture,
not because it
has any technical merit whatever."

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

That was a product of my general irritation and I agree it is not helpful.

I have been up all night and am now going to get some sleep before
responding exactly as you have requested.

---

From: John Strassner <[email-masked]>
Date: Tue, 20 Feb 2001 14:18:16 -0800

Albert,

I would very much like the emotion to be reduced and have just technical 
issues be discussed on this list. I did respond to you privately (another 
ether crossing message, as you put it) as to why I thought your remark was 
unprofessional, and will be happy to continue that discussion offline with you.

My only worry is that when discussing these matters, please don't refer to 
your MDCR draft. It has been the feeling of several members that you are 
still promoting this draft. This most likely comes from your using similar 
arguments or examples as those you used in the MDCR discussion.

What I would encourage you to do is to start with specific text from the 
requirements draft and then frame a discussion around it. Last call is due 
to end today, 20 February, but in light of the recent volume of postings, 
what I propose to do (yes, the chair hat is ON) is to encourage EVERYONE to 
respond to the current threads. I will then collect them and, over the 
weekend, summarize and declare what we do and don't have consensus on. I 
will then recommend the next steps for the WG to take on this, the charter, 
and the URP draft.

Albert, I look forward to your positive comments.

sincerely,
John