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

[<rmoats@xxxxxxxxxx>]

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.