RE: Objections to draft-ietf-ldapext-psearch-01.txt

[Surendra Reddy <skreddy@us.oracle.com>]

I  agree with Ed.

-Surendra



> -----Original Message-----
> From: "list@glacier.mcom.com"@us.oracle.com
> [mailto:"list@glacier.mcom.com"@us.oracle.com]On Behalf Of Ed Reed,
> Scott Isaacson, Dave Huntbach (Ed Reed)
> Sent: Friday, August 14, 1998 6:42 PM
> To: ietf-ldapext@netscape.com
> Cc: DHUNTBACH.PRV-7.PROVO@novell.com;
> ED#032#REED.PRV-MAIL4.PROVO@novell.com;
> SISAACSON.PRV-MAIL1.PROVO@novell.com
> Subject: Objections to draft-ietf-ldapext-psearch-01.txt
> 
> 
> Comments on  
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapext-psearch-01.txt 
> 
> 1. Point to point registration and event distribution is not 
> scalable; only channel-based approaches scale.  This approach of 
> LDAP persistent queries represents a dramatic over-simplification 
> of the implementation constraints and requirements for large 
> scale (internet scale) event notification systems.  This 
> persistent query approach is valid only for small-scale, 
> synchronization systems. 
> 
> 2. Both theory and empirical evidence shows that network 
> bandwidth is the first resource to be exhausted by a large scale 
> event notification system.  Without attribute-level filtering, 
> the network will be clogged with useless notifications being sent 
> just to be discarded at the LDAP client end.
> 
> 3. Each active Persistent Search registration requires an open 
> TCP connection. Even a single LDAP client with multiple active 
> Persistent Searches will require as many open TCP connections as 
> it has Persistent Searches. There are LDAP servers that have been 
> tested with hundreds of connections; some may even support 
> thousands of connections, but somewhere a practical number of 
> simultaneous open connections "service ceiling" will be reached 
> beyond which response times will be unacceptable. Dozens or 
> hundreds of LDAP Persistent Search open TCP connections will 
> adversely impact LDAP Server performance everywhere.
> 
> 4. Rather than first defining an LDAP specific event notification 
> mechanism, LDAP notification requirements should be fed into 
> Event Notification BOF to be held at the Chicago IETF meeting.  
> The suggested agenda for the BOF does not propose one solution 
> for all problems, however it doesexpress a desire to classify 
> each of the problems to see if there is any room for some common 
> effort that can be leveraged by many applications, services 
> and/or protocols.  Each applications group can then focus on 
> defining the specific events and their semantics rather than 
> reinventing notificaiton subsystems.  For example, in the LDAP 
> case, the LDAP extensions group can focus on defining what is an 
> "add" or a "delete" or a "modify" event is and what additional 
> info is needed in the event reports for these events rather than 
> defining new notification infrastructure.    At the WISEN 
> conference (Workshop on Internet Scale Event Notification, July 
> 13-14 1998,  http://www.ics.uci.edu/IRUS/wisen/wisen.html) there 
> seemed to be consensus that a common, scalable, infrastructure 
> notification subsystem could be used for many applications, 
> inlcuding directory events and notifications
> 
> Based on the above reasons, we don't believe that the LDAP 
> community should adopt or promote the mechanism described for 
> common use, much less forward it for consideration on any 
> standards track.  Instead, we believe work should go forward, as 
> described in (4) above, with a more generally useful mechanism.
> 
> Best regards,
> 
> 
> 
> -------------------
> Ed Reed, Technologist
> Novell, Inc.
> +1 801 861 3320
>