Re: I-D ACTION:draft-zeilenga-ldap-relax-00.txt

On Jul 1, 2011, at 11:16 AM, Michael Ströder wrote:

> Kurt Zeilenga wrote:
>> On Jul 1, 2011, at 9:13 AM, Michael Ströder wrote:
>>> I'd also suggest that relaxable attribute types are announced with X-RELAX in
>>> the subschema subentry so that a schema-aware client can determine which
>>> attributes to make editable in case the control is in effect.
>> 
>> I rather not get into detail advertisement of what DSAs will or will not
>> relax when this control is used.  This is a problem that not easily
>> solved.
>> 
>> It's basically assumed that this control will be used by the DSA
>> administrator who as knowledge of what will get relaxed when it's used.
> 
> What problems are not easily solved?

It seems to me you want to use schema to determine whether or not a DSA, not necessarily the master DSA for the target object, implements relaxation of some constraint associated with some element of schema.  And you want to use subschema for this.

This I see as quite problematic.

First, there's the problem of what exactly does it mean for something to be published in a subschema.  The assumptions a client (or server) can make based upon something being published in a subschema is quite limited.

For instance, consider the case where a master DSA for a particular context provides a schema description for a DSA-specific operational attribute.   What do we expect shadow and caching DSAs to do in this case?  If they don't implement the DSA-specific operational attribute, are they to remove it from the subschema when they publish it?  Are they to modify it based upon their relax capabilities?  Are they to add DSA-specific operational attributes descriptions to the subschema for which they support but the master doesn't provide in the subschema?   (Note: while LDAP allows for use of non-X.500 subentry models, it's written in terms of the X.500 models.  Extensions should generally be written likewise.)

Even if we were to assume a DSA-specific schema model, such as common in today's LDAP-only directory servers, what are DSAs to do when the constraint is relaxable in certain cases but not others, such as which entry is the target.

And what if the schema elements has multiple constraints which possibly could be relaxed, how do you distinguish precisely which constraints can be relaxed?  For instance, does X-RELAX on objectClass merely mean that object metamorphism is supported, or does it also mean that constraint on adding obsolete classes is relaxed?   Is the server to list X-RELAX if any constraint can be relaxed?  or is needed to indicate precisely which constraint can be relaxed?

Precision is problematic as I intended the use cases only as examples of constraints would could be relaxed by this control.

What about advertising authorization specific relaxation availability?

Also note that X- use in RFCs is problematic.  RFC 4512 says:
   Implementors should note that future versions of this document may
   expand these definitions to include additional terms.  Terms whose
   identifier begins with "X-" are reserved for private experiments and
   are followed by <SP> and <qdstrings> tokens.

as anything published as an RFC is not a "private experiment" by definition.

There was discussion back in LDAPbis days, IIRC, about why adding non-X-* terms to the schema definitions is a bad idea.  IIRC, that discussion was part of the BCP 64 (RFC 4520) discussion.  Please note that adding a non-X-* term today would require updating of either RFC 4512 or RFC 4520… and that's more than I want to chew off.

> The behaviour of web2ldap's UI already changes if this control is in effect.

How does web2ldap determine whether or not this control can only be used in conduction with another control, say the authzid control (to assert a role identity)?   (rhetorical question)

Obviously there are significant limitations of what schema discovery can reasonably provide.

> E.g. input fields of relaxable attributes are enabled if the user turns on the
> relax rules control. Obviously I'd prefer to look at the subschema to find out
> which attributes can be relaxed instead of maintaining a hard-coded list in
> web2ldap's code.

It was my intent that this control only be used at the explicit request of the directory administrator.   Hence, I never consider detailed discover as within scope of the I-D.

>> It's not intended to be used generally.
> 
> Yes, the control is for the expert DSA admin.

Yes, but only when specifically requested.

> But a good admin tool guides the admin user too. ;-)

Consider, for instance, an admin using a tool wants to change the entryUUID of an entry.

I would think a good admin tool could detect that the operation the admin user proposes is counter to various constraints, and then ask the admin if they would like to try the operation anyways (without the relax control) or would they like to include the relax control.

Likewise if the user wants to change a device into a person.

I don't think any admin tool should use this control without the explicit approval of the user.  This because the control side-steps the directory models, and doing that can have side-effects bound that which any reasonable tool could possibly understand.

>> I see that some implementations rely use of this relax control by users who
>> might no be theDSA administrators to overcome poor design of certain
>> LDAP/X.500 "policy" extensions.   Such use is beyond the scope of this
>> extension.  I would rather see better designs in these policy extensions.
> 
> Yes, so please comment in detail on the mailing lists where you saw this. ;-)

The most common abuse of this control is to overcome the poor design of various password policy extensions.  See my prior rants on this and other LDAP lists about various password policy extensions.  Beyond that, I won't comment about them in this thread as that would be highly disruptive to discussions directly concerning this I-D.

> 
> Ciao, Michael.
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext