Re: [ldapext] draft-masarati-ldap-deref as ldapext work item?

Simo Sorce <simo@redhat.com> Fri, 04 December 2015 16:06 UTC

Return-Path: <simo@redhat.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C941A88EA for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 08:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiaWaLyGgt66 for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 08:06:31 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514CF1A8908 for <ldapext@ietf.org>; Fri, 4 Dec 2015 08:06:31 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 17B3596EE; Fri, 4 Dec 2015 16:06:31 +0000 (UTC)
Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4G6T5F005224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 11:06:30 -0500
Message-ID: <1449245189.3445.72.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Howard Chu <hyc@highlandsun.com>
Date: Fri, 04 Dec 2015 11:06:29 -0500
In-Reply-To: <5661B981.2000808@highlandsun.com>
References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> <5661A883.1050806@stroeder.com> <5661B981.2000808@highlandsun.com>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/ZJyoM8kfCUU_QdWtFKz5oBSwbx8>
Cc: "'ldapext@ietf.org'" <ldapext@ietf.org>, Michael Ströder <michael@stroeder.com>
Subject: Re: [ldapext] draft-masarati-ldap-deref as ldapext work item?
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Dec 2015 16:06:32 -0000

On Fri, 2015-12-04 at 16:04 +0000, Howard Chu wrote:
> Michael Ströder wrote:
> > Simo Sorce wrote:
> >> This is very true and there are products that can cope, there are also
> >> mechanism to more efficiently (at least latency wise) if you use
> >> controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00
> >>
> >> Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use
> >> it in various clients.
> >
> > I also consider this control to be very useful and therefore I've added support
> > for it in python-ldap a couple of weeks ago.  And since there are already two
> > independent server implementations it should be easy to bring this I-D to a
> > ldapext RFC.
> >
> > Not sure whether the original authors are still motivated to work on it.
> 
> I proposed this control to satisfy a need in supporting SAMBA / 
> AD-compatibility in OpenLDAP. Symas is still actively engaged in implementing 
> ActiveDirectory functionality in OpenLDAP, so yes, we are still committed to 
> this particular item.

At this point we are dependent on this control in FreeIPA (as well as
our Samba work) so I will gladly volunteer to work on it if needed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York