Subject: RE: Fwd: controlling visability of subentries

From: "Volpers, Helmut" <[email-masked]>
Date: Thu, 19 Oct 2000 10:02:32 +0200

Hi Ed,

I personally think that solution 2 is the best one, specially for 
the future.
If you take solution 1 it will also work, but at least you will create
a control for every additional service control you will support.
I think to work with a control is a clean solution but the number
of controls increase rapitly and different servers have a lot of
different controls they support.
I think there is the requirement that the protocol has to be compatible
and only some administrative clients will use this feature and a simple
LDAP Client should not been broken.
We handle subentries over LDAP for all update operations like normal entries
and for the search in a special way, so if the filter contains
ObjectClass=SUBENTRY
the search operation is only for subentries and all other search operations
exclude subentries. Is this a problem ?

> -----Original Message-----
> From: Ed Reed [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 5:25 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Fwd: controlling visability of subentries
> 
> 
> Okay, Kurt - I've reviewed what X.511 specifies for the 
> service control
> used to control subentry visibility.  What is your opinion on 
> what we should
> do in LDAP?
> 
> 1) create a control which has no parameters, but has the 
> effect that when
> it is present, it is interpreted identically to an X.511 
> service control with the
> subentries bit set TRUE; or
> 
> 2) create a control which has a parameter identical to the 
> service control
> specified by X.511.  This would have the effect of providing 
> a lot of the
> additional controls needed to add distributed operations to 
> LDAP (including
> preferChaining, chainingProhibited, etc.), but would also 
> provide things
> like timeLimit, sizeLimit, scopeOfReferral, and 
> attributeSizeLimit, etc.
> In X.511, the serviceControls are among the CommonArguments included
> with each request.
> 
> I suppose we could consider the list of controls in LDAP providing the
> equivalent to the set of CommonArguments.  
> 
> What's your take?  1 would be easier to document.  2 would lay
> important groundwork that should be considered in the context 
> of future
> work to add distributed operations to LDAP.
> 
> Ed
> 
> =================
> Ed Reed
> Reed-Matthews, Inc.
> +1 801 796 7065
> http://www.Reed-Matthews.COM
> 
> >>> "Kurt D. Zeilenga" <[email-masked]> 08/01/00 07:41AM >>>
> Forwarded to LDUP list
> >Date: Mon, 31 Jul 2000 16:23:57 -0400
> >To: [email-masked] 
> >From: "Kurt D. Zeilenga" <[email-masked]>
> >Subject: controlling visability of subentries
> >
> >One other issue I would like to raise in regards to LDAP subentry
> >is the mechanism proposed to control their visibility.  I believe
> >the approach of overloading the search filter to control visibility
> >is not the best approach.  As we've found previously, the semantics
> >of such overloads are difficult to define (and hence implement) when
> >the filter is complex (which we must assume it will be).
> >
> >I believe that LDAPsubentry visibility should be control by 
> a mechanism
> >more closely modeled after the X.500 subentry visibility mechanism.
> >In particular, I suggest use of a control.  The use of a control
> >will allow a clear and concise specification of visibility semantics
> >which facilitates implementation and use. 
> >
> >Comments?
> >
> >        Kurt
> 
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Oct 2000 09:06:57 -0400

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:

   A ServiceControls parameter contains the controls,
   if any, that are to direct or constrain the provision
   of the service. 

   ServiceControls ::= SET {
     options [0] BIT STRING {
     preferChaining (0),
     chainingProhibited (1),
     localScope (2),
     dontUseCopy (3),
     dontDereferenceAliases (4),
     subentries (5),
     copyShallDo (6), } DEFAULT {},
     partialNameResolution (7),
     manageDSAIT (8) } } DEFAULT {},
     priority [1] INTEGER
          { low (0), medium (1), high (2) } DEFAULT medium,
     timeLimit [2] INTEGER OPTIONAL,
     sizeLimit [3] INTEGER OPTIONAL,
     scopeOfReferral [4] INTEGER { dmd(0), country(1) } OPTIONAL,
     attributeSizeLimit [5] INTEGER OPTIONAL
     manageDSAITPlaneRef [6] SEQUENCE {
     dsaName Name,
     agreementID AgreementID } OPTIONAL }

-- 
Mark Smith
Netscape Communications Corp.

---

From: "Albert Langer" <[email-masked]>
Date: Fri, 20 Oct 2000 04:27:02 +1000

[Mark]

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