[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

regards,
John

At 04:52 PM 2/17/2001 -0500, rmoats@xxxxxxxxxx wrote:
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>

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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