Re: [ldapext] ManageDsaIT control vs. parent referral objects

"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Fri, 07 May 2004 16:49 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04816 for <ldapext-archive@lists.ietf.org>; Fri, 7 May 2004 12:49:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8OS-0004Q0-EX; Fri, 07 May 2004 12:40:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8FU-0000gD-NT for ldapext@optimus.ietf.org; Fri, 07 May 2004 12:30:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04040 for <ldapext@ietf.org>; Fri, 7 May 2004 12:30:52 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8FT-0005qd-4a for ldapext@ietf.org; Fri, 07 May 2004 12:30:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8Ea-0005PD-00 for ldapext@ietf.org; Fri, 07 May 2004 12:30:00 -0400
Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BM8DI-0004bi-00 for ldapext@ietf.org; Fri, 07 May 2004 12:28:40 -0400
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i47GSdnC038446; Fri, 7 May 2004 16:28:39 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.0.1.1.0.20040507091058.04d22cc0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
Date: Fri, 07 May 2004 09:28:37 -0700
To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] ManageDsaIT control vs. parent referral objects
Cc: ldapext@ietf.org
In-Reply-To: <HBF.20040507vxh8@bombur.uio.no>
References: <HBF.20040507vxh8@bombur.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>

At 08:04 AM 5/7/2004, Hallvard B Furuseth wrote:
>RFC 3296 says:
>> 3.  The ManageDsaIT Control
>> 
>>    The control causes Directory-specific
>>    entries (DSEs), regardless of type, to be treated as normal entries
>>    allowing clients to interrogate and update these entries using LDAP
>>    operations.
>
>This control would make more sense to me if it did not apply to superior
>referral entries of the entries that are considered by the operation.
>For example, as far as I can tell from rfc3296, one can now use the
>manageDSAIT control to add subordinate entries below referral entries.

I think that reading is a bit far fetched.  One of the
fundamentals of the LDAP service model is that the result of
any modification of the directory (whether to the DIT or a
DSA IT) must result in a consistent directory state.

Maybe the text would be more easily understood if
        s/normal entries/entries in the protocol/

The control affects the semantics of the protocol operation, it
doesn't alter the underlying directory and/or DSA information models.

>I haven't got X.511(97); how does its ManageDsaIT service option work
>in this respect?

The ManageDsaIT service option, like the ManageDsaIT, indicates
that the operation acts with a Dsa IT management plane instead
of DIT.

RFC 3296 use of the term "normal" means only that, objects within
the selected Dsa It management plane are treated in the protocol
as if they were objects in the DIT.

I note that once LDAPBIS wraps up its work revising the 'core'
TS, I intend to undertake a major revision of this RFC.  In
particular, I plan to incorporate most (if not all) of Steven's
Directory Admin Models I-D
<http://www.watersprings.org/pub/id/draft-legg-ldap-admin-01.txt>
into the revision.

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext