IETF Logo Mail Archive

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

Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Fri, 01 July 2011 18:28 UTC

Return-Path: <Kurt.Zeilenga@Isode.COM>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCFA11E8091 for <ldapext@ietfa.amsl.com>; Fri, 1 Jul 2011 11:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level:
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITuwKiV9M07v for <ldapext@ietfa.amsl.com>; Fri, 1 Jul 2011 11:28:13 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28A11E808A for <ldapext@ietf.org>; Fri, 1 Jul 2011 11:28:13 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <Tg4RuwB=gA9M@rufus.isode.com>; Fri, 1 Jul 2011 19:28:12 +0100
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4E0DF21D.8060709@stroeder.com>
Date: Fri, 01 Jul 2011 11:28:08 -0700
Message-Id: <58D4405F-1BD0-4224-A46B-C035B6F2E6D0@Isode.COM>
References: <7.0.1.0.0.20060619225054.022df6e8@OpenLDAP.org> <4497ADCB.50902@stroeder.com> <7.0.1.0.0.20060620075240.022dfba8@OpenLDAP.org> <48569DB6.3040402@stroeder.com> <4E0DF21D.8060709@stroeder.com>
To: Michael Ströder <michael@stroeder.com>
X-Mailer: Apple Mail (2.1242)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ldapext@ietf.org
Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-relax-00.txt
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 18:28:15 -0000

[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
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

v2.23.0 | Report a Bug | By Email