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

[Resend from subscribed address]

On Jul 1, 2011, at 9:13 AM, Michael Ströder wrote:

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

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. 

> 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.  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 protected]
> https://www.ietf.org/mailman/listinfo/ldapext