RE: Fwd: controlling visability of subentries

["Albert Langer" <Albert.Langer@Directory-Designs.org>]

[Mark]
The problem I see with solution 2 (create a control that mimics the X511
ServiceControls) is that there would be no way for an LDAP client to
discover the subset of ServiceControls that is supported on a given LDAP
server.  Surely we are not going to require support for everything in
ServiceControls just to solve the subentry problem.  Therefore, I prefer
solution 1.

And so everyone knows what we are talking about, from X.511:

[long list of X.511 controls snipped]

[Albert]

I've got no opinion either way on option 1 or option 2 as not familiar and
don't have time to study it.

However I question the validity of this argument against option 2.

Would have thought that the usual "discovery" mechanism would work ok.
Client tries to use a control, server returns error response, client that
cares notes that server does not support control and caches that info for as
long as they wish to. Clients that don't care don't care, so they don't try
to use the control and don't get error responses.

Sorry if there is some obvious flaw in that. I haven't studied the details.

PS This also a "hi" to all in view of long absence. Sorry I haven't been
able to respond to latest requirements doc due to other commitments (still
stuck in those for a while yet). But then nobody else has either. I do
believe it was a significant improvement and genuine effort to address my
objections.

For the record:

1. I'm assuming some means of guaranteeing eventual convergence *will* be
proposed with at least an initial draft prior to final call on the
requirements draft. I believe there is probably a consensus for eventual
convergence and the apparant ambiguity in the requirements draft about this
may be unintentional and therefore easily fixed. A fix would remove the
contradictory references to non-convergent models in the final para of
section 3. The whole discussion of models in section 3 is just confusing if
in fact the intention is to require guaranteed eventual convergence. Model 2
should be clearly stated as *the* (only) relevant model.

Actual requirements 4.1 G1 and G2 are also confusing. But the real test of
whether there is in fact an intention to guarantee convergence is however
whether anyone is actually working on a means to achieve it. The current URP
and architecture simply does not.

I still haven't seen a redraft of URP and architecture to meet the apparant
consensus to support reliable eventual convergence under all circumstances.

2. My objection to non-atomicity still stands for final call but I'm
assuming there is little point arguing about it further within LDUP unless
others want to take it up. The draft now at least makes it possible to have
serious discussion about the issue in IETF review and does include several
requirements which cannot in fact be met without atomicity, such as accurate
replication of access controls and attributes such as "modifiers name".
although I disagree with much of the analysis in appendix B.5 and also the
continued misunderstanding of applications for multi-master replication in
appendix A on usage scenarios. There are still some inadequacies in
presentation of the issue but the fundamental question is now simply whether
or not atomicity should be a requirement rather than whether a document that
shows no comprehension of the issue at all should be presented to the IETF
at all. I still believe a fundamental technical mistake is being made on
that question. I also still believe the requirements draft should be
actively seeking input from directory users on the impact of non-atomicity.

3. I agree with the requirement 4.1 G6 for no unbounded conflict resolution
records. This is a better description than "oscillation". It is not met by
my MDCR draft and would need further work if in fact the current URP and
architecture drafts do not come up with a means of guaranteed eventual
convergence based only on timestamps. I'm not planning to do any work on it
unless some interest is shown by others as a result of failure to deliver a
viable URP and architecture with eventual convergence.

Sorry I simply don't have time to follow up on these issues at the moment.

Am just reminding that they are still there in case others want to take them
up before the document goes from LDUP to IETF final call.