Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot

Ludovic Poitou <Ludovic.Poitou@Sun.COM> Thu, 15 October 2009 11:54 UTC

Return-Path: <Ludovic.Poitou@Sun.COM>
X-Original-To: ldap-dir@core3.amsl.com
Delivered-To: ldap-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0062F3A680C for <ldap-dir@core3.amsl.com>; Thu, 15 Oct 2009 04:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQWMXTO2aGEc for <ldap-dir@core3.amsl.com>; Thu, 15 Oct 2009 04:54:19 -0700 (PDT)
Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 2BFC83A6781 for <ldap-dir@ietf.org>; Thu, 15 Oct 2009 04:54:18 -0700 (PDT)
Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9FBsKWn013140 for <ldap-dir@ietf.org>; Thu, 15 Oct 2009 11:54:20 GMT
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_LdfBewozpJVIJrRGPL7PJA)"
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRK00I000U4D200@fe-emea-09.sun.com> for ldap-dir@ietf.org; Thu, 15 Oct 2009 12:53:55 +0100 (BST)
Received: from dhcp-egnb07-211-59.france.sun.com ([unknown] [129.157.211.59]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRK00J5F11SLME0@fe-emea-09.sun.com>; Thu, 15 Oct 2009 12:53:53 +0100 (BST)
Date: Thu, 15 Oct 2009 13:53:50 +0200
From: Ludovic Poitou <Ludovic.Poitou@Sun.COM>
In-reply-to: <4AD66FAF.70805@eb2bcom.com>
Sender: Ludovic.Poitou@Sun.COM
To: Steven Legg <steven.legg@eb2bcom.com>
Message-id: <7F4E6236-E784-48F8-817D-47D6A68CB0C7@sun.com>
X-Mailer: Apple Mail (2.1076)
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <8161E89A-7D94-4347-80E8-9E736B00E8CC@Isode.com> <4AD66FAF.70805@eb2bcom.com>
Cc: LDAP Directorate <ldap-dir@ietf.org>, Xun Peng <xunpeng@huawei.com>, Lisa Dusseault <lisa.dusseault@gmail.com>, Spencer Dawkins <spencer@wonderhamster.org>, Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldap-dir>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2009 11:54:21 -0000

On Oct 15, 2009, at 2:41 AM, Steven Legg wrote:

>
> Hi Spencer,
>
> Kurt Zeilenga wrote:
>> The immediate question I have is "but why?"  That is, I'd like to  
>> understand better what the application requirements are so that I  
>> can analysis whether or not this mechanism mets those  
>> requirements.  I'd also like to understand better why none of the  
>> existing extensions in this area were (presumedly) found to do not  
>> address the application requirements.
>
> Ditto from me on the "but why". One thing the draft doesn't make clear
> is whether a subscription persists beyond the LDAP session that
> establishes it.

Ditto.


> That is, can an LDAP client create a subscription,
> end the session, and come back later with a new session and pick up
> the notifications for events that occurred in the meantime and occur
> subsequently ? If not, then this appears to be just another (though
> perhaps cleaner) way to do persistent search, for which there are
> already implementations.
>
> Have any LDAP server vendors expressed an interest in implementing  
> this
> subscription mechanism ?

We've had discussions with one of our customer who was interested in  
similar subscription / notification model, with the ability to end  
session, come back and retrieve notifications for all events since the  
end of the last session.

If this I-D is along the same line, we may implement such  
functionality in our server. There are definitely things to tidy up  
first.

Regards,

Ludovic.

>
> Regards,
> Steven
>
>> I am curious as to why firewalls and NATs are mentioned in the  
>> applicability of the specification.  Does this extension not have  
>> the same basic issues with firewalls and NATs that simple LDAP  
>> has?  That is, LDAP generally works just fine (*) through firewalls  
>> and NATs so long as they are configured to allow traversal, as most  
>> TCP-based client/server protocols do.  (* expecting issues with  
>> reverse NAT and knowledge references, and the like).
>> I didn't dig into the particulars of the extension protocol yet.  I  
>> defer comments here until I better understand the "why?".  But on  
>> first glance, I suspect it suffers from many of the problems folks  
>> have found in triggered searches and like extensions.
>> On security considerations, I suspect there are many considerations  
>> that this extension, by itself, raises.  Just referencing general  
>> LDAP security considerations seems quite inadequate to me.
>> -- Kurt
>> On Oct 14, 2009, at 1:07 PM, Alexey Melnikov wrote:
>>> Spencer Dawkins wrote:
>>>
>>>> Hi, LDAP Directorate,
>>>
>>> Hi Spencer,
>>>
>>>> Some of you may be aware of a 3GPP CT4 proposal to add a  
>>>> subscribe/notify capability to LDAP.
>>>>
>>>> I've been helping Xun Peng with a draft describing this  
>>>> extension, which I've just posted as http://www.ietf.org/id/draft-dawkins-ldapext-subnot-00.txt 
>>>> .
>>>>
>>>> Alexey told me that the next step was to request a review from  
>>>> the LDAP Directorate, asking for your opinion on AD-sponsoring  
>>>> this work, so I'm requesting your review.
>>>>
>>>> I will be present in Hiroshima for any face-to-face discussions  
>>>> that would be helpful.
>>>
>>> Do you want some time at the Apps Area meeting in Hiroshima  
>>> (Monday 9:00am)?
>>>
>>>> A note on timing - 3GPP CT4 is meeting the same week as IETF 76,  
>>>> and will be making a decision during that meeting on whether to  
>>>> use the approach described in this draft (and processed in the  
>>>> IETF) or to use an XML/SOAP alternative (not processed in the  
>>>> IETF). It would be extremely helpful to have your feedback before  
>>>> November 13 (when both IETF 76 and the CT4 meeting end).
>>>>
>>>> Thanks,
>>>>
>>>> Spencer
>>>
>>>
>>> _______________________________________________
>>> Ldap-dir mailing list
>>> Ldap-dir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ldap-dir
>> _______________________________________________
>> Ldap-dir mailing list
>> Ldap-dir@ietf.org
>> https://www.ietf.org/mailman/listinfo/ldap-dir
> _______________________________________________
> Ldap-dir mailing list
> Ldap-dir@ietf.org
> https://www.ietf.org/mailman/listinfo/ldap-dir

---
Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Manager            Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~