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

Steven Legg <steven.legg@eb2bcom.com> Thu, 15 October 2009 00:41 UTC

Return-Path: <steven.legg@eb2bcom.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 AC0CD3A6810 for <ldap-dir@core3.amsl.com>; Wed, 14 Oct 2009 17:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level:
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172]
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 M04EhuyGcn+f for <ldap-dir@core3.amsl.com>; Wed, 14 Oct 2009 17:41:24 -0700 (PDT)
Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by core3.amsl.com (Postfix) with ESMTP id A8DC03A680E for <ldap-dir@ietf.org>; Wed, 14 Oct 2009 17:41:24 -0700 (PDT)
Received: from eth3065.vic.adsl.internode.on.net ([150.101.156.248] helo=[192.168.1.182]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <steven.legg@eb2bcom.com>) id 1MyEPF-00035s-N6; Thu, 15 Oct 2009 11:41:26 +1100
Message-ID: <4AD66FAF.70805@eb2bcom.com>
Date: Thu, 15 Oct 2009 11:41:19 +1100
From: Steven Legg <steven.legg@eb2bcom.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Spencer Dawkins <spencer@wonderhamster.org>
References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <8161E89A-7D94-4347-80E8-9E736B00E8CC@Isode.com>
In-Reply-To: <8161E89A-7D94-4347-80E8-9E736B00E8CC@Isode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: Lisa Dusseault <lisa.dusseault@gmail.com>, Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, LDAP Directorate <ldap-dir@ietf.org>, Xun Peng <xunpeng@huawei.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 00:41:25 -0000

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

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