From alexey.melnikov@isode.com Wed Oct 14 13:07:37 2009 Return-Path: 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 E47E13A6814 for ; Wed, 14 Oct 2009 13:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 T2s3EYt61jf6 for ; Wed, 14 Oct 2009 13:07:37 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2C2F43A69C9 for ; Wed, 14 Oct 2009 13:07:36 -0700 (PDT) Received: from [92.40.185.137] (92.40.185.137.sub.mbb.three.co.uk [92.40.185.137]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 14 Oct 2009 21:07:37 +0100 Message-ID: <4AD62F79.6090703@isode.com> Date: Wed, 14 Oct 2009 21:07:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Spencer Dawkins References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> In-Reply-To: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault , LDAP Directorate , Xun Peng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:07:38 -0000 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 From Kurt.Zeilenga@Isode.com Wed Oct 14 13:56:19 2009 Return-Path: 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 BE2613A69C9 for ; Wed, 14 Oct 2009 13:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 VI6L66S-VeU9 for ; Wed, 14 Oct 2009 13:56:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9AEB63A686A for ; Wed, 14 Oct 2009 13:56:18 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 14 Oct 2009 21:56:19 +0100 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga In-Reply-To: <4AD62F79.6090703@isode.com> Date: Wed, 14 Oct 2009 13:56:03 -0700 Message-Id: <8161E89A-7D94-4347-80E8-9E736B00E8CC@Isode.com> References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: LDAP Directorate , Lisa Dusseault , Spencer Dawkins , Xun Peng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:56:19 -0000 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. 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 From steven.legg@eb2bcom.com Wed Oct 14 17:41:25 2009 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Spencer Dawkins 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 , Kurt Zeilenga , LDAP Directorate , Xun Peng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From Ludovic.Poitou@Sun.COM Thu Oct 15 04:54:21 2009 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 In-reply-to: <4AD66FAF.70805@eb2bcom.com> Sender: Ludovic.Poitou@Sun.COM To: Steven Legg 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 , Xun Peng , Lisa Dusseault , Spencer Dawkins , Kurt Zeilenga 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 11:54:21 -0000 --Boundary_(ID_LdfBewozpJVIJrRGPL7PJA) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --Boundary_(ID_LdfBewozpJVIJrRGPL7PJA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE
= On Oct 15, 2009, at 2:41 AM, Steven Legg wrote:


Hi Spencer= ,

Kurt Zeilenga wrote:
The immedi= ate question I have is "but why?"  That is, I'd like to understa= nd better what the application requirements are so that I can analysi= s whether or not this mechanism mets those requirements.  I'd al= so like to understand better why none of the existing extensions in t= his area were (presumedly) found to do not address the application re= quirements.

Ditto from me on the "but why". One t= hing the draft doesn't make clear
is whether a subscription persis= ts beyond the LDAP session that
establishes it.

Ditto.


That is, can an LDAP client create a subscri= ption,
end the session, and come back later with a new session and= pick up
the notifications for events that occurred in the meantim= e and occur
subsequently ? If not, then this appears to be just an= other (though
perhaps cleaner) way to do persistent search, for wh= ich there are
already implementations.

Have any LDAP server= vendors expressed an interest in implementing this
subscription m= echanism ?

We've had discus= sions with one of our customer who was interested in similar subscrip= tion / 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 d= efinitely things to tidy up first.

Regards,<= /div>

Ludovic.


Regards,
Steven

I am curious as to why firewalls and NATs are mentioned in the app= licability of the specification.  Does this extension not have t= he same basic issues with firewalls and NATs that simple LDAP has? &n= bsp;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 reve= rse NAT and knowledge references, and the like).
I didn't dig into the particulars of the extens= ion protocol yet.  I defer comments here until I better understa= nd the "why?".  But on first glance, I suspect it suffers from m= any of the problems folks have found in triggered searches and like e= xtensions.
On security cons= iderations, I suspect there are many considerations that this extensi= on, by itself, raises.  Just referencing general LDAP security c= onsiderations seems quite inadequate to me.
-- Kurt
On= Oct 14, 2009, at 1:07 PM, Alexey Melnikov wrote:
Spencer Dawkins wrot= e:

Hi, LDAP Direct= orate,

Hi Spencer,

Some of you may be aware o= f 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 requ= est 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-fac= e 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 a= pproach described in this draft (and processed in the IETF) or to use= an XML/SOAP alternative (not processed in the IETF). It would be ext= remely helpful to have your feedback before November 13 (when both IE= TF 76 and the CT4 meeting end).

Tha= nks,

Spencer


________________________________________= _______
Ldap-dir mailing list
Ldap-dir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ldap-dir
_______________________________________________
Ldap-dir mailing list
Ld= ap-dir@ietf.org
https://www.ietf.= org/mailman/listinfo/ldap-dir
___________________= ____________________________
Ldap-dir mailing list
Ldap-dir@ietf.org
https://www.ietf.or= g/mailman/listinfo/ldap-dir

---
Lud= ovic Poitou                 &= nbsp;                  S= un Microsystems Inc.
OpenDS Community Manag= er            Directory Services &= nbsp;        
http://blogs.sun.com/Ludo/       &nbs= p; Grenoble Enginee= ring Center - France

=
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 i= s prohibited.
If you are not the intended r= ecipient, please contact the sender by
repl= y email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~







--Boundary_(ID_LdfBewozpJVIJrRGPL7PJA)-- From spencer@wonderhamster.org Wed Oct 14 11:59:15 2009 Return-Path: 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 70A5D28C0CF for ; Wed, 14 Oct 2009 11:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001] 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 2xsPuN4mV06u for ; Wed, 14 Oct 2009 11:59:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A72CC3A689B for ; Wed, 14 Oct 2009 11:59:14 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LbLFK-1MZYfs3DIo-00kCK1; Wed, 14 Oct 2009 14:59:14 -0400 Message-ID: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> From: "Spencer Dawkins" To: "LDAP Directorate" Date: Wed, 14 Oct 2009 13:59:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/l1dV2IFvgxSH1tpyhaXWTEZ2yVgHRFjBACcz FdfkuemyTtxvt1QyrlbZO0gPULEvgqJplV2JzkjW8/z1wD4S0K 8FeA9lrAPm2zybS8aQOBaLeoMme4XcMTZcDTI+mllk= X-Mailman-Approved-At: Thu, 15 Oct 2009 08:04:38 -0700 Cc: Xun Peng Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 18:59:15 -0000 Hi, LDAP Directorate, 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. 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 From spencer@wonderhamster.org Wed Oct 14 13:53:41 2009 Return-Path: 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 1ACC23A681F for ; Wed, 14 Oct 2009 13:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11] 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 jx3NDDkpHKuu for ; Wed, 14 Oct 2009 13:53:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 3CBCE3A682B for ; Wed, 14 Oct 2009 13:53:40 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LdYEs-1MXKMH1SgE-00iphY; Wed, 14 Oct 2009 16:53:40 -0400 Message-ID: <6D9D3C3DED1F4C1D9331491DCE2C8A48@china.huawei.com> From: "Spencer Dawkins" To: "Alexey Melnikov" References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> Date: Wed, 14 Oct 2009 15:53:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/6BMctupjhwjjO4UilJ9yHcgqxxM5s4wL1TeC +qW+w+ySBOxuUxvWvCY2NkIMban/n3P5mCo/rW/QdUzgdmBAQU dY2PZtucmm8t/dus0hZza9dCsOuNHTrnQLI+u81bSs= X-Mailman-Approved-At: Thu, 15 Oct 2009 08:04:38 -0700 Cc: Lisa Dusseault , LDAP Directorate , Xun Peng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:53:41 -0000 Hi, Alexey, That would probably be an excellent thing to do. Are you thinking 10-15 minutes? Thanks, Spencer > 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 > > From spencer@wonderhamster.org Fri Oct 16 05:23:35 2009 Return-Path: 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 5F24928C209 for ; Fri, 16 Oct 2009 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 O-r-zP1TRrXC for ; Fri, 16 Oct 2009 05:23:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 7657928C0DF for ; Fri, 16 Oct 2009 05:23:34 -0700 (PDT) Received: from S73602b ([199.227.132.226]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MC3mC-1N7XGW18Ge-009DBg; Fri, 16 Oct 2009 08:23:29 -0400 Message-ID: From: "Spencer Dawkins" To: "Kurt Zeilenga" , "Alexey Melnikov" References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <8161E89A-7D94-4347-80E8-9E736B00E8CC@Isode.com> Date: Fri, 16 Oct 2009 07:23:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+RbtmzEV75vQglBEilXMUpz3iSCGOX5c04euO 0csUuZg2g13MUbJYsLHNqS3DDKO1DkmWWbLgHfoj2IXI/itAqk JmP/gLMne85NUWLVUTwVKhzIWThd9tj5yPj28NYaR4= Cc: LDAP Directorate , Lisa Dusseault , Xun Peng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 12:23:35 -0000 Hi, Kurt, I'm replying to a question you asked, but my reply is probably also relevant to Steven Legg's question about subscription lifetimes. > 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). My understanding of this proposal (Peng is the expert on the proposal, I'm the guy who understands the IETF) is that the LDAP client would not close the TCP connection to the LDAP server, but would leave the TCP connection open, so that the LDAP server can send notifications in a timely manner. This isn't normal LDAP-style TCP connection handling, as I understand it (please correct me if I am confused). The alternatives would be o having the LDAP client poll periodically to pick up notifications (as you visualized) - this wasn't chosen, because the goal is that notifications be delivered in a timely manner, or o having the LDAP server open a TCP connection to the LDAP client - this wasn't chosen, because it trips over one-way firewall policies. So I was imagining that we would have problems with firewall and NAT binding timeouts, etc. in ways that other LDAP operations would not. That's what I was thinking about when I added this section, just before we submitted. Does this make sense? (And, if so, should this model of operation be stated more clearly in the draft? :-) As for Steven's question - I believe that the LDAP server would remove the subscription if the TCP connection is closed, or reset due to unreachability of the client. Does this make sense, or would you prefer to see an LDAP-level unsubscribe operation? I'd also like to thank you guys for the near-instantaneous feedback. Spencer From Kurt.Zeilenga@Isode.com Fri Oct 16 13:54:18 2009 Return-Path: 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 5B2093A689D for ; Fri, 16 Oct 2009 13:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 XxRaVmK9c1R9 for ; Fri, 16 Oct 2009 13:54:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6234F3A68B7 for ; Fri, 16 Oct 2009 13:54:17 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 16 Oct 2009 21:54:18 +0100 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga X-Priority: 3 In-Reply-To: Date: Fri, 16 Oct 2009 13:54:01 -0700 Message-Id: <3C26F5F6-E4EE-4507-B17B-02354D36584E@Isode.com> References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <8161E89A-7D94-4347-80E8-9E736B00E8CC@Isode.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: Lisa Dusseault , LDAP Directorate , Xun Peng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:54:18 -0000 If I understand all that you and Xun have said, this specification is attempting to mechanism that allows an LDAP client to maintain a copy of select directory content, presumedly with a requirement of eventual (but timely) convergence of the copy with the directory content. Is that correct? If so, then I think the question many of then have is, how does LDAP Content Sync [RFC 4533], or LCUP [RFC 3928], or various other mechanisms that have been suggested in the past fail to met the application requirements? That is, we understand you don't want to poll for changes, but why aren't any of the existing mechanisms we already have to avoid polling for changes not suitable? -- Kurt From Kurt.Zeilenga@Isode.com Fri Oct 16 13:55:37 2009 Return-Path: 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 DAE6D3A6883 for ; Fri, 16 Oct 2009 13:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 A+eGJVS0ezDH for ; Fri, 16 Oct 2009 13:55:37 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E01DC3A6817 for ; Fri, 16 Oct 2009 13:55:36 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 16 Oct 2009 21:55:37 +0100 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga X-Priority: 3 In-Reply-To: <3C26F5F6-E4EE-4507-B17B-02354D36584E@Isode.com> Date: Fri, 16 Oct 2009 13:55:19 -0700 Message-Id: References: <7A57206D08E2483A8136B7AEA627CEB1@china.huawei.com> <4AD62F79.6090703@isode.com> <8161E89A-7D94-4347-80E8-9E736B00E8CC@Isode.com> <3C26F5F6-E4EE-4507-B17B-02354D36584E@Isode.com> To: Kurt Zeilenga X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: LDAP Directorate , Lisa Dusseault , Spencer Dawkins , Xun Peng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:55:37 -0000 On Oct 16, 2009, at 1:54 PM, Kurt Zeilenga wrote: > If I understand all that you and Xun have said, this specification > is attempting to mechanism that allows an LDAP client to maintain a > copy of select directory content, presumedly with a requirement of > eventual (but timely) convergence of the copy with the directory > content. s/attempting to mechanism/attempting to provide a mechanism/ > > Is that correct? If so, then I think the question many of then have > is, how does LDAP Content Sync [RFC 4533], or LCUP [RFC 3928], or > various other mechanisms that have been suggested in the past fail > to met the application requirements? That is, we understand you > don't want to poll for changes, but why aren't any of the existing > mechanisms we already have to avoid polling for changes not suitable? > > -- Kurt > > _______________________________________________ > Ldap-dir mailing list > Ldap-dir@ietf.org > https://www.ietf.org/mailman/listinfo/ldap-dir