Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-relax-00.txt

From: Michael Ströder <[email-masked]>
Date: Fri, 01 Jul 2011 18:13:17 +0200

Kurt,

Michael Ströder wrote:
> Kurt D. Zeilenga wrote:
>> At 01:11 AM 6/20/2006, Michael Ströder wrote:
>>> Kurt D. Zeilenga wrote:
>>>> This I-D replaces draft-zeilenga-ldap-managedit-00...
>>> Any changes in protocol besides the editorial modifications?
>>
>> I included 'entryDN' in the list of attributes whose
>> NO-USER-MODIFICATION constraint cannot be relaxed.
> 
> The draft seems to be expired. What does it need to be re-submitted?

http://tools.ietf.org/html/draft-zeilenga-ldap-relax-03 is expired since end
of 2008 but some software already uses this feature. The control's OID is
still not assigned (OpenLDAP's exp. OID arc).

What is needed to get this approved at least as informational RFC?

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.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 01 Jul 2011 20:16:22 +0200

Kurt Zeilenga wrote:
> On Jul 1, 2011, at 9:13 AM, Michael Ströder wrote:
> 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?

The behaviour of web2ldap's UI already changes if this control is in effect.
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's not intended to be used generally.

Yes, the control is for the expert DSA admin.
But a good admin tool guides the admin user too. ;-)

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

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 1 Jul 2011 19:23:18 +0100

> attributes to make editable in case the control is in effect.

I would certainly support some such mechanism. At present the only way
to find out what is relaxable is to test the operation.

Also, section 3.6 requires that operational attributes may not be
relaxed unless there is a document permitting that action. The draft
itself mentions some common attributes, but omits (for exapmle) all the
attributes described in draft-behera-ldap-password-policy, where this
control is essential for user management if the policy schema is taken
at face value.

As the password policy is still in draft, it would seem appropriate to
update both drafts and submit them together. draft-behera is so widely used
in practice that it really should be at least an Informational RFC.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 1 Jul 2011 11:28:08 -0700

[Resend from subscribed address]

> still not assigned (OpenLDAP's exp. OID arc).

Purposely.  As a matter of practice, I don't provide OIDs to works-in-progress.  I prefer the OID to be assigned just prior to publication as an RFC so that one can distinguish between implementations of the RFC and earlier implementations, which might differ significantly (more than by which OID is used).

> What is needed to get this approved at least as informational RFC?

I think Experimental is better for this than Informational.  Outside of IETF circles, the difference is not terribly significant. 

> 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.  It's not intended to be used generally.

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.

-- Kurt

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 1 Jul 2011 12:33:52 -0700

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

> which attributes can be relaxed instead of maintaining a hard-coded list in

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.

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

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

---

From: Michael Ströder <[email-masked]>
Date: Mon, 04 Jul 2011 09:47:54 +0200

Kurt Zeilenga wrote:
> 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.
> 
> 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.

To stay out of nit-picking my suggestion for a definition would be:
If there's a standard document saying that the Relax Rules Control MAY be used
to add/modify the attribute the attribute type description SHOULD contain
option X-RELAX.

All the issues you wrote apply to other subschema elements anyway and web2ldap
contains a lot of fall back behaviour.

Also note that web2ldap does not automagically enable use of this control.
It's still up to the admin user to enable it manually - kind of a special
mode. But if in this mode I'd like to know which input fields to enable.

I don't know how to get out of the X- prefix issue and RFCs. But I'd consider
it very bad if LDAPv3 does not allow any extension of the schema descriptions
with additional options usable in a newer RFC.

Ciao, Michael.

---

From: [email-masked]
Date: Mon, 4 Jul 2011 22:48:11 +0200 (CEST)

> with additional options usable in a newer RFC.

What about stating that attributeTypes MAY have a X-RELAX (please note
that it needs to have a value, so X-RELAX 'TRUE' may be needed) option if
that attribute MAY be modified using the relax control?  The double
conditional would "relax" the use of this private, and thus
non-publicable, extension.

Hope I made the point, I wouldn't be able to formalize it further right
now, as I just made too direct an acquaintance with Belgian beer :)

Cheers from Brussels, p.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 4 Jul 2011 19:18:55 -0700

On Jul 4, 2011, at 12:47 AM, Michael Ströder wrote:
> I don't know how to get out of the X- prefix issue and RFCs.

Start by drafting an update RFC 4512 which changes
	extensions = *( SP xstring SP qdstrings )

to:
	extensions = *( SP extension SP qdstrings )
	extension = keystring

and updates BCP 64 (RFC 4520) to provide a registry for values of extension with appropriate registration guidelines, including possibly a reservation of values starting with "X-" for private extensions (see apps discussion concerning this practice).

> But I'd consider it very bad if LDAPv3 does not allow any extension of the schema descriptions

I note that the X- extension restriction was discussed during the LDAPbis development of RFC 4512 with, IIRC, there being insufficient support to make such a change. 

My view is that relax I-D only describes an experiment.   One of the things that might be learned by this experiment is that more detailed discovery is needed.  If so, the future standards work can take care of that.   My intent, however, is that the relax experiment not be itself an experiment in how to provide detailed discovery (which might be something to experiment with before standardizing a facility for detailed discovery).

I'm willing to make a few minor editorial changes to the I-D and then submitting it to the RFC Editor for publication on the Experimental track in the Independent Submission.  If the consensus of the IETF is, however, that the IETF rather develop a standard in this area, I have no objection to the IETF using my I-D as a basis for that work.  However, I seriously doubt the IETF has enough energy in the LDAP arena to do much LDAP work (as evident by the progress of various LDAP I-Ds), and in absence of enough energy within the IETF, we continue to encourage independent advancement in the LDAP space.

-- Kurt